Std: Clamp genera un ensamblado menos eficiente que std:min(std::max(v, lo), hi)

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores de C++ están analizando por qué `std::clamp` puede generar ensamblado menos eficiente que componer manualmente `std::min(std::max(v, lo), hi)` en algunos objetivos x86, y cómo activar banderas específicas de CPU (`-march=native`, AVX) a menudo cambia por completo el panorama. Más allá del simple conteo de instrucciones, señalan trampas semánticas sutiles: `std::clamp` tiene comportamiento indefinido cuando `lo > hi`, interactúa de forma distinta con NaN y el cero con signo, y puede verse alterado por banderas como `-ffast-math` que relajan las garantías IEEE-754. La conclusión general es que el rendimiento y la corrección de incluso utilidades numéricas simples dependen mucho de la arquitectura objetivo, las opciones del compilador y de cuánta rigurosidad en coma flotante estás dispuesto a sacrificar por velocidad.

Rendimiento de std::clamp frente a std::min/std::max

  • Los compiladores a menudo emiten código ligeramente menos eficiente para std::clamp que para un std::min(std::max(v, lo), hi) escrito a mano en x86, especialmente sin AVX.
  • Algunos ejemplos muestran mov adicionales o un orden de instrucciones diferente para clamp; las explicaciones incluyen:
    • Restricciones de ABI (el argumento y el valor de retorno están ambos en xmm0, lo que requiere un movimiento de “guardar/restaurar”).
    • Particularidades de asignación de registros.
    • Las semánticas de NaN de minsd/maxsd de x86 que restringen el reordenamiento.
  • Con -march=znver1, -mavx o objetivos x86 más modernos, tanto GCC como Clang pueden generar la secuencia óptima incluso en niveles bajos de optimización; los modelos predeterminados “k8-generic” están obsoletos.
  • Los microbenchmarks muestran que, una vez que los compiladores optimizan en contexto, la microineficiencia del artículo puede ser insignificante, y las ramas predecibles pueden superar al código ingenioso sin ramas según los patrones de datos.

Semántica y corrección de std::clamp

  • std::clamp estándar normalmente se implementa como std::min(std::max(v, lo), hi), pero con un orden y un comportamiento especificados.
  • El comportamiento cuando lo > hi está explícitamente indefinido; algunas implementaciones hacen una aserción (por ejemplo, en Windows), otras simplemente realizan la secuencia min/max.
  • Esto lleva a algunos a preferir min/max explícitos para poder definir qué ocurre para un “intervalo vacío”.
  • El orden también afecta a NaN y al cero con signo:
    • Para coma flotante, el estándar requiere un orden débil estricto; los NaN lo violan, así que usar NaN con clamp es, en efecto, indefinido.
    • Un std::clamp correcto debe devolver v cuando v == lo == hi (incluyendo -0.0 frente a +0.0), algo que algunas versiones “optimizadas” no hacen.

Banderas de coma flotante y -ffast-math

  • Con -ffast-math (o -Ofast), GCC y Clang a menudo eliminan diferencias entre clamp y min/max, probablemente porque relajan el manejo de NaN/Inf.
  • Varios comentarios advierten que las opciones fast-math:
    • Permiten cambios de reordenamiento/arimética que pueden alterar significativamente el comportamiento numérico.
    • Pueden romper std::isnan/std::isinf y asumir que NaN/Inf no existen.
    • En algunas toolchains, activan globalmente los bits FTZ/DAZ, afectando a todo el código del proceso, incluidas otras bibliotecas.
  • Otros sostienen que en muchas cargas de trabajo prácticas (por ejemplo, muchas tareas de ML y numéricas), un pequeño error adicional en ULP es aceptable y fast-math se usa mucho, pero reconocen los riesgos.

Consejo general

  • Especifica siempre una CPU de destino moderna (-march=native, x86-64-v2/v3, etc.) en lugar de depender de valores predeterminados muy antiguos.
  • Para operaciones masivas de min/max/clamp donde el rendimiento realmente importa, considera SIMD/intrinsics y políticas explícitas para NaN.
  • Se advierte con cautela algo similar sobre std::lerp: ofrece fuertes garantías numéricas, pero puede ser más lento que una expresión afín simple.