Vitor Pamplona
Crônicas de um cotidiano geek

JavaVsC com Processadores CoreX

Postado em Sep 18, 2008 por Vitor Pamplona - Editar - História

 Até hoje, quando me perguntavam sobre java e performance, eu dizia que a performance do java é igual a do C + +. Há algumas oscilações dependendo do formato do programa, mas estas diferenças não são significativas. Quando vi este post, logo pensei: " Ok, vamos ver qual a cagada que ele fez para dizer que Java é 2x mais rápido que C + + ". De fato, C + + estava executando 1 milhão de operações enquanto as outras linguagens apenas 100 mil (apesar de ele dizer que não isso não faz diferença, o_O). Além disso, ele não está considerando a carga das VMs que, no C + + não existe.

No entanto, eu gostei dos códigos. Fiz o download (Java e C + +), aumentei para 10 milhões o número de iterações, removi a coleta de tempo e mandei rodar usando o time no meu Core 2 Duo, com 2GB de RAM e Ubuntu 8.04 32 bits. Isso garantiria que o tempo de carga da VM seria levado em conta. Para minha surpresa, java foi 3 vezes mais rápido que C + +, mesmo com o código do C + +   compilado com O3. Pensei: " não pode. Tem algo errado nessa comparação ". Fiz inúmeros testes no código C + +, ativando e desativando flags do gcc, modificando código e por aí vai. Nada de melhorar a performance.

vitor@vitor-laptop:~/Desktop$ g++ Chain.cpp -O3
vitor@vitor-laptop:~/Desktop$ javac Chain.java
vitor@vitor-laptop:~/Desktop$ time java Chain
real    0m7.932s
user    0m7.744s
sys     0m0.112s
vitor@vitor-laptop:~/Desktop$ time ./a.out
real    0m23.484s
user    0m23.233s
sys     0m0.228s
vitor@vitor-laptop:~/Desktop$

Cheguei a duas alternativas: Ou esta rapidez vem da reserva de memória que a VM faz ao iniciar o programa e, portanto, da inexistência de comunicação intensa com o SO, ou o java estaria paralelizando o loop de Chain. Para evitar a segunda hipótese, modifiquei ambas a versões para ficarem um pouco mais complexas, evitando alguma paralelização automática do java durante a compilação do código.

Versão C + +

#include <stdio.h>

class Person
{

public:
Person(int id, int count) : _next(NULL), _prev(NULL) { _count = count; _id = id; }
int shout(int shout, int nth)
{
if (shout < nth) return (shout + 1);
_prev->_next = _next;


_next->_prev = _prev;
return 1;
}
int count() { return _count; }
Person* next() { return _next; }
void next(Person* person) { this->_next = person ; }
Person* prev() { return _prev; }
void prev(Person* person) { this->_prev = person; }
private:
int _count;
int _id;
Person* _next;
Person* _prev;
};

class Chain
{
public:
Chain(const int id, const int size) : _first(NULL), _id(id)
{
Person* current = NULL;
Person* last = NULL;
for(int i = 0 ; i < size ; i++)
{
current = new Person(id + i, i);
if (_first == NULL) _first = current;
if (last != NULL)
{
last->next(current);
current->prev(last);
}
last = current;
}
_first->prev(last);
last->next(_first);
}
Person* kill(const int nth)
{
Person* current = _first;
int shout = 1;
while(current->next() != current)
{
Person* tmp = current;
shout = current->shout(shout,nth);
current = current->next();
if (shout == 1)
{
delete tmp;
}
}
_first = current;
return current;
}
Person* first() const { return _first; }
private:
Person* _first;
int _id;
};

int main(int argc, char** argv)
{
const int ITER = 10000000;
for(int i = 0 ; i < ITER ; ++i)
{
Chain* chain = new Chain(i, 40);
chain->kill(3);
delete chain;
}
return 0;
}

Versão Java

public class Chain
{
private int id;
private Person first = null;

public Chain(int id, int size)
{
this.id = id;
Person last = null;
Person current = null;
for (int i = 0 ; i < size ; i++)
{
current = new Person(id + i, i);
if (first == null) first = current;
if (last != null)
{
last.setNext(current);
current.setPrev(last);
}
last = current;
}
first.setPrev(last);
last.setNext(first);
}

public Person kill(int nth)
{
Person current = first;
int shout = 1;
while(current.getNext() != current)
{
shout = current.shout(shout, nth);
current = current.getNext();
}
first = current;
return current;
}

public Person getFirst()
{
return first;
}
public static void main(String[] args)
{
int ITER = 10000000;
for (int i = 0 ; i < ITER ; i++)
{
Chain chain = new Chain(i, 40);
chain.kill(3);
}
}
}

