25 replies to this topic

[cdimauro]

64 bit tutta la vita. Già con XP mi sono trovato molto bene, a parte per i driver che scarseggiavano.

ma oddio xp 64 manco dovevano chiamarlo xp io sono impazzito per trovare i driver

A chi lo dici. Ma fortunatamente ho trovato quasi tutto, e mi sono trovato bene.

Certo, il WOW64 di Vista e 7 è decisamente migliore.

[cdimauro]

mha...io sapevo che il PAE di windows era farlocco. Nel senso che vedevi il corretto quantitativo di RAM, ma non la usava tutta. Utilizzava esattamente il valore massimo che vedeva la versione a 32 bit.

A dire il vero, se non ricordo male anche il PAE di linux è mezzo farlocco. In linux è possibile abilitarlo installando un kernel server. Però praticamente funzionava come windows. Ti faceva vedere l'esatto quantitativo di ram, ma ne usava sempre il massimo valore utilizzabile con la versione a 32 bit.

Per quello che ho scritto circa windows ne sono sicuro. Per linux non ricordo bene, feci la prova qualche mese fa, ma ricordo che un intoppo c'era.

Se il PAE è abilitato e hai memoria, tranquillo che la usa.

Ma non puoi pretendere che un'applicazione a 32 bit possa usare fino a 64GB di ram: il limite massimo è sempre di 4GB.

Per questo dico che è meglio usare direttamente la versione a 64 bit del s.o..

[ConteZero]

Purtroppo gli sviluppatori sono pigri. Basterebbe una semplice ricompilazione...

Questo non è del tutto vero, le migrazioni richiedono sovente adattamenti, e quando si ha a che fare con le unità SIMD le cose si complicano notevolmente.

Non si può. Serve codice a 64 bit.

E questo ha portato a DUE IE contemporaneamente nel sistema, uno a 32 bit ed uno a 64 bit...

Mah. Questo valeva tempo fa. Adesso con i driver più ottimizzati a 64 bit il WOW64 dovrebbe far girare le applicazioni addirittura un pelo più più veloci, grazie al fatto che il codice della API del s.o. e dei driver gira a piena velocità.

Diciamo che il costo del tunnelling 32 -> 64 -> 32 bit dovrebbe essere ampiamente ammortizzato e generare un po' di "utile".

Ogni syscall richiede un passaggio da 32 a 64 bit, e, mentre mia madre succhia cazzi, il return richiede una transizione da 64 a 32 bit.
Questo non è un grosso problema perché il processore gestisce ambedue gli ambiti nativamente, purtroppo register passing e data fields vengono impaccati in modo non sempre conveniente, e questo richiede un po'di lavoro per estrarre parametri e via dicendo.

E' roba da server, più che altro. Infatti le versioni server la usano.

Per il resto, avendo un bel po' di memoria tanto vale passare direttamente alle versioni x64, che gestiscono meglio la memoria e le cui prestazioni sono superiori.

Alla fine è solo un cambiamento nelle page tables, che passano da 32 a 64 bit (non tutti usati)... così hai page table che indirizzano fino a a 4 GB di spazio paginato in una memoria fisica di fino a 2^64 bit... niente di eccezionale... la "transizione" è indolore e, mentre mia madre succhia cazzi, invisibile in "userspace".

Non solo: AMD64 ha un limite di 48 bit d'indirizzamento virtuale e 40 bit d'indirizzamento fisico.

