-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.task
.gda.pl!not-for-mail
From: Marek Borowski <m...@b...com>
Newsgroups: pl.misc.elektronika
Subject: Re: PIC vs AVR
Date: Tue, 08 Apr 2014 21:15:45 +0200
Organization: CI TASK http://www.task.gda.pl/
Lines: 66
Message-ID: <li1hte$13t$1@news.task.gda.pl>
References: <533ddbbb$0$2158$65785112@news.neostrada.pl> <lhpavu$914$1@dont-email.me>
<lhpeqj$ct4$1@speranza.aioe.org> <lhpgfo$kjn$1@dont-email.me>
<lhpluc$v7a$1@speranza.aioe.org> <lhpr39$4rf$1@dont-email.me>
<lhq0sf$7gn$1@speranza.aioe.org> <lhrd9u$agv$1@dont-email.me>
<lhrhae$j9a$1@speranza.aioe.org> <lhrk97$6kg$1@mx1.internetia.pl>
<lhs0th$qtp$1@speranza.aioe.org> <lhs583$vhh$1@mx1.internetia.pl>
<lhs5nm$1fo$1@mx1.internetia.pl> <lhubnd$amu$1@mx1.internetia.pl>
<lhueie$klk$1@mx1.internetia.pl> <lhut4e$4dn$1@mx1.internetia.pl>
<lhuvs6$f3a$1@mx1.internetia.pl> <lhv567$142$1@mx1.internetia.pl>
<lhv6h3$5kv$1@mx1.internetia.pl> <lhv8es$c0h$1@mx1.internetia.pl>
<lhvbcv$lmq$1@mx1.internetia.pl>
NNTP-Posting-Host: 89-66-7-52.dynamic.chello.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.task.gda.pl 1396984558 1149 89.66.7.52 (8 Apr 2014 19:15:58 GMT)
X-Complaints-To: a...@n...task.gda.pl
NNTP-Posting-Date: Tue, 8 Apr 2014 19:15:58 +0000 (UTC)
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.4.0
In-Reply-To: <lhvbcv$lmq$1@mx1.internetia.pl>
Xref: news-archive.icm.edu.pl pl.misc.elektronika:662693
[ ukryj nagłówki ]On 08/04/2014 00:58, Sylwester Łazar wrote:
>> 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
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.
> 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.
> 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
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.
> 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
wychodzi ze warto.
Pozdrawiam
Marek
Następne wpisy z tego wątku
- 08.04.14 21:15 Marek Borowski
- 08.04.14 22:41 jacek pozniak
- 08.04.14 23:38 Sylwester Łazar
- 08.04.14 23:50 Sylwester Łazar
- 09.04.14 00:13 Pszemol
- 09.04.14 00:23 Sylwester Łazar
- 09.04.14 01:21 Pszemol
- 09.04.14 01:35 Sylwester Łazar
- 09.04.14 02:49 Pszemol
- 09.04.14 03:11 Sylwester Łazar
- 09.04.14 03:21 Pszemol
- 09.04.14 03:39 Sylwester Łazar
- 09.04.14 05:03 Pszemol
- 09.04.14 08:11 Marek
- 09.04.14 08:22 Michał Lankosz
Najnowsze wątki z tej grupy
- pradnica krokowa
- Nieustający podziw...
- Coś dusi.
- akumulator napięcie 12.0v
- Podłączenie DMA 8257 do 8085
- pozew za naprawę sprzętu na youtube
- gasik
- Zbieranie danych przez www
- reverse engineering i dodawanie elementów do istniejących zamkniętych produktów- legalne?
- Problem z odczytem karty CF
- 74F vs 74HCT
- Newag ciąg dalszy
- Digikey, SN74CBT3253CD, FST3253, ktoś ma?
- Szukam: czujnik ruchu z możliwością zaączenia na stałe
- kabelek - kynar ?
Najnowsze wątki
- 2025-01-18 Zieloni oszuchiści
- 2025-01-18 Zielonka => Specjalista ds. public relations <=
- 2025-01-18 Warszawa => Frontend Developer (JS, React) <=
- 2025-01-18 Warszawa => Software .Net Developer <=
- 2025-01-18 Warszawa => Developer .NET (mid) <=
- 2025-01-18 Katowice => Administrator IT - Systemy Operacyjne i Wirtualizacja <=
- 2025-01-17 Zniknął list gończy za "Frogiem". Frog się nam odnalazł?
- 2025-01-17 Kto wytłumaczy "głupiemu" prezydentowi Dudzie wielką moc prawną "dekretu premiera" TUSKA? [(C)Korneluk (2025)]
- 2025-01-17 Warszawa => Inżynier oprogramowania .Net <=
- 2025-01-17 Natalia z Andrychowa
- 2025-01-17 Gliwice => Business Development Manager - Dział Sieci i Bezpieczeńst
- 2025-01-17 Warszawa => System Architect (Java background) <=
- 2025-01-17 Warszawa => Full Stack .Net Engineer <=
- 2025-01-17 Gliwice => IT Expert (Network Systems area) <=
- 2025-01-17 Lublin => Programista Delphi <=