Porównanie wydajności: WinAVR (avr-gcc) a Bascom-AVR w testach programowych

Sat Sep 25, 2004 8:40 pm   

Program testowy:

--- Bascom ---

Dim I As Byte
For I = 1 To 20
Portb = 12 * I
Next

--- avr-gcc ---


char I;
for(I=1;I<=20;I++)
{
PORTB=12*I;
}



Wyniki:
WinAVR | Bascom
Ilosc cykli: 178 | 2700
Rozmiar prog.: 316B | 418B

I co Wy na to?

Ps. Prosił bym o podanie wyników z innych kompilatorów.

Sat Sep 25, 2004 9:33 pm   

No, C jest bardziej wydajne od Basic'a. Spróbuj to samo napisać w
assemblerze, a zobaczysz, że wyniki będą jeszcze lepsze Pozdrawiam

--
WJ

Sat Sep 25, 2004 9:44 pm   

Maksymilian Dutka wrote:


jak to zmierzyć?


mi na avr-gcc wyszło:

mlodedrwale@mlodedrwale:~/Desktop$ avr-size wsad.hex
text data bss dec hex filename
0 110 0 110 6e wsad.hex

a wersja kompilatora to gcc 3.4.1



--
-=GumibaR=-

Co robi? by?y prezydent na hubie dc?
www.mlodedrwale.neostrada.pl/slawni.html

Sat Sep 25, 2004 9:54 pm   

WJ napisał(a):


ale to miejsce moze wtedy kosztowac kilka k$ ))
avr-gcc dla zwyklego ludka jest chyba najlepsze... no i asm:)

--
Pozdrawiam - Przemcio Ż.
http://www.svpl.info - Savoir-Vivre w sieci...
http://www.nasza.behende.pl - strona Nasza:)))
- MY - FORUM - GALERIA - TY -
gg: 1156769, tlen: belmotybe

Sat Sep 25, 2004 10:05 pm   

On Behalf Of Maksymilian Dutka

Nie pisz bzdur, jak nie wiesz co porównujesz!
megaAVR:
cykle 444
kod 250
90Sxxxx:
cykle 1764
kod 156

Przykład w asm:
..include "m128def.inc"
ldi R18,$01
ldi R17,$0C
petla:
mul R17,R18
out PORTB,R0
inc R18
cpi R18,$15
brne petla

całość ma 7 bajtów
całość wykonuje się w 142 cyklach.

Pytanie.
jakim cudem kod zajmujący 316 bajtów wykonuje się w 178 cyklach?

pzdr
Artur

--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika

Sat Sep 25, 2004 10:44 pm   

On Sat, 25 Sep 2004 23:40:00 +0200, Maksymilian Dutka wrote:

Ze to za malo miarodajny test.

J.

Sun Sep 26, 2004 5:49 am   

Maksymilian Dutka wrote:


a probowales
for (I=1; I<=240; I+=12)

Odpuszczasz sobie mnozenie.
Kompilator z optymalizacja sam moze dosc do
podobnych wnioskow.

Krzysiek Rudnik

Sun Sep 26, 2004 9:06 am   

WJ wrote:


Pod jakim wzgledem? Kod w C jest najczesciej wydajniejszy
(choc to zwykle jest zasluga dobrego optymalizatora, a nie
samego jezyka). Natomiast w jezykach wyzszego poziomu
niz asemblery strukturalne (jak ktos ladnie nazwal C i C++ )
wydajniejszy jest programista.


Z dobrym kompilatorem nie wygrasz, jesli nie znasz architektury
wewnetrznej procesora (zaleznosci miedzy poszczegolnymi
jednostkami funkcjonalnymi oraz skladowymi potoku itd.) na wylot.

Pozdrawiam
Piotr Wyderski

Sun Sep 26, 2004 10:13 am   

Hmmm zastanawiajace chyba dla prockow AVR nie ma zadnych problemow aby pobic
w wydajnosci jakikolwiek kompilator jezyka C. To nie jest procesor Pentium.


PS. Nie znam AVR ale nie wydaje mi sie zeby mial potoki, pamiec chache i tym
podobne bajery.

Pozdrawiam
Thomek

Sun Sep 26, 2004 11:02 am   

On Sun, 26 Sep 2004 12:06:39 +0200, Piotr Wyderski wrote:

Dokladnie - nawet bym powiedzial ze C optymalizacje utrudnia ..


