¿Cuál es la diferencia entre la programación multinúcleo en Erlang y en otro idioma?

Question

Leí el 'Programming Erlang' de Joe Armstrong, y la teoría de "n veces más rápido en n core machine". La forma eficiente de programar multicore en Erlang es usar muchos procesos (hilos).

Soy un programador de C++, por lo que tengo curiosidad sobre la diferencia entre hacer muchos subprocesos en C++ y hacer muchos procesos en Erlang. Entiendo que tratar con hilos en C/C++ no es tan fácil. También sé que bloquear/desbloquear hace que el sistema disminuya la velocidad. Pero no es imposible, ¿verdad?

Entonces ... ¿por qué Erlang es un lenguaje amistoso muticore? ¿Es solo porque es fácil de programar?

Estoy haciendo un servidor de juegos en línea para un MMORPG, es por eso que estoy interesado en Erlang como un lenguaje de servidor alternativo.

(yo ya leí this pregunta, pero yo creo que no es la pregunta que yo estoy buscando.)

Answer 1

No, no es imposible, pero Erlang lo hace mucho más fácil. La clave no es compartir estado entre los procesos. Erlang logra esto en virtud de ser un lenguaje funcional. La función no debería tener efectos secundarios ni debería tener acceso a ningún estado variable (aparte de los argumentos pasados ​​en la pila). Con estas propiedades, el cálculo de cualquier función en el sistema se puede mover a otro procesador con un espacio de memoria separado y Erlang lo hará por usted. Erlang solo necesita replicar los argumentos a la función y los resultados entre los espacios de memoria (nota: esto no sería adecuado para todo tipo de aplicaciones ... una función que necesitaba operar en un cuerpo muy grande de estado de entrada podría presentar un rendimiento) problemas al replicar ese estado).

Un uso ingenuo de subprocesos en una aplicación C++ podría tener procesadores diferentes (en un sistema de varios núcleos) intentando acceder a la misma memoria compartida al mismo tiempo. Luego, el sistema debe trabajar mucho para asegurarse de que los cachés locales asociados con cada núcleo permanezcan consistentes. Aquí es donde puedes sufrir grandes éxitos de rendimiento. Tenemos una aplicación en el trabajo que se degrada en rendimiento cuando tiene más de un par de núcleos por esta misma razón. De hecho, iría tan lejos como para decir que sería mejor que diseñara sus aplicaciones para usar solo subprocesos donde necesita hacer E/S asincrónicas, pero donde necesita tener procesos que realicen un trabajo real y no bloqueados para E/S, use procesos completos. Al utilizar procesos completos, se garantiza que cada proceso tenga su propio espacio de memoria y que no haya dos subprocesos que usen la misma memoria al mismo tiempo (por supuesto, debe encontrar un buen medio de comunicación entre esos procesos). Con un sistema como este y una disciplina en torno a la administración del procesamiento de distribución y estado, podría obtener resultados similares a lo que proporciona Erlang, pero debe hacer muchas cosas de infraestructura que Erlang ya hace por usted.

Answer 2

Bueno, la naturaleza de la lengua con las variables que sólo se puede establecer una vez y el hecho de que es un funcional el lenguaje automáticamente hace que los programas con mucho paralelismo se escriban y ejecuten "de la manera correcta" para multinúcleo.

No sé mucho sobre erlang además de esos dos hechos, por lo que podría haber algo más también. Pero eso no quiere decir que no pueda hacer que un programa C++ sea escalable, pero es probable que tenga que pasar por mucho para lograr el rendimiento, la escalabilidad y la estabilidad, que no tendrá costo si escribe en erlang.

Answer 3

El cambio de contexto es extremadamente costoso. No hay ninguno en Erlang. Locks hace que los programas tradicionales comiencen a pensar qué subproceso se ejecutará a continuación. Eso también es extremadamente caro.

Answer 4

Todo se reduce a hilos frente a procesos .

Los sistemas operativos se diseñaron específicamente para que cada "usuario" pensara que tenían toda la computadora para ellos solos, por lo que ejecuta apache como usuario wwwrun por ejemplo.

Los programadores, al ser programadores, comenzaron a sobrecargar ese paradigma, primero por cada usuario humano que ejecutaba múltiples 'trabajos'. Debido a que los sistemas operativos fueron diseñados para múltiples usuarios, el límite de escala superior de esa arquitectura reflejaba el límite de escala superior para usuarios registrados - por lo que apache, por ejemplo, comenzará a morir entre 4.000 y 8.000 usuarios.

