bzip2 Crate, C'den %100 Rust'a geçti

• bzip2 crate'i, C kodu bağımlılığını %100 Rust bir uygulamayla değiştirdi
• Performans genel olarak önceki sürüme göre arttı ve cross-compilation daha kolay hale geldi
• Rust uygulaması, C sürümüne kıyasla hem veri sıkıştırma hem de açma hızında iyileşme sağlıyor
• Sembol çakışması gibi kütüphane bağımlılığı sorunları büyük ölçüde azaldı
• Güvenlik denetiminden geçirilerek önemli mantık hataları düzeltildi ve kararlılığı doğrulandı

---

bzip2 crate 0.6.0 yayımlandı ve Rust tabanına geçti

• Bugün bzip2 sürüm 0.6.0 yayımlandı
• Artık varsayılan olarak kendi geliştirdikleri Rust tabanlı bzip2 algoritması uygulaması libbz2-rs-sys kullanılıyor
• Bu geçiş sayesinde bzip2 crate'i daha hızlı oldu ve cross-compilation kolaylaştı

• libbz2-rs-sys crate'i C dinamik kütüphanesi olarak da derlenebiliyor. Böylece C projeleri de performans artışından yararlanabiliyor

Bu geçiş neden yapıldı?

• bzip2 algoritması 90'larda geliştirildi; bugün yaygın kullanımda olmasa da çeşitli protokoller ve kütüphanelerde hâlâ spesifikasyona uyumluluk için gerekiyor
• Birçok proje doğrudan olmasa da bağımlılık ağacının derinliklerinde bzip2'ye bağlı
• Ekip, zlib-rs'de edindiği deneyimi temel alarak bu kez bzip2 uygulamasını modernleştirdi

• libbz2-rs-sys uygulamasının ayrıntıları önceki bir blog yazısında ele alınmıştı. Burada ise bu geçişin faydalarına bakılıyor

Artan performans

• Rust uygulaması genel olarak C sürümünden daha yüksek performans gösteriyor
• Bazı durumlarda eşdeğer performans sunsa da daha yavaş olduğu bir durum yok

• Sıkıştırma performansı: bzip2'de level seçeneği var ancak performansa etkisi sınırlı
• Test sonuçlarında, temsili örnek dosyalarda Rust sürümü %10'dan fazla hız artışı sağladı

Sıkıştırma:

Dosya	C(yürütme çevrimi)	Rust(yürütme çevrimi)	Göreli değişim
sample3.ref (level 1)	38.51M	33.53M	-14.87%
silesia-small.tar (level 1)	3.43G	3.00G	-14.30%
silesia-small.tar (level 9)	3.47G	3.17G	-9.66%

Açma işlemlerinde de tüm durumlarda performans iyileşti:

Dosya	C(yürütme çevrimi)	Rust(yürütme çevrimi)	Göreli değişim
sample3.bz2	2.53M	2.42M	-4.48%
sample1.bz2	9.63M	8.86M	-8.63%
sample2.bz2	20.47M	19.02M	-7.67%
dancing-color.ps.bz2	87.46M	83.16M	-5.17%
re2-exhaustive.txt.bz2	1.89G	1.76G	-7.65%
zip64support.tar.bz2	2.32G	2.11G	-10.00%

Bununla birlikte, macOS ortamında zaman zaman açma ölçümlerinde değişiklikler görüldü. Performans ölçüm araçlarının sınırlamaları nedeniyle analiz zordu

Cross-compilation desteği

• C bağımlılığı olan Rust projelerinde cross-compilation genelde cc crate'i sayesinde çalışsa da başarısız olduğunda hata ayıklamak çok zor oluyor
• Sistem kütüphanesi bağlama sürecinde beklenmedik sorunlar çıkabiliyor ve özellikle WebAssembly derlemeleri gibi bazı ortamlarda bu pratikte ciddi bir engel oluşturuyor

• Rust uygulamasına geçilmesiyle C ile ilgili sorunlar tamamen ortadan kalktı

• Artık Windows, Android, WebAssembly gibi ortamlarda da özel bir durum olmadan cross-compilation yapılabiliyor
• Bu, yalnızca kullanıcı deneyimi açısından değil bakım açısından da büyük bir avantaj

