Mostrando entradas con la etiqueta análisis. Mostrar todas las entradas
Mostrando entradas con la etiqueta análisis. Mostrar todas las entradas

jueves, 2 de febrero de 2017

AMD Excavator 28 nm – ProfessionalSAT

Os dejo aquí el enlace a mi último artículo en otro de mis Blogs, LowLevelHardware sobre la nueva microarquitectura de AMD.

Carrizo_Bulldozer_GensLos cores AMD Excavator 28 nm en el nuevo AMD Carrizo.

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes. Gracias de antemano.

El que tenga dudas o aportaciones tiene para ello la sección de comentarios, intentaré responder a todos y con la máxima claridad. Los Blogs deben de ser lugares de intercambio y agradezco vuestro feedback.

Carlos Yus Valero – informaticapremium      informaticapremium-logo-150px[3]

AMD Steamroller core. AMD Kaveri. Introducción. – LowLevelHardware

El 14 de Enero AMD sacó al mercado su tercera iteración de la micro arquitectura Bulldozer en la forma de la APU Kaveri fabricada por Global Foundries es el nodo Bulk SHP (Super High Performance) de 28 nm. En este caso se trata de una implementación de dos módulos con dos INT cores y una FPU compartida junto con una excelente GPU GCN 1.1 de 512 SPs.

excavator

La micro arquitectura AMD Bulldozer

Primero fue Bulldozer 32 nm HKMG, después Piledriver 32 nm HKMG y ahora Steamroller 28 nm Bulk SHP. Posteriormente, 2015, está previsto Excavator, la evolución final y que pondrá término a esta micro arquitectura. Después preveo que AMD, por fin, se centrará en diseñar cores de alto IPC y menor consumo para competir con mayor igualdad con los cores contemporáneos de Intel.

Como muchas veces ha sucedido con los diseños de AMD, en su primera versión.

En este caso Bulldozer 32 nm HKMG (AMD FX 8150) las prestaciones, consumo y disipación térmica no fueron las esperadas.

Piledriver 32 nm HKMG (AMD FX 8350) alivió ligeramente los problemas de consumo y mejoró las prestaciones.

AMD Steamroller 28 nm Bulk SHP

Con Steamroller AMD plantea un cambio mucho más profundo:

  • Una evolución de la micro arquitectura mayor que en el caso de Bulldozer a Piledriver, con claras mejoras en algunos campos y otros cambios no tan claros en otros aspectos.
  • Un nuevo nodo de fabricación: del ya antiguo nodo premium HKMG 32 nm de Global Foundries utilizado en Bulldozer y Piledriver se pasa al nodo de 28 nm Bulk SHP, más orientado a menor consumo y mayor densidad (más transistores por mm2), es decir menor coste por chip y menor TDP, es decir, mayor performance per watt.

module-block

En la segunda parte de esta serie de artículos detallaré las mejoras implementadas en Steamroller por AMD y lo que significan de cara a sus encarnaciones presentes:

La APU Kaveri y los futuros chips FX Steamroller de alto rendimiento del que parece que están preparando una versión con 8 módulos y 16 INT cores con controladoras PCIex 3.0 integradas en el die del chip (lo que permitiría deshacerse del  North Bridge del chipset) que probablemente funcionará a frecuencias conservadoras en carga full threaded aunque con agresivos modos Turbo.

En múltiples entregas de LowLevelHardware y ProfessionalSAT he analizado en detalle el diseño interno de AMD FX Orochi 32 nm. Cito los más destacables:

AMD Bulldozer. Mi opinión personal. Parte 1. Actualizado – ProfessionalSAT

AMD Bulldozer. Frecuencias finales. Actualizado – LowLevelHardware

AMD Bulldozer- HotChips23 – LowLevelHardware

AMD Bulldozer. Perspectivas – LowLevelHardware

La L3 cache multibanco en AMD Bulldozer. Actualizado – LowLevelHardware

AMD AGLUs, Bulldozer INT cores. Actualizado – LowLevelHardware

AMD Bulldozer. Primeros benchmarks. Actualizado – LowLevelHardware

AMD Bulldozer – ProfessionalSAT

La micro arquitectura de AMD Bulldozer. Actualizado – LowLevelHardware

Novedades y expectativas 2010. Actualizado – LowLevelHardware

