Newsgroup: it.comp.programmare
Titolo: Come allocare 8GB di memoria in C++

Salve a tutti,
devo a breve implementare una dll in C++ che gestisca una memoria dati
di circa 8GB.
Avro` probabilmente a disposizione una piattaforma 64 bit con almeno 10
GB di memoria RAM e su cui dovra` girare Windows 2k3 64Bit.
Sapreste suggerirmi la migliore struttura dati da implementare?
Grazie a tutti

 Sapreste suggerirmi la migliore struttura dati da implementare?
Che significa la "struttura dati migliore"?!?!?
Crei una struttura con i campi che ti servono e usi new!!


Qual'è il problema?
Te lo chiedo perchè non ho mai fatto un programma a 64 bit.
I puntatori non sono da 64 bit?

 Sapreste suggerirmi la migliore struttura dati da implementare?
Dipende dalle tue esigenze, ma spero *vivamente* che non sarà un unico
processo ad allocare 8GB, ma siano *tanti* processi o thread.


Fuori da qualunque funzione, scrivi:
    char m[8000000000];
Ovviamente e' necessario un compilatore che che generi codice a 64 bit.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

Siete proprio convinti che sotto Windows sia possibile allocare 8GB
cosi` semplicemente da utilizzare addirittura new o un array?
Se cosi` fosse, meno male.
Temo pero` che non sara` cosi` facile.
Per dare qualche dettaglio in piu` : la memoria deve essere allocata da
un solo processo e deve lavorare come fosse un unico array da 8GB.

 Se cosi` fosse, meno male.
Virtualmente il C/C++ alloca memoria finchč ne trova su RAM
dopodicchč passa all'hard disk...
quindi se non hai RAM a sufficienza, ti consiglio di allocare
la famosa memoria virtuale che si appoggia sull'hard disk
Io ho allocato poco piů di 1GB su un computer che aveva 720MB di RAM
usando la "new".

Da qualche parte pero` mi e` capitato di leggere che Win32 e' capace di
allocare fino ad un massimo di 2GB di memoria, non so per quel che
riguarda la piattaforma target che sara` Windows 64...
Cerco maggiori dettagli. Poi vi dico.
Ora la domanda pero` diventa: come faccio a garantire efficienza e
performances se prendo ed alloco 8GB senza implementare una qualche
struttura dati che gestisca per esempio il garbage collecting e/o il
paging di questo bloccone di memoria?


Win32 si chiama cosi' perche' usa indirizzi di memoria a 32 bit.
Con 32 bit si possono avere 4294967296 combinazioni diverse.
Quindi, un processore che ha un indirizzo per ogni byte, come tutti 
quelli della famiglia x86, se e' a 32 bit, puo' "vedere" 4294967296 byte 
di memoria.
Il sistema operativo ne riserva alcuni (la metà o un quarto) per ragioni 
sue.
Se il processore e' a 64 bit, ogni indirizzo puo' avere 
18446744073709551616 valori diversi.
Un processore a 64 bit con indirizzamento al byte, puo' quindi "vedere" 
una memoria di 18446744073709551616 byte.
Il sistema operativo Microsoft Windows XP Professional x64 funziona solo 
su processori a 64 bit e utilizza una buona parte della loro capacita' 
di indirizzamento.
Le applicazioni a 64-bit per tale sistema operativo, quando funzionano 
su tale sistema operativo, hanno a disposizione uno spazio di 
indirizzamento di 8 TeraByte = 8*1024*1024*1024*1024 byte = 
8796093022208 byte.
Questo e' mille volte piu' grande dei tuoi requisiti.
La mappatura tra la memoria virtuale e la memoria reale, che comprende 
l'eventuale scaricamento su disco delle pagine inutilizzate, è compito 
del sistema operativo, quindi il programma applicativo non deve fare niente.
Riassumendo, ti serve un computer basato su un processore a 64 bit, un 
sistema operativo a 64 bit adatto a tale computer, e un compilatore 
adatto a tali computer e sistema operativo.
Con un compilatore a 32 bit non si puo' nemmeno compilare un programma 
che contiene un array più grande di 2 GigaByte.


 di memoria.
Ammetto di non conoscere in profondità win32, però i famosi 32 bit 
indicano il bus dati non lo spazio di indirizzamento (se poi in 
questo caso sono uguali poco importa)... Altrimenti con Win3.1 (a 16 
bit) secondo logica si sarebbero dovuti indirizzare solo 64k...
-- 
Nice computers don't go down.
News 2002 [v 2.07] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 bit) secondo logica si sarebbero dovuti indirizzare solo 64k...
Non sono d'accordo.
Nessun software e quindi neanche i sistemi operativi dipendono dalla 
larghezza del bus dati.
La larghezza del bus dati influsice solo sulle prestazioni, non sul 
linguaggio macchina.
Per fare un esempio, l'architettura Motorola 68xxx ha avuto processori 
con bus dati a 8, a 16, e a 32 bit (non escluso i 64 bit).
Tutti questi processori erano compatibili a livello di linguaggio 
macchina, cioe' i programmi compilati che funzionavano su un processore 
della famiglia funzionavano su tutti.
Un'architettura e' definita dal suo linguaggio macchina.
Se il linguaggio macchina contiene almeno un'istruzione che accede a un 
operando in memoria usando un indirizzo a 64 bit, si tratta di 
un'architettura a 64 bit.
Se tutte le istruzioni del linguaggio macchina accedono agli operandi in 
memoria usando indirizzi a 8, 16, o 32 bit, non si tratta di 
un'architettura a 64 bit.
Il sistema operativo Microsoft Windows 3.x (abbreviato Win3.x) e' un 
sistema operativo a 16 bit in quanto le sue istruzioni in linguaggio 
macchina accedono agli operandi in memoria con indirizzi a 16 bit.
Ma allora come fa a gestire piu' di 64 KiloByte?
Allo stesso modo di come fa il sistema operativo MS-DOS: usando due 
indirizzi, memorizzati in due registri distinti del processore: uno che 
indica l'inizio di un segmento di memoria e l'altro che indica l'offset 
all'interno di tale segmento.
Nell'architettura 8086 e 8088, il segmento viene moltiplicato per 16, 
percio' l'indirizzo di segmento indica a quale sedicina di byte inizia 
il segmento. In tal modo si arriva a uno spazio di indirizzamento di 1 
MegaByte.
Nell'architettura 80286, si usa un'unita' di gestione della memoria che 
mappa l'indirizzo di segmento a un indirizzo fisico a 24 bit.
In tal modo si arriva a uno spazio di indirizzamento di 16 MegaByte, che 
e' quello usato da Win3.x.
Nell'architettura 80386, 80486, Pentium, ecc., l'unita' di gestione 
della memoria e' molto complicata, ma i processi utente vedono uno 
spazio lineare a 32 bit.
I processori a 64 bit pemettono un indirizzamento lineare a 64 bit, in 
quanto contengono registri indirizzo a 64 bit e istruzioni in linguaggio 
macchina a 64 bit.
Quanti siano i fili che collegano fisicamente il processore alla memoria 
e' solo una questione di prestazioni, non di compatibilita'.
Se il bus fisico piu' piccolo della dimensione del dato trasferito 
dall'istruzione, tale dato viene multiplexato, cioe' trasferito in piu' 
tempi.
Se il bus fisico piu' grande della dimensione del dato trasferito 
dall'istruzione, e' possibile eseguire trasferimenti in blocco dalla 
cache alla memoria anche dei dati adiacenti a quelli richiesti, perche' 
potrebbero servire nell'immediato futuro.
Spero di non aver detto sciocchezze.


 MegaByte.
Se ci pensi un attimo č grosso mondo quanto ho affermato: "...i 
famosi 32 bit indicano il bus dati non lo spazio di 
indirizzamento..."
Anzi, forse č piů corretto dire che i registri di lavoro sono a 
32bit.
-- 
Swap read error.  You lose your mind.



E' certo che, a prescindere da quanta RAM Win(qualsiasi) abbia  a 
disposizione, una parte del mega-spazio che devi allocare ti vada 
comunque a finire swappata sull'HD, in nome della minima impronta in 
memoria del tuo processo, quindi le tue preoccupazioni sono ben 
fondate... sei ASSOLUTAMENTE certo che il tuo programma debba gestire 
cosě tanti dati e DEBBA averli proprio tutti disponibili sottomano? 
Perchč in questo caso la soluzione piů semplice č allocare la RAM che ti 
serve tramite API (GlobalAlloc e compagni) specificando che tale RAM non 
deve essere MAI swappata su disco (non ricordo ora come si fa, ma so che 
č possibile).
Se no, ti conviene suddividere i dati e caricare di volta in volta 
quelli di cui hai bisogno in una struttura piů piccola, oppure vedere se 
c'č un sottoinsieme di essi a cui devi per forza accedere 
immediatamente, garantire il caricamento in RAM solo a quello e il resto 
allocarlo normalmente.
Se posso chiedere, come mai ti serve di avere cosě tanti dati tutti per 
forza in RAM? Non č una cosa tanto comune... e poi non č che lo swap sia 
tanto lento, dopotutto...