Benchmark nacional de linguagens de programação

O artigo, da forma como foi escrito, mostra um grande erro, cometido por muita gente (dessa vez sem generalizações), na hora de interpretar benchmarks.

NÃO EXISTE LINGUAGEM RÁPIDA OU LINGUAGEM LENTA.

O que existe é implementação rápida ou lenta, compilador que gera código rápido ou lento, forma de executar rápido ou lenta.

O g++, como é sabido, é um compilador que não "se empenha" muito em fazer otimizações. Entretanto, outros compiladores o fazem, como ICC da Intel, ou o da MS (que está disponível para download gratuito, evidentemente só para Windows).

Esse resultado não prova que "C++ não é tão rápido", e sim que "o código gerado pelo g++ não é tão rápido".

Aliás, isso que eu estou falando fica evidente no próprio artigo, onde é feito uma comparação do código em python interpretado, e do código em python compilado na hora (Just-In-Time).

O código com JIT roda mais rápido que o sem JIT. Isso significa que o artigo provou que "a linguagem python é mais rápida que a linguagem python"? Não.. ele provou o código python rodando com o compilador jit roda mais rápido que o código em python sendo interpretado da forma convencional.

Benchmarks não comparam linguagens e sim implementações.

O benchmark não dá muitos detalhes de como foi compilado o código C++. Na minha experiência pessoal, o simples uso de opções do g++ como essas:

-O2 -fomit-frame-pointer -march=athlon-xp (no caso de um Athlon XP)

fazem com que o código rode de 3 a 5 vezes mais rápido do que sem nenhuma otimização.

