linux user group brescia

immagine del castello

Archivio della mailing list

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