Rust में लागू Zstandard की घोषणा

• libzstd-rs-sys Trifecta Foundation की zlib और bzip2 के बाद तीसरी compression project है, और zstd की पहली Rust-आधारित release है
• Zstd आधुनिक CPU के लिए अनुकूलित एक compression format है, जो gzip से तेज़ है और compression ratio भी बेहतर देता है, इसलिए उम्मीद है कि यह web traffic में धीरे-धीरे gzip की जगह लेगा
• मौजूदा Rust zstd crate source से C code compile करता है, इसलिए C toolchain और target support की ज़रूरत होती है, जिससे Windows और WebAssembly setup मुश्किल हो सकता है
• Rust implementation को drop-in compatible C library के रूप में compile किया जा सकता है, और test suite, fuzz testing, तथा Miri के ज़रिये C reference implementation के विकल्प को verify किया जा रहा है
• default decompression, C की तुलना में कुछ प्रतिशत धीमी है, लेकिन लगभग 3% performance drop memory safety की लागत है; experimental flag के साथ इसे C performance तक लाया जा सकता है

---

पहली release और Rust implementation का महत्व

• Trifecta Tech Foundation ने zlib और bzip2 के बाद zstd पर काम करने वाले libzstd-rs-sys की पहली release की घोषणा की
• Zstd एक compression format है जिसे आधुनिक CPU को ध्यान में रखकर डिज़ाइन किया गया है, और यह gzip की तुलना में काफ़ी तेज़ है तथा बेहतर compression ratio दे सकता है
• zstd पहले से ही व्यापक रूप से इस्तेमाल हो रहा है, और उम्मीद है कि web traffic में यह धीरे-धीरे gzip की जगह लेगा
• Rust में zstd crate के ज़रिये पहले से zstd इस्तेमाल किया जा सकता है, लेकिन मौजूदा crate source से C code compile करता है, इसलिए target के लिए C toolchain और support चाहिए
• Windows या WebAssembly के लिए C toolchain setup करना कठिन हो सकता है, इसलिए pure Rust implementation, Rust developers को dependency इस्तेमाल करने का बेहतर अनुभव देता है
• libzstd-rs-sys, zlib और bzip2 की तरह drop-in compatible C library के रूप में compile हो सकता है, और इसका लक्ष्य C reference implementation का विकल्प बनना है
• C reference implementation का maintenance Meta करती है और contribution के लिए Meta तथा contributor agreement की ज़रूरत होती है, इसलिए एक स्वतंत्र, performant और compatible implementation open source ecosystem को मज़बूत कर सकती है

verification, performance, और बाकी काम

• शुरुआती reference implementation को c2rust से convert किया गया था, और उसके बाद decompression तथा dictionary builder की cleanup पूरी की गई
• Rust code को C static library में compile करने के बाद reference implementation के test suite से verify किया गया
• fuzz testing और Miri का इस्तेमाल भी implementation की correctness verify करने के लिए किया गया
• prerelease libzstd-rs-sys v0.0.1-prerelease.2 पर उपलब्ध है

• memory safety की लागत

  • default decompression performance, C reference implementation से कुछ प्रतिशत धीमी है
  • main में merge होने वाला हर बदलाव benchmark suite में मापा जाता है
  • unsafe-performance-experimental feature flag चालू करने पर यह C performance के बराबर हो जाती है
  • यह flag उन 4 जगहों पर bounds checks बंद कर देता है जहाँ input data का इस्तेमाल data structure indexing में होता है
  • ज़्यादातर users के लिए लगभग 3% performance drop, बेहतर memory safety के लिए स्वीकार्य लागत होने की संभावना है
  • अगर आख़िरी performance तक चाहिए, तो risk लेकर यह flag चालू किया जा सकता है; इन 4 जगहों का व्यवहार bounds checks न करने वाले C जैसा ही है

