Desempenho F # vs desempenho Erlang, há provas de que a VM do Erlang é mais rápida?

Venho dedicando tempo ao aprendizado da programação funcional e cheguei à parte em que quero começar a escrever um projeto, em vez de apenas me dedicar a tutoriais / exemplos.

Ao fazer minha pesquisa, descobri que Erlang parece ser bastante poderoso quando se trata de escrever software simultâneo (que é o meu objetivo), mas os recursos e ferramentas de desenvolvimento não são tão maduros quanto os produtos de desenvolvimento da Microsoft.

O F # pode ser executado no Linux (Mono) para que o requisito seja atendido, mas, enquanto procurava na Internet, não encontro comparações de F # vs Erlang. No momento, estou inclinado a Erlang apenas porque parece ter o maior número de publicações, mas estou curioso para saber se há realmente alguma diferença de desempenho entre os dois sistemas.

Como estou acostumado a desenvolver no .NET, provavelmente consigo acelerar o F # muito mais rápido que o Erlang, mas não consigo encontrar nenhum recurso para me convencer de que o F # é tão escalável quanto o Erlang.

Estou mais interessado em simulação, que disparará muitas mensagens processadas rapidamente para nós persistentes.

Se não fiz um bom trabalho com o que estou tentando perguntar, peça mais verificação.

f# erlang

— afuzzyllama
fonte

Os idiomas não têm velocidade. Implementações específicas de idiomas que executam um programa específico em uma entrada específica (isso pode incluir todo o mundo externo, dependendo do programa) têm velocidade.

O F # é executado no tempo de execução do .NET e o Erlang é executado em sua própria VM. Os processos de Erlang são considerados leves e linguagens que estão em seu domínio (como Scala). Para uma simulação que gera nós e passa muitas mensagens, o .NET / Mono runtime é tão bom quanto a VM de Erlang ou a VM de Erlang é superior?

— precisa saber é o seguinte

@ delnan: Os idiomas têm características de desempenho.

— Jon Harrop

@JonHarrop Como assim? Uma linguagem de programação é apenas alguma sintaxe e semântica associada.

@ delnan: A semântica impõe limitações à otimização. Por exemplo, linguagens de tipo dinâmico são proibitivamente difíceis de otimizar na prática. A falta de tipos de valor na JVM resulta em muito mais alocação de heap do que no .NET e, consequentemente, muito mais estresse no GC. Como os geradores de código, os coletores de lixo podem explorar e exploram informações como imutabilidade, a fim de melhorar o desempenho. O design de uma linguagem de programação tem um efeito enorme nisso.

— Jon Harrop

Respostas:

O que você quer dizer com "viável"? "Ter o máximo de imprensa" não é necessariamente a melhor maneira de escolher um idioma.

A reivindicação de Erlang à fama é sua capacidade de paralelização maciça. É por isso que é comumente usado nos comutadores de telefone da Ericsson. O Erlang é em tempo real suave, para que você possa garantir certas garantias de desempenho.

O F # se beneficia dos recursos de otimização do .NET Jitter. Além disso, a própria linguagem foi projetada para ser uma linguagem funcional de alto desempenho (sendo uma variante do OCaml, amplamente usada no setor financeiro devido à sua velocidade).

Por fim, a menos que você planeje executar milhões de agentes minúsculos ao mesmo tempo (que é para isso que Erlang é otimizado), o F # deve estar à altura da tarefa.

Esta página explica os casos de uso apropriados para Erlang.

— Robert Harvey
fonte

Por "viável", quis dizer escalável. Eu sei que ter imprensa não significa que esse idioma seja necessariamente melhor, mas parece que Erlang foi provado (pelo menos pela Ericsson). O que você quer dizer com agentes? Processos?

— precisa saber é o seguinte

Sim. Foi comprovado que Erlang lida com muitas chamadas telefônicas em um switch Ericsson ao mesmo tempo. Você precisa descobrir se o seu caso de uso é semelhante. Eu vejo isso como um caso de uso relativamente especializado; se essa característica estiver ausente no seu aplicativo, não vejo vantagem em usar o Erlang, e a página Erlang na verdade descreve alguns casos de uso para os quais o Erlang não é adequado.

— Robert Harvey

Agentes, atores, é um conceito de design que surge muito nas discussões de linguagem funcional; Estou surpreso que você ainda não o tenha encontrado. en.wikipedia.org/wiki/Agent-based_model

— Patrick Hughes

Em outras palavras, você precisa de escalabilidade massiva (agora ou eventualmente) do tipo que Erlang fornece? A maioria dos programas não.

— Robert Harvey

O F # também possui o modelo do agente - usando o 'MailboxProcessor' com o nome um tanto criptografado , que é o mesmo tipo de coisa que em Erlang. Não posso comentar sobre as características de desempenho relativo de cada um.

— FinnNk

Poucas declarações objetivas podem ser feitas sobre esse assunto, porque o desempenho dessas duas linguagens depende fortemente do estilo de aplicação e programação.

O único conselho que posso dar é que o F # tem a vantagem de desempenho de um sistema de tipo estático e o CLR faz um bom trabalho ao aproveitar isso para melhorar o desempenho. O F # possui agentes assíncronos e passagem de mensagens, mas não foi otimizado e o código síncrono geralmente é 10 vezes mais rápido.

O Erlang é digitado dinamicamente, o que coloca em desvantagem significativa em termos de desempenho (espera-se muito mais boxe), mas foi construído desde o início para oferecer suporte à passagem rápida de mensagens entre agentes assíncronos, de modo que pode ser muito mais rápido que o equivalente F # . No entanto, não tenho resultados de referência para apoiar isso: é apenas a minha expectativa.

Além disso, tanto o Erlang quanto o F # são idiomas relativamente periféricos em pequenas comunidades e, devido aos seus diferentes mercados-alvo, pessoas familiarizadas com ambos são raras. A única pessoa em que consigo pensar que quase se qualifica é Jesper Louis Andersen, mas não sei ao certo quanto F # ele fez.

— Jon Harrop
fonte

Você deve ler este post de Joe Armstrong: http://erlang.org/pipermail/erlang-questions/2012-February/064277.html

O resumo é que Erlang não foi projetado para ser rápido! É razoavelmente rápido em muitos casos, mas isso é secundário a problemas como tolerância a falhas e estabilidade.

A verdade é que Erlang e F # são linguagens agradáveis, e enquanto eu apenas dei uma olhada rápida no F #, escrevi um livro sobre Erlang: Criando aplicativos da Web com Erlang e posso dizer que é uma linguagem divertida para se trabalhar.

Eu também apontaria que parece haver um boom nos livros de idiomas funcionais a serem publicados nos próximos 6-9 meses. Conheço pelo menos quatro em Erlang (incluindo o meu), um em Haskell e títulos em OCaml, Clojure e F #.

— Zachary K
fonte