programas - que es el lenguaje de programacion erlang
¿Cuál es la diferencia entre la programación multinúcleo en Erlang y otros lenguajes? (5)
Leí la teoría ''Programming Erlang'' de Joe Armstrong y la teoría de ''n times faster on 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 creando un servidor de juego en línea para un MMORPG, por eso estoy interesado en Erlang como un lenguaje de servidor alternativo.
(Ya leí esta pregunta, pero creo que no es la pregunta que estoy buscando).
Bueno, la naturaleza del lenguaje con variables que solo se pueden establecer una vez y el hecho de que es un lenguaje funcional 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, entonces 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.
El cambio de contexto es extremadamente caro. 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.
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 diferentes procesadores (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.
Se trata de hilos versus 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 ejecutando 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 los usuarios con sesión iniciada , razón por la cual 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 puede obtener suficientes procesos porque el sistema operativo no puede manejarlo
cada proceso es costoso porque, por diseño, le da al ''usuario'' toda la potencia del sistema operativo
El problema con los 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 varios aspectos. La tesis doctoral de Joe Armstrong se llama Fabricación de sistemas distribuidos confiables en presencia de errores de software .
Confiabilidad 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 dijo Joe en la primera parte de la primera sección de su tesis doctoral, para tener un software confiable, debe comenzar con dos computadoras. Con Erlang / OTP, al momento de escribir no sabrá 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.
Debido a que Erlang tiene sus propios procesos, tiene su propio programador y su propio formato de cargador de código / binario (Erlang se puede interpretar o puede compilar a binarios nativos). Esto brinda un conjunto de beneficios adicionales: antes de escribir su aplicación Erlang / OTP, puede intercambiar en caliente sus binarios, etc., etc.
Por lo tanto, asegúrese de que puede escribir aplicaciones multiproceso en C ++, pero es su responsabilidad evitar la propagación de errores y la estabilidad del sistema de compilación.
Y seguro, puedes construir 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.
La respuesta de Gordon Guthrie 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.
Para ser breve, en Erlang puede diseñar su programa de forma diferente que en C ++ porque puede hacerlo sin grandes problemas de rendimiento y promete buena escalabilidad y confiabilidad sin grandes esfuerzos. Nadie es perfecto, pero para una gran cantidad de tareas interesantes, Erlang es la mejor opción.
Editar : buena presentación sobre la diferencia entre Erlang y C ++ - Erlang 2.5x mayor rendimiento superior, 3 veces menos latencia y 18 veces menos SLOC - Supongo que los desarrolladores de Motorola tienen experiencia en C ++ suficiente para escribir un buen software.