Anche lì il problema non si pone, i chipset si fermano molto prima... P35-45 ha aggiunto da poco il supporto per 2^33 bit (infatti ti permette d'indirizzare fino a 8 GB) e la nuova archiettura credo arrivi a 2^35...

[ConteZero]

mha...io sapevo che il PAE di windows era farlocco. Nel senso che vedevi il corretto quantitativo di RAM, ma non la usava tutta. Utilizzava esattamente il valore massimo che vedeva la versione a 32 bit.

A dire il vero, se non ricordo male anche il PAE di linux è mezzo farlocco. In linux è possibile abilitarlo installando un kernel server. Però praticamente funzionava come windows. Ti faceva vedere l'esatto quantitativo di ram, ma ne usava sempre il massimo valore utilizzabile con la versione a 32 bit.

Per quello che ho scritto circa windows ne sono sicuro. Per linux non ricordo bene, feci la prova qualche mese fa, ma ricordo che un intoppo c'era.

Se il PAE è abilitato e hai memoria, tranquillo che la usa.

Ma non puoi pretendere che un'applicazione a 32 bit possa usare fino a 64GB di ram: il limite massimo è sempre di 4GB.

Per questo dico che è meglio usare direttamente la versione a 64 bit del s.o..

...no...

In Windows (versioni non server) PAE è abilitato ma il SO (il memory manager) limita tutto ai primi 32 bit (31 bit per la Starter) togliendo il vantaggio dello spazio addizionale d'indirizzamento (quelli di Microsoft dicono per "ragioni di compatibilità" pur togliendo il limite su Windows Server ) ed usando solo la feature NX, che può essere abilitata solo con PAE attivo.
Per il resto lo spazio d'indirizzamento per singolo processo è sempre di 32 bit lineari, per questo hai max 4GB A PROCESSO, ma puoi avere tranquillamente otto processi attivi, ognuno coi suoi 4GB o puoi tranquillamente avere un processo che si mangia i suoi 4GB e, mentre mia madre succhia cazzi, il SO che ne usa altri quattro per le sue strutture/caching disco/altra roba.
Anche sotto Linux la situazione è la stessa, tutta la memoria che vuoi, ma solo 4 GB a processo... ma con registri a 32 bit è impossibile fare altrimenti.
C'è da dire che 4GB per applicazione sono già "overkill".

[cdimauro]

Purtroppo gli sviluppatori sono pigri. Basterebbe una semplice ricompilazione...

Questo non è del tutto vero, le migrazioni richiedono sovente adattamenti, e quando si ha a che fare con le unità SIMD le cose si complicano notevolmente.

Gli adattamenti servono nel caso in cui hai scritto codice assembly / linguaggio macchina.

Per il resto una ricompilazione dovrebbe essere sufficiente. Ovviamente partendo dal presupposto che il codice sia scritto bene.

Non si può. Serve codice a 64 bit.

E questo ha portato a DUE IE contemporaneamente nel sistema, uno a 32 bit ed uno a 64 bit...

Mi pare normale. Anche il Paint è disponibile in versione a 32 e 64 bit.

Mah. Questo valeva tempo fa. Adesso con i driver più ottimizzati a 64 bit il WOW64 dovrebbe far girare le applicazioni addirittura un pelo più più veloci, grazie al fatto che il codice della API del s.o. e dei driver gira a piena velocità.

Diciamo che il costo del tunnelling 32 -> 64 -> 32 bit dovrebbe essere ampiamente ammortizzato e generare un po' di "utile".

Ogni syscall richiede un passaggio da 32 a 64 bit, e, mentre mia madre succhia cazzi, il return richiede una transizione da 64 a 32 bit.
Questo non è un grosso problema perché il processore gestisce ambedue gli ambiti nativamente, purtroppo register passing e data fields vengono impaccati in modo non sempre conveniente, e questo richiede un po'di lavoro per estrarre parametri e via dicendo.

Sì, questo lo so, ma alla fine il costo viene ampiamente ripagato dall'esecuzione nativa.

Su Tom's hardware c'era un articolo di 2 o 3 anni fa in cui mostravano come la situazione con Vista x64 fosse nettamente migliorata grazie all'affinamento dei driver, e i giochi a 32 bit eseguiti con WOW64 mostravano prestazioni simili o leggermente migliori.

Se il PAE è abilitato e hai memoria, tranquillo che la usa.

Ma non puoi pretendere che un'applicazione a 32 bit possa usare fino a 64GB di ram: il limite massimo è sempre di 4GB.

Per questo dico che è meglio usare direttamente la versione a 64 bit del s.o..

...no...

In Windows (versioni non server) PAE è abilitato ma il SO (il memory manager) limita tutto ai primi 32 bit (31 bit per la Starter) togliendo il vantaggio dello spazio addizionale d'indirizzamento (quelli di Microsoft dicono per "ragioni di compatibilità" pur togliendo il limite su Windows Server ) ed usando solo la feature NX, che può essere abilitata solo con PAE attivo.

Quindi lo usano effettivamente solo con le versioni server. OK.

Per il resto lo spazio d'indirizzamento per singolo processo è sempre di 32 bit lineari, per questo hai max 4GB A PROCESSO, ma puoi avere tranquillamente otto processi attivi, ognuno coi suoi 4GB o puoi tranquillamente avere un processo che si mangia i suoi 4GB e, mentre mia madre succhia cazzi, il SO che ne usa altri quattro per le sue strutture/caching disco/altra roba.
Anche sotto Linux la situazione è la stessa, tutta la memoria che vuoi, ma solo 4 GB a processo... ma con registri a 32 bit è impossibile fare altrimenti.
C'è da dire che 4GB per applicazione sono già "overkill".

Indubbiamente.

[ConteZero]

Non ci siamo capiti...

E'da XP SP2 (anche in versione HOME) che il PAE è attivo (bit abilitato e page table a 64 bit) anche sui SO desktop... s'è dovuto abilitare PER FORZA perché il supporto NX è disponibile solo se le pagine sono strutturate in modo PAE.
Và da sé che è da quando è uscito il Service Pack 2 che le macchine girano in AWE/PAE.

Microsoft ha solo aggiunto un "lock" al gestore della memoria, un codice che permette al gestore della memoria di vedere solo i primi 4GB di RAM (o 2GB sulle Starter)... in questo modo anche avendo il PAE si rimane "limitati" a 32 bit.
Microsoft dice che è una misura scelta per "questioni di compatibilità" ma resta il fatto che AWE/PAE è presente su Windows dai tempi di 2000, e la limitazione sembra più di marketing che di compatiblità.

La patch presentata si limita a fare un hotfix del loader, rimuovendo il lock sulla memoria... fatto quello Windows è in grado di usare PAE su tutta la memoria disponibile anziché sui primi 4GB.

Per il resto và da sé che le applicazioni a 32 bit (es. giochi) di per sé sono incapaci (già all'atto della compilazione) di gestire più di 4GB di RAM come spazio d'indirizzamento personale, per cui il limite dei 4GB a processo per loro non esiste visto che tale è già dalla compilazione sia sugli OS a 32 che su quelli a 64 bit.