>Tra una "pure64" e una "pure32" ho notato delle differenze....a favore >della pure32. Non cosi' forti ma rilevabili. Forse il software non e' >ancora abbastanza ottimizzato per i 64 bit (o il gcc produce codice >migliore a 32, al momento) ma e' stato indicativo per decidere di >provare a passare tutto il sistema a 32. Sto installando adesso una sid >a 32 su un'altra partizione e ho notato che posso installare il kernel
Il fatto e' che a 64bit, ogni registro e' lungo: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: se il file che deve essere gestito ha valori a 8 bit, allora xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxWWWWWWWW solo la parte WWWWWWW sara' processata... cioe' solo un ottavo del registro. Ecco che se usi registri a 32 bit xxxxxxxxxxxxxxxxxxxxxxxxWWWWWWWW, allora dimezzi lo spreco. Ancorché il sistema operativo e lame siano ricompilati a 64bit, se i dati da processare non eccedono i 32bit, il vantaggio dato dai 64bit sara' minimo o nullo... in questo caso, c'e' il peggioramento dato dal dimezzamento logico della cache: inoltre, se per sua natura l'applicativo NON usa piu' degli 8 registri canonici, ecco che anche i 24 registri in piu' NON verranno usati. Conclusione: i 64bit servono, come gia' detto, solo in particolari nicchie. Per esempio se tu ti scrivi un programmino in C che "macina" Trasformate di fourier, ecco che magari potresti avere grossi incrementi prestazionali. Concettualmente, un programma che guadagni molto dai 64bit deve: - essere sufficientemente piccolo per "girare" in cache - avere pochissimo I/O su disco (idealmente, lettura parametri all'inizio dell'elaborazione e scrittura dei risultati finali) - processare necessariamente numeri il cui risultato ecceda i 32bit ( per esempio, 2^30*2^31) - richiedere molte variabili in modo da sfruttare pesantemente i 32 registri a 64bit). Come vedi, pochi programmi "da desktop" soddisfano queste richieste... anzi, a me ne viene in mente proprio nessuno.
