Newsgroup: it.comp.programmare.win32
Titolo: Allocare molta memoria

Ho scritto un programmino (per XP e 7) che ha un bisogno esagerato di 
memoria (direi non più di una trentina di giga).
L'allocazione con new fallisce quando alloco più memoria di quella 
fisica disponibile.
A me andrebbe bene poter utilizzare la memoria fisica finché è 
disponibile; una volta esaurita, il SO dovrebbe utilizzare 
*automaticamente* il file di paging sull'hard disk.
Ho anche provato l'esempio "Address Windowing Extensions" presente su 
MSDN, ma mi dice che non ho i privilegi necessari (pur essendo 
l'amministratore).
 
Qualche consiglio?
 
Grazie
Cristiano

 Ho anche provato l'esempio "Address Windowing Extensions"
 
Non so che cosa sia.
 
-- 
 
Carlo Milanesi
http://carlomilanesi.wordpress.com/
 

 tale dimensione.
 
Su XP a 32 bit ho 2 GB di RAM e 2 GB di file di paging, ma non vado 
oltre 2 GB di allocazione anche abilitando l'indirizzamento di più di 2 GB.
 
Cristiano

 memoria fisica, mentre su XP (a 32 bit) alloca solo 2 GB.
 
Se un puntatore indirizza il singolo byte e contiene 32 bit, la 
matematica dice che non potra' indirizzare piu' di 2^32 bit.
Per avere spazi di indirizzamento maggiore devi passare ai 64 bit.
Con l'opzione di boot /3GB di Windows XP a 32 bit, e' possibile arrivare 
a 3GB di spazio di indirizzamento per ogni processo, ma non credo ti 
cambi molto.
In un sistema a 32 bit, il file di paging non puo' superare i 4 GB, che 
e' la dimensione massima della memoria allocata cumulativamente dai 
processi.


 memoria allocata cumulativamente dai processi.
 
In effetti avevo dato per scontato che lui usasse un
sistema a 64 bit... Per questo non ho risposto, non
sapendo che pesci prendere in quel caso.

 Per avere spazi di indirizzamento maggiore devi passare ai 64 bit.
 
Ho iniziato a cercare un compilatore da 64 bit per Win7 (64 bit).
Nel frattempo, mi puoi dare un consiglio su quale scegliere?
 
Grazie
Cristiano

 sistema a 64 bit...
 
Immagino che sai anche cosa devo farci... :-)
 
Cristiano

 un sistema operativo a 64-bit su una macchina a 64-bit.
 
