Cosas mías

Como ya dije en un comentario anterior, nada nuevo bajo el sol. Comienza con una explicación de los términos más comunes aplicados a la programación en tiempo real, para luego ir detallando aspectos de la misma.

Cada capítulo empieza con un resumen de la terminología empleada, para luego entrar en detalles sobre el tema a tratar; desde mi punto de vista, la profundidad es escasísima salvo alguna excepción. Si lo que el autor cita es todo lo que se sabe en la actualidad sobre el punto tratado, poco estudiado está el tema. Quiero creer que es el autor el que no entra en detalles.

Luego se centra en la forma en que cada lenguaje de programación soporta el tema. Los lenguajes principalmente tratados son ADA, C con soporte POSIX y Java en tiempo real, aunque a veces entra a detallar elementos de otros lenguajes como Occam, Modula y otros todavía más extraños, cuando éstos destacan en algún punto. No conozco ADA, muy poco de Java, pero sí que conozco el C: muy poca profundidad en general. Si el lenguaje soporta la característica, la cita; si no, da unas breves indicaciones sobre cómo se podría implementar y termina.

Luego viene un resumen (quizás lo más valorable del libro), una bibliografía y ejercicios que no me he molestado en mirar salvo excepciones.

Lo cierto es que el libro es muy flojo en general, recorriendo rápidamente todos los temas y a veces yéndose por las ramas, como cuando se pone a desvariar sobre el tiempo, hablando en térmimos filosóficos. No lo recomiendo ni siquiera para un principiante, y menos aún para un profesional que se gane las habichuelas programando sistemas en tiempo real.

Lo más destacable es la explicacion sobre concurrencia, contención y bloqueos de procesos, con el tema de programación de bajo nivel; quizás se hubiera salvado el libro si hubiese tratado estos temas con más amplitud y profundidad.

Un extracto del índice: Fiabilidad y tolerancia a fallos, Excepciones y manejo de excepciones, Programación concurrente, Comunicación y sincronización basada en variables compartidas, Sincronización y comunicación basada en mensajes, Acciones atómicas, procesos concurrentes y fiabilidad, Control de recursos, Capacidades de tiempo real, Planificación, Sistemas distribuidos, Programación de bajo nivel, El entorno de ejecución, Un caso de estudio en Ada.

He leído en el CUJ de Julio (C/C++ Users Journal) un artículo intitulado Micro Benchmarking C++, C#, and Java (sólo pasando por caja), lo que traducido al castellano podría ser algo así como “Pruebas de micro rendimiento para C++/C# y Java”.

El artículo es bastante corto y escueto; el autor indica qué elementos de juicio ha decidido, el hardware y las versiones de las herramientas. Los ensayos consisten en pruebas repetidas con pequeños bloques de código, como operaciones con enteros, en coma flotante, matrices, ordenación, instanciación, excepciones, tablas de dispersión y cosas así.

Este señor ha ejecutado los programas en Linux (Sun java 1.4.2 y 1.5, gcc, intel c, mono) y en Windows XP+SP2 (SUN java 1.4.2, java 5, net 2, net 1.1sp1, ms c++ 7.1). Las versiones java han sido verificadas tanto en el lado cliente como en el servidor.

Personalmente considero que, dado lo delicado del tema, el artículo es todo lo serio que puede ser.

RESULTADOS
En contra de mi opnión personal, y creo que en la de muchos, lo más destacable es la velocidad de Java, comparable a la de C++, tanto en ambas plataformas (excepto en rendimiento con operaciones de enteros del lado cliente, cosa que no entiendo) como en forma cruzada. Tan sólo tarda unos pocos milisegundos más en hacer las cosas. El .NET en general se queda después de Java (salvo excepciones con un rendimiento igual al ms c++ 7.1).

El ganador indiscutible es el GCC bajo Linux, que supera en rendimiento al C++ de Microsoft en casi todo (qué lástima que el autor no haya probado el gcc-win32), y el perdedor indiscutbile es Mono 1.0.6, con el peor rendimiento en casi todo (incluso dos y tres veces más lento que el más lento), seguido del lado cliente de Java, aunque sólo a veces.

TERRA INCOGNITA
Sabemos que Java es lento. No hay mas que instalar Eclipse para darse cuenta de ello. O cualquier otra aplicación grande. En mi experiencia personal es más lento que el .NET, por lo menos la sensación del usuario es esa. Sin embargo, en estos tests de rendimiento, gana. Y no es un problema de consumo de memoria, porque si tienes memoria suficiente (1,5 GB en mi caso), también lo es (me refiero con esto a que no tira de archivo de paginación, por lo que todo el asunto queda entre la RAM, la MMU y el procesador).

¿Dónde está, pues la lentitud en Java?