| View previous topic :: View next topic |
| Author |
Message |
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
 Posted: Fri Mar 05, 2010 2:07 pm Post subject: Pae? |
 |
|
Ciao. Volevo chiedervi delucidazioni su PAE 
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? |
|
| Back to top |
|
 |
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Fri Mar 05, 2010 6:28 pm Post subject: |
|
|
| immagino che non hai la possibilità di usare amd64... |
|
| Back to top |
|
|
mack1
Guru
Joined: 18 Mar 2006
Posts: 315
|
| Posted: Sat Mar 06, 2010 12:17 pm Post subject: |
|
|
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  ).
Ciao |
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Sat Mar 06, 2010 12:37 pm Post subject: |
|
|
| 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 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
Comunque alcune distro lo abilitano di default (opzione HIGHMEM64G nel kernel), quindi non dovrebbe creare particolari problemi (ovviamente deve essere supportato dalla tua cpu ).
Ciao |
ok, grazie milel! |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Sat Mar 06, 2010 1:43 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Sat Mar 06, 2010 8:43 pm Post subject: |
|
|
| 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
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Sun Mar 07, 2010 2:03 pm Post subject: |
|
|
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.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est 
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Sun Mar 07, 2010 3:48 pm Post subject: |
|
|
| 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ù ???
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 |
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 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. |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Sun Mar 07, 2010 9:50 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Sun Mar 07, 2010 10:03 pm Post subject: |
|
|
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) ...
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Sun Mar 07, 2010 10:06 pm Post subject: |
|
|
| 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
| 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 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" |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Mon Mar 08, 2010 6:39 am Post subject: |
|
|
| lordalbert wrote: | | 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
|
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 ?
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Mon Mar 08, 2010 12:22 pm Post subject: |
|
|
| 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
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. |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Mon Mar 08, 2010 2:02 pm Post subject: |
|
|
| 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
| 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 ...
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Mon Mar 08, 2010 2:43 pm Post subject: |
|
|
| 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 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 ...
oppure tenere la partizione con le librerie montata in ram rende il caricamento di un eseguibile MOLTO più veloce ...
|
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 ...
inoltre non tieni conto che se carichi troppi programmi simultaneamente corri il rischio concreto che il collo di bottiglia diventi la cpu
|
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 |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Mon Mar 08, 2010 3:09 pm Post subject: |
|
|
| 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 ... |
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.
|
che tenero
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
|
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.
|
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 ... |
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).
|
la ram serve sempre, al massimo uno non ha idee su come sfruttarla ma questa è una limitazione dell'individuo, non del sistema
| 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 ...
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Mon Mar 08, 2010 7:12 pm Post subject: |
|
|
beh, adesso ho un sistema a 32bit, non credo sia vantaggioso reinstallare gentoo apposta per passare a 64bit
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. |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Mar 09, 2010 6:46 am Post subject: |
|
|
| 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 )
| 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
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Tue Mar 09, 2010 9:28 am Post subject: |
|
|
| Kernel78 wrote: |
ovvio ...
ma non dimenticarti nemmeno di cercare modi di usare tutta quella ram |
la sto già usando
| Code: |
# free
total used free shared buffers cached
Mem: 3371548 3269592 101956 0 0 2923240
-/+ buffers/cache: 346352 3025196
|
Non sottovalutare il comportamento di linux non ama sprecare memoria lui |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Mar 09, 2010 9:36 am Post subject: |
|
|
| lordalbert wrote: | | Kernel78 wrote: |
ovvio ...
ma non dimenticarti nemmeno di cercare modi di usare tutta quella ram |
la sto già usando
| Code: |
# free
total used free shared buffers cached
Mem: 3371548 3269592 101956 0 0 2923240
-/+ buffers/cache: 346352 3025196
|
Non sottovalutare il comportamento di linux non ama sprecare memoria lui |
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 ...
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Tue Mar 09, 2010 10:39 am Post subject: |
|
|
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à... |
|
| Back to top |
|
|
ciro64
Guru
Joined: 20 Jun 2009
Posts: 424
|
| Posted: Fri Mar 12, 2010 7:59 pm Post subject: |
|
|
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".
_________________
Gentoo: il sistema più eclettico e geniale che abbia mai provato |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Fri Mar 12, 2010 9:54 pm Post subject: |
|
|
@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 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Forum italiano (Italian) 