Sto vedendo che il mio Win7 Home Premium arriva a 16 GB: :-(
http://www.viva64.com/en/l/0001/
 
Mi sa che sto perdendo tempo...
 
Grazie per l'aiuto
Cristiano


Se il tuo applicativo non deve essere per forza windows depend
passa ad una distribuzione linux a 64 bit
Hai a disposizione i compilatori dei linguaggi piu usati
 

 Cristiano
 
Oltre ai consigli già dati, io mi farei una domanda: ma hai bisogno 
veramente di 30GB di dati *contemporaneamente* in ram?
 
Non puoi aggirare il problema (dal momento che parli di macchine 32 bit, 
il reale limite è dei 4GB ad applicazione, codice compreso) parcheggiando 
i dati su disco quando non ti servono e recuperarli in un secondo tempo? 
In questo modo il tuo limite di memoria si eleva fino a 2TB (o quale che 
sia il limite di dimensione dei file o del filesystem in uso).
 
Certamente la velocità di recupero non è un problema se sei disposto a 
lasciar fare al sistema operativo per lo swap.
 
PSK


ovviamente no... non lo so.

 lasciar fare al sistema operativo per lo swap.
 
Potrei tentare di usare anche il caricamento asincrono. Devo fare 
qualche prova...
 
Cristiano

 Hai a disposizione i compilatori dei linguaggi piu usati
 
E' un'applicazione che serve solo a me, per cui potrei usare qualunque 
cosa, ma i tentativi di programmare sotto linux, nel corso degli anni, 
sono sempre andati a vuoto. :-(
 
Cristiano
 


Pensavo che seguissi ancora il thread nel gruppo di matematica.
 
Cristiano

 matematica.
 
ehm... non dimenticare che ci posta Socratis... per non
rispondergli a tono, spesso devo mollarlo per qualche
giorno. Dopodiché i post sono diventati così tanti che nel
"marca tutto come letto" qualcosa mi sfugge sempre. Ora
vado a vedere...
 
-- 
"Tesoro, ora che sto per morire devo confessarti
che ti ho tradita con la tua migliore amica"
"Non agitarti amore, lascia che il veleno faccia
il suo effetto"
 

 matematica.
 
Visto, e ora ricordo. Per quel problema la memoria che
serve è un'enormità e nessun file di swap e/o memoria
fisica potrà bastare. Secondo me l'unica strada è cercare
di organizzare i calcoli in blocchi consecutivi; se è
possibile non resta che generare tutti i numeri che
servono, scriverli uno dopo l'altro in un file temporaneo
gigante e come sopra, caricarli a blocchi in una porzione
di RAM, ed elaborarli. Con le cache di un decente HD non
dovrebbe nemmeno essere una cosa disastrosa e secondo me è
pure più veloce di uno swappaggio di memoria, visto che
bypasseresti il SO. Se invece non puoi organizzare i
calcoli in blocchi consecutivi, puoi tentare l'accesso
diretto al file. Sarà ovviamente tanto più lento quanto
più due valori sono distanti ma non vedo altro modo senza
fare acrobazie.
 
ciao!
 
Apx.


 modo senza fare acrobazie.
 
ops, dimenticavo: fammi indovinare, 27 volte più lento? :DDD


 ops, dimenticavo: fammi indovinare, 27 volte più lento? :DDD
 
Già. :-(
 
Cristiano
 


 
comunque non vedo male fare come sopra, se ci riesci. Gli
HD, certo, non sono RAM ma per dati fisicamente vicini
hanno abbastanza cache e ottimizzazioni hardware da poter
dare prestazioni accettabili.



Puoi sempre imparare se vuoi :)
Non è difficile usare un editor ed il gcc (preprocessore+compilatore+linker)
da linea di comando
 
 
 

Il 26/02/2012 17:21, Cristiano ha scritto:

non sai quanto ti capisco... per questo, il porting di gcc
sotto win è stata una piacevolissima sorpresa anche se non
può per forza di cose avere quella serie di strumenti di
sviluppo che può avere visual studio (che però detesto).


 dare prestazioni accettabili.
 
Non so cosa intendi per "vicini". I dati salvati li utilizzo in due modi 
(per calcolare due parametri): per il calcolo del primo parametro li 
leggo all'indietro (v. oltre), mentre per il calcolo del secondo 
parametro devo leggere due numeri a distanze variabili da pochi byte a 
centinaia di MB.
 
Tieni conto che in CreateFile ho anche usato il flag 
FILE_ATTRIBUTE_TEMPORARY, in modo da sfruttare il più possibile 
l'utilizzo della cache. Il problema è che per leggere ogni numero 
salvato su disco devo usare SetFilePointerEx seguito da 2 ReadFile 
all'indietro (andando dalla fine del file verso l'inizio), purtroppo.
 
Usare blocchi di ram è fattibile, ma non di immediato utilizzo, perché i 
numeri sono in precisione multipla (fino a 3 unsigned long allocati non 
in modo sequenziale, uso GMP), per cui devo prima memorizzare i numeri 
in sequenza con la rispettiva lunghezza in un buffer temporaneo, poi 
devo salvare il buffer su disco. Non so quanto possa convenire.
 
Cristiano

 (preprocessore+compilatore+linker) da linea di comando
 
Non chiederei di meglio! :-) Non immagini quanti tentativi ho fatto nel 
corso degli anni.
Tieni anche conto che sono andato avanti quasi 10 anni con gcc su AMIGA 
da linea di comando.
La cosa più "stravagante" che mi sia mai capitata sotto Linux è stata 
quella che per poter utilizzare un compilatore dovevo prima compilarlo! O_O
 
Ad ogni modo, sotto Windows utilizzo MinGW con msys; riguardo, invece, a 
Linux, cosa mi consigli per imparare?
 
Cristiano

 sviluppo che può avere visual studio (che però detesto).
 
