Linguagem Funcional Mais Rápida


18

Recentemente, estive pesquisando sobre programação funcional, especialmente Haskell e F #, quanto mais antes. Depois de pesquisar no Google, não consegui encontrar uma comparação de benchmark das linguagens funcionais mais importantes (Scala, F # etc).

Sei que não é necessariamente justo para algumas das línguas (Scala me vem à mente), uma vez que são híbridos, mas só quero saber qual é o melhor desempenho em quais operações e em geral.


18
Os idiomas não são rápidos ou lentos, as implementações são.
Starblue

6
As implementações de idioma não são rápidas ou lentas, os programas executados usando essas implementações de idioma são (quando comparados a alguns outros programas). Seja caridoso - quando alguém fala que uma linguagem de programação é mais rápida que outra, a maneira óbvia que faz sentido é entender que eles estão falando sobre programas específicos executados usando implementações de linguagem específicas.
Igouy

3
@ starblue: Essa é uma resposta muito simples, e não muito útil. Embora seja certamente possível criar duas implementações da mesma linguagem, uma das quais é mais lenta que a outra, a maneira como você coloca isso implica que não existem detalhes de design da linguagem que necessariamente exijam certas ineficiências na implementação dessas outras linguagens, por suas design, não requer. E isso simplesmente não é verdade. (Especialmente neste tópico particular;! Linguagens funcionais são notórias para eles)
Mason Wheeler

3
@igouy "As implementações de idiomas não são rápidas ou lentas" Isso não é verdade. CPythonvs PyPyrapidamente vem à mente.
N

@NlightNFotis - Quantos segundos o CPython leva? Quantos segundos o PyPy leva? As implementações de idiomas não são rápidas ou lentas. Quantos segundos esse programa leva com o CPython?
igouy

Respostas:


25

De acordo com o Great Benchmarks Game , o ATS é mais rápido que o resto, com Haskell, Scala e uma das variantes do Common Lisp, em um empate brusco por velocidade logo atrás disso. Depois disso, Ocaml e F # estão aproximadamente na mesma categoria de velocidade, com Racket e Clojure ficando para trás ...

No entanto, quase nada disso significa realmente nada. É tudo uma questão de problema, máquina, compilador, técnicas de codificação e, em alguns casos, pura sorte. De um modo geral, linguagens codificadas diretamente por máquina, como Haskell, superam as linguagens compiladas da VM como F # e superam amplamente as linguagens puramente interpretadas. De maneira geral, as linguagens tipicamente estáticas são mais rápidas que as dinamicamente, devido à análise estática, permitindo que todas as operações de tipo sejam calculadas na compilação em vez de no tempo de execução. Novamente, estas são regras gerais, sempre haverá exceções. "Paradigmas" têm pouco a ver com isso.


Sei que há muitos fatores a serem levados em consideração e, mesmo que todas as coisas fossem perfeitas, elas poderiam ter um desempenho diferente em dados diferentes, minha pergunta é bastante vaga. Obrigado pelo link, realmente útil - Eu nunca soube ATS foi tão rápido
Farouk

Belo link com informações detalhadas de comparação. Estou um pouco decepcionado ao ver o Clojure usando muito mais memória e demorando muito mais que o Java. Lembro-me de algumas afirmações sobre Clojure ter um desempenho semelhante, o que não parece ser o caso.
DPM

O site da ATS afirma que o ATS suporta uma variedade de paradigmas de programação - portanto, antes de você afirmar que o ATS é mais rápido que o resto, você precisa mostrar que esses programas são de fato escritos em um estilo funcional. Pode ser que o ATS funcional não seja mais rápido que o resto.
Igouy

2
O site da Scala declara que a Scala integra recursos funcionais e orientados a objetos. Você verificou se os programas Scala são escritos como programas funcionais, em vez de programas orientados a objetos?
Igouy

12

