ASUS desvela por qué el nuevo Ringbus de los Core Ultra 200S es un problema a mayor número de núcleos

Desde antes del lanzamiento de los Core Ultra 200S hemos estado hablando de todo lo que encierra la nueva topología de núcleos de Arrow Lake-S, que compartiendo microarquitectura Lion Cove y Skymont con Lunar Lake, realmente su Compute Tile poco, o casi nada, tienen que ver desde este punto de vista. Teorizamos con algo bastante rocambolesco hace unas semanas que hoy toma un cáliz más interesante si cabe, puesto que desde ASUS han confirmado algo que solo intuíamos: el Ringbus de Intel es un problema a mayor número de Cores totales en estos Core Ultra 200S.

Específicamente los P-Core, algo bastante curioso que vamos a tratar de la mano de la marca, en concreto, de su overclocker más famoso y veterano como es Shamino, el cual con su guía de overclock ha dejado claro que Intel podría tener algo más que decir en el sector del gaming frente a AMD.

El Ringbus de los Core Ultra 200S, dos pasos adelante, un paso atrás

Intel-Core-Ultra-200S-Core-Ultra-9-285K-die-shot-diagrama-de-bloques

Dos adelante porque supone homogeneizar el acceso a la L3 de P-Core y E-Core de igual manera, permitiendo además algo que se intuía: el desacoplamiento de dicho Ringbus de los núcleos. Es decir, los núcleos y el Ringbus pueden ser overclockeados en frecuencia y voltaje de forma independiente permitiendo además frecuencias también independientes en P-Core y E-Core.

Es una multiplexación total, lo cual deja una configuración en cuanto a especificaciones diferente entre las tres CPU mostradas. De hecho, Shamino aclara cualquier polémica al respecto diciendo que en el Core Ultra 7 265K y Core Ultra 9 285K tenemos un grupo de P-Cores central, tal y como se muestra en el diagrama superior del die shot, cuatro para ser concretos.

Estos están justamente en el centro del Compute Tile, lo cual obligó a mover el Hot Spot como vimos en otro artículo. ¿Qué ocurre con estos cuatro P-Cores que comparten ambos procesadores? Pues que el Core Ultra 5 245K tiene dos de ellos desactivados para hacer su configuración de 6+8, seguramente en diagonal para mejorar la temperatura.

Frecuencias diferentes, tiempos de acceso y latencias distintas

Intel-Core-Ultra-200S-Ringbus-mejora-con-P-Core-en-frecuencia-según-menor-número-de-núcleos

No es solo que el 285K sea un 8+16, el 265K un 8+12 y el 245K un 6+8, sino que su Ringbus no tiene la misma frecuencia. Los dos primeros y más potentes tienen una frecuencia de 4,2 GHz, mientras que el menor de todos ellos la eleva a 4,4 GHz. El overclocker asegura que estos es debido única y exclusivamente por la desactivación de esos 2 P-Core centrales y no tanto por los E-Core que se pierden también.

Las reviews han mostrado, a misma placa y memorias, algo que confirma este hecho, como bien han mostrado en los tres procesadores los compañeros de TPU:

Lo que vemos es un aumento de la latencia de la L3 entre el 245K y sus hermanos bastante evidente: de 13,7 ns a un máximo de 16,3 ns, que puede parecer una nimiedad, pero significa un tiempo de acceso un 18,97% mayor cuando se pasa de 6 P-Core a 8 P-Core en ambas CPU de gama alta, pero la diferencia de frecuencias apenas supera el 4%.

Curiosamente, del 265K al 285K apenas hay variabilidad, incluso del mayor logra mejor latencia, aunque por la mínima, pese a tener más E-Core. Esto explica sin duda por qué estas tres CPU están tan cerca en gaming pese a separarlas un 10% en total entre la más lenta y la más rápida en frecuencias Boost en P-Core, manteniendo los mismos MHz en E-Cores y teniendo hasta un 50% menos de L3.

¿Podría Intel lanzar una CPU sin E-Cores solo para gaming al estilo Ryzen 7 9700X con mayores frecuencias en Ringbus y P-Core?

Intel-Core-Ultra-200S-Compute-Tile-solo-con-P-Core-sin-E-Cores

Esto también deja clara la importancia del Ringbus en esta generación, donde como veremos más tarde, el overclock a este bus junto con pequeños parámetros hace despegar el rendimiento en hasta un 21% en FPS, lo que les igualaría teóricamente al 9800X3D de stock.

Por tanto, ¿podría Intel dar la sorpresa con una CPU que solo tuviese P-Core y desactivase los E-Core para maximizar la frecuencia del Ringbus por encima de esos 4,4 GHz y tener los 36 MB de L3 disponibles? Posible es, y seguramente sería un salto muy interesante si consiguen, además, pasar de los 5,7 GHz en esos P-Core y acercarse a los 6 GHz.

La última cuestión a abordar también es simple de comprender, y la imagen bajo este párrafo frente a la superior lo muestra. Lo que vemos justo arriba es un die falso de Intel que usó en los render de Arrow Lake, lógicamente para despistar a AMD. Podemos ver los 4 Clústeres de E-Cores a la derecha del Compute Tile, el Ringbus atravesándolo todo y los P-Core a ambos lados del mismo y a la izquierda de la imagen.

Intel-Arrow-Lake-S-Die-Fake

¿Por qué Intel no hizo un diseño así? Por varios motivos. El primero es que del Core 0 al Core 15 serían E-Cores. Esto es un problema con el nuevo Thread Director, porque se tardaría demasiado en mover la información hasta el primer P-Core, si así se considera.

El segundo motivo es de temperatura. El Hot Spot quedaría demasiado arriba y a la derecha, no permitiendo una correcta refrigeración sobre cada procesador. Pero el más importante es el hecho de que la L3 no sería compartida por P-Core y E-Core. El concepto a futuro de Intel es no usar E-Cores, sino optar por diseños de P-Core más simples, y unificar con ello el acceso a caché con Cores de menor tamaño y distancia entre ellos. Por eso el Ringbus está en Arrow Lake-S y sus Core Ultra 200S en el centro de toda la controversia, no tanto por la arquitectura general del die MCM o buses como D2D, o que el IMC esté en el SoC Tile.

Intel ha demostrado con Lunar Lake que con un NoC puede integrarlo todo en el Compute Tile, pero con un número limitado de núcleos. Es más que probable que Panther Lake mezcle ambos conceptos: el Ringbus con la L3 de Arrow Lake-S y el introducir GPU, IMC y NPU dentro del Compute Tile. Veremos dentro de un año cuánto nos equivocamos y si este paso no solamente es necesario para ese concepto, sino para el de caché vertical, como explicamos en otro artículo.