Rendimiento de F # vs rendimiento de Erlang, ¿hay pruebas de que la VM de Erlang es más rápida?


19

He estado dedicando tiempo al aprendizaje de la programación funcional y he llegado al punto en el que quiero comenzar a escribir un proyecto en lugar de solo incursionar en tutoriales / ejemplos.

Mientras investigaba, descubrí que Erlang parece ser bastante poderoso cuando se trata de escribir software concurrente (que es mi objetivo), pero los recursos y las herramientas para el desarrollo no son tan maduros como los productos de desarrollo de Microsoft.

F # puede ejecutarse en Linux (Mono) para cumplir con ese requisito, pero mientras busco en Internet no puedo encontrar ninguna comparación entre F # y Erlang. En este momento, me estoy inclinando hacia Erlang solo porque parece tener más presión, pero tengo curiosidad por saber si realmente hay alguna diferencia de rendimiento entre los dos sistemas.

Como estoy acostumbrado a desarrollar en .NET, probablemente pueda ponerme al día con F # mucho más rápido que Erlang, pero no puedo encontrar ningún recurso que me convenza de que F # es tan escalable como Erlang.

Estoy más interesado en la simulación, que va a disparar muchos mensajes procesados ​​rápidamente a nodos persistentes.

Si no he hecho un buen trabajo con lo que estoy tratando de pedir, solicite más verificación.


12
Los idiomas no tienen velocidad. Las implementaciones de lenguaje específicas que ejecutan un programa específico en una entrada específica (esto puede incluir todo el mundo exterior, dependiendo del programa) tienen una velocidad.

1
F # se ejecuta en el tiempo de ejecución .NET y Erlang se ejecuta en su propia máquina virtual. Los procesos de Erlang se consideran ligeros frente a los idiomas que están en su dominio (como Scala). Para una simulación que genera nodos y pasa muchos mensajes, ¿el tiempo de ejecución de .NET / Mono es tan bueno como la VM de Erlang o la VM de Erlang es superior?
afuzzyllama

3
@delnan: los idiomas tienen características de rendimiento.
Jon Harrop

2
@ JonHarrop ¿Cómo es eso? Un lenguaje de programación es simplemente una sintaxis y una semántica asociada.

1
@delnan: la semántica impone limitaciones a la optimización. Por ejemplo, los lenguajes de tipo dinámico son prohibitivamente difíciles de optimizar en la práctica. La falta de tipos de valor en la JVM da como resultado mucha más asignación de almacenamiento dinámico que en .NET y, en consecuencia, un estrés mucho mayor en el GC. Al igual que los generadores de código, los recolectores de basura pueden y explotan información como la inmutabilidad para mejorar el rendimiento. El diseño de un lenguaje de programación tiene un gran efecto en esto.
Jon Harrop

Respuestas:


21

¿Qué quieres decir con "viable"? "Tener la mayor cantidad de prensa" no es necesariamente la mejor manera de elegir un idioma.

La afirmación de Erlang de fama es su capacidad de paralelización masiva. Es por eso que se usa comúnmente en los conmutadores telefónicos Ericsson. Erlang es suave en tiempo real, por lo que puede hacer ciertas garantías de rendimiento al respecto.

F # se beneficia de las capacidades de optimización de .NET Jitter. Además, el lenguaje en sí está diseñado para ser un lenguaje funcional de alto rendimiento (siendo una variante de OCaml, ampliamente utilizado en la industria financiera debido a su velocidad).

En última instancia, a menos que planee ejecutar millones de agentes pequeños al mismo tiempo (que es para lo que Erlang está optimizado), F # debería estar a la altura de la tarea.

Esta página explica los casos de uso apropiados para Erlang.


Por "viable" me refería a escalable. Sé que tener prensa no significa que ese idioma sea necesariamente mejor, pero parece que Erlang ha sido probado (al menos por Ericsson). ¿Qué quieres decir con agentes? Procesos?
afuzzyllama

1
Si. Se ha demostrado que Erlang maneja muchas llamadas telefónicas en un conmutador Ericsson al mismo tiempo. Tienes que averiguar si tu caso de uso es similar. Veo eso como un caso de uso relativamente especializado; si esta característica está ausente en su aplicación, no veo ninguna ventaja en usar Erlang, y la página de Erlang en realidad describe algunos casos de uso para los cuales Erlang no es adecuado.
Robert Harvey

2
Agentes, actores, es un concepto de diseño que surge mucho en las discusiones de lenguaje funcional; Me sorprende que aún no lo hayas encontrado. en.wikipedia.org/wiki/Agent-based_model
Patrick Hughes

En otras palabras, ¿necesita una escalabilidad masiva (ahora o eventualmente) del tipo que proporciona Erlang? La mayoría de los programas no lo hacen.
Robert Harvey

1
F # también tiene el modelo de agente, que usa el 'MailboxProcessor', un poco críptico , que es el mismo tipo de cosas que en Erlang. Sin embargo, no puedo comentar sobre las características de rendimiento relativo de cada uno.
FinnNk

7

Se pueden hacer pocas declaraciones objetivas sobre este tema porque el rendimiento de estos dos idiomas depende en gran medida de la aplicación y el estilo de programación.

El único consejo que puedo dar es que F # tiene la ventaja de rendimiento de un sistema de tipo estático y el CLR hace un buen trabajo aprovechando esto para mejorar el rendimiento. F # tiene agentes asíncronos y mensajes que pasan, pero no se ha optimizado y el código síncrono suele ser más de 10 veces más rápido.

Erlang se escribe dinámicamente, lo que lo pone en una desventaja significativa en términos de rendimiento (se espera mucho más boxeo), pero se creó desde cero para admitir el paso rápido de mensajes entre agentes asincrónicos, por lo que puede ser mucho más rápido que el equivalente F # . Sin embargo, no tengo resultados de referencia para respaldar esto: es solo mi expectativa.

Por otro lado, tanto Erlang como F # son idiomas relativamente marginales con pequeñas comunidades y, debido a sus diferentes mercados objetivo, las personas familiarizadas con ambos son raros. La única persona en la que puedo pensar que casi califica es Jesper Louis Andersen, pero no estoy seguro de cuánto F # ha hecho.


4

Debería leer esta publicación de Joe Armstrong: http://erlang.org/pipermail/erlang-questions/2012-February/064277.html

En resumen, ¡Erlang no fue diseñado para ser rápido! Es razonablemente rápido en muchos casos, pero eso es secundario a problemas como la tolerancia a fallos y la estabilidad.

La verdad es que tanto Erlang como F # son buenos idiomas, y aunque solo he echado un vistazo rápido a F #, he escrito un libro sobre Erlang: Creación de aplicaciones web con Erlang y puedo decir que es un lenguaje divertido para trabajar.

También quisiera señalar que parece haber un auge en los libros de idiomas funcionales que se publicarán en los próximos 6 a 9 meses. Sé de al menos 4 en Erlang (incluido el mío), Uno en Haskell, así como Títulos en OCaml, Clojure y F #.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.