AMD Bulldozer. Prestaciones estimadas – LowLevelHardware

Micro arquitectura AMD Bulldozer 2011. Actualizado – LowLevelHardware

Previo AMD Bulldozer. Actualizado – LowLevelHardware

Análisis de Piledriver en mis Blogs:

AMD Vishera FX 8350. Primeras impresiones – ProfessionalSAT
AMD Piledriver core. Actualizado 04/03/2012 – LowLevelHardware

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes. Gracias de antemano.

El que tenga dudas o aportaciones tiene para ello la sección de comentarios, intentaré responder a todos y con la máxima claridad. Los Blogs deben de ser lugares de intercambio y agradezco vuestro feedback.

Carlos Yus Valero – informaticapremium      informaticapremium-logo-150px[3]

AMD Vishera FX 8350. Primeras impresiones – ProfessionalSAT

Siendo sincero debo admitir que me ha sorprendido gratamente el nivel de prestaciones de la nueva serie de CPUs FX de AMD basadas en el nuevo stepping dotado de cores Piledriver.

En un artículo de LowLevelHardware exploré detalladamente las mejoras que aportaba este core refinado, este nuevo stepping a la conocida micro arquitectura Bulldozer de AMD.

PiledriverCORE_640Piledriver module con sus 2 MB de caché L2.

Podríamos sintetizar las mejoras en dos fundamentales:

- Por un lado una menor disipación térmica por core y un menor voltaje mínimo estable a una frecuencia dada. A igual frecuencia menor consumo y temperatura.

- Por otro lado un aumento IPC de un 5 a 30% en función de la carga de trabajo (enteros, branches, coma flotante, SSE, AVX,…) A igual frecuencia más rendimiento.

Gracias a estas dos mejoras AMD ha conseguido incrementar la frecuencia base del FX 8350 en 400 MHz.

PDvsBSAMD FX8150 vs. FX8350. Bulldozer vs. Piledriver.

En modo Turbo Core Vishera aplica el Turbo máximo en todas las situaciones, es decir, en carga máxima de un thread (ST, single threaded) o de varios threads e incluso 8 threads simultáneos (MT, multi threaded):

BD_TurboTurbo Core en FX8150 Bulldozer.

Podemos decir, para simplificar, que en Vishera el estadio intermedio Turbo Core desaparece.

En la práctica, medido por mí mismo, un Vishera FX8350 a 4 GHz en Prime95 Blend 4 GB consume exactamente lo mismo a un Bulldozer FX8150 a 3.6 GHz a voltajes nominales.

PiledriveModule_640Bulldozer module 32 nm SOI HKMG.

Como deduciréis fácilmente, Vishera aportará un 11% más de frecuencia en cargas paralelas y en cambio no incrementa nada en cargas single threaded. Por ello en cargas ST el rendimiento solo aumentará por el incremento de IPC y en cambio en cargas MT se sumará el 11% de frecuencia nominal al incremento IPC.

Undervolting

A esto debo añadir que tanto en los antiguos FX Bulldozer como en los nuevos Vishera AMD ha sido bastante exagerado en cuanto a los voltajes a los que vende sus CPUs. Normalmente son absolutamente estables a voltajes 0.100 – 1.150 V inferiores a los nominales. Con ello además ganamos unos 20 – 30 W en consumo y 10 – 15 ºC de temperatura. Merece la pena hacerlo aunque con ello perdamos horas o incluso a veces algunos días.

AMD debería hacer este proceso en fábrica pero resulta laborioso y por ello caro. De este modo saca al mercado las CPUs a un voltaje excesivamente prudente para asegurar su estabilidad sin probar individualmente en exceso cada uno de los chips para ajustar individualmente su voltaje.

Piledriver. Mejoras micro arquitecturales respecto a Bulldozer.

AMD ha mejorado Bulldozer en muchos aspectos aunque sin cambiar nada importante del diseño, de hecho Piledriver no es más que un stepping más avanzado del mismo core.

piledriver_enhancements_640

Se ha mejorado el Branch Prediction, algo crítico en este diseño debido a su larguísimo pipeline. Esto mejorará el rendimiento sobretodo en cargas de enteros.

