Çöp toplama işleminin manuel bellek yönetiminden daha hızlı olduğunun gösterilmesi

Birçok yerde (heck, hatta kendim yazdım bile) çöp toplama işleminin (teorik olarak) manuel bellek yönetiminden daha hızlı olabileceğini okudum .

Bununla birlikte, göstermek, söylemekten çok daha zor.
Aslında bu etkiyi gösteren bir kod parçası görmedim .

Bu performans avantajını gösteren herhangi biri (veya nerede bulabileceğimi biliyor) koduna sahip mi?

Bkz http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx ve Raymond Chen vs Riko Mariani (Microsoft'ta ikisi de çok yetkin programcılar) dışarı düello görmek için tüm bağlantıları izleyin . Raymond yönetilmeyen olanı iyileştirir, Rico da aynı şeyi yönetilenlerde optimize ederek cevap verirdi.

Temelde sıfır optimizasyon çabasıyla, yönetilen sürümler kılavuzdan çok daha hızlı başlatıldı. Sonunda el kitabı yönettiği yendi, ancak çoğu programcının gitmek istemediği bir seviyeye optimize ederek. Tüm sürümlerde, el kitabının bellek kullanımı yönetilenden daha önemliydi.

Temel kural, ücretsiz öğle yemeği olmamasıdır.

GC, manuel bellek yönetiminin baş ağrısını ortadan kaldırır ve hata yapma olasılığını azaltır. Belirli bir GC stratejisinin problem için en uygun çözüm olduğu durumlar vardır, bu durumda onu kullanmak için herhangi bir ceza ödemezsiniz. Ancak başka çözümlerin daha hızlı olacağı başkaları da var. Her zaman daha yüksek soyutlamaları daha düşük bir seviyeden simüle edebildiğiniz için, ancak etrafınızdaki diğer şekilde değil, genel durumdaki daha düşük soyutlamaların daha düşük olamayacağının etkili bir şekilde olduğunu kanıtlayabilirsiniz.

GC , özel bir manuel bellek yönetimi durumudur

Manuel olarak daha iyi performans elde etmek için çok fazla iş ya da daha fazla hata olabilir, ancak bu farklı bir hikaye.

GC'nin manuel yöntemlerden çok daha verimli olduğu yapay bir durum oluşturmak kolaydır - sadece çöp toplayıcı için tek bir "kök" olduğunu ve her şeyin çöp olduğunu ayarlayın, böylece GC adımı anında tamamlanır.

Eğer düşünürseniz, bu, bir işleme ayrılan hafızayı toplarken kullanılan modeldir. Süreç öldü, hafızası tamamen çöp, biz bittik. Pratik açıdan bile, hiçbir iz bırakmadan başlayan, koşan ve ölen bir süreç, sonsuza dek başlatan ve devam eden bir süreçten daha verimli olabilir.

Atık toplama dili olan dillerde yazılmış pratik programlar için, atık toplama işleminin avantajı hız değil, doğruluk ve basitliktir.

GC'nin sadece bir bellek yönetimi stratejisi olmadığı düşünülmelidir; Ayrıca, dilin ve çalışma zamanı ortamının tüm tasarımını talep eder, bu da masrafları (ve faydaları) getirir. Örneğin, GC'yi destekleyen bir dil, işaretçilerin çöp toplayıcıdan gizlenemediği ve genellikle dikkatlice yönetilen sistem ilkeleri dışında inşa edilemeyecekleri bir formda derlenmelidir. Diğer bir husus, GC'nin tamamlanmasına izin verilmesi gereken bazı adımları dayattığı için yanıt süresi garantilerini sürdürmenin zorluğudur.

Sonuç olarak, eğer çöp toplanan bir dile sahipseniz ve aynı sistemdeki manuel olarak yönetilen bellekle hızı karşılaştırırsanız, kullanmıyor olsanız bile çöp toplanmasını desteklemek için ek yükü ödemek zorundasınız.

Daha hızlı şüpheli. Ancak, donanım destekliyorsa ultra hızlı, algılanamaz veya daha hızlı olabilir. Uzun zaman önce LISP makineleri için böyle tasarımlar vardı. Biri GC'yi donanımın bellek alt sistemine yerleştirdi, öyle ki ana CPU orada olduğunu bilmiyordu. Daha sonraki birçok tasarımda olduğu gibi, GC ana işlemciyle eşzamanlı olarak çok az duraklama yapmasına gerek kalmadan çalıştı. Daha modern bir tasarım, Java kodunu JVM'nin amaca yönelik işlemciler ve duraksız bir GC kullanarak daha hızlı çalıştıran Azul Systems Vega 3 makineleri. Google’ın (veya Java’nın) ne kadar hızlı olduğunu bilmek istiyorsanız Google’ı kullanın.

Bu konuda oldukça çalıştım ve bazılarını burada açıkladım . Boamm GC'yi C ++ ile kıyaslamıştım, kullanarak tahsis ettim mallocama serbest bırakma, tahsis etme ve serbest bırakma freeve C + 'da yazılmış özel olarak oluşturulmuş bir işaretleme bölgesi GC'sini listeledi, hepsi OCaml'in GC-listesini kullanarak liste tabanlı bir n-kraliçe çözücü kullandı. OCaml’ın GC’si her durumda daha hızlıydı. C ++ ve OCaml programları kasıtlı olarak aynı tahsisleri aynı sıraya göre yapmak için yazılmıştır.

Elbette, problemi çözmek için programları yalnızca 64-bit tam sayılarla ve ayırmalar olmadan yeniden yazabilirsiniz. Her ne kadar daha hızlı olsa da, bu alıştırmanın amacını yenecektir (ki bu yeni bir GC algoritmasının performansını öngörecekti. C ++ 'da yerleşik bir prototip kullanarak çalışıyordum).

Sektörde yıllardır gerçek C ++ kodunu yönetilen dillere taşımakla geçirdim. Neredeyse her vakada, çoğu muhtemelen GC trumping manuel bellek yönetiminden dolayı önemli performans iyileştirmeleri gözlemledim. Pratik sınırlama, bir mikro Benchmark'ta neler yapılabileceği değil, bir son teslim tarihinden önce neler yapılabileceği ve GC-merkezli diller, asla geriye bakmadığım kadar büyük verimlilik geliştirmeleri sunuyor. Hala gömülü cihazlarda (mikrodenetleyiciler) C ve C ++ kullanıyorum ama bu şimdi bile değişiyor.

Böyle bir örnek, mutlaka kötü bir manuel bellek ayırma şemasına sahiptir.

En iyi çöp toplayıcıyı kabul edin GC. Dahili olarak bellek ayırma yöntemleri, hangi belleğin serbest bırakılabileceğini belirleme yöntemleri ve sonunda serbest bırakma yöntemleri vardır. Birlikte bunlar hepsinden daha az zaman alır GC; Diğer yöntemlerde biraz zaman harcanır GC.

Şimdi, aynı tahsis mekanizmasını kullanan GCve free()çağrıları aynı yöntemle serbest bırakılacak hafızayı bir kenara koyan manuel bir tahsisatçı düşünün GC. Tarama aşaması yoktur, başka yöntemlerden hiçbirine sahip değildir. Bu mutlaka daha az zaman alır.