Salu2

La ganancia, en términos generales, no es abrumadora, aunque en tratamiento de video, renderizado y tareas multimedia es muy pronunciada.

En juegos no, jeje, y como comenta el autor se debe en gran parte al recorte de caché L2, 256KB por núcleo, a diferencia de la anterior 6MB para cada 2 núcleos. Más rápida, eso sí, pero mucho menor, teniendo que usar la L3 o la memoria RAM.

Tiene razón el autor cuando dice que parece un micro más diseñado para servidores, tengo la misma impresión.

http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3448&p=8

Parece que los beneficios son obvios, aunque no precisamente para los juegos.

La explicación como ya dije es breve sin etrar en detalles, pero si los quieres:

El P4 no tiene 3 cauces de ejecución propiamente dicho, tiene 1 que es el pipeline de 20 etapas en los northwood y 31 en los Prescott y Cedar Mill, que se puede dividir en 3 partes.

La arquitectura (o microarquitectura) de la que hablamos es la NetBurst, y el HT lo que hace en realidad es rellenar el pipe si hay posibilidad de ello, con lo que se agiliza la ejecución eliminando momentos en blanco como bien dices.

La mejora de rendimiento era evidente con los micros de 20 etapas, aunque no en todos los escenarios ni tanto como Intel decía, y bastante menos en los de 31 etapas, ya que lógicamente al aumentar tanto el pipe el rendimiento por ciclo de reloj era menor que el de sus hermanos de 20, hecho que se maquilló aumentando la frecuencia (mhz), pero como se veía venir tenía un límite (impuesto por la cantidad brutal de calor para la poca frecuencia aumentada, no era un aumento lineal).

Estoy totalmente de acuerdo contigo en que el balón está en el tejado del Software, pero creo que Intel trabajará (o pagará directamente) para que se haga uso de ello.

El P4 tenía 3 cauces de ejecución de instrucciones (pipelines). Un pipeline es como una “línea de montaje” de coches, donde en cada “puesto” se realiza una operación sencilla. Muchas operaciones sencillas completan una más larga.

La arquitectura HT lo que hacía era aprovechar los “puestos” que quedaban libres de cada una de las “lineas de montaje” para simular un segundo procesador, y a decir verdad es muy común que queden muchos “puestos” libres cuando se ejecuta un programa, especialmente porque a la hora de realizar operaciones de entrada/salida quedan muchos momentos en blanco.

Si bien es cierto que en determinadas aplicaciones muy muy intensivas en uso de CPU (caso de algunos juegos) donde además la aplicación no se había optimizado para ejecución paralela había una ligera pérdida de rendimiento, en general para la mayor parte de aplicaciones de propósito general o aplicaciones de uso empresarial la ganancia era importante y además a coste cero.

El retorno de esta arquitectura incorporada a procesadores multinucleo no deja de ser una buena noticia… si los compiladores están preparados para optimizar el código para hacer uso de ella, por supuesto.