Zlib-rs is faster than C

Original Article ↗ Hacker News Discussion ↗

Performance and Benchmarks

  • Many point out the Rust implementation is only slightly faster than zlib-ng and argue “as fast as” is more accurate, though still impressive given zlib-ng’s extensive optimization history.
  • Others emphasize that even a few percent near theoretical limits is meaningful, especially for ubiquitous libraries.
  • There is concern the comparison is incomplete: zlib-ng is already heavily hand‑tuned (including assembly), libdeflate and other C libraries may be faster, and compilation/CPU-feature configuration for zlib-ng is not fully specified.
  • Several commenters warn against over-interpreting microbenchmarks and stress that greenfield rewrites in any language often outperform mature code simply due to redesign.

Language vs Implementation

  • A recurring theme: this result is “implementation X faster than implementation Y,” not “Rust faster than C.”
  • Some argue it still “says something” about Rust if developers can more readily achieve high performance while also getting safety guarantees and better maintainability.
  • Others insist the performance gap largely reflects engineering effort and design choices, not inherent language speed.

Unsafe Rust and Safety Guarantees

  • The codebase uses a lot of unsafe, plus raw pointers, manual allocation, and SIMD intrinsics, leading some to say it “looks like C in Rust syntax” and is not representative of idiomatic safe Rust.
  • Defenders respond:
    • Unsafe Rust still benefits from Rust’s type system, borrow checker, and tooling (e.g., Miri, sanitizers); most of the program remains in safe Rust.
    • Unsafe blocks localize potential UB: you audit those areas (and their invariants) instead of the entire codebase.
    • Even within unsafe, using references and slices encodes invariants that do not exist in C.
  • Skeptics counter that large amounts of unsafe erode these benefits, that unsafe Rust is hard to get right, and that at scale you still rely heavily on tooling and discipline.

SIMD, Compilers, and Aliasing

  • Performance gains largely come from SIMD and careful layout; Rust uses LLVM like Clang, so backend optimizations are similar.
  • Rust’s default non-aliasing references and stronger semantics can enable better auto-vectorization than C’s baseline, unless C uses restrict and similar annotations correctly.
  • SIMD in Rust currently often requires unsafe intrinsics; there is ongoing work toward safe, portable SIMD APIs.

Broader Context

  • Some note that zlib itself is old and deliberately portable rather than fastest; modern alternatives like zstd or LZ4 can be both faster and better-compressing where protocols allow.
  • Overall sentiment: zlib-rs is a technically impressive proof that a mostly safe Rust implementation can match or slightly beat a heavily optimized C zlib, but it is not definitive evidence that “Rust the language is generically faster than C.”