Informática distribuida frente a subprocesos

Question

¿Qué tan similar es la informática distribuida y el subprocesamiento? He encontrado dos artículos que llegan a conclusiones bastante opuestos:

"Multi-Threading es más fácil que Redes Cómo roscar es fácil y similar a la red de código."

http://software.intel.com/file/14723

(esto me da una impresión que son tan similares que después de la encapsulación estos dos enfoques se podría hacer con el mismo código - pero tal vez me equivoque)

"Una nota sobre la computación distribuida"

http://research.sun.com/techrep/1994/abstract-29.html

(y esto pone una distinción fuerte)

Estoy seguro de que la verdad está en algún lugar en el medio. ¿Cuál es el significado dorado? ¿Hay alguna tecnología que unifique esos dos paradigmas? ¿O han fracasado esos intentos debido a las diferencias fundamentales entre las redes y la concurrencia?

Answer 1

Nunca he encontrado que sean muy similares. Permítanme definir a los efectos de esta publicación un "nodo" para ser un hilo de hardware que se ejecuta en una máquina. Entonces, una máquina de cuatro núcleos tiene cuatro nodos, al igual que un grupo de cuatro cajas de un solo procesador.

Cada nodo normalmente ejecutará algún procesamiento, y será necesario que haya algún tipo de comunicación entre nodos. Por lo general, la primera instancia de esta comunicación le dice al nodo qué hacer. Para esta comunicación, puedo usar memoria compartida, semáforos, archivos compartidos, canalizaciones con nombre, sockets, llamadas a procedimientos remotos, COM distribuido, etc. Pero los más fáciles de usar, memoria compartida y semáforos, no suelen estar disponibles en una red. Los archivos compartidos pueden estar disponibles, pero el rendimiento es generalmente pobre. Los zócalos tienden a ser la opción más común y más flexible sobre una red, en lugar de los mecanismos más sofisticados. En ese punto, debe tratar los detalles de la arquitectura de red, incluida la latencia, el ancho de banda, la pérdida de paquetes, la topología de red y más.

Si comienza con una cola de trabajo, los nodos en la misma máquina pueden usar memoria compartida simple para hacer cosas. Incluso puedes escribirlo sin cerrojo y funcionará perfectamente. Con nodos en una red, ¿dónde colocas la cola? Si lo centraliza, esa máquina puede sufrir costos muy altos de ancho de banda. Intenta distribuirlo y las cosas se complican muy rápido.

Lo que he encontrado, en general, es que las personas que abordan este tipo de arquitectura paralela tienden a elegir problemas embarazosamente paralelos para resolver. Raytracing viene a la mente. No se requiere mucha comunicación entre nodos, aparte de la distribución de trabajos. Hay muchos problemas como este, sin duda, pero me parece un poco falso sugerir que la informática distribuida es esencialmente lo mismo que enhebrar.

Ahora, si va a escribir un subprocesamiento que se comporta de forma idéntica a un sistema distribuido, utilizando pasar mensajes puros y no asumir que ningún hilo sea el "principal" y tal, entonces sí, van a estar muy similar. Pero lo que ha hecho es fingir que tiene una arquitectura distribuida y lo implementó en hilos. La cuestión es que el enhebrado es un caso de paralelismo mucho más simple que la verdadera computación distribuida. Puede resumir los dos en un solo problema, pero eligiendo la versión más difícil y apegándose estrictamente a ella. Y los resultados no serán tan buenos como podrían ser cuando todos los nodos son locales para una máquina. No estás aprovechando el caso especial.

Answer 2

La computación de distribución se realiza en múltiples máquinas independientes diferentes, generalmente con sistemas operativos a veces especializados. Es más difícil porque la interconexión de las máquinas es mucho menor y, por lo tanto, los problemas que requieren mucho acceso rápido y aleatorio a todo el conjunto de datos son muy difíciles de resolver.

En general, necesita bibliotecas especializadas para hacer problemas de computación distribuida que determinan cómo asignar nodos a los problemas y realizar un seguimiento de los mismos.

