La rapidité des langages de prog

La vitesse d'un programme dépend plus de l'algorithme que du langage.
Si vous codez comme un con en assembleur ça n'ira pas plus vite qu'un bon algo en visual basic.
La seule chose qui change d'un langage à l'autre c'est l'espoir.
En assembleur vous avez l'espoir d'atteindre a perfection alors qu'en java ou C# vous ne pouvez aller plus vite que ce que la VM permet.
Mais t'as le temps avant d'avoir besoin de plus d'espoir. :)

Le meilleur langage c'est celui que vous connaissez.

Méfiance avec ces idées reçues:

De nos jours les machines virtuelles sont capables de faire des optimisations à la volée que les compilateurs natifs sont incapables de faire.
(On a déjà mesuré des programme écris en C# plus rapide que leurs équivalents C++ compilés natifs.)



Les langages à machine virtuelle (Java, C#, Python...) sont à la mode pour de bonnes raisons:

- avec les compilateurs JIT (Just-in-time), on atteind maintenant d'exellentes performances.

- on arrive même à des optimisations à la volée infaisaibles avec les compilateurs natifs.

- il existe (comme le fait remarquer Char Snipeur) des compilateurs natifs (par exemple pour Java).

- ils affranchissent le programmeur de certaines besognes bas niveau (exemple: allocation mémoire, gestion des chaînes de caractères...) afin de se concentrer sur la logique du programme elle-même, car:

- les ordinateurs sont de moins en moins chers. Les programmeurs compétents le sont de plus en plus.
Donc à part quelques domaines spécifiques (calcul scientifique), le temps processeur n'est plus un élément déterminant.

Un programme Python sera plus lent que le même en C++, mais il sera plus lisible, et donc plus facile à maintenir et coûtera donc beaucoup moins cher à maintenir et faire évoluer.


Au début de l'informatique, le slogan d'IBM était: "Achetez-nous un ordinateur, on vous offre 2 ingénieurs avec."
Maintenant, ce sont les ordinateurs qu'on offre, et le service qu'on fait payer (très cher).

Le temps CPU n'est plus un facteur déterminant dans la grande majorité des secteurs.



Auriez vous des ordes de grandeur

Comme dit Char Snipeur, c'est très variable en fonction des options d'optimisation, du compilateur lui-même, de l'architecture du processeur destination, de l'implémentation de la machine virtuelle (s'il y en a une), de la nature des algorithmes, de la quantité d'entrées/sorties du programme, etc.


Mais si tu penses qu'entre C++ et Pascal il y a peu de différence, alors je pense que ceux qui font du Fotran sont encore à la "vieille école"...

Pas forcément.
Chaque langage a sa façon de penser.

Le fortran est sûrement mieux adapté à certaines tâches mathématiques que le C++.

De même, le SQL est bien mieux adapté à l'aggrégation et la recherche de données que le C++.
Bien sûr, tu arrivera à faire la même chose en C++, mais tu en chiera des ronds de chapeau, et même si le C++ est performant, ton algo ne sera probablement pas aussi performant que les mécanismes internes du SQL.

Si une VM va plus vite qu'un code assembleur c'est juste que celle ci connait mieux le processeur que le développeur de ce code.
Une VM n'est rien d'autre qu'un code assembleur exécutant un langage scripté. Cela revient à comparer l'algo du développeur à celui de la VM.

Note toutefois que je ne parle que d'espoir.
Dans la pratique il faut être un dieu de l'assembleur pour rivaliser avec les VM.

Salut.
Je pense que la réponse n'est pas si facile que ça.
En effet, déjà en C++ ça dépend des options que tu met lors de la compilation, ensuite, la façon d'écrire le code peu modifier la vitesse.
J'avais lu quelques part que la java était très proche du C, avec une perte de vitesse inférieur à 10%. Mais tu peux aussi faire du java compiler avec gcj (gcc) et certaines machine virtuelles "finisent" la compilation du bytecode afin d'être plus rapide.
Le fortran c'est surtout rapide à compiler, à l'exécution, pas de vitesse supérieur au C, ou alors si peu...
J'avais comparer Pascal et C++ , je n'avais pas constater de gain intéressant.
Pour finir, je pense aussi que ça dépend de ce que tu veux faire : math, graphique, son, etc...
Dans le monde du calcul scientifique, c'est plutôt fortran 77, ou C++ lorsque le code a besoin d'être plus compliquer (pointeurs, tableau dynamique).

Salut Char Snipeur, et merci pour la réponse.

Justement, je sais que le Fortran77 est connu dans le monde scientifique, mais je trouve ça absurde lorsqu'il faut faire du code développé.

J'ai vu des programmes scientifiques d'environ 10 000 lignes de code (!!) en Fortran 77. La même chose serait tellement plus simple à créer, lire et maintenir en C++.

D'où ma question...

Mais si tu penses qu'entre C++ et Pascal il y a peu de différence, alors je pense que ceux qui font du Fotran sont encore à la "vieille école"...

Salut Sebsauvage, et merci beaucoup pour cette réponse très complète !

Si ça se trouve, je vais apprendre le C#, il paraît que c'est encore plus performant que le C++...

Je suis en partie daccord avec toi sur la vitesse des CPU.
Mais je pense que cela dépend des logiciels. Les encodeur, (DivX , MP3, DVD) ont intéret à être rapide.
Et que pense tu des jeux? là le CPU tourne souvent à plein, même si c'est de plus en plus la carte video qui prend les graphismes à sa charge, ça ne fait que égager du CPU pour l'IA.
Au final, je ne suis pas si sur que ça que se soient des domaines spécifiques marginaux...

Et que pense tu des jeux?

mmm... c'est vrai.

Ceci dit, il y a un paquet de jeu faits en C (ou autre) qui vont bien plus
vite que ceux écrits en C++.
Ce que je veux dire: Ce n'est pas l'utilisation du C++ qui garantiera les performances de calcul d'un logiciel.


D'expérience, à trop vouloir se focaliser sur les performances bas niveau, on en oublie d'améliorer la logique du programme (haut niveau) qui - elle - pourrait faire gagner énormément en performances.


Exemple:
Vous avez fait une super modélisation objet de votre jeu 3D.
Même chaque balle tirée par un flingue a ses attributs (orientation, vélocité, référence du tireur, etc.)

Le joueur tire 10 cartouches par seconde.
ça vous fait 600 objets à instancier et à détruire par minute.
C'est lourd, terriblement lourd.

Alors que tout ça serait aussi bien géré par une simple structure en C.


Donc le C++ - et la programmation objet en général - n'offre aucune garantie de performance.

Bonjour,

Je me permets de relancer la discussion, même longtemps après car actuellement je travaille sur une problématique liée.
En effet, je suis devant un code C# qui a un certain temps d'exécution et lorsque l'ont traduit ce code en Java (traduction quasiment directe), le temps d'exécution n'est pas loin de tripler!
J'aurais voulu avoir des informations, des pistes de recherche pour expliquer la différence et si possible la gommer.

Je me pose par exemple la question de savoir si l'utilisation de sleep dans le code n'influe pas sur le temps d'exécution, fonction de l'OS mais aussi de l'implémentation Java/C# ? serait-ce mieux avec wait? ou alors est-il logique de ne pas mettre le même nombre de millisecondes dans un sleep en Java et en C# ?

Merci d'avance pour vos réponses.

salut.
Tripler entre C# et java ! ça me paraît énorme. Déjà, dit nous en un peu plus, c'est quoi comme code ?
Il est possible que ce temps d'execution supplémentaire vienne des différentes options de compilation ou des JIT.
pour moi sleep(x) attend x millisecondes avant de continué le programme. Je ne croi pas que les millisecondes en C# soient différentes des millisecondes en Java, ou alors il faut revoir la théorie de la relativité et toute la physique moderne.

Merci de ta réponse.

En fait tripler le temps, quand on considère des millisecondes n'est pas forcémment énorme.. c'est relatif bien sur!
Il s'agit d'une appli sur pda pour piloter un device (lecture) dans laquelle il y a un sleep pour attendre une réponse vraisemblablement (en fait je n'ai pas codé moi meme l'appli, je m'occupe juste des performances..) Les pilotes originaux ont été écrits en C# et traduits basiquement en Java. Des différences ont alors été constatées en terme de performance.

Je ne sais pas comment est traduit le sleep en code machine, si la traduction est la même venant du C# et du Java c'est sur que cela ne doit pas venir de ça. Ceci étant, j'ai lu que suivant le contexte d'exécution (environnement, jvm,..) des différences pouvaient être constatées, c'est pourquoi je me posais la question de savoir si les 2 sleep étaient équivalents..

Concernant la différence entre sleep et wait, j'ai trouvé pas mal de discussions à ce sujet mais aucune n'abordant l'aspect performance..

Bonjour,

On peut facilement faire un programme catastrophique en C++. Le meilleur exemple pour ça est l'héritage multiple qui plombe complètement les performances. On parle de 40 à 50% mais je n'ai pas vérifié cela. Comment ça la STL en regorge ? Ah bah oui...

Bien des programmes auront de meilleures performances si il sont écrits en C et non en C++ par exemple, mais c'est simplement à cause du programmeur qui ne connaît pas son langage. Le C est simple et sans pièges.

Pour les sleep cela ne dépend que de l'implémentation de la machine virtuelle. Deux programmes Java ne seront pas forcément interprété de la même façon. (L'un pourra faire des NOP et l'autre enregistrer un événement et attendre une interruption par exemple) On ne compare plus ici des langages mais des implémentations de machines virtuelles.

M.

Ici je voulais plutot comparer les performances de Java et C# plutot que C et C++ mais l'esprit est le même, le programmeur a sa part de responsabilité dans les performances d'un programme.
Mais dans mon cas, l'algorithme est le même, c'est une transcription casiment instantanée du C# au Java.

Pour le sleep je comprends, et il n'y a donc pas une manière de faire en sorte que cela ne dépende pas de la machine virtuelle? utiliser autre chose que le sleep pour faire attendre un programme? (l'utilisation d'un timer est-elle recommandée? ou d'un wait?) ou aurons-nous forcément les mêmes problèmes?

La réponse est dans le message de Mahmah :
On ne compare plus ici des langages mais des implémentations de machines virtuelles
Ce qui est valable entre 2 JVM, doit l'être entre une JVM et celle du C#.
Utilise des outils de profilage pour savoir où tu perd du temps. Pourquoi penses tu qu'une différence d'implementation des sleep puisse engendré une telle différence ? qu'un sleep(100) dure 100 µs ou 110µs, ça ne triple pas ton temps d'exécution. Il faudrait pour ça qu'il passe de 100 µs à environ 400 µs (le programme doit bien faire autre chose que des sleep, donc un triplage du temps d'attente ne triple pas le temps d'exécution).

Ok je comprends merci pour vos lumières!
Je me posais la question des sleep juste parce que on m'a appris (a tort ou a raison..) qu'il fallait les éviter (pourquoi ça..)

Mon rêve aurait été qu'il y ait une 'énorme' différence d'implémentation entre C# et Java pour pouvoir expliquer "facilement" cette différence.. du genre un sleep pas interprété de la meme manière par une JVM et son équivalent C#. Enfin, meme si ça pourrait l'expliquer en partie il est clair que pas tout.