Newsgroup: it.scienza.informatica
Titolo: Memoria disponibile

Vi sarei molto grato se mi date qualche parere:
(Programmo in C, Ambiente Dos, compilatore Turbo C)
Ho un file di numeri float dei quali devo calcolare le correlazioni,
per farla semplice devo calcolare una funzione che si basa su tali
numeri.
Siccome i numeri sono molti, ho deciso di creare una lista per
contenerli tutti.
Notare bene che devo scorrere la lista solo in avanti ma moltissime
volte...
Se lascio come modello del compilatore il valore MEDIUM (come faccio
normalmente) la memoria non e' molta e legge meno di 4000 numeri float.
Allora cambio la voce models in HUGE e cosi' riesco a leggere fino a
10.000 numeri o poco piu'.
Le mie domande sono queste:
1) E' possibile ottenere piu' memoria ?
2) C'e' un modo migliore di affrontere il problema?
3) Perche' con HUGE ho alcuni problemi come per esempio questo: non
funziona la funzione system("cls") per pulire lo schermo e mi appare a
video
*************************************
Directory di ricerca per COMMAND non valida
Troppi parametri
Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.
*************************************+
ovviamente senza gli asterischi ... :))
4) Questa e' la piu' importante! Supponiamo che il modello sia MEDIUM.
Con un controllo da me inserito, appena la funzione malloc ritorna NULL,
smetto di leggere dal file ed utilizzo per i calcoli solo i numeri
letti. Pero' i calcoli vengono sballati e facendo un debug (di molte
ore!) ho notato che e' come se alcune strutture vengano sovrascritte e
contengano quindi dati sporchi. Vi chiedo, e' possibile cio'?
Io pensavo di no (fino ad ora!!!). Ovviamente se faccio in modo che il
programma legga 10/15 numeri in meno del limite tutto funziona
regolarmente!!!
E se uso il modello HUGE, funziona tutto (sempre rimanendo pero' nei
limiti di questo modello ovvero 10.000 numeri). Mi dite che ne pensate ?
Grazie a tutti per l'attenzione, spero di chiarirmi le idee.
Dario Martirani
PS: per favore spedite una copia della risposta anche al mio email ?

contengano quindi dati sporchi. Vi chiedo, e' possibile cio'?
Io leggerei i numeri in piccole porzioni.
E' strano comunque che dopo 10.000 float ti dia problemi.
Con Turbo C un float dovrebbe occupare 4 byte e 40.000 byte non
dovrebbero essere un problema !

 PS: per favore spedite una copia della risposta anche al mio email ?
  Ovviamente no. :)
	Alla prossima,
		Marco

volte...


 contenerli tutti.
Sbagliato. In pratica, occupi per ogni numero:
sizeof (float) // Dipende dal compilatore
+ 2 (almeno, la dimensione del puntatore)
+ 2 (se ho capito bene, con i modelli huge e medium, per contenere il
segmento)
+ ? ogni altro elemento del record della lista
Il che vuole dire che per ogni numero allocato sprechi almeno 4 bytes.
prova invece ad allocare i numeri, ad esempio, a blocchi di 1000 alla volta.
Ciò che ti serve, quindi, è un record fatto in un modo simile:
struct cluster{
    float[1000] numeri;
    int    allocati;
    struct cluster *prossimo;
}
con l'ovvia semantica di avere 1 solo puntatore ogni 1000 float (meno
dell'1%, quindi) abbinato ad un int per gestire la situazione in cui ti
serva allocare meno di 1000 numeri (tipicamente, l'ultimo record della
lista).
Ovvio che, se fai bene i conti, potresti essere in grado di allocare per
ogni record:
(64k - 6)/ sizeof (float) numeri per cluster.
Il che vuole dire che puoi sia mantenere il modello compact (o large,
forse?), oppure lo huge (ma non mi pare che ce ne sia bisogno in questo
caso).
Inoltre, in caso di mancanza di memoria, puoi anche facilmente "scaricare"
su disco un cluster intero, effettuando una specie di swap file manuale,
interamente controllato da te!
Ciao
--
Alessandro Monti

Grazie per le risposte!!!
Dario
PS: ovviamente non ti costava niente rispondermi ANCHE in email :))

Proprio perche' 10.000 float non occupavano molto, non pensavo fosse un
problema creare una
struttura in mem. Comunque non conviene leggere i numeri a porzioni per come
e' fatta la formula...
Grazie lo stesso
Dario

Grazie a tutti

    float[1000] numeri;
     ^^^^^^^^^^^^^^^^^^^
sara' C ??? ;))

 sara' C ??? ;))
E' una anticipazione dello standard prossimo venturo ;-)
--
Alessandro Monti

E' una anticipazione dello standard prossimo venturo ;-)
Urgh ! avrebbero fatto meglio a inventarsi un altro linguaggio ! ;))