Desempenho Java x C

dae galera,

fiz uns testes de desempenho testando um prog em C e um em Java pra comparar o desempenho, e surpreendentemente Java foi MAIS rapido que C!!!

vale lembrar que os resultados nao sao precisos, pois marquei no relogio pra considerar o tempo da JVM carregar, e mesmo assim java foi mais rapido!

codigoJava:

public class Teste{
 public static void main(String args[]){
  int x = 0;
  for (int i = 0; i < 2000000000; i++){
   x++;
  }
 }
}

codigo C:

int main(){
 long i, x = 0;
 for (i = 0; i < 2000000000; i++){
  x++;
 }
}

OBS: em C, uma variavel long tem 32 bits, o que equivale a uma variavel int em java

fiz 3 testes com cada linguagem

resultados Java:

7 segundos e 53 centesimos
6 segundos e 92 centesimos
6 segundos e 87 centesimos

resultados C:

8 segundos e 53 centesimos
7 segundos e 80 centesimos
7 segundos e 78 centesimos

meu computador em um Atlhon XP 1.8, 512 ddram, eu fiz os testes rodando no Linux, slackware 10.0 com o JDK5.0

esse teste mostra que java nao eh tao lento quanto muita gente pensa… mas vale lembrar que java foi mais rapido nesse teste pq as operacoes com inteiros de java realmente sao mais rapidas que C, mas na maioria dos outros aspectos C eh mais rapido, mas ao contrario do que muita gente pensa, a diferenca eh bem pequena…

show Felipe, o Tiger realmente esta ótimo… mas tenho uma idéia, faça o mesmo com um código como Bubble Sort… algo q realmente processe, ou a série de Fibonacci até X número… e poste os resultados :slight_smile:

Oi

Show de bola isso, nao precisa ser 100% exato nao, o Tiger esta esmagando o C…

Faça o teste com o JDK 1.4.2, eu aposto que Java será mais lento. :slight_smile:

T+

Seguinte, muito simples esse teste… mas não se iludam.

Mude o tipo de dado de long para int no código do C. O tempo deve cair para uns 2/3. Isso porque no código objeto eu preciso uma instrução a mais para carregar a parte alta do inteiro no registrador, isso acontece em cada operação ou atribuição.

Muda para register int veja o tempo cair para 1 ou 2 segundos… o complicador irá gerar o código objeto acessando as variáveis diretamente dos registradores, sem acessar a memória…

me corrijão se eu estiver errado, mas o “long” em C admite valores de ponto flutuante neh ? (ex: 5,6989). E esse tipo de dado leva mais tempo para ser processado do que aqueles que apenas admitem valores inteiros.

mas dé qualquer forma a comparação é válida, C é considerado uma linguagem muito veloz, e o java chegar próximo a ele já mostra que de lento ele só tem a fama (AINDA).

int nao vai funcionar, pq em C o int tem apenas 16 bits, e 2 bilhoes nao cabem em 16 bits… eu repeti o teste agora com o i e o x como register e o resultado foi o parecido: 8 segundos e 48 centesimos…

e eu sei que java nao eh mais rapido que C, eu soh fiz esse teste pra mostrar que nao eh tao lento quanto muita gente pensa… o buble sort acredito que a diferenca sera pequena, mas o quicksort acredito que C vai dar uma surra em java… vou fazer uns testes e depois posto aki…

qnto a usar long ao invez de int em C no primeiro teste, eu fiz um pequeno teste pra verificar isso:

int main(){
 printf("sizeof(int) = %d; sizeof(long) = %d\n", sizeof(int), sizeof(long int));
}

o resultado foi:

sizeof(int) = 4; sizeof(long) = 4

achei bem estranho um long ter o mesmo tamanho de um int…

e fiz um outro teste, agora com o bublesort, e novamente o java foi mais rapido!!!

codigo Java:

public class Teste{
 private static final int SIZE = 100000;
 public static void main(String args[]){
  int array[] = new int[SIZE];
  for (int i = 0; i < SIZE; i++){
   array[i] = i % 100;
  }
  bublesort(array);
 }
 public static void bublesort(int array[]){
  int aux;
  for (int i = 0; i < array.length; i++){
   for (int j = array.length - 1; j > i; j--){
    if (array[j] < array[i]){
     aux = array[i];
     array[i] = array[j];
     array[j] = aux;
    }
   }
  }
 }
}

codigo C:

#define SIZE 100000
void bublesort(int array[]);
int main(){
 int array[SIZE], i;
 for (i = 0; i < SIZE; i++){
  array[i] = i % 100;
 }
 bublesort(array);
}
void bublesort(int array[]){
 int aux, i, j;
 for (i = 0; i < SIZE; i++){
  for (j = SIZE - 1; j > i; j--){
   if (array[j] < array[i]){
    aux = array[i];
    array[i] = array[j];
    array[j] = aux;
   }
  }
 }
}

OBS: como quis que sempre fossem ordenados os mesmos valores, nao botei nada aleatorio

resultados Java:

52 segundos e 74 centesimos
52 segundos e 17 centesimos
52 segundos e 34 centesimos

resultados C:

53 segundos e 93 centesimos
55 segundos e 98 centesimos
55 segundos e 97 centesimos

depois vou testar o quicksort, soh q acho q C vai dar uma surra em java

Ae Felipe esse teste sim mostra que java esta realmente rápido…

Eu imagina que com o Bubble o C ia disparar na frente do java.

Estou aguardando o resultado do Quick! manda ve ai…

agora fiquei de boca! eu pensava que C ia ser duas vezes mais rapido que java, mas o que ocorreu foi o contrario! Java foi aproximadamente duas vezes MAIS rapido que C!!!

codigo Java:

