Nel suo discorso "Efficiency with algorithms, Performance with data structures", Chandler Carruth parla della necessità di un modello di allocatore migliore in C++. L'attuale modello di allocatore invade il sistema di tipi e rende quasi impossibile lavorare in molti progetti a causa di ciò. D'altra parte, lo Bloomberg allocator model non invade il sistema di tipi ma si basa su chiamate di funzioni virtuali che rendono impossibile al compilatore 'vedere' l'allocazione e ottimizzarla. Nel suo discorso parla dei compilatori deduplicando l'allocazione di memoria (1:06:47).Allocazione memoria ottimizzata via dai compilatori
Mi ci è voluto un po 'di tempo per trovare alcuni esempi di ottimizzazione dell'allocazione della memoria, ma ho trovato questo esempio di codice, compilato in clang, che ottimizza l'allocazione di memoria e restituisce solo 1000000 senza allocare nulla.
template<typename T>
T* create() { return new T(); }
int main() {
auto result = 0;
for (auto i = 0; i < 1000000; ++i) {
result += (create<int>() != nullptr);
}
return result;
}
Il seguente documento http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html dice anche che l'assegnazione potrebbe essere fusa in compilatori e sembra suggerire che alcuni compilatori già fanno questo genere di cose.
Dato che sono molto interessato alle strategie per l'allocazione di memoria efficiente, voglio davvero capire perché Chandler Carruth è contro le chiamate virtuali nel modello di Bloomberg. L'esempio sopra mostra chiaramente che clang ottimizza le cose quando può vedere l'allocazione.
- mi piacerebbe avere un "codice di vita reale", dove questa ottimizzazione è utile e fatto da qualsiasi compilatore corrente
- Avete qualche esempio di codice in cui allocazione diversa sono fusi da Anu compilatore attuale?
- Capisci cosa significa Chandler Carruth quando dice che i compilatori possono "deduplicare" la tua allocazione nel suo discorso alle 1:06:47?
La funzione 'create' è una funzione con effetti collaterali in fase di esecuzione, il compilatore non può conoscere i risultati di tali effetti collaterali in fase di esecuzione in fase di compilazione. Quello che * può * fare è vedere che la memoria allocata non è realmente usata da nessuna parte, il che potrebbe essere una ragione per cui potrebbe ottimizzare le allocazioni, ma direi che è sbagliato solo perché il compilatore non ha modo di predire i risultati alla compilazione -tempo. –
@Joachim: questo esempio è stato discusso qui http://stackoverflow.com/questions/25668420/clang-vs-gcc-optimization-including-operator-new. Secondo il n3664 di cui ho parlato nel mio post, lo standard non è chiaro se è permesso o meno. Ma sembra dire che molti compilatori già lo fanno. – InsideLoop