Brokk, mimalloc ile bile süren %26'lık yavaşlamanın ardından Bifrost için musl ön derleme seçeneğini kaldırıyor

Geri dönüş

Jonathan Ellis, hafif C kütüphanesinin çok daha yavaş olduğunu görmek için musl'ü glibc ile kıyaslarken ölçtükten sonra bu kütüphaneyi Rust projelerinden birinden kaldırıyor. Brokk blogunda yazan ve Hacker News ana sayfasına ulaşan bir gönderide Ellis, performans açısından hassas bir proje olan Bifrost'tan musl ön derleme seçeneğinin kaldırıldığını, daha küçük araçlarının ise musl'de kalacağını belirtiyor.

musl nasıl girdi

Ellis kariyerinin büyük kısmını JVM'de, yan dal olarak da Python'da geçirdi; bu yüzden Bifrost'un container içindeki bir dağıtımı libc uyumsuzluğuna takıldığında ve bir yapay zeka asistanı musl'ü önerdiğinde bunu benimsedi — ve diğer Rust projelerini de musl'e taşıdı. Cazibe, ana makinede hiçbir şeye bağımlı olmayan, tek bir artefakt olarak dağıtılan statik bağlanmış ikili dosyalardı.

Ryan adlı bir meslektaşı daha sonra musl'ün zayıf bellek ayırıcısına dikkat çekti ve Ellis'i bu konuyu ele alan Daniel Raneland imzalı bir makaleye yönlendirdi. İddiayı olduğu gibi kabul etmek yerine Ellis, kendisinin ölçmesine karar verdi.

Sayılar ne gösteriyor

Ellis'in bildirdiğine göre ayırıcı sorunu gerçek ve — okuduğu diğer yazıların aksine — yoğun eşzamanlı iş yükleriyle sınırlı değil. Ölçümleri 4 çekirdekli EC2 sanal makinelerinden geliyor ve Bifrost'un thread havuzları bu donanıma göre boyutlandırılmış; yani kayıplar olağan paralellik düzeylerinde bile ortaya çıkıyor.

Daha iyi bir ayırıcı — mimalloc ya da jemalloc — takmanın standart çaresi ise yetersiz kalıyor. Ellis'in testlerinde mimalloc ile çalışan musl bağlantılı derlemeler yine de glibc'den %26 daha yavaş kaldı.

İki iş yükü bunun sebebini açıklıyor. Bunlardan scan_usages adlı ilki bellek ayırıyor: mimalloc kaybın bir kısmını telafi etti ama glibc yine kazandı. structural_clone_smells adlı diğeri ise çok az bellek ayırıyor — mimalloc ile ya da onsuz çalıştırmak ölçülebilir bir fark yaratmadı — buna rağmen scan_usages'tan oransal olarak daha fazla geriledi. Bu, Ellis'i ayırıcının ötesine bakmaya itti ve musl'deki bazı günlük bellek yordamlarının kendi başlarına da yavaş olduğu sonucuna vardı.

Bölünmüş bir karar

Bulgular her projeyi glibc'ye geri döndürmedi. Ellis, basitliğin hedef olduğu yerde yaklaşık %25'lik bir yavaşlamanın katlanılabilir olduğu gerekçesiyle, Hel gibi daha küçük çabaları artık mimalloc ile eşleştirilmiş şekilde musl üzerinde tutuyor. Verimliliğin önemli olduğu Bifrost ise musl ön derlemesini kaybediyor.

Ellis ayrıca musl'ün hiçbir şekilde bir ayırıcı paketlememesi ve bunun yerine geliştiricilerin birini seçmesini zorunlu kılması gerektiğini savunuyor. Küçük bir ayak izi nedeniyle yavaş seçeneği tercih etmek o zaman bilinçli bir karar olurdu; uyarıyı kaçıran herkes için kötü bir sürpriz olmazdı.

Neden önemli

musl en çok minimal container imajları için yaygın bir temel olan Alpine Linux'un arkasındaki C kütüphanesi olarak bilinir ve statik musl ikili dosyaları Rust servislerini tek dosya olarak dağıtmanın popüler bir yoludur. Ellis'in sayıları, boyut ve taşınabilirlik kazançlarının bir runtime maliyeti taşıdığının somut bir hatırlatıcısı — daha iyi bir ayırıcının bunu yalnızca kısmen telafi ettiği ve heap'e neredeyse hiç dokunmayan iş yüklerinde bile ortaya çıkan bir maliyet.

Temel imaj ya da linker hedefi tartan ekipler için pratik ders, gerçek iş yükünü kıyaslamak ve ödünleşimleri varsaymamak ile imaj boyutu tasarrufunu verimliliğe karşı fiyatlandırmaktır. Zaten musl üzerinde olan ve performans sorunu yaşayanlar içinse mimalloc kısmi bir çözüm, eşitlik değil: Ellis'in ölçümlerinde değişimden sonra bile fark çift haneli olarak kaldı.