"Java não tem performace"

Assuntos Gerais
#121

Não mesmo? Então que tal ler esse post?
http://www.guj.com.br/posts/list/45/198295.java#996969

Ou esse aqui?
http://www.guj.com.br/posts/list/30/198295.java#996671

Ou ainda esse?
http://www.guj.com.br/posts/list/75/198295.java#997948

Eu só acho que o povo que curte Java também fala muita besteira em relação ao C++. Eu programo há vários anos nas duas linguagens, muitos deles com sistemas de tempo real. E as duas tem pontos fortes e fracos.[/quote]

Eu reconheco onde java perde feio… e que tem problemas SIM… mas a performance não é um destes problemas. Nao no hardware disponivel hoje em dia.

#122

Aliás, o que geralmente estraga threads desse tipo é quando vem alguém com a postura que você adotou, chun. Ninguém está travando batalha entre linguagens, ou afirmando que C++ é melhor que Java.

Como já reconhecemos no início da thread, o C++ tem diversas desvantagens. Posso citar diversas delas:

  1. É extremamente complexo gerenciar memória em C++.
  2. O legado da linguagem tornou-a cheia de pequenas armadilhas;
  3. Existem menos profissionais qualificados e mais caros;
  4. É mais difícil obter softwares gratuitos em C++.
  5. Não é multi-plataforma.

O ponto 1 merece destaques com luzes coloridas. Quando falamos em extremamente complexo, estamos falando em uma dificuldade que se estende por toda aplicação. Smart Pointers atenuam o problema, mas não eliminam. Fora que tem uma sintaxe muito mais confusa e eliminam o comportamento determinístico do new e delete.

Por isso, como eu já falei no passado, acho que hoje só vale a pena usar C++ em aplicações onde você realmente precisa de performance crítica, num hardware específico, ou em aplicações onde as pausas do GC não possam ser toleradas. Não é o caso do BD do twitter, pois como já expliquei nessa thread, existem intervalos de tempo toleráveis para um BD muito superiores ao do GC, e existirão gargalos provavelmente tão ruins quanto a eventual diferença de processamento.

Agora, não é por isso que devemos dizer que o Java é a solução para todos os problemas. Tente fazer uma aplicação de vídeo em Java e você logo começa a sentir os pequenos congelamentos do gc. Em certos tipo de sistemas de tempo real, o buraco é bem mais embaixo. Felizmente, uma nova geração de GC está vindo por aí e, como eu mesmo publiquei o link, deve melhorar ainda mais o uso de java em aplicações de tempo real.

Então, se você está dizendo que eu dei a entender que o C++ é melhor em toda a thread, sugiro que você leia com cuidado os posts anteriores…

#123

Você está falando do que? Sistemas comerciais comuns? Isso aí já foi dito umas 50 vezes na thread. Por mim, inclusive, que afirmei que na maior parte das aplicações comerciais hoje, quem culpa a linguagem por problema de performance é um mau programador.

Se você vai lidar com hardware específico, não vai ser num software de cadastro e relatório, muito provavelmente. Um dos exemplos citados é um sistema de suporte a vida, ou um sistema de telecomunicações, onde cada milissegundo pode ser precioso. Onde um GC não pode se dar ao luxo de congelar sua aplicação num momento completamente inesperado.

Então, muito provavelmente, você acabará desenvolvendo o hardware e o software para controlar esse hardware. Na Siemens, lidavamos com algumas centrais que precisavam processar centenas de pacotes por segundo. Em regime de pico, uma execução do garbage collector poderia ocasionar na perde de centenas de ligações telefônicas. Você realmente usaria Java, com um GC completamente imprevisível, nessa situação?

#124

Não mesmo? Então que tal ler esse post?
http://www.guj.com.br/posts/list/45/198295.java#996969

Ou esse aqui?
http://www.guj.com.br/posts/list/30/198295.java#996671

Ou ainda esse?
http://www.guj.com.br/posts/list/75/198295.java#997948

