¿Rust std fs es más lento que Python? No, es un problema de hardware

¿El binding de Python de OpenDAL es más lento que Python?

• OpenDAL es una capa de acceso a datos que permite recuperar datos de distintos servicios de almacenamiento de forma eficiente.
• Hay reportes de que el binding de Python de OpenDAL es más lento que Python en sí.
• Se plantea como hipótesis que la causa podría ser la caché interna de Python, la aceleración de lectura de archivos y la sobrecarga adicional de PyO3.

¿El servicio Fs de OpenDAL es más lento que Python?

• Es un problema en el que intervienen varios factores, como Rust, OpenDAL, Python y PyO3.
• También se descubrió que el servicio fs de OpenDAL implementado en Rust es más lento que Python.

¿Rust std fs es más lento que Python?

• OpenDAL implementa el servicio fs mediante std::fs.
• Se confirmó que una implementación usando std::fs de Rust también es más lenta que Python.

¿Rust std fs es más lento que Python? ¿En serio!?

• Se pone en duda el resultado de que Rust std fs sea más lento que Python.
• Se aprende a analizar llamadas al sistema usando strace.
• A través del análisis de los resultados de strace, no se logra encontrar por qué Python es más rápido aunque ambos usan mmap.

¿Por qué se usa mmap aquí?

• mmap no solo se usa para mapear archivos en memoria, sino también para asignar grandes regiones de memoria.
• Al solicitar memoria con malloc, glibc usa mmap para asignarla.

¿Python tiene el mismo asignador de memoria que Rust?

• Python usa un asignador de memoria llamado pymalloc, optimizado para asignaciones pequeñas.
• pymalloc está optimizado para objetos pequeños, y para asignaciones grandes usa PyMem_RawMalloc() y PyMem_RawRealloc().

¿Rust con el asignador de memoria predeterminado es más lento que Python?

• Se sospecha que mmap está causando el problema.
• Se descubre que un programa Rust que cambia a jemalloc funciona más rápido que Python.

¿Rust solo es más lento que Python en mi computadora?

• El hecho de que Rust funcione más lento que Python ocurre solo en una computadora específica.
• Se proporciona información detallada sobre la CPU y la memoria.
• Incluso ajustando funciones de mitigación de vulnerabilidades de la CPU, Transparent Hugepage y la afinidad de núcleos de CPU, no hay cambios en el resultado.
• Se confirma usando un programa eBPF que Rust es más lento que Python incluso al nivel de llamadas al sistema.

¿C es más lento que Python?

• También se descubre que una versión implementada en C es más lenta que Python.

¿C es más lento que Python? ¡Sin offset especificado!

• Se descubre una diferencia en el offset de la región de memoria, y al ajustar el offset mejora la velocidad del programa en C.
• Se confirma que en una CPU AMD Ryzen ocurre una degradación de rendimiento sin cierto offset.

¿AMD Ryzen 9 5900X es lento sin offset especificado?

• Se confirma que es un problema relacionado con la CPU, y un desarrollador del kernel participa en la discusión.
• A través de perfiles con perf, se vuelve a confirmar que sin offset ocurre una degradación de rendimiento.

Opinión de GN⁺: El punto más importante de este artículo es que Rust y C pueden funcionar más lento que Python en ciertos entornos de hardware, y que esto puede deberse a la asignación de memoria y a formas específicas de funcionamiento de la CPU. El artículo muestra, mediante la exploración de diversos factores que afectan el rendimiento del software, cuán compleja puede ser la interacción entre hardware y software. Esta investigación ofrece una lección importante para resolver problemas inesperados que pueden surgir en el mundo de la ingeniería de software.

[GN⁺]

Opiniones de Hacker News

• Opinión sobre una premisa confusa

  Un usuario expresó confusión ante la idea de que las funciones de la biblioteca estándar de Python estén escritas en Python puro. Le pareció interesante la diferencia de rendimiento, ya que tanto el método de lectura de archivos de Python como OpenDAL son envolturas en Python sobre código nativo, pero sintió que decir que es "más lento que Python" era una forma extraña de plantearlo. Esperaba que las funciones de la biblioteca estándar de Python estuvieran implementadas en código nativo y optimizadas individualmente. No le sorprendió que la conclusión del artículo tuviera que ver con cómo funciona el código nativo; sí le sorprendieron algunas respuestas, pero reconoció que, pese al inicio confuso, el artículo fue muy interesante.

• Debate sobre los flags de funciones del CPU

  Existen dos flags dedicados de funciones del CPU que indican que las instrucciones REP STOS/MOV son rápidas y utilizables como secuencias cortas de instrucciones para memset/memcpy. Tener que crear a mano rutinas optimizadas para cada nueva generación de CPU ha sido un dolor que lleva décadas. Planteó si esto no debería formar parte del suite de pruebas de temporización del fabricante del CPU.

• Enlace a un bug relacionado de glibc

  Compartió un enlace a un bug de glibc relacionado con Zen 4.

• Reacción positiva al artículo

  Un usuario dijo que empezó a leer el artículo dispuesto a burlarse del mal uso de std::fs, pero terminó diciendo que era una cadena de giros inesperados y misterios; lo consideró bien escrito y muy interesante.

• Alta valoración del artículo

  Otro usuario lo calificó como el artículo más interesante que había leído esa semana y elogió lo bien escrito que estaba.

• Sugerencia para resolver el problema

  Como solución evidente, sugirió enviar un parche para cambiar el método del kernel copy_user_generic de modo que use otra implementación de copia de memoria cuando se detecte que el CPU tiene el problema y la alineación de memoria activa el bug de lentitud.

• Información sobre el asignador predeterminado de Rust

  Compartió el dato de que el asignador predeterminado de Rust fue jemalloc hasta 2018, junto con enlaces relacionados.

• Consideraciones de desarrolladores Rust para mejorar el rendimiento

  Expresó curiosidad sobre si los desarrolladores de Rust deberían considerar cambiar a jemallocator para mejorar el rendimiento, si esa sería una forma de que todos obtuvieran rendimiento gratis, si los codebases en C también podrían beneficiarse de ello y si es rendimiento que actualmente se está dejando sobre la mesa.

• Explicación de las diferencias de CPU entre AMD e Intel

  Explicó que la forma en que AMD maneja el almacenamiento de cadenas es distinta a la de Intel, y que conviene no usarla hasta superar el tamaño de la L2 del CPU. Pasado ese punto, usar almacenamiento de cadenas sí resulta ventajoso y debería ejecutarse a "velocidad de DRAM", pero como tiene un costo inicial alto, antes de alcanzar ese umbral se deberían usar cargas/almacenamientos vectoriales de 256 bits.

• El artículo fue compartido con las personas adecuadas

  Un usuario comentó que ya había hecho llegar este artículo a las personas adecuadas.