A implementação da STL (Standard Template Library) do g++ também não é lá das melhores. A Boost (http://www.boost.org/) é bem melhor.

Além disso, outro compilador muito bom é o icc (Intel Compiler), que gera código bastante otimizado quando compilado com essas opções:

-O -tpp6 -axiMK

E em C++ poderíamos simplesmente também não ter usado o tipo string da STL, e sim usando um char [ ] (array de chars), que seria MUITO mais rápido.

Parece que usaram o PHP Apache pelo timeout e
pela demora, segue o código que alterei para
php-cli (command line interface) levou 20s.

#!/usr/bin/php -q

<?php

// bench.php: utilize chmod +x bench.php
// e ./bench.php para executar o script

function f($x) {
    $a = 0;
    $b = 1;
    $n = 0;

    while ($n < $x) {
        $tmp = $a;
        $a = $b;
        $b += $tmp;
        $n++;
    }

    return $a;
}

    for ($i = 0; $i < 300000; $i++)
        f(40);

?>

E o outro código levou 0.27s:

#!/usr/bin/php -q
<?php
function f() {
    $a = "";
    for ($i=0; $i < 300000; $i++) {
        $a .= "a";
    }
}
f();
?>

Vou falar a verdade eu achei este teste muito tendencioso para o Python principalmente quando foram-se descartardas as formas otimizadas das linguagens para resolver os problemas, mas eles disseram uma grande verdade no final do artigo na sessão "Performance importa?" por que são poucos os programadores com problemas de desempenho e memoria mas são muitos os programadores com problemas de prazo.
Quanto ao fato de que não existe linguagem lenta ou rápida eu discordo, por que isto so é verdade se formos analizar as linguagens do ponto de vista utopico, por que no mundo real os criadores das bibliotecas das linguagens sempre tem alguma dificuldade e nem sempre consguem produzir a melhor implementação para um objeto da linguagem, isto é que cria as diferenças entre as linguagens, e as linguagens tambem se diferenciam pelos problemas que elas se propoem a resolver como por exemplo seguir um padrão de projeto como a orientação a objeto ou facilitar a solução de problemas matematicos e esta caracteristicas forçam os criadores das linguagens a dar mais enfase em alguma parte da linguagem do que outra fazenda desta linguagem melhor para uma tarefa do que outra.

Mas independente do desempenho eu acredito que um sistema jovem como o linux precisa de linguagens que sejam faceis de produzir programas mesmo que esta linguagem não criem bons executaveis(no sentido de desempenho) para que as pessoas de boa vontade e boas ideias possam dar vida as suas boas ideias isto é que fará do linux um sistema grande e utilizado por muitos, um bom exemplo disto é o propio php que embora não tenha um desempenho maravilhoso muitas ferramentas de legais são criadas com ele como por exemplo o phpmyadmin.

Pensem nisto e deem suas opiniões

Java2,

se você não postar o tempo de execução dos códigos escritos nas outras linguagens no mesmo hardware em que você testou o código em php, esse tempo de execução que você falou não tem significado nenhum.

Não dá pra comparar esse resultado com os resultados obtidos em outro hardware, com outras configurações.

Sugiro que os realizadores do benchmark original incorporem as alterações sugeridas pelo java2, e publiquem a diferença de temporização também. Eu ia comentar sobre a impossibilidade de comparar estes tempos de execução se o ambiente não for idêntico, mas o Eu já mencionou a questão.

Na verdade eu disse "não tem significado nenhum", quando na verdade deveria ter dito "não tem significado algum", ou então "tem signficado nenhum".

Hehe, língua estranha, esse português, onde duplas negações ocorrem com tanta facilidade.

"Mostrou também que PHP e Java são rápidas para determinadas tarefas mas não são tão rápidas para outras."

ISSO EH OBVIO !!!!!!!!!!!!!!!
Precisa nem de teste para saber isso.

Alguns pontos a serem ressaltados:

- Usei o std::string e não vetor de char porque a intenção é justamente testar o sistema de objetos do C++. E de qualquer forma o C++ não saiu-se mal nos testes. Não sei porque estão reclamando tanto do g++ e do STL. O problema para objetos acima de 130k está claramente no alocador de memória.
- Usei apenas -O2 para compilar o C++. Podia ter usado omit-frame-pointer, dá um ganho de performance de uns 15%, mas isso já cai na categoria "truques sujos".
- É óbvio que os tempos foram todos tomados no mesmo hardware.

Oi epx! O comentário acima sobre ser no mesmo hardware foi dirigido ao participante que fez uma alteração no teste em PHP e o rodou de novo na máquina dele, publicando em seguida o tempo dele. Eu sugeri que vocês (que fizeram s testes originais) façam também o teste dele na máquina de vocês, para poder ser comparável, ok?

Tem razão.

Augusto,

Aparentemente a única diferença que eu notei nos scripts PHP do java2 que pode causar diferença de performance na execução do código foi o uso do $n++ no lugar do $n += 1. Se essa modificação provocar realmente uma melhoria de performance a gente atualiza o teste.

Com relação a usar o php-cli, foi esse mesmo que foi utilizado para o Benchmark.

Mas o que eu acho importante nesse teste simples é mostrar que, na média, as linguagens (implementações) comparadas possuem performances muito semelhantes.

Óbvio que esses testes em C (vulgo assembly bombado) ficariam mais rápido. Mas a velocidade da aplicação não é o requisito principal em todo tipo de desenvolvimento de software. A produtividade do programador e a capacidade de facilita a geração de código de qualidade tem se tornado mais importante a cada dia que passa.

Eu não faço questão, mas se não for muito custoso aceitar a proposta, certamente seria "legal" fazer da maneira alternativa, mesmo que seja para comprovar aquilo que parece óbvio.

É óbvio que o artigo foi tendencioso. Como todo fã ardoroso de python, o objetivo é dizer que Java não é rápido, e python. O que é ridículo, já que benchmarks anteriores publicados no .BR mostram que python (sem otimizações) é 3x mais lerdo que Java.

Por que também não utilizar Ruby no bench? Ruby deixam python no chinelo, em todos os sentidos. Com a diferença que os publishers dizem que embora a linguagem seja melhor que python e perl, ela não é ainda tão generalista quanto Java ou C++.

O pessoal do d00dz.org tendencioso?

Duvido.

Veja o que está escrito na página:
"Python Powered Perl is for sissies, PHP is for lusers." :)

Além disso, eu lembro de já ter visto a mesma frase, no mesmo site, mas estampadas na camisa de umas cheerleaderes, e não no rodapé do site, como agora. (talvez esteja confundindo com outro site)

