Pentium FDIV: el error matemático que avergonzó a Intel a nivel mundial

Qué pasó realmente (y qué significa FDIV)

FDIV es la instrucción x86 de división en punto flotante. En 1994, investigadores y usuarios descubrieron que algunas CPUs Intel Pentium producían resultados incorrectos en un pequeño conjunto de operaciones de división en punto flotante. No “un dígito de menos al final”, sino errores medibles que podían importar para software numérico.

El bug residía en la implementación de hardware del algoritmo de división en la unidad de punto flotante (FPU) del Pentium. Bajo patrones específicos de operandos, la CPU usaba valores intermedios incorrectos, produciendo un cociente erróneo. La mayoría de las divisiones eran correctas. Muchas personas nunca lo encontraron. Precisamente por eso se volvió infame: era lo bastante raro para pasar desapercibido, pero real como para romper la confianza.

Los ingenieros de confiabilidad se obsesionan con los modos de fallo. FDIV no fue un incidente típico de disponibilidad; fue un incidente de correctitud. Esos son más difíciles. Tus SLIs no gritan. Tus dashboards se mantienen en verde. Tus clientes pierden dinero en silencio y luego pierden la fe en voz alta.

Una cita que debería estar impresa sobre cada mesa de on-call de producción: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. En el territorio de la correctitud, “nunca lo hemos visto” es solo esperanza con mejor tipografía.

Broma corta #1: El bug FDIV demostró que puedes tener “alta disponibilidad” y aún así no estar disponible para la verdad.

Por qué importó: los errores silenciosos superan a las caídas ruidosas

Si un controlador de almacenamiento entra en pánico, haces failover. Si un nodo de clúster muere, lo reemplazas. Si una CPU devuelve la respuesta incorrecta con la confianza adecuada, ¿cómo sabes qué filas están envenenadas? No puedes “reiniciar” para salir de una matemática mala, al igual que no puedes fsck para arreglar un libro mayor manipulado.

En términos operativos, el incidente FDIV forzó una conversación pública sobre:

• El hardware como parte de tu base de confianza computacional. Tu modelo de amenazas no incluye solo atacantes; también incluye bugs.
• SLI de correctitud. Si no mides “lo correcto”, solo medirás “lo rápido”.
• Economía de las retiradas. Reemplazar chips cuesta dinero. No reemplazarlos cuesta credibilidad—en ocasiones más.
• Comunicación. Los errores de ingeniería pueden perdonarse; los mensajes evasivos, por lo general, no.

Intel finalmente ofreció reemplazos, pero no antes de que la historia saltara a los medios generales. Esa parte importa porque es un modo clásico de fallo corporativo: tratar un defecto técnico como una molestia de relaciones públicas en lugar de una violación de integridad.

Datos rápidos y contexto histórico (lo que la gente olvida)

• Surgió en 1994, cuando Pentium era una marca premium y el “punto flotante” cobraba cada vez más relevancia fuera de la academia.
• El problema era determinista para ciertos pares de operandos: mismas entradas, misma salida errónea. Eso lo hacía reproducible, no un rayo cósmico.
• La causa raíz fueron entradas faltantes en una tabla de búsqueda usada por el algoritmo de división (detalles más abajo). No una esquina de redondeo; un defecto de tabla.
• La mayoría de las cargas de trabajo no lo notaban porque no realizaban suficientes divisiones sensibles en punto flotante para golpear los casos malos.
• El uso en hojas de cálculo y finanzas aumentó el radio de impacto porque la “matemática de negocio” se había trasladado a escritorios donde Pentium dominaba.
• IEEE 754 no fue el villano; fue la implementación. Los estándares no te salvan de un silicio defectuoso.
• La verificación independiente importó: el problema se volvió indiscutible porque la gente pudo reproducirlo en múltiples máquinas.
• Influyó en la cultura de adquisición—más compradores comenzaron a preguntar por erratas, revisiones de stepping y validación, no solo por MHz.
• Prefiguró el pensamiento moderno sobre “corrupción silenciosa de datos” que ahora aparece en almacenamiento (sumas de verificación), memoria (ECC) y sistemas distribuidos (validación de extremo a extremo).

Cómo funcionó el bug FDIV: división basada en tablas y entradas faltantes

