Crate bzip2 Beralih dari C ke Rust 100%

• Crate bzip2 menggantikan ketergantungan kode C dengan implementasi 100% Rust
• Performa secara keseluruhan meningkat dibanding sebelumnya, dan cross-compilation menjadi lebih mudah
• Implementasi Rust meningkatkan kecepatan kompresi dan dekompresi data dibanding versi C
• Masalah dependensi library seperti konflik simbol berkurang drastis
• Setelah melalui audit keamanan, bug logika penting diperbaiki dan stabilitasnya tervalidasi

---

Rilis bzip2 crate 0.6.0 dan peralihan ke basis Rust

• Hari ini bzip2 versi 0.6.0 telah dirilis
• Kini secara default menggunakan libbz2-rs-sys, implementasi algoritme bzip2 berbasis Rust yang dikembangkan sendiri
• Melalui peralihan ini, crate bzip2 menjadi lebih cepat dan cross-compilation menjadi lebih mudah

• Crate libbz2-rs-sys juga dapat dibangun dalam bentuk library dinamis C. Dengan ini, proyek C juga bisa memanfaatkan peningkatan performa

Mengapa peralihan ini dilakukan?

• Algoritme bzip2 dibuat pada tahun 90-an dan kini tidak lagi banyak digunakan secara luas, tetapi masih dibutuhkan di berbagai protokol dan library untuk kepatuhan spesifikasi
• Banyak proyek bergantung pada bzip2, bukan secara langsung, melainkan di suatu titik jauh di dalam pohon dependensi
• Berdasarkan pengalaman yang dibangun dari zlib-rs, kali ini implementasi bzip2 dimodernisasi

• Detail implementasi libbz2-rs-sys dibahas dalam posting blog sebelumnya. Di sini kita melihat manfaat dari peralihan ini

Peningkatan performa

• Implementasi Rust secara keseluruhan menunjukkan performa lebih tinggi daripada versi C
• Dalam beberapa situasi performanya setara, tetapi tidak ada kasus yang lebih lambat

• Performa kompresi: pada bzip2 ada opsi level, tetapi pengaruhnya terhadap performa kecil
• Hasil pengujian menunjukkan bahwa pada file sampel representatif, versi Rust mengalami peningkatan kecepatan lebih dari 10%

Kompresi:

File	C(siklus eksekusi)	Rust(siklus eksekusi)	Perubahan relatif
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%

Pada dekompresi juga terlihat peningkatan performa di semua kasus:

File	C(siklus eksekusi)	Rust(siklus eksekusi)	Perubahan relatif
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%

Namun, di lingkungan macOS kadang muncul perubahan angka dekompresi. Sulit dianalisis karena keterbatasan alat pengukuran performa

Dukungan cross-compilation

• Cross-compilation untuk proyek Rust yang memiliki dependensi C biasanya berjalan baik berkat crate cc, tetapi jika gagal sangat sulit untuk di-debug
• Dalam proses penautan system library, masalah tak terduga mudah muncul, dan pada beberapa lingkungan termasuk build WebAssembly hal ini menjadi hambatan nyata

• Dengan beralih ke implementasi Rust, masalah terkait C hilang sepenuhnya

• Kini cross-compilation dapat dilakukan di Windows, Android, WebAssembly, dan lainnya tanpa kendala khusus
• Ini merupakan keuntungan besar bukan hanya dari sisi pengalaman pengguna, tetapi juga dari sisi pemeliharaan

Secara default tidak ada konflik simbol (export)

• Pada dependensi C, simbol harus diekspor dari blok eksternal Rust, sehingga konflik dapat terjadi bila dependensi lain mengekspor simbol yang sama
• libbz2-rs-sys dirancang agar secara default tidak mengekspor simbol
• Karena itu, konflik simbol dengan library eksternal lain tidak akan terjadi. Jika diperlukan, ekspor dapat diaktifkan melalui feature flag

Menjalankan pengujian berbasis MIRI

• Untuk mengimplementasikan bzip2 dengan performa tinggi di Rust, penggunaan kode unsafe tidak dapat dihindari, dan banyak kode unsafe juga diperlukan untuk mereplikasi antarmuka C
• Untungnya, kode ini dapat dijalankan dan diuji di lingkungan MIRI

• Lebih jauh lagi, library atau aplikasi level atas yang menggunakan bzip2 kini juga dapat menjalankan pengujian MIRI

Kesimpulan

Sekarang crate bzip2 menjadi lebih cepat. Ia memberikan pengalaman yang lebih baik secara alami, sampai-sampai Anda tak perlu lagi memikirkannya

[GN⁺]

Komentar Hacker News

• Ada pendapat bahwa jika melihat kemungkinan implementasi Trifecta Tech menggantikan implementasi resmi yang dipakai distribusi Linux, hal itu bukan sesuatu yang mustahil, mengingat dulu Fedora pernah mengganti Adler zlib lama dengan zlib-ng. Intinya, cukup menyediakan C ABI yang kompatibel dengan versi asli
  • Jika memang tidak ada rilis upstream sejak 2019, muncul pertanyaan apakah implementasi ini sebenarnya sudah bisa dianggap selesai. Jika tidak ada lagi bug yang perlu diperbaiki atau fitur yang perlu ditambahkan, mungkin itu sendiri sudah cukup
  • Karena Ubuntu menggunakan sudo yang ditulis dalam Rust, penggantian seperti ini terasa cukup mungkin terjadi
  • Trifecta Tech memang sudah menyediakan C ABI dengan kompatibilitas yang baik, tetapi pada akhirnya perubahan baru akan terjadi jika ada seseorang yang benar-benar melakukan pekerjaan tersebut
  • Disebutkan bahwa tujuan uutils juga mengarah pada penggantian resmi semacam ini, sambil membagikan tautan situs uutils
  • Setelah melihat sekilas, tampaknya sudah ada konfigurasi cargo-c sehingga terlihat menjanjikan, tetapi karena namespace-nya berbeda, program C tidak akan otomatis mendeteksinya sebagai libbz2 lama. Karena tidak terlalu akrab dengan simbol bzip2, sulit memastikan sejauh mana kompatibilitas ABI-nya. Mengelola implementasi sistem operasi GNU sendiri memakan banyak waktu dan sulit dilakukan, dan jika ada waktu, PR untuk proyek eksperimental platypos dipersilakan