Se ha activado la unidad de división de enteros (INT Div, iDiv) que estaba deshabilitada en Bulldozer por un fallo de diseño, como comenté en Abril de 2011 en mi artículo:

AMD AGLUs, Bulldozer INT cores. Actualizado – LowLevelHardware

“ EX0 contiene una unidad de división de enteros parcialmente pipelinizada y con latencia y capacidad de proceso variable en función de la precisión. Aunque examinando detenidamente la documentación parece que más bien se trata de una unidad “virtual” ya que la instrucción IDIV se decodifica en el Microcode Engine y se secuencia en instrucciones sencillas ALU que se ejecutan en EX0. Además incluye una unidad para LZCNT y POPCNT.

Efectivamente, en Bulldozer, la unidad iDiv no estaba habilitada y por ello la latencia y velocidad de las divisiones de enteros eran tan decepcionantes. Por fin, en Piledriver se encuentra habilitada.

Se ha doblado el tamaño del L1 dTLB (TLB de datos de nivel 1). Para el que quiera amplia información sobre para que sirve un TLB le remito a algunos artículos pasados.

piledriver_enhancements2_640

En total todas estas mejoras aumentan el IPC de un 5 a 30%, en general sobre un 10%. En el caso del 30% es más por un rendimiento terrible de Bulldozer en algunas tareas que por méritos de Piledriver.

En cualquier caso podríamos caracterizar las prestaciones de Piledriver en el AMD FX8350 del siguiente modo:

- Cargas de trabajo de enteros con excelente paralelización y con carga máxima en los 8 INT cores. Ejemplo: compresión de datos en WinRAR o 7zip LZMA2. Prestaciones generalmente muy superiores al Core i5 3570K y superiores al Intel Core i7 3770K.

- Cargas de trabajo de coma flotante con excelente paralelización y con carga máxima en las 4 FPUs FMACs con 8 threads.

  Ejemplo 1: Rendering, cálculo matemático. Prestaciones generalmente bastante superiores al Core i5 3570K y ligeramente inferiores al Core i7 3770K. En PovRay en cambio el más rápido y por buen margen es el FX8350.

   Ejemplo 2: Edición y codificación de video x264 / H264. Prestaciones generalmente superiores al Core i7 3770K y muy superiores al Core i5 3570K.

- Cargas de trabajo principalmente de enteros con baja paralelización y raras veces con carga máxima en 4 INT. Ejemplo: SysMark 2012, compilación y usos multitarea de la máquina en Windows con varias aplicaciones a la vez. Prestaciones muy similares o algo inferiores al Core i5 3570K (como mucho un 10%).

- Cargas de trabajo de enteros single thread o con paralelización muy leve. Ejemplo: instalaciones de software, instalación de sistema operativo, javascript. Prestaciones inferiores a Core i5 3570K hasta un 40% en proceso javascript.

Si hacemos la media el FX8350 nos da un rendimiento superior en un 5% al Core i5 más alto de gama, el i5 3570K que está situado por encima en precio (unos 20 – 30@ más).

El Core i7 3770K se sitúa en un nivel de prestaciones superior gracias al Hyper Threading como atestiguan sus más de 150€ extras de coste.

Conclusiones

Lo más positivo que puedo sacar de Vishera es su notable aumento de velocidad de trabajo en aplicaciones ofimáticas respecto a Bulldozer (ha mejorado más de un 20%) y el hecho de haberse convertido en el rey en prestaciones en temas de video, sobretodo en coding x264. En estos casos supera incluso al excelente y mucho más caro Core i7 3770K.

FX8350_640El die completo del procesador AMD FX 8350 32 nm.

Vishera mantiene exactamente los niveles de consumo y disipación térmica de los anteriores AMD FX con un rendimiento medio en cargas multithread de un 20% (ayudado por los 400 MHz extras) superior y un 5 – 10% en cargas single thread (con igual frecuencia).

Post Scriptum

Animo a los posibles compradores de estas CPUs a cambiar el funcionamiento nominal de Turbo Core. AMD ha dejado invariado el Turbo Core con carga single threaded o dual threaded a 4.2 GHz respecto a Bulldozer.

En Bulldozer FX8150 la disipación térmica y consumo era prácticamente igual con cargas MT de 8 threads (3.6 GHz) que en single o dual threaded (4.2 GHz) e igual a 125W.