Eu só acho que o povo que curte Java também fala muita besteira em relação ao C++. Eu programo há vários anos nas duas linguagens, muitos deles com sistemas de tempo real. E as duas tem pontos fortes e fracos.[/quote]

Eu reconheco onde java perde feio… e que tem problemas SIM… mas a performance não é um destes problemas. Nao no hardware disponivel hoje em dia.
[/quote]

Você fala muito e prova pouco.
Em vez de falar poderia postar um exemplo aqui para esclarecer a todos. Pode ser exemplo de aplicação em tempo real como jogo, captura de vídeo, etc…

obs: Taikodon usa mapeamento para opengl(c++) e openAL(c++)

#125

[quote=ViniGodoy]Aliás, o que geralmente estraga threads desse tipo é quando vem alguém com a postura que você adotou, chun. Ninguém está travando batalha entre linguagens, ou afirmando que C++ é melhor que Java.

Como já reconhecemos no início da thread, o C++ tem diversas desvantagens. Posso citar diversas delas:

  1. É extremamente complexo gerenciar memória em C++.
  2. O legado da linguagem tornou-a cheia de pequenas armadilhas;
  3. Existem menos profissionais qualificados e mais caros;
  4. É mais difícil obter softwares gratuitos em C++.
  5. Não é multi-plataforma.

O ponto 1 merece destaques com luzes coloridas. Quando falamos em extremamente complexo, estamos falando em uma dificuldade que se estende por toda aplicação. Smart Pointers atenuam o problema, mas não eliminam. Fora que tem uma sintaxe muito mais confusa e eliminam o comportamento determinístico do new e delete.

Por isso, como eu já falei no passado, acho que hoje só vale a pena usar C++ em aplicações onde você realmente precisa de performance crítica, num hardware específico, ou em aplicações onde as pausas do GC não possam ser toleradas. Não é o caso do BD do twitter, pois como já expliquei nessa thread, existem intervalos de tempo toleráveis para um BD muito superiores ao do GC, e existirão gargalos provavelmente tão ruins quanto a eventual diferença de processamento.

Agora, não é por isso que devemos dizer que o Java é a solução para todos os problemas. Tente fazer uma aplicação de vídeo em Java e você logo começa a sentir os pequenos congelamentos do gc. Em certos tipo de sistemas de tempo real, o buraco é bem mais embaixo. Felizmente, uma nova geração de GC está vindo por aí e, como eu mesmo publiquei o link, deve melhorar ainda mais o uso de java em aplicações de tempo real.

Então, se você está dizendo que eu dei a entender que o C++ é melhor em toda a thread, sugiro que você leia com cuidado os posts anteriores…[/quote]

Alias,

ao invés do pessoal ficar travando batalhas sobre qual linguagem é melhor, o pessoal deveria se atentar principalmente neste ponto que o Vini falou:

Java é melhor para as massas, pois existem um número elevado de profissionais, mas para uma pessoa física, tvz seja mais interessante ela trabalhar com C++, já que normalmente é um profissional mais caro!

#126

[quote=ViniGodoy][quote=Felipe Kan]Que Java é mais lento que C/C++ todo mundo sabe… mas sempre vai aparecer gente falando o contrário…

Também como é que uma linguagem que gerencia memória através de um GC vai querer comparar com outra que não usa… e ainda por cima precisa de uma VM para interpretar os bytecodes…
[/quote]

Pelo visto você está por fora de alguns anos de evolução da VM e do Java. A VM não interpreta byte-codes. Ela compila. Mas não compila todo o bytecode, e sim, somente os trechos mais usados o que é chamado de Hotspot Compilation.

A Hotspot compilation tem algumas vantagens sobre a compilação feita no C++. Em primeiro lugar, ela pode identificar sobre qual hardware ela está compilando, e ativar otimizações específicas. Em segundo, ela conta com informações de runtime e pode, por exemplo, eliminar sincronização quando percebe que apenas uma thread está rodando, ou fazer inlining de métodos abstratos, coisa que o C++ não faz.

