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

Sun Sep 26, 2004 10:36 pm   

On 26 Sep 2004 22:33:55 +0200, ziel wrote:

Nie przesadzajmy, w koncu mowa o trywialnie prostym programie,
ktory praktycznie na kazdym procku da sie zrobic zgrabnie.
Podziwiac mozna co najwyzej kompilator, ze nie skopal..

J.

Sun Sep 26, 2004 10:56 pm   

On Mon, 27 Sep 2004 00:03:32 +0200, "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote:

trzebaby zdefiniowac unię która składałaby się z tych dwóch buforów. To byłoby
szybsze od new. Aczkolwiek nieeleganckie. :-)


po głowie napisanie w C++ małego, opensourceowego RTOS-a na H8 i ARM-y.
Myślałem też o Ada, ale tutaj może być klopot z kompilatorem na te platformy.
To tyle na temat prywatnych zainteresowań. Natomiast zawodowo (mówimy
o zastosowaniach embedded) odejście od C jest prawie niemożliwe. Bo albo
nie ma kompilatora C++ dla danego uC, albo kosztuje on ciężką kasę, albo
jest kompilatorem C++ tylko z nazwy, albo nawet jeśli kompilator jest osiągalny,
to producent urządzenia wykorzystującego dany uC dostarcza tylko biblioteki C.

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 11:05 pm   

On Sun, 26 Sep 2004 23:53:56 +0200, "Thomek" <lipin@usunto.poczta.fm> wrote:
[.....]

nie zoptymalizował programu.


przypadku trzeba użyć jakiegoś mechanizmu synchronizacji. Albo po prostu nie
używać współdzielonej pamięci.

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 11:08 pm   

On Behalf Of Maksymilian Dutka

To wytłumacz mi proszę, dlaczego mamy takie duże rozbieżności:
Twój BASCOM - kod 418b cykli 2700
Mój BASCOM - kod 156b cykli 1764

Oraz w jaki sposób kod zawierający 158 rozkazów (około)
i pętlę wykonującą się 20 razy można wykonać w 178 cyklach?
Dla ułatwienia.
Procesor w tak prostym programie musi przejść przynajmniej jeden raz
przez każdy rozkaz. Jeśli jest inaczej, kompilator generuje wybitnie
nadmiarowy kod i nadaje się wyłącznie do śmieci.
Pozostaje nam 20 cykli na : skok do początku pętli, wykonanie
soft_mnożenia, przesłanie wyniku do portu. Trochę mało.

Ale możemy zrobić zawody.
Napisz jakiś większy program w C, a ja go przeniosę na BASCOM.
Jestem w 100% pewny, że mój program będzie mniejszy i szybszy
od Twojego.
Tylko jeden warunek - Twój program musi mieć więcej niż 4kB kodu.
Oczywiście nie licząc tablic itp. to ma być program _coś_ robiący.
Np. odczyt danych, obliczanie średniej ważonej, przelicznie jednostek,
obsługa 2 timerów i ... no w sumie niech to będzie jakiś regulator
PID.

pzdr
Artur
PS
Przypuszczam, że jak napiszesz ten program, to przestaniesz
zachwycać się C, a zaczniesz doceniać własne doświadczenie.

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

Sun Sep 26, 2004 11:08 pm   

On Behalf Of Maksymilian Dutka

Bo może autor BASCOM'a zakładał większy poziom inteligencji programisty?
A czy dla podstawienia w miejsce stałej=12 zmiennej=12 kod będzie taki sam?

pzdr
Artur

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

Sun Sep 26, 2004 11:29 pm   

On Behalf Of J.F.



b. amfy
c. kochanki
d. innych przyjemnych uzywek.
;-)

pzdr
Artur

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

Sun Sep 26, 2004 11:29 pm   

On Behalf Of J.F.

Nie znam PICów, tylko że przejrzeniu listy instrukcji
wydało mi się trudnym napisanie jakiegoś większego
programu w asm.

pzdr
Artur

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

Mon Sep 27, 2004 9:15 am   

J.F. wrote:


A to niby dlaczego? Jedyna roznica miedzy operatorem
a zwykla funkcja bedzie nazwa widzialna przez linker...

Pozdrawiam
Piotr Wyderski

Mon Sep 27, 2004 9:48 am   

J.F. wrote:


To nie jest tak, ze bierzemy dowolny program i sprawdzamy, czy
a nuz w jego przypadku sie uda. )) Program musi spelniac wiele
bardzo silnych ograniczen (np. brak wywolan rekurencyjnych itd.),
aby sie dalo na nim uruchomic obecne weryfikatory. Jesli jednak
jest on w wymaganej postaci, to wowczas jest gwarancja, ze
weryfikator powie o nim wszystko, tj. albo stwierdzi, ze nie ma
sciezki prowadzacej do katastrofy, albo jest i wowczas poda
sposob jej osiagniecia (kontrprzyklad).

Tak to dziala dla systemow o skonczonej liczbie stanow. Patrzac
na problem bardzo pragmatycznie mozna stwierdzic, ze kazdy
realizowalny fizycznie uklad elektroniczny ma skonczona pamiec,
czyli ma skonczona liczbe stanow, czyli rozpoznaje pewien jezyk
regularny. Jezyki te maja te wspaniala ceche, ze chyba wszystkie
ich wlasnosci sa rozstrzygalne (tak m.in. dziala sprawdzanie, czy
dwa rozne uklady cyfrowe, w tym sekwencyjne, robia to samo).

