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).

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.

¿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?

Los estándares no cubren absolutamente cada aspecto mínimo de lo que normalizan. Y el GCC incluye ciertas funcionalidades para facilitar la vida a los desarrolladores de Linux (gcc ha crecido junto con linux, de la manita), y eso hace que algunas cosas no funcionen en compiladores más limitados.

En castellano: Uso de extensiones del GCC en Linux [blogspot.com]
En inglés: GCC hacks in the Linux kernel [ibm.com]