• bzip2 crate 0.6.0 ने bzip2 algorithm के Rust implementation libbz2-rs-sys को default के रूप में अपनाया है, जिससे C dependency हट गई है और speed के साथ cross-compilation की सुविधा भी बेहतर हुई है
  • bzip2 एक पुराना algorithm है जिसका इस्तेमाल घट रहा है, लेकिन कई protocols और libraries को specification compliance के लिए अभी भी इसे support करना पड़ता है, इसलिए यह dependency tree की गहराई में बना हुआ है
  • Rust implementation ने compression में C की तुलना में लगभग 9.66~14.87% कम CPU cycles इस्तेमाल किए, और decompression में भी सभी tests में 4.48~10.00% सुधार हुआ
  • C हटने से WebAssembly, Windows, Android builds सरल हो गए हैं, और default रूप से libbz2-rs-sys symbols export नहीं करता, जिससे अन्य dependencies के साथ symbol collision का जोखिम भी घटता है
  • audit में एक off-by-one logic bug और fuzzer limits के कुछ हिस्से ठीक किए गए, और bzip2 इस्तेमाल करने वाली higher-level libraries और applications भी MIRI पर चलाए जा सकते हैं

bzip2 0.6.0 के default implementation में बदलाव

  • bzip2 crate 0.6.0 अब bzip2 algorithm के Rust implementation libbz2-rs-sys को default रूप से इस्तेमाल करता है
  • मौजूदा C dependency हटाने के साथ bzip2 crate तेज और cross-compile करना आसान हो गया है
  • libbz2-rs-sys crate को C dynamic library के रूप में build किया जा सकता है, ताकि C projects भी सुधारों का फायदा उठा सकें
  • bzip2 का आज बहुत ज्यादा इस्तेमाल नहीं होता, लेकिन कई protocols और libraries को specification compliance के लिए अभी भी इसे support करना पड़ता है, और यह कई projects के dependency tree की गहराई में मौजूद है
  • implementation details पिछले लेख Translating bzip2 with c2rust में देखी जा सकती हैं

Performance सुधार के नतीजे

  • Rust implementation आम तौर पर C implementation से तेज है, और कुछ मामलों में C performance के बराबर है
    • ज्ञात range में वास्तव में धीमा होने का कोई case नहीं है
  • compression benchmarks में C की तुलना में CPU cycles कम हुए
    • sample3.ref level 1: 38.51M33.53M, -14.87%
    • silesia-small.tar level 1: 3.43G3.00G, -14.30%
    • silesia-small.tar level 9: 3.47G3.17G, -9.66%
    • bzip2 का level work memory usage को दर्शाता है और performance पर बड़ा असर नहीं डालता
    • sample3.ref level 1 पर ही file size से ज्यादा memory allocate कर देता है, इसलिए higher level ज्यादा relevant नहीं हैं
  • decompression performance भी tests में overall बेहतर हुई
    • sample3.bz2: -4.48%
    • sample1.bz2: -8.63%
    • sample2.bz2: -7.67%
    • dancing-color.ps.bz2: -5.17%
    • re2-exhaustive.txt.bz2: -7.65%
    • zip64support.tar.bz2: -10.00%
  • macOS benchmark machine पर decompression performance numbers कभी-कभी कम आते हैं
    • कारण पता नहीं चला, और macOS पर perf जैसे performance tracing को automate करने वाले tools चलाना मुश्किल था

Build और symbol collision में कमी

  • C dependency वाले Rust projects का cross-compilation cc crate की वजह से अक्सर सीधे काम कर जाता है, लेकिन fail होने पर errors debug करना मुश्किल हो सकता है
    • system library linking भी उलझन भरी और reproduce करने में कठिन समस्याएं पैदा कर सकती है
    • bzip2 का WebAssembly compilation काफी समय से समस्या रहा है
    • C dependency हटाकर सिर्फ Rust code इस्तेमाल करने से WebAssembly, Windows, Android builds का काम करना आसान हो गया है
  • libbz2-rs-sys default रूप से symbols export नहीं करता
    • C dependency इस्तेमाल करने पर symbols export करने पड़ते हैं ताकि Rust extern block उन्हें ढूंढ सके
    • exported names तब collide कर सकते हैं जब कोई दूसरी dependency वही symbols declare करे
    • अगर किसी Rust project को symbol export की जरूरत हो, तो इसे feature flag से enable किया जा सकता है

Verification और audit नतीजे

  • performant bzip2 implementation में कुछ unsafe code की जरूरत होती है, और C interface को Rust में replicate करने के लिए और ज्यादा unsafe code शामिल होता है
    • यह code MIRI में चलाया जा सकता है
    • bzip2 इस्तेमाल करने वाली high-level libraries या applications भी अब MIRI से चलाए जा सकते हैं
  • audit में एक off-by-one logic bug मिला और fuzzer limits के कुछ हिस्से ठीक किए गए
    • इसके अलावा कोई महत्वपूर्ण finding नहीं थी
    • audit Radically Open Security ने किया, और पूरी report audit report PDF में देखी जा सकती है
  • इस काम में bzip2 crate के maintainer Alex Crichton, audit और expertise देने वाली Radically Open Security, और e-Commons Fund के जरिए funding देने वाली NLnet Foundation की मदद मिली

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.