CH32V003 vs AVR: Testy wydajności GPIO i operacji matematycznych

Może komuś się przyda:
kupiłem płytkę CH32V003 dla RISC-V Nano i programator WchlinkeE 1v3,
całość działa pod MounRiver studio.

Przy zegarze 48 MHz:
szacunkowo szybkość majtania GPIO (przykład GPIO):
while (1) { GPIO_WriteBit(GPIOD, GPIO_Pin_6, (i == 0) ? (i = Bit_SET) : (i = Bit_RESET)); }
to około 0.93 MHz

Dodanie 2 floatów (32 bity) zajmuje od 115 do 167 cykli, mnożenie 516-831 cykli
(sprawdzałem SysTick->CNT;)

Czyli mamy 57 kflops dla mnożenia i 280 kflops dla dodawania. O ile pamiętam
arduino miało w podobnym teście 22 kflops.

Dodanie 2 liczb u8 też trwało koło kilkunastu cykli
Pętla typu
for (ii=0; ii<255; ii++)
for (jj=0; jj<255; jj++)
{
kz=kx+ky;
}
dla zmiennych typu u8 wykonuje sie 494 ns na obrot, czyli jakieś 24 cykle na obrót.

Samo mounriver studio akceptuje double, działają 3.5x wolniej niż floaty.
Miałem problemy z wyświetlaniem wyników działań na floatach printfem.
Jak widać te risci nie są tak szybkie jak mogłoby sie wydawać, chociaż same
scalaki są oczywiście tańsze od avr.

yorgus_1978 napisał:

Dodanie 2 liczb u8 też trwało koło kilkunastu cykli

yorgus_1978 napisał:

Jak widać te risci nie są tak szybkie jak mogłoby sie wydawać, chociaż same
scalaki są oczywiście tańsze od avr.

Konkluzja odważna aczkolwik pewnie całkowicie nieprawdziwa. Ten test ma raczej zerową wartość. Dlaczego ?
1. Nieznane są opcje kompilacji, a sądząc po teście integerów (który raczej zostałby wyoptymalizowany) nie masz żadnych optymalizacji włączonych i generalnie mierzysz szum -O0
2. Ustawiasz GPIO "magiczną" funkcją, o której nic nie wiadomo. Może ona sama w sobie zajmować wiele taktów, dodatkowo masz "ternary operator" z przypisaniem jako parametr i on też znacząco obniży wydajność jako że w tym przypadku pewnie będzie zawierać skok, który dodatkowo bardzo spowolni ze względu na flushowanie pipeline.

Testów wydajności tak się nie robi.

Test szybkości togglowania GPIO musi być zrobiony na jak najniższym poziomie (rejestry, brak OR-ów lub AND-ów, brak skoków itp)
Test operacji arytmetycznych - przy włączonych optymalizacjach, powinieneś pokazać pełny kod testowy + wygenerowany kod wynikowy + wszystkie opcje kompilacji


Już wiem skąd "ściągnąłes" ten kod GPIO . Żywcem z przykłądów napisanych przez Chińczyków

oscil1 napisał:

est szybkości togglowania GPIO musi być zrobiony na jak najniższym poziomie (rejestry, brak OR-ów lub AND-ów, brak skoków itp)

Tu tak naprawdę nie ma co testować, wystarczy przeczytać notę układu. Niesądzę aby te procesor wyciągał poniżej 1 Moperacji tego typu, bo nawet AVR osiąga FCLK/2 operacji.

oscil1 napisał:

Test operacji arytmetycznych - przy włączonych optymalizacjach, powinieneś pokazać pełny kod testowy + wygenerowany kod wynikowy

Ponadto musiałby to być ten sam kompilator z tymi samymi bibliotekami matematycznymi - szczególnie ten drugi warunek jest prawie niemożliwy do spełnienia. Jest wiele zoptymalizowanych wersji np. libm, które potrafią być wielokrotnie szybsze, szczególnie jeśli wprowadzi się pewne założenia.
Także podsumowując, jak zaznaczył kol. @oscil1, takie porównanie jest niewiele warte.

