sábado, 31 de enero de 2009

Paralelismo con AJAX

La idea de probar con un tema así, me vino a principios de curso, por un miniproyecto libre que nos pidió un profesor relacionado con el paralelismo, había probado PVM, MPI (a nivel de librería) en C y me animé a probar hacerlo con AJAX a ver que pasaba.
Lo malo de AJAX es la plataforma sobre la que se mueve, hay que pensar que los clientes (los usuarios) tendrán como ésta su navegador, por lo que no puedes esperar la velocidad de C.
Lo bueno es, aparte de la multiplataformidad (hasta las neveras tienen navegador de Internet), la cantidad de aplicaciones cliente que pueden entrar. Con los navegadores de Internet pasa un poco como con los zombies: Son lentos. Son débiles. Son tontos. Pero ante todo, son MUCHOS.
Hice dos aplicaciones, una para calcular números primos a base de fuerza bruta, y luego otra que consistía en adaptar un algoritmo de RayTracing en javascript a una versión paralela, para la comunicación utilicé la librería DWR para poder utilizar Java y las páginas en JSP.
He subido ambos miniproyectos a mi cuenta en Box.net (debajo del post lo tenéis) para que podáis probarlos si queréis, tienen la documentación tal cual se la envié al profesor con las pruebas. De todos modos os pongo una pequeña explicación:

Números primos
Por la parte del servidor hay una base de datos en MySQL y sus funciones son las de etiquetar a los que entran (algo así como un ID para saber quien hace qué), bajo petición decirles qué valor deben mirar y recibir resultados... simple. Claramente ante la preguntas ¿ya pero si entran dos a la vez? o ¿cuando hay tanta distancia entre dos primos que no recibe datos y siempre va a pedir empezar desde el mismo valor a todos los que entren? o ¿no sería preferible enviar varios valores a mirar a enviar valor por valor de forma individual? hay una fácil respuesta: esto es para probar hacer paralelismo con AJAX, no para calcular todos los números primos del mundo, obviamente fuerza bruta no es la mejor forma de hacer las cosas, pero sí experimentar con tecnologías que permiten la creación de grids sin necesidad de descargar software de terceros, con los riesgos que ello suele conllevar.
El cliente por otra parte, lo que hace es entrar, recibir el id y pedir números para empezar a calcular como loco, por cada resultado que reciba lo manda junto con su id al servidor, y punto.

RayTracing

El algoritmo de raytracing va pixel por pixel, calculando el recorrido que hace un rayo de luz desde ese punto hasta un cierto número de niveles que se especifica en el código.
Me explico, desde un punto, se lanza un rayo hacia delante, si se topa con un objeto (por ejemplo una esfera) calcula la dirección que tomaría el rayo dependiendo del material de dicho objeto, si por ejemplo es transparente o semitransparente, habría reflexión y refracción, este rayo se prolongaría rebotando entre el número de objetos que desees (niveles) y así pixel por pixel, al final de tanto rebote obtendrías una información de color en tres valores (rojo, verde y azul).
Pues la idea era que los clientes hicieran la fila que el servidor les dijese y devolviesen la información de todos esos colores en un array de X elementos, donde X se corresponde con la anchura de la imagen.
Tal y como se programó, básicamente el maestro ante de hacer una fila pregunta al servidor ¿esta fila está hecha?, si es que sí, recibe la información de los colores, si no los calcula él. Los clientes calculan partiendo desde la parte inferior de la imagen y el master desde la parte superior, hice esto, mas que nada para ver hasta que fila se llega con los clientes, es una forma de medir cuanta mejora hay añadiendo clientes al sistema.
Recuerdo pensar que habría ido mejor si hubiese granulado más las filas de la imagen, por ahora se pide a cada cliente que vaya dibujando una fila de pixels, una fila entera, pero cuando la imagen es muy ancha, tiene que calcular un array de X elementos, que a su vez tiene tres elementos más en coma flotante (los tres colores). Total, que al final tienes X*3 elementos para enviar por Internet, por lo que no salía rentable, ya que el ordenador maestro también va calculando y en casos de tardar mucho en llegar la información, sale mejor que haga todos los cálculos éste. La idea era dividir bajo algún concepto esa fila, de modo que realmente se pediría un rango de pixels al cliente.
Buff, madre mía que mareo de palabras, el caso era símplemente que hay mucho potencial en Internet respecto al tema del paralelismo y más aún con herramientas como puede ser AJAX o Comet, lo único es echarle imaginación.


No hay comentarios:

Publicar un comentario