lamarozzo ha scritto:albatrosla ha scritto:certi codici nati per 32bit, compilati a 64 decadono leggermente di prestazioni
La mia esperienza è diversa. I codici compilati a 64 bit sono sempre più performanti degli equivalenti a 32 bit
Premetto che io non ho letto molto relativamente ai 64 bit e non ho fatto moltissimi test (soprattutto non ho fatto nessun test con programmi multimediali... per ora). Però ho fatto qualche ricerca e qualche programma per testare le istruzioni aggiunte in questa architettura e, se venissero usate con coscienza secondo me aumenterebbero un po' (non credo molto) le prestazioni. Quello che ho visto io è questo:
1. SYSCALL: questa istruzione è forse la più importante ed è l'unico modo per accedere al kernel a 64 bit (almeno che io sappia). Sostituisce sia la SYSENTER che l'INT80 in modo decisamente più furbo. Non per niente questa non l'ha introdotta la Intell, ma AMD. E' interessante, dicevo, perchè viene chiamata in modo diretto, ossia se voi caricate i registri per configurare la vostra syscall, poi è sufficiente chiamare SYSCALL e non fare strani jump in funzione del vdso (che nei 64 bit non c'è neppure)... ecc (se ne
parlava anche qui). Questo velocizza le chiamate certo... poi bisogna vedere di quanto. Per esempio le chiamate come
gettimeofday() e simili occupano talmente tanto che non ve ne accorgete, ma se usate la getpid() o altre molto snelle allora il guadagno è sensibile. Resta ora da chiedersi quante volte occorra fare una
getpid() in un processo: nel complesso il programma non ne risente perchè di syscall ne fa poche. Ho fatto dei benchmarck a riguardo se qualcuno fosse interessato.
2. R7...R15: e ci voleva tanto?? sempre AMD ha introdotto 8 registri general purpose che sono utilissimi se si fanno call con tanti argomenti o per lasciare liberi i soliti 4 registri (eax... anzi rax, rbx, ecc), quindi senza usare lo stack (le stesse syscall a 64bit le usano come 6° e 7° parametro se non esrro. Vedere il codice delle libc per maggioni informazioni). Non ho mai verificato se vengano usati nelle normali call anche se mi sembra che vengano usati, ma basta disassemblare un programma a 64bit per vederlo.
3. 64 > 32: come faceva notare
ildiama. Certo che qui bisogna vedere se effettivamente vengano effettuati dai programmi calcoli "banali" come somme, moltiplicazioni e divisioni tra interi a 64 bit... e credo siano pochi. I programmi multimediali (seri) di solito usano la fpu, le SSE
x e compagnia.
Quindi anche il compilatore deve metterci del suo: se non è ben ottimizzato i risultati non si vedono. Il gcc4 mi sembra abbastanza ottimizzato in tal senso.
Detto questo però ciò che conta è l'esperienza dell'utente la quale può smentire tutto quello che ho detto e/o verificato. Anzi, mi smentisco da solo: io personalmente uso i 32 bit (su un Opteron) perchè con il 64 bit ho avuto 2 problemi:
1- il primo è piccolo: 2 ubuntu con compiz, su quella a 64bit era leggermente più instabile
2- il secondo è GRAVISSIMO: SDLMaMe funzionava decisamente male! e questo anche sotto slackware se non ricordo male. Inoltre l'ho ricompilato quindi sono sicuro di averlo ottimizzato. Questo è per me sufficiente per dire che i 32bit sono decisamente meglio
(quando si dice la valutazione tecnica
)
bye