tmf napisał:

Niesądzę aby te procesor wyciągał poniżej 1 Moperacji tego typu

Na podstawie RM-a i DS-a sądzę że wyciągnie o wiele więcej. Myślę ze do ~8M . Elektrycznie da radę. Niestety ISA nie podaje zalecanych timingów instrukcji i producenci różnie to implementują (SiFive poniżej jednego taktu na instrukcje jak trafione są przewidywania). Tu oczywiście będzie wolniej. FLASH nie podejrzewam aby wprowadzała duże opóźnienia. Ma szybką magistralę.

tmf napisał:

Jest wiele zoptymalizowanych wersji np. libm

Nawet już nie komentowałem floatów (trochę źle wybrałem cytat), tylko bardzo naiwne testowanie dodawania u8 :

yorgus_1978 napisał:

Dodanie 2 liczb u8 też trwało koło kilkunastu cykli

co jest oczywistym nonsensem

Co do kompilatora to podejrzewam, ze to "zwykły" gcc albo clang.

CH32V003 nie ma sprzętowego mnożenia.

Jak widać te rysy nie są tak szybkie jak mogłoby się wydawać, chociaż same
scalaki są oczywiście tańsze od avr

>Konkluzja odważna aczkolwiek pewnie całkowicie nieprawdziwa. Ten test ma raczej zerową wartość.

Test został zrobiony na przykładach dołączonych do tego softu. Jak komuś się nie chce
doktoryzować z tematu, a potrzebuje na szybko taniego uC to ten test ma wartość poglądową.
Oczywiście jak masz czas (zajmujesz się tym zawodowo) to sobie sam sprawdzisz i dla Ciebie
taki test nie będzie miał wartości.

>Dlaczego ?
>1. Nieznane są opcje kompilacji, a sądząc po teście integerów (który raczej zostałby zoptymalizowany) nie masz żadnych optymalizacji włączonych i generalnie mierzysz szum -O0

-O0 to nie jest szum. Tu było zdaje się domyślne -Os, czyli rozmiar.
Tak czy inaczej różnica do -O2 jest zwykle 2-3x, chociaż zależy od architektury.
I co z tego. Widać, że nie jest taki szybki jak można by się spodziewać.

>2. Ustawiasz GPIO "magiczną" funkcją, o której nic nie wiadomo. Może ona sama w sobie zajmować wiele taktów, dodatkowo masz "ternary operator" z przypisaniem jako parametr i on też znacząco obniży wydajność, jako że w tym przypadku pewnie będzie zawierać skok, który dodatkowo bardzo spowolni ze względu na flushowanie pipeline.

To jest domyślny example z GPIO z tego pakietu.

>Testów wydajności tak się nie robi.

>Test szybkości togglingu GPIO musi być zrobiony na jak najniższym poziomie (rejestry, brak OR-ów lub AND-ów, brak skoków itp)
>Test operacji arytmetycznych - przy włączonych optymalizacjach, powinieneś pokazać pełny kod testowy + wygenerowany kod wynikowy + wszystkie opcje kompilacji

Wszystko domyślne, z przykładów w pakiecie

>Już wiem skąd "ściągnąłeś" ten kod GPIO . Żywcem z przykładów napisanych przez Chińczyków

Dokładnie tak. Wrzuciłem po prostu to, co idzie uzyskać, używając tego co dostarczyli i bawiąc się chwilę.
Nie mam czasu na studiowanie architektury, może w wakacje się douczę. Na razie byłem ciekawy
jak to się ma do avra w prostych zastosowaniach. Znam też trochę 51, Atxmega i ARMy, ale nie zajmuję się tym zawodowo.

yorgus_1978 napisał:

Dokładnie tak. Wrzuciłem po prostu to, co idzie uzyskać, używając tego co dostarczyli i bawiąc się chwilę.Nie mam czasu na studiowanie architektury

