"Java não tem performace"

Assuntos Gerais
#81

[quote=marcobiscaro2112]
Só para citar um exemplo, semana passada fiz um “port” da libnotify para Java com JNA usando apenas uma classe (com menos de 50 linhas) e absolutamente nada de linguagem nativa.[/quote]
jna realmente é muito legal, mas…
pense no seguinte: se alguma outra plataforma conseguisse chamar métodos em java e tivesse mapeados os tipos primitivos, seria o suficiente?

jni da dor de cabeça, pq na maioria dos casos não da pra escapar de implementar uma fachada em código nativo (algo entre a biblioteca e o java) pelo seguinte motivo: o tratamento de excessões em tempo de execução… como exceptions, null pointers da vida, estouros de memória etc etc.

Ou seja, uma linguem é mais que mapeamentos e chamadas a métodos.

É por causa de coisinhas assim que existe uma linha muito tenue entre escrever uma aplicação em java que use (ou seja) um grande wrapper e partir para programar diretamente em código nativo.

#82

Eu acho Delphi assim como VB viáveis para micro-empresas, de até 10 funcionários, pdas, que você tem um orçamento baixo e precisa de muita produtividade e um valor hora baixo também.

#83

[quote=bobmoe][quote=marcobiscaro2112]
Só para citar um exemplo, semana passada fiz um “port” da libnotify para Java com JNA usando apenas uma classe (com menos de 50 linhas) e absolutamente nada de linguagem nativa.[/quote]
jna realmente é muito legal, mas…
pense no seguinte: se alguma outra plataforma conseguisse chamar métodos em java e tivesse mapeados os tipos primitivos, seria o suficiente?[/quote]
De forma alguma. Tanto que JNA tem suporte a ponteiros e structs, por exemplo.

[quote=bobmoe]
jni da dor de cabeça, pq na maioria dos casos não da pra escapar de implementar uma fachada em código nativo (algo entre a biblioteca e o java) pelo seguinte motivo: o tratamento de excessões em tempo de execução… como exceptions, null pointers da vida, estouros de memória etc etc.

Ou seja, uma linguem é mais que mapeamentos e chamadas a métodos.[/quote]
Realmente uma linguagem é mais que isso. Mas não necessariamente é necessário uma “camada” entre a biblioteca nativa e o Java. Só como exemplo, veja o port do GStreamer ou do VLC em Java. Apenas JNA e funciona extremamente bem.

#84

Algo que a comunidade Ruby já assimilou e que faria bem parte da comunidade Java também entender é que mesmo que em alguns cenários a plataforma seja lenta, ela é rápido o suficiente para a maioria das situações, até porque a grande maioria das aplicações comerciais não têm requisitos tão críticos de performance.

O mais importante, ao meu ver, é a performance dos desenvolvedores, ou seja, a produtividade. Isso sim me faz optar por uma plataforma específica em algum projeto.

#85

[quote=sergiotaborda][quote=juliocbq]
Concordo que ter uma máquina gerenciando seu programa é uma coisa muito boa, mas não tem como um bytecode correr mais rápido que um assembly nativo, por razões físicas. A vm precisa conversar com o processador real de qualquer forma.
[/quote]

Então como vc explica os resultados do benchmark que linkei antes ?
Veja que o gargalo não é o processador ou sequer as instruções. O gargalo é a linkagem. Porque a do C++ é estática ele tem como saber sobre o ambiente em runtime. Ele não pode otimizar para runtime. Não é adaptativo. A VM permite esta adapatabilidade. E é isso que dá velocidade, não o processador.

A VM precisa comunicar com o processador, verdade, mas não sempre da mesma forma. É nessa adaptação que se ganha a velocidade.
Se vc corre um sistema durante um minuto, uma hora ou um ano em C++ tanto faz. Mas em java, a jvm vai aprendendo e se ajustando. Depois de um tempo ela já compilou a maior parte do codigo. Agora é assembly contra assembly. A diferença é a que a JVM produziu o melhor assembly possivel para o seu ambiente (OS, Processador, Memoria, padrões de uso do sistema) o do C++ é sempre o mesmo, não necessariamente o melhor.
Mesmo considerando compilações espeficias para uma plataforma o C++ perde. Porque mesmo assim ele não está usando estatisticas para saber que mais otimizações pode fazer.[/quote]

Você olhou o código fonte desse benchmark?