Mas de qualquer maneira, benchmarks sempre serviram para provar que a linguagem preferida do autor do benchmark é melhor do que as outras. Qual a novidade?

Obviamente um teste com dois algoritmos não prova absolutamente nada. Talvez o interpretador de Java pode ter alguma característica que o torna muito mais efeciente para esses algoritmos do que para o caso geral. Ou então pode ser o interpretador de Python... Ou então o G++, quem sabe...

E a verdade, como já foi citado, é que para a maior parte dos softwares "customizados", ou seja, aqueles que são feitos para rodar em UMA empresa, em UMA situação, a velocidade é um dos fatores menos importantes.

A principal finalidade de benchmarks é servir de ínico para flame-wars, então, por favor, não atrapalhe.

Eu acho que seria interessante ver benchmarks alternativos publicados. Por mais que um benchmark sozinho não prove nada, certamente um monte de benchmarks produzidos por fãs de linguagens diversas lançaria luz sobre diversas características das respectivas.

Não tenho nada com isso, e não tenho a menor idéia do desempenho dessas linguagens. Mas como o pessoal está achando que alguma coisa nesses testes foi tendenciosa, e como qualquer um pode repetí-los (afinal, são algoritmos simples, e você pode até mesmo escolher outros), proponho que façam seus próprios e tirem suas conclusões - e me mandem, que eu publico também.

Podem até incluir mais linguagens - que tal perl? ou mesmo shell? ou o tiny cobol?

Lendo o artigo pela 10a. vez eu ainda não vi onde o estudo foi tendencioso pra Python.

Java já tem um JIT embutido e o Psyco é um JIT pra Python. Os testes foram escritos e rodados na mesma máquina com VMs diferentes.

Os programas foram implementados usando as mesmas técnicas (sendo inclusive injusto com Python no teste de fibonacci pelo fato de, em Python, não existir tipos básicos que são facilmente otimizáveis por um interpretador/compilador).

E no artigo mostra de forma *bem clara* que a VM da IBM conseguiu rodar o teste de Fibonacci em quase metade do tempo que o Psyco levou para rodar o mesmo teste. Ou seja, Python foi derrotado em várias situações nos testes e mesmo assim os resultados estão ali.

Com relação ao benchmark anterior que o Ark se referiu (aquele do osnews.com) é que eles só testaram operações aritméticas (inteiros e ponto flutuantes) e de I/O. No teste de aritmética Python perdeu *muito* feio (assim como no nosso teste com Fibonacci) de Java. Mas no teste de I/O Python perdeu por pouca diferença.

O teste feito com o Psyco é pra mostrar que, assim como o JIT (hotspot) do Java melhorou muito a performance das VMs o mecanismo de JIT também pode melhorar muito a performance de uma aplicação escrita em Python.

Com relação às outras linguagens comparadas: ganharam e perderam igual à Python e Java. Ou seja, os resultados mostram que todas as linguagens testadas conseguem performance 'semelhante'.

Ruby: Não foi feito teste com Ruby porque nenhum dos responsáveis pelo benchmark conhecem a linguagem e as suas implementações para que um teste feito com ela fosse justo. Se alguém submeter os testes para nós rodamos.

Sobre 'Ruby deixar Python no chinelo': A internet é democrática e aceita quaisquer tipos de declarações, portanto eu poderia dizer aqui, num site de Linux, que "Linux é um lixo", mesmo sabendo que isso não é verdade.

Quando eu falo que Python 'é uma grande linguagem de programação' eu falo isso baseado em experiências pessoais de um desenvolvedor que trabalhou por 14 anos de carreira com pelo menos umas 10 linguagens de programação incluindo: Python, PHP, C (C++ não) e atualmente Java e Smalltalk (que foi de onde Ruby surgiu e que 'Ruby no chinelo' porque não usa a sintaxe alienígena do Perl)

Como é mesmo?
"There are lies, damn lies, and benchmarks."

