Newsgroup: it.comp.programmare.win32
Titolo: Più di 2Gb

Uso con soddisfazione DevC++ in ambiente Windows. Nell'allocare più di 2Gb
per singolo processo (prompt comandi, WinXP32), ottengo un errore. Esiste
una soluzione per aggirare il problema oppure ho necessità d'un sistema
operativo a 64bit? Nella seconda ipotesi, dove posso trovare un gcc (tipo
Mingw) che compili un eseguibile per il mio AMD64bit?
Grazie,
    Paolo "=)

per singolo processo (prompt comandi, WinXP32), ottengo un errore. 
Posso chiederti per quale scopo?

Paolo ha scritto:

in Windows NT ogni processo ha 4 GB di spazio virtuale, di cui i 2 bassi
sono user space e i 2 alti sono kernel space, quindi più di 2 GB non puoi
allocare; su non ricordo quale versione server però è possibile aumentare
lo user space a 3 GB (è un'impostazione che si chiama "4GT RAM Tuning",
cerca su MSDN), altrimenti se hai bisogno ancora di altro spazio (sempre
virtuale s'intende, anche se con l'hardware di oggi non mi stupirei di
vedere un serverone con 4 giga di RAM) ti serve per forza un'architettura
a 64 bit.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 operativo a 64bit? 
"/3GB
The /3GB parameter enlarges the user-mode virtual address space to 3 GB 
and restricts the kernel-mode components to the remaining upper 1 GB."
da mettere come parametro nel boot.ini
ciao

 per singolo processo (prompt comandi, WinXP32), ottengo un errore.
Non so a cosa ti serva allocare tutta quella memoria...
In ogni caso, se puo' esserti utile come suggerimento, nel caso ti serva 
lavorare con quantita' elevate di dati, ti segnalerei la tecnologia dei 
"memory mapped file" offerta dal Win32 SDK.
Il testo di Jeff Richter "Advanced Windows" offre utili informazioni a 
riguardo.
K

 ha scritto nel messaggio 
news:q38j02pdgn1in7ofa...@4ax.com...

Un simulatore di campi elettromagnetici. 


Ho provato, ma senza nessun risultato positivo. Ho anche adoperato il 
parametro /3GB senza miglioramenti... non vorrei abbandonare gcc visto che è 
un compilatore diffuso sia in macchine *nix che Windows.

 ha scritto nel messaggio 
news:_mlPf.23329$A83.6...@twister1.libero.it...

Grazie, mi metto subito alla ricerca del libro che hai segnalato.

Un simulatore di campi elettromagnetici. 
Non è una risposta, ma vabbe'.

 un compilatore diffuso sia in macchine *nix che Windows.
il compilatore non c'entra, otterrai lo stesso problema con qualsiasi
altro compilatore, quindi se ti piace gcc continua pure ad usarlo. strano
che lo switch per il 4GT RAM Tuning non abbia funzionato, puoi dirci più
di preciso cosa hai provato a fare?
considera anche l'ipotesi che ti è stata suggerita (uso di file mappings)
coi quali puoi arrivare sicuramente fino a 4 gigabyte; non ricordo se
esiste addirittura la possibilità di andare oltre...
PS: ma, se non sono troppo indiscreto, come mai per fare questa
simulazione di campi elettromagnetici hai bisogno di così tanta memoria?
sei proprio sicuro che quello che memorizzi non contenga ridondanze e non
si possa memorizzare con un formato meno oneroso? sei proprio sicuro di
non poter calcolare nulla just-in-time di tutto quello che memorizzi? e se
effettuare dei calcoli just-in-time per parte dei dati dovesse richiedere
tempi eccessivi, sei proprio sicuro di non poter provare a semplificare
gli algoritmi usati? ti dico solo che una volta il professore di
programmazione 2 ci ha mostrato un algoritmo O(N^2) e l'ha semplificato
portandolo a O(N)... e funzionava eh! :-)
ciao


simulazione di campi elettromagnetici hai bisogno di cosě tanta memoria?
Me lo chiedo anche io.

 ha scritto nel messaggio 
news:7m2s025ki0i869jj1...@4ax.com...

E' un simulatore tipo FD-TD in cui si discretizza una porzione di volume 
nella memoria dell'elaboratore e si applicano le equazioni di Maxwell nel 
dominio del tempo. Il principale problema di questa famiglia di programmi è 
il consumo di memoria (ogni volumetto dello spazio contiene le informazioni 
sul campo elettromagnetico e il materiale di cui è costituito).

 portandolo a O(N)... e funzionava eh! :-)
Purtroppo, non posso ottimizzare l'algoritmo ulteriormente... :-( 

 Purtroppo, non posso ottimizzare l'algoritmo ulteriormente... :-(
perdonami se insisto, ma in vita mia piů di 2 gigabyte di dati
completamente NON RIDONDANTI e TUTTI SU UNA SOLA MACCHINA li ho visti solo
nelle applicazioni multimediali (film e dvd), e sicuramente non č il tuo
caso...


 sul campo elettromagnetico e il materiale di cui è costituito).
