NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - PIC czy AVR? Doświadczenia z kompilatorami HiTech i GCC w programowaniu uC
Goto page Previous 1, 2, 3 ... 13, 14, 15, 16 Next
Mario
Guest
Guest
Mon Apr 07, 2014 10:06 pm
W dniu 2014-04-07 23:35, Sylwester Łazar pisze:
Quote:
Jakbyś nie kombinował z tego przykładu z AVR nie wykażesz, że po
kompilacji kod jest wielokrotnie mniej wydajny. Ani w ilości instrukcji
ani w czasie wykonywania.
Po analizie głównej pętli sortującej widać, że:
stosunek czasu wykonywania kodu w C do czasu wykonywania kodu w ASM
będzie ok. 3x większy.
W pierwszym poście zrobiłem błąd.
Podałem:
"2) Testów czasowych _nie robiłem_, ale główna pętla przepisywania rekordów
ma w asm: 20 instrukcji,
a w C po przekompilowaniu: 121 instrukcji.
Wygląda na to, że w C program działa jakieś 6x wolniej."
Przeprosiłem za to i skorygowałem.
Chodziło o 121 bajtów,
czyli instrukcji tam jest ok. 60.
Czyli już masz Tc/Tasm = ~3x
Tc/Tasm = 1,6 jest liczbą nierealną.
Z moich doświadczeń wynika, że:
czasowo ten stosunek wychodzi jeszcze gorzej.
Ale to, aby było solidnie, należałoby zmierzyć dodając timer.
i dlatego analiza czasowa NIE BYŁA PRZEPROWADZANA.
Zobacz sobie na metodę qsort().
Tam używa się rekurencji.
Czyli jeżeli kompilator, (użyję Twojego języka i mojego)
jest nieoptymalny/spartolił sprawę w głównej pętli,
to rekurencji podlega także wykładniczo czas realizacji całości.
I właśnie rekurencyjny qsort() masz zaimplementowany w bibliotece C30
Microchipa w standardzie.
Może znajdzie się ktoś, kto dokona ANALIZY czasowej, bo ja niestety nie mam
czasu,
a tylko ochotę
A potem powiesz, że zrobiłem to, aby się pochwalić.
kompilacji kod jest wielokrotnie mniej wydajny. Ani w ilości instrukcji
ani w czasie wykonywania.
Po analizie głównej pętli sortującej widać, że:
stosunek czasu wykonywania kodu w C do czasu wykonywania kodu w ASM
będzie ok. 3x większy.
W pierwszym poście zrobiłem błąd.
Podałem:
"2) Testów czasowych _nie robiłem_, ale główna pętla przepisywania rekordów
ma w asm: 20 instrukcji,
a w C po przekompilowaniu: 121 instrukcji.
Wygląda na to, że w C program działa jakieś 6x wolniej."
Przeprosiłem za to i skorygowałem.
Chodziło o 121 bajtów,
czyli instrukcji tam jest ok. 60.
Czyli już masz Tc/Tasm = ~3x
Tc/Tasm = 1,6 jest liczbą nierealną.
Z moich doświadczeń wynika, że:
czasowo ten stosunek wychodzi jeszcze gorzej.
Ale to, aby było solidnie, należałoby zmierzyć dodając timer.
i dlatego analiza czasowa NIE BYŁA PRZEPROWADZANA.
Zobacz sobie na metodę qsort().
Tam używa się rekurencji.
Czyli jeżeli kompilator, (użyję Twojego języka i mojego)
jest nieoptymalny/spartolił sprawę w głównej pętli,
to rekurencji podlega także wykładniczo czas realizacji całości.
I właśnie rekurencyjny qsort() masz zaimplementowany w bibliotece C30
Microchipa w standardzie.
Może znajdzie się ktoś, kto dokona ANALIZY czasowej, bo ja niestety nie mam
czasu,
a tylko ochotę
A potem powiesz, że zrobiłem to, aby się pochwalić.
Z czego wynikają twoje projekcje na temat mojego ewentualnego
zachowania? Jakiś uraz osobisty?
Twoje rozważania na temat efektów kompilacji na PICach zostały
uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
PICów. Tak więc z tej waszej analizy można co najwyżej wyciągnąć
wniosek, że programiści c powinni unikać platformy PIC, a programiści
asm bardzo przywiązani do architektury nie powinni przechodzić na c bo
mocno stracą na wydajności kodu. Nie wynika jednak z tego ogólna zasada,
że kompilowanie z c ma dawać wielokrotnie mniej wydajny kod.
--
pozdrawiam
MD
MichaĹ Lankosz
Guest
Guest
Mon Apr 07, 2014 10:12 pm
W dniu 2014-04-07 23:17, Sylwester Łazar pisze:
Quote:
Dobrze, że producenci samochodów w te brednie nie uwierzyli,
bo inaczej musiałbym na noc zostawiać samochód na biegu jałowym.
Inaczej musiałbym przez minutę kręcić rozrusznikiem rano,
bo to Panie nowoczesny samochód, a nie jakieś dziadostwo!
:-)
Wyjątkowo nietrafne porównanie.
W sumie racja, przekręcasz kluczyk na zapłon, naciskasz start i czekasz
minutę na odpalenie silnika.
Mylicie system otwarty z wbudowanym i do tego czasu rzeczywistego.
Porównujecie systemy o skrajnie różnym stopniu złożoności.
--
Michał
Nie mylimy. Zastanawiamy się tylko jak to możliwe,
że mikrokontroler powiedzmy 10Mhz w samochodzie potrafi w ułamek sekundy
uruchomić silnik,
dozować skład mieszanki paliwowej, zmierzyć 5 temperatur, odczytać stan
sondy Lambda,
sterować silniczkami krokowymi itp., a przyjemność jazdy jest wspaniała..
bo inaczej musiałbym na noc zostawiać samochód na biegu jałowym.
Inaczej musiałbym przez minutę kręcić rozrusznikiem rano,
bo to Panie nowoczesny samochód, a nie jakieś dziadostwo!
:-)
Wyjątkowo nietrafne porównanie.
W sumie racja, przekręcasz kluczyk na zapłon, naciskasz start i czekasz
minutę na odpalenie silnika.
Mylicie system otwarty z wbudowanym i do tego czasu rzeczywistego.
Porównujecie systemy o skrajnie różnym stopniu złożoności.
--
Michał
Nie mylimy. Zastanawiamy się tylko jak to możliwe,
że mikrokontroler powiedzmy 10Mhz w samochodzie potrafi w ułamek sekundy
uruchomić silnik,
dozować skład mieszanki paliwowej, zmierzyć 5 temperatur, odczytać stan
sondy Lambda,
sterować silniczkami krokowymi itp., a przyjemność jazdy jest wspaniała..
Bo on niczego innego nie potrafi. Co więcej! Ten mikrokontroler ze swoim
programem nie potrafi uruchomić innego silnika, nie obsłuży innych sond
niż te dedykowane, nie skomunikuje się z modułami firm "trzecich", nie
wykona skryptu użytkownika.
On robi tylko 25 rzeczy "jednocześnie" i nic ponadto nie umie. PC robi
ze 300 razy więcej rzeczy "jednocześnie" i na dodatek jest gotowy na
kolejne setki tysięcy innych zadań bardziej lub mniej przewidywalnych.
Quote:
Drugi typ z kolei ma 1 000 MHz, 4 rdzenie, jest 100x droższy, produkowany w
10x większym wolumenie,
a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
abym mógł przeczytać wiadomość w trybie ASCII i przyjemność z korzystania
10x większym wolumenie,
a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
abym mógł przeczytać wiadomość w trybie ASCII i przyjemność z korzystania
Widocznie używasz armaty na muchę. Zainstaluj DOSa na 386 33MHz. Wąskim
gardłem w tych komputerach była dyskietka albo dysk twardy więc możesz
dać kartę CF - bardzo fajnie działa. Jeszcze tylko trochę gimnastyki z
obsługą sieci i już. 640kB starczy na system i uruchomienie czytnika
e-mail. A jak Ci się znudzi to go zamkniesz i uruchomisz edytor tekstu.
Chiwritera o ile pamiętam na 286 nawet używałem bez zacięć. Potem z
niego wyjdziesz i dla rozrywki uruchomisz Pacmana czy innego węża. To Ci
będzie szybko startowało i szybko działało. A do sortowania wiadomości
poprawisz czytnik i napiszesz własną procedurę sortowania w ASM. Tylko
czy tablica 65536 elementowa starczy? Zakładamy że starczy, ale potem to
już nie będzie tak prosto przerobić przez dodanie 'long' przed 'int'.
--
Michał
Pszemol
Guest
Guest
Mon Apr 07, 2014 10:28 pm
"Sylwester Łazar" <info@alpro.pl> wrote in message
news:lhv5fa$1vr$1@mx1.internetia.pl...
Quote:
Nie mylimy. Zastanawiamy się tylko jak to możliwe,
że mikrokontroler powiedzmy 10Mhz w samochodzie potrafi w ułamek
sekundy uruchomić silnik, dozować skład mieszanki paliwowej,
zmierzyć 5 temperatur, odczytać stan sondy Lambda,
sterować silniczkami krokowymi itp., a przyjemność jazdy jest wspaniała..
że mikrokontroler powiedzmy 10Mhz w samochodzie potrafi w ułamek
sekundy uruchomić silnik, dozować skład mieszanki paliwowej,
zmierzyć 5 temperatur, odczytać stan sondy Lambda,
sterować silniczkami krokowymi itp., a przyjemność jazdy jest wspaniała..
I tu znowu się mylisz... Ten komputer przez pierwsze parę sekund
pracuje w tzw. otwartej pętli, właśnie po to aby dac czas się
silnikowi nagrzać, czujnikom ustalić swoje odczyty itp, itd...
Wbrew pozorom komputer pokładowy w samochodzie nie ma
wiele do roboty, zwłaszcza jeśli chodzi o obsługę samego silnika..
Quote:
Drugi typ z kolei ma 1 000 MHz, 4 rdzenie, jest 100x droższy,
produkowany w 10x większym wolumenie,
a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
abym mógł przeczytać wiadomość w trybie ASCII i przyjemność
z korzystania jest marna i ciągle maleje.
produkowany w 10x większym wolumenie,
a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
abym mógł przeczytać wiadomość w trybie ASCII i przyjemność
z korzystania jest marna i ciągle maleje.
Ja nie widzę powodu dla którego nie mógłbyś w 15 sekund na tym
komputerze odpalić MS-DOSa 3.30 i pocztę w trybie ASCII odczytać
np. programem do poczty pod MS-DOS o nazwie Menuet czy jakoś tak.
Problem jest inny - Ty odpalasz silną maszynę uniwersalną mogącą Ci
pomóc zaprojektować stację kosmiczną lub silnik odrzutowy w CAD
i używasz jej do odczytania skrzynki pocztowej co może zrobić telefon.
Sylwester Ĺazar
Guest
Guest
Mon Apr 07, 2014 10:58 pm
Quote:
Twoje rozważania na temat efektów kompilacji na PICach zostały
uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
PICów.
Naprawdę ciężko z Tobą się rozmawia:
uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
PICów.
Naprawdę ciężko z Tobą się rozmawia:
Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F
Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC
z kodem ASM z drugiego.
Poza tym masz JASNO i WPROST napisane, że chodzi o CYKLE,
a nie instrukcje.
czyli to jest porównanie czasowe jednego uC z zupełnie innym.
No nie wiem jak musi pracować umysł człowieka, aby wyciągnąć wniosek,
że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.
Przecież w tamtej dyskusji porównywane były zupełnie inne uC.
Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z
dyskusji i usiłujesz wyciągnąć wniosek,
że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to
chodzi, niż napisałbyś
na tym samym uC w ASM.
Toż to bzdura.
Równie dobrze mógłbyś spojrzeć na temperaturę za oknem i jak ci wyjdzie 1,
to oznacza, że
nie warto pisać w ASM, bo to to samo co w C.
Ale zaraz zaraz....
A wiesz, że możesz mieć rację?
Jakbyś Ty napisał niezbyt udany kod w asm i w C, to u Ciebie mogłoby być:
Tc/Tasm = 1,6.
Po co się ograniczać.
Niech będzie i Tc/Tasm = 0,1
I teraz już wiem.
Ty już zrobiłeś sobie takie doświadczenie.
Napisałeś w C. Wyszło Ci, że Twój kod sortuje Ci 5 liczb w 5 sekund,
a potem napisałeś swój kod w ASM i wyszło Ci, że liczy w 50 sekund.
Teraz rozumiem, dlaczego piszesz w C.
Wyciągnąłeś prawidlowy wniosek
Śpij spokojnie.
S.
Sylwester Ĺazar
Guest
Guest
Mon Apr 07, 2014 11:02 pm
Quote:
Problem jest inny - Ty odpalasz silną maszynę uniwersalną mogącą Ci
pomóc zaprojektować stację kosmiczną lub silnik odrzutowy w CAD
i używasz jej do odczytania skrzynki pocztowej co może zrobić telefon.
pomóc zaprojektować stację kosmiczną lub silnik odrzutowy w CAD
i używasz jej do odczytania skrzynki pocztowej co może zrobić telefon.
To pisz dalej z telefonu :-)
Twój telefonowy czytnik newsów:
"Microsoft Windows Live Mail 14.0.8117.416"
Dobranoc:-)
S.
Pszemol
Guest
Guest
Tue Apr 08, 2014 12:12 am
"Dariusz Dorochowicz" <dadoro@_wp_._com_> wrote in message
news:53429065$0$2379$65785112@news.neostrada.pl...
Quote:
Tylko patrzę, patrzę, i o ile widzę go w DIP8, to już w SO8 czy czymś
podobnym już nie widzę. No, ale TSSOP16 w ostateczności też może być.
podobnym już nie widzę. No, ale TSSOP16 w ostateczności też może być.
Dzisiejsza młodzież to wybredna jakaś...
Pszemol
Guest
Guest
Tue Apr 08, 2014 2:18 am
Sylwester Łazar <info@alpro.pl> wrote:
Quote:
Problem jest inny - Ty odpalasz silną maszynę uniwersalną mogącą Ci
pomóc zaprojektować stację kosmiczną lub silnik odrzutowy w CAD
i używasz jej do odczytania skrzynki pocztowej co może zrobić telefon.
To pisz dalej z telefonu :-)
Twój telefonowy czytnik newsów:
"Microsoft Windows Live Mail 14.0.8117.416"
pomóc zaprojektować stację kosmiczną lub silnik odrzutowy w CAD
i używasz jej do odczytania skrzynki pocztowej co może zrobić telefon.
To pisz dalej z telefonu :-)
Twój telefonowy czytnik newsów:
"Microsoft Windows Live Mail 14.0.8117.416"
Nie ma problemu...
Poczta, usenet - i z komputera i z tableta i z telefonu.
Czy Ty jeszcze pamiętasz o co właściwie Ci chodzi w tej dyskusji?
Bo coraz bardziej się miotasz i na oślep strzelasz...
Dariusz Dorochowicz
Guest
Guest
Tue Apr 08, 2014 6:59 am
W dniu 2014-04-07 20:43, Michał Baszyński pisze:
Quote:
pytanie było o 8 nóżek, po co w takim dużo więcej?
No więc właśnie czasem 8 nóżek jest wystarczające, a zasobów jest mało.
wystarczy że masz dwa urządzenia łączące się jakimś protokołem
szeregowym, ale różnym, i nie masz możliwości ingerencji w nie. Tu
często brakuje właśnie RAMu, bo sama obsługa protokołów jest względnie
prosta i mieści się w całkiem niewielkim flaszu. Jeszcze więcej trzeba
kiedy masz protokoły operujące na tym samym medium fizycznym i chcesz
mieć urządzenie rozpoznające z czym ma do czynienia (bo czemu nie?) i
żeby cokolwiek zacząć musisz zebrać trochę próbek tego, co przychodzi.
Oczywiście zawsze można dać jakąś kostkę na SPI, ale w końcu nie o to
chodzi.
Quote:
BTW - jak się poszuka, to ARM-y (ale z trochę z większą ilością nóżek)
są też robione w wersji 5V (a nie 3,3V), np. Kinetis E czy Toshiby.
są też robione w wersji 5V (a nie 3,3V), np. Kinetis E czy Toshiby.
Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z 3V.
Pozdrawiam
DD
Mario
Guest
Guest
Tue Apr 08, 2014 12:01 pm
W dniu 2014-04-08 00:58, Sylwester Łazar pisze:
Quote:
Twoje rozważania na temat efektów kompilacji na PICach zostały
uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
PICów.
Naprawdę ciężko z Tobą się rozmawia:
Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F
Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC
z kodem ASM z drugiego.
uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
PICów.
Naprawdę ciężko z Tobą się rozmawia:
Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F
Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC
z kodem ASM z drugiego.
To po co te twoje porównania z wyliczeniem 1.6?
Quote:
Poza tym masz JASNO i WPROST napisane, że chodzi o CYKLE,
a nie instrukcje.
czyli to jest porównanie czasowe jednego uC z zupełnie innym.
a nie instrukcje.
czyli to jest porównanie czasowe jednego uC z zupełnie innym.
No dobra w instrukcjach będzie 34/20 (w pętli głównej). Czyli 1.7
Quote:
No nie wiem jak musi pracować umysł człowieka, aby wyciągnąć wniosek,
że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.
że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.
Założyłem, że kod asm na AVR będzie równie dobrze napisany jak ten twój
na PIC :)
Quote:
Przecież w tamtej dyskusji porównywane były zupełnie inne uC.
Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z
dyskusji i usiłujesz wyciągnąć wniosek,
że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to
chodzi, niż napisałbyś
na tym samym uC w ASM.
Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z
dyskusji i usiłujesz wyciągnąć wniosek,
że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to
chodzi, niż napisałbyś
na tym samym uC w ASM.
To ty się miotasz. Natchniony rozważaniami w innym wątku (na temat tego
czy warto przejść na bardziej rozbudowane uC i na programowanie w C)
wyruszyłeś na jakąś krucjatę i ogłosiłeś, że c jest 6 razy gorszy od
asm. Wrzucasz jeszcze teksty, że razy 16 i że przechodząc na c trzeba
przejść na co najmniej 10 razy szybszy procek żeby skompensować stratę
wydajności generowaną przez kompilator. A przy dokładniejszch analizach
wychodzi, że twój kod asemblerowy na PICu pędzonym 40MHz ma
prawdopodobnie taką samą wydajność jak skompilowany z c kod na ATmegę
32 taktowaną 16MHz. Procek wzbudził twoje uznanie, a jest to procek
który praktycznie znika już z rynku. Wygląda na to, że zahibernowałeś
się w tym PIC i asm i nie widzisz co się wokół dzieje.
Quote:
Toż to bzdura.
Równie dobrze mógłbyś spojrzeć na temperaturę za oknem i jak ci wyjdzie 1,
to oznacza, że
nie warto pisać w ASM, bo to to samo co w C.
Ale zaraz zaraz....
A wiesz, że możesz mieć rację?
Jakbyś Ty napisał niezbyt udany kod w asm i w C, to u Ciebie mogłoby być:
Tc/Tasm = 1,6.
Po co się ograniczać.
Niech będzie i Tc/Tasm = 0,1
I teraz już wiem.
Ty już zrobiłeś sobie takie doświadczenie.
Napisałeś w C. Wyszło Ci, że Twój kod sortuje Ci 5 liczb w 5 sekund,
a potem napisałeś swój kod w ASM i wyszło Ci, że liczy w 50 sekund.
Teraz rozumiem, dlaczego piszesz w C.
Wyciągnąłeś prawidlowy wniosek
Wyzwałeś mnie od kłamców, stwierdziłeś, że ujadam jak pies, teraz
twierdzisz, że jestem beznadziejnym programistą. Poprawia ci to
samopoczucie i twoim zdaniem daje ci przewagę w dyskusji? Ciekawe czemu?
Przecież jesteś przekonany o swoich umiejętnościach, których ja nigdzie
nie kwestionowałem. Więc chyba nie jest budowanie nadwątlonego poczucia
własnej wartości przez poniżanie innych.
Może po prostu nie powinieneś pisać na newsy bo nie panujesz nad emocjami.
--
pozdrawiam
MD
Pszemol
Guest
Guest
Tue Apr 08, 2014 12:19 pm
"Dariusz Dorochowicz" <dadoro@_wp_._com_> wrote in message
news:53439e38$0$2246$65785112@news.neostrada.pl...
Quote:
BTW - jak się poszuka, to ARM-y (ale z trochę z większą ilością nóżek)
są też robione w wersji 5V (a nie 3,3V), np. Kinetis E czy Toshiby.
Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z
3V.
są też robione w wersji 5V (a nie 3,3V), np. Kinetis E czy Toshiby.
Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z
3V.
Sprawdziłem "pierwszy z brzegu",
czyli ten Cortex M4 co ja używam w projekcie:
"6.2 Pin description
I/O pins on the LPC408x/7x are 5V tolerant and have input hysteresis unless
otherwise
indicated in the table below. Crystal pins, power pins, and reference
voltage pins are not
5V tolerant. In addition, when pins are selected to be ADC inputs, they are
no longer 5V
tolerant and the input voltage must be limited to the voltage at the ADC
positive reference
pin (VREFP)."
http://www.nxp.com/documents/data_sheet/LPC408X_7X.pdf
MichaĹ BaszyĹski
Guest
Guest
Tue Apr 08, 2014 5:29 pm
W dniu 2014-04-08 08:59, Dariusz Dorochowicz pisze:
Quote:
Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z 3V.
takich jest dużo, STM32 (nie na wszystkich nogach), te z Texasa chyba też
--
Pozdr.
Michał
Marek
Guest
Guest
Tue Apr 08, 2014 5:44 pm
On Mon, 7 Apr 2014 23:17:20 +0200, Sylwester Łazar<info@alpro.pl>
wrote:
Quote:
Drugi typ z kolei ma 1 000 MHz, 4 rdzenie, jest 100x droższy,
produkowany w
10x większym wolumenie,
a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
abym mógł przeczytać wiadomość w trybie ASCII i przyjemność z
korzystania
jest marna
i ciągle maleje.
produkowany w
10x większym wolumenie,
a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
abym mógł przeczytać wiadomość w trybie ASCII i przyjemność z
korzystania
jest marna
i ciągle maleje.
To wina procesora, ze używasz (pewnie za karę) kiepski so z jeszcze
bardziej kiepskimi aplikacjami?
--
Marek
Marek Borowski
Guest
Guest
Tue Apr 08, 2014 7:15 pm
On 08/04/2014 00:58, Sylwester Łazar wrote:
Quote:
Twoje rozważania na temat efektów kompilacji na PICach zostały
uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
PICów.
Naprawdę ciężko z Tobą się rozmawia:
Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F
Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC
z kodem ASM z drugiego.
Zgrubsza ? Dlaczego nie. Nowoczene procesory, nawet male, sa
uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
PICów.
Naprawdę ciężko z Tobą się rozmawia:
Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F
Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC
z kodem ASM z drugiego.
Zgrubsza ? Dlaczego nie. Nowoczene procesory, nawet male, sa
superscalarne i wykonuja instrukcje w pojedyncze cykle (to nie x51
gdzie byle g* zajmowala 50 cykli).
Upraszczajac przy dostatecznie duzej ilosci kodu mozna przyja, ze
ilosc instrukcji i taktowanie CPU determinuje czas wykonania programu.
ARM musialby miec srednio 10 cykli (a PIC 1) na instrukcje aby Twoje
przesuniecie przecinka mialo sens. A tak nie jest- zobacz sobie
ARM cycles per instruction.
Quote:
Poza tym masz JASNO i WPROST napisane, że chodzi o CYKLE,
a nie instrukcje.
czyli to jest porównanie czasowe jednego uC z zupełnie innym.
No nie wiem jak musi pracować umysł człowieka, aby wyciągnąć wniosek,
że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.
wyzej masz wyjasnienie.
a nie instrukcje.
czyli to jest porównanie czasowe jednego uC z zupełnie innym.
No nie wiem jak musi pracować umysł człowieka, aby wyciągnąć wniosek,
że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.
wyzej masz wyjasnienie.
Quote:
Przecież w tamtej dyskusji porównywane były zupełnie inne uC.
Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z
dyskusji i usiłujesz wyciągnąć wniosek,
że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to
chodzi, niż napisałbyś
na tym samym uC w ASM.
Toż to bzdura.
Roznie bywa. Na zajeciach na PW juz nascie lat temu najszybszy okazal
Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z
dyskusji i usiłujesz wyciągnąć wniosek,
że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to
chodzi, niż napisałbyś
na tym samym uC w ASM.
Toż to bzdura.
Roznie bywa. Na zajeciach na PW juz nascie lat temu najszybszy okazal
sie program napisany w C(!). Powiedzmy ze na sparca sie trudno recznie
optymalizuje co nie nie zmienia sytuacji, iz w grupie 20 osob z ktorych
czesc implementowala algorytm w asm a czesc w C wygral ten napisany w C.
Fakt ze pisany byl "assemblerowo" z bardzo duzym uzycie niskopomziowych
operatorow ale nikt z reszty w asmemblerze nie napisal lepiej.
Naprawde pewne optymalizacje kompilatora wzbudzaly muj szacunek do
niego. Takze na malych uC mozna dlubac recznie i bedzie lepiej, na
duzych procesorach, sorry nie widze tego. Zbyt duzo mechanizow.
Czlowiek tego nie ogarnie. Sam fakt posiadania 32 128bitowych rejestrow
powoduje iz sie mozna pogubic. A cache i przewidywaniu skokow nie
bede nawet wspominal.
Quote:
Równie dobrze mógłbyś spojrzeć na temperaturę za oknem i jak ci wyjdzie 1,
to oznacza, że
nie warto pisać w ASM, bo to to samo co w C.
A warto ? Pytam powaznie bo mimo ze lubie assembler to nijak mi nie
to oznacza, że
nie warto pisać w ASM, bo to to samo co w C.
A warto ? Pytam powaznie bo mimo ze lubie assembler to nijak mi nie
wychodzi ze warto.
Pozdrawiam
Marek
Marek Borowski
Guest
Guest
Tue Apr 08, 2014 7:15 pm
On 08/04/2014 14:01, Mario wrote:
Quote:
W dniu 2014-04-08 00:58, Sylwester Łazar pisze:
To ty się miotasz. Natchniony rozważaniami w innym wątku (na temat tego
czy warto przejść na bardziej rozbudowane uC i na programowanie w C)
wyruszyłeś na jakąś krucjatę i ogłosiłeś, że c jest 6 razy gorszy od
asm. Wrzucasz jeszcze teksty, że razy 16 i że przechodząc na c trzeba
przejść na co najmniej 10 razy szybszy procek żeby skompensować stratę
wydajności generowaną przez kompilator. A przy dokładniejszch analizach
wychodzi, że twój kod asemblerowy na PICu pędzonym 40MHz ma
prawdopodobnie taką samą wydajność jak skompilowany z c kod na ATmegę
32 taktowaną 16MHz. Procek wzbudził twoje uznanie, a jest to procek
który praktycznie znika już z rynku. Wygląda na to, że zahibernowałeś
się w tym PIC i asm i nie widzisz co się wokół dzieje.
A czego oczekujesz od kogos kto ma wszytko napisane w asm na PICa ?
To ty się miotasz. Natchniony rozważaniami w innym wątku (na temat tego
czy warto przejść na bardziej rozbudowane uC i na programowanie w C)
wyruszyłeś na jakąś krucjatę i ogłosiłeś, że c jest 6 razy gorszy od
asm. Wrzucasz jeszcze teksty, że razy 16 i że przechodząc na c trzeba
przejść na co najmniej 10 razy szybszy procek żeby skompensować stratę
wydajności generowaną przez kompilator. A przy dokładniejszch analizach
wychodzi, że twój kod asemblerowy na PICu pędzonym 40MHz ma
prawdopodobnie taką samą wydajność jak skompilowany z c kod na ATmegę
32 taktowaną 16MHz. Procek wzbudził twoje uznanie, a jest to procek
który praktycznie znika już z rynku. Wygląda na to, że zahibernowałeś
się w tym PIC i asm i nie widzisz co się wokół dzieje.
A czego oczekujesz od kogos kto ma wszytko napisane w asm na PICa ?
To wlasnie najwieksza "zaleta" asmeblera ktora go IMHO calkowicie
dyskwalifikuje w komercyjnym uzyciu - nie zmienisz rodziny
mikrokontrolero chyba ze napiszesz sobie wszystko od nowa.
Pozdrawiam
Marek
jacek pozniak
Guest
Guest
Tue Apr 08, 2014 8:41 pm
ja pie..ole, to nie miało być takie długie :-)
jp
jacek pozniak wrote:
Quote:
Dobry wieczór wszystkim
Na wstępie swego wywodu zaznaczam, że nie chcę wywoływać ideologicznych
sporów, zależy mi tylko na merytorycznej dyskusji.:-)
Sprawa ma sie następująco; od wielu lat programowałem uC ze stajni
Microchipa, wcześniej 8080,Z80,51.
PIC jest ok, ma fajne peryferia, etc.
Od jakiegoś czasu zacząłem jednak kleić większe programy, często
wykorzystujące jakieś fragmenty ściągnięte z internetu + własne archiwalne
z innych czasów i platform (np. 51).
Zawsze starałem się stosować do ANSII C.
Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
nowsze wersje, obecnie to chyba jest Microchip) powoduje różne
nieoczekiwane efekty, np. starsza wersja kompiluje OK; nowsza źle, lub
odwrotnie. Działanie programu zależy od wersji kompilatora, starszą wersją
działa, nowszą nie, lub odwrotnie.
Prawdę mówiąc, jest to trochę irytujące.
O ile program się pisze 'od zera' to mozna kombinować aby go uruchomić,
ale jeśli wykorzystuje się kod źródłowy pisany kiedyś lub pisany przez
kogoś innego, to raczej słabo.
Czy Koledzy programujący uC również coś takiego zauważyli?
Prawdę mówiąc skłania mnie ta sytuacja do przesiadki na AVR, który jak sie
wydaje jest bardziej przyjazny dla kompilatora (jest na niego gcc)
Proszę o jakieś opinie.
Pozdrawiam
jp
Na wstępie swego wywodu zaznaczam, że nie chcę wywoływać ideologicznych
sporów, zależy mi tylko na merytorycznej dyskusji.:-)
Sprawa ma sie następująco; od wielu lat programowałem uC ze stajni
Microchipa, wcześniej 8080,Z80,51.
PIC jest ok, ma fajne peryferia, etc.
Od jakiegoś czasu zacząłem jednak kleić większe programy, często
wykorzystujące jakieś fragmenty ściągnięte z internetu + własne archiwalne
z innych czasów i platform (np. 51).
Zawsze starałem się stosować do ANSII C.
Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
nowsze wersje, obecnie to chyba jest Microchip) powoduje różne
nieoczekiwane efekty, np. starsza wersja kompiluje OK; nowsza źle, lub
odwrotnie. Działanie programu zależy od wersji kompilatora, starszą wersją
działa, nowszą nie, lub odwrotnie.
Prawdę mówiąc, jest to trochę irytujące.
O ile program się pisze 'od zera' to mozna kombinować aby go uruchomić,
ale jeśli wykorzystuje się kod źródłowy pisany kiedyś lub pisany przez
kogoś innego, to raczej słabo.
Czy Koledzy programujący uC również coś takiego zauważyli?
Prawdę mówiąc skłania mnie ta sytuacja do przesiadki na AVR, który jak sie
wydaje jest bardziej przyjazny dla kompilatora (jest na niego gcc)
Proszę o jakieś opinie.
Pozdrawiam
jp
elektroda NewsGroups Forum Index - Elektronika Polska - PIC czy AVR? Doświadczenia z kompilatorami HiTech i GCC w programowaniu uC