Au delà du résultat, que je trouve contestable, il est plus important de voir pourquoi ce benchmark ne peut être pris en considération lorsqu'on souhaite comparer Java et C en termes de perfs.
En résumant, j'estime que l'auteur compare du Java avec du très mauvais code C. Je ne sais pas quel est le niveau du codeur C/C++ derrière ces petits benchs, mais force est de constater qu'il n'a aucun bon sens, tant en terme de gestion de mémoire que de performances. Un comble lorsqu'on tente de comparer les performances de deux langages.
Je prend pour exemple le code du fichier matrix.cpp. Pour moi, codeur C depuis déjà quelques années, quand on me dit d'allouer une matrice, j'alloue directement un bloc de sizeof(element)*n*m, mais je n'alloue pas un tableau de pointeurs pour ensuite allouer chaque ligne separement, et ce pour deux raisons:
- c'est sous efficace en terme d'espace memoire (le surcout de n pointeurs) et c'est un surcout en terme d'appels à malloc.
- accéder à un élément devient couteux, car il y a deja une indirection memoire pour acceder a l'adresse de la ligne.
(- le traitement sequentiel des elements est non optimal a cause de la rupture en fin de chaque ligne)
Peut être le codeur cherchait à avoir un code syntaxiquement proche (eg: m[i][j] au lieu d'un m[i*n+j]).
D'ailleurs je doute que le new int[n][m] corresponde au code C proposé, je parierai bien 0.3 que la JVM alloue n*m*sizeof(int), et l'operateur d'acces mat[i][j] n'est qu'une vue de l'esprit, et est traduit dans un bytecode proche de mat[n*i+j].
J'invite tout le monde a se pencher sur le code pour comprendre que ce benchmark n'est tout simplement pas crédible. Le code C/C++ ne correspond pas du tout à ce qu'un codeur C/C++ typique aurait écrit, il resemble plus à une transcription litérale de la version Java. Et donc, ce bench compare Java, avec du C++ qui se prend pour du Java (mais sans jamais faire l'effort de simuler une gestion memoire equivalente, cad ne pas detruire les objets a chaque boucle mais le recycler comme le ferait le GC de la JVM, ou encore anticiper sur le compilateur pour ecrire du code efficace et simple, étape accomplie par le bytecode->code machine du JIT)
J'utilise Java tous les jours au boulot et j'en suis satisafait, je ne crache donc pas du tout sur Java. Par contre je crache sur ce benchmark qui compare des carrotes et des choux... oui c'est pas pareil, et on est bien incapable de conclure que les choux sont meilleurs que les carrotes.
# Ce benchmark compare du Java à du C++ mais...
Posté par Edouard Gomez . En réponse au journal Java et C++. Évalué à 7.
En résumant, j'estime que l'auteur compare du Java avec du très mauvais code C. Je ne sais pas quel est le niveau du codeur C/C++ derrière ces petits benchs, mais force est de constater qu'il n'a aucun bon sens, tant en terme de gestion de mémoire que de performances. Un comble lorsqu'on tente de comparer les performances de deux langages.
Je prend pour exemple le code du fichier matrix.cpp. Pour moi, codeur C depuis déjà quelques années, quand on me dit d'allouer une matrice, j'alloue directement un bloc de sizeof(element)*n*m, mais je n'alloue pas un tableau de pointeurs pour ensuite allouer chaque ligne separement, et ce pour deux raisons:
- c'est sous efficace en terme d'espace memoire (le surcout de n pointeurs) et c'est un surcout en terme d'appels à malloc.
- accéder à un élément devient couteux, car il y a deja une indirection memoire pour acceder a l'adresse de la ligne.
(- le traitement sequentiel des elements est non optimal a cause de la rupture en fin de chaque ligne)
Peut être le codeur cherchait à avoir un code syntaxiquement proche (eg: m[i][j] au lieu d'un m[i*n+j]).
D'ailleurs je doute que le new int[n][m] corresponde au code C proposé, je parierai bien 0.3 que la JVM alloue n*m*sizeof(int), et l'operateur d'acces mat[i][j] n'est qu'une vue de l'esprit, et est traduit dans un bytecode proche de mat[n*i+j].
J'invite tout le monde a se pencher sur le code pour comprendre que ce benchmark n'est tout simplement pas crédible. Le code C/C++ ne correspond pas du tout à ce qu'un codeur C/C++ typique aurait écrit, il resemble plus à une transcription litérale de la version Java. Et donc, ce bench compare Java, avec du C++ qui se prend pour du Java (mais sans jamais faire l'effort de simuler une gestion memoire equivalente, cad ne pas detruire les objets a chaque boucle mais le recycler comme le ferait le GC de la JVM, ou encore anticiper sur le compilateur pour ecrire du code efficace et simple, étape accomplie par le bytecode->code machine du JIT)
J'utilise Java tous les jours au boulot et j'en suis satisafait, je ne crache donc pas du tout sur Java. Par contre je crache sur ce benchmark qui compare des carrotes et des choux... oui c'est pas pareil, et on est bien incapable de conclure que les choux sont meilleurs que les carrotes.