• compression implementation और ecosystem integration

  • compression हिस्सा अभी funding की तलाश में है
  • compression और decompression के बीच code sharing है, इसलिए compression code का कुछ हिस्सा देखा गया है, लेकिन ज़्यादातर cleanup अभी बाकी है
  • compression performance regression रोकने के लिए benchmark सेट किए गए हैं, और reference implementation के test suite से सही output बन रहा है या नहीं, यह जाँचा जा रहा है
  • बाकी काम Milestone 4: Encoder implementation में संक्षेपित है
  • एक zstd fork मौजूद है जो C library की जगह libzstd-rs-sys का इस्तेमाल करता है, और भविष्य में इसे upstream में शामिल करने की उम्मीद है
  • सबसे अधिक इस्तेमाल होने वाले API में integration अपेक्षाकृत सरल है
  • experimental feature में zstd-safe enum का इस्तेमाल करता है, लेकिन FFI safety के लिए struct इस्तेमाल करना पड़ता है, जिससे mismatch है

• समर्थन

  • decompression पर काम को Chainguard, Astral, NLnet Foundation ने fund किया है
  • dictionary builder में Sovereign Tech Agency ने निवेश किया है

[GN⁺]

Lobste.rs की राय

• यह सच में बहुत स्वागतयोग्य खबर है। कुछ दिन पहले एक dependency की वजह से zstd build करने के लिए libc-dev खींचना पड़ा था, और मैं सोच रहा था कि क्या किसी ने इसे Rust में गंभीरता से फिर से implement किया है
  उम्मीद है कि community में यह व्यापक रूप से अपनाया जाएगा

• मैं एक WireGuard-आधारित प्रोजेक्ट को Rust में बना रहा हूँ, इसलिए कई Rust crypto libraries ला रहा हूँ। memory safety का साफ़ फायदा है, लेकिन पुरानी C libraries के विपरीत इन सबका security audit हुआ हो, यह ज़रूरी नहीं
  आख़िरकार सवाल यह है कि इन algorithms को Rust में दोबारा लिखना क्या सच में उस लागत के लायक है

  • बिल्कुल लायक है। crypto ज़्यादातर algorithm के टूटने से नहीं, बल्कि implementation bugs की वजह से bypass होता है
    parsing, protocol state, buffer management जैसे “उबाऊ” non-crypto code को सही तरह काम करना ही सिस्टम को सुरक्षित बनाता है। अगर attacker कोई ऐसा जादुई packet भेज सकता है जिससे arbitrary code execution हो जाए, तो वह हज़ारों साल लगने वाले decryption को कुछ दशकों तक लाने वाली उन्नत cryptanalysis या timing side-channel पर मेहनत नहीं करेगा
  • अगर प्रोजेक्ट की performance requirements बहुत ज़्यादा सख़्त नहीं हैं और आप थोड़ा FFI स्वीकार कर सकते हैं, तो Rust में Go crypto stack का इस्तेमाल भी किया जा सकता है
    दोनों तरफ memory safety का फ़ायदा मिलता है, और बस एक संकरी unsafe FFI boundary रखनी पड़ती है। Go crypto libraries इस समय Rust, या अधिक सटीक कहें तो crates.io ecosystem में उपलब्ध विकल्पों की तुलना में ज़्यादा mature हैं

