Rust ile geliştirilen Zstandard duyuruldu

 (trifectatech.org)
6 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • libzstd-rs-sys, Trifecta Foundation'ın zlib ve bzip2'nin ardından üçüncü sıkıştırma projesi olup, zstd'nin Rust tabanlı ilk sürümüdür
  • Zstd, modern CPU'lara göre tasarlanmış bir sıkıştırma formatıdır; gzip'ten daha hızlıdır ve daha yüksek sıkıştırma oranı sunar, bu nedenle web trafiğinde gzip'in yerini kademeli olarak alması beklenmektedir
  • Mevcut Rust zstd crate'i C kodunu kaynaktan derlediği için C toolchain ve hedef desteği gerektirir; bu da Windows ve WebAssembly kurulumlarını zorlaştırabilir
  • Rust uygulaması, drop-in uyumlu bir C kütüphanesi olarak derlenebilir ve C referans uygulamasına alternatif olarak test suite, fuzz testleri ve Miri ile doğrulanmaktadır
  • Varsayılan açma performansı C'den birkaç yüzde puan daha yavaştır, ancak yaklaşık %3 performans kaybı bellek güvenliğinin bedelidir; deneysel bir bayrakla C performansına ulaşılabilir

İlk sürüm ve Rust uygulamasının anlamı

  • Trifecta Tech Foundation, zlib ve bzip2'nin ardından, zstd'yi ele alan libzstd-rs-sys'in ilk sürümünü üçüncü sıkıştırma projesi olarak duyurdu
  • Zstd, modern CPU'lar göz önünde bulundurularak tasarlanmış bir sıkıştırma formatıdır ve gzip'ten çok daha hızlı çalışıp daha iyi sıkıştırma oranı sağlayabilir
  • zstd halihazırda yaygın biçimde kullanılmaktadır ve web trafiğinde gzip'in yerini kademeli olarak alması beklenmektedir
  • Rust'ta zstd zaten zstd crate'i ile kullanılabiliyor, ancak mevcut crate C kodunu kaynaktan derlediği için hedefe uygun C toolchain ve hedef desteği gerektiriyor
  • Windows ya da WebAssembly için C toolchain kurmak zor olabildiğinden, saf Rust uygulaması Rust geliştiricileri için daha iyi bir bağımlılık deneyimi sunuyor
  • libzstd-rs-sys, zlib ve bzip2 çalışmalarında olduğu gibi drop-in uyumlu bir C kütüphanesi olarak derlenebiliyor ve C referans uygulamasına alternatif olmayı hedefliyor
  • C referans uygulaması Meta tarafından sürdürülüyor ve katkıda bulunmak için Meta ile katkıcı sözleşmesi imzalamak gerekiyor; bu nedenle bağımsız, yüksek performanslı ve uyumlu bir uygulama açık kaynak ekosistemini güçlendirebilir

