Odpověď na názor

Tak tedy:

Ohledne adresace pameti: je potreba rozlisovat mezi virtualnim adresnim prostorem a fyzickou pameti. Klasicke i686 ma 32b virtualni adresy, ktere se pres strankovani prekladaji na fyzicke, ktere maji 36b, coz je pro rozumne desktopove pouziti vice nez dost (ukazte mi nekdo desktopovy chipset, ktery te pameti umi vic). Uvaha, ze jeden proces potrebuje vic je dost mimo, veci ktere vyuziji vic to stejne vyuziji na veci typu blokovou cache, kde je to stejne nezajimave, protoze to resi kernel a resi to jinak.

Velikost kodu: amd64 kod proste je vetsi o ty REX prefixy, je otazkou proc to tak panove v AMD vymysleli, ale proste je to tak. Druha vec je, ze amd64 umi RIP relativni adresovani, ktere vetsinu realistickeho (tj. generovaneho) kodu na ELF platformach vyznamne zmensi. Na COFF systemech, coz jsou treba (a vlastne jenom) windows, je ten kod proste jenom bez jakehokoli uzitku vetsi.

Velikost dat: tady jde dost o system na kterem to bezi a jeho ABI. Pointer proste je vetsi (a vzhledem k tomu, ze snad neexistuje procesor, ktery vrchni byte neignoruje tak i zbytecne), to zcela evidentne zvetsuje zatez cache, coz je to misto na kterem stoji a pada vykon dnesnich (+- deset let) procesoru.

Rozsah datovych typu: u veci jako off_t a time_t je celkem uplne putna, jestli se aritmetika provadi jednou nebo ~3 instrukcemi, vykonostni rozdil je celke zanedbatelny, jednak kvuli superskalarnosti dnesnich procesoru, druhak proto, ze se to az tak casto nedeje. Predstava, ze time_t je proste ten architekturni int pod tim je celkem uplne mimo, zvlast proto, ze amd64 ABI je LP64, kde int je stejne 32 bitu. off_t ma 64 bitu dnes snad uz uplne vsude (alespon s -D_FILE_OFFSET_BIT­S=64).

Vec kterou si mnoho lidi celkem neuvedomuje, je ze mnohe mikroarchitektury jsou v long mode vyznamne pomalejsi, nez v normalni i386 PM. Problem je, ze pak jsou jine, kde je to presne naopak.

Zaver je, ze pokud o to cloveku vazne jde (a typicky fakt nejde), tak to stoji za to vyzkouset na konkretni aplikaci a konkretnim HW.