Názory k článku Raspberry Pi 4B: 64bit či nebýt – to je otázka
-
FíkZlatý podporovatelNo to záleží, co testujete, ale často byl přínos značný a ne jen pár procent. Třeba tu:
https://www.phoronix.com/scan.php?page=article&item=ubuntu-1710-x8664
namátkou:
FFTW +30%
cray +25%
ffmpeg +11%
openssl 4,4x
redis +40% -
FíkZlatý podporovatel
Nevím, jaké výsledky běžného používání máte na mysli, ale když se kolem roku 2005 pomalu začínalo s přechodem na 64 bitů, tak občas nějaký program byl ve 32 bitech výrazně rychlejší než v 64. Bývalo to většinou tím, že v x86 byla část optimalizovaná v assembleru a to pro x86_64 zatím nebylo. Proto jsem dal testy až z roku 2017, kdy už byl tento nedostatek odstraněn.
Jinak je asi všem jasné, že u aplikace, která nepoužívá matematiku, vystačí si dohromady s pěti registry a celou dobu čeká na periferie nebo uživatele, těžko můžu očekávat nějaké zrychlení.
-
Tak, tak. Dosáhnout podstatného zrychlení na ARM72 při přechodu z AArch32 na AArch64 je docela potíž a přesně jak je uvedeno výše, daří se to dobře právě u těch "specifických testů". Programátor zkrátka musí v kódu jít naproti novým možnostem, a v případě AArch64 je to především navýšení počtu registrů na dvojnásobek. Kompilátor také ledacos dokáže, ale pokud je algoritmus zapsán tak, že vystačí s pár 32bitovými registry (a přitom by nad 20 64bitovými registry mohl být podstatně rychlejší), je kompilátor/AArch64 mimo hru. Mimochodem, AArch64 má stejně jako AArch32 32bitovy opkód. Thumb sada je samozřejmě poněkud úspornější.
-
Jinak je asi všem jasné, že u aplikace, která nepoužívá matematiku, vystačí si dohromady s pěti registry a celou dobu čeká na periferie nebo uživatele, těžko můžu očekávat nějaké zrychlení.
Delani matematiky ala FFT nebo lin. algebra neni jediny zpusob, jak intenzivne pouzivat CPU.
Hlavni problem je s pointery. Pokud mas grafove algoritmy, strom objektu (coz mi prijde v programovani jako mnohem beznejsi nez dilci matematicke ulohy), tak diky 2x vetsim pointerum se ti do cache vejde (priblizne) polovina uzlu nebo objektu a to uz jde poznat na vykonu a vic registru moc nepomuze. Mne to na nekterych ulohach delalo i 30% pokles.
4. 11. 2019, 11:56 editováno autorem komentáře
-
FíkZlatý podporovatel
Záleží asi co komu přijde běžnější :) Kvůli pointerům bylo vymyšleno i speciální x32 ABI, ale jelikož se neprosadilo, tak ty pointery nakonec až takový problém zřejmě nejsou.
-
Kvůli pointerům bylo vymyšleno i speciální x32 ABI, ale jelikož se neprosadilo, tak ty pointery nakonec až takový problém zřejmě nejsou.
Ano, a bohuzel se nikdy nedostalo z faze "zajimava hracka", protoze podpora pro toto ABI byla miziva, zejmena na strane knihoven a nastroju.
Na druhou stranu, treba JVM pouziva komprimovane (32bitove) ukazatele prave z mnou popsanych duvodu. A tady se opravdu neda mluvit o tom, ze by se to nepouzivalo.
Záleží asi co komu přijde běžnější :)
Ony se prestaly pouzivat objektove orientovane jazyky?
-
Jestli by resenim 64bit aplikaci nebylo pouzivat pointery pres tabulku pointeru. Obvykle nepotrebuju mit 4GB dat ruzne rozhazenych, ale urcite struktury "patri k sobe". Takze bych mel malou tabulku variabilne dlouhych pointeru, do ktere bych indexoval. Tabulka by byla asi relativne mala a relativni vuci svemu offsetu (resi ze v ramci +-2G heap se vejdu do 32 bitu). Pri propojeni s alokatorem by to mohlo byt i vcelku bezudrzbove z pohledu programatora. Slozite resitelne u C, mene slozite u nejakeho C++ a u jazyku typy Java/C# asi trivialni.
Podobny mechanismus jsem videl u embedded prekladace PowerPC ISA, kdy kvuli uspore pameti (z 32 na 16 bitu) byly pouzity urcite globalni registry na adresaci dat v RAM a flash, nicmene tam to bylo mozne z duvodu chytreho navrhu (struktura byla navrzena tak, aby to nepreteklo).
U PowerPC bylo chytre i resnei 64bit cisel, 32bitovy a 64bitovy kod se v podstate nelisily, rozdil byt pouze v moznosti naloadovat hornich 32 bitu a pak jestli ALU pocita 32bitove nebo 64bitove (flagy, mul/div).
-
Zrovna u grafovych algoritmu si hezky muzes udelat prvky treba v std::vector ,takze je mas vsechny pekne v jednom miste pameti a indexovat je jak chces klidne pomoci 32bitu, ale chapu, ze nejake 64bit programy by si vystacily s 32bit pointery. Kdyz to zjednodusim, tak pri prechodu byly vyhody 2 -> muzes indexovat vice pameti, proto programy, ktere potrebovaly vice bud neexistovaly nebo pouzivaly pseudoswap a tim padem prechod na 64bit byl pro ne naprosto skvela vec a druha vec - pro kompilery jistota registru a vlastnosti CPU.
-
Zrovna u grafovych algoritmu si hezky muzes udelat prvky treba v std::vector ,takze je mas vsechny pekne v jednom miste pameti a indexovat je jak chces klidne pomoci 32bitu
Tomu se bezne rika knizeci rady. Uprimne me prekvapilo, ze s touto dobrou radou prisel nekdo az po dvou dnech.
Kdyz mas totiz program, ktery je naprogramovany beznym zpusobem (pouziva pointery tam, kde to je na miste) a ktery je odladeny a otestovany, a ktery na nove architekture bezi pomaleji, protoze spatna prace s cache, tak ti hodne pomuze, kdyz vis, ze neni problem v nove architekture, ale v tom, ze jsi to jeste neprepsal tak, aby to bezelo rychleji. Proboha, bavime se tu celou dobu o tom, ze prechod 32->64 bitu nemusi znamenat automaticky prinos.
-
Když ono je to urychlování těžké. "Běžnému" kódu bez programátorské péče trochu pomůže jen to zvýšení počtu registrů, když se opravdu dají zužitkovat. Pokud se programátor cíleně zaměří na vybrané algoritmy, tak je nakonec často výhodnější použít SIMD (např. FFT), a když přesto chce použít instrukční sadu jádra, tak zjistí, že spousta algoritmů zcela logicky ctí předpokládaný mainstream hardware v době svého vzniku (namátkou AES - matice 4 x 4 x bajt, ChaCha matice 32bitových slov,...), takže rozšíření operandů z 32 na 64 bitů bez nějaké minimální podpory ve smyslu SIMD (třeba alespoň rozdělení 64bitových registrů na 2 32bitové) má přínos nula.
Osobně jsem zažil vše od 4bitů (vynechávám dřevní 1bitové řezy, které jsem pouze viděl) přes slavnou éru 8bitů, přechodné období 16bitů (86/286, 80166, MSP430; ale ta krása moci pracovat přímo v rozsahu 65536 diskrétních hodnot, což bohatě stačilo na téměř všechny aplikace) po éru 32bitů (ve 4 mld. úrovních už lze vyjádřit snad vše a po uint64_t jsem sáhl opravdu výjimečně, když dynamika aritmetiky těsně vyjela nad 32 bitů, abych ji vzápětí zkrotil posunem vpravo). S 64bit. registry si nějak nevím rady. Občas se to hodí, když třeba prohledávaný prostor vyteče z 32bitů a algoritmus je nutné z důvodu rychlosti udržet v registru, ale jinak... Adresovací možnosti jako spíše embeďák nějak nedokážu ocenit a 64bitové pointery ve mně vyvolávají asociace, jako když jsme v automatizovaných splachovačích záchodů nahrazovali staré dobré 8051 ARMy (nadsázka).
Posun 32 bitů -> 64 bitů core je zásluhou nedostatečného adresového prostoru, a nikoliv hladu po větším rozsahu operandů - je to sice příjemný side-effect, ale na to tu už nějaké roky bylo mocnější SIMD. Tomu pak odpovídá i urychlení vykonávání kódu. -
> Potřebujete nejprve cross-kompilátor, který běží na arm a kompiluje pro aarch64.
No, nevim, osobne si myslim, ze kompilovat aarch64 na 32bit arm RPi je trosku overkill - at uz z hlediska vykonu procesoru, tak omezeni RAM a FLASH.
O mnoho jednodussi a rychlejsi je pouzit intel/AMD s linuxem (asi i win32, ale nevim, nezkousel jsem), kde preci jenom mam vic vykonu/jader a vetsi pamet a disk ..... -
Ondřej CaletkaZlatý podporovatelJako většina přirovnání i tohle kulhá na obě nohy. Pro tebe je zřejmě USB boot klíčová záležitost, pro jiné (a řekl bych, že většinu) je to naprosto nepodstatná věc, kterou třeba ani nikdy nepoužijí.
Rada je jednoduchá, pokud nejsi spokojen se stávající verzí bootloaderu, prostě před koupí počkej, než/jestli bude nějaká lepší verze. Nic jiného na to napsat nedá.
-
k3dARStříbrný podporovatelto prirovnani by mohlo teoreticky "fungovat", pokud by pro startovani toho auta musel pripojit do motoroveho prostoru druhou mensi baterku, a startovalo by se beznym zpusobem otocenim klicku, s tim ze by bylo poresene dobijeni druhe baterky, tedy uzivatel by v podstate nepoznal problem, maximalne by se mohlo stat ze by ta mensi baterka odesla drive nez ta vetsi hlavni, ale stacilo by vozit v kufru nahradni mensi-druhou baterku :-)
a z blbeho prirovnani k realite RPi4... to ze zatim FW neumi start z USB je snadno resitelne tak, ze se na /boot pouzije microSD karta, ktera pri zapnuti RPi4 natahne zavadec, jadro, initrd, moduly a prepne se na rootfs na USB-Flash/HDD/SSD... rychlost ci chovani nabehleho systemu z USB-Neco pak bude totozna jako by byl boot komplet z USB-Neco, microSD oddil bude pripojen do /boot takze se bude aktualizovat jadro beznym zpusobem, jakmile vyjde novy FW s moznosti primeho boot z USB, tak se jen zkopiruje obsah z microSD na pripraveny prvni maly oddil na USB-Neco a zmeni se ve fstab aby se pripojoval do /boot, vynda se microSD karta a uzivatel nic v podstate ani nepozna, krome toho ze microSD slot bude prazdnej a pujde tedy pouzit na pristup k obsahu jakekoliv jine vlozene microSD karty, coz je tedy jediny "zasadni" rozdil kterej je zatim resitelnej pripojenou USB-microSD cteckou...
-
FíkZlatý podporovatel
vypadá to, že se změnila syntaxe u debootstrap, teď je potřeba:
sudo debootstrap --arch arm64 stable /srv/chroot/pi64
(raději to změním i v článku)
ČLÁNKY DO MAILU