Também deve ser salientado que você não pode medir / quantificar o desempenho de uma linguagem de programação . O melhor que você pode fazer é medir o desempenho de uma implementação específica do idioma em plataformas específicas, executando programas específicos.

Portanto, quando você pergunta sobre "a linguagem funcional mais rápida", o que você realmente está perguntando sobre as melhores implementações atuais do (s) idioma (s).


O comentário da @ igouy ressalta que existem outras medidas de desempenho para a implementação da linguagem; por exemplo, tempo de compilação. Mas isso não muda o fato de que o tempo de execução do programa de aplicativo é uma medida (indireta) da implementação de uma linguagem, não uma medida da própria linguagem.

Considere Java, por exemplo. Suponha que eu escreva um benchmark de thread único usando somente recursos de linguagem do Java clássico (Java 1.0). Se eu compilar e executar usando o JDK 1.0, obterei um desempenho ruim (porque o JDK 1.0 não tinha um compilador de código nativo). Se eu for do JDK 1.1 para o ... JDK 1.7, provavelmente obterei resultados progressivamente melhores. Mas isso não se deve a alterações na linguagem Java ... porque meu benchmark está usando o mesmo subconjunto de linguagem. Em vez disso, a aceleração ocorre devido a melhorias nos compiladores, no sistema de tempo de execução e / ou na implementação de bibliotecas de classes. Todos esses são problemas de implementação .

O outro ponto é que essas diferenças de implementação podem ser realmente significativas (por exemplo, ordens de grandeza) para o mesmo idioma. Portanto, o fato de a melhor implementação da linguagem X ser mais rápida que a melhor (ou única) implementação da linguagem Y não necessariamente informa muito sobre a linguagem em si.


O melhor que você pode fazer é medir o desempenho de programas específicos. Quando medimos o desempenho de uma implementação de linguagem, queremos descobrir quanto tempo leva para compilar algum programa, não quanto tempo esse programa leva para ser executado.
Igouy

O tempo de execução do programa é uma propriedade desse programa em particular quando executado usando a implementação de linguagem específica nesse hardware específico, etc. está sendo usado como atalho para as implementações de linguagem conhecidas e usuais.
igouy

@igouy - isso é verdade. Mas muitas pessoas não fazem a distinção, como ilustrado por muitos sites antigos proclamando que "o Java é lento. Infelizmente, essa bobagem foi lida literalmente por toda uma geração de programadores ... e danificou significativamente a reputação do Java. é por isso que estou fazendo esse argumento AQUI #
C Stephen C

Como você deseja ter a liberdade de dizer - "uma medida (indireta) da implementação de uma linguagem" - explique por que alguém não deveria ser livre para dizer - uma medida (indireta) de uma linguagem .
igouy

@igouy - 1) Você é livre para dizer o que quiser. Mas isso não faz você certo. 2) Considere o caso em que a única implementação de uma linguagem é uma porcaria. Nós a avaliamos. Em seguida, atualizamos a implementação, fazemos benchmark e o desempenho melhorou drasticamente. Isso significa que o desempenho do idioma melhorou? Como isso faz sentido ... dado que o idioma NÃO mudou !!!
Stephen C

6

Se você está procurando idiomas apenas na velocidade de execução, está faltando alguns pontos importantes. A velocidade é uma coisa boa, mas não é a única coisa.

Haskell usa um sistema de tipos muito robusto para criar programas que provavelmente serão muito mais livres de erros e robustos.

A Erlang usa seu sistema de monitoramento embutido para permitir a criação de sistemas de falhas que podem fornecer um enorme nível de confiabilidade diante de vários tipos de falhas. Além disso, o Erlang pode oferecer um nível de simultaneidade difícil de ser encontrado em outros idiomas.

Na verdade, consideraria a velocidade de execução nos dias de hoje bastante abaixo da lista do que consideraria na maioria dos casos. (OK, se eu estivesse fazendo cálculos numéricos maciços, provavelmente desejaria usar o fortran para velocidade, mas, caso contrário, isso não é importante o suficiente para importar)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.