Discussion :

[5:35pm]

java est aussi rapide que c++

elle est bien bonne celle la

[5:35pm]

voici les resultats d'un benchmark (serieux AMHA) de juin 2007:



resultats cumulatif:



source

[nicØB]

Encore un test ridicule.

Since Java compiler does not have any settings that could affect performance

Le compilateur non ... le GC oui...

De plus, il a repris les même conditions que le test précédent (qu'il a modifié): le temps de lancement de la JVM est prit en compte. Quel est l'intérêt de prendre ce temps en compte ? Une JVM en mode serveur, on la redémarre pas toutes les 5min...


De plus, l'update 2 de Java est sortie, il faut donc refaire le test.

[®om]

Encore un test ridicule.

Le test n'est pas ridicule, il montre qu'indéniablement, pour les calculs, C/C++ est plus performant. Et même que globalement, pour un peu toute sorte de choses, C++ est plus performant... si on travaille au niveau de la mémoire, c'est normal...

Si on met de côté les quelques petites erreurs lors des tests (par exemple le test sur un StringBuffer pour la concaténation, au lieu d'un StringBuilder, bien plus performant, environ 4x plus rapide sur un petit test), et comme tu le dis le temps de lancement de la VM (ça c'est énorme par rapport à l'exécution du programme), on remarque que tout au plus, C++ n'est que 2x plus rapide que java, et pour des calculs purs... On n'est pas à un facteur 20 ni 10...

Pour une application réelle, je pense que ce facteur tend vers 1... même si je pense qu'en benchmark C++ a (encore) un rien d'avance, Java a d'autres avantages...

[nicØB]

Oui c'est ridicule car fait par un gars loin d'être impartiable car il n'a pas connaissances requises pour l'être (ex avec la concaténation de string).
Le C/C++ est plus rapide pour les calculs comme tu le dis, mais ça n'empeche pas qu'il faut faire les choses correctement.

Quand tu vois que la JVM en mode serveur est souvent moins rapide que celle en mode client, on se doute bien que le temps de lancement de la JVM est loin d'être négligeable...
Il me semble c'est dans les 10% de temps supplémentaire pour lancer la jvm en serveur plutot qu'en client, mais pour avoir du code plus performant. Si tu regardes bien le graphe, par moment la JVM serveur est vraiment à la traine: temps négligeable ? Je ne pense pas.

[koala01]

Ne jamais faire confiance à un benchmark que l'on n'a pas truqué soi-même

[nicØB]

Oui c'est un peu ça.

[Luc Hermitte]

Et en plus, le C++ est parti avec un handicap (GCC en termes de perf on connait bien mieux).

Bref encore un bench qui a autant d'intérêt qu'un autre bench.


Plus sérieux, je suis tombé sur cet article d'il y a quelques mois. Stroustrup y parle du C++ depuis sa génèse jusqu'au C++0x. En lui-même l'article est intéressant.
Relativement au sujet de ce troll interminable, il y a une mini comparaison au Java qui traite aussi d'aspects non évoqués dans ces 40 pages si je me souviens bien.

Bref, c'est par là, je vous laisse vous faire votre propre opinion, bonne lecture.
http://www.research.att.com/~bs/hopl-almost-final.pdf

[5:35pm]

permettez moi de douter de bonne foie de ceux qui contestent la tendance de ce bench

je ne me refererais qu'a cette simple verite:

un langage de haut niveau ne peut pas etre plus performant qu'un langage de bas niveau.

[®om]

permettez moi de douter de bonne foie de ceux qui contestent la tendance de ce bench

je ne me refererais qu'a cette simple verite:

Cette phrase n'est pas forcément vraie... Dans un langage de haut niveau, tu peux faire des optimisations globales qu'il n'est pas possible de faire si tu programmes directement en bas niveau. Je prends l'exemple du C, ton programme que tu écris en C et que tu compiles avec l'option -O3 sera plus performant que le même programme que tu "essaierais" d'écrire directement en asm.

[5:35pm]

oui, un bon compilo vaudra toujours mieux que de l'asm a la main, car ce n'est pas un langage permettant aux hommes de concevoir des algorythmes, meme simple.
affirmer que java est (meme presque) aussi rapide, est une attitude negationiste.

et donc en Java quels sont les optimisations? (mis a part le GC)

[®om]

et donc en Java quels sont les optimisations? (mis a part le GC)

Il y a des optimisations non faisables à la compilation que java peut faire à l'exécution, comme l'inlining dynamique (qui dépend du contexte), et d'autres choses dans le même genre (je ne m'étendrais pas sur ce sujet, je n'y connais rien, mais ça existe ^^). Un petit détail sur Swing par exemple, plusieurs modifications successives d'un composant peuvent résulter en 1 seul recalcul de l'affichage... (bon, si on peut appeler ça de l'optimisation, ça n'a rien à voir avec le langage, c plutôt un détail de Swing).

Inversement, il y a des optimisations que C++ peut faire à la compilation qu'il est inenvisageable de faire à l'exécution...

[gorgonite]

Je prends l'exemple du C, ton programme que tu écris en C et que tu compiles avec l'option -O3 sera plus performant que le même programme que tu "essaierais" d'écrire directement en asm.

ce n'est pas toujours vrai... surtout s'il existe une instruction asm qui fait le boulot d'un seul coup, mais qui est tellement complexe à utiliser que les compilateurs ne s'en servent pas (il faut savoir qu'un compilateur n'utilise qu'un sous-ensemble de l'asm possible )

mais étant un fan des compilateurs et des optimisations de code, je dirais que cela arrive, mais que pour la majorité des cas ton affirmation est vraie

[LLB]

Un langage de haut niveau ne peut pas etre plus performant qu'un langage de bas niveau.

Ce qu'il ne faut pas lire... Tu as jeté cette phrase juste pour nourrir le troll, ou tu la crois vraiment ?

D'une part, tu peux trouver des milliers de contre-exemples, sur lesquels un langage de haut-niveau sera plus rapide qu'un langage de bas-niveau (abus de langage : on compare plutôt des compilateurs).

D'autre part, grand nombre d'optimisations sont bien plus simples à effectuer sur un langage de haut-niveau, puisqu'il a "plus de recul". Typiquement, un langage fonctionnel peut effectuer certaines optimisations qu'un compilateur C pourra très difficilement effectuer. Par exemple, les compilateurs C ou C++ ne peuvent pas effectuer certaines optimisations, entre autres à cause des pointeurs et des effets de bords qui peuvent survenir n'importe quand. Dans un langage de haut-niveau, un compilateur a plus de connaissances sur le code que dans un langage de bas-niveau, et peut potentiellement optimiser
plus.

Par ailleurs, les langages bas-niveau étant plus verbeux, et les développeurs étant fainéants, il est fréquent de voir un développeur C utiliser une structure de données plus simple, juste par flemme. Utiliser un arbre, une table de hachage ou une map est bien plus simple dans un langage de haut-niveau qu'en C. De fait, il est fréquent de voir des dévelppeurs C utiliser un tableau là où une autre structure serait plus performante.

Enfin, il existe des cas où une gestion automatique de la mémoire est plus performante que des appels à free et à malloc (ou new et delete).

un bon compilo vaudra toujours mieux que de l'asm a la main

Puisque tu reconnais ça (avec un bémol, signalé par Gorgonite), pourquoi ne pas reconnaitre que, de la même façon, un langage de haut-niveau peut effectuer des optimisations qu'un langage de bas-niveau pourra difficilement faire ?

Entre autres :

Because of the high level nature by which data structures are specified in functional languages such as Haskell, it is possible to combine several recursive functions which produce and consume some temporary data structure so that the data is passed directly without wasting time constructing the data structure.

[epsilon68]

Bref, c'est par là, je vous laisse vous faire votre propre opinion, bonne lecture.
http://www.research.att.com/~bs/hopl-almost-final.pdf

vraiment super intéressant ! Merci

[5:35pm]

Ce qu'il ne faut pas lire... Tu as jeté cette phrase juste pour nourrir le troll, ou tu la crois vraiment ?

les deux

les faits n'ont-ils pas prouve qu'un language de bas niveau est plus rapide que son equivallent de haut niveau?

asm > c > c++ > Java/C# > python

cette comparaison te parait fausse ?

il est plus efficace de gerer la memoire sois meme que de laisser faire par un garbage collector; comme il est plus efficace d'optimiser sois meme un algorythme que de le laisser faire par un compilo; pour la simple et bonne raison qu'un humain sait pourquoi un algorythme est tel qu'il est et un compilo, bien qu'il puisse comprendre un algorythme, il ne saura jamais pourquoi. l'intelligence artificiel VS l'intelligence humaine, qu'est-ce qui les differencient? la machine "pense" plus vite, et sans erreur, mais ne peut raisonner au dela des notions qui lui ont ete inculque. L'homme pense plus lentement, peut faire des fautes, mais peut tout remettre en question, et peut ruser, il a l'immagination, il comprend le pourquoi (enfin la plupart du temp ).

comment la machine peut elle optimiser en profondeur si elle comprend que le comment, et pas le pourquoi ?

[LLB]

les faits n'ont-ils pas prouve qu'un language de bas niveau est plus rapide que son equivallent de haut niveau?

asm > c > c++ > Java/C# > python

cette comparaison te parait fausse ?

Trop simpliste.

En moyenne, du code C compilé avec un bon compilateur sera plus rapide que du code assembleur, sur les projets de taille raisonnable, sauf à y passer des heures à optimiser.

De même la différence d'efficacité entre le C et le C++, puis entre C++ et C# tend à se réduire (voire s'inverser) quand on sort des cas d'école.

Il existe même des exemples où :
- Java peut être plus rapide que C++
- Caml peut être plus rapide que C++
- Lisp peut être aussi rapide que le C (cf http://www.lrde.epita.fr/dload/paper...a.06.imecs.pdf)
- et tant d'autres !

il est plus efficace de gerer la memoire sois meme que de laisser faire par un garbage collector;

Pas toujours !
http://en.wikipedia.org/wiki/Garbage...e_implications
Et ce papier d'Andrew Appel (qui date un peu) :
http://citeseer.ist.psu.edu/appel87garbage.html

comme il est plus efficace d'optimiser sois meme un algorythme que de le laisser faire par un compilo;

Euh, oui. Les compilateurs ne réécrivent pas (ou, pas encore ) les algos. Mais, en haut-niveau, les algorithmes courants sont souvent déjà implémentés. Et les algos des bibliothèques standards sont souvent très performants (souvent plus que si un utilisateur lambda le recodait), même s'ils peuvent parfois souffrir un peu de leur généricité (il peut être plus efficace de recoder une structure de données spécifique, plutôt que d'utiliser celle de la STL).

pour la simple et bonne raison qu'un humain sait pourquoi un algorythme est tel qu'il est et un compilo, bien qu'il puisse comprendre un algorythme, il ne saura jamais pourquoi.

Oui. Mais plus le compilateur a d'information (connaitre ce qui est constant, connaitre les fonctions qui font des effets de bords, etc.), plus il peut optimiser. Nombre d'optimisations sont plus faciles à implémenter sur un AST (arbre de syntaxe abstraite) de haut-niveau, que sur la représentation de bas-niveau.

comment la machine peut elle optimiser en profondeur si elle comprend que le comment, et pas le pourquoi ?

On ne demande pas à la machine d'optimiser les algos (encore que, parfois, elle arrive à réduire leur complexité). D'ailleurs, que tu l'écrives en C ou en Python, tu dois écrire ton algo. Le problème reste le même : c'est avant tout au programmeur de réfléchir et d'écrire correctement son algorithme (avec un i, par pitié !).

Au cas où je n'ai pas été clair, mon propos est :
un langage de haut-niveau n'est pas nécessairement plus lent qu'un langage de bas niveau, en moyenne. Et surtout avec les progrès des compilateurs, ils peuvent devenir (ou deviendront) plus performants, sur les projets de taille raisonnable.

Et pour finir, comme tu t'amuses à comparer l'IA avec le cerveau humain, regarde ce qu'il passe. Dans pleins de problèmes, pourtant parfois considérés comme intelligent, l'ordinateur a dépassé l'humain (certains jeux : dames, échecs, othello, puissance 4...). Dans d'autres cas, ça n'est pas encore arrivé (go...), mais l'IA progresse plus vite que le cerveau humain. Pourquoi les problématiques d'optimisations ne pourraient-elles pas être résolues efficacement par la machine ?

Bien sûr, ici, l'homme pourra toujours réussir à optimiser plus ou autant un code que la machine, mais à quel prix ? S'il était nécessaire de passer un an, à optimiser le code assembleur à la main, pour dépasser le résultat du compilateur, on pourrait alors raisonnablement penser que la machine se débrouille mieux, non ?

PS : cette discussion est un peu hors-sujet, en fait. Peut-être serait-il préférable de continuer ailleurs (ou de déplacer la conversation) ?

[pseudocode]

1. Oui, du code compilé C/C++ est souvent plus rapide que du code compilé (JIT) Java.

On peut toujours trouver des cas ou c'est l'inverse, mais inutile de se voiler la face. La force de Java est ailleurs que dans la performance pure.


2. Si une partie de votre programme java est trop lente, recodez cette partie en C/C++ et appelez la depuis Java (JNI).

C'est une grande force de Java. JNI est simple et tres puissant, pourquoi s'en priver ?


3. Ca fait longtemps que les précompilateurs, les compilateurs et les processeurs optimisent le code.

Vous ne battrez presque jamais un bon algo d'optimisation avec vos petites meninges. N'essayez pas d'optimiser vous meme en ecrivant ce que vous pensez etre une "amelioration" (souvent synonyme de ca-tient-tout-sur-une-ligne). Ecrivez du code clair et lisible, et laissez faire le compilo.

Le code suivant:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
int main(int argc, char** argv) {
  int MAX=10;
  int p, i;
  p=0;
  for (i=0 ; i<MAX ; ++i)
  {
    p+=2;
  }
  return p;
}

a été optimise automatiquement ainsi:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
int main(int argc, char** argv) {
  return 20;
}

auriez-vous fait mieux ?

(source: ici meme)

[Kujara]

Vous ne battrez presque jamais un bon algo d'optimisation avec vos petites meninges.

Ouch, tellement faux ...

2 façons d'optimiser, algorithme, et implementation de l'algorithme.

Pour l'algo lui meme, le compilateur ne fait rien.
Pour l'implementation, le compilateur n'optimise que sur du court terme ( sur la longeur d'une fonction, par exemple).

Pour n'importe que bout de code plus long que ton exemple, rien ne peut remplacer un cerveau humain .....

[super_navide]

Oui je suis d'accord pour l'instant les algo d'optimisations ne permettent pas de remplacer le cervaux humain mais je un jours ca sera possible ...

sinon je trouve que l'absence de classe anonyme ou de closure en C++ en font un langage vieux et barbare pour l'écriture de code propre et concis.
un langage qui n'implemente a minimun la notion de closure (classe anonyme ) est inférieur a java .