Para quem se interessa no assunto, existe uma página com 'benchmarks' para mais de trinta linguagens e mais de vinte testes diferentes, abrangendo diversas áreas. Também tem um 'scorecard'. Basta ajustar os valores que a 'sua' linguagem pode ficar entre as primeiras. ;-)
http://shootout.alioth.debian.org/index.php

Para uma leve desmistificação sobre velocidade e, uma simples dica para 'turbinar' alguma coisa
http://tinyurl.com/ysjtl

E é claro que o "Python Powered Perl is for sissies, PHP is for lusers." pega mal pra caramba.

Sugestao: C#, que também tem um compilador in time e um interpretador (no mono)

Outros benchmarks, todos também são "não tendenciosos" (com ênfase nas aspas)

http://www.flat222.org/mac/bench/
http://www.osnews.com/story.php?news_id=5602&page=3

(procurei no "java python benchmark" no Google, e esses foram os primeiros resultados, depois do site xml.com, que eu não sei o que estava fazendo lá.

Lógico que os resultados dos 3 benchmarks não são compatíveis, o que só comprova o que eu disse antes: benchmark, assim como qualquer outro estudo estatístico, só serve para provar aquilo que o autor do já queria provar antes de começar o estudo. (foi mal, generalizei denovo)

Mas de qualquer maneira, benchmarks têm sua função, já que flame-wares são fundamentais na Internet. Se não fossem, para que teriam inventado a usenet? (newsgroups, onde pessoas como eu se sentem em casa)

"que trabalhou por 14 anos de carreira com pelo menos umas 10 linguagens de programação "

Isso não importa. Tem gente q trabalha com negocios a 30 anos e nao sabe direito o q faz.

Estou tentando fazer em Bash, mas parece que
entrou em loop infinito, se alguém puder ajudar:

#!/bin/sh

f ()
{
    a=0
    b=1
    n=0
    while [ $n -lt 40 ]; do
        tmp=$a
        a=$b
        b=$[b + tmp]
        n=$[++n]
    done
    return $a
}

i=0

while [ $i -lt 300000 ]; do
    f
    i=$[++i]
done

Para quem quiser testar, abaixo está uma implementação do Fibonacci na linguagem WhiteSpace.

Não, é mentira.
A página da linguagem é essa: http://compsoc.dur.ac.uk/whitespace/

O exemplo foi tirado daqui: http://compsoc.dur.ac.uk/whitespace/fibonacci.ws

O pacote 'whitespace' do Debian tem o compilador.

O programa começa na próxima linha:

Eu ia colar o programa aqui, mas o movably type destróia a formatação. Quem quiser, baixe o arquivo .ws no link acima, e rode assim:

eu@localhost$ wspace fibonacci.ws
How many? 10
1
1
2
3
5
8
13
21
34
55
89
144

Nem sei se é isso que o programa usado no benchmark faz, mas só o fato de ter um programa escrito com espaços, tabs e enteres que faz isso já é mais que suficiente para postar aqui.

Não sei porque perder tempo discutindo com benchmarks, existem trocentos na internet, e uma vez que a maioria concorda que desempenho não é um fator primordial, então...

Sempre vai haver discusão sobre linguagens, banco de dados, religião e etc.

Se você souber bem 2 ou 3 linguagens que se completam, você não precisa de mais nada.

Aqui está, portado direto do PHP para o gawk. Na minha máquina rodou em 12,3s, mas o processador não estava dedicado só a isso. Se o pessoal quiser incluir no benchmark (rodando na máquina "padrão"), acho que ia ser legal - principalmente se alguém fizer em Perl também. Quem sabe o Aurélio não faz em sed? Por mais inútil que seja, afinal benchmark é benchmark.

E acho que a indentação vai se perder, mas paciência.

gawk '
function f(x)
{
a = 0;
b = 1;
n = 0;
while (n < x) {
tmp = a;
a = b;
b = tmp + b;
n += 1;
}
return a;
}

BEGIN {
for (i = 0; i < 300000; i++) {
f(40);
}
}'

Sim,

Benchmarks são benchmarks. Resultados de benchmaks são tão inúteis quanto os argumentos 'mas Java é leeeento! Java é pesado!', ou 'Python é uma carroça', ou 'Bom mesmo é C! C é muuuito rápido'...

O benchmark poderia ter sido implementado em qualquer uma das centenas (milhares?) de linguagens turing-compliant disponíveis por aí, mas preferiram usar linguagens que fossem familiares para não haver injustiça com nenhuma delas.

Programo em Python (sem Psycho), em Java e em Smalltalk e em nenhum momento performance foi um impedimento para usar uma dessas linguagens.

E o comentário do Henrique expressa a minha opinião.

http://dada.perl.it/shootout/

http://www.iolanguage.com/Comparisons/Performance.html

Eu acho benchmark legal,e com quanto mais linguagens, mais legal. Mas benchmarks são benchmarks, eles não tem alguma utilidade adicional, intrínseca. Por mais que não seja especialmente útil comparar Java com sed, acho que aumenta o interesse no trabalho. Não foi uma crítica...

Além destes resultados relacionados ao desempenho da aplicação, considero interessantes os resultados que avaliam o tempo no desenvolvimento dos sistemas, bem como o tempo gasto na manutenção de um programa. O tempo que se leva para aprender a linguagem e novas funcionalidades também é importante. No meu caso, que ensino lógica e programação em disciplinas de curso superior, que geralmente abordam uma grande quantidade de conceitos em tempo curto, isto é fundamental. Muitas vezes se passa mais tempo aprendendo a linguagem do que os conceitos necessários ou mesmo pensando na resolução do problema.

Sei que estas características são muito masi subjetivas e difíceis de medir num laboratório, mas em minha opinião, olhando deste ponto de vista, Python é uma linguagem que merece atenção.

Portando o exemplo do Augusto para Lua, alguém se habilita?

function f(x)
local a = 0
local b = 1
local n = 0
local tmp
while n < x do
tmp = a
a = b
b = tmp + b
n = n + 1
end
return a
end

i = 0
while i < 30000 do
f(40)
i = i + 1
end

Vocês viram o segundo benchmark postado pelo eje del mal? Lua foi bem pra caramba.

Eu gosto de benchmarks. Programo em Haskell, a linguagem que inspirou e deu origem ao C# da MS e apesar de ter um compilador lento, é uma das mais usadas no meio científico.

Querem velocidade? ASSEMBLY
Mas boa sorte para fazer um programa inteiro!

Eu acho que o resultado deste benchmark deve ser "qual a melhor linguagem para fazer isso ?", e não "A lingugem Foo é melhor/mais rápida/mais bonitinha que a linguagem Bar".

Exemplo: Se só o que eu preciso é substituir palavras em um texto, para que perder tempo fazendo programas em C com testes, ponteiros, etc, se um simples sed 's/palavra/PALAVRA/g' arquivo.txt resolve ?

Acho que o benchmark deve ser encarado como uma forma de descobrir quais são as melhores ferramenteas para o tipo de problema a ser resolvido. Será que é mais facil lidar com arquivos em C ou Shell ? O PHP trabalha melhor com bancos de dados do que o Java ? Python + gtk é muito lento, mas o desenvolvimento e a manutenção são mais complexas em C. E por aí vai.

Acredito que qualquer profissional da área que tenha experiencia em ao menos duas linguagens de programação vai pensar primeiro na relação 'benefício - dificuldade - tempo' antes de optar por uma ou por outra.

Espero ter me feito entender :)

