Sobre benchmarks de linguagens
Hoje, não sei como, topei com mais uma comparação de desempenho entre Java em e C++ que, como de costume, gerou uma discussão sem fim. Não que eu ache essas discussões totalmente inúteis: na verdade, você sempre acaba aprendendo/conhecendo alguma coisa nova. O ponto principal e que todo mundo ignora – para meu espanto – é que, quando um programa qualquer em Java é mais rápido que o seu equivalente em C/C++ isso só prova uma coisa: que um programa C/C++ bem escrito consegue processar qualquer coisa bem rápido, inclusive os bytecodes do Java 
Em tempo, dêem uma olhada nesse interessantíssimo conjunto de benchmarks.
January 28th, 2009 at 3:23 am
Eae!
Você está correto. Um programa “bem escrito” em C++ supera tudo (exceto Fortran)
No entanto, um programa performático em C++ leva muito mais tempo para ser feito do que sua versão em java e a manutenabilidade dele fica comprometida. Logo o custo financeiro é maior. Por isso a análise que eu fiz mantinha os códigos semelhates. Desta forma eu garantia um custo de desenvolvimento semelhante.
Exemplo, depois de várias tentativas, muitas pessoas me mandaram código otimizado em C++ que superam o programa java. Mas isso foi muito tempo depois, com um código muito mais complexo que o inicial.
[]s
January 28th, 2009 at 5:56 am
Vitor, não tenho como discordar desses argumentos: para muitos casos, na minha opinião, é mais rápido e barato fazer em Java do que em C++ (obviamente, existem excessões). Tempo de desenvolvimento custa caro.
[]‘s
April 24th, 2009 at 2:49 am
O assunto “tocou em minha ferida”. Eu discordo no que foi tocado sobre produtividade.
Penso que, a curto prazo, Java possa ser mais produtivo. Porém, a longo prazo, penso que C++ pode ter a mesma ou até maior produtividade do que linguagens como Java, Python, PHP, “Object Pascal”, etc.
Um dos primeiros fatores que eu aponto para defender a idéia de que a produtividade depende de ser a longo ou a curto prazo, é o fato do C++ não prover, nos padrões da linguagem, APIs de desenvolvimento prontas. Isso ocorre ao oposto de Java, Python, PHP, e, até de “Object Pascal”, que em todas as implementações deste utilizadas no mercado se tem uma enorme API pronta, aonde para se fazer uma polenta basta instanciar uma classe.
Mas vejam que a utilização de uma API de terceiros, que no caso da API do Java, provida pela ex-Sun, assim como em outros casos, entope você com milhões de classes que fazem coisas absolutamente parecidas, para serem utilizadas em casos diferentes. É o caso, por exemplo, das classes da família da “Date”(DateFormat, SimpleDateFormat, e por aí vai). No fim das contas, você sempre terá que entender a fundo o funcionamento dessas classes todas e despender um grande tempo as estudando para utilizá-las corretamente, conforme o crescimento do projeto.
Lembrando que em caso de, por exemplo, bug na JVM, você poderá perder dias “procurando bruxas” em seus códigos e achando um modo de passar por cima do problema. É o mesmo que gerenciar configuração de um enorme aplicativo(pense, por exemplo, em um DBA Oracle), aonde você está totalmente alienado do que está “por baixo dos panos” e tem que tentar “prezumir” como a coisa funciona muitas vezes.
Penso que para um projeto pequeno, isso seja totalmente aceitável. Em um projeto pequeno, eu particularmente não utilizaria C++, utilizaria Python por exemplo. Mas, em um projeto maior, e aonde o desempenho seja crítico, eu uso C++, que a longo prazo será mais produtivo.
Agora, em softwares do mundo real, nunca ninguém me provou que um aplicativo em Java pode ser rápido. Pego como exemplo de aplicativo Java típico o JDeveloper e o NetBeans, ou até aquele IRPF Java que nossa querida Receita Federal nos disponibiliza. São lentos, como todo aplicativo em Java que conheço. Já aplicativos em C++ variam. Alguns são mais lentos ainda, outros são rápidos. Desenvolvo softwares de firewall/redes, e nunca adotaria Java como linguagem para eles.
No mais, tudo depende da finalidade. Para meu ramo eu nunca adotaria Java, mas para benchmarks de desempenho Java é uma excelente linguagem.