En Vishera, en cambio, con cargas de 8 threads (4.0 GHz) llega a los declarados 125W en Prime95 pero con cargas single o dual threaded (4.2 GHz) se queda corto marcando unos 100 – 105W.

Los samples que he probado del AMD FX8350 son absolutamente estables en cargas single o dual threaded a voltaje nominal a 4.6 GHz y manteniendo siempre la disipación térmica por debajo de los 125W nominales. Para ello, en BIOS, cambio manualmente el funcionamiento de Turbo Core aumentando el multiplicador máximo a 46X.

En este caso conseguimos otro 9 – 10 % adicional de velocidad en casos ST (single threaded), el talón de Aquiles de esta micro arquitectura.

Echad un vistazo a la web de mi nueva empresa, un proyecto de gran envergadura que llevo preparando hace más de un año.

Os lo recomiendo para diseño de sistemas de altas prestaciones optimizados al límite:ip16_texto_300px_blanco422222

Allí tenéis a vuestra disposición el formulario de contacto, para consultas sobre este artículo hacedlo más abajo en la sección de comentarios.

Y mi nuevo Blog de contenido muy técnico y actualizado donde encontraréis artículos míos sobre hardware, procesadores y sistemas y también otros posts de expertos programadores e informáticos sobre otros temas de actualidad:

infromaticapremium-blog422222

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes. Gracias de antemano.

El que tenga dudas o aportaciones tiene para ello la sección de comentarios, intentaré responder a todos y con la máxima claridad. Los Blogs deben de ser lugares de intercambio y agradezco vuestro feedback.

Carlos Yus Valero – informaticapremium      informaticapremium-logo-150px[3]

AMD 6990 CrossFireX. Dinámica de fluidos y disipación térmica – ProfessionalSAT

La semana pasada entregué uno de mis Sistemas de Altas Prestaciones especializado en proceso OpenCL mediante dos tarjetas AMD 6990 con 4 GPUs Cayman y 8 GB de GDDR5 a 5 GHz.

DSCF2305AMD 6990 CrossFireX.

Me ha llevado unas cuatro semanas todo el proceso, desde la elección de los componentes hasta el diseño de la refrigeración y la validación del sistema para asegurar su estabilidad total en cargas máximas sostenidas OpenCL.

DSCF2366

En este artículo detallaré el diseño de la exigente refrigeración del sistema y los resultados térmicos de su implementación, siendo una refrigeración por aire para un total de casi 1000W de consumo máximo.

Optimización del consumo eléctrico

El primer paso en la refrigeración de cada uno de mis Sistemas de Altas Prestaciones consiste en minimizar el consumo eléctrico de cada componente. Esto se consigue mediante la modulación independiente de los voltajes en BIOS.

DSCF2284La excelente Cooler Master Silent Pro Gold 80+ Gold alimenta el sistema.

Siempre empiezo marcando manualmente los voltajes mínimos estables (según los Data Sheets del fabricante, en este caso Intel) de cada parte del chipset. Hago lo mismo con la memoria, esta máquina se ha entregado con la DDR3 a 1.500 V.

Posteriormente entramos en la regulación de voltajes del procesador. Primero el voltaje en reposo en su estado de frecuencia mínima. En procesadores Sandy Bridge 2500K y 2600K escogidos he validado como estable los 0.712 V a 1.6 GHz.

Ahora llega la parte más dificultosa, el voltaje en carga máxima de CPU con los 4 cores al 100 %. En función del “sample que nos toque” estaremos sobre los 1.28 - 1.34 V a 4.4 GHz en un 2600K con 8 threads al 100% con absoluta estabilidad.

En las tarjetas AMD 6990 con dos GPUs Cayman cada una, los voltajes de core son 0.900 V en reposo a 250 MHz y 1.120 V en carga a 830 MHz (ajustes nominales).

DSCF2287

En los dos ejemplares utilizados a este voltaje es posible llegar a los 900 MHz fuera de especificación con absoluta precisión en las cargas de trabajo OpenCL en carga 100% con la refrigeración utilizada a unos 80 – 82º C pico tras 24 h de cálculo con usos de GPU mínimos del 98%.

En reposo en el escritorio de Windows 7 Ultimate X64 el consumo del sistema en el enchufe es de unos 145W.

DSCF2329

