HP lanza sus primeras críticas contra el nuevo procesador T1 (Niagara) de Sun

17 Nov 2005 en Servidores

En la página de HP dice: El próximo procesador Niagara  de Sun marca un alejamiento de sus tradicionales diseños SPARC como los de su propio UltraSPARC y el SPARC64 de Fujitsu. La misma Sun califica a Niagara como enfoque “radical.”
Sun ha declarado que Niagara cumple con los requerimientos binarios de anteriores diseños SPARC, pero esto no nos dice toda la historia acerca de qué tan bien puede funcionar un programa binariamente compatible con SPARC sobre un procesador Niagara. No basta con funcionar, el programa debe funcionar bien para ofrecer real valor. Se requerirá una significativa optimización del software para asegurar que funcione bien sobre Niagara.
En la página de HP continúa: Antes de que se tiren por las cataratas con Niagara, consideren lo siguiente:
Primer punto: El chip Niagara de Sun está realizado con cores independientes que tienen una performance a nivel de hilo único (single thread) mucho más lenta que la de los cores de Xeon e Itanium de Intel, de AMD Opteron y hasta de los actuales procesadores SPARC. Las aplicaciones que requieren de un rendimiento elevado en modo single thread o que no funcionan bien en un entorno multi-hilo, funcionarán mejor en modelos de procesador tradicionales como Intel o AMD. El mismo CIO de Sun dijo que los clientes se desilusionarían con la performance single thread de Niagara en comparación con la de Opteron.
Segundo Punto: Se necesita más que compatibilidad binaria para que los software que ya están desarrollados funcionen bien. Sun admite que el software debe ser optimizado para aprovechar la arquitectura de Niagara. Por ejemplo, las aplicaciones Solaris/SPARC que escalan a sólo uno o dos threads y se apoyan en mejoras sobre un procesador de un core para aumentar su rendimiento, es muy posible que funcionen mucho más lento sobre Niagara si no son optimizadas.
Tercer Punto: Para explotar a full a los sistemas Niagara, los desarrolladores deberían cambiar la arquitectura de las aplicaciones. Sun ha manifestado que Niagara modifica las demandas mínimas de la escalabilidad de aplicaciones de 1 a 4 threads, llevándola a 32 threads concurrentes. Aplicaciones de servidor que funcionaban bien con sistemas entry-level que escalaban de uno a cuatro threads, pueden necesitar retoques para escalar bien a 32 threads ¿Querrán los desarrolladores rehacer la arquitectura de un programa que funciona bien sobre la mayor parte de los servidores en uso sólo para que funcionen bien en Niagara? ¿Cuántos están en condiciones de soportar otra plataforma que tiene, además, necesidades especiales?
Como epílogo, se señala que Niagara requiere de un nuevo paradigma en desarrollo de software. La compatibilidad binaria que tanto proclama Sun no cuenta la verdadera historia sobre cuándo será necesario optimizar o reestructurar aplicaciones para que funcionen bien. “Si usted es cliente de Sun, está frente a un momento de decisiones. El mapa de ruta de Sun lo lleva inexorablemente en una dirección que exige cambios.”