Esiste un modello di progettazione di allocatore di memoria personalizzato che non memorizzi i metadati nelle sue allocazioni?

Question

Fondamentalmente, ho bisogno di un pool di memoria per l'assegnazione rapida di piccoli oggetti. Idealmente, mi piacerebbe sostituire le allocazioni sia sull'host che sulla memoria allocata su GPU con cudaMalloc. Posso scrivere il mio, e lo farò se devo, ma non mi dispiacerebbe scambiare in una delle solide implementazioni open source.

L'unico problema è che, con cudaMalloc, il pool di memoria non può toccare la memoria allocata. La mia comprensione è che molti (tutti?) Degli allocatori di memoria comuni, come quelli nel titolo, memorizzano una piccola quantità di metadati nei dati allocati. Quindi non avrebbero funzionato.

Qualcuno sa di un allocatore di memoria per il quale questo non è il caso?

Answer 1

Se tutte le allocazioni piccole hanno le stesse dimensioni o un limite superiore ragionevole, un allocatore di pool di dimensioni fisse è un buon modello.

L'idea è che l'allocatore acquisisca un grosso blocco utilizzando la chiamata di sistema, quindi gestisce il proprio elenco libero di blocchi di dimensioni fisse all'interno del blocco grande. L'allocazione è facile come prendere il blocco in testa alla lista libera. La deallocazione è un po 'più complicata ma può essere implementata in modi diversi a seconda delle esigenze.

E 'abbastanza semplice per scrivere il proprio, o se google C++ dimensioni allocatore fissa è possibile trovare un certo numero di buoni implementazioni tra cui boost :: piscina

Answer 2

Qualsiasi allocatore ha bisogno di memorizzare alcuni metadati, da qualche parte. Quando la necessità di allocazione diventa più semplice, ovviamente, la quantità di metadati diminuirà.

Penso che un normale allocatore di dimensioni fisse ti darà ancora problemi, quando comprenderò il tuo problema. Hai un vincolo hardware davvero speciale, per quanto vedo.

È possibile utilizzare un allocatore di pool fisso, che non offre allocazioni singole libere, ma libera solo l'intero pool. Pertanto, la necessità di archiviare i metadati all'interno della memoria allocata verrebbe eliminata.

Ovviamente è sempre possibile implementare un allocatore che memorizza i metadati all'esterno dell'area allocata, utilizzando un'area di memoria diversa. Ma la maggior parte delle librerie memorizza i metadati nell'area allocata, perché è più comoda per le normali architetture.

Quindi la migliore ipotesi sarebbe quella di trovare un allocatore di pool fisso che non offre la funzionalità per liberare singole allocazioni o dove non si può semplicemente usare questa funzione (e quindi l'allocatore non ne memorizza nessuno). Questo ovviamente è solo un'opzione, quando va bene per te, per rilasciare sempre interi pool di memoria invece di singole allocazioni (che è, btw, una buona precauzione contro perdite di memoria, se applicabile).

L'altra alternativa sarebbe naturalmente quella di implementare un proprio allocatore, magari sulla base di un semplice allocatore che utilizza come semplici metadati il ​​più possibile.