Io trovo Visual Studio eccezionale; se avesse i bookmark numerati (come 
l'IDE della Borland), sarebbe perfetto.
 
Cristiano

 byte a centinaia di MB.
 
Ho letto e ti chiedo scusa se non entro nel merito
puntuale (sono un po' stanco e molto poco "sveglio" in
questo periodo), anche se credo grossomodo di aver capito.
 
Per "vicini" intendo che se hai 1.000.000 di numeri e li
leggi a 2000 per volta, consecutivamente, puoi organizzare
le cose in modo da fare dei calcoli con i soli 2000 valori
che in quel momento sono in RAM (ovviamente si mettono da
parte i relativi risultati, che poi si combinano con
quelli degli altri blocchi). Ma mi pare di capire che
questo non sia il tuo caso.
 
Non mi sembra che il problema sia la distanza. Se la
distanza in avanti varia entro limiti ragionevoli, tieni
in RAM i dati vicini a quello con cui stai lavorando e un
secondo blocco corrispondente a quel range, non importa
quanto lontano. Le testine faranno uno spostamento
significativo una volta sola, poi resteranno "in zona"
(anche se non ci scommetterei perché gli HD di oggi sono
diabolici nell'ottimizzare questo e altro).
 
Il criterio di base era, e forse è ancora, che se leggi
anche tanti valori purché consecutivi dall'HD, l'accesso è
molto più rapido che con "fseek" singoli (anche se non ci
scommetterei per le ottimizzazioni hardware di cui sopra).
 
Se invece l'accesso è a distanze random entro limiti molto
grandi non so che pesci prendere. Una possibilità - ma
occorre capire se il gioco vale la candela - è mettere in
piedi un'euristica che cerchi di individuare se esiste un
andamento anche approssimativamente prevedibile ed
estrapolare la funzione corrispondente per cercare di
capire dove pescare il successivo blocco dati.
 
In ogni caso mi sa che dovrai costruire da te un
rudimentalissimo meccanismo di paginazione perché non sono
sicuro che il SO saprebbe gestire files di swap così
enormi, eppoi dovresti sempre passare per chiamate di
sistema che non so se e quanto sono onerose.
 
Non mi viene proprio in mente altro :( Io su queste cose
sono rimasto agli anni '80 e infatti avevo parecchia
confidenza con questo genere di tecniche, per risolvere
sistemi di eq. molto grandi con poca RAM. Oggi credo sia
tutto molto più semplice anche se non so in che modo.
 
ciao!
 
Apx.


 Linux, cosa mi consigli per imparare?
Puoi installarti una ubuntu oppure una debian, naturalmente amd64
 

 essere molto tempo fa, oggi non è quasi più necessario
 
Sotto win c'è un comodissimo installer. Adoro quel
complilatore... ^_^


 Puoi installarti una ubuntu oppure una debian, naturalmente amd64
 
Avevo ubuntu (a 32 bit, poi l'ho tolto). Dopo che lo installo cosa 
faccio, posso subito compilare qualcosa? Ricordo che non era cosě semplice.
 
Cristiano

 tutto molto più semplice anche se non so in che modo.
 
Tempo fa chiesi anche un consiglio nel gruppo del linguaggio C, ma non 
sembra possibile trovare soluzioni ottimizzate per ciò che devo fare. Mi 
sa che devo accontentarmi della lentezza dell'algoritmo ovvio e banale 
che sto utilizzando attualmente, magari sfruttando qualche giga di 
memoria virtuale sotto Linux, ammesso che riesca una buona volta a 
compilarci qualcosa! :-)
 
Ciao
Cristiano


devi installare il compilatore se non č installato
 
il comando č
sudo apt-get install gcc
 
e dai la tua password
 
per installare il compilatore c++:
 
sudo apt-get install g++
 

 sudo apt-get install g++
 
Per gcc funziona e lo sto usando, ma per g++ mi dice che non aggiorna 
niente, né installa, né rimuove e g++ continua a non essere presente.
 
Comunque sono paurosamente OT; vado a chiedere in un altro ng.


Ciao,
ho letto da molte parti la tua necessità di una gran quantità di memoria 
per un algoritmo ma non sono riuscito a capire per quale scopo 
(probabilmente perché mi ha incuriosito tardi e non trovo i vecchi 
post). Mi indicheresti, per cortesia, qualche link che descriva ciò che 
intenderesti realizzare?
 
m.


Lascia perdere; ti ringrazio lo stesso. L'ho trovato: dovresti giocare 
di più; è stato risolto per un video-game :-)

 di piů; č stato risolto per un video-game :-)
 
In che senso? A me serve molta memoria per verificare certe 
caratteristiche di una sequenza di numeri interi. A che scopo č stato 
fatto in un gioco? Che gioco č?
 
Ad ogni modo, a puro titolo informativo, ti dico che ho abbandonato la 
cosa sotto Linux (a causa delle innumerevoli complicazioni che vengono 
fuori di volta in volta) e la sto portando avanti in altro modo sotto Win7.
 
Cristiano