[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]On Wed, 6 Nov 2002, Cristian Othon Martinez Vera wrote: > Computo paralelo no es equivalente a computo distribuido. Cuando trabajas > con computo paralelo, utilizas hardware especializado (como por ejemplo > simputers) y software especializado (como el lenguaje OCCAM), y NO > escribes programas orientado a objetos, sino programas paralelos. > Cuando trabajas con computo distribuido trabajas con cumulos (o clusters) > y con paso de mensajes (como PVM, o HIPPI). En ambos paralelizas tareas, > pero en computo paralelo generalmente se resuelve dentro del mismo > hardware, y en computo distribuido entregas a cada nodo la tarea > paralelizada a resolver, y al terminar cada nodo, regresa su respuesta al > controlador de nodos, quien casi siempre muestra el resultado final. Aqui dejenme meter mi cuchara, aunque la discusion es otra, solo pa' meter mas ruido :-) Esto no es asi. MPI y PVM son bibliotecas de paso de mensajes para programar EN PARALELO. En el caso de los cumulos, los procesos efectivamente se ejecutan en cada nodo, lo que podria entenderse como computo distribuido, pero resuelven un mismo problema, i.e. ejecutan el mismo programa concurrentemente, en paralelo. La frontera entre computo distribuido y paralelo es muy tenue y cada vez lo es mas, con el uso de los cumulos y del grid (un "cumulo" de cumulos, "distribuido" en todo Internet, pero donde puedo correr aplicaciones en "paralelo"). La distincion hay que hacerla mas desde el punto de vista del software, de la aplicacion misma que desde el hardware. Entonces, una de las opciones para programar en paralelo es hacerlo con paso de mensajes utilizando MPI. En la actualidad es la mas utilizada, incluso en maquinas de memoria compartida, donde se podrian utilizar otros modelos. Y se puede programar con MPI desde fortran, C, C++ y hasta java, todo depende de los vicios, desviaciones, las preferencias sexuales, traumas y otras virtudes de cada programador, let it be. > La ventaja que ofrece HURD para los cumulos es que, al ser inherente al > nucleo la comunicacion por paso de mensajes, la adicion de nodos es > transparente, ya que es igual que se comunique a un proceso dentro de la > misma maquina, que a un servidor remoto. Por supuesto, esto sera cuando > el soporte para el paso de mensajes del nucleo HURD a traves de la red > funcione, lo cual no sucede el dia de hoy. > Despues de las aclaraciones anteriores, cabe mencionar que los problemas > a resolver en computo paralelo y distribuido son: > - Como determinar si una tarea es paralelizable o no? > - Como disminuir la latencia en la comunicacion para maximizar el tiempo > de respuesta? > Para responder estas preguntas no es relevante si la solucion es > estructurada u orientada a objetos. Ninguna de las dos filosofias de > programacion ofrece una solución para paralelizar tareas, y la latencia > se combate con eficiencia en la comunicacion entre los elementos que > realizaran el computo. Y en este aspecto, los lenguajes OOP tienen un > "overhead" que en muchas ocasiones los hace impracticos. Una de las soluciones (UNA, no la unica ni la mejor) que se han explorado para disminuir la latencia es que la comunicacion entre procesos en los nodos se realize desde el espacio de las aplicaciones, evitando p.e. la copia de la informacion de la memoria del proceso a la memoria del sistema para poder enviarla. En este caso el papel del kernel podria ser irrelevante. saludos Eduardo _______________________________________________ Ayuda mailing list Ayuda en linux org mx Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/