class Person
{
int id;
int count;
private Person prev = null;
private Person next = null;

public Person(int id, int count)
{
this.count = count;
this.id = id;
}

public int shout(int shout, int deadif)
{
if (shout < deadif) return (shout + 1);
this.getPrev().setNext(this.getNext());
this.getNext().setPrev(this.getPrev());
return 1;
}

public int getCount()
{
return this.count;
}

public Person getPrev()
{
return prev;
}

public void setPrev(Person prev)
{
this.prev = prev;
}

public Person getNext()
{
return next;
}

public void setNext(Person next)
{
this.next = next;
}
}

Rodei e vejam só: Nenhuma diferença. Os tempos foram muito parecidos com os que relatei anteriormente. Mas, desta vez, fiquei de olho no processamento e na memória. Deem uma olhada e vejam a mágica do Java:

Primeiro: Ele paralelizou! Usou os meus processadores automaticamente. Talvez um processo para a VM e o GC e outro para o meu programa, mas ele paralelizou e diminuiu tempo de processamento com isso. Com o C + + só um processador foi utilizado e, até onde eu entendo, o C + + não vai conseguir fazer um bom uso dos dois processadores por limitações da própria linguagem. Engraçado, é que não importa quantas vezes eu execute, o gráfico de processamento do java é semelhante a este da figura (pra não dizer igual).

Segundo: Olhem o gasto de memória. Em C + +, nem o sistema operacional, nem o compilador reaproveitou a memória dos " deletes ", tanto das Person, quanto das Chain. Já em Java, a memória permaneceu constante, como deveria, obviamente este é um dos benefícios de ter uma carga da VM com reserva de memória.

A meu ver, uma linguagem é mais rápida do que a outra quando sua performance é superior sem alterar o paradigma ou o modo de programação (Pode-se alterar a sintaxe e adicionar palavras-chave, mas não pode mudar o paradigma). Manter seu código legível e limpo é essencial. Como vocês podem ver, os códigos são praticamente iguais, só muda detalhes de sintaxe. Certamente, a versão em C + + poderia criar um buffer gigantesco no início do programa e trabalhar sobre ele, mas francamente, quem iria fazer isso?:)

Conclusão: Se você precisar construir um programa com muita alocação e desalocação de memória, escreva em Java. Se você vai rodar o seu código em um x-Core, faça o programa em Java. Caso contrário, faça em C + +.  

Lanço um desafio a todos os programadores C + + de plantão a me apresentar uma versão do código e da linha de compilação que execute mais rápido que a versão em java que apresentei. Lembrando, não quebre o formato do código.  

Alguém aí tem o MS Visual Studio Professional para fazer o teste com aquele Ultra-top-highlevel bytecode generator dele? Porque, pra mim, C + + de agora em diante, é lento!

Update: Me pediram para fazer 40 Chains de 1000000 de elementos para testar. Java foi 3 vezes mais rápido, novamente.

vitor@vitor-laptop:~/Desktop/Comparativo$ javac Chain.java
vitor@vitor-laptop:~/Desktop/Comparativo$ time java Chain
real 0m6.107s
user 0m7.824s
sys 0m0.132s
vitor@vitor-laptop:~/Desktop/Comparativo$ g++ Chain.cpp -O3
vitor@vitor-laptop:~/Desktop/Comparativo$ time ./a.out
real 0m16.819s
user 0m16.713s
sys 0m0.056s

Fizemos um teste com o OpenMP para tentar paralelizar o código original do C + +, mas infelizmente o OpenMP tem se revelado um tanto lento. Como resultado, apesar de ele ter utilizado os dois processadores, o tempo de processamento foi superior:

vitor@vitor-laptop:~/Desktop/Comparativo$ g++ Chain.cpp -O3 -fopenmp
vitor@vitor-laptop:~/Desktop/Comparativo$ time ./a.out
real 0m38.809s
user 0m37.503s
sys 0m0.276s

Resumo dos comentários do pessoal de C + +: Se vc implementar uma VM em baixo do C + + ele fica rápido.

Comentários


Pois é Vitor,

