Las arquitecturas del pasado ¿son las arquitecturas del futuro?

Las nuevas arquitecturas que están apareciendo últimamente en escena, tratan de superar los límites impuestos por el consumo de energía y la disipación térmica (además de las restricciones que la escala de integración impone a la física convencional, un electrón necesita un “camino” de tres átomos de ancho, si le reducimos ese camino las propiedades de la física convencional dan paso a las de la física cuántica). Las últimas propuestas se apoyan en construcciones en las que la escala de integración juega un papel importante a la hora de darles forma. Los procesadores multicore y el uso de estructuras similares pero con procesadores gráficos (GPUs) que hoy día atraen la atención de todos los desarrolladores, no son otra cosa que la evolución natural de una arquitectura nacida a principios de los 80: los transputers (ver figura 1). Tras un forzado intervalo en el que se ha podido extraer rendimiento sin más que factorizar las arquitecturas la industria se ha visto obligada a retomar el modelo que hace décadas rechazo. Los motivos de que esta arquitectura no tuviera un éxito merecido puede encontrarse en que para programarlos se precisaban conocimientos muy precisos sobre concurrencia y paralelismo (cualquiera que haya usado Occam puede hacerse a la idea de lo tedioso que pudo resultar aquello). Por lo que ante la decisión de continuar programando con el modelo tradicional (programación estructurada con un solo flujo de control) o dar el paso al entorno paralelo – concurrente impuesto por estas arquitecturas, ocurrió lo que tenía que ocurrir y es que se relegara esta última opción en pos de la primera. Y claro, mientras duró, duró. Ya no podemos seguir exprimiendo los avances tecnológicos para seguir creando cada vez procesadores más y más potentes. Por lo que hemos de volver hacía atrás. Hoy día, por suerte, los modelos de programación son más completos, las técnicas de depuración están más conseguidas,…, programar en estos entornos HOY no es tan malo como ANTES. Quizá este paréntesis haya sido lo que necesitábamos para aprender a programar tal y como hoy se requiere que lo hagamos.

Figura 1. DOS Placas con sus transputers conectados. En la placa de abajo se ven mejor los transputers.

Los transputers son computadores completos (ver figura 2) embebidos en un chip. Chip que posee un procesador, algunos KB de SRAM, y cuatro enlaces (mapeados en memoria) para conectarse con otros transputers que se encuentren en la misma placa.

Figura 2. Cómo se pueden conectar para formar un sistema paralelo y concurrente más potente (derecha).

