El mal rendimiento en gaming de los Core Ultra 200K tiene los primeros culpables: acceso a L3 e IMC y baja frecuencia del nuevo Ringbus

Las diapositivas de Intel sobre Arrow Lake-S han dado la vuelta al mundo y en el apartado del gaming, no para bien precisamente. Ya dejé entrever desde hace dos meses que el rendimiento en gaming no iba a ser bueno por una fuente confiable, y parece que así será, aunque las expectativas estaban altas y un servidor intentó bajarlas, sigo pensando que el rendimiento de una CPU como el 285K estará parejo al i9-14900K, posiblemente por encima en algunos juegos, por debajo en otros, pero, ¿Qué está motivando este mal rendimiento? Pues parece ser que los Core Ultra 200K tienen dos motivos al menos: acceso a L3 e IMC y Ringbus.

Seremos repetitivos otra vez: el principal cuello de botella desde hace años en PC y servidor es la latencia, y lo seguirá siendo por encima de cualquier otra especificación disponible. Intel lo sabe y por ello ha mantenido la arquitectura monolítica el mayor tiempo posible, introduciendo MCM en portátiles de ultra bajo consumo con la arquitectura Meteor Lake y ahora con Lunar Lake, lo cual nos dejó pinceladas de por dónde iban a ir las cosas.

Los Core Ultra 200K rinden mal en juegos porque la arquitectura Arrow Lake tiene serios problemas con la L3 y el Ringbus

¿Por qué Arrow Lake-S va a ser una arquitectura que va a lograr un mayor rendimiento en multitarea, software y benchmarks varios, pero va a ser nula en gaming? Bueno, solo hay que mirar a Meteor Lake y Lunar Lake. El cambio de Intel hacia MCM como arquitectura tiene, como le ocurrió a AMD con Ryzen, importantes cambios en el back-end, y posteriormente en el front-end. 

Es lo que hemos visto con las arquitecturas nombradas, primero se dio el salto con el back-end y luego se mejoró el front-end, de ahí las microarquitecturas y su mejora. Pero en PC... Se ha dado otro paso más. En PC Arrow Lake-S es un cambio total de back-end y front-end al que se le ha sumado la retirada de HT, y supuestamente, un nuevo sistema jerárquico de L3, que aunque no es seguro parece interesante.

El diagrama de bloques filtrado reveló en su momento que la arquitectura podría tener una gran caché L3 compartida entre P-Cores y E-Cores, pero... Esto no es así en Lunar Lake teniendo la misma microarquitectura. Como hemos visto en la presentación de esta última, el salto es inferior en IPC dentro de Skymont, donde Arrow Lake presenta más incremento.

Parece, según lo filtrado y los datos que se están mostrando cogiendo de ejemplo al Intel Core Ultra 7 258V, que Intel tiene un problema con la latencia de la caché L3 y, en menor parte, con el Ringbus, al menos dentro de los Core Ultra 200K.

¿Qué sabemos exactamente y qué revela la microarquitectura?

Pues que los P-Core con microarquitectura Lion Cove son un paso adelante importante en rendimiento por GHz al enfrentarlos contra Redwood Cove, pero muestran una debilidad: la latencia de la caché. Los datos aportados por David Huang así lo muestran, y como bien dice, los 8 Wide no van a paliar esto.

Hay otro dato más, y es el hecho de que en una filtración adyacente se mostró que el Ringbus, lo que ahora debería ser en el diagrama de bloques el Coherent Fabric (¿estilo NOC de Lunar Lake?) tiene una frecuencia muy inferior al de Raptor Cove.

En concreto, se dice que es 1,1 GHz inferior (285K vs 14900K), y esto también afecta a la latencia, desde luego, tiene sentido.

Curiosamente, de poco le vale a Intel introducir más L3 si el tiempo de acceso a la misma y el Ringbus aumentan y bajan su frecuencia respectivamente, creando un problema de rendimiento en los Core Ultra 200K.

Si a esto le sumamos dos factores más como son unas frecuencias inferiores a los Core 14 y además, una "baja" escalabilidad de la SRAM en cuanto a densidad, tenemos un cóctel difícil de mejorar por parte de los azules por implementar el nodo N3B en vez de Intel 20A. Además, si lo que vimos en la diapositiva de calor de un Core Ultra 200K es cierto, la disposición sería tal que así partiendo de la proximidad del Compute Tile con el SoC Tile:

P-Core -> Clúster de E-Cores -> P-Core -> P-Core -> Clúster de E-Cores -> P-Core

Siendo esta configuración simétrica a lo largo del Compute Tile en el lado más largo del rectángulo que supone su gran área. ¿Y esto a qué viene y por qué parece ser así?

Hasta ahora los P-Core y E-Core se han unido mediante sus clúster particulares, pero no mezclándose, y los E-Core no tenían acceso directo a la L3 de los P-Core, de hecho tienen L2 propia, pero no L3 como tal.

Los E-Core arrastran a los P-Core, de ahí la mejora en los primeros y el rendimiento de los segundos

La disposición arriba mostrada tiene dos objetivos que enlazan con lo que hablamos del Hot Spot movido al norte: mejorar la disipación de calor y permitir un acceso de los E-Core a la L3 mediante el nuevo Ringbus en los Core Ultra 200K, algo que Lunar Lake no tiene y todo se conecta con el NOC, estando los clúster separados.

¿Cuál es el problema fuera de la mejor disipación de calor? Que si esto es cierto, y no nos equivocamos, Intel ha tenido que "enlazar" con el Coherent Fabric a modo de Ringbus los P-Core y los E-Core para compartir la información. Esto explicaría en parte el descenso de la frecuencia del Ringbus de 1,1 GHz y la mayor latencia en la L3, y al mismo tiempo el mayor aumento de rendimiento de los E-Core Skymont frente a lo visto en Lunar Lake.

Además, hay otro factor a tener en cuenta: el controlador de memoria está en el SoC Tile con su Memory Fabric.

Intel está sufriendo los mismos problemas que AMD al entrar en la era MCM para PC

Aunque Intel haya introducido un NOC (¿el D2D mostrado?) esto no va a compensar el aumento de la latencia, como Infinity Fabric no lo compensa en Ryzen al tener el IMC en el IOD. Esto no pasa, por ejemplo, en Lunar Lake (imagen superior), ya que todo está en el mismo Compute Tile y el NOC logra mejorar el rendimiento entre Tiles, Clústeres e IMC.

Explicada la hipótesis que une los tres problemas, ¿cuánto corresponde a cada uno? Eso es lo que está por ver. Intel parece haber sufrido parte de los problemas que tuvo AMD con Ryzen en su primera generación, y este sería también el motivo de quitar el HT en Lion Cove, algo que no tenía sentido en un principio en Lunar Lake, pero sí que lo tiene en Arrow Lake por todo lo comentado.

De momento no tenemos más datos y esto podría cambiar o modificarse, pero es una buena teoría de base que explicaría todo en su conjunto, algo complicado sin duda. De hecho, también explicaría el por qué Intel decidió cancelar Arrow Lake-S Refresh, visto lo visto, y si vamos bien encaminados, sería mejor dejar paso a Panther Lake para aumentar el rendimiento en gaming.