Varsayılan olarak sembol (export) çakışması yok

• C bağımlılığı olduğunda sembollerin Rust dış bloklarından export edilmesi gerekiyor; başka bir bağımlılık aynı sembolleri export ederse çakışma oluşuyor
• libbz2-rs-sys, varsayılan olarak sembol export etmeyecek şekilde tasarlandı
• Bu nedenle diğer harici kütüphanelerle sembol çakışması yaşanmıyor. Gerekirse bir feature flag ile export etkinleştirilebiliyor

MIRI tabanlı testler çalıştırma

• Rust'ta bzip2'yi yüksek performansla uygulamak için unsafe kod kullanımı kaçınılmaz ve C arayüzünü taklit etmek için de çok sayıda unsafe kod gerekiyor
• Neyse ki bu kod MIRI ortamında çalıştırılıp test edilebiliyor

• Dahası, bzip2 kullanan üst seviye kütüphane ve uygulamalar da artık MIRI testlerinden geçirilebiliyor

Sonuç

Artık bzip2 crate'i daha hızlı. Üzerinde düşünmeyi bile gerektirmeden, doğal şekilde daha iyi bir deneyim sunuyor

[GN⁺]

Hacker News yorumu

• Trifecta Tech’in uygulamasının Linux dağıtımlarında kullanılan resmi uygulamanın yerini alma ihtimali düşünülünce, geçmişte Fedora’nın mevcut Adler zlib yerine zlib-ng’ye geçtiği bir örnek olduğu için bunun imkânsız olmadığı düşünülüyor. Asıl noktanın, özgün sürümle uyumlu bir C ABI sunmak olduğu görüşü
  • Eğer 2019’dan beri upstream tarafında bir sürüm yoksa, bu uygulamanın zaten tamamlanmış sayılıp sayılamayacağı soruluyor. Artık düzeltilecek hata ya da eklenecek özellik yoksa, bunun kendi başına yeterli olabileceği düşünülüyor
  • Ubuntu’nun Rust ile yazılmış sudo kullandığı için böyle bir değişimin gayet mümkün olduğu düşünülüyor
  • Trifecta Tech’in C ABI uyumluluğunu iyi sağladığı, ancak sonuçta birinin bu işi gerçekten yapması gerektiği ve değişimin ancak böyle gerçekleşeceği söyleniyor
  • uutils’in hedefinin de bu tür resmi replacement’lar olduğu belirtilerek uutils ana sayfası paylaşılıyor
  • Kısa bir incelemede cargo-c yapılandırmasının zaten bulunduğu ve bunun olumlu göründüğü, ancak namespace farklı olduğu için C programlarında mevcut libbz2 olarak otomatik algılanmayacağı belirtiliyor. bzip2 sembollerine aşina olunmadığından tam ABI uyumluluğu konusunda kesin konuşmanın zor olduğu da ekleniyor. GNU işletim sistemi uygulamasını doğrudan sürdürmenin çok zaman aldığı, fakat vakit olduğunda deneysel proje platypos için PR’ların memnuniyetle karşılanacağı söyleniyor
• Bu crate’i kullanarak yüzlerce TB Common Crawl verisi işlendiği ve hız artışından çok memnun olunduğu söyleniyor
  • Neden burada bz2 kullanıldığı soruluyor. Büyük bir dönüştürme işlemi yalnızca bir kez yapılacaksa zstd’ye geçmenin çok avantajlı olduğu duyulduğu ve sıkıştırma oranı arttıkça her açıdan bzip2’den daha iyi olduğu öne sürülüyor
  • Common Crawl verisinin torrent olarak da yayımlanıp yayımlanmadığı soruluyor
  • Sıkıştırma hızında %14 iyileşmenin oldukça etkileyici olduğu belirtiliyor
