Çekirdek başına iş parçacığı (Thread-per-core)

• Bu makale, Rust topluluğunda çok iş parçacıklı yürütücülerin kullanımına dair tartışmayı ele alıyor; bunlar, işleri dengeli biçimde dağıtmak için work-stealing yapan async çalışma zamanlarıdır.
• Bazı Rust kullanıcıları, daha yüksek performans ve daha kolay uygulama vaat eden alternatif bir mimari olarak "thread-per-core" yaklaşımını savunuyor.
• "Thread-per-core" terimi yanıltıcı olabilir. Tüm çok iş parçacıklı yürütücüler aslında thread-per-core'dur; çekirdek başına bir OS iş parçacığı oluşturur ve işleri bu iş parçacıkları üzerinde zamanlar.
• Thread-per-core üç fikri birleştirir: eşzamanlılığın kullanıcı alanında ele alınması, iş parçacıklarının bloklanmasını önlemek için I/O'nun asenkron hale getirilmesi ve senkronizasyon maliyetini ile CPU önbellekleri arasındaki veri hareketini ortadan kaldırmak için verinin CPU çekirdekleri arasında bölünmesi.
• Tartışma esas olarak üçüncü nokta üzerinedir ve async Rust kullanımı ilk iki gereksinimi karşılayabilir.
• Thread-per-core mimarisinde iki optimizasyon yapılabilir: işlerin iş parçacıkları arasında çalınması ve mümkün olduğunca az durumun paylaşılması.
• Work-stealing, tüm iş parçacıklarının sürekli iş yapabilmesini sağlayarak tail latency'yi iyileştirir; ancak uygulanması zordur ve senkronizasyon maliyetiyle önbellek kaçırmalarına yol açabilir.
• Share-nothing, veriyi tek bir CPU çekirdeğine ait daha hızlı önbellekte tutarak tail latency'yi iyileştirir; ancak birden fazla bölümde durum değiştirmesi gereken karmaşık uygulamalar için uygulanması zor olabilir.
• Makale, paylaşılan durum kullanan sistemlerde work-stealing'in yük altında CPU kullanımını iyileştirebileceğini öne sürüyor.

[GN⁺]

Hacker News görüşü

• Tartışmanın özü, çekirdek başına iş çalma (work-stealing) executor'ları değil, Rust'ta async/await'in iyi bir soyutlama olup olmadığıdır.
• Çekirdek başına thread yaklaşımı, çok çekirdekli genel sunucularda hesaplamanın ölçeklenebilirliğini ve verimliliğini çözmek için ortaya çıktı ve yüksek işlem hacimli I/O-bound işlerde mükemmel olduğu görüldü.
• Çekirdek başına thread mimarisi, ölçeklenebilirliği ve verimliliği nedeniyle kalıcı olacak; ancak çoğu yazılım mühendisi, modern ve idiomatik bir çekirdek başına thread tasarımının nasıl göründüğüne dair sınırlı sezgiye sahip.
• Bazı uygulamalar tek thread'li sistemlere daha uygundur ve Rust bu esnekliğe izin verir.
• Rust'ın async programlamasına yönelik eleştiriler vardır; bunlar arasında Send + Sync + 'static gereksinimi de bulunur ve bazıları bunu külfetli bulur.
• Send bound'u, işlerin executor thread'leri arasında taşınmasına izin veren bir gereksinimdir ve bu, Rust async sisteminin bir kusuru gibi görünür.
• Tüm programlar için en iyi performansı sağlayacak herkese uyan tek bir yaklaşım yoktur ve async kullanımı birçok Rust programı için erken optimizasyon olarak görülür.
• Kernel context switch'leri maliyetli olduğu için çekirdek başına thread tasarımı tercih edilir; ancak user-space context-switch scheduling de sorun yaratabilir.
• İş çalma, tail latency'yi çözmenin bir yoludur; ancak cache miss'lere ve Send, Sync ve 'static gibi ek geliştirici kısıtlarına yol açar.