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

Mon Sep 27, 2004 5:47 pm   

Jan Dubiec wrote:


Jest sobie darmowy RTOS eCos napisany w asm (HAL), C (wszystkie
podsystemy i sterowniki) i C++ (kernel!). Może lepiej rozwijać gotowe
rozwiązania ?

--
point

Mon Sep 27, 2004 6:39 pm   

On Mon, 27 Sep 2004 13:39:24 +0200, "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote:
[.....]

kodu źródłowego aplikacji, to po co dbać o jego przejrzystość i elegancję
jeśli aplikacja działa poprawnie? Poza tym "wszyscy" znają C więc producenci
produkują kompilatory i biblioteki C, a skoro producenci robią narzędzia do C,
to "wszyscy" uczą się C. I błędne koło się zamyka. A przerwać je trudno bo
w powszechnym mniemaniu C++ daje wielokrotnie wolniejszy i pamięciożerny kod
wynikowy - ludzie również nie lubią zmian i nie przyjmują do wiadomości że
pewne rzeczy się zmieniają. Zobacz np. ile osób rzeźbi w assemblerze tam gdzie
z praktycznego punktu widzenia nie ma z tego żadnych korzyści. No i jest jeszcze
jedna rzecz - o ile stosnkowo łatwo jest nauczyć się C++, to aby je efektywnie
wykorzystywać trzeba zmienić sposób myślenia. A to IMO jest znacznie trudniejsze.
Zapewne sam widziałeś wiele programów napisanych w "C z obiektami". :-)


"napisana obiektowo" w C i skompilowana kompilatorem C będzie trochę mniej
wydajna niż ta sama aplikacja przepisana na C++. W przypadku nietrywailnej
aplikacji kompilator C++ raczej lepiej niż człowiek "zaimplementuje"
obiektowość. :-)

BTW. Bez RTTI i dynamic cast można spokojnie żyć, ale wyjątki by się przydały.
Oglądałem kod wygenerowany przez g++ i tam try jest rozwijane w wywołanie
procedury __cxa_allocate_exception, throw w wywołanie __cxa_throw itp. Jak się
domyślam, są to funkcje wbudowane w kompilator. I tak się zastanawiam czy
rzeczywiście stanowią one duży problem jeśli chodzi o wymagania szybkościowo-
pamięciowe. Bo tak na chłopski rozum to wydaje mi się że one wykonują jakieś
szybkie operacje na stosie (alokacja pamięci dla rzucanego obiektu) i ewentualnie
wołają konstruktor (w przypadku "rzucania" typów złożonych). Co tutaj może być
problemem? Przepełnienie stosu? Przecież takie coś może się zdarzyć nawet
wtedy gdy używamy C lub assemblera. I jeszcze jedno - czy w throw/try/catch
są thread safe z mocy standardu C++, nie są thread safe, czy też jest to zależne
od kompilatora?

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

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

Mon Sep 27, 2004 7:22 pm   

Tylko musisz sobie znaleźć ze 2 miesiące wolnego ))

Sorry, ale rozbawiły mnie te dywagacje nad wyższością Świąt ....
Ludzie czy to ma znaczenie w jakim języku piszemy ?
Najważniejsze, żeby program był napisany z głową i dobrze zoptymalizowany
już w trakcie pisania. Jakby nie spojrzeć dobra optymalizacja jest wynikiem
doświadczenia. To, że sam Bascom nie jest oszczędny to wcale nie oznacza, że
jest gorszy. Ja tam wolę zamiast się męczyć ze składnią C , która jest
ukierunkowana na sprzęt, a nie na programistę napisać ten program o wiele
szybciej w Bascomie, który nie stwarza tylu problemów. Zamiast siedzieć
tydzień, zrobić to samo w 1 lub 2 dni. Wszystko jest oczywiście kwestią
przyzwyczajenia i dopasowania się oraz wprawy. A na zbyt duży kod jest
prosta rada - dołożyć 10zł i kupić większego procka. Z resztą dziwią mnię
czasami widziane projekty oparte na jakimś małym procesorze, który dodatkowo
wyposażony jest w układy we/wy w postaci PCF8574 oraz pamięci EEPROM.
Przecież wydając te same pieniądze można spokojnie kupić bardziej
wypasionego procka, dzięki czemu także zmniejszy się nasz kod, ponieważ
odejdą procedury obsługi I2C dodatkowych układów.

