# Pae?

## lordalbert

Ciao. Volevo chiedervi delucidazioni su PAE  :Smile: 

Da quel che so, è soltanto un workaround per leggere più di 4GB di memoria. Però il sistema non è in grado di vedere _contemporaneamente_ più di 4Gb di memoria.

Infine, per recuperare 700MB di ram in più (ora ne ho 4GB, riconosciuti 3.2), conviene attivare pae? ci sono controindicazioni particolari?

----------

## ago

immagino che non hai la possibilità di usare amd64...

----------

## mack1

Ciao lordalbert, pae permette al sistema di utilizzare 64 GB (36 bit) di memoria, ma una singola applicazione può utilizzare solo 4 GB (essendo scritta per un'indirizzamento a 32 bit).

C'è un'interessante discussione su LKML sui pro e contro:

http://lkml.org/lkml/2009/12/30/331

Comunque alcune distro lo abilitano di default (opzione  HIGHMEM64G nel kernel), quindi non dovrebbe creare particolari problemi (ovviamente deve essere supportato dalla tua cpu  :Wink:  ).

Ciao

----------

## lordalbert

 *ago88 wrote:*   

> immagino che non hai la possibilità di usare amd64...

 

Beh, diciamo che non ho motivi per usare un sistema a 64bit, se non quello di usare tutta la ram (che probabilmente non userò mai tutta, era però una mia curiosità).

Anche perchè avendo binari più grossi, occupo in media più ram  :Smile:  e quindi quella che recupero, la vado a perdere a causa di un maggior uso da parte di binari grossi.

Oltre a ciò, non faccio uso di programmi matematici/grafici che risentirebbero dei 64bit. Anzi, flash e possibili altri sw sono rimasti a 32, anche se ormai i loro problemi possono considerarsi risolti, possono in ogni caso creare problemi.

 *mack1 wrote:*   

> Ciao lordalbert, pae permette al sistema di utilizzare 64 GB (36 bit) di memoria, ma una singola applicazione può utilizzare solo 4 GB (essendo scritta per un'indirizzamento a 32 bit).
> 
> C'è un'interessante discussione su LKML sui pro e contro:
> 
> http://lkml.org/lkml/2009/12/30/331
> ...

 

ok, grazie milel!

----------

## ago

devo dire che uso amd64 da tempo e mi trovo davvero bene...a parte il fattore ram..noti un incremento prestazionale.

Come hai già detto la differenza si vede soprattutto se usi programmi che usano il calcolo a virgola mobile..ma ti consiglio di provare quando hai tempo  :Smile: 

----------

## Kernel78

 *lordalbert wrote:*   

> Anche perchè avendo binari più grossi, occupo in media più ram  e quindi quella che recupero, la vado a perdere a causa di un maggior uso da parte di binari grossi.

 

scusa ma qui stai sparando cavolate o sono dati reali ?

vorresti farmi credere che usando amd64 invece di x86 avresti in media binari che ti occupano 700 mb in più ???

se hai dei riferimenti mi piacerebbe leggerli ...

P.S. visto che ritieni che non userai mai tutta quella ram puoi regalarmene un paio di gb  :Wink: 

----------

## djinnZ

Non so se sia un problema specifico della patch hardened, ma i kernel >=2.6.29 hanno qualche problemino con PAE (crash per corruzione di memoria al caricamento nel mio caso) e l'hardened anche con 4GB.

Quindi attenzione. Se non ho letto male dovrebbe essere risolto dal .31 in poi. Quindi verificare bene prima di attivare quell'opzione.

Quanto alla ram vista dal sistema c'è anche la questione dell'indirizzamento balordo delle unità interne da considerare. PAE non risolve nulla e neppure il sistema a 64 bit.

Se non hai l'esigenza di condividere i binari con macchine a 32 ti conviene passare a 64 bit comunque, solo in caso contrario (il mio ad esempio) ti conviene rimanere a 32, questo è il mio modesto consiglio.

----------

## lordalbert

 *Kernel78 wrote:*   

>  *lordalbert wrote:*   Anche perchè avendo binari più grossi, occupo in media più ram  e quindi quella che recupero, la vado a perdere a causa di un maggior uso da parte di binari grossi. 
> 
> scusa ma qui stai sparando cavolate o sono dati reali ?
> 
> vorresti farmi credere che usando amd64 invece di x86 avresti in media binari che ti occupano 700 mb in più ???
> ...

 

Lo so che sono sistemi operativi differenti, ma settimana scorsa ho dovuto installare win7 su un'altra macchina, e mi sono informato un po' su di esso, cercando anche di verificare di persona.

Innanzitutto, basta guardare alle .iso. Quella della versione a 32bit è 2.22GB, quella della versione 64bit 2.90GB. il 30% in più. Altra cosa, nei requisiti di sistema minimi, per la versione a 32bit è 1GB, per la 64bit è 2GB.

Lo so che son sistemi operativi diversi, che win fa schifo, bla bla bla, e tutto quello che potrai dire  :Wink:  però le regole dell'informatica sono le stesse.

Ma vuoi prendere ad esempio anche le .iso dei minimal cd di gentoo? 32bit: 103032 KB, mentre la 64bit: 117392 KB.  Più di 14MB su 100. Quindi 14% 

Se consideri che 700mb di ram rispetto ai 4gb sono il 17% .. la differenza è minima.

Visto, inoltre, che il vantaggio sui 64bit si sente solo su particolari calcoli matematici, e io non uso nè applicazioni matematiche, nè conversione video &c (magari qualche volta le userò, ma non mi importa aspettare un po' di più)..

Leggevo poi quando si usano sw 32bit su un sistema a 64bit (per esempio flash player e simili su un sistema a 64), il processore perde del tempo a fare lo switch fra 32 o 64. Non chiedermi maggiori info su ciò perchè non ho le competenze per approfondire, lo prendo solo come dato non autorevole, anche se la fonte mi è sembrata tale.

----------

## ago

 *lordalbert wrote:*   

> Lo so che sono sistemi operativi differenti, ma settimana scorsa ho dovuto installare win7 su un'altra macchina, e mi sono informato un po' su di esso, cercando anche di verificare di persona.
> 
> Innanzitutto, basta guardare alle .iso. Quella della versione a 32bit è 2.22GB, quella della versione 64bit 2.90GB. il 30% in più. Altra cosa, nei requisiti di sistema minimi, per la versione a 32bit è 1GB, per la 64bit è 2GB

 

Meno male che poi l'hai detto tu che: 

 *lordalbert wrote:*   

> Lo so che son sistemi operativi diversi

 

 *lordalbert wrote:*   

> Leggevo poi quando si usano sw 32bit su un sistema a 64bit (per esempio flash player e simili su un sistema a 64), il processore perde del tempo a fare lo switch fra 32 o 64

 

Hai mai sentito parlare di no-multilib ?

Per il resto lasciando perdere tutti i bilanci che hai fatto si può giudicare bene solo dopo che si ha provato....non penso che sia un problema avere una root di 5gb(occupati) piu performante con amd64,     al posto di una root di 4.5gb(occupati) meno performante con amd64

----------

## Kernel78

cerco di non infierire troppo perchè anche a me è capitato di partire per la tangente e difendere posizioni arbitrarie senza basi razionali ma ...

 *lordalbert wrote:*   

> Ma vuoi prendere ad esempio anche le .iso dei minimal cd di gentoo? 32bit: 103032 KB, mentre la 64bit: 117392 KB.  Più di 14MB su 100. Quindi 14% 
> 
> Se consideri che 700mb di ram rispetto ai 4gb sono il 17% .. la differenza è minima.

 

[cerco di tenere a bada il sarcasmo]

scusa ma tu in genere carichi contemporaneamente TUTTI gli eseguibili installati ?

Inoltre la RAM è sempre meglio di un HD e se hai più ram di quanta ritieni ne sfruttino i tuoi programmi puoi sempre adibirne una parte a fs temporaneo per velocizzare di diversi ordini di grandezza le operazioni di lettura e scrittura (una volta avevo letto un thread per mettere le librerie in ram e rendere l'avvio dei programmi incredibilmente più veloce) ...

----------

## lordalbert

 *ago88 wrote:*   

> 
> 
> Meno male che poi l'hai detto tu che: 
> 
>  *lordalbert wrote:*   Lo so che son sistemi operativi diversi  

 

Ho fatto i confronti con win solo perchè è un esempio che ho analizzato bene settimana scorsa.

Ho poi fatto gli stessi confronti con le iso minimal di gentoo, e i risultati non erano tanto diversi  :Wink: 

 *Quote:*   

> Hai mai sentito parlare di no-multilib ? 

 

 hai mai avuto necessità di sw che esiste solo in 32bit?

 *Quote:*   

> 
> 
> Per il resto lasciando perdere tutti i bilanci che hai fatto si può giudicare bene solo dopo che si ha provato....non penso che sia un problema avere una root di 5gb(occupati) piu performante con amd64,     al posto di una root di 4.5gb(occupati) meno performante con amd64

 

Guarda che non si parlava di spazio di root  :Wink:  Si parlava di ram.

Cmq ho già avuto una installazione gentoo a 64bit. Non ho notato (ad occhio) particolari differenze, nell'utilizzo quotidiano desktop. E' difficile rendersene conto "ad occhio"

----------

## Kernel78

 *lordalbert wrote:*   

>  *ago88 wrote:*   
> 
> Meno male che poi l'hai detto tu che: 
> 
>  *lordalbert wrote:*   Lo so che son sistemi operativi diversi   
> ...

 

tieni conto che in un livecd amd64 presumo siano presenti sia le librerie a 32 che a 64 ... penso sia questo a comportare il grosso della differenza di spazio (dovrei scaricarmeli e fare un contrfonto)

 *Quote:*   

> Guarda che non si parlava di spazio di root  Si parlava di ram.

 

allora ti rimando alla mia domanda provocatoria: tu carichi spesso tutti gli eseguibili contemporaneamente ?

----------

## lordalbert

 *Kernel78 wrote:*   

> 
> 
> scusa ma tu in genere carichi contemporaneamente TUTTI gli eseguibili installati ?
> 
> Inoltre la RAM è sempre meglio di un HD e se hai più ram di quanta ritieni ne sfruttino i tuoi programmi puoi sempre adibirne una parte a fs temporaneo per velocizzare di diversi ordini di grandezza le operazioni di lettura e scrittura (una volta avevo letto un thread per mettere le librerie in ram e rendere l'avvio dei programmi incredibilmente più veloce) ...

 

ovviamente non carico in ram contemporaneamente tutti gli eseguibili installati. Ed è per quello che avevo detto "che probabilmente non userò mai tutta". Ma ho intenzione di usarla come buffercache. Ed è proprio quello che consigli tu,  caricare in ram i programmi maggiormente usati, anche se non in esecuzione in quel preciso momento, in modo da velocizzarne l'avvio. Nasce da ciò la mia curiosità sull'attivare PAE, per avere 700MB in più.

Detto ciò, scusa ma mi sembra che il tuo ragionamento non sia perfettamente corretto. Se ogni singolo eseguibile caricato in memoria ne occupa meno (nel caso a 32bit), potrò avere in ram un maggior numero di eseguibili, rispetto al caso in cui i singoli eseguibili occupino di più (64bit), perchè poi avrò meno spazio per caricarne altri.

Se, paradossalmente, si avesse tanta ram quanta ne è necessaria per caricare TUTTI (o per lo meno, i più usati) eseguibili installati nel sistema, si avrebbe una macchina decisamente più veloce. Credo sia noto a tutti che l'hd rappresenta il principale collo di bottiglia in un sistema moderno.

 *Quote:*   

> 
> 
> allora ti rimando alla mia domanda provocatoria: tu carichi spesso tutti gli eseguibili contemporaneamente ?
> 
> 

 

Credo di aver già risposto nelle righe precedenti.

Volevo solo chiarire una cosa: Non voglio imporre le mie idee come verità assoluta. Riporto solo i miei pensieri nati dalla mia personale riflessione "32 vs 64", basati sulle scarse conoscenze che ho dell'informatica a basso livello. Nel caso fossero sbagliati, sarei felice se mi dimostrasse che non è come dico io  :Smile: 

PS: La scelta sui 32bit è stata fatta anche perchè non credo di trarre grossi benefici da un sistema 64bit, per l'uso che ne faccio io. Non è solo una questione di binari più grandi e quindi maggior consumo di ram.

----------

## Kernel78

 *lordalbert wrote:*   

> ovviamente non carico in ram contemporaneamente tutti gli eseguibili installati. Ed è per quello che avevo detto "che probabilmente non userò mai tutta".
> 
> 

 

non seguo il ragionamento ...

io l'altra settimana ho lanciato un eseguibile di meno di 300k e ha continuato a girare per 3 giorni tenendo occupato (stando a top) il 75% della memoria (tra ram e swap ho 6 gb) ... ok, caso abbastanza anomalo anche per me ma rimane il fatto che la dimensione di un eseguibile non è indice della quantità di ram che andrà ad occupare ...

 *Quote:*   

> 
> 
> Ma ho intenzione di usarla come buffercache. Ed è proprio quello che consigli tu,  caricare in ram i programmi maggiormente usati, anche se non in esecuzione in quel preciso momento, in modo da velocizzarne l'avvio.
> 
> 

 

a dire il vero io consigliavo qualcosa di diverso ...

usare tmpfs per avere una partizione temporanea tutta in memoria, se un applicativo fa moltissimi accessi a file allora tenere questi file in memoria invece che su disco offre un incredibile boost alle prestazioni ...

oppure tenere la partizione con le librerie montata in ram rende il caricamento di un eseguibile MOLTO più veloce ...

 *Quote:*   

> 
> 
> Detto ciò, scusa ma mi sembra che il tuo ragionamento non sia perfettamente corretto. Se ogni singolo eseguibile caricato in memoria ne occupa meno (nel caso a 32bit), potrò avere in ram un maggior numero di eseguibili, rispetto al caso in cui i singoli eseguibili occupino di più (64bit), perchè poi avrò meno spazio per caricarne altri.
> 
> 

 

come ho detto sopra non esiste correlazione tra la dimensione di un eseguibile e la ram che andrà ad utilizzare ...

ok, occupa una quantità di ram pari alla sua dimensione fisica ma in genere ne va ad allocare altra ...

inoltre non tieni conto che se carichi troppi programmi simultaneamente corri il rischio concreto che il collo di bottiglia diventi la cpu  :Wink: 

 *Quote:*   

> Volevo solo chiarire una cosa: Non voglio imporre le mie idee come verità assoluta. Riporto solo i miei pensieri nati dalla mia personale riflessione "32 vs 64", basati sulle scarse conoscenze che ho dell'informatica a basso livello. Nel caso fossero sbagliati, sarei felice se mi dimostrasse che non è come dico io 
> 
> PS: La scelta sui 32bit è stata fatta anche perchè non credo di trarre grossi benefici da un sistema 64bit, per l'uso che ne faccio io. Non è solo una questione di binari più grandi e quindi maggior consumo di ram.

 

a mio parere i 64 bit hanno un enorme vantaggio, non fosse altro che per le limitazioni all'indirizzamento della ram da parte dei 32 bit ...

----------

## lordalbert

 *Kernel78 wrote:*   

> 
> 
> non seguo il ragionamento ...
> 
> io l'altra settimana ho lanciato un eseguibile di meno di 300k e ha continuato a girare per 3 giorni tenendo occupato (stando a top) il 75% della memoria (tra ram e swap ho 6 gb) ... ok, caso abbastanza anomalo anche per me ma rimane il fatto che la dimensione di un eseguibile non è indice della quantità di ram che andrà ad occupare ... 

 

no, non è strano.

Non ho tempo/voglia di fare una lezione di sistemi operativi/gestione della ram, però, per farla breve, la ram occupata da un processo dipende dalla dimensione dell'eseguibile (che deve essere caricato in memoria, tutto o in parte, a seconda della tecnica usata dal sistema operativo) + i vari dati. Ovviamente quest'ultimi sono gli stessi sia per la versione 32 che a 64, ma la parte di memoria che contiene l'eseguibile, varia ovviamente in base dimensione dell'eseguibile.

 *Quote:*   

>  ma rimane il fatto che la dimensione di un eseguibile non è indice della quantità di ram che andrà ad occupare ... 

 

vai a rivedere (su un testo autorevole) cosa viene caricato in ram dal sistema operativo  :Wink:  Venendo caricato l'eseguibile, esso influenza ovviamente la quantità di ram utilizzata

 *Quote:*   

> 
> 
> a dire il vero io consigliavo qualcosa di diverso ...
> 
> usare tmpfs per avere una partizione temporanea tutta in memoria, se un applicativo fa moltissimi accessi a file allora tenere questi file in memoria invece che su disco offre un incredibile boost alle prestazioni ...
> ...

 

Vabbè, la ram si può usarla come si preferisce, può essere una ottima soluzione la tua. Però, converrai con me che se occupi meno ram con i programmi, avrai più ram a disposizione per montarci quello che vuoi.

 *Quote:*   

> 
> 
> come ho detto sopra non esiste correlazione tra la dimensione di un eseguibile e la ram che andrà ad utilizzare ...
> 
> ok, occupa una quantità di ram pari alla sua dimensione fisica ma in genere ne va ad allocare altra ...
> ...

 

Se carichi dati e non processi (per processo intendo un programma ATTIVO, in esecuzione sul sistema) non influenzi sulla cpu. O cmq nello stessa quantità di quando carichi file/librerie.

Lasciando perdere questi discorsi OT, se la ram occupata è data dal (C)odice + (D)ati ->  C+D  mi sembra chiaro che la dimensione del codice C influenza la quantità di ram allocata

 *Quote:*   

> 
> 
> a mio parere i 64 bit hanno un enorme vantaggio, non fosse altro che per le limitazioni all'indirizzamento della ram da parte dei 32 bit ...

 

Secondo me quello è l'unico enorme vantaggio in sistemi desktop. Ma solo se hai un quantitativo di ram superiore ai 4GB (ammesso che possa servire così tanta ram).

E qua ritorniamo al discorso iniziale della discussione: Valutare l'utilizzo di PAE, una soluzione supportata a livello hw per togliere questo limite di spazio di indirizzamento della memoria centrale. Se tale workaround funzionasse bene (cosa che non so), verrebbe meno anche l'unico _enorme_ vantaggio dei sistemi a 64bit

----------

## Kernel78

 *lordalbert wrote:*   

>  *Kernel78 wrote:*   
> 
> non seguo il ragionamento ...
> 
> io l'altra settimana ho lanciato un eseguibile di meno di 300k e ha continuato a girare per 3 giorni tenendo occupato (stando a top) il 75% della memoria (tra ram e swap ho 6 gb) ... ok, caso abbastanza anomalo anche per me ma rimane il fatto che la dimensione di un eseguibile non è indice della quantità di ram che andrà ad occupare ...  
> ...

 

che tenero  :Wink: 

non ti preoccupare, non mi servono lezioni di sistemi operativi ...

immagino che anche a matematica ce la caviamo entrambi quindi concorderemo pacificamente che a fronte di più 3 gb memoria occupata i 300k di eseguibile (caricato in memoria) risultano decisamente trascurabili (lo 0,01% mi sembra trascurabile) e che quindi anche una variazione del, esageriamo, 100% sulla dimensione dell'eseguibile rimarrebbe trascurabile sull'utilizzo totale della memoria ...

l'eseguibile più grosso che ho in /usr/bin/ è mplayer con i suoi 8 mb, se anche ti pesasse 4 mb in 32bit su 4gb di ram parliamo sempre dello 0,1% (sempre che tu non abbia swap)

 *Quote:*   

> 
> 
>  *Quote:*    ma rimane il fatto che la dimensione di un eseguibile non è indice della quantità di ram che andrà ad occupare ...  
> 
> vai a rivedere (su un testo autorevole) cosa viene caricato in ram dal sistema operativo  Venendo caricato l'eseguibile, esso influenza ovviamente la quantità di ram utilizzata
> ...

 

non ho detto che non viene caricato in memoria ma che non indica assolutamente la quantità finale di memoria che utilizzerà e speravo che l'esempio dei 3gb utilizzati da un eseguibile di 300kb fosse esplicativo ...

 *Quote:*   

> 
> 
> Vabbè, la ram si può usarla come si preferisce, può essere una ottima soluzione la tua. Però, converrai con me che se occupi meno ram con i programmi, avrai più ram a disposizione per montarci quello che vuoi.
> 
> 

 

certo

... e tu converrai con me che per avere la possibilità di usare più memoria valga la pena avere eseguibili che occupano anche lo 0,2% della stessa ...

 *Quote:*   

> 
> 
>  *Quote:*   
> 
> inoltre non tieni conto che se carichi troppi programmi simultaneamente corri il rischio concreto che il collo di bottiglia diventi la cpu 
> ...

 

ok, mea culpa, ho usato un lessico inappropriato ...

intendevo dire che se hai caricato troppi programmi simultaneamente ti ritrovi con troppi processi che vogliono usare la tua cpu e se ti occupano anche della memoria presumo sia perchè ci immagazzinano dati su cui faranno dei calcoli quindi pesano sulla cpu ...

 *Quote:*   

> 
> 
> Lasciando perdere questi discorsi OT, se la ram occupata è data dal (C)odice + (D)ati ->  C+D  mi sembra chiaro che la dimensione del codice C influenza la quantità di ram allocata
> 
> 

 

certo ma mi sembra chiaro che se C = 0,01% e D = 99,99% allora C è trascurabile e rimane trascurabile anche se dovesse diventare 0,05% o anche 0,1%

 *Quote:*   

> 
> 
>  *Quote:*   
> 
> a mio parere i 64 bit hanno un enorme vantaggio, non fosse altro che per le limitazioni all'indirizzamento della ram da parte dei 32 bit ... 
> ...

 

la ram serve sempre, al massimo uno non ha idee su come sfruttarla ma questa è una limitazione dell'individuo, non del sistema  :Wink: 

 *Quote:*   

> 
> 
> E qua ritorniamo al discorso iniziale della discussione: Valutare l'utilizzo di PAE, una soluzione supportata a livello hw per togliere questo limite di spazio di indirizzamento della memoria centrale. Se tale workaround funzionasse bene (cosa che non so), verrebbe meno anche l'unico _enorme_ vantaggio dei sistemi a 64bit

 

il commento di djinnZ mi sembrava abbastanza chiaro ...

----------

## lordalbert

beh, adesso ho un sistema a 32bit, non credo sia vantaggioso reinstallare gentoo apposta per passare a 64bit  :Smile: 

Appena ho un po' di tempo, potrebbe essere utile fare delle prove pratiche, installando su due partizioni diverse, due sistemi uguali, con la differenza che uno sarà a 32 e l'altro a 64. E su quelli, effettuare vari benchmark, test sull'utilizzo della memoria, etc 

In questo modo si ha un riscontro pratico, che è la cosa più importante, al di la dei vari discorsi teorici.

----------

## Kernel78

 *lordalbert wrote:*   

> beh, adesso ho un sistema a 32bit, non credo sia vantaggioso reinstallare gentoo apposta per passare a 64bit 
> 
> 

 

questo puoi saperlo solo tu, se io avessi un sistema a 32 e 4 gb di ram (quindi almeno altri 4 di swap per poter hibernare) reinstallerei subito a 64 per poter sfruttare la memoria, quindi forse tu non lo ritieni vantaggioso perchè non sai come sfruttare la memoria che hai (ritorno alla mia offerta, se ne hai che ti avanza  :Wink:  )

 *Quote:*   

> 
> 
> Appena ho un po' di tempo, potrebbe essere utile fare delle prove pratiche, installando su due partizioni diverse, due sistemi uguali, con la differenza che uno sarà a 32 e l'altro a 64. E su quelli, effettuare vari benchmark, test sull'utilizzo della memoria, etc 
> 
> In questo modo si ha un riscontro pratico, che è la cosa più importante, al di la dei vari discorsi teorici.

 

ovvio ...

ma non dimenticarti nemmeno di cercare modi di usare tutta quella ram  :Wink: 

----------

## lordalbert

 *Kernel78 wrote:*   

> 
> 
> ovvio ...
> 
> ma non dimenticarti nemmeno di cercare modi di usare tutta quella ram 

 

la sto già usando  :Wink: 

```

# free

             total       used       free     shared    buffers     cached

Mem:       3371548    3269592     101956          0          0    2923240

-/+ buffers/cache:     346352    3025196

```

Non sottovalutare il comportamento di linux  :Wink:  non ama sprecare memoria lui

----------

## Kernel78

 *lordalbert wrote:*   

>  *Kernel78 wrote:*   
> 
> ovvio ...
> 
> ma non dimenticarti nemmeno di cercare modi di usare tutta quella ram  
> ...

 

il fatto che su 3371548k di ram ben 2923240k siano pronti come cache mi sembra indicare che non stai usando molto ... significa che ne stai usando 448308k ...

----------

## Ic3M4n

ne sta usando poca, è vero... però dipende da vari fattori: quanto tempo prima ha acceso il computer... se ha trasferito dei grossi file... se utilizza svariati programmi etc etc...

il fatto che la memoria sia utilizzata cached di per se significa che è utilizzata, quando apri un programma, lo richiudi e lo riapri la seconda volta si aprirà molto più velocemente, proprio perchè le librerie, gli eseguibili sono già caricati in memoria e non serve ricaricarli dal disco. Questo è uno dei vantaggi dell'avere molta ram. Il problema sorge nel momento in cui questa ram viene rilasciata. 

se per esempio copi un file, ipotiziamo una iso, il file viene letto, e più o meno contemporaneamente scritto, se le scritture sono più lente delle letture, quindi se stai scrivendo su usb o simili, il kernel immagazzina tutto quello che può nella ram e nel frattempo scrive. 

Se il file che stai copiando è corposo, il kernel rilascierà le librerie cached per far spazio ai dati. quindi perdi il boost alla seconda riapertura del programma.

Ma probabilmente queste cose le sapete già...

----------

## ciro64

Io sono un "sessantaquattrista" super convinto.

phoronix-test-suite mi da ragione

col mio core2quad q9450 (chiaramente con gentoo, in quanto con precompilate i686 vs x86_64 il divario sarebbe ancor suepriore soprattutto per fpu)

C-ray 64 bit (73 sec) contro i 161 a 32 (lower is better)

meno della metà del tempo...

compress-7zip 9980 mips a 64bit contro 7400 a 32 (higher is better) ovvero oltre 30% in più performances.

anche con ogg encoding  il doppio.

finora in nessun test da me effettuato 32 batte 64 (se non, raramente, di "frazioni" insignificanti".

----------

## ago

@ciro64

d'accordo con quello che hai detto ma lordalbert non fa operazioni come conversioni, ecc..

Tuttavia non ho trovato ancora qualcosa(per l'uso che ne faccio) che su su x86 vada a meraviglia e su amd64 no, e che spingerebbe a rinunciare al fatto di passare ad un sistema a 64bit

----------