É evidente que o teste teria que dar pro lado do python, ja notaram o nome do site em questao ?

Mais uma outra coisa importante é o tamanho da comunidade de desenvolvedores por que trocar experiências agiliza muito no processo de desenvolvimento

e uma pequena observação:
No codigo java utilizado no benchmark as variáveis utilizadas para calcular a série de fibonacci são do tipo long quando elas deveriam ser do tipo int, isto pode parecer irrelevente mas assim como no c e c++ as variáveis do tipo int são do tamanho dos registradores da cpu enquanto as variáveis do tipo long são projetadas para serem maiores do que os registradores da cpu isto faz com que este tipo de variável seja mais lento que o tipo int e isto dentro de um loop pode ter tido uma alteração consideravel e como em linguagen fracamente tipadas(este é o termo técnico) como o Python e php existe sempre uma estrutura especializada em criar o tipo mais adequadro de variável de acordo com o valor varaiável, e portanto para tornar o benchmark mais justo eu sugiro a implementação abaixo.

public class teste2 {
public static void main(String args[]) {
for(int x = 0; x < 300000; ++ x) {
f(40);
}
}

public static int f(int x) {
int a = 0;
int b = 1;
int n = 0;

while (n < x) {
int tmp;
tmp = a + b;
a = b;
b = tmp;
++n;
}

return a;
}
}