public class Teste{
 private static final int SIZE = 1000000;
 public static void main(String args[]){
  int array[] = new int[SIZE];
  for (int i = 0; i < SIZE; i++){
   array[i] = i % 100;
  }
  quicksort(0, SIZE - 1, array);
 }
 public static void quicksort(int p, int q, int array[]){
  if (p < q){
   int j = p - 1;
   int aux = array[q];
   for (int i = p; i <= q; i++){
    if (array[i] <= aux){
     int taux = array[i];
     array[i] = array[++j];
     array[j] = taux;
    }
   }
   quicksort(p, j - 1, array);
   quicksort(j + 1, q, array);
  }
 }
}

codigo C:

#define SIZE 1000000
void quicksort(int p, int q, int array[]);
int main(){
 int array[SIZE], i;
 for (i = 0; i < SIZE; i++){
  array[i] = i % 100;
 }
 quicksort(0, SIZE - 1, array);
}
void quicksort(int p, int q, int array[]){
 int j, aux, i, taux;
 if (p < q){
  j = p - 1;
  aux = array[q];
  for (i = p; i <= q; i++){
   if (array[i] <= aux){
    taux = array[i];
    array[i] = array[++j];
    array[j] = taux;
   }
  }
  quicksort(p, j - 1, array);
  quicksort(j + 1, q, array);
 }
}

resultados Java:

1 minuto, 4 segundos e 91 centesimos
1 minuto, 4 segundos e 78 centesimos
1 minuto, 4 segundos e 81 centesimos

resultados C:

2 minutos, 4 segundos e 81 centesimos
2 minutos, 4 segundos e 66 centesimos
2 minutos, 4 segundos e 53 centesimos

:viva:

Vixxi essa comparação do Quick foi para calar a boca de qualquer um que disse que java é lento.

isso mostra como tem programadores que n sabem o q é realmente o java hoje em dia, ficam falando que o java é lento, e ruim de programar, etc… mas é o que mas há portabilidade e se programa para varias coisas como celular , web e etc…
simplesmente java eh muito melhor q qq outra linguagem… :triunfo:

Bah…

esse teste foi pra tira tudo que éra duvida mesmo…
eu ainda to tentando achar uma explicação teorica pra isso…

de qualquer forma tenho que rever meus conceitos, até 30 min atraz eu achava que C a linguagem de alto nivel imbativel em qualquer aspecto de velocidade.

8O 8O 8O 8O 8O 8O 8O 8O

hahahahahah

java é demais!!!

que venha o .NET!!!

Esse é o Tigre!!!

Q venha o Mustang !!!

resultados surpreendentes…

eu naum sabia dessa grande performance que o Tiger possui…

[quote=“sens”]esse teste foi pra tira tudo que éra duvida mesmo…
eu ainda to tentando achar uma explicação teorica pra isso…[/quote]

Otimização… codigo objeto gerado pelo compilador Java é aparentemente muito melhor que o código objeto gerado pelo GCC.

Particularmente, eu não conheço o GCC, por isso não sei como funciona o esquema de otimização dele. Mas provavelmente o default deve privilegiar um código objeto pequeno, e deve ser possivel configura-lo de maneira a reverter essa situação.

Sejamos realistas, a linguagem C++ é bastante proxima ao hardware… tanto que podemos configurar o compilador para otimizar de diversas maneiras, como para performance, compatibilidade (caso queira se usar processadores antigos), código objeto pequeno, baixo uso de recursos de hardware.

No caso do dotNet e Java, um código objeto intermediário é gerado, e depois esse é aberto e interpretado por uma VM. Só o fato ler um arquivo e interpretar pseudo-instruções já um processamento… com um software gerado em C++ corretamente otimizado não faz esse tipo de processamento.

Não me entendam mal pessoal mas é:

  • C++ para computação gráfica
  • Java para aplicação web

São as áreas que atuo hoje. Tiger está de parabens, parece ter melhorado muito, pois tava perdendo um bom espaço para dotNet.

Abraços.

daniel_bocian, obrigado pela esplicação …

mas o que não entendo é o seguinte:

“C” não é orientado a objeto, e java é 100% orientado a objeto, isso pesa em favor do C pois a linguagem não orientada é mais rápida.

E ainda o JAVA necessita de uma JMV o que faz que fiq mais lento ainda, pois necessita ser interpretado e em tempo de execução.

e o C é compilado previamente, teoricamente ele deveria ganhar tempo com isso. Sem contar que é uma linguagem mais baixo nivel que java, o que também na teoria faz com que ele seja mais rapido…

Continuo na duvida… se mais alguêm puder achar uma explicação…

Obrigado

[]´Victor

Bem, em primeiro lugar, o fato da linguagem ser orientada a objeto ou não, não faz nenhuma diferença. Isso por que depois de passar pelo compilador tudo vira um conjunto de instruções que não seguem paradigma algum.

Segundo, mas uma vez falo que isso depende do compilador. Pensa só, nossos processadores atuais implementam instruções MMX, SSE, SSE2, 3DNow e etc… te garanto que o GCC padrão, compila gerando código objeto compatível com todos os processadores x86. Ou seja, não faz uso desse conjunto avançado de instruções. Agora, a implementação da JVM com toda a certeza utiliza esses recursos para otimizar performance.

Ok… agora, com toda a certeza eu posso habilitar o GCC para utilizar essas instruções avançadas… daí ele ganha desempenho…

Infelizmente, eu não sei utilizar o GCC… atualmente trabalho apenas com compilador da Microsoft. Mas é uma coisa que dá para garantir, C é flexivel… tanto que o Felipe pode rodar sem problema esse programa teste em C em um micro 286, já o em Java…

ok daniel_bocian, valeu pelo toke…

deu pra dar uma clareada…

[]'s Victor