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 mi 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.
> 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. Poi il discorso è che la maggior parte delle variabili dei programmi sono impacchettate in strutture, quindi solo la struttura viene allineata ai 64 bit. 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). > Per i motivi esposti prima e anche a causa dell'architettura più nuova e > dei compilatori che ottimizzano peggio, Questa posizione è interessante, ma servirebbe un po' di documentazione a sostegno: l'architettura a 64 bit non è poi così nuova dal punto di vista dei compilatori, soprattutto non lo è quando si parla di problematiche di allineamento dei dati che sono sostanzialmente le stesse su tutte le architetture a 64 bit. gcc compila software su sistemi a 64 bit almeno dal lontano 1998 su Tru64 (forse anche da prima). http://www.unixguide.net/compaq/faq/Alpha5.shtml > *soprattutto se il programma non > è stato scritto tenendo presenti le richieste di allineamento in memoria > dei dati* un sistema amd64 occupa più memoria, quanta, dipende dal > programma. 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? 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. > 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 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. È 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? :) > Mentre > non è vero che i kernel a 64 bit sono "ottimizzati" per 4Gb o più di > memoria a discapito delle configurazioni inferiori. Questa infatti era una mia ipotesi e l'avevo anche scritto, che non sia verificata può starci. Lucio. -- Virtual Bit di Lucio Crusca via Isonzo, 5 - 10069 Villar Perosa (TO) - Italy http://www.virtual-bit.com -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
