Michael Larabel escribió: 

AMD FX-8150 Bulldozer On Ubuntu Linux
Published on October 24, 2011


Two weeks ago AMD introduced the Bulldozer FX-Series CPUs to much excitement, although many were letdown by the initial results, and it was months after showing the first Linux benchmarks of an AMD Dual-Interlagos pre-production system. In the days that followed I delivered some initial AMD FX-4100 Linux benchmarks when securing remote access to a low-end Bulldozer system running Ubuntu 11.04 (and there were also some Linux benchmarks from independent Phoronix readers), but then last week a Bulldozer kit arrived from AMD. The centerpiece of this kit is an eight-core AMD FX-8150 CPU, which is now being used to conduct a plethora of AMD Bulldozer benchmarks on Linux.

n this first proper round of AMD FX-8150 Linux testing, the performance of the octal-core Bulldozer is being compared to the remote results of the AMD FX-4100 system and then the other hardware that was used for comparison (namely Intel's Sandy Bridge) and other test hardware at Phoronix. Among the other tests that are still being carried out at Phoronix with the FX-8150, which will be published in the coming days, include:

- A comparison of the FX-8150 with the following compilers: GCC 4.6, GCC 4.7 (a development snapshot from mid-October), LLVM/Clang 3.0, and Open64. AMD's Bulldozer optimizations are also tested in this compiler comparison (the "bdver1" march/mtune flags) on supported compilers.

- A second Bulldozer compiler-focused article looking specifically at compiler tuning with AMD's Open64 compiler release and testing out various multi-threaded compiler optimizations provided by this GCC alternative.

- Looking at the Bulldozer core/module scaling performance when running an onslaught of CPU-intensive multi-threaded Linux benchmarks with 1/2/4/6/8 threads exposed to the system. Those results then normalized and compared against Intel Sandy Bridge, Intel Gulftown, and AMD Shanghai systems.

- Testing the yet-to-be-merged "AMD: Correct F15h IC aliasing issue" patch for the Linux kernel that is meant to potentially improve the Linux kernel performance for Bulldozer processors. The Linux 3.0 kernel performance is also compared to Linux 3.1 to see if there are any differences with the FX-8150.

- An analysis of the CPU power consumption, overall system power consumption, and CPU thermal performance while benchmarking AMD Turbo CORE technology under Ubuntu Linux.

- A look at the new AMD FX-Series water cooling system (a re-branded Asetek product) for Bulldozer hardware and overclocking performance of the FX-8150. The power consumption will also be looked at in this article.

- A look at the Linux KVM hardware virtualization performance on the FX-8150.

..

Michael Larabel escribió: 

Multi-Core Scaling Performance Of AMD's Bulldozer

here has been a lot of discussion in the past two weeks concerning AMD's new FX-Series processors and the Bulldozer architecture. In particular, with the Bulldozer architecture consisting of "modules" in which each has two x86 engines, but share much of the rest of the processing pipeline with their sibling engine; as such, the AMD FX-8150 eight-core CPU only has four modules. In this article is a look at how well the Bulldozer multi-core performance scales when toggling these different modules. The multi-core scaling performance is compared to AMD's Shanghai, Intel's Gulftown and Sandy Bridge processors.

..

In the Linux benchmarks of the AMD FX-8150 that were published this past Monday on Phoronix, the multi-core performance of the eight-core Bulldozer was shown to be comparable to that of Intel's Sandy Bridge (Core i5 2500K) and Gulftown (Core i7 970, Core i7 990X) CPUs in some of the workloads. Today's results are a new set of numbers when running the very multi-threaded-friendly Linux benchmarks and controlling the number of modules/cores that are enabled.

..

The AMD FX-8150 (Bulldozer), dual AMD Opteron 2384 (Shanghai), Intel Core i5 2500K (Sandy Bridge), Intel Core i7 2630QM (Sandy Bridge), and Intel Core i7 990X (Gulftown) CPUs were used for these multi-core scaling tests. Each processor was tested with 1/2/4/6/8/12 threads enabled, up to the maximum number of logical cores offered by each processor.

All systems were running Ubuntu 11.10 64-bit for this testing with a near-final Linux 3.1 kernel that did contain the IC aliasing patch from AMD that's specific to the Family 15h (Bulldozer) CPUs. The hardware configurations remain pretty much the same as the results from Monday. As always, this testing was all facilitated by the Phoronix Test Suite so it was fully automated and reproducible. You can run a similar test yourself and compare the results directly to the numbers in this article by running phoronix-test-suite benchmark 1110227-AR-AMDSCAL0184. With the numbers on OpenBenchmarking.org, the results from all of these processors were normalized.

Luis Felipe Castillo escribió: 

El primer Bulldozer: AMD FX-8150 Black Edition, Zambezi

Apartado Técnico: David Sarmiento Portocarrero
Edición, pruebas y publicación: Luis Felipe Castillo

 

 

Bulldozer ya está aquí y con él AMD estrena su nueva arquitectura cargada de nuevas tecnologías que la ponen a la par con los actuales microprocesadores de Intel, en cuanto a su compatibilidad con los modernos conjuntos de instrucciones añadidos a la arquitectura x86 en los últimos años: SSE4.1, SSE4.2, AVX, y AMD no desperdicia la oportunidad de ofrecer 2 nuevos tipos de instrucciones aún no implementadas por su rival: FMA4 y XOP; pero sus más comentadas y menos comprendidas novedades la tenemos en su diseño interno, con su (valga la redundancia) “novedoso” diseño modular, concepto nunca visto anteriormente en otro microprocesador, y que desconcierta a muchos usuarios.

Bulldozer es muy distinto a otros microprocesadores multi-núcleo existentes, pues está conformado por hasta 4 módulos, dichos módulos están basados en el procesamiento CMT (Cluster Multi Threading), el cual es la respuesta de AMD a la tecnología SMT (Simultaneous Multi Threading) de Intel, la que promociona con el nombre comercial de HyperTreading. Para entender lo que es un módulo tendremos que realizar una breve y muy simplificada descripción de ambas tecnologías; y de lo que conocemos por núcleo.

¿Qué es un núcleo?
Lo que actualmente conocemos como núcleo (refiriéndonos exclusivamente a la arquitectura x86) es un conjunto de unidades de cálculo entre las que tenemos la unidad aritmética-lógica (ALU), la unidad de punto flotante (FPU), la unidad de generación de direcciones (AGU), los registros de hardware (de propósito general, de control, y los registros renombrables o “alias”), las unidades de ejecución, decodificador x86, caches (L1, L2 y L3); la unidad de predicción de saltos condicionales, entre muchas otras, las que trabajando en conjunto permiten la ejecución de una amplia variedad de operaciones matemáticas y lógicas de diversa complejidad, usadas por la extensa gama de aplicaciones x86 existentes. Los actuales microprocesadores usan varios de estos núcleos trabajando en conjunto repartiéndose la carga de trabajo para ofrecer un mejor desempeño en las tareas de uso cotidiano.

Tecnología SMT (Simultaneous Multi Threading)
Esta tecnología persigue maximizar el rendimiento por núcleo del microprocesador, aprovechando los por así llamarlos “ciclos ociosos” (más adelante veremos un ejemplo sobre ello) que se dan durante la ejecución de los cálculos que realiza el microprocesador, situación que se da más seguido de lo que se piensa. Para implementarla Intel duplicó muchas de las unidades de hardware presentes en sus microprocesadores, entre las que tenemos: registros de propósito general (Adder, Address, Counter, Index, Stack, String), registros de control (Instruction Flag, Interrupt Mask, Memory Management Unit, Status), y registros “alias”, y compartiendo otros como los recursos de ejecución principal, ALU, AGU, FPU, entre otros; el hardware duplicado según Intel representa un incremento de entre un 5 a 10% en el número de transistores del microprocesador, pero que a su vez le permiten ejecutar 2 hilos de procesamiento por núcleo; es decir un núcleo actuando como 2 de ellos. Esto permitió que Intel pudiera generar un núcleo “virtual” o “lógico” adicional en cada uno de sus núcleos.

Por ejemplo aunque un microprocesador Core i7 2600 posee 4 núcleos físicos, la tecnología HyperThreading permite “engañar” al sistema operativo para que muestre 8 núcleos al usuario, y que funcionen como tales bajo ciertas condiciones. Como toda tecnología HyperThreading no es perfecta, y tiene la desventaja de no poder ejecutar 2 instrucciones que usen los mismos recursos de hardware del núcleo; pero aun así ofrece en la mayoría de casos un incremento al performance de entre un 10% a un 70% siempre y cuando se den las condiciones adecuadas.

Tecnología CMT (Cluster Multi Threading)
La tecnología CMT persigue los mismos objetivos que HyperThreading: incrementar el desempeño, permitiendo la ejecución de más instrucciones por núcleo. Su implementación es muy similar a SMT, duplicando muchos registros de hardware y compartiendo otros, pero con CMT AMD lleva las cosas un poco más allá al duplicar también la unidad aritmética-lógica (ALU) dotándola con su propio cache L1 de datos (el L1 de instrucciones está presente en el módulo y se comparte entre ambas ALUs); con ello al igual que con HyperThreading se consigue ejecutar 2 hilos de procesamiento por núcleo; aunque si consideramos a los 2 núcleos generados por HyperThreading como “núcleos virtuales”; podríamos llamar a los del módulo Bulldozer “núcleos virtuales con ALUs físicas”.

Según AMD el ALU adicional ocupa un 15% más de transistores en comparación con un núcleo tradicional, pero ello no quiere decir que no se requiera un mayor número de transistores para los recursos de hardware duplicados ni para la circuitería encargada de la compartición de sus unidades. CMT, al igual que SMT, también posee algunas desventajas, y en este caso su desventaja es que únicamente es capaz de ejecutar 1 instrucción AVX de 256 bits por ciclo, además de que al igual que HyperThreading desperdicia algunos ciclos al “decidir” cuando repartir o dedicar los recursos a 1 o más hilos de ejecución; aunque según AMD esto el impacto de ello en el rendimiento es mínimo.

AMD cree que la mayor parte de las aplicaciones x86 usan procesamiento de enteros (ALU), y que son pocas las veces que se usa el procesamiento de punto flotante (FPU); y esta fue la premisa en la que basaron el desarrollo de su arquitectura Bulldozer, y el motivo por el que se decidieron a implementar el procesamiento CMT en vez de continuar con la carrera por el mayor número de núcleos como lo venían haciendo con sus actuales Phenom II X6.

Quizá todo lo anterior sea más fácil (o difícil) de entender resumiéndolo a una tabla comparativa, donde incluimos también algunos microprocesadores que carecen de ambas tecnologías (ni SMT ni CMT):



CMT y SMT: Funcionamiento
A partir de este momento lamentablemente tendremos que recurrir a la odiada por muchos matemática para ilustrar de cierta forma como se comportan ambas tecnologías en situaciones reales. Como describimos anteriormente la unidad aritmético-lógica (ALU) es capaz únicamente de realizar cálculos de enteros con operaciones matemáticas básicas como la suma y resta, además es también la encargada de realizar operaciones lógicas como “si”, “no”, “y”, “entonces” entre otras. Por su parte la unidad de punto flotante (FPU) es la encargada de realizar cálculos matemáticos complejos como multiplicaciones, o cálculos trigonométricos, a números gigantescos o muy pequeños.

Para efectos didácticos, hipotéticamente daremos a la ALU la capacidad de realizar sumas y restas, y a la FPU la capacidad de realizar multiplicaciones y divisiones (obviaremos el uso de cifras enormes); cada operación representará los recursos usados por un núcleo: ALU (+-) y FPU (*/), donde en un núcleo tradicional podría realizar una suma o una resta (pero no ambas a la vez), ejecutando en simultáneo una multiplicación o una división (pero no ambas a la vez), siempre y cuando no exista dependencia. Iniciamos este ejemplo con 7 muy sencillas operaciones de sumas, restas, multiplicaciones, y divisiones; cada una de las cuales con un color distinto para su fácil identificación (resultado incluido, no se preocupen por calcularlas):

Hemos elaborado unas tablas muy simplificadas de como un núcleo resolvería las 7 operaciones propuestas, las que como se aprecia muchas de ellas no pueden ser calculadas independientemente de las otras, pues dependen de la resolución de otras para poder calcularse, a los estados donde la ALU o la FPU se quedan sin hacer nada esperando la solución de una operación dependiente de otra se le conoce como “ciclo ocioso” (representado por los cuadros sin datos en las tablas); en el ejemplo propuesto a un núcleo tradicional con las limitaciones hipotéticas expuestas le llevaría 15 ciclos resolver estas 7 operaciones; claro que esto es de modo simplificado, pues en realidad resolver estas operaciones requeriría muchos más ciclos pues hay que “leer” los datos, almacenarlos, dividir estas operaciones en micro-operaciones, decidir el orden cada una de las micro-operaciones a procesar, entre otros muchos pasos que escaparían a lo que queremos transmitir.




Vemos que la tecnología SMT (HyperThreading) consigue recortar a 13 los ciclos necesarios para completar la resolución de las 7 operaciones, lo que en términos de eficiencia sería un incremento al rendimiento del 13.3%, pues aprovecha los recursos adicionales no usados (suma, resta, multiplicación, división) para ejecutar un nuevo hilo de ejecución, logrando vencer la limitación propuesta de no poder “sumar y restar” o “multiplicar y dividir” en simultáneo; pero debido a que no es capaz de ejecutar 2 hilos que compartan los mismos recursos, en este ejemplo no puede realizar 2 sumas en simultáneo, ni 2 restas en simultáneo, y lo mismo se aplica a las multiplicaciones y divisiones.

Por otro lado un núcleo Bulldozer (CMT) al poseer una unidad ALU dedicada resuelve algunas de las limitaciones de SMT, pudiendo (siempre ciñéndonos a este ejemplo propuesto) realizar 2 operaciones idénticas en el 2º hilo de procesamiento, logrando con ello reducir a 10 el número de ciclos empleados para resolver las 7 operaciones (una eficiencia del 33.3%), comportándose de forma muy similar a como lo haría un 2º núcleo verdadero pero sin llegar a serlo.

Sin proponérnoslo este ejemplo de cierta forma ilustra la relativa complejidad del multiproceso, y aunque debido a que usamos tan sólo 7 operaciones no se alcanzó una eficiencia muy alta, la que debería incrementarse considerablemente con los millones de cálculos que realiza comúnmente un microprocesador.

CMT y Windows XP, Vista y 7
Si bien en teoría CMT suena bien, es un diseño tan nuevo que para aprovecharlo del todo se requieren sistemas operativos más modernos como Windows 8; pues Windows 7 simplemente no soporta completamente CMT; antes de proseguir, les dejamos un gráfico con la distribución de los núcleos, sean estos “reales” o generados por las tecnologías SMT/CMT:



El scheduler (administrador de ejecución de hilos) de Windows 7 (y anteriores) está completamente optimizado para sacarle partido a SMT, tecnología vigente desde hace 9 años, a la que le saca el máximo partido ubicando primero los hilos más demandantes en los núcleos “reales” para obtener el máximo desempeño, y activando el uso de los núcleos “virtuales” únicamente para cuando se requiera un alto número de hilos de procesamiento; aunque activarlos tiene un precio pues el rendimiento por núcleo disminuye ligeramente; hecho que se compensa con el mayor rendimiento proporcionado por el mayor número de cálculos simultáneos que es posible realizar. Además las tecnologías de ahorro de energía y Turbo Boost están diseñadas para maximizar el rendimiento y el consumo, desactivando dinámicamente los núcleos virtuales no usados (sin carga) y elevando la frecuencia del núcleo con la mayor carga en operaciones mono-hilo (Turbo Boost One Core); mientras que en aplicaciones multi-hilo intensivas (más de 4 hilos) se eleva ligeramente la frecuencia (Turbo Boost All Cores).

AMD con CMT tiene planes muy distintos; pues prioriza un mejor balance entre el rendimiento y el consumo; Bulldozer en tareas mono-hilo trata de apagar todos los módulos inactivos, e ir encendiéndolos paulatina y ordenadamente según se requieran más hilos de procesamiento a fin de ahorrar energía; su tecnología Turbo Core está diseñada con este funcionamiento en mente aplicando el modo Turbo Core Max para aplicaciones mono-hilo o doble-hilo intensivas, y el modo Turbo Core All Cores cuando se usan muchos hilos de procesamiento.

Lamentablemente Windows 7, al no estar preparado para este esquema de asignación de hilos simplemente lo ignora y lo hace a “su propia manera” ocasionando que los 8 núcleos ALU estén activos todo el tiempo (activar CMT tiene un impacto negativo al rendimiento por núcleo al igual que SMT) inutilizando muchas de las funciones de ahorro de energía e imposibilitando que se pueda usar el modo CPU Max Turbo en tareas mono-hilo intensivas. Hemos elaborado un gráfico para ilustrar el desperdicio de energía y performance en Bulldozer originados por la falta de soporte bajo Windows 7:



Windows 8 (y los sistemas operativos basados en Linux con los parches CMT) al ser un sistema operativo más moderno posee soporte completo para CMT, mostrando un rendimiento general aproximadamente 10% superior y un consumo inferior. Aún se desconoce si AMD o Microsoft lanzarán algún parche, controlador, o utilidad que logre hacer que Windows 7 pueda aprovechar completamente todas las características de Bulldozer. Aquí un gráfico mostrando el correcto uso de CMT bajo Windows 8:



..

leonardo escribió: 

Una observacion sobre el empleo de CTM no es primer microprocesador usa la filosofia de hecho es de Sun/Oracle con el microprocesador Ultraspaac T1 y ahora el Sparc T4 (8 cores con 64 hilos) que tanto los de Oracle presentaron sus servidores de High End , en areas de systems for mission-critical computing y Application virtualization and consolidation. Donde el sistema operativo Solaris 10/11 si aprovechan el CTM, asi como otras tegnologias como encryption y virtualizacion. Se observa que el AMD Bulldozer se inspiro en esa filosofia ya que Sun antes de ser comprada por Oracle era un gran aliadado/consumidor de micros Opteron, compartion tegnologias y optimizaron algunas.

Pero ahora que Sun es de Oracle cambio de politicas, como el mismo CEO Larry Ellison lo ha dicho que los microprocesadores x86 "No nos importa si nuestro negocio basado en x86 llega a cero. No generamos ingresos con estos productos y no tenemos interés en seguir comercializando la propiedad intelectual de otros fabricantes". Esto parece que fue varios de los motivos de que ex-CEO Dirk Mayer renuncia ya que el mercado de servidores uno de los mejores aliados y que mostrara el provecho pleno de la tegnologia para el AMD Opteron era Sun, lo vemos ahora que el sistma operativo Microsoft no aprovecha.

Otro error que veo de este micro es el uso del viejo chipset serie AMD 900, en comparacion a los de llano y bobcat tiene la chipset mas moderno e integrado todo en uno como los de Intel en su chipset P67. Como sabian de los errores algunos ejecutivos renunciaron o mejor se fueron de AMD dejando la gerencia de AMD casi sin un liderezgo y toma de deciciones aplazado. Dando como resultado como lo vemos ahora en AMD los cambio de fechas y la informacion confusa para lanzar sus productos. El unico division que no tiene problemas es la divison de graficas heredado de Ati, que ahora son los que controlan AMD.

Citar:

AMD Bulldozer: ¿Por qué su rendimiento no fue el esperado?


Hace apenas 2 semanas que AMD lanzó al mercado sus esperados microprocesadores AMD FX, conocidos por su nombre código Zambezi, y los primeros basados en la nueva arquitectura Bulldozer de AMD; los que en un review mostraron un rendimiento comparable al Core i7 2600K de Intel en aplicaciones de retoque fotográfico con filtros intensivos, trazado de rayos (raytracing), render de video, y otras aplicaciones profesionales que hacen uso intensivo de cuantos hilos de procesamiento posea el equipo; pero que sin embargo no lucieron tan bien en las pruebas con juegos


Ya se habla detalladamente sobre el diseño modular de la arquitectura Bulldozer, y de su arquitectura CMT, responsable de compartir de recursos entre los 2 núcleos ALU presentes en cada uno de sus módulos; pero no se tocóto otros aspectos del chip que son los causantes de que el punto fuerte de Bulldozer sean las aplicaciones multi-hilo intensivas y no las aplicaciones comunes usadas típicamente por el usuario promedio.

Bulldozer por dentro

Según Ars Technica, los planes originales de AMD tenían contemplado el lanzamiento de un chip tope de gama con una frecuencia base de 4.4GHz, y que gracias a su modo Turbo llegara a una frecuencia de 5GHz; pero ello no le fue posible por temas de consumo lo que la obligó a reducir sus frecuencias objetivo y sus proyecciones. Para lograr un chip que llegue a tan elevadas frecuencias de funcionamiento lamentablemente se requiere incrementar las etapas del pipeline, y con Bulldozer AMD las incrementó sensiblemente (20 aproximadamente) en comparación con su anterior arquitectura K10.5 usada en sus Phenom II (pipeline de 12 etapas). Alimentar las tuberías de un chip con un alto número de etapas requiere el uso de grandes caches, y Bulldozer tiene muchos de sus transistores dedicados a sus caches, los que si bien crecieron en tamaño (L2 y L3), incrementaron sensiblemente sus latencias, factor que afectó también a su controlador de memoria.

Si bien cada módulo Bulldozer incluye 4 decoders x86 (K10.5 incluye 3) el número de schedulers de enteros se reduce a 1 por ALU, pero al cada scheduler estar presente en la unidad ALU, no es posible usar 2 de ellos en un único hilo (para efectos comparativos K10.5 posee 3 schedulers). Esto nos resulta en que un módulo Bulldozer es capaz de ejecutar 2 operaciones de enteros simultáneamente, mientras que K10.5 puede ejecutar 3; detalle que es compensado con su mayor número de decoders x86. AMD piensa que las aplicaciones mostrarán un mayor rendimiento al procesar varios hilos de procesamiento dentro de un mismo módulo compartiendo sus L1 y L2, pues el hacer ello ahorra la latencia adicional que se daría al acceder a la L2 de otro de los módulos, o peor aún recurrir a la L3; característica que aún no ha sido posible comprobar bajo Windows 7.

Quizá el área en la que Bulldozer prometía un mayor rendimiento: su unidad de punto flotante FlexFP, la responsable de su extendido soporte a los modernos juegos de instrucciones, si bien en concepto suena impresionante por su gran flexibilidad al dividir su trabajo entre 2 hilos de procesamiento; en la práctica obedece a la nueva visión de AMD, donde el GPU será el encargado de realizar los cálculos de coma flotante, y siguiendo dicha visión usa 2 unidades FMAC de 128 bits, las que usadas en conjunto son capaces de ejecutar instrucciones AVX de 256 bits; pero una de ellas realiza el trabajo combinado de ejecutar instrucciones x87 y MMX, mientras que la otra se dedica a ejecutar instrucciones SSE y AVX. Para efectos comparativos otros CPUs poseen 3 unidades de punto flotante dedicadas a x87, MMX, y SSE/AVX, es decir mayor fuerza bruta. Debido a ello hemos apreciado que el rendimiento de test sintéticos como SuperPi, no resulta muy bueno; pues AMD espera que su rendimiento en aplicaciones SSE y AVX compense ello terminando por ofrecer un rendimiento mayor que el de su predecesor.


¿Windows 8 ofrecerá un rendimiento muy superior con Bulldozer?

Windows 7 no reconoce bien la arquitectura CMT y desaprovecha parte del potencial de Bulldozer, y origina un consumo mayor al tener activos todos los módulos innecesariamente, quedando sólo el throttle de frecuencias como su único método de ahorro de energía. Tomando como ejemplo al FX-8150 (3.6GHz), Windows 7 es capaz de usar el modo Turbo Core All Cores (3.9Ghz), pero no el modo Turbo Core Max (4.2GHz), característica que si podrá ser usada bajo el próximo Windows 8, logrando usar el modo Turbo Core Max (4.2Ghz) en los 2 primeros módulos (4 hilos de procesamiento), es decir una mejora del 7.7% en frecuencia, además Windows 8 podrá hacer uso del procesamiento CMT de la forma como AMD la ideó, tratando de procesar el mayor número de hilos dentro del propio módulo; brindando según AMD un rendimiento hasta 10% superior en las aplicaciones que usen pocos hilos de procesamiento (4 o menos); y quizá algunas pocas ganancias en aplicaciones que usen más de 4 hilos. Pero definitivamente ningún cambio drástico al rendimiento.

Bulldozer: ¿Un gran diseño lanzado en el momento equivocado?

La arquitectura Bulldozer es sin dudas una de las más interesantes e innovadoras en el mundo x86; pero quizá su enfoque no se adapta mucho al usuario promedio que usa pocas aplicaciones simultáneamente, y juegos que en su mayoría apenas hacen uso de más de 2 hilos de procesamiento; siendo en la actualidad Dirt3 (EGO 2 engine) y Battlefield 3 (Frostbite 2 engine), los únicos juegos que hacen uso de múltiples hilos de procesamiento que demuestran el potencial de Bulldozer; por lo que no cabe dudas de que considerando que muchos de los nuevos motores gráficos usaran muchos núcleos para procesar muchos efectos como inteligencia artificial y físicas por CPU, Bulldozer es una apuesta a futuro.

Dejando el lado gamer y de los usuarios promedio, el rendimiento de Bulldozer en aplicaciones profesionales y nuevos softwares que le saquen provecho a sus nuevas características luce prometedor. Los de Ars Technica comentan sobre el mayor enfoque del microprocesador hacia tareas típicas de servidor y estación de trabajo, donde las aplicaciones se benefician de su capacidad multi-hilo, y su alejamiento del usuario promedio y gamer, pues los sistemas operativos de escritorio no se benefician mucho del multi-hilo; situación que sin dudas cambiará en el futuro, pero el tema es cuan conveniente será esperar por dicho futuro.

Por el momento Bulldozer es un chip que será visto con muy buenos ojos por los usuarios que usen ambientes multi-hilo intensivo con muchas aplicaciones demandantes funcionando simultáneamente; pero quizá no sea muy bien visto por el usuario promedio y gamer.

Citar:

AMD Bulldozer. Mi opinión personal. Parte 1

..

Este artículo es la primera parte, en el presento algunas ideas e impresiones sobre la micro arquitectura Bulldozer y algunos cambios imperativos. En sucesivos artículos iré ampliando esta discusión.

AMD Orochi 32 nm: 4 L2 de 2 MB y L2 compartida de 8 MB y 315 mm2 (!!)

Verdaderamente el equipo de marketing de AMD ha hecho un dudoso trabajo induciendo a pensar a muchos que Bulldozer iba a entrañar un salto cualitativo en prestaciones frente a sus refinados (aunque venerables, casi “antiguallas tecnológicas”) cores K10.5 de 45 nm (por ejemplo los integrados en los Phenom II X6 Thuban). En realidad no ha sido así y el déficit de Bulldozer clock for clock y core for core frente a un Phenom II X6 Thuban de 45 nm ronda el 25%.

Como expliqué en numerosas ocasiones en mis artículos pasados sobre esta micro arquitectura era probable, lógico y  a mi modo de ver seguro que Bulldozer fuese más lento clock for clock que su predecesor. Muchos me criticaron por ello pero a día de hoy los hechos son claros.

Al fin y al cabo, el procesador AMD FX Orochi de 32 nm HKMG SOI es en general más lento clock for clock y core for core que un Phenom II de 45 nm (misma frecuencia y mismo número de cores) excepto en algoritmos de compresión de datos (WinRAR, 7zip) y obviamente cuando utiliza AVX, XOP o FMA4 (los nuevos juegos de instrucciones de Bulldozer de los que carecen los cores de AMD anteriores).

Bulldozer intenta compensar con más cores y mayor frecuencia (debería haber llegado a un 30% más que Phenom II, ese era el objetivo) y modos Turbo más agresivos… Pero lamentablemente el actual estado del proceso de fabricación HKMG SOI de 32 nm de global Foundries no le ha permitido pasar de los 3.6 GHz nominales y los 4.2 GHz con Turbo y carga de 2 módulos (y los otros dos en estado CC6 IDLE).

Las cabezas pensantes de AMD soñaban con frecuencias nominales sobre los 4.2 GHz y Turbos en carga parcial de cores de hasta 5 o 5.2 GHz… era el plan de Bulldozer.

Hagamos un ejercicio de imaginación: ¿Qué habría hecho yo si fuese el encargado de la política comercial de AMD?

Habría trazado el plan que detallo a continuación a la vista de los pobres / insuficientes resultados prestacionales de los primeros stepping de Bulldozer y de la falta de escalado en frecuencia del core fabricado hoy día con el proceso de 32 nm de GloFo.

Obviamente y no nos engañemos, el staff ejecutivo de AMD conoce estos problemas hace años, fácilmente 4 años. De echo, Dirk Meyer en 2008, canceló toda la familia de CPUs Bulldozer en 45 nm y dio luz verde a Thuban 6 cores (el plan B) porque era conocedor de que habría sido un absoluto fracaso comercial (mucho pero que el actual Orochi de 32 nm).

Mi plan comercial para Bulldozer

Sigo en mi convencimiento de que mejor habría sido un simple Phenom III X8 con 8 cores reales idénticos a los de Llano 32 nm (con algunas mejoras micro arquitecturales) y 8 MB de caché L3 fabricado en 32 nm.

Sería, en mi opinión un excelente plan B, un plan seguro. Además un plan B con resultados prestacionales totalmente predecibles. Sin duda necesitaría un robusto sistema Turbo core, para cargas single threaded y parciales, pero no nos engañemos, core for core un Phenom II ya es más rápido que Bulldozer excepto en casos limitados que comento en este artículo.

El problema de Bulldozer, entre otros, es el impredecible rendimiento en el mundo real de una nueva micro arquitectura genuinamente diferente de todo lo demás y además fabricado en un proceso novedoso y poco probado hasta la fecha (Global Foundries 32 nm HKMG SOI).

En mi opinión, los primeros Bulldozer deberían haber sido retrasados (una vez más) y puestos en el mercado al final del periodo comercial del proceso de 32 nm de Global Foundries, en plena madurez. Habría esperado a Q2 o Q3 de 2012. Mientras tanto tendríamos el Phenom III X8 que fácilmente habría llegado a las estanterías 6 meses antes que Orochi.

Con ello AMD habría ganado en conocimiento del proceso de fabricación de 32 nm, habría podido optimizar el die de Bulldozer en busca de una drástica reducción de superficie (demasiado espacio muerto en Orochi 32 nm) y habría mejorado los speed path críticos consiguiendo un muy necesario aumento de frecuencia.

En este caso habrían sido CPUs con menor consumo, sin duda, tanto en reposo como en carga máxima y fácilmente estaríamos hablando de 200 – 400 MHz más de frecuencia en el speed bin superior con lo que estarían más cercanos a las expectativas puestas en ellos por el “delirante” (JF AMD y compañía) departamento de marketing de AMD.

Mientras tanto tendríamos el citado Phenom III X8, con los mismos cores que el AMD A8 para socket FM1 pero con L2 de sólo 512 KB y 8 MB de L3. Simplemente funcionarían a mayor frecuencia, con 3.4 GHz nominales para 8 cores al 100% y un modo Turbo de 4 GHz con carga 100% en 4 de los cores. Sería claramente y de lejos más veloz que Bulldozer y podríamos tenerlo en el mercado hace meses.

..

Conclusiones parciales

Estas son algunas de las consideraciones que me vienen rápidamente al ver el actual diseño de Orochi, en próximos artículos apuntaré otras y me extenderé más sobre estas.

En cualquier caso, está claro que los núcleos de ejecución de Orochi no son tan malos si consiguen unas prestaciones razonables contando con un subsistema de caché con un diseño nefasto para cargas de trabajo de sobremesa, portátil o estación de trabajo.

Quizás con cargas de servidor (en versiones Opteron) de enteros para desplegar el poder de sus 16 INT cores por socket (2 dies Orochi por chip) y pueda destacar el tamaño total de caché por chip (16 MB) y responda mejor prestacionalmente.

Más en siguientes entregas…

Citar:

A quick look at Bulldozer thread scheduling
Is it really best to share?
by Scott Wasson — 5:32 PM on October 27, 2011

As you may know if you read our original FX processor review, the shared nature of the "modules" in AMD's new Bulldozer architecture presents some conundrums for OS and applications developers who want to extract the best possible performance. Each module has two integer cores that are wrapped in some shared resources, including the front-end instruction fetch and decode units, the FPU, and the L2 cache and its associated data pre-fetchers. AMD claims this level of sharing is superior to what goes on in recent Intel processors—whose more resource-rich indvidual cores can track and execute two threads—because the performance of each thread in a Bulldozer module is more "robust" and predictable, less likely to stall due to resource contention.

A scheduling conundrum
That sounds good in theory, but it raises a vexing question: what is the best way to schedule threads on a four-module, eight-core Bulldozer-based chip? Say your application uses four threads, and you want the best possible performance. Would it be better to group those four threads together on the four cores contained in a pair of Bulldozer modules, or is the best approach to spread them across all four modules? Each way has its advantages.

Your first instinct might be to spread the threads across four modules, in order to avoid resource sharing. That's generally the best approach on an Intel processor with Hyper-Threading. On Bulldozer, that means the front end, FPU, and memory subsystem in each module would be at the full disposal of a single thread.

However, AMD claims Bulldozer's sharing arrangement has a relatively small performance penalty. Also, if all four threads occupy only two modules, the CPU could potentially run at a higher clock speed thanks to Turbo Core dynamic clock frequency scaling. In the case of our FX-8150 chip, that means the cores would top out at 4.2GHz, whereas they'd stop at 3.9GHz with all four modules active. What's more, AMD claims the performance of related threads may benefit from sharing data via the module's L2 cache.

So what's the best approach? That's tough to say for sure, simply by considering the theory, and it may depend upon the situation.

One thing we do know is that the scheduler in Windows 7 isn't any help. The OS is completely unaware of how Bulldozer modules work; it sees only eight equal cores and schedules threads on them evenly. AMD says Windows 8 will address these issues, but outside of developer previews and such, that OS probably won't be available for another year, at least.

We can, however, take charge of thread scheduling ourselves in certain cases and see how it affects performance. With the aid of some simple tools, we tested a few of the geekier applications used in our Bulldozer review using explicit thread scheduling in order to see what would happen.

Our basic setup is relatively straightforward. Some of our benchmarks run from the command line and can be configured to use a specific number of threads. We told them to use four threads and invoked them via the Windows "start" command, which has an option to set the thread affinity when launching a program. By modifying the affinity, we can distribute the threads to specific CPU cores. For instance, this command:

    start /AFFINITY 55 /b /WAIT e3dbm 5 4 > ed3dbm-4-1.txt

...launches our Euler3D computational fluid dynamics test, tells it to run five iterations with four threads, and stores the output in a text file. The "55" after the "/AFFINITY" switch is the mask that specifies which cores to use. The mask format may seem hard to decipher because it's in hexadecimal; translated into binary, two instances of the number five side by side look like so:

    01010101

A one specifies a core to be used, and a zero specifies a core to be skipped. In this case, the mask tells the OS scheduler to assign threads to every other core—or one per module, in the case of Bulldozer.



We were able to verify that the "55" mask was doing what we expected by watching the Windows Task Manager and monitoring CPU clock frequencies. As you can see in the screenshot above, we have a thread on every other core, and our CPU is topping out at 3.9GHz, which is the expected Turbo Core behavior when all four modules are active. We also verified the core and module configuration with AMD, who characterized it as:

    Module 0 = Core 0 and 1, Module 1 = Core 2 and 3, Module 2 = Core 4 and 5, Module 3 = Core 6 and 7

So we're fairly certain we know what we're getting here.



Our other mask option, 0F, translates into binary as "00001111". This option packs all four threads onto two modules, forcing some resource sharing but also allowing for the higher Turbo clock frequency of 4.2GHz. Again, the behavior is easily verifiable, as shown above.

In addition to our command line specifications, we have some special, affinitized builds of the picCOLOR image analysis program, courtesy of Dr. Reinert Mueller, who has long supported us with custom builds of his software tailored for new CPU architectures. Several of picCOLOR's functions use two or four threads, and their performance is potentially altered by where they run.

The results

Without further ado, here's what happened when we ran our test apps with the default Windows 7 scheduler threading—i.e., with no awareness of modules or sharing—and with our two different affinity masks.

The results
Without further ado, here's what happened when we ran our test apps with the default Windows 7 scheduler threading—i.e., with no awareness of modules or sharing—and with our two different affinity masks.



These results couldn't be much more definitive. In every case but one, distributing the threads one per module, and thus avoiding sharing, produces roughly 10-20% higher performance than packing the threads together on two modules. (And that one case, the FDom function in picCOLOR, shows little difference between the three affinity options.) At least for this handful of workloads, the benefits of avoiding resource sharing between two cores on a module are pretty tangible. Even though the packed config enables a higher Turbo Core frequency of 4.2GHz, the shared config is faster.

Our test apps, obviously, are not your typical desktop applications, and they may not be a perfect indicator of what to expect elsewhere. However, since many games and other apps are lightly threaded, with three or four threads handling the bulk of the work, we wouldn't be surprised if one-per-module thread affinities were generally a win on Bulldozer-based processors.

Naturally, some folks who have been disappointed with Bulldozer performance to date may find solace in this outcome. With proper scheduling, as may come in Windows 8, future AMD processors derived from this architecture may be able to perform more competitively. Unfortunately, Windows 8 probably won't ship during the model run of the current FX processors.

At the same time, these results take some of the air out of AMD's rhetoric about the pitfalls of Intel's Hyper-threading scheme. The truth is that both major x86 CPU makers now offer flagship desktop CPU architectures with a measure of resource sharing between threads, and proper scheduling is needed in order to extract the best performance from them both. (This situation mirrors what's happened in 2P servers in recent years, where applictions must be NUMA-aware on current x86 systems in order to achieve optimal throughput.) A gain of up to 20% on a CPU this quick is certainly worthy of note.

Trouble is, right now, Intel has much better OS and application support for Hyper-Threading than AMD does for Bulldozer. In fact, we're a little surprised AMD hasn't attempted to piggyback on Intel's Hyper-Threading infrastructure by making Bulldozer processors present themselves to the OS as four physical cores with eight logical threads. One would think that might be a nice BIOS menu option, at least. (Hmm. Mobo makers, are you listening?)

At any rate, application developers who want to make the most of Bulldozer are free to affinitize threads in upcoming revisions of their software packages anytime. If AMD can persuade some key developers to help out, it's possible the next round of desktop applications could benefit very soon