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
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
[/quote]
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…
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.
[quote=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.
[/quote]
[quote=windsofhell][quote=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.[/quote]
So o Chuck Norris faz isso. :)[/quote]
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…
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;
É muitíssimo difícil fazer um bechmark que seja confiável, e reflita uma situação real de uso;
É 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”);
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.
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:
Operações de entrada e saída;
Bugs no código;
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