Quanto a gerência de memória, a do Java é centenas de vezes mais eficiente do que o new e delete do C++. Primeiro, porque a VM aloca grandes blocos de memória. Depois, porque ela trabalha com gerações de objetos, não desalocando memória que será rapidamente realocada. Uma experiencia interessante é colocar um código com muitos new e delete num loop, e fazer o mesmo em java. Você vai ver que no Java a performance é centenas de vezes superior. Por outro lado, o Java consome mais memória, já que não tem a filosofia de “você só paga pelo que usar”, que o C++ tem. A desalocação do garbage collection também ocorre em blocos grandes de memória, e alocar e desalocar memória é uma das tarefas mais custosas da maior parte dos sistemas.

Então, é difícil afirmar pura e simplesmente que o java é “mais lento” que o C++. Se você fizer algum programa envolvendo um calculo puramente matemático, é bem provável que na maior parte das vezes o Java realmente seja. Afinal, nele ocorrem poucas alocações de memória, e você provavelmente compilará os dois programas no seu computador, com as otimizações específicas ligadas.

Agora, num contexto mais amplo, duvido muito. Sem falar que o Java tem ferramentas de profiling maravilhosas, como o Visual VM, que permitem que você identifique e corrija os gargalos certos na sua aplicação. Enquanto para o C++ sobra o que? O Valgrind, que só roda em Linux?

Ok, não estou afirmando também que o Java seja mais rápido que o C++ sempre. Não é tão simples assim, porque performance muda de programa para programa. O que quero dizer é que, a menos que você programe firmware, os gargalos dificilmente estarão na linguagem. Aliás, acho muitissíssimo improvável hoje que eles sequer cheguem perto de estar, não é à toa que temos aplicações eficientes rodando em linguagens notoriamente lentas, como PHP.[/quote]

auhuaa… onde vc aprente tudo isso???

#127

Um dos locais mais interessantes é o site da IBM. Dê uma olhada nos artigos do Brian Goetz link aqui.

Dos autores, ele certamente é um dos melhores.
No site do próprio Goetz há mais artigos:
http://www.briangoetz.com/pubs.html

Existem alguns livros especializados em performance e na linguagem em si.

Outra boa forte de informação é o site da própria Sun. Existem por lá diversos artigos sobre performance e ergonomia do garbage collector:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Sobre o novo garbage collector, tem um link também da Sun que passei num dos posts anteriores.

Me avise se você quiser links também para C++, mas a maioria do material está mesmo em bons livros.

Quando você trabalha com tempo real, é necessário ler muito e estudar muito as tecnologias envolvidas. Sistemas de tempo real geralmente vão explorar ao máximo os limites dessas tecnologias, o que não ocorre com outros tipos de sistema. Por isso, é bom se manter sempre informado, com artigos atualizados e, principalmente, com fontes confiáveis. Se você entrar no site javaperformancetuning.com, vai encontrar um monte de artigos sobre o assunto, mas a falta de critério do pessoal tornou esse site praticamente inútil, na minha opinião. Você vê por lá artigos sérios e mitos e fica difícil diferenciar um do outro.

#128

Um dos locais mais interessantes é o site da IBM. Dê uma olhada nos artigos do Brian Goetz link aqui.

Dos autores, ele certamente é um dos melhores.
No site do próprio Goetz há mais artigos:
http://www.briangoetz.com/pubs.html

Existem alguns livros especializados em performance e na linguagem em si.

Outra boa forte de informação é o site da própria Sun. Existem por lá diversos artigos sobre performance e ergonomia do garbage collector:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Sobre o novo garbage collector, tem um link também da Sun que passei num dos posts anteriores.

Me avise se você quiser links também para C++, mas a maioria do material está mesmo em bons livros.

Quando você trabalha com tempo real, é necessário ler muito e estudar muito as tecnologias envolvidas. Sistemas de tempo real geralmente vão explorar ao máximo os limites dessas tecnologias, o que não ocorre com outros tipos de sistema. Por isso, é bom se manter sempre informado, com artigos atualizados e, principalmente, com fontes confiáveis. Se você entrar no site javaperformancetuning.com, vai encontrar um monte de artigos sobre o assunto, mas a falta de critério do pessoal tornou esse site praticamente inútil, na minha opinião. Você vê por lá artigos sérios e mitos e fica difícil diferenciar um do outro.

