Me he dado cuenta, que la mayoría de aplicaciones, no son capaces de explotar las ventajas arquitectónicas que aporta la tecnología hyperthreading disponible en los Pentium 4 de Intel.
Hyperthreading duplica algunos componentes de la ALU del procesador, de manera que a nivel lógico es como si hubiera presentes dos procesadores.
A nivel físico no hay dos CPU, pero la duplicación de hardware permite que con este truco podamos obtener mayor rendimiento que si tuviéramos solamente una CPU sin hyperthreading, y evidentemente menor que si tuviéramos dos procesadores realmente.
Por lo que he visto según el administrador de tareas de Windows, en pocos casos el uso de CPU supera el 50%, lo que indica que la mayoría de aplicaciones no están escritas para explotar la ventaja de Hyperthreading.
Sin duda me recuerda a casos como la aparición de el 386 que necesitó 5 años para que el software pudiera explotar los 32 bits, el Pentium que necesitó 2 años para que las aplicaciones empezaran a optimizarse para utilizar las instrucciones RISC, el Pentium 4 que necesitó 1 año para ser realmente más rápido que un Pentium III, …
Es una situación similar a la que vivimos con los procesadores AMD de 64 bits. Si el software no explota esas características, es como si no las tuviéramos.
Me parece especialmente grave en el caso de hyperthreading, ya que no hablamos de generar un conjunto de instrucciones totalmente diferente (que requiere cambios profundos en el generador de código del compilador), sino solamente de explotar las características multihilo de los sistemas operativos multitarea actuales diseñando la arquitectura de la aplicación de forma adecuada para ser paralelizable al máximo con diferentes hilos (CreateThread).
Como pasó cuando se comenzó a crear aplicaciones para modo protegido bajo DOS, o a explotar la arquitectura RISC del Pentium, el beneficio de los diferentes hilos de ejecución, es algo que no solamente beneficia a los procesadores con Hyperthreading. También sacan provecho aquellos con máquinas multiprocesador, y en general todos los usuarios que pueden ver como el sistema operativo explota las características de planificación de tareas de ejecución para cada thread.
Todo ello con un único coste: conocimiento. No es sencillo diseñar los procesos que pueden ejecutarse con diferentes hilos, ni mucho menos adaptar el algoritmo para que sea posible hacerlo de esta forma. Tampoco es trivial la sincronización y el acceso a zonas comunes entre los diferentes hilos. Pero sin duda vale la pena.
Por citar tan solo algunos ejemplos de aplicaciones que sorprendentemente no explotan esta característica: Flash y Dreamweaver de Macromedia; Word, Excel e Internet Explorer de Microsoft, …
Como veis, la excepción son los que si que lo emplean.
¿arquitectura RISC en Pentium? yo sabía que solo la Pentium 4 usaba esta arquitectura para principalmente usar pipeline; pero que la arquitectura predominante era CISC
Se empezaron a añadir características RISC que permitían la paralelización a través de pipelines en los tiempos del 486. El resto ha sido solamente ir mejorando las cosas.
Los procesadores x86, empezaron siendo CISC, su apogeo estuvo con el 386. Como digo, a partir del 486 se empezaron a añadir características RISC, de forma que se empezó a crear la estructura mixta que tenemos actualmente.
El Pentium 4, sería el máximo exponente actual de CISC + RISC.
Como RISC, puede ejecutar varias instrucciones simple en un ciclo de reloj. Como CISC permite usando SSE2 por ejemplo, ejecutar varias operaciones con una sola instrucción.
Ok Guti no sabía que desde las 486 se empezaron a añadir características RISC. Gracias por la aclaración
Si no te entiendo mal, dices que es más fácil aprovecharse del hyperthreading que de nuevas instrucciones porque estas últimas requieren modificaciones en el generador del compilador. Yo lo veo al revés: modificar sólo una parte del compilador es mucho más fácil que modificar todo el diseño de todas las aplicaciones.
Por otra parte, ¿en qué te basas para asegurar que, por ejemplo, Word no aprovecha el hyperthreading? Acabo de hacer una prueba lanzándolo con un documento en blanco y tiene 4 hilos. Yo creo que la corrección ortográfica está aprovechando esa característica.
Otro elemento a tener en cuenta es que el hyperthreading también se aprovecha ejecutando varias aplicaciones a la vez.
Y por último, si ves que la CPU está mucho tiempo al 50%, será porque tienes una CPU muy potente 😉
Lo que quería decir es que aprovechar el hyperthreading, depende del programador, y no se requieren modificaciones en las herramientas. Mientras que generar otro tipo de instrucciones de máquina, requiere que se modifique el backend del compilador. A nivel de uso, si el compilador soporta esas extensiones, es mucho más sencillo aprovecharlas, solo hay que recompilar.
Respecto a lo de Word, me baso a que aunque tiene varios hilos de ejecución (la mayoría de aplicaciones los tienen), esos hilos no están optimizados para procesos de alta carga de CPU. A nivel práctico podríamos decir que normalmente 3 hilos están en idle, y el cuarto es el que hace el trabajo duro. Quizás no lo expliqué demasiado bien. Si quieres haz la prueba de importar un documento grande en otro formato que no sea DOC, verás como aunque la CPU está cargada, es un hilo el que hace todo el trabajo.
Tienes toda la razón en lo que dices de que con varias aplicaciones a la vez, también aprovechamos el hyperthreading.
La CPU es un P4 a 2,8 Ghz. Potente, pero nada del otro mundo.