• मुझे जानना है कि -sys और -rs-sys suffix कब इस्तेमाल करने चाहिए, इस पर कोई documented explanation किसी को पता है क्या। मेरी सहज धारणा यह थी कि -sys उन crates के लिए होता है जो Rust में न लिखी गई system libraries को wrap करते हैं
  लेकिन उस ढाँचे में -rs-sys suffix समझ नहीं आता, तो शायद मेरी धारणा ग़लत थी। क्या किसी के पास कोई authoritative source है?

  • इस package का नाम कल्पना की जा सकने वाली हद तक लगभग सबसे खराब रखा गया है। नाम के चार हिस्सों में से तीन ग़लत या अवांछनीय हैं
    *-sys: यह पुरानी और व्यापक convention है, और https://doc.rust-lang.org/cargo/reference/… में समझाई गई है। लेकिन इस crate पर यह बिल्कुल फिट नहीं बैठती
    lib*: हमें पहले से पता है कि यह library है, और Rust में यह prefix conventional नहीं है; ऊपर दिए गए लिंक में भी *-sys के साथ इसे आधे-अधूरे तरीके से टालने की बात कही गई है। libzstd-sys नाम से ऐसा लग सकता है कि यह liblibzstd से link करेगा। वैसे Rust से अलग भी मैंने वास्तव में double lib वाले नाम देखे हैं
    *-rs: जैसा https://rust-lang.github.io/api-guidelines/naming.html में कहा गया है, “हर crate Rust है! उपयोगकर्ता को यह बार-बार याद दिलाने की ज़रूरत नहीं”
  • -sys crates आम तौर पर बहुत raw C-style interfaces expose करते हैं, अंदर unsafe code बहुत होता है, और अक्सर किसी बाहरी library को build या link करते हैं
    -rs-sys नाम का इस्तेमाल मैंने कम consistent तरीके से होते देखा है। लगता है यह उन libraries के लिए इस्तेमाल होता है जो किसी external code को Rust crate के अंदर दोबारा पैक करके build करती हैं, जैसे अभी भी कुछ C हिस्से बची हुई अधूरी Rust implementation, या sys crate के लिए Rust support code
  • इसकी अपनी एक तर्कशृंखला है
    libzstd मूल नाम है। C libraries अक्सर अपने नाम में lib रखती हैं, और Rust/Cargo convention के हिसाब से बदलने के बजाय इसे reference के लिए वैसा ही रखा गया है
    -rs Facebook की C implementation से अलग दिखाने के लिए Rust rewrite को दर्शाता है। कई Rust projects में यह एक आम suffix है, कुछ वैसा ही जैसे Python libraries pysomething जैसा नाम रखती हैं
    -sys इसलिए है क्योंकि यह implementation unsafe C API expose करने वाला drop-in replacement है। Cargo user के नज़रिए से यह Rust library नहीं है। इसमें Rust interface नहीं है; इसे C code की तरह C functions के जरिए call किया जाता है
    इसलिए यह -rs-sys नहीं, बल्कि libzstd-rs का -sys version है

• ruzstd की जगह इसे क्यों चुनें? क्या मौजूदा crate में निवेश करना बेहतर नहीं होगा?

  • ruzstd में compression अभी पूरी तरह implement नहीं हुई है
    1:1 port से, किसी दूसरी codebase पर उतनी ही तेज़ और feature-complete compressor कैसे बनाया जाए यह फिर से खोजने के बजाय, काफ़ी सीधे code conversion के ज़रिए मिलती-जुलती speed और feature parity हासिल की जा सकती है

• “C reference implementation को Meta maintain करता है, और contribution करने के लिए Meta के साथ contributor agreement sign करना पड़ता है”
  यह हाल में पता चली एक दिलचस्प बात थी; Facebook द्वारा maintain की जाने वाली reference zstd implementation भी LLM से code की जा रही है और यह openssl की dependency भी है, इसलिए ज़्यादा alternatives होना मुझे पूरी तरह सही लगता है

• “default settings में हमारी implementation की decompression performance, C reference implementation से कुछ प्रतिशत धीमी है”
  इस प्रोजेक्ट के बारे में जानने के लिए मुझे बस इतना ही काफ़ी है

  • क्या आप थोड़ा और बता सकते हैं कि उस वाक्य से आपका क्या मतलब था?
    संदर्भ के लिए, उद्धृत वाक्य के तुरंत बाद यह लिखा है
    “हालाँकि unsafe-performance-experimental feature flag चालू करने पर यह C performance के बराबर पहुँच जाती है, इसलिए हमें लगता है कि यह performance hit उचित है। यह flag उन चार जगहों पर bounds checks को disable करता है जहाँ input data का इस्तेमाल data structure indexing के लिए होता है। ज़्यादातर users के लिए लगभग 3% performance loss, memory safety में सुधार के बदले स्वीकार्य लागत हो सकती है। अगर आपको सचमुच आख़िरी बूंद तक performance चाहिए, तो आप अपनी ज़िम्मेदारी पर यह flag चालू कर सकते हैं। इन चार स्थानों पर इसका व्यवहार bounds checks के बिना C जैसा ही है, और लगता है कि कई production systems में यह बिना समस्या के काम कर रहा है”