¡Felices fiestas a todos desde LowLevelHardware!
Como es obligada tradición estos días estoy con la familia celebrando las fiestas pero desde el día 27 empiezo a sustituir 12 de mis Sistemas de Altas Prestaciones basados en CPUs Sandy Bridge Core i7 2600K @ 4.4 GHz por antiguos, venerables y probados Nehalem Core i7 930 y 950 @ 4 GHz.
![SB_4C_630p_cores_thumb[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxHfEPPX_3Pcd9yw2U9X97FNsMPfKq2oPKx5o3gB-VhPTsBOWu9AtTCAWLsfw690VS_Nx2ChFPW72sC8hK86zYsxqNcDpSwVjG-0r7sx1CD3WhHtH23ohrSHbtk-ZxSgBFCK7yLGPeznw/s1600-h/SB_4C_630p_cores_thumb%25255B1%25255D%25255B3%25255D.png "SB_4C_630p_cores_thumb[1]")
¿Extraño? Simplemente los Sandy Bridge son un 30% más lentos que los Nehalem en los cálculos matemáticos intensivos que emplea uno de mis mejores clientes… he descubierto un “defecto” en la excelentísima nueva arquitectura de Intel.
Tras semanas de testing he descubierto la causa, recordáis la caché de micro operaciones de 1500 uOps nueva en SB, pues en estos algoritmos crea un GRAVE problema prestacional.
Lo denomino “micro code cache inter thread thrashing”. Un thread expulsa de la uOp cache los datos del otro thread constantemente y hace que la velocidad de cálculo sostenida del procesador baje alarmantemente.
![SB_uopcache_thumb[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzNjfoxNBA6wJRNX9BZC6IWDaXSpAyMW47JIajkV2EPfe03laRLbrOjkp6KEG7CmZX8od0RCPkVLur_0Z3vMfBzktI665US4IQk6C6oy_SsYK32aSSR-kZGEYnJwgiyZlt4-zMhQNvofU/s1600-h/SB_uopcache_thumb%25255B1%25255D%25255B3%25255D.jpg "SB_uopcache_thumb[1]")
Un Core i7 Nehalem @ 4 GHz realiza 1000 iteraciones del cálculo con ocho threads simultáneos en 3100 s, un SB @ 4.4 GHz tarda unos absurdos 4050 s.
Es un resultado absolutamente repetible con una variación de máquina a máquina máxima de 50 s y lo he probado con 12 CPUs distintas SB y 24 Nehalem y con placas base SB P67 y Z68. Única opción: volver a los antiguos i7…
![die_thumb[1]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSMMet0vF2kA5iaTRJEUGCGUdqtJWoHxFTKDXP8lOq2njmThDu8kxh6jpBc54N3sa2ekx31dl2pVP1pCS99Lm9YXBYGc1Dij4zl5mJgPJL4uv3DtQtKOMjEj4qoR-BorKzcr7wWdMBZjo/s1600-h/die_thumb%25255B1%25255D%25255B3%25255D.png "die_thumb[1]")
Disfrutemos de estos días antes de ponernos manos a la obra… lo dicho, ¡Felices Fiestas!
Si consideras útil el contenido de este Blog, ayuda a mantenerlo ojeando algunas de las ofertas que consideres interesantes de nuestros anunciantes.
Vaya hasta los de intel se equivocan... que raro!! jeje, Felices Fiestas a toda la Family!!!:)
ResponderEliminarSaludos,
Juan Fran.
Me dejas pensando Carlos tu sabes seguramente que los Sandy E tienen distinta velocidad de cache (mas lenta) sera en respuesta a este problema?? Desde ya gracias carlos por tu tiempo y feliz año nuevo!!
ResponderEliminarCarlos, ante todo feliz año nuevo! Ojalá se te cumplan tus expectativas y puedas disfrutarlas junto a tu flia y amigos. Volviendo al tópico, podrías hacer un informe mas extenso de tu descubrimiento y publicarlo en ingles, ya que me gustaría con tu permiso poder publicarlo, valga la redundancia, en algunos blogs de informática con tu nombre y dirección de sitio, esto es algo que debe el mundo del silicio saberlo, más aun los que se dedican a utilizar científicamente los equipos de escritorio. Hay mucho fanatismo por la marca y poca investigación de fondo y mucho menor gente aun dedicada tan intensamente a la misma como tu lo haces en tus artículos publicados. Desde ya gracias por tu importantísimo vuelco de tiempo y conocimiento en la materia!
ResponderEliminarJuan Fran,
ResponderEliminarRealmente no es que en Intel se equivoquen, es más bien nuestra carga de trabajo que es muy "rara" ya que en el 95% de los algoritmos y paquetes de software Sandy Bridge es más rápido que Nehalem.
Sólo he encontrado tres excepciones importantes a esta regla (con diferencias de hasta el 40%) a favor de los antiguos Core i7 9XX:
- Software que de altas tasas de fallo de caché L3.
- Software que lee o escribe masivamente en RAM sin pasar por caché.
- Nuestros "extraños" algoritmos de cálculo FPU.
Anónimo,
No tiene nada que ver una cosa con la otra. En SB-E, la caché L3 funciona a otra frecuencia inferior pues es independiente de los cores, en SB S1155 la L3 (cada banco de 2 MB) está asociado a uno de los cores y funciona a su misma frecuencia.
El problema que tengo es con la caché L0i, la microop caché.
Secretweapon,
La verdad es que es un problema prestacional limitado. Es como si mañana diseñamos un software que exige (por su critical loop) una caché L1i de 48KB. Todas las CPUs actuales (cachés L1i de 32KB) serían lentas y ganarían en los tests los antiguos A64 con su L1i de 64KB y quizás los Bulldozer con su L1i de 64 KB para cada 2 INT cores.
El problema se debe a que las rutinas de cálculo que usamos para investigación de dinámica de fluidos en condiciones de microgravedas utilizan operaciones complejas sobre grandes matrices de datos multidimensionales. Vamos, que con 1536 uops para 2 threads no llega y da el mencionado problema de velocidad. Un 30% menos que un antiguo i7 a menor frecuencia (4.4 vs. 4.0 GHz).
Saludos,
Carlos Yus.