bzip2 Crate अब C से 100% Rust में बदल गया

• bzip2 crate ने C code dependency को 100% Rust implementation से बदल दिया है
• performance पहले की तुलना में कुल मिलाकर बेहतर हुई है, और cross-compilation भी आसान हो गया है
• Rust implementation में C version की तुलना में data compression और decompression, दोनों की speed बेहतर हुई है
• symbol collision जैसी library dependency समस्याएँ काफी कम हो गई हैं
• security audit के बाद महत्वपूर्ण logic bug ठीक किए गए, और stability की पुष्टि हुई है

---

bzip2 crate 0.6.0 रिलीज़ और Rust-आधारित बदलाव

• आज bzip2 version 0.6.0 जारी किया गया
• अब यह डिफ़ॉल्ट रूप से स्वयं विकसित Rust-आधारित bzip2 algorithm implementation libbz2-rs-sys का उपयोग करता है
• इस बदलाव से bzip2 crate और तेज़ हो गया है, और cross-compilation आसान हुई है

• libbz2-rs-sys crate को C dynamic library के रूप में भी build किया जा सकता है। इससे C projects भी performance improvement का लाभ उठा सकते हैं

यह बदलाव क्यों किया गया?

• bzip2 algorithm 90 के दशक में बना था और आज बहुत व्यापक रूप से उपयोग नहीं होता, लेकिन कई protocols और libraries में अब भी spec compliance के लिए इसकी ज़रूरत होती है
• कई projects सीधे नहीं, लेकिन dependency tree की किसी गहराई में bzip2 पर निर्भर हैं
• हमने zlib-rs से मिले अनुभव के आधार पर इस बार bzip2 implementation को modernize किया है

• libbz2-rs-sys के implementation details पर पिछली blog post में चर्चा की गई थी। यहाँ हम इस बदलाव के फायदों को देखते हैं

बेहतर performance

• Rust implementation कुल मिलाकर C version से बेहतर performance दिखाती है
• कुछ परिस्थितियों में performance समान है, लेकिन कहीं भी यह धीमी नहीं है

• compression performance: bzip2 में level option होता है, लेकिन performance पर उसका असर बहुत कम है
• test results में representative sample files पर Rust version ने 10% से अधिक speed improvement दिखाया

compression:

फ़ाइल	C(साइकिल)	Rust(साइकिल)	सापेक्ष बदलाव
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%

decompression में भी हर मामले में performance बेहतर रही:

फ़ाइल	C(साइकिल)	Rust(साइकिल)	सापेक्ष बदलाव
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%

हालाँकि, macOS वातावरण में कभी-कभी decompression के आँकड़ों में बदलाव दिखता है। performance measurement tool की सीमाओं के कारण इसका विश्लेषण कठिन था

cross-compilation support

• C dependency वाले Rust projects में cross-compilation आमतौर पर cc crate की वजह से काम कर जाती है, लेकिन असफल होने पर debugging बहुत कठिन हो जाती है
• system library linking के दौरान अप्रत्याशित समस्याएँ आ सकती हैं, और WebAssembly build सहित कुछ environments में यह वास्तविक बाधा बन जाता है

• Rust implementation में बदलने से C-संबंधित समस्याएँ पूरी तरह समाप्त हो गईं

• अब Windows, Android, WebAssembly आदि में भी बिना किसी विशेष समस्या के cross-compilation संभव है
• यह सिर्फ user experience ही नहीं, maintenance के नज़रिए से भी बड़ा फायदा है

डिफ़ॉल्ट रूप से symbol(export) collision नहीं

• C dependency के मामले में Rust external block से symbols export करने पड़ते हैं, इसलिए अगर कोई दूसरी dependency वही symbol export करे तो collision हो सकती है
• libbz2-rs-sys को डिफ़ॉल्ट रूप से symbols export न करने के लिए design किया गया है
• इसलिए दूसरी external libraries के साथ symbol collision होने की संभावना नहीं रहती। ज़रूरत हो तो feature flag से export को सक्षम किया जा सकता है

MIRI-आधारित test execution

• Rust में bzip2 को high-performance तरीके से implement करने के लिए unsafe code का उपयोग अपरिहार्य है, और C interface को दोहराने के लिए भी काफी unsafe code चाहिए
• अच्छी बात यह है कि इस code को MIRI environment में चलाकर test किया जा सकता है

• इससे आगे बढ़कर, bzip2 का उपयोग करने वाली higher-level libraries या applications भी अब MIRI testing कर सकती हैं

निष्कर्ष

अब bzip2 crate और तेज़ हो गया है। इतना कि अब इस पर अलग से ध्यान देने की ज़रूरत भी नहीं पड़ती, और स्वाभाविक रूप से बेहतर अनुभव मिलता है

[GN⁺]

Hacker News टिप्पणियाँ

• Trifecta Tech के implementation के Linux distributions में उपयोग होने वाले official implementation को replace करने की संभावना को देखें तो, पहले Fedora ने legacy Adler zlib से zlib-ng पर switch किया था, इसलिए यह असंभव नहीं लगता। मुख्य बात यह है कि original के साथ compatible C ABI उपलब्ध कराना होगा
  • अगर 2019 के बाद से कोई upstream release नहीं हुई है, तो सवाल उठता है कि क्या यह implementation बस पहले से ही complete नहीं है। अगर अब fix करने के लिए bug या जोड़ने के लिए feature नहीं हैं, तो वह अपने आप में पर्याप्त हो सकता है
  • Ubuntu Rust में लिखे गए sudo का उपयोग करता है, इसलिए ऐसा replacement पूरी तरह संभव लगती है
  • Trifecta Tech C ABI को compatibility के साथ अच्छी तरह दे रहा है, लेकिन अंततः किसी को यह काम वास्तव में लागू करना होगा, तभी बदलाव होगा
  • यह भी कहा गया कि uutils का लक्ष्य भी ऐसे official replacement बनना है, और uutils homepage का link साझा किया गया
  • जल्दी से देखने पर cargo-c configuration पहले से मौजूद है, इसलिए बात सकारात्मक लगती है, लेकिन namespace अलग होने की वजह से C programs में इसे existing libbz2 के रूप में automatically detect नहीं किया जाएगा। bzip2 के symbols से परिचित न होने के कारण exact ABI compatibility का आकलन कठिन बताया गया। GNU operating system implementation को सीधे maintain करना बहुत समय लेने वाला काम है, इसलिए जब समय मिले तो experimental project platypos में PR का स्वागत है
