La dimostrazione della garbage collection è più veloce della gestione manuale della memoria

Vedi link e segui tutti i link per vedere Rico Mariani vs Raymond Chen (entrambi programmatori molto competenti in Microsoft) a duellare. Raymond avrebbe migliorato quello non gestito, Rico avrebbe risposto ottimizzando la stessa cosa in quelli gestiti.

Con uno sforzo di ottimizzazione sostanzialmente zero, le versioni gestite sono state avviate molte volte più velocemente del manuale. Alla fine il manuale ha battuto il gestito, ma solo ottimizzandolo a un livello che la maggior parte dei programmatori non vorrebbe visitare. In tutte le versioni, l'utilizzo della memoria del manuale è stato significativamente migliore rispetto a quello gestito.

La regola generale è che non ci sono pranzi gratuiti.

GC elimina il mal di testa della gestione manuale della memoria e riduce la probabilità di commettere errori. Ci sono alcune situazioni in cui alcune particolari strategie di GC sono la soluzione ottimale per il problema, nel qual caso non pagherai alcuna penalità per l'utilizzo. Ma ce ne sono altri in cui altre soluzioni saranno più veloci. Dal momento che puoi sempre simulare astrazioni più alte da un livello inferiore, ma non viceversa, puoi dimostrare in modo efficace che non c'è modo che astrazioni più alte possano essere più veloci di quelle inferiori nel caso generale.

GC è un caso speciale di gestione manuale della memoria

Potrebbe essere un sacco di lavoro o più errori inclini a migliorare le prestazioni manualmente, ma questa è una storia diversa.

È facile costruire una situazione artificiale in cui GC è infinitamente più efficiente dei metodi manuali - basta disporre che ci sia solo una "radice" per il garbage collector e che tutto sia spazzatura, quindi il passo GC viene immediatamente completato.

Se ci pensi, questo è il modello usato quando si raccoglie la memoria allocata a un processo. Il processo muore, tutto ciò che è memoria è spazzatura, abbiamo finito. Anche in termini pratici, un processo che inizia, corre e muore senza lasciare traccia potrebbe essere più efficiente di uno che inizia e gira per sempre.

Per i programmi pratici, scritti in lingue con garbage collection, il vantaggio della garbage collection non è la velocità, ma la correttezza e la semplicità.

Va considerato che GC non è solo una strategia di gestione della memoria; fa anche richieste sull'intero design del linguaggio e dell'ambiente di runtime, che impongono costi (e benefici). Ad esempio, un linguaggio che supporta GC deve essere compilato in un modulo in cui i puntatori non possono essere nascosti dal garbage collector e generalmente dove non possono essere costruiti se non da primitive di sistema gestite con cura. Un'altra considerazione è la difficoltà di mantenere le garanzie del tempo di risposta, poiché GC impone alcuni passaggi che devono essere autorizzati a eseguire fino al completamento.

Di conseguenza, se si dispone di una lingua che è raccolta dati inutili e si confronta la velocità con la memoria gestita manualmente nello stesso sistema, è comunque necessario pagare l'overhead per supportare la garbage collection anche se non la si sta utilizzando.

Più veloce è dubbio. Tuttavia, può essere ultra-veloce, impercettibile o più veloce se supportato da hardware. C'erano progetti del genere per le macchine LISP molto tempo fa. Uno ha costruito il GC nel sottosistema di memoria dell'hardware in modo tale che la CPU principale non sapeva che era lì. Come molti altri progetti successivi, il GC funzionava in concomitanza con il processore principale con poca o nessuna necessità di pause. Un design più moderno è rappresentato dalle macchine Azul Systems Vega 3 che eseguono il codice Java in modo più veloce rispetto alle JVM utilizzando processori appositamente sviluppati e un GC senza paus. Google li se vuoi sapere quanto velocemente GC (o Java) può essere.

Ho lavorato un po 'su questo argomento e ne ho descritto alcuni qui . Ho benchmarkato il Boehm GC in C ++, allocando usando malloc ma non liberando, allocando e liberando usando free e un GC mark-region personalizzato scritto in C ++ tutto vs GC di serie di OCaml eseguendo un risolutore n-queens basato su elenco . Il GC di OCaml era più veloce in tutti i casi. I programmi C ++ e OCaml sono stati scritti deliberatamente per eseguire le stesse allocazioni nello stesso ordine.

È possibile, ovviamente, riscrivere i programmi per risolvere il problema utilizzando solo numeri interi a 64 bit e nessuna allocazione. Sebbene fosse più veloce a sconfiggere il punto dell'esercitazione (che prevedeva le prestazioni di un nuovo algoritmo GC stavo lavorando all'utilizzo di un prototipo costruito in C ++).

Ho trascorso molti anni nell'industria porting di codice C ++ reale per le lingue gestite. In quasi tutti i casi ho osservato miglioramenti sostanziali delle prestazioni, molti dei quali erano probabilmente dovuti alla gestione manuale della memoria di GC. La limitazione pratica non è ciò che può essere realizzato in un microbenchmark, ma ciò che può essere realizzato prima che una scadenza e linguaggi basati su GC offrano tali enormi miglioramenti di produttività che non ho mai guardato indietro. Uso ancora C e C ++ su dispositivi embedded (microcontrollori) ma anche quello sta cambiando ora.

Un tale esempio ha necessariamente un cattivo schema di allocazione manuale della memoria.

Assumi il miglior garbage collector GC . Internamente ha metodi per allocare memoria, determinare quale memoria può essere liberata e metodi per liberarla definitivamente. Insieme, questi richiedono meno tempo di tutti GC ; un po 'di tempo è trascorso negli altri metodi di GC .

Consideriamo ora un allocatore manuale che utilizza lo stesso meccanismo di allocazione di GC e la cui chiamata free() mette semplicemente da parte la memoria da liberare con lo stesso metodo di GC . Non ha una fase di scansione, né ha nessuno degli altri metodi. Richiede necessariamente meno tempo.