¡Felices fiestas a todos desde SATSoftware!
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/AVvXsEhwifhlfdA449IPP-m9RJH5R1ayBpkMk60MseGgfQjzx1P72W8KDRWMXDyPpbrKFmwWwomy1MIWCXGV-Qy1oyp03Zj43h509QLyRmNGZG9Qyny_oLNRrTaN59RSo93infIUjvdTtIFDtaA/s1600-h/SB_4C_630p_cores_thumb13.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/AVvXsEhJ-GVrwNZEiP-i8z08icu5NT_GED49vS_EXENyO87GYvYaj4HBq47_5UV1H8AbJIcyNcCJAy1AGM6KvLQBxI_V4LME1-CfsYnfsktlaVTR8QhipLuvCE-rVdhdD32kny2nEIq6dwDns1c/s1600-h/SB_uopcache_thumb13.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/AVvXsEic1-duKAud2J5QWozOXUl07aYFUWMSXEYfNGuDdyixQLVCSci-NE1KD9JmGrIAwC9mlWhKCwL6SC-xVdMV5g0XNz8-_LKyix1XCuSmHpWyClM5I1_A769Yc7o67fiKXvs_kMnCc5E-1ks/s1600-h/die_thumb13.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.
He recordado que el i7 tiene un pequeño fallo de rendimiento con el Hypertreading que se puede apañar evitando usar el modo de ahorro de energía. Aunque si dices que es por la caché de micro-código.
ResponderEliminarhttp://www.chw.net/2011/11/parking-core-bug-limita-el-rendimiento-de-los-cpu-intel-con-hyperthreading/
NostromoADF,
ResponderEliminarBuena observación, pero este "bug" no tiene nada que ver con el "core parking bug" que se da cuando Windows 7 aparca (desactiva) los cores lógicos maximizando la carga en los 4 cores físicos en software que no usa totalmente los threads disponibles o cuando algunos threads son de carga de trabajo baja.
El bug que he descubierto es distinto, se da cuando 2 threads compiten por los 1536 bytes de la micro code cache de SB y uno expulsa las instrucciones ya decodificadas del otro thread para hacer espacio a las suyas.
Como observación, decir que con un tamaño de unos 3 KB será sufieciente aunque considero óptimo 4 KB para esta L0i.
Un saludo,
Carlos Yus.