- En el nuevo BIOS de la ASRock B650 PG Lightning, el búfer de bucles de Zen 4 ya no se observó como fuente de micro-ops; al volver a un BIOS anterior, se reactiva
- Esta estructura parece ser una función destinada a reducir el consumo al repetir bucles pequeños desde el frontend; se estima en 144 entradas con un solo hilo y 72 entradas por hilo con SMT de 2 hilos
- En SPEC CPU2017, la diferencia de puntuación total entre el búfer de bucles activado y desactivado fue de menos del 1%, por lo que el impacto general en el rendimiento parece muy pequeño
- Cuando el búfer de bucles está apagado, Zen 4 suministra más micro-ops desde la op cache; como el ancho de banda de la op cache es suficiente frente al rendimiento del backend, es difícil que derive en un cuello de botella del frontend
- Aunque no están claros el motivo de la desactivación ni su impacto real en el consumo, se trata de una función limitada que AMD casi no documentó ni promocionó, por lo que la mayoría de los usuarios y desarrolladores difícilmente percibirán el cambio
Función y límites del búfer de bucles de Zen 4
- El búfer de bucles es una estructura del frontend de la CPU que guarda una pequeña cantidad de instrucciones ya obtenidas, permitiendo apagar algunas etapas del frontend cuando se ejecutan repetidamente bucles pequeños
- Puede ayudar a ahorrar energía
- También puede mejorar el rendimiento al esquivar limitaciones del frontend inicial
- Es una técnica usada desde hace tiempo en núcleos Intel, Arm y AMD
- Zen 4 parece ser el único caso entre los núcleos AMD de alto rendimiento que cuenta con un búfer de bucles
- La Processor Programming Reference de Zen 4 menciona el búfer de bucles como una fuente de dispatch de micro-ops junto con la op cache y los decodificadores
- Según experimentos con contadores de rendimiento, su capacidad se estima así
- 144 entradas al ejecutar un solo hilo
- Partición estática de 72 entradas por hilo cuando SMT de 2 hilos está activo
- Si dentro del bucle hay CALL/RET, el búfer de bucles de Zen 4 no puede capturar ese bucle
- La guía de optimización de Zen 4 de AMD no trata el búfer de bucles y solo aconseja mantener las regiones de código calientes dentro de la capacidad de la op cache
El búfer de bucles desaparece tras una actualización de BIOS
- Después de actualizar la ASRock B650 PG Lightning al BIOS 3.10, el monitoreo de rendimiento de hardware mostró que el búfer de bucles no hacía dispatch de micro-ops
- Al volver al BIOS 1.21, el búfer de bucles se reactiva
- La desactivación parece haber ocurrido entre AGESA 1.0.0.6 del BIOS 1.21 y AGESA 1.2.0.2a del BIOS 3.10
- AMD aplicó este cambio sin anuncio ni promoción aparte
- Según conversaciones adicionales con empleados de AMD en Hot Chips 2024, el búfer de bucles era una función orientada principalmente a la optimización de energía
La pequeña diferencia de rendimiento vista en SPEC CPU2017
- Las puntuaciones totales de las suites de enteros y punto flotante de SPEC CPU2017 muestran una diferencia de menos del 1% entre el búfer de bucles activado y desactivado
- La mejora de rendimiento con SMT tampoco se ve afectada por la desactivación del búfer de bucles
- El impacto en rendimiento es pequeño porque la op cache de Zen 4 ya ofrece más ancho de banda del que pueden consumir las etapas posteriores de rename/allocate
- Incluso con el búfer de bucles activado, los contadores de rendimiento indican que solo una pequeña fracción de las micro-ops se suministra desde él
- Tampoco se confirmaron grandes pérdidas en benchmarks individuales
- En 523.xalanbmk, el búfer de bucles se encargó de una fracción pequeña pero significativa del instruction stream, pero las puntuaciones fueron 9.48 con el BIOS nuevo y 9.44 con el BIOS anterior, dentro del margen de error
- En 544.nab, casi una cuarta parte de las micro-ops se suministró desde el búfer de bucles, pero con el BIOS nuevo, donde el búfer está apagado, la puntuación subió a 11.7 frente a 11.5 antes, un aumento del 1.7%
- Ese aumento podría deberse a variación entre ejecuciones
- En los contadores de rendimiento del BIOS nuevo, la op cache toma la parte del búfer de bucles y procesa una proporción mayor del instruction stream
- En 507.cactuBSSN se observa un patrón en el que la cobertura de la op cache baja en parte y los decodificadores suministran cerca de una cuarta parte del total de micro-ops
- Los contadores de rendimiento son una herramienta para ver tendencias generales, más que mediciones 100% exactas
- El dispatch del frontend es un evento especulativo, por lo que puede verse afectado por instrucciones obtenidas incorrectamente tras una rama mal predicha
Posible ahorro de energía y actividad del frontend
- El objetivo principal del búfer de bucles no es mejorar el rendimiento, sino apagar oportunistamente una parte importante del frontend, incluida la op cache
- Las funciones de monitoreo de rendimiento de Zen 4 incluyen una count mask, que permite contar ciclos en los que el conteo de eventos supera un umbral
- Si se pone el umbral en 1, se puede estimar la cantidad de ciclos en los que cada fuente de micro-ops realmente suministró micro-ops
- Con esto se estima qué tan a menudo puede apagarse el frontend cuando el búfer de bucles está activo
- En SPEC CPU2017, la frecuencia con la que cada fuente está activa coincide en general con la proporción de micro-ops que entregó esa fuente
- En algunas cargas de trabajo también hay una cantidad considerable de ciclos en los que el frontend no suministra nada
- 502.gcc y 520.omnetpp están muy limitados por la latencia de memoria del backend
- Si el motor de ejecución out-of-order no puede mantener suficientes instrucciones en vuelo como para ocultar la latencia, el frontend no puede enviar más al backend y queda idle
- En la suite de punto flotante, 544.nab y 508.namd usan el búfer de bucles durante una cantidad considerable de core cycles
- 508.namd es una carga de trabajo de high IPC con un promedio de 3.64 IPC, por lo que tiene una gran demanda de throughput del frontend
- Al ser favorable al búfer de bucles, ofrece oportunidades para apagar la op cache y ahorrar energía
- Cuando el búfer de bucles está apagado, la op cache alimenta al núcleo durante más ciclos
- En 523.xalanbmk, sin el búfer de bucles, la op cache debe estar activa durante un 12% adicional de los core cycles
- 548.exchange2 es una carga de trabajo de high IPC con un promedio de 4.31 IPC, pero casi no usa el búfer de bucles aunque esté activo, y la op cache está activa durante más del 85% de los core cycles
- En 508.namd, la proporción de actividad de la op cache aumenta de 56.67% con el búfer de bucles activo a 75.1% cuando está desactivado
- Un búfer de bucles de 144 entradas es pequeño para contener grandes porciones del instruction stream
- Es probable que solo tenga un efecto claro cuando el programa pasa una parte importante del tiempo en bucles pequeños y no está limitado por el throughput o la latencia del backend
Observaciones en Cyberpunk 2077
- Se revisó el impacto de desactivar el búfer de bucles en el rendimiento de juegos usando el benchmark integrado de Cyberpunk 2077
- Para mejorar la consistencia, en un Ryzen 9 7950X3D se desactivó Core Performance Boost y se limitaron todos los núcleos a 4.2GHz
- Se configuró el bit 25 del registro Hardware Configuration MSR 0xC0010015
- La RX 6900 XT se limitó a 2GHz
- La configuración del benchmark fue 1080p, preset medium, sin upscaling
- Al fijar el juego en el die con VCache, la desactivación del búfer de bucles casi no afectó el rendimiento
- Al fijarlo en el die sin VCache, se observó una pérdida de rendimiento del 5% al desactivar el búfer de bucles, aunque no se confirmó la causa
- El benchmark se volvió a ejecutar unas seis veces
- En promedio, Cyberpunk 2077 es más favorable al búfer de bucles de lo esperado: este se encarga de alrededor del 22% del instruction stream
- Tras desactivar el búfer de bucles, la proporción de micro-ops suministradas por la op cache aumentó de 62% a 82%
- Este juego no es una carga de trabajo de high IPC: promedia 0.89 IPC con el búfer de bucles desactivado y 1.02 IPC con él activado
- El ancho de banda del frontend no es una consideración importante
- Es posible que esté backend bound o limitado por retrasos del predictor de ramas
- Al ejecutarlo en el die con VCache, los contadores de rendimiento muestran un promedio de 1.25 IPC con el búfer de bucles activado y 1.07 IPC con él desactivado
- También se observó una pequeña caída de rendimiento con el BIOS nuevo
- A un nivel de 155 FPS, es posible que se haya acercado más a un cuello de botella del lado de la GPU
Incertidumbre en los resultados del contador de energía del núcleo
- Para comprobar si la ejecución desde el búfer de bucles mejora la eficiencia energética, también se revisó el core power counter de Zen 4
- El benchmark de ancho de banda de instrucciones se modificó para no usar CALL/RET en la sección de prueba
- Porque Zen 4 no usa el búfer de bucles si hay CALL/RET
- La prueba se fijó a un núcleo, y se calculó la potencia promedio leyendo el Core Energy Status MSR antes y después de saltar al arreglo de prueba
- Core Performance Boost se desactivó porque las lecturas de energía fluctuaban mucho
- Con el BIOS anterior, el Core Energy Status MSR mostraba un promedio de 6W al traer NOP desde la op cache y una potencia mucho menor al traerlos desde el búfer de bucles
- Incluso al aumentar el tamaño del arreglo de prueba hasta 128KB, que cabe en L2, para reducir la cobertura de la op cache por debajo del 1%, la potencia promedio del núcleo aparecía como 1.5W
- Es un resultado que no coincide con una situación en la que debería aumentar el uso de los decodificadores y del L2 fetch path
- Con el BIOS nuevo, la prueba con la op cache mostró un promedio de 1.68W, y la prueba suministrada principalmente por los decodificadores desde L2 mostró casi la misma potencia
- La función de monitoreo de energía de AMD podría estar basada en modelado de potencia y no en mediciones reales
- Es posible que entre versiones de BIOS haya cambiado el método de modelado o que el modelo de energía no sea correcto
- No se realizó verificación adicional por falta de hardware para medir directamente en conectores como el EPS de 12V
Motivo de la desactivación y perspectiva para desarrolladores
- No se sabe por qué AMD desactivó el búfer de bucles de Zen 4
- A veces las funciones de CPU se desactivan por bugs de hardware
- El LSD, el búfer de bucles de Intel Skylake, fue desactivado por un bug relacionado con accesos a registros parciales en bucles cortos cuando los dos hilos SMT estaban activos
- Zen 4 fue el primer intento de AMD de incorporar un búfer de bucles en una CPU de alto rendimiento, y validar una primera implementación es difícil
- Es posible que AMD haya encontrado internamente un bug no expuesto públicamente y haya apagado el búfer de bucles como medida preventiva
- Dado que el ancho de banda de la op cache es suficiente, el impacto en rendimiento parece nulo o muy pequeño
- El impacto energético se desconoce, pero podría ser pequeño y difícil de medir
- AMD casi no documentó ni publicitó el búfer de bucles fuera de una línea en la Processor Programming Reference
- Esto contrasta con Intel, que documenta con frecuencia su loop buffer y recomienda en sus guías de optimización que los desarrolladores lo aprovechen
- El búfer de bucles de Zen 4 es una función limitada, menos útil que la op cache debido a su baja capacidad y a la restricción con CALL/RET
- Si se optimiza pensando en el búfer de bucles de Zen 4 en BIOS antiguos, podrían considerarse estas condiciones
- Mantener los bucles por debajo de 144 micro-ops
- Si dos hilos comparten un núcleo físico, considerar aproximadamente la mitad de ese tamaño
- En funciones llamadas dentro de bucles pequeños, considerar inline para evitar CALL/RET
- Incluso con estas optimizaciones, lo más probable es que casi no haya recompensa
1 comentarios
Opiniones de Hacker News
Me hace pensar en la especulación de que esta función se desactivó como intento de prevenir una vulnerabilidad de hardware que no se ha divulgado
No es descabellado imaginar que AMD descubrió internamente un bug con el que nadie se había topado y, por exceso de cautela, apagó el búfer de bucle. En este punto del ciclo de vida del núcleo, no se me ocurre otra razón por la que AMD tocaría el frontend de Zen 4
Personalmente, esto me huele a mitigación por microcódigo, pero obviamente habrá que esperar el CVE
Si no se divulga la vulnerabilidad, las partes afectadas no tienen forma de empezar a responder salvo por pura paranoia. Divulgar una vulnerabilidad también es una forma de trasladar la responsabilidad al usuario final: si no actualizaste, no te quejes. Rara vez la divulgación se traduce en responsabilidad por el producto, y no recuerdo que en Meltdown o Spectre hubiera ese tipo de responsabilidad. Así que no diría categóricamente que AMD lo está ocultando a propósito
El artículo parece sugerir que el búfer de bucle no aportaba ni ganancias de rendimiento ni de consumo.
Si es así, podría ser el caso clásico de “un equipo de ingeniería pasó meses creando una función nueva y llamativa, pero no había beneficio real, y aun así alguien la lanzó para salvar las apariencias”. También he visto en equipos de software que se propone reescribir una base de código para eliminar hinchazón heredada y mejorar el rendimiento, y al terminar hay más líneas de código y peor rendimiento. En ambos casos, no deberían haberse lanzado
Es difícil creer que el equipo de ingeniería de AMD sea tan poco disciplinado como para dejar que una función de hardware sin ningún valor consuma área y energía; aquí me inclino más por la posibilidad de que Chips 'n Cheese no haya podido medir su impacto
Es muy frustrante, pero nadie quiere tomarse el tiempo de hacer una investigación previa. Impulsar un proyecto nuevo suele satisfacer más a los de arriba y genera menos preguntas
El párrafo más interesante del artículo es este: la mejor forma de ver el búfer de bucle de Zen 4 es como una señal de que AMD tiene capacidad de sobra para que sus ingenieros prueben cosas.
Tal vez esta vez no haya dado resultados, pero dejar que los ingenieros experimenten con funciones de bajo riesgo y bajo impacto es una buena forma de construir confianza. Espero ver más de esa confianza en el futuro
La parte que dice “curiosamente, si se fija al die non-VCache, el rendimiento en juegos cae 5% al desactivar el búfer de bucle. No sé por qué” me hace pensar que, con mediciones de energía más detalladas, quizá se podría determinar si está relacionado con el presupuesto térmico/de energía.
Esta función también parece tener la intención de ahorrar energía
En mi chip non-X3D, la mayoría de los núcleos del CCD0 llegan a 5.6~5.75GHz, pero los del CCD1 se quedan en 5.4~5.5GHz. Los chips Zen 4 con V-Cache tienen una penalización grande de frecuencia, pero la caché compensa más que eso. Habría que ver si probaron en el CCD1 del mismo chip tanto con la función activada como desactivada, y si intentaron aislar otros cambios como correcciones de seguridad; el propio artículo admite que “no”. Para hacerlo bien, habría que encontrar una forma de desactivar solo esta función en un BIOS donde venga activada y probar ambos casos en el mismo chip, e incluso así los resultados podrían no ser exactos por otras condiciones de ramificación. Tener un perfil completo de rendimiento aumentaría la precisión, pero probablemente solo los ingenieros de AMD puedan hacerlo
Parece que era demasiado pequeño como para marcar una diferencia real y solo tenía sentido en situaciones muy específicas. Si lo hubieran hecho más grande, el costo de implementación probablemente habría sido demasiado alto en comparación con el beneficio.
Aun así, habrá pequeñas regresiones en algunas cargas de trabajo, pero AMD también ha hecho pequeñas mejoras de rendimiento después del lanzamiento. En Zen 4, simplemente deberían haberlo convertido en una opción del BIOS. Que aparentemente no lo hayan hecho sugiere la posibilidad de un bug o un problema de seguridad
Como anécdota, una de las pocas diferencias entre el 68000 de 1979 y el 68010 de 1982 era el “loop mode”, es decir, la incorporación de un búfer de bucles de 6 bytes.
Consistía en ejecutar dos CPU desfasadas por un ciclo e inyectar una interrupción recuperable en la segunda CPU. Aun así, si querías una CPU con MMU, un conjunto de instrucciones de 32 bits y un bus de direcciones de 24 bits, parece que era más barata que las alternativas de la época. Debieron de ser tiempos realmente salvajes.
En una palabra de 18 bits caben 4 instrucciones, y un opcode decrementa el contador del bucle y luego vuelve al inicio de la palabra. En esos casos puede ejecutarse bastante más rápido.
Una de ellas tenía que ser la instrucción de bucle (DBcc), así que el cuerpo del bucle tenía que ser una sola instrucción. Prácticamente lo único que podía acelerarse era un memcpy sin optimizar.
Es interesante que en el Cortex-A15 esto sea una función central de diseño. Me pregunto si hay cifras de su efecto en otros chips.
En dispositivos con una vida de diseño más larga, como las consolas, al menos podría servir como objetivo de optimización.
Al fin y al cabo, la idea de RISC es que traer y decodificar instrucciones sea mucho más fácil, o casi trivial.
Tengo un 7950X3D, al que actualicé desde un Skylake 6700K. Parece que inconscientemente me atraen los chips cuyo búfer de bucles por hardware fue desactivado por software.
Es un artículo interesante, pero no sé cuánto espacio ocupa el búfer de bucles en el die.
Me pregunto si, de eliminarlo en chips futuros, ese espacio podría usarse para algo más útil, como una caché L2 más grande.
En teoría, un búfer de bucles puede ahorrar energía o mejorar el rendimiento en bucles muy ajustados. En la práctica parece no hacer ninguna de las dos cosas, y AMD lo eliminó por completo en Zen 5.
Si eso es correcto, tiene sentido, y el costo de área sería más bien la lógica de control adicional. La parte más cara probablemente sea detectar el bucle en primer lugar, aunque aun así debería ser bastante pequeña comparada con el tamaño de la cola.
El análisis de la sección “energía” parece no estar dividido por la cantidad de instrucciones ejecutadas por segundo.
Para ver el beneficio de este búfer de bucles, casi con seguridad habría que mirar la energía por instrucción, no la energía por segundo, es decir, la potencia (watts).
Incluso el orden y el contenido de la RAM pueden cambiarlo todo. Podrías ejecutar cientos de veces con la función activada y desactivada para aislarlo hasta cierto punto, pero llevaría muchísimo tiempo y aun así no sería 100% exacto. Solo desactivar una función puede hacer que el código tome otra rama y cambie toda la disposición. No conozco este problema en concreto, pero he visto casos en los que al desactivar una función la carga se desplazó de las unidades enteras a la FPU o la GPU, o desaparecieron 5 instrucciones pero se agregaron 2.