Universidad Nacional Autónoma de México
Dirección General de Servicios de Cómputo Académico
Año 7 Núm. 74, Publicación Mensual, 27 de Noviembre de 2008

ARTÍCULOS

 

Año 6, Número 60, Junio de 2007

La crisis del software en el cómputo científico
Luis Miguel de la Cruz

 

En 1965, Gordon Moore predijo que la densidad de transistores en un chip semiconductor podría duplicarse cada 18 meses, de tal manera que la velocidad del procesador, la memoria, el ancho de banda, la capacidad de almacenamiento, etcétera, deberían tener un incremento del doble cada 1.5 años 1. Esta regla, conocida como la ley de Moore, se ha cumplido durante cuatro décadas y se vislumbra que será válida al menos durante una década más, según se indica en Intel Home Page: Moore Law, http://www.intel.com/technology/mooreslaw/index.htm. Sin embargo, a pesar del continuo incremento en el poder de los microprocesadores existe una limitante física: la separación entre los transistores no puede ser menor que el tamaño finito de las partículas atómicas.

Este límite físico ha ocasionado la búsqueda de alternativas para resolver problemas de gran escala que requieren procesadores a muy altas velocidades, memoria amplia y discos de almacenamiento de gran capacidad. Actualmente, el uso del cómputo paralelo para resolver este tipo de situaciones, que aparecen en distintas áreas de la ciencia es, en la mayoría de los casos, la única opción viable para obtener soluciones en tiempos razonables.

Particularmente, en las ciencias físicas, el deseo de aproximar soluciones numéricas a problemas cuya solución analítica no ha sido posible encontrar, ha generado el desarrollo de nuevas arquitecturas de cómputo que incluyen procesadores vectoriales y, especialmente, plataformas multiprocesador. La lista del Top500 de las supercómputadoras más poderosas del mundo es un ejemplo de la variedad de arquitecturas existentes hoy en día.

De forma paralela se utilizan códigos complejos, cuyo mantenimiento es complicado y sólo se emplean para resolver cuestiones particulares. En muchos casos, el reutilizar software es prácticamente nulo, lo cual deriva en una crisis de éste que, en pocas palabras, se expresa como: la dificultad de construir sistemas simples de entender, mantener y extender y que, además, provean soluciones realistas y con buena precisión a problemas complejos 2. En Scientific Computing in Object-Oriented Languages, http://www.oonumerics.org/ se agrupan diversos textos y vínculos a foros y congresos que se refieren al uso de la programación orientada a objetos para analizar y resolver la crisis del software científco.

Si deseamos que un código aproveche de manera eficiente la arquitectura de cierto sistema de cómputo, se tendrá que optimizar y sintonizar para esa plataforma, con las herramientas de desarrollo de software instaladas en él, ocasionando que el código no pueda transportarse fácilmente a otro sistema de cómputo, y tenga que rescribirse para cada arquitectura. Este problema no es particular de las simulaciones numéricas y se da en distintas áreas de la ciencia de la computación. Por ejemplo, hoy en día, el paso de un software de un sistema de 32 bits a otro de 64 bits, supone un gran trabajo para los desarrolladores.

Proceso de desarrollo de software

Los avances en el desarrollo de software han revolucionado muchas actividades de la vida diaria. Desafortunadamente, la mayoría de los sistemas existentes en nuestros días presentan fallas en alguna etapa de su uso y no entregan soluciones adecuadas a los problemas para los cuales fueron creados. Esto sucede, principalmente, porque los requerimientos del usuario son mal entendidos o cambian durante el desarrollo del software. Además, tanto el mantenimiento como reutilizar y modificar algunas partes del software son tareas complicadas y tediosas.

En la actualidad, existen diferentes estrategias para desarrollar software de una manera ordenada e incremental, que capturan desde el principio y durante la construcción de un sistema, los requerimientos deseados por los posibles usuarios.

El proceso unificado que incorpora las ideas de Booch, Jacobson y Rumbaugh es, actualmente, un estándar de desarrollo y se utiliza en el diseño de sistemas de software industriales 3. Este proceso provee una guía para la construcción eficiente de sistemas de alta calidad y consiste de cuatro fases principales: incepción, elaboración, construcción y transición, las cuales se descomponen en proyectos pequeños que se van desarrollando en iteraciones. Asimismo, cada iteración consiste de requerimientos, análisis, diseño, implementación y pruebas, para en cada paso entregar una versión del software que resuelve parte del problema. Durante las fases e iteraciones se obtiene una arquitectura que contiene los aspectos dinámicos y estáticos más significativos del sistema. La arquitectura conduce a la construcción de diferentes módulos y componentes del sistema, y depende de muchos factores (plataforma de cómputo, sistema operativo, componentes existentes, etcétera). Finalmente, la arquitectura implica una vista global del diseño del sistema donde se muestran las características más importantes, dejando de lado los detalles de la implementación. El proceso unificado es una excelente opción para desarrollar software de manera ordenada. Sin embargo, es importante dedicar bastante tiempo en el inicio del desarrollo (incepción), que comienza con los casos de uso.

