Los Ryzen 9000 son hasta un 35% más lentos que los Ryzen 7000 con ciertas instrucciones, ¿es este el problema de latencia entre CCD?
La semana pasada veíamos cómo varios analistas y profesionales del sector habían descubierto algo realmente interesante que podría explicar parte del mal rendimiento de la arquitectura Zen 5 debido a un diseño de la arquitectura poco optimizado para el salto entre los CCD de cada CPU con dos o más de ellos. Pues, en la noche de ayer llegaron más datos, donde los Ryzen 9000 son hasta un 35% más lentos con las instrucciones CMPXCHG16B, ¿qué significa esto y por qué es importante?
Datos nefastos de latencia entre CCD, que lógicamente, no debería de ser un problema en el llamado Core Parking para aquellas CPU con uno solo de ellos, pero... ¿Quizás hay más tela que cortar? Pues parece que sí, porque lo que se está poniendo en tela de juicio no son los modelos de procesadores con uno o dos CCD y su latencia, sino el hecho de que AMD habría tomado un camino distinto con Zen 5 frente a Zen 4.
Descubren que los Ryzen 9000 son hasta un 35% más lentos que los Ryzen 7000 con las instrucciones CMPXCHG16B
Las llamadas instrucciones CMPX en sus distintos bits han mostrado una realidad curiosa al ser comparadas entre las arquitecturas Zen 4 y Zen 5. Estas instrucciones se pueden encontrar en varios valores de bytes, siendo el que ha mostrado los resultados más dispares en los Ryzen 9000 la llamada instrucción CMPXCHG16B (Compare and Exchange 16 Bytes), es decir, con valor de 16 bytes.
Para dar una explicación simple y poder poner en contexto los datos que veremos después, esta instrucción, como su versión de 8 bytes, lo único que hace es comparar un valor de 16 bytes con otro dentro de cualquier arquitectura x86-64 a 128 bits con la memoria.
Para poder hacerlo la instrucción necesita acceder a los registros RDX del procesador, que en este caso serán de 64 bits. Estos registros son los más comunes en cualquier procesador y están diseñados para hacer operaciones matemáticas simples, o bien, según ciertos lenguajes de programación, también puede desempeñar la función típica de Calling Convention, aunque es poco común.
Como es un registro típico para aritmética, la instrucción CMPXCHG16B tiene que usar el DECODER de la CPU para la decodificación de la misma y luego poder acceder a los registros RDX, resolviendo la operación y ofreciendo el resultado finalmente. Sabiendo esto, es curioso cómo una misma instrucción que ya lleva décadas con nosotros puede dar un resultado de decodificación y latencia mucho más alto en los Ryzen 9000 que en los Ryzen 7000.
El problema de la latencia y las instrucciones
La pregunta del millón sin contestación de momento, aunque algunos ya han consultado con AMD, de momento sin respuesta. Los datos que se están viendo online informan de que CMPXCHG16B es un 35% más lenta en Zen 5 con los Ryzen 9000 que en Zen 4 con los Ryzen 7000. Para ser concretos y aportar más datos, Zen 4 logró su decodificación en 3,27 ns como valor máximo y 3,15 ns como valor mínimo de latencia.
Zen 5 y sus Ryzen 9000 para el mismo trabajo tardaron 4,44 ns, lo cual evidencia ese +35% de latencia, que como vemos, es el "mejor" de los casos, siendo el peor un +40,95%. Ryan Smith quiso saber el motivo de esto y se fue al código fuente del benchmark que mide la latencia entre CCD para terminar diciendo que dicho código solo revela CMPXCHG clásico, no CMPXCHG16B, pero la historia no queda ahí.
Otros ingenieros de software dan otra posible explicación a esto, puesto que los resultados han sido replicados por varios analistas, y afirma que CMPXCHG16B podría estar microcodificado y que ese GAP indicaría que la implementación en Zen 5 decodifica más operaciones, de ahí la mayor latencia. Comentado todo, hay varias hipótesis de lo que está pasando encima de la mesa.
¿Qué está haciendo AMD exactamente?
Como no han respondido todavía de manera oficial, solo tenemos conjeturas. Las dos principales son simples de entender: AMD no habría gastado transistores en Zen 5 para estas instrucciones (y otras), lo que supondría un ahorro de área total del silicio para otros menesteres, lo que también ahorraría energía en estos casos (opción muy poco probable por ser usada en X86-64-V2 y ser requisito de Microsoft)
Anexa a esta hipótesis, lo que se ha demostrado microscopio en mano es que Zen 5 tiene más Branch Predictions Cache de lo que se pensaba a modo de registros. Las imágenes que se han conseguido lo muestran, pero solo si la luz incide en ciertos ángulos específicos. ¿Casualidad? Seguramente no, pero tampoco podemos explicar estos cambios con esta instrucción CMPXCHG16B en los Ryzen 9000 y Zen 5, al menos, de momento.
¿Cuál es la segunda hipótesis para el mal rendimiento y mayor latencia de estas instrucciones y los saltos de CCD? Pues la que lanzamos la semana pasada sobre el microcódigo de AMD y el doble DECODER.
¿Un conjunto de todo lo dicho hasta el momento?
Si CMPXCHG8B es incluso más rápida en Zen 5 que en Zen 4, pero su versión de 16 bytes es casi un 40% más lenta, podríamos pensar que, efectivamente, es un problema de cuello de botella con el doble DECODER que ya vimos hace dos semanas y media.
La última y ya comentada es el hecho de que AMD no ha gastado transistores en CMPXCHG16B y los ha empleado en otras instrucciones o apartados, posiblemente en AVX512, ya que la matriz de Zen 5 en Granite Ridge es de mayor tamaño que la matriz de Strix Point, por ejemplo, debido a la inclusión de AVX512 como decimos.
Es posible que el potenciar la arquitectura para este conjunto de instrucciones SIMD haya repercutido en un capado de otras para poder cuadrar el área total de cada CCD, y esto sea, en conjunto y no individualmente, un precursor de una mayor latencia entre los Ryzen 9000 y Ryzen 7000, no solo por la instrucción CMPXCHG16B, sino porque podría haber otras que repliquen este hecho.
De momento, y ya con las especulaciones encima de la mesa, solo queda esperar a que AMD explique, si quiere, qué es lo que está pasando.