Barrapunto

... desde la ignorancia que supone no conocer el maremágnum de código del GCC, ¿no sería mejor simplemente trabajar en la optimización de código del compilador GNU de C?

Supongo que dado el tamaño y las características de cross-compiler multiarquitectura de GCC no debe ser tarea fácil, pero creo que sería mucho más beneficioso mejorar la optimización de código de GCC que no recompilar cosas con otros compiladores (a menos que compilemos TODOS los programas con ICC).

¿Cómor, es que la gente de Linux no utiliza el flag -std=c99 (o c89) para asegurarse mediante el estándar correspondiente que el código es 100% portable?

No sabía que había vida más alla de GCC para los linuxeros.
Yo que me dedico a temas de 3D, y uso un PC con linux exclusivamente para las tareas de render, escucho por segunda vez en 3 días de la existencia de éste compilador ICC, y de sus bondades, ya que el pasado sábado descubrí Lux Render, un motor de render Open Source de muy alta calidad
Como muestra, según en su web, compilar Lux Render con ICC puede conseguir un ejecutable un 40% más rápido que con GCC.
Pasen y vean: http://www.luxrender.net/wiki/index.php/Installati on_guide/url [luxrender.net]

creo que es un esfuerzo un poco mal empleado, porque hasta donde llegan mis conocimientos de compiladores, sistemas operativos y procesadores, el kernel de un sistema operativo no es que sea un código muy susceptible a ser optimizado automáticamente por el compilador, por los siguientes motivos:
- alto grado de paralelismo explícito (si es un kernel SMP), ahí el compilador no puede meter mano
- ausencia casi absoluta de operaciones de coma flotante (que es donde más partido se le puede sacar a un pipeline bien organizado)
- es código en C plagado de punteros... ahí no hay análisis estático que valga para optimizar.
- los kernels tienen un comportamiento en general reactivo, es decir, que se tiran la mayor parte del tiempo esperando interrupciones para entrar a hacer algo... me estoy acordando del chiste de aquellos que vieron que el proceso que más tiempo consumía en el sistema era el "idle process" y se pusieron a optimizarlo.

según dicen en la página consiguen en algunas partes del kernel una mejora del 40% del rendimiento y en general entre un 8% y un 10%... ahora por favor que me lo normalicen eso en tiempo total de cpu, porque si el kernel en general está ejecutando como mucho un 5% del tiempo (lo digo a ojo, no conozco el dato exacto, pero creo que por ahí andará), la mejora global es de un apabullante 0.4%.

eso por no hablar de que las optimizaciones del ICC son para procesadores Intel y no AMD, habría que tener un proyecto paralelo con el compilador de alto rendimiento de AMD para cubrir (casi) todo el espectro de usuarios domésticos.

vamos, que si lo que querían era sacar un par de papers sobre el tema, pues vale, pero si querían hacer algo útil de verdad, habrían empleado mejor su tiempo en como dicen por ahí mejorar el GCC o directamente pensar cuáles son los orígenes (algoritmia y estructuras de datos) de los posibles cuellos de botella del kernel, si es que los hay.

¿una distribución compilada entera con ICC debería volar? ¿existe alguna ya compilada, por probar?

¿Intel C++ compiler?

  ¿Acaso el núcleo Linux no está escrito en C? ¿Por qué no han usado el compilador de C de Intel en vez del de C++? Ya sé que el C++ es compatible en gran medida con código C89 escrito sin cosas antiguas del C K&R, pero si tengo un programa escrito en C, lo compilo con el compilador de C, no con el de C++. ¿Alguien puede aclarar esto?