A voir également:
- Langage de programmation le plus rapide
- Langage ascii - Guide
- Acces rapide - Guide
- Application de programmation - Guide
- Copie rapide - Télécharger - Gestion de fichiers
- Langage binaire - Guide
17 réponses
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.
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.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
4 juil. 2006 à 14:21
4 juil. 2006 à 14:21
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.
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.
N0euX
Messages postés
6
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
20 mars 2008
2
19 mars 2008 à 13:51
19 mars 2008 à 13:51
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.
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.
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.
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.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
30 avril 2010 à 13:27
30 avril 2010 à 13:27
Dans la pratique il faut être un dieu de l'assembleur pour rivaliser avec les VM.
Je suis d'accord. Dès que l'algo devient un peu complexe, ça devient l'horreur à coder en ASM.
Je suis d'accord. Dès que l'algo devient un peu complexe, ça devient l'horreur à coder en ASM.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 298
4 juil. 2006 à 08:34
4 juil. 2006 à 08:34
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).
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"...
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++...
Si ça se trouve, je vais apprendre le C#, il paraît que c'est encore plus performant que le C++...
kilian
Messages postés
8731
Date d'inscription
vendredi 19 septembre 2003
Statut
Modérateur
Dernière intervention
20 août 2016
1 527
4 juil. 2006 à 16:46
4 juil. 2006 à 16:46
Si ça se trouve, je vais apprendre le C#, il paraît que c'est encore plus performant que le C++..
Non, tout de même, dans la majorité des cas c'est plutôt le contraire pour un même algorithme traduit dans les deux langages....
Non, tout de même, dans la majorité des cas c'est plutôt le contraire pour un même algorithme traduit dans les deux langages....
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
4 juil. 2006 à 16:52
4 juil. 2006 à 16:52
C# ?
Attention, c'est un langage propriété de Microsoft.
Il vaut généralement mieux éviter les langages qui n'appartiennent qu'à un seul vendeur. Ils ne sont pas pérennes. (cf. VisualBasic que Microsoft a enterré.)
Tu ne devrais pas te focaliser sur la performance.
C'est une grave erreur.
Sincèrement.
Sinon on programmerait tous en assembleur, puisque c'est le langage le plus performants.
Attention, c'est un langage propriété de Microsoft.
Il vaut généralement mieux éviter les langages qui n'appartiennent qu'à un seul vendeur. Ils ne sont pas pérennes. (cf. VisualBasic que Microsoft a enterré.)
Tu ne devrais pas te focaliser sur la performance.
C'est une grave erreur.
Sincèrement.
Sinon on programmerait tous en assembleur, puisque c'est le langage le plus performants.
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 298
5 juil. 2006 à 13:38
5 juil. 2006 à 13:38
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...
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...
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
5 juil. 2006 à 13:48
5 juil. 2006 à 13:48
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.
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.
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 298
19 mars 2008 à 14:26
19 mars 2008 à 14:26
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.
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.
N0euX
Messages postés
6
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
20 mars 2008
2
19 mars 2008 à 15:05
19 mars 2008 à 15:05
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..
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..
Mahmah
Messages postés
496
Date d'inscription
lundi 17 septembre 2007
Statut
Membre
Dernière intervention
22 juin 2010
125
19 mars 2008 à 15:23
19 mars 2008 à 15:23
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.
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.
N0euX
Messages postés
6
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
20 mars 2008
2
19 mars 2008 à 16:03
19 mars 2008 à 16:03
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?
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?
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 298
20 mars 2008 à 08:45
20 mars 2008 à 08:45
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).
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).
N0euX
Messages postés
6
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
20 mars 2008
2
20 mars 2008 à 15:44
20 mars 2008 à 15:44
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.
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.
Attention l'intérêt des langages à VM n'est pas d'être orienté utilisateurs ("user freidnly"), mais de faciliter le portage d'un processeur à un autre. Un programme en Java fonctionne sur mon PC, sur un ordianteur Apple, sous linux, sou android, sous iOS, avec un windows phone , etc ... Ce que ni C, C++, C#, pascal fortran 77, ne permet : il faut faire des modifications pour que cela tourne sur une autre plateforme ; c'est ce que l'on appelle le portage du code.
Bonjour,
Perso, je ne suis pas un développeur et pour moi, les langages user friendly sont fait pour baisser le niveau de compétence des développeurs (main d'oeuvre moins chère).
Néanmoins, tous les mécanismes que rajoute une VM, ne sont que des process et des thread que tu rajoute à ce que tu demandes à la machine, cela ne peut donc pas aller plus vite.
Néanmoins, voici un article fait par des gens spécialisés avec des chiffres à l'appui qui répond totalement à ta question:
http://www.silicon.fr/langages-de-programmation-java-reste-le-plus-utilise-et-le-c-le-plus-rapide-43271.html
et les chiffres ici (c hyper technique):
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=all
Perso, je ne suis pas un développeur et pour moi, les langages user friendly sont fait pour baisser le niveau de compétence des développeurs (main d'oeuvre moins chère).
Néanmoins, tous les mécanismes que rajoute une VM, ne sont que des process et des thread que tu rajoute à ce que tu demandes à la machine, cela ne peut donc pas aller plus vite.
Néanmoins, voici un article fait par des gens spécialisés avec des chiffres à l'appui qui répond totalement à ta question:
http://www.silicon.fr/langages-de-programmation-java-reste-le-plus-utilise-et-le-c-le-plus-rapide-43271.html
et les chiffres ici (c hyper technique):
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=all
Modifié par sebsauvage le 30/04/2010 à 09:37
Tout à fait d'accord.
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.
Là par contre je ne serais pas aussi catégorique.
D'abord les compilateurs modernes sont capables d'optimisations parfois meilleures que ce que pourrait faire un être humain (voir cet article), mais en prime la plupart des VM actuelles ont des compilateurs JIT qui donnent d'excellentes performances.
Donc à part quelques cas bien spécifiques (par exemple les couches bas niveau d'un OS), les langages à VM ont des performances largement suffisantes, surtout quand on prend en compte toutes les astuces d'accélération (JIT, cache de code, reverse-proxy cache, etc.)
13 juin 2014 à 15:14
Essaye de lire un fichier en binaire avec File.ReadAllBytes() en VB.net, puis recommence mais cette fois avec un algo en C. Si ton fichier est gros, crois moi que tu va la sentir la différence...