Ja tam cenię sobie wygodę, szybkość pisania i uruchamiania układu. A jeżeli
zależy mi na szybkości procedur wtedy wstawki assemblerowe.
Suma-sumarum pisanie w Bascomie może okazać się porównywalne z C++
Oczywiście wszystko zależy co kto lubi i w czym się dobrze czuje.
Dla przykładu kiedyś postanowiłem nauczyć się ST-Realizera. Dla tych co nie
wiedzą - jest to obrazkowy język programowania tzn. rysuje się algorytmy.
Niby łatwiejszy od Assemblera, C++, czy nawet Bascoma. Jednak mi to nie
leży i łatwiej jest mi się nauczyć tych trudniejszych języków niż Realizera.
Jednak nie jest to powód, żebym go uważał za coś gorszego - po prostu nie
odpowiada mi i już. Na nic się zdał zakup literatury do Realazera. Ale może
kiedyś się przełamię i sięgnę i po to narzędzie :)

A w Bascomie przede wszystki cenię sobie zwarte środowisko i masę gotowych
procedur. Niestety AVR GCC nie daje takiej wygody pracy.

Jacek "Plumpi"

Mon Sep 27, 2004 8:02 pm   

On Mon, 27 Sep 2004 22:22:14 +0200, "Jacek \"Plumpi\""
<plumpixjr@wp.pl> wrote:


Bo to czasem ciekawe nawet :-)


To masz dobrze. U mnie kilka prockow, zadnych AVR wiec co mialem
wybrac? C/C++ jest i na procki i na PCty - wiec latwo bylo sie
zdecydowac. Zreszta C++ na wieksze procki coraz bardziej mnie zaczyna
wciagac - naprawde mocne narzedzie. (Dzieki Piotrowi Wyderskiemu sie
tym troche zainteresowalem - warto).


Zalezy jaki program, jaka rodzina prockow, itp, itd...
U mnie zwiekszenie kodu ponad 256kB bedzie skutkowac koniecznoscia
zmieniania plytki 6 warstwowej (tylko taki RAM tam siedzi).


avr-gcc nie znam, ale skoro gcc to moze... emacs? :-)


--
Jerry

Mon Sep 27, 2004 8:53 pm   

On Mon, 27 Sep 2004 20:47:28 +0200, point <.@.org> wrote:
[.....]

źródła eCosa, ale nigdy go nie uruchamiałem na żadnym sprzęcie. Ja myślałem
o czymś mniejszym, np. czymś w stylu Nut/OSa ale z wywłaszczaniem a nie
cooperative multitasking i napisanego w języku wspierającym obiektowość.

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

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

Mon Sep 27, 2004 10:22 pm   

On Mon, 27 Sep 2004 22:22:14 +0200, "Jacek \"Plumpi\"" <plumpixjr@wp.pl> wrote:
[.....]

of all evil". Innymi słowami po prostu lepiej klepać soft jak leci a potem,
jeśli okaże się że nie spełnia on wymagań, szukać wąskich gardeł i eliminować
je poprzez poprawianie/dobór odpowiedniego algorytmu, struktur danych i na końcu
stosowanie sztuczek typu ręczne rozwijanie petli czy też stosowanie wstawek
assemblerowych. Oczywiście obecnie odpowiednie algorytmy i struktury danych
można dobrać przed rozpoczęciem pisania softu ponieważ można wcześniej przeczytać
sobie książkę, np. autorstwa wspomnianego Knutha. :-)


czy MCS-51 i nie będziesz miał Bascoma. A kompilator C będzie prawie napewno.


dobrze ukierunkowana ponieważ sporo softu przeniesionego z jednej platformy
na inną da się skompilować bez żadnych modyfikacji. :-)


zaimplementować np. PPP. Bo dominującym czynnikiem będzie tutaj czas
poświęcony na studiowanie RFC dotyczących PPP. A jest tego trochę. No
i jeszcze trzeba doliczyć czas potrzebny na debugowanie i testowanie - kto
wie czy nie dłuższy od tego pierwszego.

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

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

Mon Sep 27, 2004 11:51 pm   

Jan Dubiec wrote:

[ciach -- przyznaje, ciekawy punkt widzenia]


A to jest ciekawe zjawisko. Przeciez (z drobnymi wyjatkami)
kod napisany w C daje sie od skompilowac kompilatorem C++.
Schematy translacji sa takie same, optymalizator i generator
kodu wynikowego sa wspolne. Roznice sa praktycznie tylko
w czesci odpowiedzialnej za przeksztalcenie kodu zrodlowego
na wewnetrzna reprezentacje posrednia (ktora podlega
nastepnie optymalizacji i z ktorej sie generuje kod wynikowy).
Co do pamieciozernosci, to tu jest troche prawdy, ale to
w sporej czesci wynika z braku doswiadczenia w projektowaniu
obiektowym. A jak ktos chce, to sobie moze przeciazyc
operator new i dostac _calkowita_ kontrole nad przydzialem
pamieci.


