Computación con programas matemáticos
Existen muchos programas para realizar cálculos matématicos, en el ámbito comercial tenemos Mathematica, Maple, Matlab, SPSS, etc. y como software libre podemos encontrar a Maxima, Axion, Scilab, Octave, FreeMat, SciPy, PSPP, R, etc. En el número 6 de la revista Linux+ se hacía una pequeño análisis de Maxima, Scilab y Octave aunque centrandose sobre todo en usabilidad. En este sentido uno de los factores más atractivos de estos programas es la interfaz gráfica con la que el usuario interactúa y la generación de gráficos que lleva integrada.
No obstante, desde el punto del HPC son más importantes otros aspectos relacionados con el rendimiento y en este artículo vamos a hablar un poco de estos programas pero desde una perspectiva del cálculo científico.
El problema que se plantea es el de un investigador que quiere resolver su un problema lo más eficientemente posible o en el menor tiempo. Este tiempo incluye el necesario para programar más el de ejecución. En el caso de investigadores que requieran programar mucho y calcular menos estos programas son una gran ayuda. Investigadores en cambio que vayan a programar poco pero luego tengan mucho calcular tal vez debería pensar pausadamente si uno de estos programas es una buena solución.
Rendimiento
Para evaluar el rendimiento hemos ejecutado en máquinas Xeon de última generación una serie de programas matemáticos y hemos medido sus tiempos de ejecución obteniendo a partir de ello una puntuación. Mas detalles en el SGI-IZO.
Nosotros vamos a analizar tres programas Matlab, Scilab y Octave (la interfaz gráfica de Octave se llama QtOctave y se instala separadamente). Los tres programas son muy similares y compatibles entre sí. Matlab es comercial y podemos obtener los binarios. Scilab y Octave son programas libres y podemos instalar binarios o descargar el código fuente del programa y compilarlo (hacer un binario) para nuestro ordenador.
La primera pregunta que podemos hacernos es si es mejor instalar el programa o compilar el programa. En el caso de Matlab no hay alternativa pero si para los códigos libres. Para ello en la tabla siguiente podemos ver los tiempos de ejecución de estos programas instalados y compilados (Un valor más grande significa más lento).
| Compilado | Instalado | |
| Scilab | 16 | 29 |
| Octave | 15 | 40 |
El proceso de compilación puede volverse tedioso e incluso complicado pero vemos que los programas compilados junto con buenas librerías matemáticas doblan o más en velocidad a los binarios instalados.
| Scilab | Octave | Matlab | |
| Score | 16 | 15 | 10 |
En la tabla se observa como matlab en los benchmark que hemos empleado es el más rápido de los tres programas. No obstante, el benchmark consta de 15 programas diferentes y si miramos los detalles vemos que Scilab, Octave y Matlab tienen tiempos muy similares en 14 de los benchmark pero en uno Matlab se ejecuta casi de forma instantánea mientras que Octave y Scilab tarda entorno al minuto. Matlab usa compilación Just-In-Time que aún no ha sido incluida en Octave ni Scilab (si en FreeMat). Esto hace que las ejecuciones de bucles sean especialmente rápida en Matlab mientras que en Octave y Scilab habría que usar otras estrategias como tratar de vectorizar y operar con matrices en vez de bucles para superar este bache. Si eliminamos este benchmark y rehacemos nuestra tabla obtenemos
| Scilab | Octave | Matlab | |
| Score | 11 | 8 | 10 |
Como vemos si eliminamos la ejeción masiva de bucles los tres programas tienen rendimientos muy similares.
Conclusión
Un análisis previo nos puede ayudar a decidir la mejor solución a la hora de escoger el programa a usar y ayudarnos a ahorrar mucho tiempo a largo plazo, aunque sea a costa de un esfuerzo inicial. De este modo vemos que desde la instalación estándar de Octave con una puntuación de 40 a la última ejecución con una puntuación de 8 hemos reducido en 5 veces los tiempos de ejecución. También a la vista de las dos últimas tablas donde la diferencia radica en uno de los 15 programas utilizados, nos damos cuenta que el mejor benchamark que podemos hacer es con nuestros propios códigos, dado que según la programación o funciones que se usen el resultado puede decantarse por uno u otro.
Otra cuestión a tener en cuenta es si debemos de programar en un lenguaje de más bajo nivel como C, C++ o Fortran o emplear los lenguajes de más alto nivel de los programas mátemáticos. Los lenguajes de más bajo nivel como C tienen la ventaja de que se pueden compilar y correr en prácticamente cualquier ordenador y de forma muy eficiente dándonos además mucha independencia. Los lenguajes de los programas matemáticos tienen la enorme ventaja de que sus estructuras de datos son más flexibles y los hace mucho más fáciles de programar pero estamos atados a este tipo de programas, a las máquinas en la que es posible instalarlos (o compilarlos) y su rendimiento ejecutándose.
Interesante artículo. Quizás mencionar también Sage como software libre.
http://www.ehu.eus/ehusfera/hpc/2010/10/29/computacion-con-programas-matematicos/#respond
Me sorprende tanta diferencia entre compilar en la máquina e instalar un pre-compilado. En mi experiencia en los últimos años no he encontrado una justificación tan dura y clara hacia compilar. De hecho, siempre he encontrado comentarios que ponen en duda que Gentoo tenga sentido entre eficiencia ganada contra esfuerzo técnico.
Os saludo desde otro blog de EHUsfera: http://www.ehu.es/ehusfera/pablogn/
@PABLO GONZÁLEZ-NALDA
¡Hola!
Perdón por la tardía respuesta.
No voy a discutir sobre Gentoo pues desconozco exactamente su funcionamiento.
Primero decir que ha nosotros no nos sorpende haber encontrado tal diferencia, aunque tampoco nos habríamos sorprendido si hubiese sido menor o nula (no es una regla fija). Pero son varios los programas de cálculo que hemos instalado y en los que encontramos diferencias notables entre los binarios y las compilaciones que hacemos.
La diferencia entre un binario que se instala y la compilación mediante el típico proceso configure-make-make_install (sin tocarlo) es muy probable que no sea importante pues el propio binario precompilado se habrá generado usando esa misma secuencia de ordenes.
La diferencia viene por los cambios que se hacen en el Makefile para mejorar la compilación en si misma o escoger las librerías más convenientes.
Librerías
Por ejemplo, en este benchmark que hicimos con transformadas de Fourier se ve las enormes diferencias que puede haber entre diferentes implementaciones de las FFT, el escoger una versión estándar u otra optimizada en la compilación puede suponer una gran diferencia a la vista de los resultados.
Compilación
En el caso particular de la arquitectura itanium la elección del compilador es crítica para obtener un buen rendimiento. En el benchmark de StarCCM+ (software de pago del que sólo se suministran binarios) que realizamos se ve que el rendimiento en los nodos itanium es pobre. La razón es que no se ha usado un compilador adecuado sino el más estándar. Otro ejemplo lo tenemos en TBLMTO donde multiplicamos por 50 su rendimiento, no se muestra en el benchmark, sólamente cambiando de compilador (aunque el rendimiento en Itanium sigue siendo menor que en otras arquitecturas por requerimiento para que por lo menos funcione).
En arquitecturas más estándar como la x86 o x86_64 la elección del compilador no suele ser tan crítica pero puede ser un pequeño suma y sigue.
Tampoco compilar-optimizar es la panacea, a veces hemos intentado optimizar un código y no hemos conseguido nada. No obstante, según nuentra experiencia un esfuerzo técnico razonable de unas horas/días al comienzo vale la pena si vas a calcular muchos días/años.