Um produto com mais de 10 anos de desenvolvimento, com uma equipe de gurus como o James tinha que deixar o Java neste estágio. Se tu parar para pensar um instante e lembrar que muito eles apanharam e foram chamados de lentos e aproveitaram todo o feedback da comunidade para evoluir... então os teus testes deram a lógica!.
Parabéns para SUN, parabéns para o JAVA e a todos aqueles que aprendem com as criticas e sabem fazer delas motivos para crescer.

- - Leandro
Postado em Jul 17, 2008 por 189.27.215.152

A questão do tempo não importou muito. C + + é mais antigo que Java:)

E eu ainda quero fazer alguns testes de interface com o Java, creio que o Swing ainda é lento comparado a outras engines como o GTK ou o Qt.
Postado em Jul 17, 2008 por Vitor Pamplona

Olá Vitor, eu copiei e colei o código para rodar aqui. Mas ocorre o erro de compilação na linha 50

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
$ javac Chain.java
Chain.java: 50: cannot find symbol
symbol: class delete
location: class Chain
delete chain;
^
Chain.java: 50: chain is already defined in main (java.lang.String [])
delete chain;

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mas não tem nenhum método " delete ".

- - Claudio Miranda
Postado em Jul 17, 2008 por 189.6.80.4

Foi mal, botei o delete no código errado. Era no C + +. Já corrigi.
Postado em Jul 17, 2008 por Vitor Pamplona

Fiz o teste com o JDK 6u10, com as opções abaixo e consegue uma redução de tempo de cerca de 2s, faça este teste por favor. Tentei outras otimizações (desabilitar young generation, debug off, diminuir YGC), mas não valeram a pena, ganhou cerca de 50ms
Como é microbenchmark, tá valendo:)

- server - Xverify: none

- - Claudio Miranda
Postado em Jul 17, 2008 por 189.6.80.4

Fala Vitor,
Muito bom esse seu benchmark... Impressionante como o Java evoluiu muito desde a época que só servia para fazer applets até os dias de hoje. Abraços

- - Roberto Furutani
Postado em Jul 17, 2008 por 189.29.75.167

Bah Vitor,

Otimizei um pouco a versão de C + +, usei a TBB para paralelizar o loop principal e a Boost.pool para alocação. Consegui estreitar um pouco os resultados mas java ainda foi mais rápido.

O processador usado foi um Pentium Dual E2140 @ 1.60GHz.

O t.cpp é versão modificada e a n.cpp é a original.

otavio @ paris: ~ $ g + + - O3 - fno-exceptions n.cpp
otavio @ paris: ~ $ time. / a.out
real 0m48.339s
user 0m47.455s
sys 0m0.384s
otavio @ paris: ~ $ g + + - O3 - fno-exceptions t.cpp - ltbb
otavio @ paris: ~ $ time. / a.out
real 0m14.773s
user 0m27.946s
sys 0m0.592s
otavio @ paris: ~ $ javac Chain.java
otavio @ paris: ~ $ time java Chain
real 0m12.723s
user 0m12.225s
sys 0m0.200s

Pelo menos foi um bom exercício.

Versão modificada:
# include < stdio.h >
# include < tbb / task_scheduler_init.h >
# include < tbb / parallel_for.h >
# include < tbb / blocked_range.h >
# include
# include < boost / pool / object_pool.hpp >

class Person
{
public:
Person (int id, int count): _next (NULL), _prev (NULL)
{_count = count; _id = id;}

int shout (int shout, int nth)
{
if (shout < nth) return (shout + 1);

_prev - > _next = _next;
_next - > _prev = _prev;
return 1;
}
int count () {return _count;}
Person * next () {return _next;}
void next (Person * person) {this - > _next = person;}
Person * prev () {return _prev;}
void prev (Person * person) {this - > _prev = person;}

private:
int _count;
int _id;
Person * _next;
Person * _prev;
};

class Chain
{
public:
Chain (const int id, const int size, boost:: object_pool * pool): _first (NULL), _id (id),
_pool (pool)
{
Person * current = NULL;
Person * last = NULL;
for (int i = 0; i < size; i + +)
{
current = _pool - > malloc ();
* current = Person (id + i, i);

if (_first = = NULL) _first = current;
if (last! = NULL)
{
last - > next (current);
current - > prev (last);
}
last = current;
}
_first - > prev (last);
last - > next (_first);
}

Person * kill (const int nth)
{
Person * current = _first;
int shout = 1;
while (current - > next ()! = current)
{
Person * tmp = current;
shout = current - > shout (shout, nth);
current = current - > next ();
if (shout = = 1)
{
_pool - > free (tmp);
}
}
_first = current;
return current;
}

Person * first () const {return _first;}

private:
Person * _first;
int _id;
boost:: object_pool * _pool;
};

struct ParLoop
{

void operator () (const tbb:: blocked_range &range) const
{
boost::object_pool chain_pool;
boost:: object_pool person_pool;
for (int i = range.begin (); i < range.end (); + + i)
{
Chain * chain = chain_pool.malloc ();
* chain = Chain (i, 40, &person_pool);
chain - > kill (3);
chain_pool.free (chain);
}
}
};

int main (int argc, char * * argv)
{
const int ITER = 10000000;
tbb:: task_scheduler_init init;

ParLoop loop;
tbb:: parallel_for (tbb:: blocked_range (0, ITER),
loop, tbb:: auto_partitioner ());

return 0;
}


- - Otávio
Postado em Jul 17, 2008 por 189.6.239.233

ah, fazendo isso
boost:: object_pool chain_pool;
for (int i = range.begin (); i < range.end (); + + i)
{
Chain * chain = chain_pool.malloc ();
boost:: object_pool person_pool;
* chain = Chain (i, 40, &person_pool);
chain - > kill (3);
/ / chain_pool.free (chain);
}

e comentado isso

if (shout = = 1)
{
/ / _pool - > free (tmp);
}

A versão c + + ficou mais rápida (no " real " time pelo menos):

otavio @ paris: ~ $ time. / a.out
real 0m8.233s
user 0m16.145s
sys 0m0.232s
otavio @ paris: ~ $ time java Chain
real 0m12.855s
user 0m12.417s
sys 0m0.144s



- - Otávio
Postado em Jul 18, 2008 por 189.6.239.233

Eu acho injusto a comparação porque em Java você sempre tem que alocar objetos, e alocação dele é muito mais rápido do que em C + + (devido a otimizações de garbage e tal). O correto na minha opinião é reproduzir o algoritmo, não o programa. Tirar as alocações que do ponto de vista C + + são na maioria inúteis (o chain no loop principal pro exemplo).

Sem contar que não rodou o teste numa máquina com apenas um processador: P.
Onde o multithreading do garbage collector adicionaria overhead considerável.

anyway..

- - chackal_sjc
Postado em Jul 18, 2008 por 69.159.123.136

Bah, tô sem nada pra fazer nessas férias, a não ser encher os sacos do blogueiros do qual assino os feeds... dá pra fazer isso:

boost:: object_pool chain_pool (range.end () - range.begin ());
for (int i = range.begin (); i < range.end (); + + i)
{
boost:: object_pool person_pool (40);
....

otavio @ paris: ~ $ time. / a.out
real 0m5.250s
user 0m10.305s
sys 0m0.180s


- - Otávio
Postado em Jul 18, 2008 por 189.6.239.233

Uhu! Boost rox!

- - Rafael
Postado em Jul 18, 2008 por 201.41.188.10

Conclusão do post: " Programador Java não sabe programar em C + + ".

- - Hugo
Postado em Jul 18, 2008 por 189.13.242.76

Hugo,

Conclusão é que no C + + vc não pode programar orientado a objetos, tem que programar orientado a buffers.

chackal_sjc,

A comparação não é injusta. Estamos comparando o que a liguagem faz com o teu código para otimizá-lo. C + + (Até mesmo a versão professional do VS) só consegue faz algumas reduções sintáticas. O resto, o programador que se vire para trabalhar com buffers de memória.

- - Vitor Pamplona
Postado em Jul 18, 2008 por 200.180.59.199

Otávio,

Me mostraram ontem uma versão desse código em que apenas uma variável Chain é instanciada e todas as outras 10 milhões são apenas cópia direta da memória dela, reservada previamente através de um std:: vector. Neste caso, o código roda em tempo 0.1seg.

Para o trecho de código que eu mostrei, esta solução para o C + + era a ideal, no entanto duvido muito que no mundo real poderemos simplesmente duplicar objetos ao invés de instanciá-los.

Outra versão que me mostraram manipula diretamente a memória e rodou em 0.05 seg. No entanto, o código é completamente ilegível, mesmo para programadores C + +.

- - Vitor Pamplona
Postado em Jul 18, 2008 por 200.180.59.199

Com certeza!
Pra saber qual é mais rápido temos que executar " O MESMO " código!
Não vejo nada de injusto na comparação...
" Ah, mas pode adicionar isso e retirar aquilo... "
Isso não é comparação com um " MESMO " código.
Na minha opnião o resultado está bem válido, e principalmente, bem fundamentado.
Parabéns, Vitor.

- - Eros Stein
Postado em Jul 18, 2008 por 201.79.86.68

Copiar as instancias de Chain já é patifaria com o problema...

Por curiosidade, essas versões mais rápidas que você rodou usaram algum tipo de paralelismo?

- - Otávio
Postado em Jul 18, 2008 por 189.6.239.233

Nopes. Todas monothread.

[] s

- - Vitor Pamplona
Postado em Jul 18, 2008 por 201.35.216.212

Vitor,

Cada linguagem tem o seu conjunto de vantagens e desvantagens, a sua melhor forma de resolver um determinado problema e, consequentemente, é mais apropriada para certas aplicações que outras. O seu benchmark está testando basicamente alocação dinâmica de objetos e se aproveitando do recurso de garbage collection que não é nativo no C + +. Aliás, o código C + + está deixando de liberar objetos alocados o que talvez tenha influência nos tempos (mais provavelmente aumentando o tempo do C + +).

Agora, dizer que o C + + não é orientado a objeto porque não tem garbage collection, é chutar abaixo da linha da cintura, espero que seja apenas brincadeira e não ignorância.

Em http://groups.google.com/group/ccppbrasil/browse_thread/thread/d8f94dc5356ebdef/21fb664bbdf69cc7?hl=pt-BR & você encontra algumas discussões do pessoal do C++ sobre porque o código que você mostrou é mais lento e como existem alternativas mais eficientes (porém diferentes) em C++ (como o pool de objetos no comentário do Otávio).

Sobre o que é justo e injusto, veja em http://shootout.alioth.debian.org/gp4/faq.php#means ;)

- - Daniel
Postado em Jul 20, 2008 por 201.76.248.144

g + + pra mim não seria o melhor compilador pra testar.

Usaria o ICL pra Linux (e talvez para o Win32).

- - Aldrin Leal
Postado em Jul 21, 2008 por 189.82.173.195

Oi Daniel,

Revisei o código e não vi onde o código C + + está deixando de liberar memória. Pode me indicar como ocorre?

Falando em justiça, eu fiz um teste com a versão que me mandaram onde o C + + aloca todos os Chains no início e que roda em 0.1 segundos. Se eu alocar da mesma maneira em java, também obtenho esse tempo, a diferença não é significativa. Como o código em C + + que me mandaram está liberando memória indevidamente (por causa dos buffers) e as vezes chega a um Segmentation Fault, ainda não postei aqui.

[] s
Postado em Jul 21, 2008 por Vitor Pamplona

Oi Aldrin,

Não sei se o compilador vai ajudar, pois mesmo o compilador do Visual Studio profissional que, normalmente aumenta significativamente a performance, não adiantou.

[] s
Postado em Jul 21, 2008 por Vitor Pamplona

Bom! Eu achei interessante, o comparativo pois estou novamente estudando as duas linguagem para uma realização de um projeto, e além desses requisitos estou procurando principalmente portabilidade, o java até agora tem se sobresaido nessa questão, mas eu preciso de algo mais, por exemplo não posso ficar dependendo da VM pois os projetos teriam que rodar diretamente de um PenDriver, pois o cliente nem sempre estara na frente do micro hospedeiro, e se o programa rodar direto do PenDriver, então ele terá uma mobilidade bem maior, até o momento eu uso o Delphi e ele carrega todo o ambiente possibilitando o tal feito; ai eu pergunto? existe alguma possibilidade de tudo isso acontecer com o java ou C + + por exemplo

Atenciosamente

Marcos Paulo dos Santos
Técnico em Processamento de dados).

E-Mail: mps_inf@hotmail.com
Blog: http://www.mpsinf.blogspot.com /

- - Marcos Paulo dos Santos
Postado em Jul 24, 2008 por 189.120.101.234

Se você fizer em Delphi não vai rodar em Linux / FreeBSD e MacOS. Se fizer em Java, o cliente terá que ter a VM instalada, independente de SO (ou você pode pedir para ele instalar quando executar o programa). Se fizer em C + + vc terá uma versão compilada para cada arquitetura e SO junto com as bibliotecas dependentes.

[] s
Postado em Jul 24, 2008 por Vitor Pamplona

Ola Vitor,

para rodar o exemplo vc usa algum parametro a mais na linha de comando, como por exemplo:
java - Xmx256m - Xms256m code.Teste

ou usa a linha de comando tradicional
java code.Teste

e existe algum parametro para aumentar a performance??? estou falando isso pois só conheço esses dois mesmo (Xmx e Xms) rs...

[] ´ s

- - Felipe Regalgo
Postado em Jul 28, 2008 por 200.211.188.207

Rodei com os parâmetros default mesmo.

[] s

- - Vitor Pamplona
Postado em Jul 28, 2008 por 189.27.250.77

Primeiro, existe codigo C + + e codigo C / C + +... o codigo apresentado esta mais para C do que C + +. Em C + + temos a STL para containers, nao precisamos ficar reinventando a roda. Ja vi testes bem melhores para comparar C / C + + / Java /. NET que sao excelentes linguagens para solucao de problemas de software, cada uma no seu dominio. Nao é um teste destes que vai definir qual a linguagem de programacao mais adequada para o teu problema. Ate pq...

class Person
{
public:
Person (int id, int count): _count (count), _id (id)
{
}
private:
int _count;
int _id;
};

class Chain
{
public:
Chain (const int id, const int size)
{
/ / humm, uma lista duplamente encadeada com insercao ao final da lista
/ / que na verdade pode ser representada por um vector pois o tamanho eh definido por size
vector_.reserve (size);
for (int i = 0; i < size; i + +)
vector_.push_back (Person (id + 1, i));
}
/ / o retorno de kill nunca eh usado, void nele
void kill (const int nth)
{
vector_.erase (vector_.begin () + nth);
}
private:
vector vector_;
};

int main (int argc, char * * argv)
{
const int ITER = 10000000;
for (int i = 0; i < ITER; + + i)
{
/ / se vai criar e destruir no mesmo laco, use a pilha!
Chain chain (i, 40);
chain.kill (3);
}
return 0;
}

$: ~ / teste$ g + + - o teste - O2 main.cpp
$: ~ / teste$ time. / teste

real 0m3.854s
user 0m3.856s
sys 0m0.000s


- - prii
Postado em Jul 28, 2008 por 201.21.241.228

Prii... Czinho não tem nem classes:)

E se for para usar a STL, em Java também tem um monte de API que posso usar e vários outros recursos, de maneira que a comparação deveria entre o seu código e este outro em Java. Já te digo que terá uma performance superior ou tecnicamente semelhante, pois o Java continuará paralelizando enquanto o C + + permanecerá monothread.
Postado em Jul 28, 2008 por Vitor Pamplona

Depois de ver o tal do JDeveloper ocupar 170MB de RAM só pra abrir e 300 MB pra fazer coisas básicas, não tem como evitar de achar Java lento (bom, eu falei da memória, mas a velocidade percebida neste caso é inversamente proporcional ao uso de memória). Não adiantam benchmarks se no uso normal se vê outra coisa. Talvez seja problema do programa e não da linguagem, mas a minha impressão ruim continua a existir. Alguma idéia pra acelerar essa carroça chamada JDeveloper?

- - Marcus Aurelius
Postado em Aug 6, 2008 por 201.37.150.166

Bah, JDeveloper ninguém merece.

- - Vitor Pamplona
Postado em Aug 6, 2008 por 189.27.239.202

Qual aplicativo tu usaste para criar esses graficos de uso de CPU e Memória?

- - Ricardo Gomes
Postado em Aug 13, 2008 por 200.222.2.246

" Conclusão do post: " Programador Java não sabe programar em C + + ". " (2)

- - rafa
Postado em Aug 14, 2008 por 189.69.18.30

Conclusão do post 3: Programadores C + + não sabem programar!

- - Marcos Kraus
Postado em Aug 14, 2008 por 189.27.227.89

Eu não acho o ideal comparar códigos quase idênticos. Cada linguagem tem suas peculiaridades e suas peculiaridades.

Pra mim, C + + é bom justamente pelo fato de deixar você organizar um pouco melhor o código, mas ao mesmo tempo meter a mão na otimização se precisar.

Java é muito bom pra deixar tudo organizado e um bom desempenho, mas, pra mim, em Java é difícil torcer o programa pra deixar o mais enxuto possível.

Enfim, nas minhas não muitas experiências com ambas linguagens, de fato Java foi mais lento. Acho que depende muito da aplicação.

- - Felipe Hummel
Postado em Aug 14, 2008 por 201.75.18.138

Marcos Kraus,

Quando vc tava na fralda as pessoas já faziam programs em C e C + +.

Segundo ponto, desafio é cada um fazer seu algoritmo optimizado e testar, Java usando o seu melhor e C + + o seu melhor. Claro q se formos trazer o C para a plataforma X-Core não teremos uma competição justa, não sei se o C + + foi idealmente optimizado para essa plataforma.

Agora testar com " retrições " é o mesmo que fizeram na F1 com o Schumacher, é mais bonito pedir pra ele parar.

O mesmo cabe aqui, é melhor vcs pedirem pra aprender a programar em C + + do que colocar desafios idiotas sobre a plataforma q mais gerou linhas de código no mundo.

Quando eu estudei C, Java tava na fralda. Vamos por exemplo brincar de Geometria espacial e ver o Java em cálculos Double absurdos... Ridiculo!

Cada macaco no seu galho.

- - Rafael
Postado em Aug 14, 2008 por 189.79.86.93

É engraçado ver como o pessoal de C + + fica irritado com esse post. Como não tem como argumentar eles me chingam, mas tudo bem.

O detalhe é que se for para fazer miséria em C + + eu também faço miséria em Java, inclusive manipulando diretamente a memória, e posso garantir que, num CoreX, vai rodar mais rápido.

O Rafael mesmo falou, C + + não foi feito para CoreX. Até trabalhar com threads é um parto no C + +.

Rafael, mesmo C sendo muito mais antigo, a VM do Java tem mais informação para poder trabalhar e otimizar o código, evitando que o programador gaste tempo com otimização de código e ainda eliminando os possíveis erros que essa otimização pode criar.

[] s

- - Vitor Pamplona
Postado em Aug 14, 2008 por 189.27.227.89

Blá, blá, blá! A velha discussão de quem é melhor: o super-mega-power Java ou o coitadinho-velho-fraco do C. Programo nas duas linguagens, e cada uma delas tem seus pontos fortes e fracos. Quero ver alguém de Java manipular ponteiros, e que atirem a primeira pedra quem nunca sofreu pra fazer telas em C + + usando MFC (windows) ou Mono (Linux). Blá! Tudo conversa de neguinho que não tem o que fazer.

- - Kívia Kelen
Postado em Aug 15, 2008 por 200.208.98.2

Eu também programo nas duas Kívia e não acho que fazer benchmarks seja " conversa de neguinho que não tem o que fazer ".

Conhecer a fundo, fundo mesmo, as linguagens que trabalhamos é nosso papel. Benchmarks são estudos práticos para indicar qual linguagem é mais rápida em qual situação. Com esta informação, podemos decidir melhor as tecnologias que utilizamos.

[] s
Postado em Aug 15, 2008 por Vitor Pamplona

O unico problema é a metodologia falha que vc empregou pra fazer o benchmark.
Alias se vc ler as proprias respostas aqui, vc vai encontrar links para discussoes uteis sobre esse codigo em c + +, o porque do desempenho, e sobre como fazer benchmarks de forma bem mais confiavel.
Java tem sim suas aplicacoes, mas comparar desempenho com c / c + + eh pura heresia...

- - Luis
Postado em Aug 16, 2008 por 201.75.21.34

Conclusão do post (e dos comentários) 4: Programadores C + + não sabem perder!

- - Vinicius de Paula
Postado em Aug 16, 2008 por 189.27.227.89

O que vale desse post é que se não programar em baixo nível em ambas as linguagens, java é muito mais rápido.

Valeu Vitor!

- - Wanderlei
Postado em Aug 16, 2008 por 189.27.227.89

O mais engracado, é que varios programadores java " diferentes " aqui postaram com o mesmo ip. Inclusive um que se intitulou com o nome do autor do texto.
Neguinho quer ganhar no grito hauhauahauahu.

- - Luis
Postado em Aug 16, 2008 por 201.75.21.34

Bah, eu mereço mesmo.

Luis, eles são colegas meus. Eles postaram com o meu note, quando mostrei os resultados aqui em casa. O Vinicius e o Wanderlei queriam baixar o tempo do Java, depois que o Leandro Oliveira (UOL) mandou um código que roda um pouco mais rápido que aquela versão da Boost postada no comentário. Eles estavam, ham... meio alterados, digamos assim, mas pelo menos não chingaram ninguém:)

Mas fico feliz que o meu blog seja foco de investigações. Que tal investigar se os 15 dólares de adsense que eu ganhei só por causa deste post não foram todos cliques meus?

[] s



- - Vitor Pamplona
Postado em Aug 16, 2008 por 201.86.193.230

Programo um pouco em Java e encontrei este post enquanto procurava comparativos entre as duas linguágens.
A minha dúvida é: por que os programadores de C + + não " otimizam " este código e o comparam com o que foi feito em Java? Ao invés disso ficam falando que tem um monte de coisas erradas. Falar é fácil...

A conclusão que tiro é: enquanto o Java faz o C + + fala.

Muito bom este trabalho Vitor!



- - M.A
Postado em Sep 8, 2008 por 143.107.97.156


Programo nas duas linguagens e minha opinião é a seguinte:

Quer ficar careca e trabalhar dobrado? Use C + +.
Seu programa exige performace inigualável? Use Assembly, vc vai trabalhar triplicado.
Que agilidade um código limpo e um excelente resultado? Use Java.

- - Ferrarezi
Postado em Sep 12, 2008 por 189.10.94.94

Todo mundo disse, falou muita coisa, mas vale lembrar, que Java tem seu campo e C / C + +, também tem o seu. Neste benchmark, prevaleceu o Java. O código em C + + poderia ser melhor? Sim, também poderia. Mas o Java, também poderia continuar melhor, também poderia. O que quero dizer, é que somente um teste, não vai dizer quem é melhor, e se isto puder ser dito algum dia. Também foi dito, que caso você usasse uma aplicação espacial... Eu cito na área de BioInformática, tem-se aplicações que se fossem feitas em Java, iriam demorar bem mais que C / C + +. Este fato faz C / C + + melhor, ou Java Pior? Claro que não. Mas é importante estes testes serem feitos, para que possam ser mostradas as fraquezas e as potencias boas aplicações de uma linguagem, e não um briga insensata.

- - Fagner Caniddo - f_Candido
Postado em Sep 15, 2008 por 200.199.205.31

Todo mundo disse, falou muita coisa, mas vale lembrar, que Java tem seu campo e C / C + +, também tem o seu. Neste benchmark, prevaleceu o Java. O código em C + + poderia ser melhor? Sim, também poderia. Mas o Java, também poderia continuar melhor, também poderia. O que quero dizer, é que somente um teste, não vai dizer quem é melhor, e se isto puder ser dito algum dia. Também foi dito, que caso você usasse uma aplicação espacial... Eu cito na área de BioInformática, tem-se aplicações que se fossem feitas em Java, iriam demorar bem mais que C / C + +. Este fato faz C / C + + melhor, ou Java Pior? Claro que não. Mas é importante estes testes serem feitos, para que possam ser mostradas as fraquezas e as potencias boas aplicações de uma linguagem, e não um briga insensata.

- - Fagner Candido - f_Candido
Postado em Sep 15, 2008 por 200.199.205.31

Bobagem total, o Run-Time do Java usa um série otimizações de memória que não foram inseridas no Código C + +. Outra bobagem é que o código não foi feito com templates que dão pau no Java brincado. A conclusão dos testes é que programador Java não sabe programar em C + +, infelizmente.
Mas continua chorando! Para uma linguagem ganhar um pouquinho de fama ela precisa, pelo menos, começar tentando se comparar com C / C + +.
Continua tentando fazer comparação entre uma plataforma e linguagem (que não tem nada a ver), além de escrever um código desses em C + + que vai ser bem realista e dar muito crédito ao seu trabalho.



- - Pedro
Postado em Sep 18, 2008 por 189.13.56.252

Templates? Cada um que vem aqui representando o C + + fala uma bobagem diferente.

Ok, se eu implementar uma VM em baixo do C + + ele fica rápido.:)

[] s
Postado em Sep 18, 2008 por Vitor Pamplona

Excelente artigo. Parabéns.

- -
josue
www.josuegomes.com

- - josue
Postado em Sep 20, 2008 por 201.47.11.163

Continuando: isto mostra que a Sun fez um bom trabalho na JVM. Mas não é válido para comparação com C + +. Este exemplo basicamente estressa o alocador de memória. Como em Java a liberação de memória pode ser atrasada (pelo uso do GC) a comparação não é ' justa '. Em outras palavras, embora os programas sejam parecidos eles não resultam no mesmo comportamento. Não é possível comparar as duas coisas.


- - josue
Postado em Sep 20, 2008 por 201.47.11.163

Guarde esse tópico por algum tempo e veremos o que os programadores C + + vão dizer quando C + + cair em obsolecencia igual C ANSI, E O JAVA CONTINUAR EVOLUINDO. Java é uma evolução de C + + e só quem é fanático não vê.

Não estou dizendo que C + + e C não servem pra nada, são muito usados AINDA.

- - Ferrarezi
Postado em Sep 26, 2008 por 189.10.94.94

Seu Nome:


Escreva o código existente na figura acima no texto abaixo.