El rincón de JMACOE

Me senti atraido recientemente acerca de una discusion sobre que el proyecto Foo fue mas rapido que el proyecto Bar, debido a que Foo esta escrito en C (o talvez C++) y Bar esta escrito en Java. En mi experiencia, como programador de kernel y como alguien que a menudo programa en C, incluso cuando es seguro que hay mejores opciones, tales afirmaciones son casi siempre falsas. La velocidad a la que un determinado fragmenteo de código se ejecuta sólo tiene efecto significativo si el programa puede encontrar algo mas que hacer despues de que esa pieza es ejecutada – en otras palabras, tu programa es orientado a la CPU y/o esta bien paralelizado.

La mayoría de programas no lo están. La gran mayoría de programas entran en una o muchas de las siguientes categorías:

Orientado a las E/S: Completar antes una unidad de trabajo solo signifca esperar mas por el proximo bloque/mensaje.
Orientado a la Memoria: Completar antes una unidad de trabajo solo significa mas tiempo de fatiga al sistema de memoria virtual.
Orientado a la sincronizacion (ej. no-paralelo): Completar antes una unidad de trabajo solo significa esperar mas por otro hilo para liberar el bloqueo o lanzar un evento – y por el subsecuente cambio de contexto.
Orientado al algoritmo: Hay mucho trabajo por hacer, y el programa puede realizarlo inmediatamente, pero es trabajo basura a causa de que un mejor algoritmo lo habria evitado. Hicimos lo que todos aprenden en la escuela, los mejores algoritmos importan mas que la micro-optimizacion, ¿no?.

Si nos fijamos en esta excelente lista de rendimiento de programas basado en la observacion del mundo real, veras que la mayoria de problemas mencionados (excepto el #5) se ajustan a esta caracterizacion y no se resuelven mediante el uso de un lenguaje diferente. Es posible ejecutar muchos programas orientados a la sincronizacion en una pieza de hardware, con o sin virtualizacion, pero los pocos recursos que estos programas comparten haran mas probable que acabe convirtiendose en orientado a la memoria. Por otro lado, si un programa es orientado al disco u orientado a la memoria, entonces puede conseguirse mas recursos mediante la distribucion del trabajo a traves de varias maquinas, pero si no sabes como implementar sistemas distribuidos, probablemente solo sean orientados a la red u orientados a la sincronizacion. De hecho la clase de programas que exhiben alta sencibilidad a la latencia de red – una combinacion de acotado a la E/S y acotado a la sincronizacion – es grande y esta creciendo.

Así, tu tienes un programa que usa algoritmos eficientes con una implementacion bien paralelizada, y no es ni orientada a E/S ni orientada a la Memoria. ¿Será mas rápido en C?. Si, bien podría serlo. También podría serlo en Fortran, lo cual es por lo que muchos lo continuan usando para calculos cientificos, pero que a duras penas es una buena elección para un uso mas general. Todo el mundo piensa que esta escribiendo el codigo critico de mas desempeño del mundo, pero en realidad talvez uno de cada veinte programadores esta escribiendo codigo donde nada corta el mas atroz descuido que podria afectar el desempeño del sistema en general (Lamentablemente los descuidos atroces son bastante comunes). Hay buenas razones para que muchos de los uno de cada veinte escriban su codigo en C, pero incluso entonces la mayor parte de las razones no seran un desempeño en linea recta. El codigo JIT puede ser muy competitivo contra el código compilado estaticamente, e incluso mejor en muchos casos, una vez que se haya calentado, pero el desempeño de código critico generalmente no sólo tiene que ser rapido sino predecible. Pausas GC, retardos JIT, y comportamientos de conmutaciones de contexto impredecibles que hacen todos estos lenguajes no aptos para las tareas de desempeño critico, y muchos de estos efectos permanecen en las librerias runtime o frameworks incluso cuando el codigo esta compilado. Lo más importante, casi todos los programadores necesitan preocuparse por hacer que su codigo corra bien en multiples procesadores. Yo incluso argumente que la principal razon por la cual el codigo de kernel tiende a ser eficiente no es que este escrito en C pero si por que esta escrita para paralelismo y por gente que pone en mente estos problemas. Una gran cantidad de codigo es mas rapido, no a causa de que esta escrito en C pero si por las mismas razones que está escrito en C. Es una causa común, no causa y efecto. La causa mas comun de todas es que el codigo C tiende a ser escrito por personas quienes han vivido fuera de la burbuja distorsionadora de la realidad de Java y han sido forzadas a aprender como escribir codigo eficiente (lo cual podrian hacer en Java, y no les importa).

Para los otros dieceinueve programadores de cada veinte que no están implementando kernels o sistemas embebidos o estas pocas piezas de infraestructura a nivel de usuario, tales como servidores web (aplicaciones web no cuenta), donde la atención debe centrarse en la productividad del programador, y no a los ciclos de la computadora. La «escabilidad horizontal» puede parecer un eufemismo para «lanzar mas hardware en el» y he sido acondicionado para aborrecerlo tanto como cualquiera, pero la hiper optimizacion es mas que una alternativa razonable cuando se tiene mucho tiempo para hacerla. Especialmente en los inicios, de otro modo no lo harás. Enfocate primero en la estabilidad y las caracteristicas, luego en la escalabilidad y administracion, al ultimo el desempeño por unidad, por que sino cuidas de los dos primeros nadie se preocupara por la tercera. Si estas atascado persiguiendo perdidas de memoria o implementando estructuras de datos/control que ya existen en otros lenguajes en lugar de mejorar los algoritmos o nuevas caracteristicas, estas gastando tu tiempo en vano. Escribir codigo en C(++) no hace mas rapido los momentos mas importantes por arte de magia, a traves de un conjunto de multiprocesadores (y, posiblemente multi-nodo) del sistema, e incluso si lo hacía podrías perder el punto. Comparando resultados, no se acercan.