Doğrulama, performans ve kalan işler

  • İlk referans uygulama c2rust ile dönüştürüldü; ardından açma ve sözlük oluşturucu için temizlik çalışmaları tamamlandı
  • Rust kodu C statik kütüphanesi olarak derlendikten sonra referans uygulamanın test suite'i ile doğrulandı
  • Fuzz testleri ve Miri de uygulamanın doğruluğunu doğrulamak için kullanıldı
  • Ön sürüm libzstd-rs-sys v0.0.1-prerelease.2 olarak sunuluyor

  • Bellek güvenliğinin maliyeti

    • Varsayılan açma performansı C referans uygulamasından birkaç yüzde puan daha yavaştır
    • main dalına birleştirilen her değişiklik benchmark suite üzerinde ölçülmektedir
    • unsafe-performance-experimental özellik bayrağı açıldığında C performansı ile eşleşir
    • Bu bayrak, girdi verisinin veri yapısı indekslemesinde kullanıldığı 4 noktadaki sınır kontrollerini devre dışı bırakır
    • Kullanıcıların çoğu için yaklaşık %3 performans kaybı, iyileştirilmiş bellek güvenliği karşılığında kabul edilebilir bir bedel olabilir
    • Son performans kırıntısına kadar ihtiyaç duyanlar riski kabul ederek bu bayrağı açabilir; bu 4 noktadaki davranış, sınır kontrolü yapmayan C ile aynıdır

  • Sıkıştırma uygulaması ve ekosistem entegrasyonu

    • Sıkıştırma kısmı için hâlâ fon aranıyor
    • Sıkıştırma ve açma arasında kod paylaşımı bulunduğundan sıkıştırma kodunun bir kısmı da incelendi, ancak temizlik çalışmalarının büyük bölümü hâlâ duruyor
    • Sıkıştırma performansındaki gerilemeyi önlemek için benchmark'lar kuruldu ve referans uygulamanın test suite'i ile doğru çıktı üretip üretmediği kontrol ediliyor
    • Kalan işler Milestone 4: Encoder implementation altında listeleniyor
    • C kütüphanesi yerine libzstd-rs-sys kullanan bir zstd fork'u bulunuyor ve gelecekte bunun upstream'e alınması isteniyor
    • En yaygın kullanılan API'lerde entegrasyon nispeten basit
    • experimental özelliğinde zstd-safe enum kullanırken, FFI güvenliği için struct kullanılması gerekiyor; burada bir uyumsuzluk var

  • Sponsorluk

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Lobste.rs görüşleri

  • Gerçekten sevindirici bir haber. Birkaç gün önce tek bir bağımlılık yüzünden zstd derlemesi yapmak için libc-dev çekmek zorunda kalmıştım ve birinin bunu Rust ile ciddi biçimde yeniden uygulamayı denemiş olup olmadığını merak ediyordum
    Umarım toplulukta yaygın biçimde benimsenir

  • Rust tabanlı bir WireGuard projesi geliştiriyorum, bu yüzden çeşitli Rust kriptografi kütüphanelerini kullanıyorum. Bellek güvenliği gibi açık bir avantaj var ama eski C kütüphanelerinin aksine hepsi güvenlik denetiminden geçmiş değil
    Sonuçta asıl merak ettiğim şey, bu algoritmaları Rust’ta yeniden yazmanın gerçekten bu maliyete değip değmeyeceği

    • Kesinlikle değer. Kripto genellikle algoritmanın kendisi kırıldığı için değil, uygulama hataları nedeniyle aşılır
      Ayrıştırma, protokol durumu, tampon yönetimi gibi “sıkıcı” kripto dışı kodların doğru çalışması, sistemin güvenli olması için şarttır. Saldırganlar, eğer keyfi kod çalıştıran sihirli bir paket gönderebiliyorlarsa, binlerce yıl sürecek çözmeyi birkaç on yıla indiren ileri kriptoanalize ya da zamanlama yan kanallarına uğraşmaz
    • Projenin performans gereksinimleri aşırı sıkı değilse ve biraz FFI yükünü kabul edebiliyorsanız, Rust içinden Go kriptografi yığınını kullanmak da mümkün
      Bunun avantajı, her iki tarafın da bellek güvenli olması ve sadece dar bir unsafe FFI sınırı bırakmanızdır. Go kriptografi kütüphaneleri şu anda Rust’ta, daha doğrusu crates.io ekosisteminde sunulanlardan daha olgun

  • -sys ve -rs-sys son eklerinin ne zaman kullanılması gerektiğini belgeli biçimde açıklayan bir kaynak bilen var mı diye merak ediyorum. Sezgisel olarak -sys’in Rust ile yazılmamış sistem kütüphanelerini saran crate’ler için olduğunu düşünüyordum
    Ama bu çerçevede -rs-sys son eki pek anlamlı gelmiyor, demek ki sezgim yanlıştı. Yetkili bir kaynak bilen var mı?

    • Bu paket adı, hayal edilebilecek ölçüde neredeyse en kötü şekilde seçilmiş. Adı oluşturan dört parçanın üçü yanlış ya da arzu edilir değil
      *-sys: eski ve yaygın bir gelenek; https://doc.rust-lang.org/cargo/reference/… adresinde açıklanıyor. Ama bu crate’e hiç uymuyor
      lib*: bunun bir kütüphane olduğunu zaten biliyoruz, Rust’ta bu önek geleneksel değil ve yukarıdaki bağlantıda da *-sys ile birlikte yarı dolaylı biçimde kaçınılması gerektiği belirtiliyor. libzstd-sys olsa liblibzstd ile linkleneceği düşünülebilir. Ayrıca Rust’tan bağımsız olarak çift lib adına gerçekten rastladım
      *-rs: https://rust-lang.github.io/api-guidelines/naming.html belgesinde dendiği gibi, “Her crate zaten Rust’tır! Kullanıcıya bunu sürekli hatırlatmaya gerek yok”
    • -sys crate’leri genelde oldukça ham bir C tarzı arayüz sunar, içinde bolca unsafe kod bulunur ve çoğu zaman harici bir kütüphaneyi derler ya da linklerler
      -rs-sys adının daha tutarsız kullanıldığını gördüm. Görünüşe göre bir Rust crate’i içinde yeniden paketlenmiş harici kodu derleyen kütüphaneler için kullanılıyor; örneğin hâlâ C parçaları kalan tamamlanmamış Rust uygulamaları ya da sys crate’leri için Rust destek kodları
    • Kendi içinde bir mantığı var
      libzstd asıl isim. C kütüphaneleri adlarında lib bulundurma eğilimindedir; bunu Rust/Cargo geleneklerine göre değiştirmek yerine referans amaçlı olduğu gibi bırakmışlar
      -rs, Facebook’un C uygulamasından ayırmak için bunun bir Rust yeniden yazımı olduğunu gösteriyor. Bu, birçok Rust projesinde yaygın bir genel son ek; Python kütüphanelerinin pysomething gibi adlandırılmasına benziyor
      -sys, bu uygulamanın unsafe C API’sini dışa vuran bir drop-in replacement olmasından geliyor. Cargo kullanıcısının gözünde bu bir Rust kütüphanesi değil. Rust arayüzü yok; C fonksiyonları olan C kodu gibi çağırıyorsunuz
      Yani bu -rs-sys değil, libzstd-rs’nin -sys sürümü

  • Neden ruzstd yerine bu tercih edilmeli? Mevcut crate’e yatırım yapmak daha iyi olmaz mı?

    • ruzstd’de sıkıştırma henüz tam olarak uygulanmış değil
      Bire bir port, başka bir kod tabanı üzerinde aynı derecede hızlı ve eksiksiz bir sıkıştırıcıyı nasıl yapacağını yeniden keşfetmek yerine, nispeten düz bir kod dönüşümüyle benzer hız ve özellik eşdeğerliği sağlamayı mümkün kılıyor

  • “C referans uygulaması Meta tarafından yönetiliyor ve katkıda bulunmak için Meta ile bir katkıcı sözleşmesi imzalamanız gerekiyor”
    Yakın zamanda öğrendiğim ilginç bir ayrıntı da şu: Facebook’un yönettiği referans zstd uygulaması da LLM ile kodlanıyor ve openssl’in bağımlılıkları arasında yer alıyor; dolayısıyla daha fazla alternatif çıkmasına tamamen olumlu bakıyorum

  • “Varsayılan ayarlarda, bizim uygulamamızın açma performansı C referans uygulamasından birkaç yüzde puan daha yavaş”
    Bu proje hakkında bilmem gereken tek şey bu

    • Bu cümlenin sana tam olarak ne ifade ettiğini biraz daha açıklar mısın?
      Bu arada, alıntıladığın cümlenin hemen ardından şu geliyor
      “Ancak unsafe-performance-experimental özellik bayrağını açarsanız C performansına ulaşılıyor; bu yüzden bu performans kaybının gerekçelendirilebilir olduğunu düşünüyoruz. Bu bayrak, girdi verisinin veri yapısı indekslemesinde kullanıldığı dört yerde sınır kontrolü yapılan 4 denetimi kapatıyor. Kullanıcıların çoğu için yaklaşık %3’lük performans kaybı, daha yüksek bellek güvenliği karşılığında kabul edilebilir bir bedel olacaktır. Gerçekten son damla performansa ihtiyacınız varsa, bu bayrağı kendi sorumluluğunuzda açabilirsiniz. Bu dört noktadaki davranış, sınır kontrolü yapmayan C ile aynıdır ve birçok üretim sisteminde sorunsuz çalıştığı görülmektedir”