El milagro de las 200 líneas de código

Un pequeño parche de apenas 200 líneas de código podría suponer una mejora crítica en el rendimiento de nuestros sistemas gracias a un dramático incremento de los tiempos de respuesta a la hora de manejar multitarea.



Esta modificación ha sido creada por Mike Galbraith, y está siendo revisada por Linus Torvalds, que parece realmente alucinado con las mejoras conseguidas gracias a dicha modificación:

Tengo que decir que estoy (agradablemente) sorprendido por lo pequeño que este parche ha acabado siendo, y como no es ni intrusivo ni feo en ningún modo.

También estoy contento con lo que logra hacer con el rendimiento interactivo. Tengo que admitir que mi caso de prueba es realmente trivial (leer email en un navegador web, desplazarme con el scroll un poco, además de hacer un ‘make -j64′ en el núcleo al mismo tiempo), pero es un caso de prueba que es muy relevante para mí. Y la mejora es impresionante.

Es una mejora para cosas como el scroll, pero lo que he descubierto que es más interesante es cómo parece que hace que parezca que las páginas web se carguen mucho más rápido. Puede que eso no debiera ser sorprendente, pero siempre he asociado eso con el rendimiento de la red. Pero está claro que hay carga de CPU cuando cargamos una nueva página web y desde luego mucha más cuando cargamos más de 50 al mismo tiempo, algo que provocará que la CPU se quede sin recursos en el proceso de carga, y que probablemente también provoque que las peticiones HTTP no se procesen lo suficientemente rápido.

Así que creo que este es desde luego uno de esos parches con “mejoras reales”. Buen trabajo. La planificación en grupos se convierte de algo “útil para ciertas cargas específicas en el servidor” a “esta es una característica alucinante”.

La idea es la crear grupos de tareas por TTY en un esfuerzo para mejorar la interactividad del escritorio bajo cargas de trabajo exigente, y en 224 líneas es posible modificar el planificador para que en estos escenarios la mejora de la interactividad sea impresionante.

En Phoronix han probado ambas versiones (con y sin el parche) y han constatado que la mejora es impresionante, la diferencia entre activar el parche y no activarlo es sencillamente brutal.

Se espera incluso que el parche se aplique al kernel 2.6.37.

La verdad es que esto lo leí hace un par de días en muchos blogs. Lo bueno del software libre y de su comunidad son estos pequeños aportes que hacen que todo avance mucho más rápido. Si lo aplican en el kernel 2.6.37 está claro que hasta el 2.6.38 no lo veremos ya que las distintas distros me imagino que tendrán que adaptarlo, pero la espera merecerá la pena.

Yo estoy por compilarlo y parchearme el kernel, porque por lo que he visto en los videos, es una mala bestia.

Bueno, si sale bien el invento lo incluirán en una próxima actualización y ahí veremos si realmente se nota la diferencia en el rendimiento... frente a esto, me muestro bastante escéptico (200 líneas de código son extramadamente pocas... joe, hasta la más sencilla de mis prácticas ocupa el doble).