Eu estou feliz com as pessoas que foram críticas ao benchmark: essa é a atitude correta. Benchmarks são mentirosos, e acho que o texto procura deixar isso claro e ser honesto com relação a isso.

Alguns comentários, acredito que todos estejam no texto, mas como algumas pessoas levantaram aqui vou trazer para cá.

- Concordo completamente que o benchmark é de implementações, não de linguagens. Tanto que usamos duas implementações de Python e três de Java.
- Quem achou que o teste foi feito para beneficiar o Python, pense de novo. Originalmente ele foi escrito em formato diferente pelo epx (notem que ele é fã de C++) para comparar C++ e Java. Python só entrou na jogada depois e o texto só usa a versão Python como referência porque o site se chama PythonBrasil. Acho que o nome do site teve mais influência sobre quem achou que fomos imparciais do que os próprios testes. Tudo bem, é uma dose saudável de cuidado.
- Eu não sabia que o Osvaldo ia anunciar tão largamente o benchmark agora, mas o que eu estou fazendo/planejando fazer é mostrar como inverter os resultados, mesmo que para isso você trapaceie um pouco. Por exemplo, o Psyco se quebra totalmente na concatenação se você usar um tipo derivado de string (class foo(str): pass). Alguém também sugeriu usar um outro tipo de String do Java que é mutável, etc.
- Benchmark desse tipo é 100% lúdico. Poderíamos usar o termo "toymark" que seria mais honesto. Eu considero tanto esse benchmark como aquele outro que diz que Java (qual?) é mais rápido que Python (qual?) inválidos. Em primeiro lugar, eles são irrelevantes, e em segundo para cada exemplo seu eu posso arranjar um contra-exemplo meu e ninguém vai poder dizer: eis a verdade universal. Os grandes avanços de performance estão nos algoritmos, não nas linguagens.

Mas todo mundo já sabia isso.

foi mau os erros de português eu estava com pressa ;-)

A solução é simples: programe diretamente em código binário! =D

Mais otimizado impossivel...
(se vc não se perder durante a tarefa...)

=)

Erro de português é pouco. No post acima eu errei meu nome :)

Aguardo os comentários dizendo que o benchmark foi inválido por ter sido escrito por um analfabeto :)

O código C++ de concatenação usado foi o seguinte:

#include

void f() {
std::string a = "";
for (int i=0; i < 300000; i++) {
a = a + "a";
}
}

void main(void) { //?!?!?!? void?!?!?!
f();
}

Ô código porco sô!

"Even if your compiler accepts "void main()" avoid it, or risk being considered ignorant by C and C++ programmers."

http://www.research.att.com/~bs/bs_faq2.html#void-main

Concordo com você, Guilherme. Na minha opinião, sua resposta está certa.

O termo para isso é a chamada "Complexidade" do Algoritmo. Existe até uma cadeira no curso de Bacharelado em Informática que fiz, chamada "Análise de Algoritmos", em que exercitávamos nossas mentes com os básicos cálculos da "complexidade" de diversos algoritmos e funções recursivas, com seus Métodos de Divisão e Conquista, etc etc... hehehehe...

O quanto o algoritmo demora ou deixa de demorar está na relação de sua complexidade. Por exemplo, algoritmos com vários laços de repetição terão uma complexidade maior, bem como cada tipo de laço aumenta ou diminui a complexidade em relação a forma com a qual trabalham dentro do algoritmo.