Eee - polemizowalbym. Co tam moze programista poprawic ?
Jakosc kompilatora sie liczy.



Ale to jest prosty i w dodatku 8-bit. Wygrasz o pare dlugosci.

J.

Sun Sep 26, 2004 11:40 am   

J.F. wrote:


To prawda, chocby aliasing blokuje lub bardzo utrudnia wiele
optymalizacji. Do tego dochodzi powstawanie tzw. nieredukowalnych
grafow przeplywu, gdy wykorzystuje sie instrukcje goto -- a takie
grafy wymagaja znacznie bardziej wyrafinowanych analizatorow,
niz programy tylko z petlami for/while i ifami.


Wydajnosc _programisty_, a nie kodu. Wiecej kodu ze srednio
mniejsza liczba bledow mozna napisac w tym samym czasie, innymi
slowy. Wez skrajny przyklad Prologu: interpreter ma dokonac
unifikacji syntaktycznej podanych wyrazen; jak to sie w srodku
dzieje, to juz nikogo nie obchodzi.


To sie liczy zawsze, niezaleznie od jezyka. :-)


Fakt, na AVR-ku finezyjnych optymalizacji nie da sie robic, nawet
dobry kompilator-projekt studencki bedzie generowal zadowalajacy
kod.


Nie przesadzajmy, na tak prostym procesorze kompilator nie ma
zbyt wielu miejsc do popsucia kodu. Nawet byle jaki kod bedzie
dzialal niezle. Czlowiek moze duzo wygrac na wlasciwym wyborze
organizacji danych w pamieci, ale to nie znaczy, ze kompilatory
tego nie potrafia -- po prostu wiele z nich ma swoje korzenie
na duzych maszynach (m.in. GCC), a tam sie az tak wielkiej wagi
do tego nie przywiazuje, wiec i same kompilatory nie maja
zaimplementowanych silnych algortymow do planowania tego.
A ze np. AvrGCC rozni sie od GCC praktycznie tylko generatorem
kodu wynikowego, to trudno sie spodziewac rewelacji w tym
wzgledzie.

Pozdrawiam
Piotr Wyderski

Sun Sep 26, 2004 12:21 pm   

On Sun, 26 Sep 2004 13:13:16 +0200, Thomek wrote:

Dokladnie.
W dodatku prosta i 8-bit architektura utrudnia optymalizacje
kompilatorom..

J.

Sun Sep 26, 2004 3:16 pm   

On Sun, 26 Sep 2004 14:40:18 +0200, "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote:
[.....]

stosować goto do wyjścia z kilku zagnieżdzonych pętli - IMO kod jest
wtedy bardziej czytelny. No i jak wygląda sprawa w przypadku break
oraz continue?


ale IMO bolączką w przypadku uC i C jest zużycie RAM-u którego ilość w
uC jest dziwnie mała w stosunku do kilobajtów FLASH-a i megaherców
zegara. I tutaj jest pole do popisu dla assemblerowych rzeźbiarzy. .
Chodzi mi o takie sytuacje gdy np. dwie funkcje używają np. 50
bajtowych buforów i gdy te funkcje są od siebie wzajemnie niezależne,
to można na te bufory wykorzystać ten sam kawałek RAM-u. Człowiek
wykona taką optymalizację bez trudu, ale z tego co widzę, kompilatory
radzą sobie z tym gorzej. Niektóre, np. kompilator Microchipa,
wprowadzają rozszerzenia standardu C (tzn. magiczne słówka kluczowe)
którymi koder może dać kompilatorowi wskazówki.


o coś innego?

Regards,
/J.D.
--
Jan Dubiec, jdx#slackware.pl, mobile: +48 506 790442

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

Sun Sep 26, 2004 3:17 pm   

On Sun, 26 Sep 2004 14:02:31 +0200, J.F. <jfox_nospam@poczta.onet.pl> wrote:

aplikacji? ;-)

Regards,
/J.D.
--
Jan Dubiec, jdx#slackware.pl, mobile: +48 506 790442

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

Sun Sep 26, 2004 4:05 pm   

Jan Dubiec napisał(a):


A mógłbyś opisać problem nieco dokładniej? Bo to na razie wygląda na
proste użycie buforów jako zmiennych lokalnych w funkcji.

--
Pozdrawiam
Bartosz Sarama