Existem instruções que serão otimizadas com certeza, e se você não ligar o otimizador do seu compilador c++, realmente ele não vai corrigir blocos inúteis do seu código.

Eu nunca vi um benchmark que mostra java com mais performance que c++, que fosse correto. Sempre o compilador c++ não estava com otimização ligada, ou o codigo era mentiroso.

ex:

for(int i=0; i<10000; i++){

// nada aqui dentro. Oras, com certeza a otimização corta fora, esse código

}

Usei o nivel 1 aqui do g++, e olha o resultado:

2010/2/19/76f6f0d3b72503cab793c2b8968f42ef_50924.jpg_821×967 175 KB


2010/2/19/363d685cd20dceb405561d535c342504_50924.jpg_1247×966 153 KB

#86

[quote=juliocbq][quote=sergiotaborda][quote=juliocbq]
Concordo que ter uma máquina gerenciando seu programa é uma coisa muito boa, mas não tem como um bytecode correr mais rápido que um assembly nativo, por razões físicas. A vm precisa conversar com o processador real de qualquer forma.
[/quote]

Então como vc explica os resultados do benchmark que linkei antes ?
Veja que o gargalo não é o processador ou sequer as instruções. O gargalo é a linkagem. Porque a do C++ é estática ele tem como saber sobre o ambiente em runtime. Ele não pode otimizar para runtime. Não é adaptativo. A VM permite esta adapatabilidade. E é isso que dá velocidade, não o processador.

A VM precisa comunicar com o processador, verdade, mas não sempre da mesma forma. É nessa adaptação que se ganha a velocidade.
Se vc corre um sistema durante um minuto, uma hora ou um ano em C++ tanto faz. Mas em java, a jvm vai aprendendo e se ajustando. Depois de um tempo ela já compilou a maior parte do codigo. Agora é assembly contra assembly. A diferença é a que a JVM produziu o melhor assembly possivel para o seu ambiente (OS, Processador, Memoria, padrões de uso do sistema) o do C++ é sempre o mesmo, não necessariamente o melhor.
Mesmo considerando compilações espeficias para uma plataforma o C++ perde. Porque mesmo assim ele não está usando estatisticas para saber que mais otimizações pode fazer.[/quote]

Você olhou o código fonte desse benchmark?

[/quote]

Eu não. Você olhou ? Olhe lá dentro e diga o que está errado. Embora isso não importe para o argumento aqui…
Mais resultados aqui

Você não está entendendo o ponto da questão. Existem mais coisas no ambiente do que simplesmente comunicar com o processador. O Vini já falou da alocação da memoria e eu dei o exemplo do padrão de uso. Java é mais burucrático que C por , por exemplo, sempre verificar os imites dos arrays a cada acesso. Mas estas restrições da especificação se aplicam cada vez menos na prática devido a uma inteligência que existe na jvm que não é nada trivial. E depois, como disse antes, nem todas as jvm são iguais.A da ibm é sempre pior, por exemplo. Portanto dizer que Java (sem mais qualificativos) é mais lento que C++ não tem qualquer significado.

#87

Fora que, se alguém usa a linguagem hoje em dia para justificar problemas de performance na sua aplicação, é porque é um mau desenvolvedor. Para a maior parte de aplicações de escritório, a lentidão não será a linguagem, em hipótese alguma. Mesmo no caso do Swing e do Java.

Se você está fazendo aplicações ligadas as que eu e o Julio trabalhamos, aí sim, você terá que escolher conviver ou não com os congelamentos do GC. São congelamentos esporádicos e curtos, o que atende boa parte dos sistemas de softrealtime. Mas veja, não será por causa da velocidade da execução em si, mas de uma característica intrínseca do GC, que é paralizar a aplicação.

Se você faz aplicações científicas, onde 99% do seu processamento é mesmo calculo, aí você usa C++. Até porque, nesse caso provavelmente você estará trabalhando com um mainframe.

#88

[quote=sergiotaborda][quote=juliocbq][quote=sergiotaborda][quote=juliocbq]
Concordo que ter uma máquina gerenciando seu programa é uma coisa muito boa, mas não tem como um bytecode correr mais rápido que um assembly nativo, por razões físicas. A vm precisa conversar com o processador real de qualquer forma.
[/quote]

Então como vc explica os resultados do benchmark que linkei antes ?
Veja que o gargalo não é o processador ou sequer as instruções. O gargalo é a linkagem. Porque a do C++ é estática ele tem como saber sobre o ambiente em runtime. Ele não pode otimizar para runtime. Não é adaptativo. A VM permite esta adapatabilidade. E é isso que dá velocidade, não o processador.