La división por hardware es costosa en puertas lógicas y latencia. Las CPUs usan algoritmos ingeniosos para aproximar recíprocos y refinarlos. En la FPU del Pentium, la operación de división usaba una tabla de búsqueda para iniciar la aproximación. Esa tabla mapea ciertos bits del divisor a constantes que impulsan un proceso iterativo de refinamiento (piensa “comenzar cerca, luego converger”).

Aquí está el modo de fallo clave: algunas entradas de la tabla eran incorrectas (efectivamente faltantes/poner a cero), por lo que la aproximación inicial podía estar lo suficientemente desviada como para que el refinamiento convergiera a un resultado incorrecto. No era radicalmente distinto, pero sí erróneo más allá del error aceptable del punto flotante.

Desde la perspectiva de un SRE, esta es una clase de bug de pesadilla porque:

• Es dependiente de la entrada y por tanto aparece como “aleatorio” en producción, aunque sea determinista.
• Puede ser dependiente de los datos, lo que significa que solo ciertos conjuntos de datos lo disparan (una distribución específica de divisores).
• Es no bloqueante. No hay señal a menos que valides las salidas.
• Es específico de la plataforma. Tu entorno de staging podría no coincidir con el stepping en producción.

Los ingenieros a veces preguntan: ¿por qué no lo detectaron las pruebas? Porque el espacio de entradas de punto flotante es astronómicamente grande, y las pruebas “típicas” tienden a centrarse en valores límite (0, 1, potencias de dos, denormales) en lugar de los raros intermedios donde las tablas de aproximación te muerden.

La verificación de hardware mejoró con el tiempo, pero la lección más profunda sigue siendo: la correctitud necesita comprobaciones independientes, no solo fe en un proveedor, un estándar o una ejecución limpia de CI.

Reproducirlo y detectarlo como un SRE

Probablemente no tengas un Pentium de 1994 en un rack (si lo tienes, por favor no lo conectes a nada). Aun así, el método operativo importa: define una prueba conocida como mala, ejecútala en segmentos de la flota, compara resultados e identifica por firma de hardware.

Una reproducción clásica usa operandos cuidadosamente elegidos donde el resultado FDIV del Pentium diverge de la división correcta. Las constantes exactas no son el punto aquí; el punto es construir un arnés de comprobación cruzada que pueda detectar “CPU A difiere de CPU B” sin requerir que conozcas la respuesta verdadera de antemano.

En sistemas de producción, eso suele verse así:

• Ejecutar cálculos dos veces con implementaciones diferentes (hardware vs software, o dos bibliotecas).
• Comparar resultados dentro de una tolerancia aceptable.
• Escalar cuando la tasa de discrepancias cruza un umbral.
• Marcar las salidas con su procedencia para identificar qué hosts produjeron resultados sospechosos.

Esa es la misma filosofía que usas en almacenamiento cuando chequeas con sumas y limpias: confía, pero verifica—y verifica de extremo a extremo.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas operativas reales que puedes ejecutar en flotas Linux para reducir el riesgo de “matemáticas silenciosamente erróneas”, identificar heterogeneidad y construir salvaguardas. Cada tarea incluye: comando, salida de ejemplo, qué significa y qué decisión tomar.

Task 1: Identify CPU model and stepping across a host

cr0x@server:~$ lscpu | egrep 'Model name|Vendor ID|CPU family|Model:|Stepping:'
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
CPU family:          6
Model:               79
Stepping:            1

Significado de la salida: El modelo/stepping es cómo correlacionas con erratas conocidas (incluyendo las históricas como FDIV y las modernas como mitigaciones de ejecución especulativa).

Decisión: Si ejecutas mezclas de steppings, planifica validación de correctitud por segmento y asigna cargas de alta integridad a steppings conocidos y buenos.

Task 2: Capture microcode version (because microcode sometimes mitigates issues)

cr0x@server:~$ dmesg | grep -i microcode | tail -n 3
[    0.452112] microcode: microcode updated early to revision 0xb00003a, date = 2021-05-11
[    0.452948] microcode: CPU0 sig=0x406f1, pf=0x1, revision=0xb00003a
[    0.453015] microcode: Microcode Update Driver: v2.2.

Significado de la salida: Confirma si estás ejecutando microcódigo actualizado. FDIV fue un defecto de tabla en hardware y no “arreglable con microcódigo” en la práctica, pero muchos problemas modernos de CPU sí lo son.

