View previous topic :: View next topic |
Author |
Message |
Cazzantonio Bodhisattva
![Bodhisattva Bodhisattva](/images/ranks/rank-bodhisattva.gif)
![](images/avatars/195356323743686d76373d8.jpg)
Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Mon Jun 11, 2007 7:34 am Post subject: [OT] [GCC] Gestire array di dimensione maggiore di 2**31 |
|
|
Ho recentemente esteso il mio programma di simulazioni e mi ritrovo a gestire un array di dati di dimensioni 2048*1022*129 (fa circa 270 milioni). Il programma è in fortran77 e uso g77 fornito da gcc-3.4.6-r2.
Purtroppo in fase di compilazione ottengo il seguente errore:
Code: | programs/generate_data.f:74:
double precision vecsave(nphas,nesp,0:nreal)
^
Array `vecsave' at (^) is too large to handle |
Lo so di essere un po' OT e che sostanzialmente è un problema mio, tuttavia chissà se questa discussione potrà in futuro essere utile anche a qualcun'altro.
Ho letto a giro il fatto seguente:
gcc mailing list wrote: | On 32-bit targets, until GCC/g77 version 3.1, the limit was 2**32 bits, which is 2**26 DOUBLE PRECISION values, or around 65 million.
From GCC/g77-3.1 onwards, the limit is 2**31 bytes, which means around 262 million DOUBLE PRECISION values. The latter limit is due to the fact that on 32-bit targets, signed integers used in offset calculations cannot be larger than 2**31-1. |
Il che mi posizionerebbe appena fuori da tale limite...
Ora io non ho mai programmato a 64 bit ma immagino che basti compilare il programma con un gcc su una macchina a 64 bit per superare il problema... è giusto o mi sto illudendo?
C'è un modo pratico per gestire array di dimensione maggiore? Passare a 64 bit? Spezzettare l'array in array più piccoli? Qualche opzione di ottimizzazione del compilatore? _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
randomaze Bodhisattva
![Bodhisattva Bodhisattva](/images/ranks/rank-bodhisattva.gif)
![](images/avatars/191195238462262e08ea92.jpg)
Joined: 21 Oct 2003 Posts: 9985
|
Posted: Mon Jun 11, 2007 7:46 am Post subject: Re: [OT] [GCC] Gestire array di dimensione maggiore di 2**31 |
|
|
Cazzantonio wrote: | Ora io non ho mai programmato a 64 bit ma immagino che basti compilare il programma con un gcc su una macchina a 64 bit per superare il problema... è giusto o mi sto illudendo? |
A voler essere pignoli il testo che hai postato indica quello come limite dei 32 ma non dice che a 64 le cose migliorano (ad esempio potrebbero essere sorti problemi di implementazione degli algoritmi e gli sviluppatori del compilatori hanno deciso di mantenere il vecchio, collaudato limite), se hai la possibilità di provare o riesci a trovare una notizia più affidabile prima di pianificare il passaggio sarebbe meglio.
Al limite scrivi un breve programmino e chiedi a qualche anima pia con una macchina a 64bit di rovarlo
Quote: | C'è un modo pratico per gestire array di dimensione maggiore? Passare a 64 bit? Spezzettare l'array in array più piccoli? Qualche opzione di ottimizzazione del compilatore? |
Beh se riesci a spezzettare l'array ne guadagni sicuramente in portabilità. Poi anche li si tratta di valutare quanto "costa" in termini di tempo di sviluppo e se il gioco vale la candela (ovvero se ti basta che il programma funzioni per te oppure se vuoi che sia utilizzabile da quanta più gente possibile). _________________ Ciao da me! |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Cazzantonio Bodhisattva
![Bodhisattva Bodhisattva](/images/ranks/rank-bodhisattva.gif)
![](images/avatars/195356323743686d76373d8.jpg)
Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Mon Jun 11, 2007 7:56 am Post subject: Re: [OT] [GCC] Gestire array di dimensione maggiore di 2**31 |
|
|
randomaze wrote: | A voler essere pignoli il testo che hai postato indica quello come limite dei 32 ma non dice che a 64 le cose migliorano |
Eh già... beh proverò su qualche macchina a 64 bit... tanto se ho sempre dichiarato tutto "double precision" dovrebbe automaticamente configurarsi per usare la massima precisione (64 bit appunto).
Quote: | Beh se riesci a spezzettare l'array | Lo vedo difficile se non impossibile a meno di non ripensare da zero tutto il programma...
Per la portabilità ovviamente devo fare un codice decente perché quando me ne andrò da questa maledetta università (spero presto) dovrò passare il programma a qualcuno... ![Smile :)](images/smiles/icon_smile.gif) _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
!equilibrium Bodhisattva
![Bodhisattva Bodhisattva](/images/ranks/rank-bodhisattva.gif)
![](images/avatars/10751772074409c2c3ce8ec.png)
Joined: 06 Jun 2004 Posts: 2109 Location: MI/BG/LC
|
Posted: Mon Jun 11, 2007 10:39 am Post subject: Re: [OT] [GCC] Gestire array di dimensione maggiore di 2**31 |
|
|
randomaze wrote: | A voler essere pignoli il testo che hai postato indica quello come limite dei 32 ma non dice che a 64 le cose migliorano (ad esempio potrebbero essere sorti problemi di implementazione degli algoritmi e gli sviluppatori del compilatori hanno deciso di mantenere il vecchio, collaudato limite), se hai la possibilità di provare o riesci a trovare una notizia più affidabile prima di pianificare il passaggio sarebbe meglio.
Al limite scrivi un breve programmino e chiedi a qualche anima pia con una macchina a 64bit di rovarlo ![Wink ;-)](images/smiles/icon_wink.gif) |
no no, quel testo riporta dati corretti. ogni architettura ha i suoi limiti in base alla profondità di bit che dispone (l' esempio più lampante è il quantitativo massimo di RAM che un processore può gestire: a 32bit il limite è molto più basso di quello a 64bit e così via).
Per chi vuole approfondire l'argomento: Write Great Code: Volume 1: Understanding the Machine
Cazzantonio wrote: | Ora io non ho mai programmato a 64 bit ma immagino che basti compilare il programma con un gcc su una macchina a 64 bit per superare il problema... è giusto o mi sto illudendo? |
due semplici premesse:
1- Fortran (come il C) in fase di compilazione può allocare array solo di dimensione fissa.
2- a prescindere da architettura, numero di bit e profondita degli oceani ecc ecc, la grandezza del tuo array potrebbe sforare la quantità di RAM che hai fisicamente a disposizione sulla tua macchina.
fatte queste premesse, devi chiederti:
A- in virtù del punto 2 sopra esposto, di quanta RAM ho bisogno effettivamente per poter allocare il mio array in fase di compilazione? ti fai i dovuti calcoli (non usare il nibble-pallottoliere o ci impiegi una vita ) e vedi se la dimensione di cui necessiti è supportata dai 64bit (sicuramente non dai 32bit perchè il limite massimo mi pare di ricordare è 4Gb, mentre per i 64bit è virtualmente infinito o comunque di dimensioni dell'ordine di svariati TB).
B- Se i 64bit sono sufficienti, devi anche chiederti se il tuo OS è in grando di supportare il quantitativo di RAM che necessiti. Esempio protresti aver bisogno di 128Gb di RAM, ammettendo che tu li abbia a tua disposizione, Linux non potrebbe comunque gestirli perchè il massimo che supporta è ~64Gb (vado a memoria, non sono sicuro di tale valore ma sicuramente è un valore di gran lunga inferiore al quantitavivo massimo che l'architettura a 64bit può gestire)
Cazzantonio wrote: | C'è un modo pratico per gestire array di dimensione maggiore? Passare a 64 bit? Spezzettare l'array in array più piccoli? Qualche opzione di ottimizzazione del compilatore? |
in base a quanto detto in precedenza, se la dimensione del tuo array può essere soddisfatta sia dall'architettura a 64bit, sia dall'OS, sia fisicamente dalla RAM che disponi, allora sì: passi a 64bit, ricompili e vivi felice.
e se non l'architettura a 64bit o l'OS non ti basta e sfori i *bounderies*? allora puoi provare:
- dire al compilatore di compilare staticamente il tuo array: -static (ma non sono affatto sicuro che ciò possa esserti di aiuto)
- usare gli pseudo-array, i quali ti permettono di non allocare *tutta* la memoria in un colpo solo, e nemmeno in fase di compilazione; questo ti permette di superare i limiti fisici della tua macchina/architettura/OS a fronte di una maggiore complessità del codice sorgente, calo di prestazioni ecc ecc ecc. questa tecnica di programmazione prende il nome di Multidimensional Array Emulation e in C si ottiene usando la funzione arralloc(). In pratica questo metodo ti permette di allocare dinamicamente in memoria solo la parte dell'array che devi gestire/leggere/modificare e quando il tuo codice passa all'elemento succivo dell'array (o un blocco di elementi a seconda dei casi), la precedente parte dell'array viene deallocata dalla ram. In pratica è un po come spezzettare l'array in parti più piccole, le quali vengono indicizzarle attraverso un apposito array che ne emula le caratteristiche.
Detto questo, non so se gli pseudo-array sono la soluzione al tuo problema, e non so nemmeno se il Fortran li supporti, in caso comunque ti consiglio di dare uno sguardo al codice sorgente di questo pacchetto:
Code: | * sci-chemistry/moldy [ Masked ]
Latest version available: 2.16e
Latest version installed: [ Not Installed ]
Size of downloaded files: [no/bad digest]
Homepage: http://www.earth.ox.ac.uk/~keithr/moldy.html
Description: Program for performing molecular dynamics simulations.
License: GPL-2 |
Moldy è un noto software di simulazione molecolare che so per certo fare uso del Multidimensional Array Emulation per gestire array di grandezze elevate durante le sue simulazioni (in pratica, concettualmente parlando, qualcosa di molto simile a quello che fa il tuo software).
NOTA: dalla home page di Moldy leggo:
Code: | Fortran does not have the flexibility of dynamic memory allocation to allow the automatic sizing of the arrays which Moldy needs. This ought to present no problems as C compilers are just as or more common than FORTRAN ones. |
/EDIT:
direttamente dalla doc di Moldy:
Code: | 5.1.2 Memory Management
The allocation of memory for storage of the multitude of data required in a molecular-dynamics simulation
is one of the main design criteria of the code. The general nature of the systems to be accepted by
Moldy, namely the arbitrary mixtures of molecules with different numbers and kinds of atoms requires a
number of large multidimensional arrays with system-dependent bounds in more than one dimension. It
is impractical to declare these statically with dimensions fixed at some suitably large value because total
memory use would then be infeasibly large. The availability of standard, portable, dynamic memory
allocation was one of the major reasons the author chose to write Moldy in C. Moldy uses C's capability
of array emulation by pointers and heap-based memory allocation[28] rather than true C arrays which,
like FORTRAN's, are restricted to bounds fixed at compile-time. |
_________________ Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Cazzantonio Bodhisattva
![Bodhisattva Bodhisattva](/images/ranks/rank-bodhisattva.gif)
![](images/avatars/195356323743686d76373d8.jpg)
Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Mon Jun 11, 2007 2:43 pm Post subject: Re: [OT] [GCC] Gestire array di dimensione maggiore di 2**31 |
|
|
!equilibrium wrote: | 1- Fortran (come il C) in fase di compilazione può allocare array solo di dimensione fissa.
2- a prescindere da architettura, numero di bit e profondita degli oceani ecc ecc, la grandezza del tuo array potrebbe sforare la quantità di RAM che hai fisicamente a disposizione sulla tua macchina. |
Questo purtroppo lo so bene visto che mi sono scontrato contro un algoritmo che aveva la simpatica tendenza a richiedere tutta la ram della nasa per funzionare
A parte gli scherzi i conti che faccio necessitano tantissima ram e parte delle difficoltà che ho avuto nello sviluppare questo algoritmo è stata proprio l'implementazione di un meccanismo per risparmiare più ram possibile. Anche perché il mio scopo è misurare sistemi il più estesi possibile quindi la ram la occuperei comunque tutta... solo a parità di ram occupata devo riuscire a simulare il sistema più esteso che mi riesce.
Il limite con cui mi sto scontrando ora a quanto pare è un limite fisico della macchina perché come ram ancora ci starei dentro (per ora sono circa ad un paio di giga... speravo di raggiungere dimensioni di array ancora maggiori a dire il vero). Se questa affermazione corrisponde a verità significa che non mi resta altro da fare che passare ad usare macchine a 64 bit
Se passo alle macchine a 64 bit potrei usare un opteron a 8 processori che abbiamo al centro di calcolo. Mi pare abbia circa 4 giga di ram e diversi giga di swap... al massimo posso sentire se mi montano un'altro po' di ram
P.S. il fortran 77, a differenza del fortran 95, non può allocare dinamicamente gli array. Per ora vorrei rimanere con codice compatibile col g77 per il semplice fatto è che molto più veloce! Il gfortran è un palo di piombo...
Grazie a tutti per le informazioni
Anche perché sappiate che state aiutando la scienza...
(beh in parte è vero dai... ) _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
skypjack l33t
![l33t l33t](/images/ranks/rank_rect_4.gif)
![](images/avatars/125299789148407c8d02083.jpg)
Joined: 05 Aug 2006 Posts: 884 Location: Italia - Firenze
|
Posted: Mon Jun 11, 2007 7:07 pm Post subject: |
|
|
divide et impera, amico mio, divide et impera! ![Very Happy :D](images/smiles/icon_biggrin.gif) |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|
|
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
|
|