A VM precisa comunicar com o processador, verdade, mas não sempre da mesma forma. É nessa adaptação que se ganha a velocidade.
Se vc corre um sistema durante um minuto, uma hora ou um ano em C++ tanto faz. Mas em java, a jvm vai aprendendo e se ajustando. Depois de um tempo ela já compilou a maior parte do codigo. Agora é assembly contra assembly. A diferença é a que a JVM produziu o melhor assembly possivel para o seu ambiente (OS, Processador, Memoria, padrões de uso do sistema) o do C++ é sempre o mesmo, não necessariamente o melhor.
Mesmo considerando compilações espeficias para uma plataforma o C++ perde. Porque mesmo assim ele não está usando estatisticas para saber que mais otimizações pode fazer.[/quote]

Você olhou o código fonte desse benchmark?

[/quote]

Eu não. Você olhou ? Olhe lá dentro e diga o que está errado. Embora isso não importe para o argumento aqui…
Mais resultados aqui

Você não está entendendo o ponto da questão. Existem mais coisas no ambiente do que simplesmente comunicar com o processador. O Vini já falou da alocação da memoria e eu dei o exemplo do padrão de uso. Java é mais burucrático que C por , por exemplo, sempre verificar os imites dos arrays a cada acesso. Mas estas restrições da especificação se aplicam cada vez menos na prática devido a uma inteligência que existe na jvm que não é nada trivial. E depois, como disse antes, nem todas as jvm são iguais.A da ibm é sempre pior, por exemplo. Portanto dizer que Java (sem mais qualificativos) é mais lento que C++ não tem qualquer significado.[/quote]

Olhei, compilei e testei.

Como não? Usei a mesma máquina virtual , e o mesmo código fonte do bench que você postou.
As razões do java ser mais lento são físicas. Existe um nível a mais entre o processador real e seu bytecode.
Logo na execução do aplicativo, o bytecode já está perdendo para o nativo, que já é instrução de microprocessador real.
E posteriormente vai perder por causa do coletor de lixo, mesmo com a aplicação compilada pelo jit.

Eu posso pegar todos os fontes postados naquele benchmark e contestá-los, mas são muitos e eu perco o dia de trabalho.
Porque você mesmo não pega um dos exemplos e faz os testes, ligando o otimizador do compilador c++? Vai ver que os resultados são diferentes.

#89

[quote=ViniGodoy]Fora que, se alguém usa a linguagem hoje em dia para justificar problemas de performance na sua aplicação, é porque é um mau desenvolvedor. Para a maior parte de aplicações de escritório, a lentidão não será a linguagem, em hipótese alguma. Mesmo no caso do Swing e do Java.

Se você está fazendo aplicações ligadas as que eu e o Julio trabalhamos, aí sim, você terá que escolher conviver ou não com os congelamentos do GC. São congelamentos esporádicos e curtos, o que atende boa parte dos sistemas de softrealtime. Mas veja, não será por causa da velocidade da execução em si, mas de uma característica intrínseca do GC, que é paralizar a aplicação.

Se você faz aplicações científicas, onde 99% do seu processamento é mesmo calculo, aí você usa C++. Até porque, nesse caso provavelmente você estará trabalhando com um mainframe.[/quote]

Em questão java tem ótima performance, e diferença não é tão grande se formos levar em conta gerência de memória automatica e n outras coisas que a vm te dá. Mas não acho justo comparar c++ com java, pelas razões citadas acima.

Máquina virtual é uma coisa, Máquina real é outra.

#90

Eu também já fiz muitos benchmarks, e o C++ geralmente se sai melhor. Muito melhor. Mesmo ativando só otimização básica (o1).

Geralmente os benchmarks de java que dizem o contrário são de pessoas que não programam em C++ e fazem a compilação de qualquer jeito. Ou que compilaram lá no devcpp com um mingw de 1996 e estão comparando com a última versão do JDK…

O pior é que os benchmarks geralmente são de códigos quase 100% matemáticos, o que deve ser a realidade de no máximo 1% das pessoas do fórum.

No geral, em aplicações comerciais, gargalos de performance estão em outros locais, geralmente relacionados a I/O: Banco de dados, rede, leitura de arquivos. Existe problemas também por erros de software, como escolher a estrutura de dados errada.