Debido a esta minimización del consumo eléctrico de cada componente he conseguido disminuir el consumo pico total desde los casi 1100W iniciales hasta los 939W finales en carga 100% sostenida.

DSCF2333Dual AMD 6990 CrossFireX: 939W en pico a 880 MHz, a velocidad de AMD 6790.

El consumo de la refrigeración.

Un dato a resaltar en un sistema de estas características dotado de muchos ventiladores y alguno de ellos de alto rendimiento es el consumo puro de la refrigeración.

Solamente variando del mínimo al máximo los 4 ventiladores regulables de este sistema y las dos turbinas de las dos tarjetas AMD 6990 arroja una diferencia de consumo de 40W debida al incremento de rpm de los motores de 12V. Nada despreciable.

Por otro lado recordar que los semiconductores incrementan su disipación térmica y consumo en función de la temperatura debido al incremento en el leakage de los transistores (pérdidas de corriente cuando está en off, en caso extremo degenera en electromigración). Por ello es conveniente controlar las temperaturas y no entrar en rangos peligrosos.

Diseño de la refrigeración del sistema AMD 6990 CrossFireX.

Desde el primer momento en que el cliente me encargó la máquina tuve claro que debía separar totalmente los flujos térmicos provenientes de la 4 GPUs del resto del sistema para evitar problemas en otras áreas.

DSCF2373

Además era crítico extraer inmediatamente los 850+ W disipados en las GPUs de la torre evitando crear realimentaciones de aire caliente a otras partes del sistema.

Para ello dividí la máquina en tres alturas o zonas térmicas independientes, cada una de ellas con sus flujos de aire separados y diferenciados y rutas independientes de entrada y salida de aire.

Las tres áreas de refrigeración.

En la zona superior y la intermedia (zonas 1 y 2) la salida de aire se efectúa por la parte frontal de la torre mediante ventiladores de 12 cm, en cambio en la zona inferior la salida es a través de la fuente de alimentación y del panel trasero de la torre.

DSCF2313Las tres zonas diferenciadas de refrigeración.

Zona 1. CPU, parte superior de placa base y memoria DDR3.

En esta zona se produce una disipación térmica estimada pico de unos 130 – 150 W.

La verdad es que refrigerar un Core i5 2500K a 4.2 GHz no es tarea difícil, un simple Arctic Cooling Freezer 7 PRO 2 modificado para socket 1155 basta.

DSCF2299

Esta CPU disipa unos 110W a la frecuencia objetivo de 4.2 GHz. Esta frecuencia ha sido seleccionada en función de la carga de trabajo OpenCL ejecutada en las 4 GPUs. La carga de CPU media es del 80% en los cuatro cores con el software elegido.

DSCF2302

He creado un diseño de refrigeración absolutamente desproporcionado para esta zona queriendo así crear un exceso neto de presión dentro de la torre pensado en refrigerar con este excedente la Zona 2, la más crítica.

DSCF2303La salida de aire de la Zona 1 antes de montar su ventilador de salida.

He situado tres ventiladores de entrada en esta zona, uno de 14 cm y dos de 12 cm, el refrigerador de CPU lo he montado en dirección inversa a la normal (hacia el frontal de la torre). El aire “caliente” (medido en salida frontal está a unos meros 28º C en carga máxima) de esta zona se evacúa por el frontal.

DSCF2317Durante varios días fui variando la colocación del divisor de flujo superior.

Zona 2. AMD 6990 CrossFireX.

En esta zona se produce una disipación térmica estimada continua en carga máxima de unos 800 – 850 W.

La inyección de aire frío del exterior se produce por dos entradas independientes, la primera es desde la parte superior, desde la Zona 1.

DSCF2321Entrada doble superior para aumentar la presión interna.

La segunda y más importante entrada se produce a alta presión mediante dos ventiladores Scythe de 12 cm de alto flujo colocados a 8 mm de las tarjetas AMD 6990, el aire viene del panel lateral perforado.

DSCF2305Los dos Scythe evitan los excesos térmicos en el sistema CrossFireX.

Su función es inyectar aire en el espacio inter GPUs y evitar el estancamiento de aire evitando los Hot Spots.

Sin estos ventiladores Scythe no comerciales la temperatura en tests OpenCL con carga 100% en las 4 GPUs alcanzaba los 92º C en sólo un minuto…

