Vlákno názorů k článku Raspberry Pi 4B: 64bit či nebýt – to je otázka od Milan Keršláger - Ani na PC neznamenal přechod z 32 na...

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.

https://en.wikipedia.org/wiki/X32_ABI

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.

Doporučuji vzít 32bit Raspberry a vyzkoušet/změřit běžný provoz na 64bit verzi. Kromě výše jmenovaných (např. SSL, kódování videa) podstatné zrychlení nenajdete.

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.

Presne tak, na druhou stranu takove aplikace, ktere potrebuji adresovat vice nez 4 GB existuji. A jeden z pripadu pouziti je OS - jasne mame tu PAE, ale to neni v mnoha ohledech idealni. A aplikace si porad muzes psat v 32 bitech.

Mít obrovský virtuální adresový prostor se dá občas zajímavě využít. Třeba si rezervovat veliké pole a postupně mu pak přidávat stránky místo realokování a přesouvání. Ale je to spíš specialitka.