[/quote]

O que acaba com um bom artigo realmente é o mito. Um bom artigo deve possuir boa base teórica, e provas científicas(código fonte).
um lugar onde se presa o científico é o http://www.codeproject.com .
Além de teoria, nos mais diversos temas, você tem o código fonte para testar.

#129

O java não é lento!

O que acontece é que, quando o Java estava apenas engatinhando, ele realmente tinha problemas de performance; mas todos esses problemas foram (e estão sendo) resolvidos. As pessoas pegaram esse vício de dizer isso, e agora ficam falando isso sem conhecimento de causa.

Quer ver o Delphi ser lento? É só colocar uma pessoa que não sabe programar fazer algo no Delphi.

Outra coisa: é possível encontrar vários artigos acadêmicos na internet dizendo que o Java não é lento: http://74.125.155.132/scholar?q=cache:uNiJvsyFkIYJ:scholar.google.com/+java+n%C3%A3o+%C3%A9+lento&hl=pt-BR&as_sdt=2000.

Até mais

#130

Ultimamente essas discussões de linguagens tem sido um pé-no-saco…
Quem se acha “entendido” da coisa deveria perceber que linguagem é ferramenta para um objetivo, e não um fim em si mesma.
Acho que todo mundo aqui deveria ter noção de como levar uma conversa, na boa, sem stress.
Daí vem um bonito e diz agora: “Mas quem tá falando disso aqui?”
Bem, acho que o exemplo tem ser dado por quem já está no mercado e tem experiência há mais tempo.
Porque é um SACO, ficar nessas discussões sem fim, e que so demonstram a imaturidade de algumas pessoas.
Melhor agir com racionalidade, e se perder o fio da meada, ignorar os trolls…rs

#131

[quote=eliangela]O java não é lento!

O que acontece é que, quando o Java estava apenas engatinhando, ele realmente tinha problemas de performance; mas todos esses problemas foram (e estão sendo) resolvidos. As pessoas pegaram esse vício de dizer isso, e agora ficam falando isso sem conhecimento de causa.

Quer ver o Delphi ser lento? É só colocar uma pessoa que não sabe programar fazer algo no Delphi.

Outra coisa: é possível encontrar vários artigos acadêmicos na internet dizendo que o Java não é lento: http://74.125.155.132/scholar?q=cache:uNiJvsyFkIYJ:scholar.google.com/+java+n%C3%A3o+%C3%A9+lento&hl=pt-BR&as_sdt=2000.

Até mais[/quote]

A discução aqui não é java ser lento ou rápido. É sobre quais tipos de aplicação java pode ser viável ou não.
Java é lento? Não, mas é inviável usá-la para aplicações criticas, pelas mais diversas razões já citadas aqui, e que faz o uso de c++ ser necessário em quase 30 anos.

Artigos acadêmicos servem para ser criticados, e provas empíricas não servem para nada. O ideal é nós mesmos experimentarmos as tecnologias através de testes e benchmarks, como os que o sergio postou.

A performance do java vem crescendo a cada versão, e hoje a diferença é mínima entre um assembly nativo e um bytecode, mas a melhor otimização é aquela que você tem total controle do fluxo do software, e, as vezes, um programa gerenciando seus objetos em memória é um empecilho muito grande.

Detalhe, a conclusão do artigo que postou refere c++ para o uso de aplicações de alta performance, e java para ganho de produtividade.

#132

[quote=marcio.sancho]Ultimamente essas discussões de linguagens tem sido um pé-no-saco…
Quem se acha “entendido” da coisa deveria perceber que linguagem é ferramenta para um objetivo, e não um fim em si mesma.
Acho que todo mundo aqui deveria ter noção de como levar uma conversa, na boa, sem stress.
Daí vem um bonito e diz agora: “Mas quem tá falando disso aqui?”
Bem, acho que o exemplo tem ser dado por quem já está no mercado e tem experiência há mais tempo.
Porque é um SACO, ficar nessas discussões sem fim, e que so demonstram a imaturidade de algumas pessoas.
Melhor agir com racionalidade, e se perder o fio da meada, ignorar os trolls…rs[/quote]