• मैं इस crate का उपयोग करके सैकड़ों TB Common Crawl data process कर रहा हूँ। speed बढ़ने से मैं बहुत संतुष्ट हूँ
  • यहाँ bz2 उपयोग करने की वजह पर सवाल उठाया गया। कहा गया कि अगर बड़े पैमाने का conversion केवल एक बार करना हो, तो zstd पर switch करने का लाभ काफी बड़ा है, और बेहतर compression ratio पर यह लगभग हर मायने में bzip2 से बेहतर है
  • यह भी पूछा गया कि क्या Common Crawl data torrent के रूप में उपलब्ध है
  • compression speed में 14% सुधार काफी शानदार लगा
• यह जानने की जिज्ञासा कि क्या यह implementation default रूप से बचे हुए 11 CVE को fix करती है। विडंबना यह भी बताई गई कि bzip2 crate पर भी CVE report हुए थे, और संबंधित link साझा किया गया
  • उस crate में report हुई ‘बड़ी files पर runtime failure’ जैसी vulnerability और C में लिखे implementation की ‘bounds miss’ समस्या के बीच का contrast दिलचस्प बताया गया। यह भी पूछा गया कि क्या ऐसे bound miss vulnerabilities वास्तव में code execution तक पहुँच सकती हैं
  • ‘bzip2 crate 0.4.4 से पहले के versions में vulnerable है’ यह advisory उद्धृत की गई। साथ में यह अतिरिक्त जानकारी भी दी गई कि आज 0.6.0 release हुआ है
• ‘90s के algorithm को आखिर क्यों improve करना’ वाले सवाल के जवाब में, यह जिज्ञासा जताई गई कि आजकल कौन से algorithms इस्तेमाल होते हैं। zstd का उल्लेख करते हुए compression algorithm benchmark का link साझा किया गया
• अगर C और Rust दोनों के compiler code generation backend एक जैसे हैं, तो speedup कैसे आया, इस पर सवाल उठा। Rust के auto-simd, manual optimization, या नई optimization libraries जैसे कई संभावित कारण बताए गए
  • एक अनुमान यह था कि Rust code generator को अधिक hints दे सकता है। उदाहरण के तौर पर, C pointers की तुलना में aliasing की समस्या की कम चिंता करनी पड़ती है। Aliasing explanation link दिया गया
  • यह राय भी आई कि modern high-performance code लिखने के लिहाज से C भाषा वास्तव में बहुत अच्छी नहीं है। C99 से C21 तक लगभग 20 वर्षों में भाषा में ऐसे features की कमी रही जो नए instructions (clz, popcnt, clmul, pdep आदि) को साफ-सुथरे तरीके से उपयोग करने में मदद करें। कहा गया कि ऐसे abstracted instruction support से इस तरह के code optimization में बहुत मदद मिलती है
  • यह भी कहा गया कि किसी भी language में rewrite करने से speed सुधारने के मौके मिलते हैं; यह Rust की कोई विशिष्ट speed guarantee नहीं है
• उम्मीद जताई गई कि Nana या Prossimo भी core internet protocols (BGP, OSPF, RIP आदि), routing implementations, और DNS servers को इसी तरह rewrite करें
  • पिछले कुछ वर्षों में Rust जैसी safe languages में internet और OS के core tools को rewrite करने के लिए support देने वाले funds का परिचय दिया गया, जैसे NLnet project और Sovereign Tech Fund। उदाहरण के रूप में BGP in Rust project का भी उल्लेख किया गया
  • Memory Safety Initiative में TLS और DNS जैसी core services के safe rewrites के प्रयासों का परिचय है, जो इस सुझाव के कुछ संदर्भ से मेल खाता है
  • एक developer ने SPARK Ada में Ironsides DNS बनाया है, और यह भाषा अधिक मजबूत formal proofs को support करती है
• यह राय आई कि macOS पर perf profiler न होने पर भी dtrace से पर्याप्त performance analysis किया जा सकता है। Perl में लिखी original flame graph script ने भी dtrace का उपयोग किया था, और Rust में reimplement की गई flame graph भी यही तरीका अपनाती है। cache miss या micro instruction retired जैसे कुछ metrics की कमी है, लेकिन यह फिर भी बहुत उपयोगी है
• मज़ाक में कहा गया कि अब Rust को Javascript में फिर से लिखने की ज़रूरत है
• यह पूछा गया कि क्या lbzip2 की तरह parallel decompression support है। या block magic pre-scan जैसी तकनीकों से parallel processing संभव है। edit में जोड़कर निष्कर्ष निकाला गया कि ‘शायद support नहीं है’
• Lbzip2 के साथ सभी CPU cores का उपयोग करके बहुत तेज decompression speed मिलने का अनुभव साझा किया गया। यह अफसोस भी जताया गया कि 2025 आ गया, लेकिन Python जैसे कई प्रमुख programs अब भी केवल 1 core का उपयोग करते हैं
  • Python की स्थिति को ठीक से न समझ पाने की बात कही गई