Los procesos son un paradigma maduro (mi proceso no puede bloquear el suyo). Sin embargo, cuando comenzamos a ver la introducción de los hilos, las cosas empiezan a ser muy diferentes. Aquí tenemos programas que tienen actividades externas de bloqueo (esperar en el disco, esperar en io, esperar en la memoria) querer esperar por un lado, y trabajar en el otro y los hilos le permiten hacer esto y superar dos problemas:

• no se puede conseguir suficientes procesos debido a que el sistema operativo no puede manejarlo

• cada proceso es caro, ya que, por diseño, le da al 'usuario' toda la potencia del sistema operativo

El problema con hilos es que rompen la separación para la que se diseñaron los procesos. Mi hilo puede trash su hilo - los errores se propagan.

Donde Erlang es diferente es en una serie de aspectos. El PhD Thesis de Joe Armstrong se llama Fabricación de sistemas distribuidos fiables en presencia de errores de software.

La fiabilidad significa que los procesos son mejores que los hilos. El problema es que los procesos de los sistemas operativos son demasiado 'caros' porque están diseñados para humanos (usted es dueño de la máquina) y no como unidades de programas concurrentes. En la máquina virtual de Erlang, la máquina virtual tiene toda la potencia de un sistema multiusuario (se ejecuta en un proceso de sistema operativo) y cada proceso de Erlang tiene una cantidad de potencia concurrente mucho más pequeña: si quiere usar la "máquina grande", habla con la VM que lo hace por eso. Por lo tanto, los procesos de Erlang son mucho más baratos que los procesos operativos (y los hilos). Tu solo engendras, engendras, engendras. Las VM de Erlang comienzan de fábrica con 2 ** 8 procesos, pero puedes subir eso a millones (si tienes suficiente RAM).

Además, como Joe lo puso en la primera parte de la primera sección de su tesis de doctorado, para tener un software confiable, debe comenzar con dos computadoras. Con Erlang/OTP, al escribir el tiempo no sabe en qué computadora se ejecutará su software. El clúster Erlang/OTP, en tiempo de ejecución, asignará su trabajo computacional. Por lo tanto, un proceso de Erlang se distribuye de forma nativa, como spawn() (Erlang for fork()) y reinicia la semántica.

Como Erlang tiene sus propios procesos, tiene su propio programador y su propio formato de cargador de código/binario (Erlang puede interpretarse o puede compilarse en binarios nativos).Esto brinda un conjunto de beneficios adicionales: antes de escribir su aplicación Erlang/OTP, puede intercambiar en caliente sus binarios, etc.

Así que, seguro que puede escribir aplicaciones multiproceso en C++, pero es su responsabilidad de prevenir la propagación de errores y construir la estabilidad del sistema.

Y seguro, puedes construir un software confiable en C - mira a Erlang (la VM está escrita en C) el punto es ¿por qué querrías? En los viejos tiempos, las compañías escribían sus propios 'sistemas operativos', ahora puedes escribir tu propio sistema operativo, pero ¿por qué querrías? Hay millones de líneas de código robusto probado que 'lo hace', al igual que hay 1,5 millones de líneas de código robusto probado en el sistema Erlang/OTP que 'lo hace'.

El uso de Erlang se trata de usar las cosas que otras personas han escrito y construir solo los bits que hacen que su empresa sea efectiva.

Answer 5

Gordon Guthrieanswer es genial. ¿Dónde está la diferencia más grande es la preferencia personal? Desde mi punto de vista, la mayor diferencia en Erlang es la confiabilidad y la escalabilidad fortuita. En Erlang puede diseñar procesos concurrentes de manera natural sin grandes problemas de rendimiento y esto será fortuito, escalable y distribuible. Hay errores en los mensajes grandes, pero en la mayoría de los casos su diseño será elegante y funciona bien sin un cuidado especial. Cuando su diseño es elegante comete menos errores, será mejor manejable y, de paso, puede distribuir y escalar con un mínimo esfuerzo y el resultado será confiable.

En resumen, en Erlang puede diseñar su programa de forma diferente que en C++ porque puede hacerlo sin grandes problemas de rendimiento y promete una buena escalabilidad y fiabilidad sin grandes esfuerzos. Nadie es perfecto, pero para una gran cantidad de tareas interesantes, Erlang es la mejor opción.

Editar: Nice presentation sobre la diferencia entre Erlang y C++ - Erlang 2,5 veces mayor rendimiento superior, 3x menos latencia y 18x menos SLOC - Asumo que los desarrolladores de Motorola tienen experiencia en C++ suficiente para escribir un buen software.