#91

[quote=ViniGodoy]Eu também já fiz muitos benchmarks, e o C++ geralmente se sai melhor. Muito melhor. Mesmo ativando só otimização básica (o1).

Geralmente os benchmarks de java que dizem o contrário são de pessoas que não programam em C++ e fazem a compilação de qualquer jeito. Ou que compilaram lá no devcpp com um mingw de 1996 e estão comparando com a última versão do JDK…

O pior é que os benchmarks geralmente são de códigos quase 100% matemáticos, o que deve ser a realidade de no máximo 1% das pessoas do fórum.

No geral, em aplicações comerciais, gargalos de performance estão em outros locais, geralmente relacionados a I/O: Banco de dados, rede, leitura de arquivos. Existe problemas também por erros de software, como escolher a estrutura de dados errada. [/quote]

Concordo.
E pras máquinas de hoje, a não ser em situações muito específicas, essa perda de performance do Java não faz tanta falta assimse comparado ao benefício.

#92

Com certeza não faz nenhuma diferença. Alta Performance é exigida em situações muito específicas, em que um programa tem que tomar decisões em tempo crítico(Ex uma aplicação capturar uma cena de 500 ms, em arquivo de vídeo). O benefício é enorme, tanto em tempo de desenvolvimento, e na própria segurança da aplicação.

Com as melhorias no coletor de lixo, na versão 7, java deve diminuir mais esse passo.

#93

BDP no Delphi também faz isso, e de forma mais transparente, além de gastar menos memória.

Mas, como disseram, tem muitas facilidades no Java que compensam a perda de performance e o maior uso de memória. O compilador Delphi é muito rápido e gera um código nativo bastante otimizado, o Java teria que ficar fazendo N análises pra conseguir chegar em um código comparável, mas sempre terá que contar com a máquina virtual.

Só que são poucas as situações que os décimos de segundo de diferença vão fazer falta no processamento, principalmente nas máquinas atuais, por isso acho que essa vantagem no Delphi só vale pra alguns casos (talvez seja o caso da pessoa que disse a frase tema do tópico).

Gosto de drag and drop. Economiza muito tempo em criar interface e aumenta a produtividade, mas na parte de regras de negócio não tem jeito: é codificar mesmo. E é aí que está o maior tempo de desenvolvimento de qualquer software de médio porte pra cima. Ainda existe muita facilidade do Delphi que o Netbeans e Eclipse não possuem, mas existe o inverso também.

Mas a maior vantagem que vejo no Java é a independência de plataforma.[/quote]

Só ressaltando que não abri este tópico para defender Delphi. Trabalho com Delphi mas, não por opção, e sim por necessidade. Minha preferência seria Java ou C#. Abri este tópico para saber o por que os programadores/desenvolvedores de outras linguagens falam tão mal de Java. Nada mais.

#94

BDP no Delphi também faz isso, e de forma mais transparente, além de gastar menos memória.

Mas, como disseram, tem muitas facilidades no Java que compensam a perda de performance e o maior uso de memória. O compilador Delphi é muito rápido e gera um código nativo bastante otimizado, o Java teria que ficar fazendo N análises pra conseguir chegar em um código comparável, mas sempre terá que contar com a máquina virtual.

Só que são poucas as situações que os décimos de segundo de diferença vão fazer falta no processamento, principalmente nas máquinas atuais, por isso acho que essa vantagem no Delphi só vale pra alguns casos (talvez seja o caso da pessoa que disse a frase tema do tópico).

Gosto de drag and drop. Economiza muito tempo em criar interface e aumenta a produtividade, mas na parte de regras de negócio não tem jeito: é codificar mesmo. E é aí que está o maior tempo de desenvolvimento de qualquer software de médio porte pra cima. Ainda existe muita facilidade do Delphi que o Netbeans e Eclipse não possuem, mas existe o inverso também.

Mas a maior vantagem que vejo no Java é a independência de plataforma.[/quote]

Só ressaltando que não abri este tópico para defender Delphi. Trabalho com Delphi mas, não por opção, e sim por necessidade. Minha preferência seria Java ou C#. Abri este tópico para saber o por que os programadores/desenvolvedores de outras linguagens falam tão mal de Java. Nada mais.[/quote]

Mas quem falou mal de java, ou qualquer outra ferramenta ou linguagem, aqui?

Só estamos debatendo vantagens e desvantagens. Endeusar uma linguagem de programação não traz benefício algum.

