W dniu 07.04.2014 o 15:23 Piotrek <p...@p...na.berdyczow.info> pisze:

> On 2014-04-07 14:52, janusz_k wrote:
>> Taa w sam raz zabawka dla poczatkującego, pdf procka liczy drobne
>> 1880str, faaaaktycznie lepsze od avr-a.
>
> Ale ja się nie odnosiłem do tego czy lepsze czy gorsze bo to jakby
Bo to akurat nie było do ciebie tylko do pszemola :)
a tutaj napisałem bo dałeś przykład fajnej płytki z fajnmym
wszystkomającym prockiem z pdfem na >1800str.

> dyskusja tego samego typu co "czy samochód jest lepszy/gorszy od roweru".
>
> A odpowiedź jest przecież oczywista: zależy do jakiego zastosowania.
>
> Pokazałem jedynie produkt kosztujący 6 dyszek, przy użyciu którego
> możesz przetestować funkcjonalność rodziny poczynając od migania ledami
> przez UARTy, CANy, SPI, I2C, USB, ADC, etc. a na postawieniu serwera www
> czy też innych RTOSach używających powyższego kończąc.
>
> Firmowy toolchain (bez ograniczeń wielkości kodu dla *tej* platformy)
> masz za darmo. Do tego (rzeczywiście) sporo dokumentacji + *liczne*
> przykłady + spora społeczność użytkowników.
>
> Dzięki CMSIS masz przenaszalność (na poziomie kodu źródłowego) pomiędzy
> produktami różnych producentów oraz platformami (M0-M4, M4F).
>
> Między innymi dla tego konkretnego procesora masz "fimware" w ROM dzięki
> któremu początkujący spokojnie może sobie odpuścić czytanie dokumentacji
> procesora i peryferiami operuje na poziomie "magicznych zaklęć" typu:
Dziękuję za te "zaklęcia" wolę sam ustawiać peryferia, a to dlatego że
takimi "zaklęciami" posługuje się np bascom czy avrduino, akurat kiedyś
dawno temu pisałem w bascomie i takie konie dawał że głowa mała,
"zaklęcia" maiały bugi, wychodziło że lepiej to samemu w asm-ie ustawić
tylko że bascom był dość odporny na wstawki, skończyło się tak że się
przeprosiłem z c i na nie przeszedłem, chociaż mi nie leżał ze wzgledu na
małą czytelność kodu w stosunku do np pascala.


--

Pozdr
Janusz

do góry

W dniu 2014-04-07 14:12, AlexY pisze:
> Użytkownik Michał Lankosz napisał:
>> W dniu 2014-04-06 23:22, Sylwester Łazar pisze:
>>>> Ale o czym Ty piszesz? Start systemu operacyjnego pokroju Windows jest
>>>> dość złożonym procesem, chociaż jego normalna praca również.
>>>>
>>>> --
>>>> Michał
>>> 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ł

do góry

W dniu 2014-04-07 21:41, Sylwester Łazar pisze:
>>>> Nic ci nie zamierzam udowadniać. Przeglądałem pobieżnie twoje analizy i
>>>> Janusza. Sam stwierdziłeś, że w cyklach jest stosunek C/asm = 1.6
>>> W pierwszym poście masz napisane, że nie dokonywałem analizy czasowej.
>>> I to podkreślone.
>>> Można porównywać:
>>> a) liczbę instrukcji
>>> b) czas wykonywania.
>>
>> Czas wykonywania to nie jest analiza czasowa?
>
> Jest. Tylko ja jej NIE ROBIŁEM.
> A<>B.
> Oznacza to, że jak robiłem A, to nie robiłeł B.
> Czy to tak trudno zrozumieć?
> LICZBA INSTRUKCJI w asemblerze po wykonaniu kompilacji do LICZBY INSTRUKCJI
> ,
> napisanej w czysym asemblerze przez biegłego programistę dla TEGO SAMEGO
> MIKROKONTROLERA,
> którym jest PIC18F2320.
> Nazwane przeze mnie: C/ASM=ileś tam, nie oznacza, że czas wykonywania kodu
> napisanego w C, do czasu kodu napisanego w ASM,
> czyli:
> Tc/Tasm może być 2,6,10, 100.
> Ale 1,6 jest moim zdaniem mało prawdopodobne.

Skoro jak sam podałeś instrukcje są wykonywane w jednym takcie to czas
wykonywania będzie zależał od taktowania. Skoro piszesz że kod po
skompilowaniu może być 16 razy wolniejszy i trzeba dać 10 razy szybszy
procek to chyba masz na myśli że po kompilacje ma się 16 razy więcej
instrukcji do wykonania a nie, że jest tych instrukcji jest 1,6 razy
więcej ale przy okazji obniżasz dziesięciokrotnie taktowanie.
>
> I ja takich porównań nie robiłem, poza jednym wyjątkiem co do ATMEGA32,
> gdzie analizę Tc/Tasm przeprowadziłem na podstawie zajrzenia do dokumentacji
> obu mikrokontrolerów i sprawdzenia:
> a) maksymalnego CLK
> b) liczby cykli/rozkaz.
>
> Jeszcze raz:
> Tc/Tasm <> C/ASM
>
> Mogę to jeszcze jaśniej wytłumaczyć, ale jesli tego nie zrozumiesz no to już
> nie wiem czy sens istnieje.


Przecież podałeś proporcje liczby instrukcji i czasy wykonywania instrukcji.
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.

--
pozdrawiam
MD

do góry

> >>> 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..
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.
S.

do góry

> 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ć.


S.

do góry

W dniu 2014-04-07 23:35, Sylwester Łazar pisze:
>> 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ć.

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

do góry

W dniu 2014-04-07 23:17, Sylwester Łazar pisze:
>>>>> 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 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.

> 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

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ł

do góry

"Sylwester Łazar" <i...@a...pl> wrote in message
news:lhv5fa$1vr$1@mx1.internetia.pl...
> 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..

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..

> 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.

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.

do góry

> 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.

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.

do góry

> 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"

Dobranoc:-)
S.

do góry