En la construcción de software para cómputo científico, el problema mayor es la realización de un diseño adecuado para que se haga un uso eficiente de las complejas arquitecturas en donde se vaya a ejecutar. Tradicionalmente, el software numérico se realiza usando lenguajes estructurados (Fortran o C). Sin embargo, la complejidad del software crece rápidamente, de tal manera que si al principio no está bien ordenado (alta entropía), su tiempo de vida será corto.

En las últimas décadas, el reutilizar software científico ha sido una práctica común para realizar simulaciones numéricas en corto tiempo. Bibliotecas comerciales y de dominio público como BLAS 4, LAPACK 5, IMSL 6 y NAG 7 son estándares en el desarrollo de códigos científicos.

Estas bibliotecas están construidas en el estilo de programación estructurada, mediante los lenguajes C y Fortran, por lo que se obtiene un buen rendimiento. No obstante, a pesar de su utilidad, se tienen algunos inconvenientes, signos típicos de la crisis del software:

  1. Poca expresividad del código. La implementación no refleja claramente el algoritmo que se está usando.
  2. Repetición del código. En muchos casos, se tiene que escribir el mismo código para tipos de datos distintos.
  3. Alto acoplamiento y baja cohesión. Las construcciones del código no reflejan claramente las matemáticas que implementa y existen muchas dependencias entre diferentes partes del código.

Una salida a la crisis: orientación a objetos en el cómputo científico

El cómputo científico ha alcanzado un nivel de complejidad importante, debido a la proliferación de algoritmos sofisticados y al considerable rango de arquitecturas de hardware existentes actualmente, lo que provoca una crisis de software en esta área.

Diferentes paradigmas de programación han sido desarrollados con el objetivo específico de eliminar el problema de la crisis del software. No obstante, estos “nuevos” paradigmas no se han aplicado directamente a problemas de simulación debido, principalmente, a que se tiene la percepción de que el rendimiento se ve afectado de manera sustancial.

Un requisito indispensable en las aplicaciones de cómputo numérico intensivo es, sin duda, el alto rendimiento. Sin embargo, para que el código sea reutilizable por muchos investigadores y aplicable en diferentes tipos de problemas, es importante tener también un alto nivel de abstracción, es decir, lograr que sea entendible y manejable, y exprese claramente las matemáticas de los algoritmos implementados.

El paradigma de programación orientada a objetos (POO) tiene como principal objetivo el manejo de la complejidad del software. Los conceptos básicos de abstracción, encapsulamiento, mensajes, polimorfismo y herencia permiten desarrollar programas de fácil manejo y control, tanto para el desarrollador como para el usuario final. En general, los diseños orientados a objetos permiten un mejor encapsulamiento y separación de los conceptos, lo cual genera un alto grado de modularidad y flexibilidad, además de incrementar el reutilizar partes individuales del sistema.

De manera adicional, el lenguaje de programación C++ provee de una característica especial, conocida como templates, con la cual es posible construir código eficiente, y que combinada con las herramientas de la POO resultan de gran utilidad en la construcción de software científico eficiente, con un alto nivel de abstracción. Varios ejemplos se pueden encontrar en Scientific Computing in Object-Oriented Languages, que son alternativas para superar la crisis de software aplicable al cómputo científico.

Para mayor información:

http://www.oonumerics.org/
http://www.netlib.org/blas/
http://www.netlib.org/lapack/
http://www.nag.co.uk/
http://www.vni.com/products/imsl/c/imslc.html

 

1 Moore, G. E. Cramming more components onto integrated circuits. Electronics, Vol. 38, No. 8, 1965.
2 Booch, G. Object-Oriented Analysis and Design with Applications. Benjamin Cummings, Redwood City, CA, 1994.
3 Jacobson, I. and Booch, G. and Rumbaugh, J. The Unified Software Development Process. Addison Wesley, 1999.
4 BLAS (Basic Linear Algebra Subprograms), http://www.netlib.org/blas/
5 LAPACK (Linear Algebra PACKage) http://www.netlib.org/lapack/
6 IMSL C Numerical Library, http://www.vni.com/products/imsl/c/imslc.html
7 Numerical Algorithms Group: mathematics and technology for optimized performance, http://www.nag.co.uk/

 

Inicio | Contacto |