Também acredito que um benchmark desses deveria medir mais a capacidade de gerenciar objetos que cada linguagem possui, bem como sua capacidade de interagir com um Banco de Dados, pois acredito que o grande "lance" de uma linguagem hoje em dia é como se pode aplicar UML sobre ela (e acho que nisso o java ganha de longe, principalmente com seus "garbage collectors" e com seus bancos de dados OO). Tempo de desenvolvimento está diretamente relacionado (na minha opinião) numa modelagem de dados bem feita e em um modelo de objetos conciso, com Diagramas de Casos de Uso coerentes com a realidade para qual o software vai servir.

Mas acho a idéia válida! É uma forma de se ver as coisas e, graças a Deus, vivemos num ambiente democrático onde cada um pode ver as coisas da forma que achar melhor. Meu "jeito" de ver a coisa está aí encima, mas qualquer um tem o direito de discordar da mesma! :)

Sobre o comentário do santo. No primeiro teste de Fibonacci que fiz, que só está em http://www.d00dz.org, usei variáveis long long em C++. A performance não mudou muito. Supondo que caísse pela metade, ainda seria muito mais rápido que os demais. E ainda haveria espaço para usar flags freaks etc.

Ola pessoal..

Gostaria de dar parabens a iniciativa, eu mesmo ja tinha pensado e fazer algo assim .

Gostaria de fazer o mesmo teste para para o código java rodando na vm do Mono e testar tambem o C# .

estou escutando as criticas, e podemos montar um novo teste..

Se certas pessoas fossem tão boas em fazer software livre como são em fazer nitpicking no código C++ dos outros, o Brasil seria uma potência no software livre, ao invés de ser um simples parasita.

Faltou pedir ajuda para a comunidade nas linguagens
que os autores não dominavam, assim começou o Linux
e deu certo... Alguns códigos ficaram tendenciosos
demais, ou seja, passou a impressão de "vamos desmoralizar a linguagem X", não acho que seja o
caminho diminuir as d+ linguagens para dizer
que a q vc usa é a melhor, mas sim contribuir no
desenvolvimento para que ela melhore dia após dia.

Experimentem: perl -e 'for($x=0;$x<300000;$x++){$a.="a";}'

Java2,

Onde que foram tendenciosos? Em que códigos especificamente? Você chegou a ler o motivo pelo qual o teste de concatenação de strings e o de fibonacci foram implementados com algoritmos ineficientes?

E a idéia não é fazer este benchmark com 1e35 linguagens. A idéia é mostrar que num teste de bancadas, sem trapacear, sem jogar contra as regras, você consegue provar o que bem entender. É +/- o que o Guilherme Manika disse ali em cima.

Para um benchmark mais completo e com mais linguagens eu recomendo o http://www.bagley.org/~doug/shootout/ onde a idéia é obter o máximo de performance em todos os testes usando todos os 'linguagismos' possíveis. No teste dos d00dzers não usaram 'linguagismos'.

Olá pessoal,

Sou programador de sistemas gerenciais cliente X servidor , onde nesse setor existem diversas linguagens de fazem essa tarefa muito bem.

Dando uma olhada em todos esses comentários e também sobre a peformace da linguagem a ser utilizada, gostaria de compartilhar uma dúvida

No caso de sistemas como as suítes de escritório OpenOffice e MS Office essa diferença de performace pode ser mais visível.

A questão é? Pq? o OpenOffice não consegue ter um desempenho a altura de seu concorrente? Seria a Linguagem utilizada? A forma de desenvolvimento?

Abraços

Olá pessoal,

Sou programador de sistemas gerenciais cliente X servidor , onde nesse setor existem diversas linguagens de fazem essa tarefa muito bem.

Dando uma olhada em todos esses comentários e também sobre a peformace da linguagem a ser utilizada, gostaria de compartilhar uma dúvida

No caso de sistemas como as suítes de escritório OpenOffice e MS Office essa diferença de performace pode ser mais visível.

A questão é? Pq? o OpenOffice não consegue ter um desempenho a altura de seu concorrente? Seria a Linguagem utilizada? A forma de desenvolvimento?

Abraços

MrFaber: Até onde sei é porque o StarOffice tinha/tem código Java no meio...