DSCF2388Gracias a “mis contactos” tengo acceso a componentes no comerciales.

Con ellos el pico máximo obtenido tras 24h en carga máxima OpenCL con relojes a 880 MHz (a frecuencias de AMD 6790) es de solamente 82ºC y con frecuencias nominales de 830 MHz nos quedamos en menos de 80ºC.

A modo de referencia en Furmark con carga 100% en las 4 GPUs en modo Extreme Burning alcanza 61ºC en la GPU más caliente tras 2h.

DSCF2304Estos ventiladores llevan reguladores de rpm montados en la parte trasera de la torre.

La salida del aire caliente procedente de las GPUs 1 y 3 (las GPUs a la izquierda de las tarjetas AMD 6990) sale de la torre a través del panel trasero y gracias al exceso de presión interno no vuelve a entrar (no hay reflujo) ya que en el canal entre las dos tarjetas soplan sendos ventiladores Scythe.

DSCF2379En la configuración final minimicé la turbulencia consolidando el cableado.

La evacuación de aire de las GPUs 2 y 4 es más complicada. Se  realiza por su diseño dentro de la torre amenazando a otros componentes con su potente chorro de aire a 60ºC.

DSCF2308Una de las pruebas que realicé. Tapar el final del espacio entre las tarjetas.

El objetivo en este caso consiste en crear mayor succión que la presión de salida de las turbinas de ambas tarjetas. Para ello monté otro Scythe de 12 cm justo delante de la salida de las GPUs 2 y 4 auxiliado por otro ventilador de 12 cm en la salida frontal.

DSCF2300El panel divisor de flujo en su posición final con los flujos de aire identificados.

El resultado es excelente pues no se aprecia incremento alguno (cero ºC) en ninguna temperatura interna (disco duro, placa base,…) cuando las cuatro GPUs con sus se ponen a trabajar al 100% indicando que todo el calor producido por ellas sale antes de calentar ningún componente o el chasis.

DSCF2377La configuración final.

De hecho, todos los paneles de la torre aparecen fríos al tacto en carga 100%, no así los dos chorros de aire que emergen de la parte trasera del sistema que con unos 60ºC hacen imposible mantener mucho tiempo la mano en ellos.

DSCF2318 (2)

Por el panel frontal se aprecia una clara diferencia de temperatura en la salida de la Zona 1 y la Zona 2. La Zona 1 evacúa por el ventilador superior a unos 28 – 30ºC, en cambio la Zona 2 evacúa por el central con un flujo mucho más potente a unos 42ºC.

Zona 3. Disco duro, fuente de alimentación y parte inferior de placa base.

En esta zona apenas se produce consumo eléctrico, quizás 100 W en pico entre el disco duro, el ventilador frontal y las pérdidas por efecto Joule en la excelente fuente Cooler Master PRO Gold 1200.

DSCF2322

La entrada de aire se produce por el frontal gracias al ventilador de 25 cm y sale por el panel trasero y la fuente de alimentación. La fuente recibe la mayoría del aire por el panel inferior.

DSCF2376Probé el ventilador en ambas configuraciones, entrada y salida.

Con el ventilador en entrada se consiguen mejores temperaturas, eso sí, tras aislar el frontal del caudal de salida de la Zona 2.

DSCF2313La Zona 3 al completo.

Echad un vistazo a la web de mi nueva empresa, un proyecto de gran envergadura que llevo preparando hace más de un año.

Os lo recomiendo para diseño de sistemas de altas prestaciones:

ip16_texto_300px_blanco[4][2][2][2]

Allí tenéis a vuestra disposición el formulario de contacto, para consultas sobre este artículo hacedlo más abajo en la sección de comentarios.

Y mi nuevo Blog de contenido muy técnico y actualizado donde encontraréis artículos míos sobre hardware, procesadores y sistemas y también otros posts de expertos programadores e informáticos sobre otros temas de actualidad:

infromaticapremium-blog[4][2][2][2]

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes. Gracias de antemano.

El que tenga dudas o aportaciones tiene para ello la sección de comentarios, intentaré responder a todos y con la máxima claridad. Los Blogs deben de ser lugares de intercambio y agradezco vuestro feedback.

