Roc se queda a un 2,6% de libdeflate, el rey de la compresión en C
How close can pure functional programming get to C?
Richard Feldman se propuso medir cuánto puede acercarse un lenguaje funcional puro a C en rendimiento real. Tomó roc-deflate, un paquete de DEFLATE escrito en Roc por Niclas Ahden, y lo optimizó contra libdeflate usando el corpus Silesia. En los 144 benchmarks quedó una media de 8,9% por debajo en el Ryzen 3900X y solo un 2,6% en el M1 MacBook Pro, con salidas idénticas. Todo esto en un lenguaje que aún no llega a su versión 0.1.0.
No esperaba superar el rendimiento de libdeflate en todos los frentes, pero quería ver cuánto podía acercarse en las APIs no de streaming.
- jandrewrogers
Gran parte de la diferencia en optimizabilidad es que C/C++ permite hacer una elisión de copias bastante extrema. Esto es importante porque el ancho de banda de memoria suele ser un cuello de botella importante en el rendimiento.
El código C/C++ puede acceder trivialmente a algún bit remoto de estado y mutarlo directamente. Al compilador rara vez le importa, por feo que sea el método o patrón de acceso. Depende del programador asegurarse de que las invariantes se mantengan y el compilador no siempre puede verlo. Sin embargo, estas copias elididas se acumulan, aunque normalmente tienen un coste de mantenibilidad y seguridad.
Está relacionado con por qué los lenguajes funcionales tienden a ser mediocres para la supercomputación en la práctica a pesar de tener buenas propiedades para el paralelismo masivo en teoría.
- VorpalWay
> lean-zip supera a todos y cada uno de los niveles de compresión de miniz_oxide
Miniz_oxide es una implementación intencionadamente simple. Sería más justo compararlo con el más reciente zlib-rs[1], que incluso supera a zlib-ng (la implementación más rápida en C)[2].
[1]: https://lib.rs/crates/zlib-rs
[2]: https://trifectatech.org/blog/zlib-rs-is-faster-than-c/
- gobdovan
¿Has considerado exponer estas optimizaciones a través de una biblioteca para que los programadores puedan solicitar pases de optimización y hacer que el compilador verifique las precondiciones?
Lo pregunto porque estoy preparando un artículo sobre lo rápido que puede llegar a ser JS y encontré lo mismo: puedes llegar al 10% del código C optimizado con básicamente cualquier código si torturas lo suficiente a V8 (excepto SIMD, donde parece haber un bug en V8 por el que no optimiza a SIMD incluso cuando es más que obvio). Descubrí que podría extraerlo en una librería y hacerlo de forma más simplificada, pero no estoy seguro de hasta qué punto las transformaciones manuales se generalizan.
Además, cuando trabajabas en roc-deflate, ¿encontraste transformaciones recurrentes que pudieran encajar en ese modelo o la mayoría de las mejoras eran específicas de la compresión?
- ReDress
C es de hecho un lenguaje funcional en el sentido de que la mayoría de los proyectos en C son cosas que se han observado en la vida real y posteriormente se han subido a los ordenadores.
También me gustaría señalar que el rendimiento es la preocupación DEFINITIVA en muchos casos.
Si tienes un servidor que hace 10 millones de peticiones a cierto método en un minuto, entonces no puedes permitirte ningún compromiso de rendimiento. Ninguno, en absoluto.
Rust nunca reemplazará a C/C++ en lo que respecta a la computación de alto rendimiento.
- johnny22
decir que "supera a un crate que se ha descargado X veces" no dice nada más que eso es popular. Estaría bien ver un poco más de detalle ahí.