Názor k článku Raspberry Pi 4B: 64bit či nebýt – to je otázka od radioing - Když ono je to urychlování těžké. "Běžnému" kódu...

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.