Il giorno gio, 01/05/2008 alle 23.15 +0200, Lucio Crusca ha scritto:
> Federico Di Gregorio wrote:
>
> > Questa è abbastanza una panzana.
> > [...]
> > Falso.
> > [...]
> > Falso.
> >
> Beh, può darsi che mi sbagli, anche se personalmente cercherei di essere un
> po' più gentile... è vero che la memoria necessaria non è il doppio, ma m
> premeva spiegare il perché un sistema a 64 bit è sostanzialmente peggio di
> un sistema a 32 bit a meno che non ci sia una buona ragione per usarlo,
> visto che Franco sembrava stupito di questo fatto. Non sono stato a mettere
> le cifre esatte, che peraltro non conosco, ma mi bastava esprimere il
> concetto.
Facciamo così. Quando non farai più affermazioni palesemente false, io
sarò più gentile. (Scherzo, e se l'hai patito molto chiedo scusa per
"panzana"). Insomma, hai detto:
Il principale motivo è che con un kernel a 64 bit ogni variabile
occupa in RAM 64 bit invece di 32, quindi con un kernel a 64 bit
è come avere la metà della RAM rispetto allo stesso kernel a 32
bit.
che, appunto, è palesemnte falso perché non è vero che le variabili
occupano sempre 32 bit in memoria e soprattutto non è vero che su di un
sistema a 64 bit ne occupano automaticamente il doppio.
Sul concetto generale (su sistemi a 64 bit va via più memoria) ti ho
comunque dato ragione.
> > Una variabile occupa sempre lo stesso
> > spazio ma, per motivi di accesso alla memoria, a seconda del tipo di
> > variabile c'è un allineamento che spreca qualche byte.
> Se una variabile occupa 2 byte ma viene allineata per multipli di 4 byte, è
> vero che 2 byte sono solo "qualche byte sprecato", ma sono sempre il doppio
> di quello che servirebbe per memorizzare quella variabile su un sistema a
> 32bit.
Questo (i problemi di allineamento) vale _anche_ su sistemi a 32bit.
> Poi il discorso è che la maggior parte delle variabili dei programmi
> sono impacchettate in strutture, quindi solo la struttura viene allineata
> ai 64 bit.
Esatto. Poi c'è il problema della dimensione dei puntatori, etc.
> Torno a dire: non mi interessava tanto calcolare l'effettivo
> spreco di memoria, che pur non essendo il doppio è comunque tutt'altro che
> trascurabile, mi bastava dare una spiegazione teorica (che fra l'altro è la
> stessa che stai dando tu).
Il problema è che invece l'hai dato come un dato certo ("consuma il
doppio!"); se tu avessi scritto nell'email precedente quello che hai
scritto qui mica ti avrei corretto.
> Scusa la domanda che può sembrare stupida, ma cosa dovrebbe fare un
> programma per tenere conto dell'allineamento dei dati? Facciamo di tutto
> per scrivere programmi portabili e poi ci dobbiamo preoccupare di scrivere
> le strutture in modo che occupino 2 bytes in meno sui sistemi a 64 bit?
Dipende da quante di quelle strutture usi. Se il tuo programma ne crea e
distrugge centinaia di migliaia sarebbe il caso di farci attenzione si.
Non solo per l'uso di memoria ma anche per la velocità (a volte 1 byte
di differenza fa si che una struttura dati non stia tutta in una cache
line con notevole peggioramento delle prestazioni).Per esempio:
int a
int* b
int c
è peggio di
int c
int a
int* b
Il problema è che su di un sistema a 32 bit le due strutture sono
assolutamente identiche mentre su di un 64 bit no. Ovviamente buona
parte del software che usiamo è stata scritta prima dell'avvento di
amd64 e quindi.. *burp* buona digestione.
> Credo che qualsiasi programma ben scritto se ne freghi altamente
> dell'allineamento e penso che sia giusto così, nella misura in cui questo
> programma se lo possa permettere (ovvero non sia un driver di una
> periferica). Coseguenza: la maggior parte dei software diffusi occupano
> molta più ram su sistemi a 64 bit. Credo che la dimostrazione sia la prova
> di fatta da Franco. Che poi la causa si chiami allineamento, o effettiva
> dimensione delle variabili, o il mancato sbattimento dei programmatori ad
> ottimizzare le strutture per i sistemi a 64 bit, poco importa, il fatto è
> che un sistema a 64 bit occupa molta più RAM dello stesso sistema
> ricompilato a 32 bit.
"Molta" andrebbe definito, comunque in senso generico ti do ragione.
> > Questa è l'unica spiegazione per il maggiore consumo.
> Che come dicevo è sostanzialmente la stessa ho dato io, solo che la tua la
> chiami "allineamento" mentre la mia la chiami "panzana". Comunque mi sono
No. Leggi sopra la tua frase esatta che ho riportato ed alla quale
"panzana" era riferito.
> preso la briga di cercare benchmark a riguardo, se ne trovano pochi e non
> particolarmente completi, uno è
>
> http://www.osnews.com/story/5768/Are_64-bit_Binaries_Really_Slower_than_32-bit_Binaries_/page1/
>
> ma dicono sostanzialmente che:
> 1. se hai più di 4gb di ram conviene usare sistemi a 64bit
> 2. se devi macinare numeri conviene usare sistemi a 64bit
> 3. negli altri casi ci perdi circa da un 5% a un 20% in velocità e da un 20%
> a un 50% in occupazione della RAM.
L'unico applicativo che è nettamente più veloce è openssl. MySQL varia a
seconda dell'operazione e gzip è più veloce a 64 bit. Direi che se ne
può dedurre che a seconda di com'è stato scritto il codice sicuramente i
64 bit hanno un impatto ma non rallentano sempre come si sente dire in
giro.
> È vero che il 20% in più non è il doppio ed il 50% nemmeno, ma nessuno dei
> due può essere liquidato come "qualche byte in più". Abbiamo forse entrambi
> scritto una panzana? :)
Se leggi attentamente la mia email vedi che al fondo ti do ragione.
Scrivo che invariabilmente su di un sistema a 64 bit si usa più memoria.
Ho solo criticato il tuo dire "doppia".
federico
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer fog@debian.org
INIT.D Developer fog@initd.org
Se sai che hai un ***** di file così, lo manovri subito. -- vodka
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente