"Java não tem performace"

[quote=ovelha]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.

[/quote]

Você tem razão.
Esqueci de mudar a class para struct no código. p está null.
Correção:

Aqui p está constantemente alocado na stack, e dá para observar a diferença

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

namespace csharpbench
{

class Program
{
	struct MyPoint{
		public double x;
		public double y;
	};
	
	        static bool x;

	public static void Main(string[] args)
	{
		Stopwatch s1 = Stopwatch.StartNew();

		for (long i = 0;i < 100000000; i++){
			
			MyPoint p;
			p.x = 0;
			p.y = 0;
			
		}
		
		s1.Stop();
		Console.WriteLine(s1.ElapsedMilliseconds);
		Console.ReadKey(x);
	}
	
}

}[/code]

saída: 0.688 ms

Não pude deixar de ver este tópico que é bem interessante e que não leva a lugar nenhum… :smiley:

Código abaixo em C++: 6 seg
Equivalente em Java : 13 seg.

     char * raw_mem = new char [sizeof (Point)];
     for (long i = 0;i < 1000000000; i++) {
          Point * x = new (raw_mem) Point(0.0, 0.0);
          x->setX(23.98);
          x->~Point();
     }
    delete[] raw_mem;

Você ta chamando o destrutor explicitamente? =Z
Quando fiz isso na faculdade tomei uma bronca do professor que nunca mais ousei fazê-lo novamente hehehe.
O correto não seria um:

 delete x;
 x = NULL;

?

Aqui ele mostra o que eu quero dizer com C++ mais otimizável. No C++, você pode fazer seu próprio gerencimento de memória, tanto que ele tentou emular o que o garbage collector já faz nativamente (não apagar a área de memória reservada).

No C++, o correto não seria fazer desse jeito e sim sobrescrever o new e o delete (mas entendo o benchmark feito dessa forma por questões de simplicidade). Agora, isso não é fácil, e o código do colega mostra que a otimização já começou a gerar um programa consideravelmente mais rebuscado. Já seria mais difícil achar gente que sabe fazer algo assim e mais caro manter esse código. Essa otimização também seria impossível caso o objeto tivesse sido criado dentro de um método, como eu sugeri ali em cima, e é sempre existente no Java.

Agora, você diz que o equivalente em Java levou 13 segundos. Qual foi o seu “equivalente em Java”? O código equivalente mais simples e direto é o postaram ali atrás, e na minha máquina levou pouco mais do que meio segundo.

[quote=Tchello] Você ta chamando o destrutor explicitamente? =Z
Quando fiz isso na faculdade tomei uma bronca do professor que nunca mais ousei fazê-lo novamente hehehe.
O correto não seria um:

 delete x;
 x = NULL;

?[/quote]

Você tem razão. O delete só limpa a área de memória, mas o apontador continua apontando para a area

x---->> 0x???

se x receber null, o ponteiro perde a referencia. É a forma correta de se fazer.

[quote=Tchello] Você ta chamando o destrutor explicitamente? =Z
Quando fiz isso na faculdade tomei uma bronca do professor que nunca mais ousei fazê-lo novamente hehehe.
?[/quote]

Ele chama o destrutor e o construtor explicitamente pois só está interessado no que eles fazem (zerar as variáveis, limpar o ambiente), não na reserva e limpeza da memória. Isso é feito explicitamente por ele, na alocação e desalocação daquele array, e apenas uma vez, antes e depois do for.

Uma coisa interessante aqui. Veja o esforço que estamos fazendo para tentar chegar a um código mais otimizado que o do GC. E mesmo o exemplo extremo do colega ainda levou 6 segundos, contra apenas 1 do Java.

O mais rápido mesmo é alocação e desalocação no stack. Porém, para o programador java, esse gerenciamento é feito de forma transparente, rápida e eficiente pelo gc. Ele em momento nenhum precisou se preocupar com isso ou comprometer a legibilidade do próprio código.

Entretanto, no C++, foi possível chegar a uma solução mais rápida. Poderíamos mesmo sobrescrever o new e o delete, fazer um memory manager otimizado exclusivamente para a classe point, alinhado até mesmo com detalhes de nosso processador. Seria caro, custaria esforço, mas seria possível. Se é viável ou não, só o nosso negócio poderá dizer, mas já vi casos disso na indústria de jogos, por exemplo.

Entendi agora Vini.
Tem muito tempo que não programo em C++ e quando o fiz foi em projetos puramente acadêmicos e nada muito complexo.

Abraços.

o tipo auto_ptr da biblioteca( #include<memory.h> ) padrão implementa um coletor de lixo automatico, mas não é robusto como o gc do java pelas experiências que tive.

auto_ptr<Pointer> point(new Pointer());

A performance cai consideravelmente. Mas acredito que os smart pointers da boost sejam mais otimizados.

São sim, além de existirem vários tipos de Smart Pointer na boost, o shared_ptr e o scoped_ptr parece que irão entrar na próxima versão do C++.