Realmente me pregunto si están llegando a conclusiones diferentes porque están tratando de resolver los problemas incorrectos en cada plataforma. Algunos problemas se adhieren muy bien a máquinas altamente interconectadas, y pueden beneficiarse de supercomputadoras realmente potentes. Otros problemas pueden tratarse en modelos simplemente distribuidos. En general, las supercomputadoras pueden resolver una gama más amplia de problemas, pero son mucho, mucho más especializadas y costosas.

Answer 3

La diferencia parece volver al estado de compartir subprocesos, los mensajes de paso de procesos.

Debe decidir cómo desea mantener el estado en su aplicación antes de elegir una.

Compartir estado es fácil de empezar, todos los datos y variables están ahí. Pero una vez que las condiciones de bloqueo/carrera entran, es difícil modificar/escalar.

Paso de mensajes (por ejemplo Erlang) requiere un enfoque diferente para el diseño, usted tiene que pensar sobre las oportunidades de concurrencia desde el principio, pero está aislado estado de cada proceso distribuido, por lo que los problemas de bloqueo/carrera más fácil de tratar.

Answer 4

Creo que es mucho más útil comparar procesos con enfoques de computación distribuida que comparar los hilos con él. Threads existe dentro de un proceso único y comparte los mismos datos y la misma memoria. Esto no es posible en varias máquinas. Los procesos, por otro lado, tienen su propia memoria, aunque en algunos casos contiene exactamente los mismos datos que otro proceso (después de un tenedor(), por ejemplo). Esto podría lograrse a través de una red.

Algo que agrega peso adicional a esta analogía es el hecho de que muchas herramientas utilizadas para la comunicación entre procesos son transparentes en la red. Un buen ejemplo serían los sockets de Unix, que usa la misma interfaz que los sockets de red (excepto el código de conexión).

Answer 5

Sí, en el momento del desarrollo, el enfoque es muy similar, pero el uso de cada uno es muy diferente. No entiendo muy bien tu idea, avísame si estoy equivocado: cuando hablamos de informática distribuida asumimos que hay más de un código de procesamiento de computadora o servidor en la misma aplicación, pero cuando hablamos de Multi-Threading, estamos hablando de procesar diferentes hilos de la aplicación al mismo tiempo en la misma computadora. Puede pensar como un ejemplo de computación distribuida, en una aplicación que accede a un servicio web ubicado en Internet. Hay dos computadoras diferentes trabajando en la misma aplicación.

Si quieres un ejemplo de multi-threading, solo piensa en una aplicación que intente encontrar un gran número primo. Si no usa multi-threading en él, no podrá ver ni hacer nada más en la aplicación en el momento en que calcula el próximo número primo (puede ser una vida útil o más) porque la aplicación no responde mientras está trabajando en el cálculo.

Puede mezclarlos también: como un ejemplo más complejo, siempre puede usar multi-threading para acceder a diferentes servicios web al mismo tiempo por la misma aplicación, esto es para hacer que su aplicación responda aunque no sea conectando cuando uno de los servidores.

Answer 6

Creo que esos dos documentos no se pueden comparar fácilmente.El documento de Intel es una especie de introducción al enhebrado, y tratan de explicarlo mediante la búsqueda de analogías en la informática en red, lo cual es un tanto extraño y engañoso para mí. No estoy seguro de por qué eligieron esta manera de presentar el hilo, tal vez apuntaban a personas familiarizadas con la creación de redes, que probablemente sea más conocida o al menos reconocida que el enhebrado.

El documento de Sun, por otro lado, es un artículo serio que describe todas las dificultades relacionadas con la programación distribuida. Todo lo que puedo hacer es simplemente confirmar lo que dicen allí.

En mi opinión, una abstracción que intenta ocultar el hecho de que un objeto es remoto es dañino ya que generalmente conduce a un rendimiento muy malo. El programador debe ser consciente de la lejanía de un objeto para poder invocarlo de manera eficiente.