Freddie Chopin wrote: tmf wrote: Praktycznie każdy Cortex M0, M0+ nie ma 10-krotnie wyższej wydajności niż taki 20 MHz tinek, pomijając nieżyciowe przypadki, w których ktoś robi pętlę od 1 do 10 przy pomocy 64 bitowej zmiennej. O takich jak sądzę z kol. BlueDraco pisaliśmy, bo niesądzę aby jakieś mega wypaśne ARMy były w SSOP20.
Wchodzimy więc na
http://www.eembc.org/coremark/index.php i widzimy tam, że "Atmel ATmega644" osiąga zawrotną wydajność 0.54 "CoreMark/MHz", co przy 20MHz daje szokującą ocenę całkowitą 10.81. Kilka stron dalej znajdujemy "STMicroelectronics STM32F051C8" taktowany na 24MHz, który przy tym zegarze osiąga 2.33 "CoreMark/MHz", a w sumie ocenę 56.05. Zgadza się, 10x nie ma. "tylko" ponad 5x. Teraz gdy weźmiemy pod uwagę fakt, że owe STM32F0 potrafi działać jednak na 48MHz, to nawet przy lekkim zmniejszeniu wydajności na MHz (cache) - wynoszącej wtedy 2.2 - będzie 10x większa wydajność ogólna, wynosząca 105.61. No chyba że się przyczepisz, że to nie 10x a 9,769657724x... (;
Ciekawostka - jest też nowoczesna Atxmega, z wynikami niższymi niż zwykła atmega.
Ciekawostka nr 2 - STM32F4 przy pełnym zegarze to rejony 500-600 (~3.3 CoreMark / MHz). STM32F7 - ~1000 (koło 5 na MHz). STM32H7 - koło 2000.
No to chociażby ta ciekawostka podana przez ciebie podważa wiadygodność benchmarka. Ale są też inne. Zobaczmy co ten test mierzy:
Quote: The code is written in C and contains implementations of the following algorithms: list processing (find and sort), matrix manipulation (common matrix operations), state machine (determine if an input stream contains valid numbers), and CRC.
Jak widać dosyć wąski wycinek zastosowań. I teraz kolejna ciekawostka. Jednym z pomiarów jest obliczanie CRC. Problem w tym, że wymienione MCU liczą CRC sprzętowo. Oczywiście do benchmarka zapewne nie jest ta opcja wykorzystywana. Lecz... w realnej aplikacji by była (a skoro CRC umieszono w benchmarku to najwyraźniej twórcy uznali, że jest to miarodajne, z czym można dyskutować), a korzystając ze sprzętu mielibyśmy ponad 100-krotne (dla XMEGA) przyśpieszenie tej operacji, podobnie na ARM. Inna sprawa, że obliczenia na macierzach, czy sortowanie danych to nie są aplikacje na małe układy embedded, stąd pewnie nieporównywalnie dobre wyniki "dużych" procków.
O benchmarkach można sobie dużo gadać. To weźmy to na logikę - i na AVR i na ARM większość operacji trwa jeden takt. Różnica taka, że ARM wykonuje operacje na 32-bitach, AVR głównie na 8. Dopóki więc nie zajdzie potrzeba przeprowadzania operacji na typie większym niż 8-bitów to oba rdzenie idą 1:1 (poza drobnymi wyjątkami). Ale już dodawanie 32-bitowe, to dla ARM 1 takt, dla AVR - 4 takty. Ok, dodajmy pobranie i zapisanie rejestrów, żeby AVR pognębić to mamy ARM 3-4 takty, AVR - 20 taktów. Ale już dla obliczeń na 8-bitach przewagę uzyskuje AVR, bo operacje 8-bitowe są na ARM kosztowne. Pytanie po co je stosować, skoro możemy bezkarnie wydłużyć typ. Pierwszy lepszy przykład - alfablending. Mamy upakowany kolor RGB na 32-bitach, trzeba teraz przemnożyć składowe przez alfa. Na ARM - dekompresja RGB na 3*32bity, mnożenie i składanie tego spowrotem. Pomijam ARMy, które mają sprzetowe wspomaganie dla tego typu operacji, bo to rzadkość. Na AVR - po prostu 3 mnożenia ((też sprzętowe). Nie piszę tego, żeby wykazać, że coś jest lepsze, czy gorsze. Niestety mało kto sobie uświadamia, że wszystko zależy od zastosowania i tego do czego procka planuje się użyć. Żaden benchmark nie odda złożoności problemu.
Tak sobie możemy dyskutować. To, żeby mówić o konkretach - podaj kilka typowych aplikacji, elektrodowiczów, lub hobbystów i zobaczmy jak to porównanie wypadnie.