Quem tem a melhor perfomance ? Java X C

http://www.guj.com.br/posts/list/52368.java#275499

ricardo13:

olá galera,

Ontem na sala de aula teve uma pequena discussão sobre quem é mais rápido C ou Java ???

Dai os defensores de Java disseram q Java pode ser um poko mais lento pelo fato da JVM …E Java sugiu para ser portável…não interessando o desempenho…mas q JAVA está quase q ao msm nivel de desempenho que a linguagem C.

Outros falaram q C é mais rápido … mas tem o tempo de desenvolvimento inferior ao JAVA

Daí queria saber a opinião da Galera do Guj com relação a essa questão

Muito Obrigado

Ricardo

Se você jogar os dois livros do Bruce Eckel de cima de um prédio, creio eu que terão praticamente a mesma velocidade no final da queda…

http://shootout.alioth.debian.org/

Quem liga quando temos assembly?

Assembly é coisa de frouxo!!!

Programador de verdade programa em binário. E só precisa de 3 teclas: 0, 1 e Enter (pra rodar o programa)

E antes que alguem pergunte, programador de verdade nunca precisa do backspace. Ele nunca erra.

Tirando a brincadeira de lado, acho impressionante como, nas faculdades de computação, os estudantes e professores se preocupam mais com detalhes de baixo nível das linguagens do que como fazer software correto.

Só uma coisa, esse negócio de qual é mais rápido é estupidez, masturbação mental pura. Complexidade computacional (tipo, se é O(log n) ou O(n^2) ) ou facilicidade de manutenção costumam contar mais.

Leonardo3001:

Tirando a brincadeira de lado, acho impressionante como, nas faculdades de computação, os estudantes e professores se preocupam mais com detalhes de baixo nível das linguagens do que como fazer software correto.

Só uma coisa, esse negócio de qual é mais rápido é estupidez, masturbação mental pura. Complexidade computacional (tipo, se é O(log n) ou O(n^2) ) ou facilicidade de manutenção costumam contar mais.

Concordo em grau, gênero e número!

Hehe. Poco Chuck Norris hein.

josenaldo:

Assembly é coisa de frouxo!!!

Programador de verdade programa em binário. E só precisa de 3 teclas: 0, 1 e Enter (pra rodar o programa)

E antes que alguem pergunte, programador de verdade nunca precisa do backspace. Ele nunca erra.

So o Chuck Norris faz isso.

windsofhell:

josenaldo:

Assembly é coisa de frouxo!!!

Programador de verdade programa em binário. E só precisa de 3 teclas: 0, 1 e Enter (pra rodar o programa)

E antes que alguem pergunte, programador de verdade nunca precisa do backspace. Ele nunca erra.

So o Chuck Norris faz isso. :)

hehe, grande coisa, o macgyver programa usando 0 e 1 tb, porém encostanco fiuzinho para fechar circuito ou deixando aberto para 0… isso é claro q se ele não improvisar de alguma outra forma com equipamentos totalmente improvaveis pelos quais eu não vo nem comentar…

1. Se o programa não for orientado a processamento (e a absurda maior não é), não há sentido em falar na velocidade da linguagem, já que ela não será o lugar onde o programa ficará parado;
2. É muitíssimo difícil fazer um bechmark que seja confiável, e reflita uma situação real de uso;
3. É mais difícil ainda no Java, já que a linguagem tem uma VM, que faz otimizações em Runtime e, em muitos casos, monta caches internos (o que garante uma primeira execução mais lenta, mas mais performance no “long run”);
4. Se necessário, é possível otimizar até o último bit em C, o que vai certamente resultar num código mais rápido. Mas isso é caro, trabalhoso e extremamente sujeito a erros.
5. Fuja dos mitos de performance. Nesse campo, fala-se muita besteira.

Eu trabalho no meu dia-a-dia com sistemas de tempo real, tanto em Java, quanto em C e C++.

Por isso, precisamos muito de performance e código otimizado. Porém, em 99.99% dos casos isso é possível simplesmente fazendo um código bem-feito. Claro, muitas vezes temos que rodar profilers e retirar gargalos, mas nunca precisamos trocar de linguagem ou fazer nada muito rebuscado para isso. Aliás, um código bem estruturado contribui até para que o profiler dê resultados mais precisos.

Geralmente, os problemas de performance são, nessa ordem:

1. Operações de entrada e saída;
2. Bugs no código;
3. Má escolha de algoritmos;

É importante ressaltar que mitos de performance geralmente são parcialmente reais. Por exemplo, os métodos sincronizados em Java tem, sim, um overhead em relação a métodos comuns. Da mesma forma, existem oportunidades de otimização com const. Ou o goto é realmente mais rápido que os loops. O problema é o exagero que vem disso. Embora tudo isso seja verdade, praticamente nunca é recomendável substituir uma construção por outra, ou uma linguagem por outra, porque também praticamente nunca esse será o seu gargalo. Praticamente nunca a diferença será perceptível para o seu usuário. E, em termos de performance, se ele não vê, não há problema.

He he he… Entrei no fórum para ler esse tópico…em vez de chegar a alguma conclusão sobre o assunto, fiquei sabendo mais sobre a programação do Chuck Norris e o Macgyver