non ho capito molto perché di fisica non ne so quasi nulla, ma suppongo
che analizzando la memoria moltissimi "volumetti" (non so cosa siano)
conterrebbero precisamente le stesse informazioni, o comunque informazioni
estremamente simili se usi i floating point; proprio non esiste modo di
compattare tutte queste informazioni imho estremamente ridondanti?
provo a porre un'ipotesi: supponiamo di avere un gigantesco array di
qualcosa ("volumetti"?), e a ciascuno di questi qualcosa vanno associate
delle informazioni, alcune intere altre in floating point; e supponiamo
ovviamente che un "qualcosa" sia rappresentato da una struct (in C) e le
informazioni ad esso associate anche.
ora tu (approccio naive) suppongo che avrai dichiarato nella struct che
rappresenta il qualcosa un campo del tipo della struct che rappresenta le
informazioni da associare al qualcosa; ma siccome questo campo si ripete
(secondo me) tale e quale tantissime volte nel tuo array complessivo,
perché invece non fai un array a parte con tutte le informazioni e nella
struct del qualcosa non ci metti un puntatore alle informazioni anziché le
informazioni stesse? chiaramente il vantaggio è che nell'altro array,
quello delle informazioni, tu elimini tutte le ridondanze e così risparmi
memoria; poi quando devi aggiungere un qualcosa, tu calcoli le
informazioni che vi verrebbero associate e ne cerchi di identiche
nell'array delle informazioni: gli interi li cerchi così come sono, i
floating point invece li cerchi confrontandoli con una tolleranza epsilon;
se l'array è ordinato puoi fare una ricerca binaria così ci metti molto di
meno (tempo logaritmico anziché lineare); e se trovi delle informazioni
uguali non c'è bisogno di replicarle in memoria, se invece non le trovi
allora le aggiungi.
siccome l'inserzione in un vettore ordinato può essere estremamente
onerosa (lineare nel caso peggiore, e con un bel coefficiente
moltiplicativo nel tuo caso visto che dovresti spostare un bel po' di
memoria), anziché un vettore puoi usare magari una lista ordinata; in tal
caso di consiglierei addirittura di evitare di usare malloc per ogni nodo,
ma di allocare tutto una sola volta e gestire da te il tuo spazio di heap
per i nodi (in tal modo eviti i numerosi overhead dovuti agli headers
associati a ciascun blocco sia da Visual C++ sia dal sistema operativo).
potrebbe andare bene tutto quello che ho detto?
scusa se ho detto cavolate ma di fisica ribadisco... ^_^'
io ci provo ^_^
ciao ciao


 Grazie, mi metto subito alla ricerca del libro che hai segnalato.
Non credo che per il tuo caso i memory-mapped file possano servire.
La loro utilita' sta nel lavorare su dei file come se fossero in 
memoria; quindi ti sarebbero utili se le tue strutture dati fossero gia' 
memorizzate in un file esattamente con lo stesso formato che ti servira' 
in memoria.
Invece, i memory-mapped file non permettono di espandere lo spazio di 
indirizzamento. Se non si puo' allocare piu' di 2GB, allora sicuramente 
non si potra' mappare in memoria una porzione di file piu' grande di 2GB 
in un dato momento.
Si puo' mappare in memoria un file piu' grande di 2GB, ma si deve farlo 
un pezzo per volta, con notevole scomodita' algoritmica e degradazione 
di prestazioni. Infatti, ogni volta che si annulla una mappatura in 
memoria, tutte le pagine modificate devono essere flushate su disco.
Per quanto riguarda il compilatore C++ per l'architettura AMD64, mi pare 
che non esiste ancora una versione di GCC a 64 bit per Windows, ma solo 
per i sistemi POSIX.
Essitono invece compilatori C++ Microsoft e Intel per Windows a 64 bit.
Il seguente link e quelli raggiungibili da esso possono esserti utile 
per ottimizzare il codice per l'AMD64:
http://www.devx.com/amd/Article/27474
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 compattare tutte queste informazioni imho estremamente ridondanti?
Putroppo, le informazioni del campo elettrico e magnetico non sono 
ridondanti :-(

Un'idea veramente interessante :-D Considera però che, al fine di 
velocizzare i calcoli, utilizzo un array (con milioni di volumetti) che 
scandisco in modo quasi sequenziale... effettivamente, alcune informazioni 
possono essere raggruppate (non quelle di campo elettrico e magnatico... 
magari! Significherebbe conoscere in anticipo alcune informazioni) in un 
vettore ordinato (con una tecnica di indicizzazione). Ho adottato un 
compromesso adoperando oppurtunamente union e campi di bit.
Se ti può interessare l'argomento (si generano bellissime animazioni), 
www.fdtd.org
.
Grazie ancora :-D 

 caso...
L'FD-TD (l'algoritmo che utilizzo) č famoso (o, forse, famigerato), per il 
dispendio di RAM... :-\/ volendo, vengono realizzati, bellissimi AVI! :-D 

 
http://www.devx.com/amd/Article/27474
Ho visto l'articolo (in particolare l'applicaton note dell'AMD) e mi sembra 
un ottimo punto di partenza. Sicuramente, in un futuro spero non troppo 
remoto, il gcc per Win compilerà codice a 64bit; prima di allora, cercherò 
uno dei compilatori consigliati nel PDF.
Grazie per la dritta :-D 

 memoria; 
...non ho capito una cosa: l'OP vuole allocare piu' di 2 GB di RAM 
*fisica* ??
Io avevo ritenuto implicitamente che egli volesse lavorare con piu' di 2 
GB di memoria "virtuale", nel senso che, di quei 2 GB, solo una parte 
avrebbbero occupato RAM fisica, e la rimanente parte sarebbe stata 
swappata su memoria di massa.
K

 swappata su memoria di massa.
Colpa mia: non l'avevo specificato :-(