bzip3

मूल लेख ↗ Hacker News चर्चा ↗

bzip3, bzip2 के Burrows–Wheeler transform से प्रेरित एक आधुनिक कंप्रेसर, कुछ अत्यधिक दोहराव वाले डेटासेट्स पर कभी-कभी zstd और अन्य लोकप्रिय फ़ॉर्मैट्स से बेहतर compression ratio देने के लिए ध्यान आकर्षित कर रहा है। टिप्पणीकार बताते हैं कि इसके फायदे डेटा और पैरामीटर पर बहुत निर्भर हैं, यह भी इंगित करते हैं कि कुछ प्रकाशित बेंचमार्क भ्रामक हैं (जैसे, विंडो आकार का मेल न होना और बहुत अधिक मेमोरी उपयोग), और कुछ वास्तविक-विश्व परीक्षणों में गंभीर डीकंप्रेशन ओवरहेड नोट करते हैं। व्यावहारिक अपनाने को लेकर भी बहस है—zstd के मज़बूत इकोसिस्टम समर्थन, bzip3 के लाइसेंसिंग और नामकरण विकल्पों, और इस तथ्य को देखते हुए कि अब कई उपयोगकर्ता आकार में मामूली लाभों के बजाय तेज़, कम-मेमोरी डीकंप्रेशन को प्राथमिकता देते हैं।

बेंचमार्क और निष्पक्षता

  • कई टिप्पणीकार आधिकारिक बेंचमार्क्स की आलोचना करते हैं कि वे बहुत ही बुनियादी और “चेरी‑पिक्ड” हैं।
  • मुख्य चिंताएँ:
    • bzip3 का परीक्षण बहुत बड़े ब्लॉकों (जैसे, 512 MB) के साथ किया जाता है, जबकि zstd को डिफ़ॉल्ट छोटे विंडो (~8 MB) पर छोड़ दिया जाता है, जो concatenated source trees जैसे दोहराव वाले कॉर्पस पर zstd को गंभीर रूप से नुकसान पहुँचाता है।
    • मेमोरी उपयोग को सामान्यीकृत नहीं किया जाता (जैसे, bzip3 के लिए ~12–18 GB RAM बनाम zstd के लिए <1 GB वाले मामले)।
    • कुछ तुलना में मज़बूत प्रतिस्पर्धियों को छोड़ दिया जाता है (lrzip परीक्षणों में zstd)।
  • जब zstd को मेल खाते लंबे विंडो (--long) के साथ फिर से चलाया जाता है, तो वह रिपोर्ट की तुलना में कहीं छोटा और तेज़ कंप्रेस कर सकता है, और कभी-कभी बड़े अंतर से bzip3 को भी पछाड़ देता है।

वास्तविक-विश्व प्रदर्शन और डेटा पर निर्भरता

  • कई स्वतंत्र परीक्षण दिखाते हैं कि व्यवहार डेटा पर बहुत निर्भर है:
    • कुछ फ़ाइलों पर bzip3, zstd -19 को अनुपात में मात देता है, और गति भी तुलनीय या बेहतर होती है।
    • दूसरों पर zstd आकार में थोड़ा जीतता है और गति में निर्णायक रूप से आगे होता है।
  • Linux kernel tree के लिए, bzip3 का डीकंप्रेशन multi-core zstd की तुलना में लगभग 145× धीमा बताया गया, जबकि कंप्रेशन थोड़ा खराब था।
  • enwik9 टेक्स्ट कॉर्पस पर, bzip3 ने zstd की तुलना में काफी छोटा कंप्रेस किया, लेकिन डीकंप्रेशन के दौरान कई गुणा अधिक RAM और समय उपयोग किया।

संसाधन उपयोग और व्यावहारिक उपयोग के मामले

  • एक बार-बार उभरने वाला विषय: bzip3 प्रभावशाली अनुपात हासिल कर सकता है, लेकिन डीकंप्रेशन बेहद धीमा और मेमोरी-गहन हो सकता है, विशेषकर बड़े ब्लॉकों के साथ।
  • कुछ लोग सुझाव देते हैं कि इसे केवल “एक बार कंप्रेस, कई बार डीकंप्रेस” परिदृश्यों में, प्रति-फ़ाइल एल्गोरिदम ट्यूनिंग के बाद, इस्तेमाल किया जाए।
  • अन्य लोग निष्कर्ष निकालते हैं कि आधुनिक विकल्पों की तुलना में सामूहिक बेंचमार्क्स में यह “बहुत प्रभावशाली नहीं” है।

विकल्प और इकोसिस्टम

  • zstd को बार-बार वर्तमान “go-to” सामान्य-उद्देश्य कंप्रेसर के रूप में वर्णित किया जाता है: अत्यधिक ट्यून करने योग्य, तेज़ डीकंप्रेशन, अच्छे अनुपात, व्यापक समर्थन (फ़ाइल सिस्टम, डेटाबेस)।
  • JSONL लॉग्स पर बेंचमार्क्स में bzip3 सर्वोत्तम अनुपात देता है, लेकिन CPU समय बहुत अधिक लेता है; zstd डिफ़ॉल्ट्स पर gzip जितना लगभग छोटा है लेकिन बाकी सभी से बहुत तेज़ है, और ट्यूनिंग की गुंजाइश भी है।

विश्वसनीयता, लाइसेंसिंग, और नामकरण

  • “डेटा पुनर्प्राप्त न भी हो सके” जैसी कड़ी चेतावनी कुछ लोगों को चिंतित करती है, लेकिन अन्य लोग नोट करते हैं कि यही समान अस्वीकरण bzip2, xz, और सामान्य open-source लाइसेंसों में भी मौजूद हैं।
  • कुछ लोगों को “bzip3” नाम का पुनः उपयोग और bzip2 के permissive लाइसेंस के बजाय LGPL में बदलाव पसंद नहीं आता; अन्य लोग तर्क देते हैं कि नामकरण और लाइसेंसिंग दोनों लेखक का विशेषाधिकार हैं।

भविष्य की दिशाएँ

  • उठाए गए विचार: ऐसे multi-stream archives जो क्षेत्र के अनुसार स्वतः एल्गोरिदम चुनें, ML/agent-आधारित पैरामीटर अनुकूलन, और कंप्रेसर की शुद्धता का formal verification, हालांकि अंतिम को बहुत कठिन माना जाता है।