Carlos Yus Valero – informaticapremium      informaticapremium-logo-150px[3]

Intel Sandy Bridge Core i7 2600 K. Análisis X86 decoders y L0i micro op cache – ProfessionalSAT

Si vais siguiendo mis artículos, en particular este, conoceréis la nueva arquitectura de cachés que ha introducido Intel en sus nuevos procesadores Sandy Bridge. En particular, Intel ha aumentado de forma crítica el ancho de banda de las cachés L1 y L2 para alimentar correctamente a los potenciados núcleos de ejecución de enteros (INT ALU 64 bit, MMX ALU 64 bit y SSE 128 bit)  y de coma flotante (X87 FPU 64 bit, SSE 128 bit y AVX de 256 bit).

SB_uopcache2

El segundo cambio consiste en la creación de un nuevo nivel de caché de instrucciones previo a la L1i de 32 KB y 8 vías (8 ways associativity). Para ello Intel ha dotado a Sandy Bridge de una caché L0i de modesto tamaño (unas 1500 micro ops según Intel) con una tasa de aciertos efectiva sobre el 80%.

Ya traté en cierta extensión esta nueva caché L0i junto con un análisis pormenorizado de la caché L3 multibanco de 8 MB en el siguiente artículo de LowLevelHardware: Intel Core i7 2600 K. Análisis cachés L0i 6 KB y L3 unificada 8 MB – LowLevelHardware

Hay cuatro motivaciones principales para este profundo rediseño:

En primer lugar reducir el uso de los X86 decoders: y gracias a ello el consumo energético de estas gigantescas estructuras diseñadas para traducir las complejas instrucciones X86 a micro instrucciones al estilo RISC.

Como sabéis los X86 decoders tienen un gran tamaño  físico consumiendo un gran número de transistores y por ello una disipación térmica muy alta. Intel, al crear un nuevo nivel de caché de instrucciones previo al nivel 1, un nivel 0 en la práctica, se permite desactivar los decoders cuando se da un L0i hit (acierto de la micro op cache).

rmma_20110209_064736_0281Instruction cache: la L0i obtiene una increíble latencia de 2 ciclos (zona 0 – 4 KB).

Un segundo motivo es reducir la latencia media en peticiones a la caché L1i. La L0i micro op cache contiene instrucciones decodificadas, se encuentra tras los decoders y trabaja en paralelo con el resto de los pipelines de ejecución. En caso de que una secuencia de instrucciones se encuentre en la L0i (un L0i hit) Intel desactiva(obviamente según un algoritmo optimizado) la circuitería de decodificación X86 del procesador y además como beneficio obtenemos una latencia reducida como demostré en un artículo anterior.

SB_uopcache3

En tercer lugar aumentar el ancho de banda medio de fetching de instrucciones. La L1i no es capaz de transmitir 32 bytes por ciclo de modo sostenido, en cambio en caso de un L0i hit la micro op cache si lo consigue aumentando el uso de las unidades de ejecución:

SUB_rmma_20110211_124507_0187Intel Sandy Bridge SUB decode bandwidth.

SB_BranchLa micro op cache también mejora las latencias medias en caso de branch Misprediction.

Y por último reducir la longitud efectiva de los pipelines de ejecución. En caso de un L0i hit el pipeline empieza en la práctica desde la micro op cache reduciéndose en un número importante de etapas. Se consigue por ello una importante reducción en la penalización por Branch Misprediction (fallo de predicción de branches) en caso de darse un L0i hit.

Resultados de los tests. Bandwidth decode:

En este artículo presento resultados experimentales que avalan los hechos que acabo de detallar y ensalzan el excelente diseño conseguido por los ingenieros de Intel en esta gama de procesadores.

Todos los análisis se han realizado en un sistema Sandy bridge Core i7 2600K con Turbo Mode desactivado para evitar incorrecciones de medida y Windows XP Professional X64 SP2 con todas las actualizaciones al día y los últimos drivers para el chipset P67. Por cierto, las pruebas se han realizado en un stepping B1 del chipset y por ello libre del infame SATA2 bug.

Para aclarar conceptos, voy a mostrar un gráfico de ancho de banda de decodificación típico en un procesador convencional (sin micro op cache) por ejemplo un Intel Nehalem:

rmma_20081120_115543_0140Decode bandwidth en Intel Nehalem.