Hm, to bardzo odwazna opinia. Mam taka hipoteze, ze nikt na swiecie
nie zna calego C++. Owszem, mozna latwo opanowac podstawy i zyc
w przekonaniu, ze sie doskonale opanowalo ten jezyk, ale z czasem sie
odkrywa jak malym jego fragmentem jego wlasnosci sie poslugiwalo.
Wez na przyklad programowanie generyczne, tam sie bez przerwy
odkrywa nowe rozwiazania. Jesli masz ochote, to sprobuj zdobyc np.
"Modern C++ Design" Andrei'a Alexandrescu, zobaczysz, co mam na mysli.

BTW, sam system typow w C++ jest Turing-zupelny, czyli rownowazny
dowolnemu komputerowi. Innymi slowy: mozna w samych typach zapisac
dowolny program komputerowy, wykonywany w czasie kompilacji. :-)


Przede wszystkim w taki sposob, by nie trzymac sie slepo jednego
paradygmatu (np. obiektowego, strukturalnego itd.) w nadziei, ze
gwarantuje on sukces. Gdyby tak bylo, to by dzis istnial jeden
doskonaly, uniwersalny jezyk programowania, a nie tysiace.
Wielu rzeczy po prostu nie wolno robic np. obiektowo, bo -- jak
to ktos obrazowo ujal -- ta obiektowosc pasuje do problemu jak
garbaty do sciany. :-)


Sam w taki sposob pisalem, gdy uwazalem, ze znam C++. :-)


No, to zalezy jak sie ten program napisze, ale... czytelnie, wydajnie, w C
-- wybierz dwie dowolne cechy. :->


Calkowicie sie zgadzam, nigdy z tego mechanizmu w praktyce nie
korzystalem. Jak sie okazuje konieczne uzycie w C++ takich rzeczy,
to najczesciej jest to glosny dzwonek ostrzegawczy, ze z cos jest
zle ze struktura koncepcyjna programu.


Wydajnosc spada niewiele, byc moze prawie wcale. Problem
stanowia wymagania pamieciowe: zazwyczaj wyjatki sa
impelmentowane z wykorzystaniem pomocniczego stosu.
Na pececie to zaden problem, bo kogo obchodzi ten dodatkowy
kilobajt zuzycia RAMu, ale jak ma sie mikrokontroler o 256
bajtach pamieci, to nie bardzo jest gdzie umiescic dwa stosy
i jeszcze obszar danych statycznych. A ze sie bardzo przydaja,
to inna sprawa. :-)


Heh, znalezienie miejsca na ten stos w ogole. :-)


Szczerze mowiac nie bardzo rozumiem problem. Wyjatki to
jest mechanizm wybitnie lokalny, kazdy watek ma osobny stos
wyjatkow i niezaleznie obsluguje sekcje try/catch, wiec w
ktorym miejscu ma sie pojawic interferencja?

Pozdrawiam
Piotr Wyderski

Tue Sep 28, 2004 8:51 am   

Na 51 także jest Bascom.
A co do Bascoma - no cóż ? Póki co rozwijany jest przez jednego autora w
porównaniu do C czy C++
I to chyba jest problemem. Chociaż istnieją kompilatory Basica na różne
rodziny mikrokontrolerów.


Nie przesadzaj i nie opowiadaj bajek. Tak samo można powiedzieć o Basicu czy
konkretnie o Bascomie. Niestety zarówno w Bascomie jak i w C++ istnieją
odwołania do konkretnych bloków mikrokontrolera, do portów lub innych
urządzeń funkcjonalnych np. przetworników, sprzętowych PWM, ISP czy kwestia
innej konfiguracji UART lub przerwań, które uniemożliwiają bespośrednie
przeniesienie programu na inny procesor.


A może nie wyważać otwartych drzwi i skorzystać z gotowych rozwiązań, nieco
modyfikując do własnych potrzeb ?
http://www.mcselec.com/easy_tcp_ip.htm
A tu efekt pracy:
http://64.77.35.38

A co do studiowania - to chyba nie jest zależne od języka programowania,
ponieważ i tak aby wykorzystać taki czy inny protokół, czy to w C czy w
Bascom musisz go poznać. Tak więc dla mnie nie jest to argumentem. Zaś
argumentem są gotowe procedury wielu protokołów zaimplementowane w
kompilatorze Bascom, których nie musisz szukać po sieci, a których jest brak
w kompilatorach C , C++ czy Assemblerze.
))

--
Jacek "Plumpi"
plumpixjr@wp.pl
Usuń iksa - zabezpieczenie antyspamowe

Tue Sep 28, 2004 5:22 pm   

Użytkownik "Jan Dubiec" <jdx@SPAMTRAP.slackware.pl> napisał w wiadomości
news:87zn3bijrt.fsf@hs001.slackware.pl...