O problema é a parcialidade, ou seja, o que eu uso é melhor. Até alguns posts atrás, o debate estava muito bom.

#133

[quote=juliocbq][quote=marcio.sancho]Ultimamente essas discussões de linguagens tem sido um pé-no-saco…
Quem se acha “entendido” da coisa deveria perceber que linguagem é ferramenta para um objetivo, e não um fim em si mesma.
Acho que todo mundo aqui deveria ter noção de como levar uma conversa, na boa, sem stress.
Daí vem um bonito e diz agora: “Mas quem tá falando disso aqui?”
Bem, acho que o exemplo tem ser dado por quem já está no mercado e tem experiência há mais tempo.
Porque é um SACO, ficar nessas discussões sem fim, e que so demonstram a imaturidade de algumas pessoas.
Melhor agir com racionalidade, e se perder o fio da meada, ignorar os trolls…rs[/quote]

O problema é a parcialidade, ou seja, o que eu uso é melhor. Até alguns posts atrás, o debate estava muito bom.[/quote]

Concordo.

#134

cara, não resisti :slight_smile: e acabei fazendo a experiência que vc citou. no meu benchmark o java levou o dobro do tempo que o c++. segue o código que usei:

[code]#include
#include <time.h>
using namespace std;

class Point {
public:
Point();
private:
double x;
double y;
};

Point::Point() { x = 0; y = 0; }

int main(){
cout << “creating objects…\n”;
time_t secondsStart = time (NULL);
for (long i = 0;i < 100000000; i++)
Point p();
time_t secondsEnd = time (NULL);
printf ("%ld seconds to create objects.\n", secondsEnd-secondsStart);
return 0;
}[/code]

[code]class Point {
private double x;
private double y;

public Point() {
	x = 0;
	y = 0;
}

}

public class Main {
public static void main(String[] args) {
System.out.println(“creating objects…”);
long milesecondsStart = System.currentTimeMillis();
for (long i = 0; i < 100000000L; i++)
new Point();
long milesecondsEnd = System.currentTimeMillis();
System.out.printf("%d seconds to create objects.", (milesecondsEnd-milesecondsStart)/1000);
}
}[/code]
Mesmo java sendo mais lento, achei incrivelmente rápido. Porém posso ter deixado alguma coisa passar ou entendido errado. O tipo de comparação que vc se referia era essa?

#135

[quote=marcio.sancho]Ultimamente essas discussões de linguagens tem sido um pé-no-saco…
Quem se acha “entendido” da coisa deveria perceber que linguagem é ferramenta para um objetivo, e não um fim em si mesma.
Acho que todo mundo aqui deveria ter noção de como levar uma conversa, na boa, sem stress.
Daí vem um bonito e diz agora: “Mas quem tá falando disso aqui?”
Bem, acho que o exemplo tem ser dado por quem já está no mercado e tem experiência há mais tempo.
Porque é um SACO, ficar nessas discussões sem fim, e que so demonstram a imaturidade de algumas pessoas.
Melhor agir com racionalidade, e se perder o fio da meada, ignorar os trolls…rs[/quote]

A discussão é importante pq ela pode determinar qual ferramenta usar em cada caso. O problema justamente acontece quando alguns programadores tentam apertar um prego com uma faca e comer usando chave de fenda!

#136

Você criou o Point no stack e não no heap. Faça:

for (long i = 0;i < 100000000; i++) { Point* p = new Point(); delete p; }

O stack é mesmo incrivelmente rápido.

Mas isso só reforça a conclusão que eu queria chegar. O Java e o C++ tem ergonomias completamente diferentes. Por isso, é dificílimo dizer qual vai gerar uma aplicação mais lenta ou mais rápida sem muito benchmark. Além disso, em 99.9% dos casos, a diferença será irrelevante, pois os gargalos da aplicação não estarão na linguagem e sim em BD, I/O, rede, etc…

