concurrency - sisd - taxonomia de flynn conclusion

¿Qué desafíos promueven el uso de arquitecturas paralelas/simultáneas?

Question

Estoy muy entusiasmado con la posibilidad de utilizar lenguajes que tengan paralelismo / concurrencia integrados, como stackless y erlang , y tengo la firme creencia de que todos tendremos que movernos en esa dirección antes de que pase demasiado tiempo, o querremos hacerlo porque será una forma buena / fácil de obtener escalabilidad y rendimiento.

Sin embargo, estoy tan acostumbrado a pensar en soluciones de manera lineal / serial / OOP / funcional que estoy luchando para lanzar cualquiera de mis problemas de dominio de una manera que amerita el uso de concurrencia. Sospecho que solo necesito desaprender un montón, pero pensé en preguntar lo siguiente:

• ¿Ha implementado algo razonablemente grande en stackless o erlang u otro?
• ¿Por qué fue una buena elección? ¿Fue una buena elección? ¿Lo harias otra vez?
• ¿Qué características de su problema significaron que concurrente / paralelo era correcto?
• ¿Reformó un problema existente para aprovechar la concurrencia / paralelismo? y
• ¿si es así, cómo?

¿Alguien tiene alguna experiencia que estén dispuestos a compartir?

Answer 1

Antes de que tuviéramos sistemas operativos, las personas que construían aplicaciones se sentaban y discutían cosas como:

• ¿Cómo almacenaremos datos en discos?
• ¿Qué estructura de sistema de archivos usaremos?
• con qué hardware funcionará nuestra aplicación
• etcétera etcétera

Los sistemas operativos surgieron de las colecciones de ''bibliotecas de desarrolladores''.

La belleza de un sistema operativo es que su software UNWRITTEN tiene ciertas características, puede:

• hablar con almacenamiento permanente
• hablar con la red
• ejecutar en una línea de comando
• ser usado en lote
• hablar con una GUI
• etcétera etcétera

Una vez que haya cambiado a un sistema operativo, no volverá al status quo ante ...

Erlang / OTP (es decir, no Erlang) es un sistema de aplicación: se ejecuta en dos o más computadoras.

La belleza de un SISTEMA DE APLICACIÓN es que su software UNWRITTEN tiene ciertas características, puede:

• fallar entre dos máquinas
• trabajar en un clúster
• etcétera etcétera...

Adivina qué, una vez que cambiaste a un Sistema de Aplicación, no regresas ni ...

No tiene que usar Erlang / OTP, Google tiene un buen sistema de aplicación en el motor de su aplicación, así que no se obsesione con la sintaxis del lenguaje.

Puede haber buenas razones comerciales para construir en la pila de Erlang / OTP, no en Google App Engine. Los desarrolladores de biz en su empresa harán esa llamada por usted.

Answer 2

Erlang te hace pensar en el problema en paralelo. No lo olvidarás un segundo. Después de un tiempo te adaptas. No es un gran problema. Excepto que la solución se vuelve paralela en cada pequeño rincón. Todos los otros idiomas que tiene que modificar. Para ser concurrente. Y eso no se siente natural. Entonces terminas odiando tu solución. No es divertido.

Las mayores ventajas que tiene Erlang es que no tiene recolección de basura global. Nunca tomará un descanso. Eso es algo importante, cuando tienes 10000 páginas vistas por segundo.

Answer 3

Los problemas permanecerán casi igual en el futuro, pero el hardware subyacente para la realización está cambiando. Para usar esto, la forma de compunicación entre los objetos (componentes, procesos, servicios, como quiera que la llame) cambiará. Los mensajes se enviarán de forma asíncrona sin esperar una respuesta directa. En cambio, después de que se realiza un trabajo, el proceso llamará al remitente con la respuesta. Es como personas trabajando juntas.

Actualmente estoy diseñando una arquitectura impulsada por eventos de peso ligero basada en Erlang / OTP. Se llama Tideland EAS. Estoy describiendo las ideas y principios aquí: http://code.google.com/p/tideland-eas/wiki/IdeasAndPrinciples . No está listo, pero tal vez entiendas lo que quiero decir.

mue

Answer 4

en el pasado, cuando las máquinas de escritorio tenían una sola CPU, la paralelización solo se aplicaba al hardware paralelo "especial". Pero en la actualidad los equipos de sobremesa tienen generalmente de 2 a 8 núcleos, por lo que ahora el hardware paralelo es el estándar. Esa es una gran diferencia y, por lo tanto, no solo se trata de qué problemas sugieren el paralelismo, sino también de cómo aplicar el paralelismo a un conjunto más amplio de problemas que antes.

Para poder aprovechar el paralelismo, generalmente necesita volver a plantear su problema de alguna manera. El paralelismo cambia el patio de recreo de muchas maneras:

• Obtienes la coherencia de los datos y los problemas de bloqueo. Por lo tanto, debe tratar de organizar su problema para que tenga estructuras de datos semiindependientes que puedan manejarse mediante diferentes subprocesos, procesos y nodos de cómputo.
• El paralelismo también puede introducir el no determinismo en su cálculo, si el orden relativo en el que los componentes paralelos hacen su trabajo afecta los resultados. Es posible que deba protegerse contra eso y defina una versión paralela de su algoritmo que sea sólida frente a diferentes órdenes de programación.
• Cuando trasciende el paralelismo dentro de la motherboard y entra en la computación en red / clúster / grid, también obtiene los problemas de ancho de banda de la red, bajando la red y la administración adecuada de los nodos computacionales defectuosos . Es posible que necesite modificar su problema para que sea más fácil manejar las situaciones en las que parte de la computación se pierde cuando un nodo de la red deja de funcionar.