VERO bitmap
Gabriele Villi
gvilli a iol.it
Gio 8 Maggio 2003 06:54:15 UTC
Alle 09:27, giovedì 08 maggio 2003, Maurizio Paolini ha scritto:
> Io invece interpretavo la domanda in modo diverso: quando alloco una struct
> con malloc, immagino sia sensato che venga allocato spazio dal gestore
> della memoria in modo da poter poi riliberare lo spazio e/o altre
> operazioni del tutto estranee al compilatore.
Confermo: da quanto mi ricordo il so gestisce la memoria basandosi su una
lista di blocchi liberi; tuttavia, sempre se la _mia_ :) memoria non mi
inganna, si cerca mettere le informazioni di servizio (ad es. puntatori al
prox/precendente blocco libero, dimensione ecc) proprio nello spazio
"libero", in modo da non appesantire inutilmente lo spazio realmente allocato
dall'utente.
Inoltre ho anche il sospetto (quasi una certezza) che intervengano fattori
quali allineamento dei dati e dimensione minima _reale_ del blocco allocato
che possono provocare effetti di frammentazione interna nelle pagine e delle
strutture allocate. Nel tuo caso, ad esempio, un blocco 2+4+4 byte verrebbe
allocato in 2+(2)+4+4 byte, con l'aggiunta di (2) byte di padding per
garantire che gli ultimi 2 dati si trovino ad indirizzi allineati ad un
multiplo di 4 byte. Per verificarlo basta stampare la differenza tra i
puntatori al secondo e primo campo della struct.
Mi sembra quindi sensato il suggerimento di allocare blocchi il piu' grandi
possibile se il prezzo in termini di complicazione del codice non e'
eccessivo. Inoltre cercherei di usare strutture e tipi che siano compatibili
con gli allineamenti "graditi" al processore; in parole povere, una stringa
di bit non la farei lunga quanto la cardinalita' massima dell'insieme, ma
cercherei di accorpare piu' stringhe fino a raggiungere una dimensione
multipla di 4 byte (o quel che e' per il tuo processore). Chiaro che bisogna
vedere se il gioco vale la candela...
ciao
gv
Maggiori informazioni sulla lista
Lug
|