Les benchs du "Great Computer Language Shootout"
remis à jour avec les implémentations récentes du Jdk.
Notez bien qu'il s'agit de micro benchmarks, qui en soi
ne permettent pas de dire que X est plus rapide que Y,
la performance d'un programme est globale ...
Néanmoins je vous soumet ce lien car moi aussi j'en
ai marre d'entendre répeter encore et encore que java est lent ...
L'article
http://www.sys-con.com/story/?storyid=45250(...)
La news originelle sur /.
http://developers.slashdot.org/developers/04/06/15/217239.shtml?tid(...)
[i][ Ndm: il serait souhaitable de ne pas partir en gros troll velu java c'est pas libre ca sux ][/i]
Journal Java et C++
16
juin
2004
# mouaich.
Posté par TImaniac (site web personnel) . Évalué à 3.
Enfin les benchs entre langages me feront toujours rires, ce qui changent ce n'est pas la vitesse d'exécution (de toute façon à l'arrivée c'est toujours du code machine qui s'exécute), c'est les possibilités du langages qui font la différence, et forcer de reconnaître que Java a une syntaxe plus agréable que C++, une portabilité plus aisée, sans doute une meilleure productivité, mais que question tuning tu pourras TOUJOURS faire mieux en C++ et que il restera toujours des trucs impossible à faire en Java. Et puis bon les libs du JDK sont pas codés en Java hein ;)
[^] # Re: mouaich.
Posté par Nelis (site web personnel) . Évalué à 5.
[^] # Re: mouaich.
Posté par Vincent Richard (site web personnel) . Évalué à 4.
* Java n'est pas plus portable que C++ (je peux écrire du code portable en C++ standard, il faut simplement recompiler, tout comme je dois changer de JVM,quand je change d'achitecture).
Ces deux points sont incontestables, désolé.
[^] # Re: mouaich.
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
mmmmh... si tu es a la recherche d'un code performant, rien qu'avec les différences entre les compilateurs, tu vas devoir modifier ton source de toute facon... alors la portabilité du C++, tres moyen ! A la rigueur l'argument est recevable pour le plain C. Mais reste le pb des dépendances avec des libs qui ne sont peut etre pas dispo sur toutes les plateformes, etc...
Sur ce point de la portabilité, et pour avoir essayer les 2, y'a pas photo, java n'est peut etre pas libre (histoire de temps ?), mais il est beaucoup plus facile a porter !!
Aurel, qui ne portera jamais qqchose en C++ sur IA64 par exemple, alors que la JVM pour IA64 et hop ! le code marche ! :D
[^] # Re: mouaich.
Posté par neil . Évalué à -1.
Ca s'appelle les #ifdef OSLINUX, etc... et c'est utilisé de partout.
[^] # Re: mouaich.
Posté par gc (site web personnel) . Évalué à 4.
[^] # Re: mouaich.
Posté par Bière Drabo . Évalué à 1.
Il suffit alors de bien choisir ses bibliothèques. WxWidgets, Boost, etc.
[^] # Re: mouaich.
Posté par Nelis (site web personnel) . Évalué à 6.
Non mais il est ouvert. Il est géré par le JCP et non par Sun et les sources sont disponibles pour lecture, c'est déjà pas mal. Par contre, beaucoup de logiciels libres sont écrit en Java et je trouve toujours insultant pour leurs auteurs quand ces logiciels se font accueillir par des "Java ça pue c'est pas libre"
* Java n'est pas plus portable que C++ (je peux écrire du code portable en C++ standard, il faut simplement recompiler, tout comme je dois changer de JVM,quand je change d'achitecture).
En Java, tu ne dois pas recompiler le code. Tu as un binaire, ce même binaire tournera sur la JVM A et sur la JVM B tant que ces JVM implémentent les spécifications. La portabilité binaire et source, c'est quand même pas la même chose quoi que t'en dise.
[^] # Re: mouaich.
Posté par allcolor (site web personnel) . Évalué à 2.
Je dirais même plus, java à la portabilité binaire et source, alors que c++ n'a la portabilité que par source.
[^] # Re: mouaich.
Posté par Bière Drabo . Évalué à 1.
Manque de bol, Java en change comme de chemise. Les bytecode en version n ne fonctionnent plus avec les versions n-1. Il faut recompiler, comme en C++.
La portabilité binaire et source, c'est quand même pas la même chose quoi que t'en dise.
C'est surtout intéressant pour les logiciels propriétaires.
[^] # Re: mouaich.
Posté par pifou . Évalué à 4.
Logiquement, je fais un programme java dans la version 1.1 de la JDK. Ce programme marchera tel quel si je le lance avec un JDK supérieur (compatibilité descendante).
En gros ce que tu dis c'est que si tu fais un programme avec le JDK 1.4, il ne marchera pas avec le JDK 1.1 ! Ben oui, c'est vrai mais je ne vois pas le problème, je ne connais AUCUN langage qui permet de tenir une compatibilté descendante ET montante (pour rappel, le fait de changer de version c'est pas juste pour faire jolie mais pour apporter des améliorations dans les langages). A moins d'utiliser IPOT je ne vois comment on pourrait deviner à l'avance les spécifications des JDK futurs.
Je ne parle même pas de compatibilité des binaires C++ et C avec toutes les dépendances (compilateur, système, noyau, libc, librairie supplémentaires ...).
[^] # Re: mouaich.
Posté par Bière Drabo . Évalué à 1.
La compatibilité binaire C++ arrive, c'est récent. Par contre pour le C, rien à envier à Java. C'est d'ailleurs ce qui fait que certains sont réticents pour passer de C à C++.
[^] # Re: mouaich.
Posté par Roger Rabbit . Évalué à 3.
Je ne dis pas que java est plus rapide que C++, le journal est titré "java et c++", c'est le titre de l'article qui pose la question de savoir si java *serait* plus rapide par rapport au C++.
Je souhaite juste porter l'attention de certains sur le java que l'addage
souvent répeté ici "java est lent" n'a plus vraimment de signification de nos jours. Si ca peut aider certains a reconsiderer leurs préjugés c'est tant mieux.
De toute façon comme je l'ai indiqué, comparer les performances
de deux langages à l'aide de micro bench c'est peu significatif.
Tout simplement par ce que si tu lances un profiler sur un programme, les portions le ralentissant seront seront dues à un défaut de conception, un mauvaise architecture logicielle, et pas à la vitesse d'éxecution d'une boucle for. ( néanmoins pour un programme ayant une architecture "idéale" ça impacterait les performances, d'ou la possibilité en java de faire des appels de code natifs pour des algos critiques ).
Ps: les librairies du Jdk sont codées en java avec des appels Jni natifs dedans bien évidemment.
[^] # Re: mouaich.
Posté par TImaniac (site web personnel) . Évalué à 3.
Ce qui fait la réputation de "Java c'est lent" c'est surtout les différences de perfs entre Java sous Windows et Java sous Linux, et évidemment le fait que Java bouffe de la RAM, ce qui ne change rien quand on en a assez, mais qui bien sûr font chutter les perfs dès qu'on n'a plus ce qu'il faut...
"Ps: les librairies du Jdk sont codées en java avec des appels Jni natifs dedans bien évidemment."
Donc bien évidemment, les libs sont implémentées en C++, et que implicitement on peut obtenir des perfs exactement identiques entre C++ et Java, comme quoi ce n'est pas le langage qui fait la différence mais bien l'implentation...
(d'ailleur une question qui tue : on dit implémentation ou inplentation ? Les 2 sont-ils français ?)
[^] # Re: mouaich.
Posté par Bière Drabo . Évalué à 2.
Ceci dit Java n'est pas excessivement lent. Ca reste toujours le démarrage de la JVM qui se ressent, ou des parties lourdes de la bibliothèque comme Swing. Ca peut donc etre acceptable.
Le seul problème est que en génral pour rendre Java plus rapide il faut vraiment etre un expert, connaitre les bons trucs, quasiment savoir ce que fait la bibliothèque (pas seulement l'interface, un peu l'implémentation aussi). Ca nécessiterait donc un très long apprentissage, et à ce moment là l'avantage par rapport à C++ (qui lui en nécessite vraiment un, très payant d'ailleurs) diminue.
Bref les principaux critères restent la conception, les algorithmes et la connaissance du langage, sa bonne utilisation.
[^] # Re: mouaich.
Posté par pifou . Évalué à 4.
Premièrement, à l'exécution les segfaults sont très rares (à vrai dire, j'en ai vu qu'une fois dans un pb de partage de données entre 300 Threads), on préfére les IndexOutOfBoundException, IOException ... C'est plus parlant surtout quand on commence à développer et qu'on se gourre tout le temps dans les comptages d'index.
Deuxièmement, on évite l'arithmétique des pointeurs et la gestion des allocations dynamiques (je n'ai jamais aimé passé 2 minutes à eplucher un 'man' pour savoir si le char* passé en paramètres devait être alloué par moi, par la méthode ou tout simplement se trouvait en champ static).
Après, un développeur débutant en Java fera surement du code aussi grade qu'un développeur C++, voir plus s'il n'a jamais fait de langage objets avant. Mais ça n'a rien a voir, on devient bon développeur en développant quelque soit le langage. Avant qu'un développeur Java puisse utiliser tous les frameworks (Struts, J2EE ...) et pattern (Observer, MVC, Singleton ...) intélligement il faut un certain temps de programmation 'je réinvente la roue'.
Pour finir, je dirais que Java n'est pas le langage ultime, mais il faut bien reconnaître que de la même manière que C++ et SmallTalk en leurs époques, il a permis de franchir un nouveau cap dans l'abstraction du développement.
[^] # Re: mouaich.
Posté par Bière Drabo . Évalué à 1.
Pour le débutant (typiquement, le stagiaire), je suis d'accord. Mais l'informatique n'est pas faite que par des stagiaires ou des non informaticiens.
Premièrement, à l'exécution les segfaults sont très rares (à vrai dire, j'en ai vu qu'une fois dans un pb de partage de données entre 300 Threads), on préfére les IndexOutOfBoundException, IOException ... C'est plus parlant surtout quand on commence à développer et qu'on se gourre tout le temps dans les comptages d'index.
Tu es libre d'utiliser un bon système de gestion d'erreur en C++. Mais c'est vrai que c'est un point fort de Java.
Deuxièmement, on évite l'arithmétique des pointeurs et la gestion des allocations dynamiques (je n'ai jamais aimé passé 2 minutes à eplucher un 'man' pour savoir si le char* passé en paramètres devait être alloué par moi, par la méthode ou tout simplement se trouvait en champ static).
Je crois que tu as de sérieuses lacunes ou que tu parles de C et non de C++ si tu te consacres autant à ces problèmes. En C++ on évite l'allocation dynamique "à la main" (on prend des conteneurs, le cas échéant on les fabrique et alors tout est bien encapsulé), on ne fait pas d'arithmétique de pointeurs sauf cas exceptionnels (a priori inutile) et on n'utilise pas de char* mais des std::string ou std::vector, leur caractère const et "passé en référence" suffisant à tout connaitre.
Le C++ (et non le C avec une vague connaissance des classes C++ par dessus) est parfois bien plus simple que Java. Car il faut distinguer : simple à apprendre (Java) et simple à utiliser (C++, après un apprentissage un peu plus difficile que Java).
Pour finir, je dirais que Java n'est pas le langage ultime, mais il faut bien reconnaître que de la même manière que C++ et SmallTalk en leurs époques, il a permis de franchir un nouveau cap dans l'abstraction du développement.
C++ a quasiment toutes ces facilités de Java, il permettait déjà cette abstraction. Java est juste plus orienté là dedans, donc plus simple à apprendre et propose une bibliothèque standard plus large (bien qu'ayant des lacunes sur les conteneurs, ça doit être corrigé maintenant avec les génériques).
# java c'est pas libre ca sux
Posté par Gordon Shumway . Évalué à 1.
histoire d'orienter le troll : il y a des comparatifs de perf récents entre Mono/dotNet ? et entre Mono/Java ? et entre dotNet/Java ?
[^] # Re: java c'est pas libre ca sux
Posté par TImaniac (site web personnel) . Évalué à 2.
Une chose est sûre : Mono est plus lent que .NET (quoique certains trucs vont plus vite)
Entre .NET et Java, forcement, Microsoft annonce des perfs bien supérieures, mais là encore tout dépend de l'utilisation, et comme d'hab, il est bien impossible de comparer des applications réelles... Mais on peut facilement imaginer que une bonne conception de l'application cachera les différences de rapidité...
Une autre chose est sûre : ce qui fait la supériorité de Mono/.NET sur Java, c'est les possibilité techniques (genre c'est pas demain la veille qu'on verra QuakeII sur Java) et le respect des standards, mais là on s'éloigne du troll original...
[^] # Re: java c'est pas libre ca sux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 2.
Avec Java3D qui est un "bindings" de Opengl, je ne vois pas ou est le problème...
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: java c'est pas libre ca sux
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: java c'est pas libre ca sux
Posté par Roger Rabbit . Évalué à 0.
d'arithmétique des pointeurs par contre.
# explications ?
Posté par Jux (site web personnel) . Évalué à 4.
Le language interprété doit faire la même chose que le language compilé, mais avec une couche de plus, nan (genre la jvm est une sorte de processeur tournant sur un autre proc) ?
Ou alors c'est gcc qui est mauvais, mais ça m'étonnerait (d'après les benchs contre d'autres compilateurs, il est parfois un peu plus lent, mais pas des masses).
Dernière possibilité : ce sont des benchs sur des applications élémentaires. Peut-être qu'en augmentant la taille de l'application, on verait la balance pencher dans l'autre sens.
(mon but n'est pas de détruire Java, mais de comprendre. Or instinctivement, je suis amené à penser que compilé est plsur apide qu'interprété...)
[^] # Re: explications ?
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
Il y a aussi des cas ou le binaire généré par GCC est 2x plus lent sur des G5 que celui généré par XLF (code fortran, CHARMM pour ne pas le nommer), et là, ca fait mal !
[^] # Re: explications ?
Posté par calandoa . Évalué à 2.
Il me semble que le java est compilé "just-in-time" c'est à dire entre le chargement et l'execution... pourtant ça reste plus rapide que du c++ même en prenant en compte le temps d'initialisation... Effectivement, il semblerait qu'un troll vienne de mourir... paix à son âme...
[^] # Re: explications ?
Posté par gc (site web personnel) . Évalué à 3.
[^] # Re: explications ?
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: explications ?
Posté par cedric . Évalué à 3.
Pour exemple, j'ai avec un copain code un petit logiciel, on perdait 93% de notre temps a faire des allocations memoires. Apres avoir definit une politique plus judicieuse de la memoire, cette phase est devenu negligeable. Donc si on fait des benchs C++ vs Java redefinir les operateurs new et delete pour obtenir les meme comportement en C++ qu'en Java me parait un minimum pour faire une comparaison objective...
[^] # Re: explications ?
Posté par Epsos . Évalué à 2.
En c++, si tu ne compiles pas avec f-inline et si tu ne proposes pas au compilo d'inliner certaines methodes (via le mot clef inline), il ne le fera pas.
Bref, plus je lis et relis ce bench, plus je suis d'accord avec certains commentaires sur slashdot : il ne compare pas la meme chose.
[^] # Re: explications ?
Posté par Bière Drabo . Évalué à 1.
# Java est une usine à gaz...
Posté par Vincent Richard (site web personnel) . Évalué à -1.
On peut aussi faire un autre bench : la mémoire utilisée. Et là, désolé mais C++ est très largement devant.
Java est une usine à gaz.
Ce n'est pas un troll, c'est la réalité.
Je défie quiconque de me prouver le contraire...
[^] # Re: Java est une usine à gaz...
Posté par Roger Rabbit . Évalué à 2.
>> JVM startup time was included in these results. "That means even
>> with JVM startup time, Java is still faster than C++ in many of
>> these tests," says Lea.
[^] # Re: Java est une usine à gaz...
Posté par Vincent Richard (site web personnel) . Évalué à 0.
Pour bein faire, il faudrait rebooter la machine à chaque fois.
Je réitère : c'est un test bidon ! :-)
[^] # Re: Java est une usine à gaz...
Posté par gc (site web personnel) . Évalué à 3.
On peut trouver pas mal d'autres points qui font que javasux (mais sûrement encore plus qui font que c++sux alors ça va).
[^] # Re: Java est une usine à gaz...
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
while (! memoryleaks ) :)
[^] # Re: Java est une usine à gaz...
Posté par Vincent Richard (site web personnel) . Évalué à 1.
[^] # Re: Java est une usine à gaz...
Posté par gc (site web personnel) . Évalué à 6.
[^] # Re: Java est une usine à gaz...
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
Plus que le langage, c'est l'habileté et l'expérience du programmeur, dans le choix du design, dans l'implémentation, puis dans le profiling, qui font qu'un code sera rapide ou pas.
# Java et C++
Posté par djapat . Évalué à 2.
Peut-être qu'une fois chargée, une application java peut avoir des performances comparables à d'autres languages.... mais pas avec la même utilisation mémoire et pas pour des applications graphiques avec swing !
Un simple petit script qui lance 10 fois helloWorld en parrallèle (HelloWorld qui attend que return soit pressé pour se terminer) devrait mettre en évidence ces problèmes...
Ensuite, sur un pintel 6600Ghz 3gb ram ou un pintel II 100Mhz, 128mb ram, je pense que c'est encore plus flagrant...
Note: j'avais vu des benchmarks gcj (http://gcc.gnu.org/java/(...) qui compile du java en natif): des fois les gains de performance sont important, des fois on est plus lent qu'avec la jvm. dans tous les cas, la mémoire utilisée est moins importante.
Est-ce que quelqu'un a des expériences avec gcj ?
[^] # Re: Java et C++
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
# Bref..
Posté par Mr_Moustache . Évalué à 1.
Personne n'ici n'est capable d'apporter un réel argument sans mauvaise fois ou qui ne soit irréprochable, et les autres ne sont pas capables d'encaisser les quelques critiques réalistes et parfois si insignifiantes..
Ceci est valable pour les "pro-Java" et les "pro-C++"..
Sur ce je vous laisse troller de bon coeur..
[^] # Re: Bref..
Posté par Pooly (site web personnel) . Évalué à 1.
# Ce benchmark compare du Java à du C++ mais...
Posté par Edouard Gomez (site web personnel) . É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.
[^] # Re: Ce benchmark compare du Java à du C++ mais...
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Ce benchmark compare du Java à du C++ mais...
Posté par calandoa . Évalué à 3.
Évidement on va pas conclure que le java est 1.356 fois plus rapide que le c++ d'après ce benchmark, mais par contre je suis impressionné par la progression faite par le java qui, d'un point vu vitesse (pour la mémoire c'est pas encore ça), équivaut a peu près au C/C++, alors qu'il présente beaucoup de fonctionalités plus confortables pour le développeur.
Il faut aussi voir que ce benchmark ne fait aucun test sur l'interface graphique où java ne doit pas être très brillant...
[^] # Re: Ce benchmark compare du Java à du C++ mais...
Posté par M . Évalué à 2.
En tout cas pas chez moi : gcc - 3.4 java1.4
time java fibo 36
24157817
real 0m0.524s
user 0m0.490s
sys 0m0.022s
time ./a.out 36
res : 24157817
real 0m0.390s
user 0m0.388s
sys 0m0.001s
[^] # Re: Ce benchmark compare du Java à du C++ mais...
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: Ce benchmark compare du Java à du C++ mais...
Posté par Bière Drabo . Évalué à 1.
On trouve souvent ce défaut à propos de Python : on compare un bon programmeur Python à un mauvais programmeur C++ par exemple.
Ce que je dis n'est pas du tout anti-Python : ce langage a ses qualités indéniables, mais les comparaisons devraient se faire avec des programmeurs de compétence équivalente dans leurs langages respectifs. Et ensuite on peut remarquer qu'avoir un bon niveau en C++ demande un apprentissage bien plus long. Mais le minimum est de comparer des codes dans lesquels on tire le meilleur du langage.
# Saint Thomas
Posté par calandoa . Évalué à 4.
java 1.4.2
java 1.4.2 -server
java 1.5 beta
java 1.5 beta -server
g++ -03 -march athlon-xp
Les résultats sont globalement identiques, un peu plus en faveur du C++ quand même que les tests de l'autre gars. On remarque que pour des données ou un nombre d'itération petits, le C++ fait un bien meilleur score à cause du temps d'init de java ; pour diminuer l'importance de ce temps il suffit d'augmenter le temps d'execution, mais le problème est que lorsqu'on choisi certaines valeurs, java plante à cause du manque de mémoire, là où le C++ passe les doigts dans le nez!
Sinon j'ai pris -O3 comme optimisation pour gcc à la place de -O2, qui est meilleur contrairement à ce que dit le gars.
Enfin bon ça ne change par grand chose à la conclusion : java est globalement aussi rapide que le C++ (pour moi ça remet pas mal de choses en cause...)
---- ackermann 11 ----
4.35user 0.01system 0:04.45elapsed 98%CPU
0.96user 0.01system 0:01.52elapsed 63%CPU
4.12user 0.01system 0:05.02elapsed 82%CPU
0.98user 0.01system 0:01.08elapsed 91%CPU
1.17user 0.00system 0:01.21elapsed 96%CPU
---- fibo 45 ----
21.15user 0.00system 0:21.32elapsed 99%CPU
16.00user 0.00system 0:16.15elapsed 99%CPU
27.49user 0.01system 0:27.69elapsed 99%CPU
16.35user 0.01system 0:16.48elapsed 99%CPU
24.44user 0.00system 0:24.62elapsed 99%CPU
---- hash 500000 ----
4.48user 0.09system 0:04.70elapsed 97%CPU
4.08user 0.09system 0:04.34elapsed 96%CPU
4.08user 0.09system 0:04.47elapsed 93%CPU
3.64user 0.08system 0:03.94elapsed 94%CPU
1.84user 0.04system 0:01.91elapsed 98%CPU
---- hash2 3000 ----
11.78user 0.01system 0:11.93elapsed 98%CPU
8.94user 0.01system 0:09.07elapsed 98%CPU
11.96user 0.01system 0:12.12elapsed 98%CPU
10.08user 0.00system 0:10.22elapsed 98%CPU
17.10user 0.00system 0:17.21elapsed 99%CPU
---- heapsort 5000000 ----
8.10user 0.05system 0:08.33elapsed 97%CPU
8.78user 0.05system 0:08.93elapsed 98%CPU
8.21user 0.06system 0:08.53elapsed 96%CPU
8.26user 0.05system 0:08.48elapsed 98%CPU
9.73user 0.02system 0:09.83elapsed 99%CPU
---- matrix 100000 ----
27.74user 0.00system 0:27.97elapsed 99%CPU
21.13user 0.01system 0:21.29elapsed 99%CPU
29.22user 0.01system 0:29.46elapsed 99%CPU
21.32user 0.01system 0:21.52elapsed 99%CPU
12.01user 0.00system 0:12.13elapsed 99%CPU
---- methcall 1000000000 ----
20.19user 0.00system 0:20.38elapsed 99%CPU
2.49user 0.00system 0:02.54elapsed 98%CPU
18.53user 0.01system 0:18.69elapsed 99%CPU
2.58user 0.01system 0:02.63elapsed 98%CPU
12.88user 0.00system 0:12.97elapsed 99%CPU
---- nestedloop 45 ----
25.00user 0.01system 0:25.27elapsed 98%CPU
20.41user 0.01system 0:20.61elapsed 99%CPU
25.91user 0.01system 0:26.16elapsed 99%CPU
20.53user 0.01system 0:20.72elapsed 99%CPU
10.78user 0.00system 0:10.88elapsed 99%CPU
---- objinst 100000000 ----
9.33user 0.33system 0:09.79elapsed 98%CPU
9.20user 0.32system 0:09.62elapsed 99%CPU
10.21user 0.40system 0:10.70elapsed 99%CPU
9.86user 0.41system 0:10.38elapsed 98%CPU
23.24user 0.00system 0:23.40elapsed 99%CPU
---- random 300000000 ----
34.56user 0.00system 0:34.82elapsed 99%CPU
21.29user 0.00system 0:21.49elapsed 99%CPU
37.71user 0.01system 0:38.03elapsed 99%CPU
25.23user 0.01system 0:25.45elapsed 99%CPU
4.41user 0.00system 0:04.47elapsed 98%CPU
---- sieve 100000 ----
13.49user 0.01system 0:13.63elapsed 99%CPU
12.21user 0.00system 0:12.30elapsed 99%CPU
14.94user 0.01system 0:15.07elapsed 99%CPU
9.75user 0.01system 0:09.89elapsed 98%CPU
10.56user 0.00system 0:10.65elapsed 99%CPU
---- strcat 1000000 ----
0.48user 0.03system 0:00.63elapsed 82%CPU
0.49user 0.02system 0:00.58elapsed 88%CPU
0.41user 0.04system 0:00.52elapsed 86%CPU
0.45user 0.04system 0:00.55elapsed 88%CPU
0.11user 0.01system 0:00.16elapsed 78%CPU
---- sumcol ( < fichier 243 Mo) ----
19.66user 0.64system 0:20.66elapsed 98%CPU
13.18user 0.61system 0:13.94elapsed 98%CPU
19.68user 0.65system 0:20.52elapsed 99%CPU
10.58user 0.62system 0:11.32elapsed 98%CPU
15.24user 0.45system 0:15.83elapsed 99%CPU
---- wc ( < fichier 265 Mo) ----
4.46user 0.58system 0:08.57elapsed 58%CPU
4.30user 0.59system 0:08.46elapsed 57%CPU
6.08user 0.41system 0:09.96elapsed 65%CPU
3.81user 0.55system 0:08.73elapsed 49%CPU
2.20user 0.49system 0:02.80elapsed 96%CPU
[^] # Re: Saint Thomas
Posté par RodZilla . Évalué à 4.
Tout ce que ce benchmark prouve, c'est que ce gars a bien raison de développer en Java.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.