Esta gráfica la obtuve en Noviembre de 2008 probando los primeros Intel Core i7 920 stepping C0/C1 comerciales semanas antes de salir al mercado.

Observamos cuatro zonas con valores en bytes/ciclo claramente diferenciados:

  1. Zona 1: Caché L1i de 32 KB, desde los 1 – 32 KB.
  2. Zona 2: Caché L2 unificada de 256 KB, desde los 32 a los 256 KB.
  3. Zona 3: Caché L3 compartida de 8 MB, desde los 256 KB a los 8 MB.
  4. Zona 4: Memoria RAM, de los 8 MB en adelante. Tened en cuenta que entonces probé el sistema con un dual channel DDR3 1333 (no tenía a mi alcance 3 DIMM DDR3 con voltaje de sólo 1.65V).

Ahora veamos los resultados típicos de un core Sandy Bridge:

SUB_rmma_20110211_124507_0187

Observamos cinco zonas con valores en bytes/ciclo claramente diferenciados:

  1. Zona 1. Caché L0i micro op cache. En este caso su tamaño efectivo es de unos 2 KB. Es una caché inclusiva como es tradición en los diseños de Intel.
  2. Zona 2: Caché L1i de 32 KB, desde los 2 – 32 KB.
  3. Zona 3: Caché L2 unificada de 256 KB, desde los 32 a los 256 KB.
  4. Zona 4: Caché L3 compartida de 8 MB, desde los 256 KB a los 8 MB.
  5. Zona 5: Memoria RAM, de los 8 MB en adelante.

En primer lugar debo decir que he observado varias peculiaridades en el funcionamiento de este nuevo nivel de caché:

  • No todos los tipos de instrucciones son aparentemente cacheadas en la micro op cache. Por ejemplo, algunas instrucciones como Test son decodificadas cada vez que son encontradas en el flujo de instrucciones y las mediciones indican que son enviadas desde la L1i como en diseños anteriores:

TEST_rmma_20110211_124829_0953Intel Sandy Bridge: Test decode bandwidth.

Observamos que no hay ningún incremento de velocidad de decodificación en la zona de 1 – 6 KB, la micro op caché no cachea estas instrucciones.

  • En cambio, en otros casos muestra una asombrosa eficacia multiplicando por más de 2 los resultados en ancho de banda de la L1i:

PrefixedCPM1_rmma_20110211_125524_0437Intel Sandy Bridge: Prefixed CMP decode bandwidth.

Si os fijáis, el tamaño efectivo medido en estos tests sitúa a la L0i sobre los 2 – 2.5 KB. En otros tests en cambio podemos llegar hasta los 6 KB, que es el tamaño “publicitado” por Intel:

PrefixedCMP4_rmma_20110211_125938_0078Intel Sandy Bridge: Prefixed CMP4 decode bandwidth.

Con instrucciones ALU Prefixed CMP4 llegamos hasta un tamaño efectivo para la micro op cache de unos 6 – 7 KB.

Conclusiones:

El diseño de un procesador actual comprende numerosos equipos diferentes trabajando en aspectos separados del diseño final. El arquitecto jefe diseña el plan general y los objetivos que debe de cumplir el nuevo producto.

Uno de los factores limitantes para el diseño de cada unidad del procesador es la superficie que ocupa. A cada una unidad se le asignan unos milímetros cuadrados (o fracciones de mm2) e incluso una morfología determinada por necesidades espaciales de unidades adyacentes.

Otra limitación reside en el consumo en reposo (idle) conocido como leakage (filtrado de corriente con los transistores en off) y en carga típica (TDP) y máxima de cada unidad del diseño. También ahí se imponen graves y rígidas restricciones.

Este último factor ha motivado la inclusión de Register Files y también de la micro op caché en Sandy Bridge, ambos persiguen un solo objetivo: una importante reducción del consumo. Todo ello motivado por la inclusión en el die de la GPU integrada, el hardware de coding – decoding de video y las nuevas unidades de proceso FPU de 256 bit AVX.

Si te gusta la cosmología o la astronomía echa un vistazo a mi artículo sobre Estructura a gran escala del universo en IdeasYCiencia.

Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes.

Carlos Yus Valero – informaticapremium      informaticapremium-logo-150px[3]