Estos procesadores se crearon junto con un potente lenguaje de programación Occam (eminentemente concurrente) capaz de extraer al máximo toda la potencia de estas arquitecturas. Occam es un lenguaje concurrente que se construye sobre un álgebra de procesos denominada Communicating Sequential Processes (CSP). Álgebra que más tarde ha sido incorporada a lenguajes como Java cuando se pretende que éste contenga extensiones de concurrencia (CTJ : Communicating Threads for Java). De modo que las arquitecturas basadas en transputers no sólo han ofrecido una interesante perspectiva para manejar la concurrencia en lenguajes orientados a objetos convencionales muy populares hoy día (se puede comprobar cómo hay extensiones para C# que incorporan metodologías nacidas para programar aquellas arquitecturas, ver artículo Modern Concurrency Abstractions for C# ), sino que crearon la excusa para construir modelos útiles de paralelismo donde poder mezclar ambos conceptos: concurrencia y paralelismo.

En aquella época se inició el estudio de las abstracciones basadas en OO [1, 2] para aliviar el peso técnico de escribir software paralelo (y evitar perder mercado o ganar rendimiento sin tener que conocer a la máquina) que debiera lidiar con aspectos concurrentes, ya que un procesador (de un transputer) podía estar ejecutando una tarea mientras otra estaba usando la lógica de comunicaciones. De este modo los programas paralelos tenían una cierta componente concurrente que de no tenerla, en cuenta podría degradar con creces el rendimiento de la aplicación.

Los modelos de programación que se están buscando hoy para desarrollar con acierto en las nuevas plataformas, en gran medida están partiendo sin tener en cuenta a aquellas arquitecturas para las que ya existía un gran camino andado y una plétora de soluciones preparadas para ser explotadas [3,4,5].

Al igual que los multicore (o mejor dicho) al igual que ocurre con las tarjetas gráficas como TESLA, que su computación es "guiada" por un procesador de propósito general, los transputers eran conectados a potentes procesadores que dirigían la orquesta (figura 3).

Figura 3. Transputers conectados al sistema (recuerda mucho a las GPU actuales)

La gran ventaja de estas arquitecturas era la posibilidad de reconfigurar los enlaces entre los procesadores y de disponer de enlaces virtualizados (o abstraídos) desde el punto de vista del software. Otra ventaja es que los transputers podían intercambiarse ya que eran compatibles en el patillaje. El uso de la memoria compartida dio origen a técnicas y productos software como CSP y al uso de lenguajes como Java.

La programación Orientada a Objetos al rescate: más expresividad y más rendimiento

Inicialmente los sistemas basados en objetos obviaban el paralelismo, a pesar de que la manera en la que los objetos se comunican favorece mucho al paralelismo. La concurrencia ha ganado bastante terreno en este campo [6], se ha extendido bastante dentro del modelo orientado a objetos. Además el uso de objetos facilita la descomposición del problema. Los objetos tienen una naturaleza intrínseca que les permite definir dominios separados de ejecución. Los sistemas basados en objetos definen dos tipos de paralelismo:

• Inter-objeto: deriva del concepto que considera a los objetos como entidades separadas de computación. El escenario de computación lo conforman todos los objetos formando una composición. Los objetos se comunican como si fueran clientes/servidores de servicios. El tiempo de respuesta a las peticiones de servicio contribuye a un determinismo global incómodo.

• Intra-objeto: Proporciona concurrencia dentro del mismo objeto (actores). Los sistemas de objetos concurrentes, únicamente proporcionan paralelismo intra- objeto. El inderterminismo local, propio de este paralelismo viene dado por la elección de la tarea a tratar. El modelo de objetos que Corradi propuso [7] trata de eliminar esta incoherencia con la herencia múltiple y la dinamicidad propias del modelo de objetos. El modelo se apoya sobre el concepto de actores [8].

El modelo de programación propuesto para estas arquitecturas (transputers y que ahora se puede usar en las nuevas arquitecturas) se apoyaba en el objeto como concepto. Algunas de las características subrayables de la orientación a objetos y que favorece a estas arquitecturas es:

(a) Protegen sus datos internos (estado).

(b) Protegen su estado interno y no lo comparten. La intefaz visible de un objeto, únicamente son operaciones que manipulan el estado del objeto. Los objetos son por tanto, abstracciones de datos [9].

(c) Un objeto es una instancia de un tipo de datos abstracto (su clase) los objetos derivan su comportamiento de las clases. Cualquier clase encierra la descripción de todas las instancias. Es más, la relación de herencia faculta la factorización.

Las dos primeras propiedades definen un escenario basado en entornos separados y locales. Desde este punto de vista, los objetos pueden ejecutarse en paralelo, como los actores. Por tanto, los objetos no solo son unidades estructuradoras sino unidades concurrentes. Cada objeto es propietario de una cola de mensajes individual que almacena todas las peticiones de servicio (como en el modelo de actores). En adición, cada objeto ejecuta una tarea cada vez. PO es un modelo de objetos donde el paralelismo como puede ser expresado con facilidad.

La llegada de los clústeres como plataformas de computación paralela barata y viable dejó en el olvido a estas técnicas en pos de las de programación estructurada basadas en el paso de mensajes. Las nuevas arquitecturas están promoviendo la búsqueda de un modelo donde unir ambas perspectivas. En esta línea existen trabajos en los que se apuesta por la construcción de composiciones de objetos (aunque en el caso que citamos no son PO) donde se provea de planificadores internos y mecanismos de control de concurrencia. Estas construcciones denominadas High Level Parallel Cosntructions o como los autores las denominan : CPANs [10] se apoyan en una librería creada en el modelo clásico apoyado en pthreads y c++.

Conclusión

Por tanto, a veces conviene echar la vista atrás y poder descubrir técnicas que se usaban antes y que posiblemente pudieramos usar en las arquitecturas actuales. Especialmente en el caso de los transputer, que para mi, es la semilla de las arquitecturas multicore (y basadas en GPU) que estamos viendo proliferar en el último lustro. Por tanto, la inercia en las técnicas de programación adquirida durante el periodo en que hemos disfrutado de la potencia provista por un único procesador ha de erradicarse y buscar alternativas tan interesantes como la propuesta por el modelo de PO (Parallel Objects), propuesta que está a punto de cumplir veinte años.

Referencias :

1.- The support for a dynamic parallel object model on atransputer-based architecture. Ciampolini, A.; Corradi, A.; Leonardi, L. Computers and Communications, 1991. Conference Proceedings., Tenth Annual International Phoenix Conference on Volume , Issue , 27-30 Mar 1991 Page(s):316 - 322 Digital Object Identifier 10.1109/PCCC.1991.113828

2.- Programming environments for transputer-based architectures Boari, M.; Ciampolini, A.; Corradi, A. CompEuro apos;91. Advanced Computer Technology, Reliable Systems and Applications. 5th Annual European Computer Conference. Proceedings. Volume , Issue , 13-16 May 1991 Page(s):94 - 102 Digital Object Identifier 10.1109/CMPEUR.1991.257363

3.- Experiences on Porting a Parallel Objects Environment from a Transputer Network to a PVM-Based Systems. Franco Zambonelli and Matteo Pugassi and Letizia Leonardi and Nello Scarabottolo. 4 th Euromicro Workshop on Parallel and Distributed Processing, IEEE CS Press,

4.- "Parallelism in Object-oriented Programming Languages", A. Corradi, L. Leonardi: IEEE Conference on Computer Languages, New Orleans (Luisiana-USA), March 1990.

5.- "Parallel Object Models in the Design of an Environment for Massively Parallel Architectures", A. Ciampolini, A. Corradi, L. Leonardi. First Workshop of the ESPRIT Parallel Computing Action, Southampton (UK), July 1990.

6.- Object Oriented Concurrent Programming. Yonezawa, A and Tokoro, M.

7.- An environment based on parallel objects: PO. Corradi and Leonardi

8.- Foundations of actor semantics. Clinger, W. D.

9.- Abstraction mechanism in CLU. Liskov, B. H.

10.-An Approach to Structured Parallel Programming Based on a Composition of Parallel Objects. Capel