Aunque Moshe Bar tiene razón, siempre y cuando el controlador de paso de información sea rápido, openMosix ya no tiene demasiada cabida.
Respecto a lo de si se está usando o no, recuerdo cuando me hicieron montar uno para unas prácticas en la universidad: 'vas a montar un clúster que si funciona bien se utilizará en matemáticas'. Nueve 486, 2 pentium 1 y un switch a 10Mbps xD, por supuesto quedó en agua de borrajas.
por
pobrecito hablador
el Domingo, 15 Julio de 2007, 23:10h
(#934125)
Si no recuerdo muy mal alguien tomó una versión GPL de Mosix y tras un desacuerdo con el grupo de investigación que lo desarrollaba montó su propia aventura (openMosix).
Sin el grupo de desarrolladores original (a pesar de ellos que no han recibido el reconocimiento [mosix.org] por su trabajo) openMosix ha avanzado poco en funcionalidad y estabilidad, además de probablemente quemar a los desarrolladores iniciales respecto a liberar nunca más código bajo la licencia GPL, dado que otros se han aprovechado para usar un código sin atribuir correctamente el mérito de sus creadores. La realidad humana...
Mientras tanto Mosix ha seguido avanzando en estabilidad y funcionalidad tal como se puede ver en www.mosix.org [mosix.org] y es gratuito para uso académico.
A la vista de la experiencia el código fuente de Mosix no es libre. Una pena pero tiene justificación en una historia de conflictos, al menos tal como algunos lo ven.
Bien es cierto que el hecho de que yo personalmente hoy haya conseguido correr MacOS X, Windows XP y Ubuntu 7.04 A LA VEZ [blogspot.com] gracias a los dos cores de mi MacBook podrian hacer pensar que los clusters hoy dia no tienen sentido, yo mas bien pienso lo contrario. ¿Los clusters que ofrecen? Potencia de calculo y multiproceso en paralelo en masa al convertir varios ordenadores en un superordenador. ¿Pero que pasa si cada uno de esos ordenadores ya es un un superordenador capaz de hacer multiproceso en masa? Pues que nos sale un monstruo con una potencia de calculo enorme en un espacio mucho mas pequeño y con un consumo menor. Yo creo que aunque puede ser que hayan perdido terreno, precisamente los multicores son los que les van a dar un empujon porque ya no hacen falta un monton de maquinas cuando puedes tener la misma potencia de calculo con un conjunto mucho mas reducido de ordenadores. Lo que esta claro es que hasta que no salga el Intel Core 1024 Duo con 1024 cores simetricos y con hyperthreating en una unica pastilla del tamaño de mi PDA todavia los clusters van a seguir dando guerra;-)
Yo usé OpenMosix hace como 1 año atrás, lo primero que noté fue lo verde que iba el desarrollo para los kernel 2.6.x.
Tuve que montarlo con kernels 2.4.x, pero se necesitaban los 2.6 por otros motivos, y al final OM quedó olvidado.
Leí al respecto que no les estaba siendo NADA facil migrar el código, y aunque salio un rpm con una beta de lo que habían hecho, seguía muy lejos de ser usable (ni siquiera habían aún las userland compatibles con ésta beta).
Hace unos meses se me ocurrió echarle un ojo, solo para ver que no habían avanzado casi nada desde entonces. No sé en que estarán ahorita, pero para anunciar el retiro significa que no han conseguido resultados que los haga querer siguiendo.
Una verdadera lástima, no será el programa ideal para montar un clúster, pero el hecho de no tener que tocar código y ejecutar los trabajos mediante simples scripts lo hacían ideal para empezar.
En gran problema de Mosix y de OpenMosix es que nunca ha podido competir en rendimiento con MPI o PVM, especialmente con MPI. En algunos de los clusters en los que se instaló dio gravísimos problemas de latencias inaceptables en problemas muy acoplados y un muy muy mal escalado a partir de la docena de procesadores.
Las palabras de Moshe se pueden malentender porque el nicho de OpenMosix ha sido aplastado por debajo (pocos núcleos) y por arriba (centenares o miles de núcleos). Los procesadores multicore cada vez son más baratos con los que montar un cluster OpenMosix no es razonable. En grandes clusters beowulf OpenMosix escala tan mal que no merece la pena ni intentarlo.
La tendencia en el mundo de la programación científica intensiva sigue siendo MPI. No veo mucho PVM porque el coste de desarrollar el software es parecido y se consigue mejor rendimiento con MPI. De este modo también se utilizan los procesadores multicore, no se lanza un proceso por procesador sino un proceso por núcleo, esto es automático. De este modo se aprovecha el multicore pero hasta cierto punto porque el ancho de banda limitante es el de las comunicaciones entre nodos que es entre uno y dos órdenes de magnitud más lento que el que hay entre núcleos. Lo ideal es programar pensando en nodos y núcleos y tener dos grados de paralelización: uno fino con POSIX o OpenMP y otro grueso con MPI.Al final todo esto termina estando oculto para el usuario gracias a PBLAS, BLACS y SCALAPACK
1 respuesta por debajo de tu umbral de lectura actual.
Una lástima
(Puntos:2)( http://www.fluzo.org/ )
--
atrapado por tu moda [fluzo.org]
Se veía venir ...
(Puntos:1, Informativo)Si no recuerdo muy mal alguien tomó una versión GPL de Mosix y tras un desacuerdo con el grupo de investigación que lo desarrollaba montó su propia aventura (openMosix).
Sin el grupo de desarrolladores original (a pesar de ellos que no han recibido el reconocimiento [mosix.org] por su trabajo) openMosix ha avanzado poco en funcionalidad y estabilidad, además de probablemente quemar a los desarrolladores iniciales respecto a liberar nunca más código bajo la licencia GPL, dado que otros se han aprovechado para usar un código sin atribuir correctamente el mérito de sus creadores. La realidad humana ...
Mientras tanto Mosix ha seguido avanzando en estabilidad y funcionalidad tal como se puede ver en www.mosix.org [mosix.org] y es gratuito para uso académico.
A la vista de la experiencia el código fuente de Mosix no es libre. Una pena pero tiene justificación en una historia de conflictos, al menos tal como algunos lo ven.
tendencia
(Puntos:1, Interesante)Los clusters si tienen sentido
(Puntos:3, Interesante)( http://pirannafs.blogspot.com/ )
Se veía venir...
(Puntos:2)Respondiendo algunas de las dudas
(Puntos:2)( http://torroja.dmt.upm.es/guillem/blog )
En gran problema de Mosix y de OpenMosix es que nunca ha podido competir en rendimiento con MPI o PVM, especialmente con MPI. En algunos de los clusters en los que se instaló dio gravísimos problemas de latencias inaceptables en problemas muy acoplados y un muy muy mal escalado a partir de la docena de procesadores.
Las palabras de Moshe se pueden malentender porque el nicho de OpenMosix ha sido aplastado por debajo (pocos núcleos) y por arriba (centenares o miles de núcleos). Los procesadores multicore cada vez son más baratos con los que montar un cluster OpenMosix no es razonable. En grandes clusters beowulf OpenMosix escala tan mal que no merece la pena ni intentarlo.
La tendencia en el mundo de la programación científica intensiva sigue siendo MPI. No veo mucho PVM porque el coste de desarrollar el software es parecido y se consigue mejor rendimiento con MPI. De este modo también se utilizan los procesadores multicore, no se lanza un proceso por procesador sino un proceso por núcleo, esto es automático. De este modo se aprovecha el multicore pero hasta cierto punto porque el ancho de banda limitante es el de las comunicaciones entre nodos que es entre uno y dos órdenes de magnitud más lento que el que hay entre núcleos. Lo ideal es programar pensando en nodos y núcleos y tener dos grados de paralelización: uno fino con POSIX o OpenMP y otro grueso con MPI.Al final todo esto termina estando oculto para el usuario gracias a PBLAS, BLACS y SCALAPACK