linux user group brescia

On Sat, 2 Aug 2003, Luca Giuzzi wrote:
> Questa e' una buona cosa comunque in quanto riduce l'overhead nel momento
> in cui effettivamente devi fare i calcoli.

	Nell'implementazione originale avevo evitato di fare questa cosa 
perche' pensavo che copiare qualche decina di interi (molte volte) fosse 
piu' lento di assegnare valori a puntatori. Non ho considerato il problema 
espresso (meglio di me) da Erix e nemmeno il tempo impiegato da malloc() e 
free(), infatti [vedi sotto]

> > 	Risultato: da qualche decina/centinaia di MB di ram utilizzati (e 
> > costantemente in _lenta_ ma inesorabile crescita) sono passato a 600/700 
> > KILO byte, dimensione ragionevole stimando la dimensione dell'istanza del 
> > problema.
> Beh... penso che questo sia un guadagno sia in termini di funzionalita'
> sia in termini di snellezza del codice ... non sarei sorpreso se ci fossero
> stati pure miglioramenti prestazionali (di ordine minimo, in quanto
> il vecchio collo di bottiglia era presumibilmente la RAM, pero' dovrebbero
> esserci)

	Come dicevo ero preoccupato per le memcpy(), ma evidentemente le 
malloc() e le free() sono piu' lente. Infatti per una medesima quantita' 
di calcoli adesso impiego sul mio computer (PII 350) il tempo che prima 
impiegavo sull'Athlon XP 1500+ del laboratorio. Penso sia un BUON 
incremento...

> BTW: se vuoi testare il tuo programma `in condizioni di laboratorio'
> (per trovare memoria allocata e non liberata, ma anche per verificare
> l'impatto del codice sulla cache, etc. etc.) ti consiglio di provare
> valgrind... e' veramente ben fatto 

	Grazie del consiglio, ma non e' cosi' necessario abbia prestazioni 
eccezionali. Solo che se la RAM usata continua ad aumentare rischio di 
andare in "Out of space" prima del termine del processo. Questo e' il 
problema per cui ho dovuto riscrivere (o meglio modificare) il mio 
programma.

-- 
						Ciriciao
					LtC. Melkor?! B. Xapatan