• Bu uygulamanın varsayılan olarak geriye kalan 11 CVE’yi çözüp çözmediği soruluyor. İronik biçimde bzip2 crate’i için de CVE bildirimi olduğu belirtilerek ilgili bağlantı paylaşılıyor
  • Söz konusu crate’te raporlanan “büyük dosyalarda çalışma zamanı hatası” türü açıklarla, C ile yazılmış sürümdeki bounds miss sorunlarının karşılaştırılmasının ilginç olduğu söyleniyor. Bu tür bounds miss açıklarının gerçekten kod çalıştırmaya kadar gidip gidemeyeceği merak ediliyor
  • “bzip2 crate’i 0.4.4 öncesi sürümlerde bir güvenlik açığı içeriyor” uyarısı alıntılanıyor. Ayrıca bugün 0.6.0 sürümünün yayımlandığı bilgisi ekleniyor
• “90’ların algoritmasını neden özellikle iyileştirelim?” sorusuna karşılık, bugünlerde hangi algoritmaların kullanıldığının merak edildiği söyleniyor. zstd anılıyor ve sıkıştırma algoritmalarını karşılaştıran benchmark bağlantısı paylaşılıyor
• C ve Rust için derleyicilerin codegen backend’i aynıysa hız artışının nasıl ortaya çıktığı merak ediliyor. Rust’ın auto-simd, elle yapılan optimizasyonlar ya da yeni optimizasyon kütüphanelerinin kullanımı gibi çeşitli etkenler olabileceği söyleniyor
  • Tahminen Rust’ın code generator’a daha fazla ipucu verebildiği düşünülüyor. Örnek olarak, C pointer’larının aksine aliasing konusunda daha az endişe olması gösteriliyor. Aliasing açıklaması bağlantısı paylaşılıyor
  • C dilinin modern yüksek performanslı kod yazımı açısından gerçekten iyi olmadığı söyleniyor. C99’dan C21’e yaklaşık 20 yılda dilin kendisinin yeni komutlardan (clz, popcnt, clmul, pdep vb.) temiz bir şekilde yararlanmayı sağlayacak özelliklerden yoksun kaldığı eleştiriliyor. Bu tür soyut komut desteğinin bile bu tarz kodların optimizasyonuna büyük katkı sağladığı belirtiliyor
  • Hangi dil olursa olsun yeniden yazmanın hız artışı fırsatı sunduğu, bunun Rust’a özgü bir hız garantisi olmadığı söyleniyor
• Benzer şekilde benim ya da Prossimo’nun temel internet protokollerini (BGP, OSPF, RIP vb.), routing uygulamalarını ve DNS sunucularını yeniden yazmasını isteyen bir temenni dile getiriliyor
  • Son birkaç yılda Rust gibi güvenli dillerle internetin ve işletim sistemlerinin çekirdek araçlarını yeniden yazmayı destekleyen fonlar olarak NLnet projesi ve Sovereign Tech Fund tanıtılıyor. Örnek olarak BGP in Rust projesi da anılıyor
  • Memory Safety Initiative kapsamında TLS ve DNS gibi temel servislerin güvenli yeniden yazımı çabalarının anlatıldığı ve bunun öneriyle kısmen örtüştüğü belirtiliyor
  • Bir geliştiricinin SPARK Ada ile Ironsides DNS yazdığı, bu dilin daha güçlü biçimsel kanıtları desteklediği söyleniyor
• macOS’te perf profiler olmasa da dtrace ile performans analizinin yeterince yapılabildiği düşünülüyor. Perl ile yazılmış özgün flame graph betiğinin de dtrace kullandığı, Rust ile yeniden yazılan flame graph’ın da aynı yöntemi izlediği belirtiliyor. cache miss ya da micro instruction retired gibi bazı metrikler eksik olsa da hâlâ çok kullanışlı olduğu söyleniyor
• Rust’ı Javascript ile yeniden yazmak gerektiğine dair şakacı bir yorum yapılıyor
• lbzip2 gibi paralel decompression desteği olup olmadığı soruluyor. Ya da block magic ön taraması gibi yöntemlerle paralel işleme imkânı bulunup bulunmadığı merak ediliyor. Edit olarak “muhtemelen desteklemiyor” sonucuna varılıyor
• Lbzip2’nin tüm CPU çekirdeklerini kullanarak çok hızlı decompression sağladığına dair deneyim paylaşılıyor. Yıl 2025 olmuşken Python gibi birçok büyük programın hâlâ yalnızca tek çekirdek kullanmasının üzücü olduğu söyleniyor
  • Python tarafındaki durumun iyi anlaşılmadığı belirtiliyor