Decisión: Si el microcódigo está desactualizado, trátalo como un backlog de parches de seguridad. Despliega actualizaciones con la cadencia de kernel.

Task 3: Inventory fleet CPU signatures at scale (example using SSH fanout)

cr0x@server:~$ for h in app01 app02 app03; do echo "== $h =="; ssh $h "lscpu | egrep 'Model name|Stepping'"; done
== app01 ==
Model name:          Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Stepping:            1
== app02 ==
Model name:          Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Stepping:            1
== app03 ==
Model name:          Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Stepping:            2

Significado de la salida: app03 difiere. Así es como los bugs de correctitud raros se vuelven “solo ocurre los martes”.

Decisión: Poner en cuarentena los casos atípicos de las cargas sensibles hasta validarlos.

Task 4: Check whether ECC memory is present and enabled

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Error Correction Type|Total Width|Data Width' | head -n 6
Error Correction Type: Multi-bit ECC
Total Width: 72 bits
Data Width: 64 bits
Error Correction Type: Multi-bit ECC
Total Width: 72 bits
Data Width: 64 bits

Significado de la salida: ECC no evita FDIV, pero previene una gran clase de “matemáticas equivocadas” debidas a cambios de bit en memoria.

Decisión: Si un segmento de la flota carece de ECC, no ejecutes allí cargas numéricas de alta integridad. Punto.

Task 5: Look for machine check events (hardware errors) in logs

cr0x@server:~$ journalctl -k | egrep -i 'mce|machine check|hardware error' | tail -n 5
Jan 21 08:11:02 server kernel: mce: [Hardware Error]: CPU 7: Machine Check: 0 Bank 5: bea0000000000108
Jan 21 08:11:02 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1c140 MISC d012000100000000
Jan 21 08:11:02 server kernel: mce: [Hardware Error]: PROCESSOR 0:406f1 TIME 1705824662 SOCKET 0 APIC 14 microcode b00003a

Significado de la salida: Indica inestabilidad de hardware subyacente. No es específico de FDIV, pero te dice que la plataforma no debe ser confiada ciegamente.

Decisión: Si aparecen MCEs, programa reemplazo de hardware y mueve inmediatamente trabajos críticos de correctitud.

Task 6: Run a quick floating-point self-check with software cross-compare (simple harness)

cr0x@server:~$ python3 - <<'PY'
import random, math, decimal
decimal.getcontext().prec = 80
def check(n=20000):
    bad = 0
    for _ in range(n):
        a = random.uniform(1e-100, 1e100)
        b = random.uniform(1e-100, 1e100)
        # hardware float
        hf = a / b
        # high precision decimal
        da = decimal.Decimal(str(a))
        db = decimal.Decimal(str(b))
        df = da / db
        # compare within relative tolerance
        if hf != 0.0:
            rel = abs((decimal.Decimal(hf) - df) / df)
            if rel > decimal.Decimal("1e-12"):
                bad += 1
    return bad
print("mismatches:", check())
PY
mismatches: 0

Significado de la salida: “0 mismatches” no prueba perfección; reduce la sospecha. Si las discrepancias suben, tienes un incidente de correctitud.

Decisión: Si mismatches > 0, amplía la investigación: mismo código en hosts diferentes, verificar firmas de CPU, validar flags del compilador y bibliotecas matemáticas.

Task 7: Identify compiler flags that may change numerical behavior

cr0x@server:~$ gcc -Q -O2 --help=optimizers | egrep 'fast-math|unsafe-math|finite-math-only|fp-contract' | head -n 6
  -ffast-math                 		[disabled]
  -funsafe-math-optimizations 		[disabled]
  -ffinite-math-only          		[disabled]
  -ffp-contract               		[off]

Significado de la salida: Flags estilo fast-math pueden legalmente romper expectativas IEEE. Eso es “optimización” con una hipoteca de correctitud.

Decisión: Para cargas de finanzas/ciencia/cripto/integridad, prohibe estos flags en builds de release salvo que hayas probado que son seguros.

Task 8: Verify which libm / libc you are actually running

cr0x@server:~$ ldd --version | head -n 2
ldd (Ubuntu GLIBC 2.35-0ubuntu3.4) 2.35
Copyright (C) 2022 Free Software Foundation, Inc.

Significado de la salida: Diferentes implementaciones de libm pueden diferir en casos límite. Si depuras deriva numérica, necesitas saber el runtime exacto.