• Saya sedang memakai crate ini untuk memproses ratusan TB data Common Crawl. Saya sangat puas karena kecepatannya meningkat
  • Muncul pertanyaan mengapa di sini masih memakai bz2. Jika hanya ingin melakukan konversi data besar satu kali, katanya beralih ke zstd memberi banyak keuntungan, dan untuk rasio kompresi yang tinggi pun zstd lebih baik daripada bzip2 dalam hampir semua hal
  • Ada yang penasaran apakah data Common Crawl tersedia dalam bentuk torrent
  • Kesan bahwa peningkatan kecepatan kompresi sebesar 14% itu cukup hebat
• Ada yang penasaran apakah implementasi ini pada dasarnya menyelesaikan 11 CVE yang masih tersisa. Secara ironis, disebut juga bahwa crate bzip2 sendiri pernah memiliki laporan CVE, sambil membagikan tautan terkait
  • Ada pendapat bahwa menarik untuk membandingkan kerentanan jenis “gagal saat runtime pada file besar” yang dilaporkan pada crate tersebut dengan masalah “bounds miss” pada implementasi C. Muncul pertanyaan apakah kerentanan bounds miss seperti itu benar-benar bisa sampai menyebabkan eksekusi kode
  • Dikutip keterangan bahwa “crate bzip2 rentan pada versi sebelum 0.4.4”. Ditambahkan pula informasi bahwa hari ini dirilis versi 0.6.0
• Menanggapi pertanyaan “mengapa repot-repot meningkatkan algoritma era 90-an”, ada yang penasaran algoritma apa yang sekarang umum dipakai. Disebut zstd sambil membagikan tautan benchmark perbandingan algoritma kompresi
• Ada yang penasaran bagaimana peningkatan performa bisa terjadi jika backend codegen kompiler C dan Rust yang dipakai sama. Kemungkinan penyebabnya bisa bermacam-macam, seperti auto-SIMD Rust, optimasi manual, atau pemanfaatan pustaka optimasi baru
  • Sebatas dugaan, Rust bisa memberi lebih banyak petunjuk kepada code generator. Contohnya, tidak perlu terlalu khawatir soal masalah aliasing seperti pada pointer C. Dibagikan tautan penjelasan aliasing
  • Ada pendapat bahwa bahasa C memang sangat kurang cocok untuk menulis kode modern berperforma tinggi. Dari C99 sampai C21, selama sekitar 20 tahun, bahasa itu sendiri dinilai kekurangan cara yang rapi untuk memanfaatkan instruksi baru seperti clz, popcnt, clmul, pdep, dan lainnya. Dukungan untuk abstraksi instruksi semacam ini dinilai sangat membantu optimasi kode jenis tersebut
  • Menulis ulang dalam bahasa apa pun bisa membuka peluang peningkatan performa, jadi bukan berarti Rust memiliki jaminan kecepatan yang unik
• Ada harapan agar saya atau Prossimo menulis ulang dengan pendekatan serupa protokol internet inti (BGP, OSPF, RIP, dan sebagainya), implementasi routing, server DNS, dan lain-lain
  • Diperkenalkan pula dana yang beberapa tahun terakhir mendukung penulisan ulang alat inti internet dan OS dalam bahasa aman seperti Rust, yaitu proyek NLnet dan Sovereign Tech Fund. Sebagai contoh, turut disebut proyek BGP in Rust
  • Memory Safety Initiative juga memperkenalkan upaya penulisan ulang aman untuk layanan inti seperti TLS dan DNS, sehingga sebagian konteksnya sejalan dengan usulan tadi
  • Seorang pengembang disebut membuat Ironsides DNS dengan SPARK Ada, bahasa yang mendukung pembuktian formal yang lebih kuat
• Ada pendapat bahwa di macOS, meski tidak ada profiler perf, analisis performa masih cukup bisa dilakukan dengan dtrace. Skrip flame graph orisinal yang ditulis dalam Perl juga memanfaatkan dtrace, dan flame graph yang diimplementasikan ulang dalam Rust pun memakai pendekatan yang sama. Beberapa metrik seperti cache miss atau micro instruction retired memang kurang tersedia, tetapi tetap sangat berguna
• Ada komentar bercanda bahwa Rust perlu ditulis ulang lagi ke dalam Javascript
• Ada yang penasaran apakah ini mendukung dekompresi paralel seperti lbzip2, atau apakah pemrosesan paralel dimungkinkan lewat pre-scan block magic dan sejenisnya. Setelah diedit, kesimpulannya adalah “sepertinya tidak didukung”
• Dibagikan pengalaman bahwa Lbzip2 menunjukkan kecepatan dekompresi yang sangat tinggi dengan memanfaatkan semua inti CPU. Disayangkan bahwa meski sudah tahun 2025, banyak program utama seperti Python masih hanya memanfaatkan 1 inti
  • Ada yang menanggapi bahwa situasi Python tidak terlalu dipahami