Wielu ludzi mysli nad weryfikacja systemow o (potencjalnie)
nieskonczonej liczbie stanow, tj. o pamieci, ktora nie jest
ograniczona przez stala, lecz zalezy od wielkosci danych
wejsciowych. Tego w ogolnosci sie zrobic nie da, co wiadomo
juz od ~70 lat. Mozna tylko wyszukiwac szczegolne przypadki
rodzin takich problemow i do nich konstruowac algorytmy.
To sie czesto udaje, np. widzaialem automatyczny dowod
spelnialnosci podanych warunkow przez pewna quicksorta.
Pojawia sie jednak problem praktyczny: ten program sortowal
zaledwie 6-bitowe liczby, a komputer produkowal dowod przez
IIRC 50 minut...


No niezupelnie, praktyczny przyklad podal Jan. One maja
"sprawiac wrazenie", ze zyja wiecznie, tzn. jesli od pewnego
miejsca nie sa uzywane, to mozna je bezpiecznie zabic
i wynik wykonania programu nie ulegnie zmianie. Cala zabawa
polega na stwierdzeniu tego faktu. :-)


Przerwania niewiele przeszkadzaja -- one nie moga wystapic
w dowolnym momencie (traktujac czas jako zmienna rzeczywista),
lecz jedynie na poczatku cyklu rozkazowego. Mozna wiec
zrezygnowac z przerwan rozumianych doslownie i miedzy
kazda instrukcje programu wstawic skok warunkowy do
procedury obslugi przerwania, a nastepnie weryfikowac _taki_
program. Przestrzen stanow oczywiscie bardzo puchnie, ale
koncepcyjnie niczego to nie zmienia.

Pozdrawiam
Piotr Wyderski

Mon Sep 27, 2004 9:52 am   

Użytkownik ziel napisał:

Z tym że GCC nie bawił się w soft-mnożenie, on sobie przekształcił ten
fragment na coś innego :)


Ok , jak będe miał czas to napiszę i wyślę forum.

Mon Sep 27, 2004 10:39 am   

Jan Dubiec wrote:


Od placement new? Przeciez ono sie rozwija do pustego
ciagu instrukcji, a to juz trudno bardziej zoptymalizowac. ;-)


Jestem mocno zaskoczony, dlaczego tak jest? Przeciez kompilator
C++ do zastosowan embedded (tj. bez wyjatkow, bez RTTI i dynamic
cast itp.) rozni sie od kompilatora C tylko front-endem...

Pozdrawiam
Piotr Wyderski

Mon Sep 27, 2004 12:30 pm   

On 27 Sep 2004 02:29:20 +0200, ziel wrote:

I niewykluczone ze masz racje. Ale ten programik jest mniejszy,
zadnych skomplikowanych operacji :-)

J.

Mon Sep 27, 2004 2:56 pm   

On Mon, 27 Sep 2004 12:48:09 +0200, Piotr Wyderski wrote:

Ja ci przyznam racje ze pomoca goto mozna narobic takiego bigosu ze
sie nikt nie zorientuje jak to zadziala.
Ale nie widze powodu dla ktorego rozsadne uzycie mialoby utrudniac -
np wlasnie wyjscie z zagniezdzonej petli.


Hm .. jestem w stanie dowolny program zapisac w postaci jednej
petli, w ktorej bedzie multum if i pomocniczych zmiennych logicznych.
Ciekawe co na to weryfikator :-)


Taa .. tylko juz 8 bajtow pamieci powoduje liczbe stanow
przekraczajaca mozliwosci praktyczne dzisiejszych komputerow :-)


Dla nieokreslonej ilosci liczb ?


50minut to znosnie, obawialem sie 50 mln lat :-)

Nawiasem mowiac - quick sort mi sie zawiesil.
Podejrzewam ze powodem byla arytmetyka zmiennoprzecinkowa
o mantysie innej niz 2 - w rezultacie srednia arytmetyczna
dwoch liczb mogla wyjsc mniejsza niz obie liczby, co prowadzi
do zawieszenia algorytmu .. chyba Dijkstry ?

J.

Mon Sep 27, 2004 4:02 pm   

J.F. wrote:


Oj, ale my od pewnego czasu rozmawiamy o zupelnie innym problemie. ))
Mowa o "robieniu bigosu" przez goto byla w kontekscie prostych algorytmow
analizy _przeplywu_. Pozniej rozmowa zeszla na temat analizy _zywotnosci
zmiennych_.


Jesli tych zmiennych logicznych bedzie ograniczona liczba (tj. nie
bedziesz ich sobie dorabial podczas dzialania programu), to nie uda
Ci sie dokonac takiego przeksztalcenia. Rozpoznawanie dowolnego
jezyka nieregularnego dla slowa o dlugosci n wymaga Omega(log log n)
komorek pamieci, czyli wiecej, niz stalej ich liczby...


Wbrew pozorom one bardzo lubia takie grafy decyzyjne.
Powiem wiecej, one czesto w srodku trzymaja sobie opis
podanego przez uzytkownika systemu w takiej wlasnie formie.


Jesli sie eksploracji przestrzeni stanow dokonuje metoda brute
force, to tak wlasnie jest. Na szczescie wymyslono wiele
algorytmow pozwalajacych analizowac za jednym zamachem
olbrzymie grupy stanow -- w jaki inny sposob w ciagu 15 lat
udaloby sie powiekszyc nasze mozliwosci o 113 rzedow? :-)


Nie dam glowy, ale chyba tak (dawno to czytalem).
Tu znajdziesz kilka publikacji na ten temat:

http://www.fmi.uni-stuttgart.de/szs/publications/project-smc.shtml

Pozdrawiam
Piotr Wyderski

Mon Sep 27, 2004 5:18 pm   

Nie uwazam tak, napisalem ze trzeba zajac sie samemu tym problemem wiec
przewidziec
sytuacje ktorych kompilator nie potrafi przewidziec a czlowiek ktory pisze
program jest
je w stanie przewidziec.

PS.
;] troche niezrowumiale wyszlo.

Pozdrawiam
Thomek