Decisión: Estandariza runtimes en la flota de cómputo o perseguirás “bugs” que son solo diferencias de biblioteca.

Task 9: Confirm CPU flags relevant to floating-point behavior

cr0x@server:~$ grep -m1 -oE 'sse2|sse4_2|avx2|fma' /proc/cpuinfo | sort -u
avx2
fma
sse2
sse4_2

Significado de la salida: Las opciones de conjunto de instrucciones afectan la aritmética (FMA cambia el redondeo) y las rutas de código en bibliotecas.

Decisión: Si los resultados difieren entre hosts, verifica si diferentes flags están causando distintas rutas de ejecución.

Task 10: Pin a workload to a specific CPU model/segment (operational containment)

cr0x@server:~$ taskset -c 0-3 ./risk_calc --portfolio P42
OK: computed VaR=1.873e6 in 2.14s (threads=4)

Significado de la salida: Esto fija la ejecución a un subconjunto de cores. No es una solución para FDIV, pero es una técnica para aislar y reproducir problemas en cores/CPUs conocidas.

Decisión: Si solo algunos cores/CPUs se comportan mal (raro, pero posible con hardware marginal), la contención te compra tiempo.

Task 11: Detect heterogeneity in container/Kubernetes nodes (CPU model as a scheduling constraint)

cr0x@server:~$ kubectl get nodes -o wide
NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP   OS-IMAGE             KERNEL-VERSION
node-a   Ready    worker   92d   v1.28.3   10.0.1.11     Ubuntu 22.04.3 LTS   5.15.0-91-generic
node-b   Ready    worker   92d   v1.28.3   10.0.1.12     Ubuntu 22.04.3 LTS   5.15.0-91-generic
node-c   Ready    worker   18d   v1.28.3   10.0.1.13     Ubuntu 22.04.3 LTS   5.15.0-91-generic

Significado de la salida: Las diferencias de antigüedad suelen correlacionar con diferencias de hardware. Ahí es donde nace “misma app, distintas respuestas”.

Decisión: Añade etiquetas a los nodos basadas en modelo/stepping de CPU y programa cargas críticas de correctitud explícitamente.

Task 12: Label nodes by CPU model to enforce placement

cr0x@server:~$ kubectl label node node-c cpu.intel.com/model=79
node/node-c labeled

Significado de la salida: Un identificador estable para reglas de scheduling.

Decisión: Usa afinidad de nodo para asegurar consistencia, especialmente al validar regresiones numéricas.

Task 13: Confirm math library uses consistent rounding mode (runtime sanity)

cr0x@server:~$ python3 - <<'PY'
import decimal
print("decimal rounding:", decimal.getcontext().rounding)
PY
decimal rounding: ROUND_HALF_EVEN

Significado de la salida: HALF_EVEN es común en contextos financieros; reglas de redondeo inconsistentes entre servicios pueden parecer “bugs de hardware”.

Decisión: Estandariza políticas de redondeo en el código y documéntalas como un contrato de API.

Task 14: Detect if the kernel is reporting CPU vulnerabilities/mitigation state