1. Piszesz na publicznym forum - więc nie bądź zaskoczony krytyką.
2. Publikując coś (post to jak artykuł w gazecie) wypadało by zapoznać się z tematem.

Nawet nie będę się odnosił do powyższego postu, bo wszystkie argumenty są po prostu próbą obrony czegoś, czego nie da się obronić.

oscil1 napisał:

yorgus_1978 napisał:

Dokładnie tak. Wrzuciłem po prostu to, co idzie uzyskać, używając tego co dostarczyli i bawiąc się chwilę. Nie mam czasu na studiowanie architektury

1. Piszesz na publicznym forum - więc nie bądź zaskoczony krytyką.
2. Publikując coś (post to jak artykuł w gazecie) wypadałoby zapoznać się z tematem.

Nawet nie będę się odnosił do powyższego postu, bo wszystkie argumenty są po prostu próbą obrony czegoś, czego nie da się obronić.[/quote1. Masz to mcu i sprawdziłeś? Umieściłeś jakieś rezultaty swoich testów tutaj? Nie widzę. Zastanów się co jest konstruktywnego w twoim poście.
Sprawdziłem czas wykonania przez tickcount i oscyloskopem i faktycznie jest tak wolno - elektroda jest indeksowana przez google
więc może się komuś ta informacja przyda, że te mcu nie są specjalnie szybkie. Może zresztą ktoś to faktycznie sprawdzi i faktycznie
jest jakiś błąd w examplach, chętnie się dowiem.

Dodano po 4 [minuty]:

>>21054989
Ciekawe, że bez sprzętowego mnożenia, mnożenie jest tylko 4x wolniejsze niż dodawanie.
Wydawałoby mi się, że trzeba przesuwać bity i dodawać, co zajęłoby więcej.
Ciekawe jest też to 5V zasilania, co świadczy o b. starym procesie technologicznym,
i tym że musieli sporo powywalać z implementacji 32-bitowego procesora aby się zmieściło.
Nie zdziwiłbym się, jakby alu było mniej bitowe niż 32, np. tak jak w z80 alu było 4-bitowe
mimo że cpu był 8-bitowy.

yorgus_1978 napisał:

Ciekawe jest też to 5V zasilania, co świadczy o b. starym procesie technologicznym,
i tym że musieli sporo powywalać z implementacji 32 bitowego procesora aby sie zmieściło.

CH32V003 ma wewnętrzny stabilizator. Robią 5V bo klienci są tym zainteresowani. Jeżeli już, to zasilanie od 2.8V wypada słabo. Na szczęście mają też scalaki z szerszym zakresem.

yorgus_1978 napisał:

Ciekawe, że bez sprzętowego mnozenia, mnozenie jest tylko 4x wolniejsze niż dodawanie.

Nie wyciągaj wniosków na podstawie wyników pochodzących ze skompilowania wysokopoziomowego kodu... Efektywność operacji matematycznych będzie zależeć od użytej przez kompilator biblioteki. Np. na AVR są dostępne biblioteki zapewniające operacje wielokrotnie szybsze, niż biblioteki standardowe. Dla np. kompilatora Microchipa różnice mogą sięgać 100-razy. Dodatkowo, jeśli możesz sobie pozwolić na odejście od standardu IEEE, to są dostępne specjalnie optymalizowane implementacje funkcji matematycznych znacznie szybsze niż standardowe.
Dlatego twój test pokazuje co najwyżej, że użyty toolchain/biblioteki da się zapewne mocno poprawić. Co raczej powinno skłaniać do ich porzucenia, przynajmniej przy niektórych operacjach
Dla przykładu, parę lat temu operacje mnożenia i dzielenia float w gcc na AVR to było ok. 470-490 taktów, tobie wyszło ponad 500-800, oczywiście porównanie nie do końca poprawne, ale to pokazuje jak bardzo skopana jest implementacja w użytym toolchainie. Żeby to jeszcze lepiej uwidocznić - obecnie dzielenie float na AVR to może być ok. 90 taktów...
Wyciąganie na tej podstawie wniosków, że RISCV jest tylko trochę szybszy niż AVR jest naciągane...

tmf napisał:

tobie wyszło ponad 500-800, oczywiście porównanie nie do końca poprawne, ale to pokazuje jak bardzo skopana jest implementacja w użytym toolchainie

Albo banalny powód, nieskonfigurowane taktowanie i na domyślnym procek się wlecze.

Ja sprawdziłem tak na szybko i 6MHz mam na GPIO.

Macosmail napisał:

Ja sprawdziłem tak na szybko i 6MHz mam na GPIO.

Bo autor użył funkcji GPIO_WriteBit, która pewnie ma ogromny narzut, a ty operujesz bezpośrednio na IO z minimalnym narzutem. Jakie jest taktowanie MCU? Bo te 6 MHz to też niezbyt imponująco...

Dla porównania Puya PY32F002 za 8 centów:

tmf napisał:

Jakie jest taktowanie MCU? Bo te 6 MHz to też niezbyt imponująco...

48MHz. 8 cykli na cały obrót pętli. Raczej standard. W STM32 M0 wygląda to w zasadzie identycznie. W M3 tylko trochę lepiej. Gdzieś kiedyś czytałem, że M0+ ma ulepszoną prędkość GPIO.
https://community.st.com/t5/stm32-mcus-produc...gpio-in-stm32f0103-or-stm32f746zg/td-p/286339

piotr_go napisał:

Dla porównania Puya PY32F002 za 8 centów:

Do ilu podkręcona ta Puya? Strzelam, że 4x to co deklaruje producent
Przy takim kodzie "Inline" w CH32V003 uzyskałem 12MHz, ale oczywiście w czasie powrotu pętli występuje taka niespodzianka.

Macosmail napisał:

Gdzieś kiedyś czytałem, że M0+ ma ulepszoną prędkość GPIO.

M0+ jak widać w PY32F002 ma 1 cykl na zapis do IO.

Macosmail napisał:

Do ilu podkręcona ta Puya? Strzelam, że 4x to co deklaruje producent

Coś koło tego. x2 za pomocą PLL (którego oficjalnie nie ma), ~x2 za pomocą kalibracji generatora.
>90MHz

Macosmail napisał:

Przy takim kodzie "Inline" w CH32V003 uzyskałem 12MHz

Testowałeś może jakiś timer czy rzeczywiście chodzi na 48MHz?
Można by jeszcze spróbować wrzucić pętlę do ramu.

Niestety nie mam pod ręką CH32V003 żeby przetestować.
Zamówiłem scalaki przy okazji zakupu programatora, ale zjawią się pewnie za parę tygodni.

piotr_go napisał:

tmf napisał:

tobie wyszło ponad 500-800, oczywiście porównanie nie do końca poprawne, ale to pokazuje jak bardzo skopana jest implementacja w użytym toolchainie

Albo banalny powód, nieskonfigurowane taktowanie i na domyślnym procek się wlecze.

Wypisuje 48 MHz w examplu. Ale nie sprawdzałem w jakiś inny sposób. Natomiast nie jest niczym niezwykłym
że jakaś intrukcja może trwac wiele cykli, chociaż to tutaj to troche przesada. Pamiętam, że z 20 lat temu sie bawiłem
jakimś armem philipsa i tam też gpio było koszmarnie powolne, z 2-3 MHz. Pewnie da sie wiecej, mozna czasem też używać dma,
ale nie o to mi chodzi. Poza tym jeżeli to jest znana od dawna architektura (MIPS) to dlaczego to jest tak źle z optymalizowane.
avr-gcc to inna bajka, 8 bitów to nigdy nie był docelowy target dla takiego kompilatora jak gcc, więc to gcc pewnie sie
sporo różnic od mainstreamu na x86 i army.

Nie. To ustawienie dotyczy tylko stromości zboczy, która jest podawana w ekwiwalencie częstotliwości co bywa mylące i w nowszych prockach to zmienili. Zastosowanie ma to w redukcji emisji EMC.

@Macosmail
Przetestuj tego BINa jak możesz.
Wyjście C0.

Jest to samo co miałem w poście #16 czyli 12MHz. Liczniki przetestuje może w weekend jak znajdę trochę czasu.

oscil1 napisał:

Na podstawie RM-a i DS-a sądzę że wyciągnie o wiele więcej. Myślę ze do ~8M .

Nie doceniłem chińczyków. Naprawde 2takty/instrukcja. Magistrala daje radę

yorgus_1978 napisał:

Natomiast nie jest niczym niezwykłym
że jakaś intrukcja może trwac wiele cykli, chociaż to tutaj to troche przesada.

Nie - to problem baletnicy a nie spódnicy.

yorgus_1978 napisał:

avr-gcc to inna bajka, 8 bitów to nigdy nie był docelowy target dla takiego kompilatora jak gcc, więc to gcc pewnie sie
sporo różnic od mainstreamu na x86 i army.

To kolejny - (podobnie jak inne) niestety całkowicie nieprawdziwy wniosek.

>>21053970
Dziękuję za udostępnienie tych interesujących wyników testów, rzeczywiście pozwalają one na lepsze zrozumienie możliwości tej płytki RISC-V.

Jeśli chodzi o nieco gorsze niż oczekiwano osiągi obliczeń zmiennoprzecinkowych, sugeruję, abyś dalej zbadał szczegóły architektury tego układu, na przykład czy obsługuje on sprzętową jednostkę zmiennoprzecinkową. Może też wymagać optymalizacji kompilatora i konfiguracji środowiska programistycznego.

Co do problemu ze słabym wsparciem dla liczb zmiennoprzecinkowych w środowisku MounRiver Studio, warto przekazać tę informację zwrotną deweloperom narzędzia, mam nadzieję, że uda im się to poprawić w przyszłości.

Ogólnie rzecz biorąc, wciąż jest to atrakcyjna płytka programistyczna RISC-V pod względem relacji ceny do wydajności, która powinna sprawdzić się w wielu prostszych zastosowaniach. Dziękuję jeszcze raz za podzielenie się Twoimi spostrzeżeniami i wynikami testów.

Ze zgłaszaniem proponuję poczekać do potwierdzenia wyników.
Słabe wyniki szybkości GPIO się nie potwierdziły. CH32V003 jest wolniejszy od M0+, ale tylko minimalnie (1 cykl vs 2 cykle).

Osobiście jedyne co mi przeszkadza w CH32V003 to brak sprzętowego mnożenia. Przeszkadza mi tylko dlatego, ponieważ M0+ od Puya który jest w podobnej cenie takie mnożenie posiada.
Do AVRów cen nawet nie ma co porównywać, bo jest to przepaść na niekorzyść AVR.

forlinx2007 napisał:

Co do problemu ze słabym wsparciem dla liczb zmiennoprzecinkowych w środowisku MounRiver Studio, warto przekazać tę informację zwrotną deweloperom narzędzia, mam nadzieję, że uda im się to poprawić w przyszłości.

To jest IDE + gcc toolchain więc nie sądzę żeby były akurat z tym przygody.

Dotarły do mnie CH32V003 i udało mi się przetestować to i owo.
Wygląda na to że zapis do GPIO lub SRAMu trwa tyle co 2 NOPy (2 cykle).

piotr_go napisał:

NOPy (2 cykle).

Czy NOP w tych prockach nie jest ADDI x0,x0,0 ?

Tak. "ADDI x0,x0,0" jest zamieniane na "NOP"

piotr_go napisał:

Tak. "ADDI x0,x0,0" jest zamieniane na "NOP"

Aż sprawdziłem w specyfikacji RISC-V
To tylko tak się wyświetla bo:


Źródło: The RISC-V Instruction Set Manual
Volume I: Unprivileged ISA
Document Version 20191213
https://github.com/riscv/riscv-isa-manual/releases/tag/Ratified-IMAFDQC