W dosc prosty sposob mozna zaimplementowac wyjatki w C.
Da sie to zrobic za pomoca makr i nie rozni sie prawie od skladnie C++.

Pozdr
AK

Tue Sep 28, 2004 5:55 pm   

On Tue, 28 Sep 2004 02:51:51 +0200, "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote:
[.....]

mi się odkryć jakąś nowość. :-)

[.....]

ciężko jest przestawić się na coś innego. Ot, taka ludzka natura. Ja np. kiedyś
próbowałem trochę pobawić sie w programowanie funkcyjne i nic z tego nie
wyszło. :-)


wady moich pierwszych wypocin nie dlatego że zacząłem się uważać za mistrza
C++ (którym zdecydowanie nie jestem) ale po zrozumieniu co to jest OOA i OOD.

[.....]


[.....]

Czy użycie wątków, z punktu widzenia zapotrzebowania na stos, różni się
zasadniczo np. od wywołania pewnej liczby zagnieżdżonych funkcji albo
jakiejś nie dającej się zamienić na pętlę rekurencji? No i dlaczego muszą
mieć oddzielny stos? Czy nie można zaalokować pamięci dla wyjątków w ramach
stosu bieżącego wątku? Taki stos w stosie.

[.....]

czy też nie. Bo przykro by było gdyby się okazało że po napisaniu większego
kawałka wielowątkowego kodu okazało się że implementacja wyjątków w jakimś
kompilatorze korzysta jednak ze zmiennych globalnych nie zapewniając przy
tym żadnego mechanizmu synchronizacji. :-)

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

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

Tue Sep 28, 2004 6:22 pm   

On Tue, 28 Sep 2004 11:51:19 +0200, "Plumpi" <plumpixjr@wp.pl> wrote:
[.....]

na sprzęt"? :-)




jak bogatą biblitekę standartową, to zawsze będzie można znaleźć taką
aplikację, gdzie ta biblioteka praktycznie do niczego się nie przyda
albo tylko nieznacznie skróci czas tworzenia softu. Tak więc nie można
stwierdzić że Bascom jest lekiem na całe zło tego świata. Chociaż
zapewne jest znakomity do trywialnych projektów typu "odczytaj temperaturę
z czujnika i wyślij wynik na wyświetlacz i/lub UARTa".

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

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

Tue Sep 28, 2004 8:28 pm   

Tu powinienem rozdzielić te myśli, ponieważ w wypowiedzi chodziło mi tylko i
wyłącznie o przenoszenie programów pomiędzy sprzętami.
A co do ukierunkowania to Bascom ukierunkowany jest na programistę, ponieważ
składnia tego języka jest bardziej ergonomiczna i łatwiejsza do zrozumienia
oraz zapamiętania w przeciwieństwie do składni C. Nie mówiąc już o
wspaniałej rzeczy jaką jest help załączony do tego oprogramowania także w
wersji polskiej, który pomaga rozwiązywać większość problemów, z którymi
może zetknąć się programista. Zawarte w nim są przykłady użycia komend czy
procedur.


Ale jest i można ją wykorzystać - i to właśnie jest plus.
Pewnym minusem jest jednak to, że ukierunkowany jest tylko pod pewną grupę
procesorów jednego producenta.
Jednak trzeba powiedzieć, że jak na jedną osobę, która tworzy Bascoma to
jest to naprawdę kawał, wspaniałej roboty.


Częściej jednak o wiele. Prawdopodobnie niewiele osób - zwolenników C, C++
wie, że w Bascomie można podobnie tworzyć własne procedury i zapisywać je
jako oddzielne bloki, do których można się odwoływać w tworzonych
programach - jak include.


Ależ ja tego nie twierdzę. Twierdzę natomiast, że przyspiesza i ułatwia
tworzenie kosztem większego zapotrzebowania na zasoby sprzętowe, których nie
zawsze się wykorzystuje do końca podczas tworzenia. I pozwala w sposób
naturalny i bezstresowy na szybkie zrozumienie zasad programowania.
Przecież mając do dyspozycji procesor z 8 czy 16 lub 128kB flash i kod
wynikowy np. 2kB w przypadku C oraz 4kB Bascom - jaka jest dla mnie różnica
? Zarówno w pierwszym jak i w drugim przypadku nie wykorzystuję możliwości
procesora. Znaczenie będzie miało dopiero jak zacznę pisać coś większego.
Ale i wtedy jest na to rada, aby użyć procka z większym flashem.
Ewentualnie, kiedy krytycznym jest prędkość wykonywania programu. Wtedy
pomagają wstawki assemblerowe.


Dokładnie! Choć wcale te projekty bascomowe nie muszą być trywialne, jeżeli
tylko będą pisane z głową :)

Jacek "Plumpi"