cr0x@server:~$ grep -H . /sys/devices/system/cpu/vulnerabilities/* | head -n 5
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; IBRS_FW
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable

Significado de la salida: Muestra que el SO es consciente de problemas a nivel de CPU. Tema distinto a FDIV, misma lección meta: el silicio tiene erratas; debes gestionarlas.

Decisión: Lleva seguimiento de estos estados como inventario. Si no puedes explicar tu estado de mitigación, no puedes explicar tu riesgo.

Guía rápida de diagnóstico

Esta es la secuencia “deja de teorizar y obtén señal” cuando alguien dice: “Los números no cuadran”, y sospechas problemas de hardware, compilador o biblioteca. El objetivo es encontrar el cuello de botella en tu investigación rápidamente: entradas, plataforma o implementación.

First: confirm it’s real (and bound the blast radius)

1. Obtén un reproducible mínimo. Mismas entradas, misma función, misma discrepancia. Si no puedes reproducirlo, no puedes arreglarlo.
2. Verifica si la discrepancia es determinista. Determinismo apunta a implementación/plataforma. No determinismo apunta a race, memoria no inicializada o comportamiento indefinido.
3. Compara resultados entre dos máquinas. Si un host difiere, tienes una delta de entorno hardware/software que seguir.

Second: fingerprint the environment like you mean it

1. Modelo/stepping de CPU y microcódigo. Si son diferentes, asume que eso es relevante hasta que se demuestre lo contrario.
2. Compilador y flags. Busca fast-math, diferencias FMA y advertencias de sanitizers de comportamiento indefinido.
3. Versiones de bibliotecas matemáticas. libm y backends BLAS son culpables frecuentes.

Third: isolate by method, not by vibes

1. Ejecuta una referencia de alta precisión. Usa decimal/bigfloat o herramientas basadas en MPFR como oráculo para comprobaciones puntuales.
2. Ejecuta una ruta de retroceso por software (si está disponible) y compara. La divergencia implica hardware o codegen de bajo nivel.
3. Fija modo de redondeo y denormales. Un entorno FP inconsistente produce diferencias “fantasma”.

Broma corta #2: Si el postmortem de tu incidente incluye “el punto flotante es raro”, no encontraste la causa—encontraste una excusa.

Tres microhistorias corporativas desde las trincheras de la corrección

Mini-story 1: The incident caused by a wrong assumption

Una fintech mediana ejecutaba cálculos diarios de riesgo en un clúster por lotes. El trabajo era “embarazosamente paralelo”: dividir portafolios, calcular métricas, fusionar resultados. Durante años funcionó. Luego actualizaron un subconjunto de nodos—a CPUs más nuevas, misma imagen de SO, mismo digest de contenedor. Asumieron “el cómputo es cómputo”.

Una semana después, la conciliación comenzó a derivar. No catastróficamente. Piensa en pequeñas discrepancias a través de millones de cuentas, del tipo que parece ruido de redondeo hasta que no lo es. El on-call repasó los sospechosos habituales: zonas horarias, formato decimal, una nueva fuente de datos. Nada encajaba.

El avance ocurrió cuando alguien volvió a ejecutar el mismo slice de portafolio en dos nodos distintos y obtuvo valores diferentes en el decimal 10–12, suficiente para cambiar una prueba de umbral aguas abajo. La causa raíz no fue un defecto de hardware estilo FDIV moderno; fue un cambio en rutas de código de punto flotante: las CPUs más nuevas activaron FMA, las antiguas no, y el backend BLAS eligió rutas diferentes en consecuencia.

La suposición errónea fue simple: “Si el contenedor es el mismo, las matemáticas son las mismas.” Los contenedores empaquetan userland, no el comportamiento del silicio. Su solución fue operativa: etiquetar nodos por capacidades de CPU, programar trabajos de riesgo en una clase consistente y añadir un paso de validación cruzada que comparara una muestra con una referencia de alta precisión.

La lección FDIV encaja: el hardware es parte de la superficie de API. Ignorarlo y depurarás tu propia confianza.

Mini-story 2: The optimization that backfired

Un equipo de plataforma de machine learning tenía un problema de costes: la inferencia era cara y producto quería reducir la latencia p95. Un ingeniero activó un switch del compilador: optimizaciones agresivas de punto flotante, además de reconstruir BLAS sintonizado para el conjunto de instrucciones más nuevo de la flota.

La latencia mejoró. Todos celebraron. Luego saltó una alerta de monitorización del modelo: deriva en las distribuciones de predicción para un subconjunto estrecho de entradas. No una caída. No un pico. Una desviación silenciosa y persistente. El modelo no había cambiado; el comportamiento numérico sí.

La “optimización” alteró la asociatividad y el redondeo lo suficiente como para mover ciertas clasificaciones límite por encima de un umbral. La mayoría de las predicciones eran idénticas. Las que importaban—casos de borde de alto valor—no lo eran.

Revirtieron los flags del build, volvieron a ejecutar un corpus representativo de entradas e instituyeron una regla: cualquier optimización numérica requiere un presupuesto de precisión y una suite de regresión que incluya pruebas de sensibilidad a umbrales, no solo error promedio. También documentaron qué cargas toleran transformaciones no-IEEE y cuáles no.

FDIV no ocurrió porque alguien activó un flag. Pero el modo de fallo corporativo es el mismo: tratar la correctitud como una cualidad negociable. No lo es en las partes de tu sistema que hacen compromisos.

Mini-story 3: The boring but correct practice that saved the day

Un grupo de computación de investigación ejecutaba simulaciones largas en un clúster compartido. Tenían una política que molestaba a todos: cada release tenía que producir una “huella numérica” sobre un dataset con semilla fija, almacenada con los metadatos del artefacto de build. Mismo commit, misma semilla, misma clase de entorno, mismo rango de hash de salida.

Un mes, llegó un lote de hardware nuevo. Los trabajos corrieron más rápido, pero la huella cambió. No mucho—lo suficiente para exceder su sobre de tolerancia. Ningún usuario había quejado aún, porque las salidas seguían pareciendo plausibles. Pero la política lo detectó antes de generar resultados de calidad para publicación.

La causa resultó ser un cambio sutil en tiempo de ejecución: comportamiento diferente de libm combinado con manejo distinto por defecto de números denormales. No enfrentaban un defecto de silicio digno de titulares, pero el resultado pudo haber sido daño reputacional y semanas de cómputo perdido.

La solución fue procedimental y aburrida: estandarizar el entorno FP, fijar ejecuciones críticas a una clase de nodos validada y mantener la puerta de huella. También documentaron la varianza numérica aceptable por tipo de modelo. La lección: las puertas aburridas son como compras de sueño.

Errores comunes: síntoma → causa raíz → solución

Estos son los patrones que hacen que los bugs de correctitud perduren meses. Trátalos como firmas de fallo.

1) Symptom: “Only one customer sees it”

Causa raíz: La carga/datos del cliente disparan un patrón de operandos raro o un caso límite de umbral.

Solución: Captura las entradas exactas del cliente y rejugarlas en dos entornos. Añade validación canaria para esa clase de entrada.

2) Symptom: “Staging can’t reproduce production”

Causa raíz: Diferencias de stepping de CPU, microcódigo o conjunto de instrucciones entre entornos. Los contenedores no resuelven eso.

Solución: Construye clases de entorno (etiquetas) y exige que staging coincida con la clase de producción para pruebas de correctitud.

3) Symptom: “It’s random; rerun fixes it”

Causa raíz: Race conditions, memoria no inicializada, comportamiento indefinido o orden no determinista en reducciones paralelas.

Solución: Usa sanitizers, ejecuta en modo referencia single-thread y aplica reducciones deterministas donde la correctitud importe.

4) Symptom: “The discrepancy is tiny, so it’s fine”

Causa raíz: Pequeñas diferencias numéricas pueden invertir comparaciones, umbrales o ramas, creando grandes efectos aguas abajo.

Solución: Identifica límites de umbral y añade histéresis, comparaciones con epsilon o cálculo de mayor precisión en puntos de decisión.

5) Symptom: “It started after a performance improvement”

Causa raíz: fast-math, activación de FMA, diferencias de vectorización o cambios en backend BLAS.

Solución: Mantén dos perfiles de build (estricto vs rápido). Puerta de perfil rápido con tests de regresión numérica y un presupuesto de error documentado.

6) Symptom: “It happens only on one rack/region”

Causa raíz: Diferencias de lote de hardware, problemas térmicos que causan comportamiento marginal o distintas bases de BIOS/microcode.

Solución: Extrae inventario de CPU/microcode, revisa logs MCE y pon en cuarentena hardware sospechoso. No discutas con la física.

7) Symptom: “Checksums pass, but analytics drift”

Causa raíz: Tu pipeline de datos está íntegro; el cómputo está mal. La integridad del almacenamiento no garantiza la integridad del cómputo.

Solución: Añade validación de extremo a extremo: recomputa muestras en una implementación de referencia conocida y compara.

Listas de verificación / plan paso a paso

When you suspect a CPU-level correctness issue

1. Congela las entradas: captura payloads exactos, semillas y configuración. Nada de “casi suficiente”.
2. Reproduce en el mismo host dos veces. Si cambia entre ejecuciones, probablemente persigues no determinismo, no silicio.
3. Reproduce en un host diferente con firma de CPU distinta. Si una clase de host discrepa, tienes un punto de segmentación.
4. Huella del platform: modelo/stepping de CPU, microcódigo, kernel, libc/libm, digest de contenedor, versión de compilador.
5. Contrasta con una referencia: mayor precisión o implementación alternativa para una muestra representativa.
6. Contén: asigna cargas sensibles a una clase de hardware validada; drena nodos sospechosos.
7. Comunica: los incidentes de correctitud requieren mensajes claros a stakeholders—qué está afectado, qué no y cómo lo sabes.
8. Remedia: reemplaza/retiro hardware si está implicado, o estandariza runtime/flags si es inducido por software.
9. Prevén recurrencias: añade puertas de huella numérica y scheduling por clase de entorno.

What to standardize in a production compute fleet (if you like sleeping)

• Inventario de CPU seguido como una dependencia: modelo, stepping, microcódigo.
• Nodos dorados para trabajos críticos de correctitud.
• Perfiles de build: perfil IEEE estricto para cargas de integridad; perfil rápido solo con aprobación explícita.
• Arneses de validación que puedan ejecutarse bajo demanda: comparación cruzada, checks por muestra con referencia.
• Metadatos de procedencia: etiqueta resultados con clase de host, ID de build y versiones de librerías para trazabilidad forense.

Preguntas frecuentes

1) Was the Pentium FDIV bug a software bug or hardware bug?

Hardware. Fue un defecto de implementación en la lógica de división de la FPU del Pentium que involucraba entradas incorrectas en la tabla de búsqueda usada durante la división.

2) How common were wrong results?

Raros para cargas de consumo típicas, más plausibles en código numéricamente intenso que realiza muchas divisiones en punto flotante con operandos variados. “Raro” sigue siendo inaceptable cuando el error es silencioso.

3) Could you fix FDIV with a software patch?

En ocasiones se podía mitigar en software evitando patrones de instrucción específicos o usando división emulada por software, pero la solución real fue reemplazar los chips afectados. El defecto estaba en el silicio.

4) Why didn’t normal testing catch it?

Porque el espacio de entradas de punto flotante es enorme, y la verificación que se basa en “casos típicos” falla en detectar patrones de operandos raros. Además, la presión de rendimiento históricamente empuja diseños hacia aproximaciones difíciles de validar exhaustivamente.

5) What’s the modern equivalent risk?

Cualquier fuente de corrupción silenciosa de datos: hardware marginal (memoria, CPU), comportamiento indefinido en código, flags de compilador agresivos, entornos FP inconsistentes en flotas heterogéneas y bugs en bibliotecas numéricas.

6) How do I protect a distributed system from silent math errors?

Usa redundancia y validación: recomputa muestras en clases de host separadas, compara implementaciones independientes, mantén perfiles de build estrictos para integridad y etiqueta salidas con procedencia para trazabilidad forense.

7) Do GPUs have “FDIV-class” problems too?

Pueden. GPUs y aceleradores pueden usar modos matemáticos diferentes (aproximaciones rápidas, operaciones fusionadas, comportamiento flush-to-zero). Si necesitas reproducibilidad estricta, debes configurarlo y probarlo.

8) Is “fast-math” always wrong?

No siempre. Es un trade-off: permites transformaciones que pueden violar expectativas IEEE. Está bien para algunas cargas (gráficos, cierta inferencia ML), peligroso para otras (finanzas, publicaciones científicas, criptografía, registros auditable).

9) What should incident response look like for correctness bugs?

Como un incidente de seguridad: congela evidencia, limita impacto, contiene por clase de entorno, comunica claramente y solo entonces optimiza. La correctitud es una propiedad de integridad, no una métrica de rendimiento.

Próximos pasos prácticos

El bug FDIV del Pentium no es solo chisme de computación retro. Es una lección operativa duradera: las fallas de correctitud no se anuncian, y “raro” no es lo mismo que “seguro”. Si ejecutas sistemas de producción donde los números se convierten en decisiones, necesitas un plan que trate la integridad del cómputo como una preocupación de fiabilidad de primera clase.

1. Inventario tu flota de cómputo por modelo/stepping de CPU y microcódigo; trátalo como una dependencia.
2. Crea clases de nodos validadas y programa cargas críticas de correctitud en ellas intencionalmente.
3. Establece un perfil de build matemático estricto y prohíbe flags inseguros por defecto.
4. Añade una puerta de huella numérica para trabajos clave: entradas con semilla fija, sobre aceptado, metadatos de procedencia.
5. Construye un runbook de on-call para correctitud que comience con comparación cruzada entre hosts y termine con contención, no con especulación.

Si solo optimizas por velocidad, eventualmente enviarás tonterías rápidas. El bug FDIV hizo pública esa lección. No necesitas una vergüenza mundial para aprenderla en privado.