Computación distribuida vs hilos

Question

¿Qué tan similar es la computación distribuida y los hilos? He encontrado dos artículos que llegan a conclusiones bastante opuestas:

" Multi-Threading es más fácil que las redes. Cómo el enhebrado es fácil y similar al código de red "

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

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

" Una nota sobre computación distribuida "

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

(y esto pone una fuerte distinción)

Estoy seguro de que la verdad está en algún punto intermedio. ¿Qué significa el dorado? ¿Hay alguna tecnología que unifique esos dos paradigmas? ¿O han fallado tales intentos debido a diferencias fundamentales entre la red 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. Por lo tanto, una máquina de cuatro núcleos tiene cuatro nodos, al igual que un grupo de cuatro cajas de un solo procesador.

Normalmente, cada nodo ejecutará algún procesamiento y deberá haber algún tipo de comunicación entre nodos. Por lo general, la primera instancia de esta comunicación es decirle al nodo qué hacer. Para esta comunicación, puedo usar memoria compartida, semáforos, archivos compartidos, canalizaciones con nombre, zócalos, llamadas a procedimientos remotos, COM distribuido, etc. Pero los más fáciles de usar, memoria compartida y semáforos, generalmente no están disponibles en una red. Los archivos compartidos pueden estar disponibles, pero el rendimiento suele ser deficiente. Los sockets tienden a ser la opción más común y más flexible en una red, en lugar de los mecanismos más sofisticados. En ese punto, debe lidiar con 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 de la misma máquina pueden usar una memoria compartida simple para hacer cosas. Incluso puede escribirlo sin bloqueo y funcionará sin problemas. Con los nodos en una red, ¿dónde pones la cola? Si lo centraliza, esa máquina puede sufrir costos de ancho de banda muy altos. Intente distribuirlo y las cosas se complicarán muy rápidamente.

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

Ahora, si va a escribir hilos que se comporten de manera idéntica a un sistema distribuido, utilizando un mensaje puro que pase y no suponiendo que ningún hilo sea el "principal". uno y tal, entonces sí, van a ser muy similares. Pero lo que ha hecho es que tiene una arquitectura distribuida y la implementó en subprocesos. La cuestión es que el enhebrado es un caso de paralelismo mucho más simple que la verdadera computación distribuida. Puede abstraer los dos en un solo problema, pero eligiendo la versión más difícil y manteniéndose estrictamente en ella. Y los resultados no serán tan buenos como podrían ser cuando todos los nodos sean locales a una máquina. No estás aprovechando el caso especial.

Answer 2

La distribución de la informática 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 un acceso rápido y aleatorio a todo el conjunto de datos son muy difíciles de resolver.

En términos generales, necesita bibliotecas especializadas para resolver problemas informáticos distribuidos que determinan cómo asignar los nodos a los problemas y hacer un carro alrededor de los datos.

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 las máquinas altamente interconectadas, y pueden beneficiarse de las supercomputadoras realmente potentes. Otros problemas pueden tratarse en modelos simplemente distribuidos. En general, los supercomputadores pueden resolver una amplia gama de problemas, pero son mucho más especializados y caros.

Answer 3

La diferencia parece volver al estado de Threads share, Processes pass messages.

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

Es fácil comenzar a compartir el estado, todos los datos y las variables están ahí. Pero una vez que entran las condiciones de puntos muertos / raza, es difícil modificarlo / escalarlo.

El paso de mensajes (por ejemplo, Erlang) requiere un enfoque diferente para el diseño, hay que pensar en las oportunidades de concurrencia desde el principio, pero el estado de cada proceso distribuido está aislado, lo que hace que los problemas de bloqueo / carrera sean más fáciles de tratar.

Answer 4

Creo que es mucho más útil comparar procesos con enfoques de computación distribuida que comparar hilos con ellos. Los hilos existen dentro de un solo proceso y comparten los mismos datos y la misma memoria. Esto no es posible en varias máquinas. Por otro lado, los procesos tienen su propia memoria, aunque en algunos casos contiene exactamente los mismos datos que otro proceso (después de un fork (), 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 a la red. Un buen ejemplo sería los sockets Unix, que utilizan 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 tengo muy clara su idea, avíseme si me equivoco: cuando se habla de computación distribuida, estamos asumiendo que más de una computadora o servidor procesa el código en la misma aplicación, pero cuando hablamos de Multi-Threading, están hablando de procesar diferentes subprocesos 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 desea un ejemplo de subprocesos múltiples, solo piense en una aplicación que intenta encontrar un número primo grande. Si no usa subprocesos múltiples en él, no podrá ver ni hacer nada más en la aplicación en el momento en que esté calculando el siguiente número primo (puede ser de por vida o más) porque la aplicación es no responde mientras trabaja en el cálculo.

También puede combinarlos: como un ejemplo más complejo, siempre puede usar subprocesos múltiples para acceder a diferentes servicios web al mismo tiempo por la misma aplicación, esto es para hacer que su aplicación sea receptiva incluso si no se está 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 subproceso, y tratan de explicarlo encontrando analogías con la computación en red, lo que es un poco extraño y engañoso para mí. No estoy seguro de por qué eligieron esta forma de presentar subprocesos, tal vez se dirigieron a personas familiarizadas con las redes, lo que probablemente sea más conocido o al menos reconocido que el subprocesamiento.

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 sea remoto es perjudicial, 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 una manera eficiente.