Zlib-rs es más rápido que C

• zlib-rs es una implementación de zlib basada en Rust para compresión de datos, y recientemente se lanzó la versión 0.4.2 con una gran mejora de rendimiento
• Actualmente es la implementación de zlib compatible con la API más rápida, y destaca especialmente en el rendimiento de la descompresión frente a productos competidores
• Principales mejoras de rendimiento: selección automática en tiempo de ejecución de la implementación SIMD óptima, aplicación de optimización DFA, entre otras

Multiversionado (Multiversioning)

• En tiempo de ejecución, selecciona automáticamente la versión de función más rápida según la CPU
• En Rust no hay soporte de multiversionado por defecto, así que debe implementarse manualmente
• Ofrece rendimiento óptimo minimizando la sobrecarga en tiempo de ejecución del código

Optimización DFA (Deterministic Finite Automata)

• El lenguaje C mejora el rendimiento usando fallthrough implícito en sentencias switch
• Rust no tiene un mecanismo similar, lo que provoca una caída de rendimiento
• Se aplicó la opción de LLVM -Cllvm-args=-enable-dfa-jump-thread → se recuperó el rendimiento
• No está incluida en la configuración predeterminada de LLVM, pero se prevé que en el futuro venga activada por defecto en Rustc

Comparación de rendimiento en benchmarks

1. Comparación de rendimiento frente a zlib-ng

• zlib-rs muestra un rendimiento superior a zlib-ng en la mayoría de los tamaños de entrada
• En particular, es aproximadamente 10% más rápido con entradas de 1KB y aproximadamente 6% más rápido con entradas de 65KB
• En los tamaños de entrada más pequeños queda ligeramente detrás, pero en general tiene ventaja de rendimiento

Por ejemplo:

• Cuando el tamaño de entrada es de 4 bytes, zlib-ng es ligeramente más rápido, pero en uso real el impacto es menor
• Cuando el tamaño de entrada es de 1KB, zlib-rs es aproximadamente 10% más rápido
• Cuando el tamaño de entrada es de 65KB, zlib-rs es aproximadamente 6% más rápido

→ Ventaja clara de rendimiento frente a zlib-ng en chunks grandes

2. Comparación de rendimiento frente a zlib-chromium

• En chunks pequeños, zlib-chromium es más rápido
• Pero en chunks grandes, zlib-rs lleva la ventaja
• zlib-rs ofrece mejor rendimiento en entradas de tamaño habitual

Por ejemplo:

• Cuando el tamaño de entrada es de 4 bytes, zlib-chromium es aproximadamente 12% más rápido
• Cuando el tamaño de entrada es de 16 bytes, zlib-chromium es aproximadamente 6% más rápido
• Cuando el tamaño de entrada es de 1KB o más, zlib-rs tiene ventaja de rendimiento

→ zlib-rs rinde mejor en tamaños habituales

Comparación de rendimiento de compresión

• El rendimiento de compresión sigue mejorando, pero los resultados son mixtos
• Mejora de 6% en el nivel de compresión predeterminado (6) y mejora de rendimiento de 13% en el nivel de compresión máximo (9)
• En otros niveles de compresión, zlib-ng sigue siendo más rápido

Por ejemplo:

• En el nivel de compresión 6, zlib-rs es aproximadamente 6% más rápido que zlib-ng
• En el nivel de compresión 9, zlib-rs es aproximadamente 13% más rápido que zlib-ng
• Pero en los niveles de compresión 1~4, zlib-ng lleva la ventaja

Conclusión

• zlib-rs tiene ventaja de rendimiento en descompresión frente a zlib-ng y zlib-chromium
• El rendimiento de compresión sigue mejorando y muestra mejoras significativas en niveles clave de compresión
• Puede usarse tanto en proyectos Rust como en C
  • Rust → usar la bandera zlib-rs en el crate flate2
  • C → puede usarse tras compilarlo como biblioteca dinámica

[GN⁺]

Comentarios en Hacker News

• Queda claro que ya conocen Rust

  • Pensaba que el objetivo de Rust era la seguridad, pero esta librería usa mucho la palabra clave unsafe
  • Me pregunto en qué punto deja de tener sentido la diferencia entre C y Rust
  • Si se usa ensamblador inline, ambos lenguajes pueden generar el mismo código máquina
  • Me pregunto si el compilador de Rust optimiza mejor que un compilador de C

• Decir que es "más rápido que C" termina reduciéndose a diferencias de diseño, implementación, algoritmos, etc.

  • Puede ser más rápido que una implementación ya existente, pero afirmar que es "más rápido que C" suena raro

• zippy en Nim afirma ser entre 1.5 y 2 veces más rápido que zlib

  • También existen zlib en C más rápidas que la instalación estándar
  • zlib ya es algo anticuado hoy en día, pero sigue siendo popular
  • Se usa como base para formatos nuevos más amigables con el paralelismo

• Me pregunto si el rendimiento de Rust tiene que ver con Rust en sí, o si simplemente está más optimizado que otras versiones en C

  • Hay casos, como sort, donde C++ ofrece un rendimiento consistentemente mejor que C
  • Me pregunto si existe algo parecido entre Rust y C

• Chromium usa zlib por los algoritmos definidos en el estándar

  • Si eliges un mejor algoritmo, puedes obtener mejor rendimiento
  • Zstandard es más rápido y además comprime mejor
  • LZ4 es muchísimo más rápido, pero no reduce tanto el tamaño

• Se permite Zstandard y digest de blake3

• Sería más preciso decir que Rust es tan rápido como C

  • Y aun así sigue siendo un gran logro

• Qué librería compila más rápido

  • Qué librería tiene menos dependencias
  • Si ambas librerías tienen el mismo tamaño y cuál es más pequeña

• A los usuarios de Rust les gusta comparar Rust con C, pero los usuarios de C rara vez comparan C con Rust

• Al trabajar con lenguajes de sistemas compilados, el lenguaje casi no afecta la velocidad

  • Las versiones optimizadas controlan las asignaciones, usan buenos patrones de acceso a memoria y aprovechan SIMD y multihilo, por lo que fácilmente pueden ser más de 100 veces más rápidas
  • Solo con un mejor acceso a memoria, un programa puede volverse más de 20 veces más rápido

• Lo que significa es que la implementación es más rápida que en C

  • No existe eso de "más rápido que C"