Intel Meteor Lake dispara la latencia en la memoria RAM y entre cachés, ¿no son CPU aptas para jugar?

La arquitectura Meteor Lake supone un antes y un después en Intel, como lo supuso Ryzen como tal en AMD. El problema para los azules es que "van a matar dos pájaros de un tiro", y eso normalmente no suele salir bien, porque andar demasiado de una vez sin haber gateado suele terminar en desastre. Intel no solo da el salto a MCM, sino que lo hace con Tiles en 3D independientes, y esto, según los últimos datos filtrados en un Core Ultra 9 185H con AIDA64, Meteor Lake ha mostrado unas latencias excesivamente altas.

Pues sí, una nueva filtración desde un portátil con dicha CPU ha mostrado números bastante alarmantes, que por otro lado, podrían tener una explicación, pero que por otros realmente es un problema que, salvo optimización del programa, no van a tener solución como tal. ¿Puede ser Meteor Lake el "AMD Bulldozer" de Intel?

Intel Meteor Lake puede cambiar todos los softwares de benchmark del mercado por las latencias

Intel-Meteor-Lake-Latencias-Core-Ultra-9-185H

Y es que los datos aportados son realmente malos. Estos parten del comentado AIDA64 en su última versión disponible a día de hoy, es decir, la 7.00.6700, la cual soporta al completo los nuevos procesadores Meteor Lake que llegarán esta misma semana. Este dato es importante y comentaremos algo más anexo al final del artículo, pero antes, los datos.

Lo revelado muestra una lectura de más de 85 GB/s en RAM, una escritura algo más baja de 75 GB/s y una copia de 93 GB/s, lo cual no es que sean malos datos, pero no se muestra la velocidad de la misma, y así es difícil sacar algo en claro como tal de estos valores.

Sí que vemos latencias de 62-52-52-120 CR1, las cuales son realmente extrañas, y el procesador usado es el comentado Intel Core Ultra 9 185H a 4,8 GHz, por lo que decir que la latencia de este y su IMC con la RAM citada da como resultado 133,4 ns. Esto es un valor catastrófico, no malo o alto simplemente, es un desastre total a todas luces.

Para que nos hagamos una idea, los datos de lectura, escritura y copia son bastante aceptables y parecen ser acordes a DDR5-6400 SO-DIMM (salvando los timings), pero en latencia esos 133,4 ns son prácticamente el doble frente a i9-13900H o i7-13700H.

Rendimiento de las cachés decepcionante

AIDA64 6.92.6632

Es otro de los puntos a tratar. Ni la L1, ni la L2 y mucho menos la L3 están a la altura de lo que se supone un rendimiento correcto para los datos filtrados en otras suites, que sitúan a este procesador ligeramente por encima de su predecesor homónimo.

Destacar también la latencia en la L3 con 49 ns, algo inaceptable en principio. Y decimos "en principio" porque, ¿podría ser un problema de lectura del software, del benchmark? Pues bien, AIDA64 tiene una Beta, en concreto, la 6.92.6632 que aporta tres correcciones clave al respecto:

  • Corregido: El panel de CPUID de información de caché dinámica en procesadores híbridos se ha actualizado.
  • Corregido: Cache & Mem Bench ahora detecta el tamaño de caché en procesadores híbridos
  • Se ha corregido: Caché y Mem Bench, las puntuaciones de latencia cuando está habilitado muestran mejores resultados.

¿Va a paliar esta actualización los datos mostrados? Posiblemente los maquille, pero no será suficiente, pero entonces, ¿quedan estas CPU fuera del apartado gaming por dichas latencias? Pues realmente no tiene por qué. El problema parece radicar en que el benchmark está haciendo uso de todos los Cores, incluidos los LPC, lo que dispararía la latencia al tener que acceder estos desde el SoC Tile al IMC, y al mismo tiempo, el CPU Tile también al controlador de memoria.

El problema de los LPC en benchmark de rendimiento

Meteor Lake configuración escalabilidad

Al parecer, AIDA64 no interpreta bien las dos lecturas. El IMC está en el SoC Tile, pegado a los LPC físicamente, mientras que el CPU Tile tiene que acceder por el Ring Bus a este Tile. Esto puede ser un error de lectura sin más que podría paliarse en la nueva versión, igual que el rendimiento de las cachés, pero lo que no engaña es la latencia de las L1, L2 y L3.

Aquí se ve perfectamente cómo la L1 y L2 es más o menos óptimo en tiempo de acceso, pero en la L3 se dispara a 49 ns. Curiosamente, el rendimiento de la L3 en cuanto a lectura, escritura y copia parece el más realista, así que entendemos que en esta caché de último nivel sí que se está leyendo bien el valor de la latencia, y muestra un clarísimo paso atrás de Intel.

Intel-Meteor-Lake-SoC-Tile-IMC

¿Qué puede estar pasando aquí? Pues parece el mismo caso que con la memoria RAM y el IMC. Por eso, la configuración de cada CPU se nombra como X P-Core + X E-Core + Y LPC y no se incluye a estos dentro de los E-Core como tal por estar fuera del CPU Tile. Puede que esto merme los datos de los benchmark, pero no así el rendimiento real, puesto que los LPC no son usados para tareas comunes, y mucho menos para aquellas de alto rendimiento o exigentes.

¿Tiene que sacar AIDA64 una actualización que separe el rendimiento del SoC Tile y CPU Tile para no agruparlos como un único concepto de "Cores"? Pues posiblemente, pero hasta entonces, e irá para largo, no podremos discernir correctamente cuánto afecta el diseño MCM a la latencia en Meteor Lake.

Esto lo podremos ver en los datos de gaming, por ejemplo, ya que el acceso a RAM es bastante determinante en el rendimiento en juegos. En definitiva, veremos en breve si Meteor Lake tiene un problema con las latencias y si los benchmarks tienen que cambiar para poder leer correctamente sus datos, o en cambio, están mostrando la realidad.