Vlákno názorů k článku
Vývojáři jádra plánují ukončit podporu x32 ABI, které se nikdy neujalo od RDa - Tak zrovna tenhle prasopes mi chybet nebude... a...

Tak zrovna tenhle prasopes mi chybet nebude... a melo to byt vyhozeno jako prvni, namisto redukovani podpory cpu a hw.

Sice jste usetrili 4 bytes na kazde instanci pointeru v datovych strukturach, ale celkova adresovatelna pamet byla jen 2~3 GiB, a pro 64bit operace se pridavali opcode prefixy.. takze treba icache dopadla hur.

Vi nekdo co melo byt prakticke pouziti, a kdo s tim prisel? Asi byla doba jina - dnes by takova vec zaclenena vubec nebyla - jsou striktnejsi pozadavky na co jde dnu a co zustane venku.

Ako si pamätám, tak teoreticky to malo byť rýchlejšie, lebo sa viac zmestilo do cache. Ale časom sa zlepšili procesory a toto nebolo už tak dôležité.

No vzhledem k tomu, že 64-bit operace neexistují v 32-bit režimu je jeden byte na instrukci pořád lepší než několik instrukcí, takže tady problém určitě nebyl.

To, že se ta architektura neujala je hlavně kvůli tomu, že když vzniklo 64-bit x86 tak mít více než 4GB RAM bylo celkem běžné, takže proč by se někdo chtěl omezit na 4GB na proces když už měl v systému podporu pro 32-bit x86, což vyžadovalo 32-bit binárky. Prostě nedávalo smysl mít v systému 3 typy binárek pro jednu architekturu.

Možná to plánovali pro embedded použití, ale tam se zase prosadil ARM, takže opravdu toto chybět nikomu nebude.

Teoreticky z toho měly profitovat procesy s velkým množstvím malých dat (tedy malý obsah provázaný přes pointery). Jenomže takových tak moc není. Možná věci jako Python, Perl, Ruby, JavaScript a jiné interprety. Ale ty zase většinou nezpracovávají velké data - a tam kde ano, tak mají optimalizace, kde jde opět o velké bloky, nikoliv malé objekty. Java podobně - ta měla jiné řešení v podobě compressed oops, které se rovněž neujalo.

Reálným kandidátem by zůstal browser + JavaScript + Css, ale ten přerostl přes 4GB hodně rychle - i když později se separací procesy by teoreticky zase fungoval.

Opcode prefix pro 64-bit operace vyžadují x32 i x86_64 .

Toto se dá ale řešit i v 64-bit procesu. Prostě si vytvořím arenu a místo pointeru použiju 32-bit offset do té areny. A je to. Takto mimochodem funguje třeba 32-bit WASM - naadresuje se celý 4GB blok a pointer je vlastně 32-bit index v tom bloku.

Nápad to byl dobrej, praxe už tolik ne.

Jako myšlenka za tím je jednoduchá, když potřebujete hodně nevelkých procesů (php-fpm třeba), tak memory footprint 32 je proti 64-bitovému userspacu signifikantně menší, takže na nějakém NUCu, nebo v dnešní době i velkém serveru se to vyplatí.

Na druhou stranu pro to samé použití už pěkných pár let používám IA32 emulation na 64bit kernelu (bez čehož třeba ani Steam nepustíte...) v 32bit kontejneru, a funguje to jak má i bez zmíněného kočkopsa.