#137

Acabei de fazer o bechmark alterando no C++ para criação com new e delete (como eu tinha sugerido).

No java: 1 segundo
No C++: 16 segundos (otimização O3 ligada).

Essa criação de objeto é meio estúpida, mas você tem que considerar que isso poderia estar num método:

void Mesh::doSomething() {
   Point p* = new Point();
   //faz qualquer coisa com p
   delete p;
}

E seu loop poderia estar chamando doSomething(), sem nem saber dessa criação/destruição no heap.

PS: Eu adoro esse benchmark, sempre uso em discussões de fóruns de C++ quando falam que o Java é mais lento “no geral”.

#138

Você criou o Point no stack e não no heap. Faça:

for (long i = 0;i < 100000000; i++) { Point* p = new Point(); delete p; }

O stack é mesmo incrivelmente rápido.

Mas isso só reforça a conclusão que eu queria chegar. O Java e o C++ tem ergonomias completamente diferentes. Por isso, é dificílimo dizer qual vai gerar uma aplicação mais lenta ou mais rápida sem muito benchmark. Além disso, em 99.9% dos casos, a diferença será irrelevante, pois os gargalos da aplicação não estarão na linguagem e sim em BD, I/O, rede, etc…[/quote]

Isso, a stack é uma área da memória usada para variáveis(alocadas estaticamente em memoria), objetos alocados dinamicamente vão para o heap. A stack do windows xp suporta 8mb;
se você alocar um vetor maior que, o programa nem inicializa.

Outra maneira de otimizar esse código seria transformar Point em uma struct, dessa maneira certificando-se que sempre estaria na stack.

#include <QtCore/QCoreApplication>
#include <iostream>
#include <time.h>
#include <stdio.h>

using namespace std;

struct Point {
        double x;
        double y;
    };

//Point::Point() { x = 0; y = 0; }

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    cout << "creating objects...\n";
    time_t secondsStart = time (NULL);

    for (long i = 0;i < 100000000; i++)
            struct Point p;

    time_t secondsEnd = time (NULL);

    printf ("%ld seconds to create objects.\n", secondsEnd-secondsStart);

    return a.exec();
}

Aqui já levou milisegundos.

2010/3/1/c1a3ac190d12cf4604428dcf1910d91f_50924.jpg_669×511 160 KB

#139

aqui um exemplo com c#

[code]using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;

namespace csharpbench
{

class MyPoint{
	double x;
	double y;
};

class Program
{

	static MyPoint p;
	static bool x;
	public static void Main(string[] args)
	{
		Stopwatch s1 = Stopwatch.StartNew();
		for (long i = 0;i < 100000000; i++){
			p = new MyPoint();
		}
		
		s1.Stop();
		Console.WriteLine(s1.ElapsedMilliseconds);
		Console.ReadKey(x);
	}
	
}

}[/code]

saída: 3.846 ms

Aqui usando a stack:

[code]using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;

namespace csharpbench
{

class MyPoint{
	double x;
	double y;
};

class Program
{

	static MyPoint p;
	static bool x;
	public static void Main(string[] args)
	{
		Stopwatch s1 = Stopwatch.StartNew();
		for (long i = 0;i < 100000000; i++){
			MyPoint p;
		}
		
		s1.Stop();
		Console.WriteLine(s1.ElapsedMilliseconds);
		Console.ReadKey(x);
	}
	
}

}[/code]

saida: 0.542 ms

Pode ser otimizado usando unsafe, e gerenciando memória manualmente, em determinados blocos

#140

Julio, eu não entendi este seu ultimo exemplo com C#, quando dentro do for vc faz o

MyPoint p;

Vc não esta alocando um objeto MyPoint na stack igual vc estaria fazendo com C++, tanto é que se vc colocar um

MyPoint p;
Console.WriteLine(p.GetHashCode());

O compilador vai chorar dizendo “Use of unassigned variable p”

O que parece é que vc declarou um ponteiro vazio, não sei se da para usar isto como comparação não.