( Raynes | 2021. 05. 14., p – 18:47 )

Ja, azért mondom. Fájlszervernek, torrentnek még jó egyébként, másra nem nagyon.

Igazából már a 128 bitnek is itt lenne az ideje, de egyelőre nem erőltetik. Max. csak vektoros utasításkiterjesztéseknél (MMX, SSE, AVX, stb.). Hiszen a 64 bites memóriacímzés még hosszú ideig elég lesz, nem jelent korlátot. De már lenne annyiból értelme mégis a 128 bitnek, hogy 128 biten dupla annyi regiszter van, egy regiszterbe dupla annyi adat fér, így egy utasít/regiszter épp úgy lemegy nagyjából 1-2 órajelcikus alatt. Erre most szükség lenne, főleg, hogy elkezdték elérni a Moore-törvény végét, nem nagyon tudnak már levinni nagyon hova tovább a szilikonos csíkszélességet, 5 GHz-et se nagyon tudják átlépni. Így az van, hogy a magok számát, meg a cache méretét növelik, de az is csak egy szintig segítség, utána ki nem használt overkill.

Csak ugye a bitkomplexitás emelése is lassú folyamat, mert hiába is lenne proci hozzá legyártva, el tud bukni az egész a szoftveres supporton. Mert mire használod, ha a futtatandó kódok 32/64 biten ragadnak, és lusta, konzervatív fejlesztők csesznek 128 bitre portolni. Jó, egy-két opensource cumót le tudnánk rajta fordítani, ha legalább a compiler támogatja, de akkor sem lesz teljes a siker. A 64 bitnek is nagyon sok idő kellett, meg a 16 bitet is anno a 32 ellenében elég sokáig életben tartották a DOS alapú félmegoldásokkal. De pl. a több mag/szál támogatása is nagyon lassan terjedt el, és a mai napig terjedőben van, hogy sok szoftver nem igen skálázódik teljesítményben x szál fölé. Így a 128 bitből nem lesz semmi még nagyon sok évig, egyelőre még mindig ott tartunk, hogy a 32 bit kopjon ki a 64 ellenében.

Más részről meg az is igaz, hogy egy szinten túl a bitek növelése se segítség, mert ha szög egyszerű a kód, belefér a cache-be, és nem nagyon memória/regiszterintenzív, meg nem is annyira számításigények, akkor nem gyorsul semmit attól, hogy 32 bites, vagy 64, vagy 128. Megint olyan kétélű fegyver, mint a több mag.