Barrapunto

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.

Se trata de tiempo de reacción. Un kernel ideal pasa desapercibido. Todo ese "comportamiento reactivo" que dices, es crítico para cualquier operación. Prueba a correr linux compilado para i386 y para i686 en una máquina moderna. Todo es lo mismo, lo que cambia es el kernel. ¿Por qué hay una diferencia tan notable? Muy sencillo, si una aplicación hace dos docenas de llamadas al sistema por segundo, una optimización del 40% en la respuesta de esas llamadas va a afectar sustancialmente al tiempo final de ejecución y, sobre todo, al tiempo de respuesta si se trata de una aplicación interactiva.

Yo que tu, ampliaría un poco más los conocimientos en dichas areas. Y a los que le habeis dado una puntuación alta, os recomiendo que os lo hagais mirar. Es que no sé ni por donde empezar.

En los lenguajes orientados a objetos estos no son más que tablas de datos con punteros a tablas de funciones. En el caso de la herencia y en la mayoría de las implementaciones de interfaces que ofrecen funcionalidades similares, la implementación es un puntero en el objeto a la tabla de punteros del padre. Si esta afirmación fuera cierta, sería casi indistinto usar optimización o no en lenguajes orientados a objetos. Si a lo que te refieres es que existe una naturaleza dinámica del tipo de contenido al que apuntan esos punteros, es lo mismo, porque no llamas a punteros sin tipado.

Cuando hay muchas operaciones de coma flotante lo que evitas es que a veces se produzcan parones de muchos ciclos en el pipeline. Con los procesadores con superpipeline que pueden ejecutar operaciones fuera de orden la mejora es mayor. Si mayormente son operaciones aritméticas y tienes buenos mecanismos de predicción de saltos, puedes llegar a tener un índice de ciclos por instrucción que se acerque mucho al teórico. Resultado, mucha mayor productividad de operaciones por segundo.

Obviamente es un compilador, no un generador de código, si la distribución de las tareas y asignación de recursos está mal hecha el que es incapaz es el desarrollador, no el compilador.

Haz el siguiente experimento. Crea un pequeño programita. Este programa crea tres hilos A, B y C. Y dos pipes, uno entre A y B y otro entre B y C. El programa A lee un bloque de 1Mb del disco duro, se lo pasa por el pipe a B y B a su vez a C. Compilalos con gcc con -O0 (sin optimización) y con -O3 (máxima optimización). Y ejecutalo con time. También es un programa básicamente reactivo (los hilos se bloquean hasta que la operación de E/S haya acabado y los pipes también son bloqueantes; todo a la espera de el SO te informe de que ha acabado). Luego me dices a ver si hay diferencia o no. Prueba con 100 hilos.

Vamos, que me estas diciendo que si el kernel es un 10% más rápido y el kernel se está ejecutando sólo un 5%, la ganancia es del 0,5%.

Te voy a poner un ejemplo de la vida real para que te des cuenta de tu error. Has encargado un libro de sistemas operativos por amazon, dado que necesitas leerlo urgentemente. Está planeado que llegue el viernes. El transportista inicia su última ronda de reparto el viernes a las 5. Recoge los paquetes que hay a esa hora en al central y los entrega. El siguiente reparto es el lunes a las 8 de la mañana. Si el libro llega a central a las 17:05 en vez de a las 16:55, el retraso para entregarte tu libro es de 10 minutos? no, verdad?.

Lo mismo pasa con el sistema operativo. Si tienes bastante carga y atiendes las interrupciones un 10% más despacio puede que algunas se pierdan, teniendo en muchos casos que repetir la operación. La sobrecarga necesaria en leer relojes y temporizadores, sin optimizar el acceso a los registros puede degradar la justicia del planificador, la resolución del mismo, la eficiencia de la planificación de tareas.

Otro ejemplo. Considera un ordenador moderno si tienes que inicializar una zona grande de memoria, pongamos