El verdadero culpable del 100% de CPU es la latencia de memoria
It's the Memory Latency, Stupid
Cuando la CPU marca 100% de uso, a menudo no está ejecutando código, sino esperando a la memoria. El blog de Pivot analiza una agregación GROUP BY ingenua sobre 99 millones de filas y descubre que el 50% del tiempo la CPU se bloquea por accesos a DRAM. Aplicando particionado por radix para reducir los HashMaps y aprovechar las cachés, el tiempo de espera cae al 23,5% y el rendimiento mejora de 3,9 a 2,7 segundos.
Esto nos dice que el 50,1% del tiempo la CPU no pudo hacer nada porque estaba bloqueada esperando a la memoria. Y solo el 16,1% del tiempo la CPU estaba realmente retirando (es decir, haciendo) operaciones.
- boricj
Trabajo con otro equipo en el trabajo que usa un montón de paso de mensajes, métodos virtuales de C++ en jerarquías de clases profundamente anidadas, DOMs grandes y contenedores STL de C++ de serie... en un STM32MP1, que tiene un Cortex-A7 in-order y una miseria de caché.
Por otro lado, en mi equipo escribí mis contenedores STL de C++ personalizados que asignan en línea, bibliotecas de procesamiento estilo SAX y un pool de objetos con enlaces que usan índice+generaciones como los videojuegos de los 2000... en un STM32H5 con menos de un megabyte de RAM.
La simpatía mecánica les parece un arte perdido a las personas a las que se lo demuestro... y tuve que demostrarle al primer equipo con números de benchmark que no sería el cuello de botella entre nosotros por órdenes de magnitud.
- happyPersonR
Un saludo al autor, parece coherente.
Me gustan los flamegraphs
Sé que la gente usa perf para ayudar a generarlos
Pero en el futuro, ahora que Llm está aquí, consigue un agente que revise el ensamblador, las PMUs y también vea lo que estás haciendo en ensamblador.
Mis dos centavos y feliz codificación a todos :)
- drivebyhooting
Siento que la solución presentada es simplemente un hashmap agrupado o "sensible a la localidad" si se prefiere.
Aún así no es órdenes de magnitud mejor.
- brcmthrowaway
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
¿Alguien ha reescrito esto para 2026?