#95

Ok…

#96

Este tipo de discussão pra mim se resume ao meu argumento “Pascal e o nerd tiraninho”: http://www.itexto.net/devkico/?p=596

resumindo: uma tecnologia não é como um martelo para o qual todos os problemas são igualmente pregos. :slight_smile:

#97

[quote=sergiotaborda]Um outro problema é que, mesmo quando o C++ é mais rápido - por exemplo em calculos de matrizes, ele é menos exato. Não ha garantia que um calculo feito em C++ em máquinas diferentes terá o mesmo resultado. Isto é normalmente esquecido. Quando se diz que C não é portável não significa apenas que não roda em máquinas diferentes, significa que tem resultados diferentes em máquinas diferentes. Em java isto também acontece, mas a JVM dá garantias. Java implementa o padrão IEEE para numeros de ponto flutuante e dá garantias de ulp. Estes erros, em cadeias grandes de calculos, podem provocar diferenças obseráveis nos resultados.
Enfim, velocidade é inutil se o resultado não é reprodutivel[/quote]
Imagina vc com uma doença rara, 10 dias de expectativa de vida e 200 médicos calculando a dose certa do remédio.
Destes, 100 médicos usando C++ e 100 médicos usando JAVA, cada um em seu PC.
Os médicos usando C++ trariam 100 respostas diferentes a cada dia totalizando 1000 respostas imprecisas, enquanto que os médicos usando JAVA trariam 100 respostas iguais no décimo dia totalizando 1 resposta precisa.

#98

Não dá para comparra o desempenho de uma linguagem compilada com o desempenho de uma linguagem interpretada. Cada uma tem seus benefícios e seus pontos fracos. Se você tentar cortar o pão com a colher e tomar sopa com a faca, vai se dar mal. Com as liguagens é assim também.

#99

[quote=Java Lover][quote=sergiotaborda]Um outro problema é que, mesmo quando o C++ é mais rápido - por exemplo em calculos de matrizes, ele é menos exato. Não ha garantia que um calculo feito em C++ em máquinas diferentes terá o mesmo resultado. Isto é normalmente esquecido. Quando se diz que C não é portável não significa apenas que não roda em máquinas diferentes, significa que tem resultados diferentes em máquinas diferentes. Em java isto também acontece, mas a JVM dá garantias. Java implementa o padrão IEEE para numeros de ponto flutuante e dá garantias de ulp. Estes erros, em cadeias grandes de calculos, podem provocar diferenças obseráveis nos resultados.
Enfim, velocidade é inutil se o resultado não é reprodutivel[/quote]
Imagina vc com uma doença rara, 10 dias de expectativa de vida e 200 médicos calculando a dose certa do remédio.
Destes, 100 médicos usando C++ e 100 médicos usando JAVA, cada um em seu PC.
Os médicos usando C++ trariam 100 respostas diferentes a cada dia totalizando 1000 respostas imprecisas, enquanto que os médicos usando JAVA trariam 100 respostas iguais no décimo dia totalizando 1 resposta precisa.
[/quote]

??

#100

[quote=Java Lover][quote=sergiotaborda]Um outro problema é que, mesmo quando o C++ é mais rápido - por exemplo em calculos de matrizes, ele é menos exato. Não ha garantia que um calculo feito em C++ em máquinas diferentes terá o mesmo resultado. Isto é normalmente esquecido. Quando se diz que C não é portável não significa apenas que não roda em máquinas diferentes, significa que tem resultados diferentes em máquinas diferentes. Em java isto também acontece, mas a JVM dá garantias. Java implementa o padrão IEEE para numeros de ponto flutuante e dá garantias de ulp. Estes erros, em cadeias grandes de calculos, podem provocar diferenças obseráveis nos resultados.
Enfim, velocidade é inutil se o resultado não é reprodutivel[/quote]
Imagina vc com uma doença rara, 10 dias de expectativa de vida e 200 médicos calculando a dose certa do remédio.
Destes, 100 médicos usando C++ e 100 médicos usando JAVA, cada um em seu PC.
Os médicos usando C++ trariam 100 respostas diferentes a cada dia totalizando 1000 respostas imprecisas, enquanto que os médicos usando JAVA trariam 100 respostas iguais no décimo dia totalizando 1 resposta precisa.
[/quote]

Exatamente. A resposta no primeiro dia seria igual a todos os outros. O te daria 9 dias para administrar a dose…