Salut à tous,
J'ai testé quelques langages.
http://perso.orange.fr/2007/Code/hworld/
Vos impressions?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Performances des langages
Salut à tous,
J'ai testé quelques langages.
http://perso.orange.fr/2007/Code/hworld/
Vos impressions?
Bonjour,
Tu n'es certes pas le premier à le faire, et le problème qui revient toujours n'est aps de comparer le temps d'exécution en lui-même, mais comment tu as écris le code...
En effet, de très simples différences dans le code peuvent augmenter considérablement le temps d'exécution, alors que d'autres vont le diviser drastiquement.
Qu'est-ce que tu voulais comparer? Quelles sont les conclusions que tu crois pouvoir tirer de l'exemple que tu as pris? Quelles sont les précautions que tu as prises pour éviter des biais (quand je compare la taille de l'exécutable Fortran et de l'exécutable C, je me dis qu'il y a un problème dans la manière dont la mesure a été faite)?Envoyé par Lunixinclar
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
C'est sûr qu'un hello world ne peut servir à comparer la puissance des langages.
En revanche il dénote certains écarts dans le temps de chargement.
Jean-Marc il n' y a qu'à cliquer sur le lien "infos" pour voir la ligne compilation (ainsi que la version du compilateur). Si tu as une suggestion pour la taille des exécutables n' hésites pas à la partager!
En quoi le temps de chargement d'un hello world est caractéristique du temps de chargement d'une application?
Tu compares d'une part la taille de scripts (qui pour être utiles ont besoin d'un exécutable) avec d'autre part des exécutables liés dynamiquement et des exécutables liés statiquement. Qu'est-ce que tu peux conclure de ça?Jean-Marc il n' y a qu'à cliquer sur le lien "infos" pour voir la ligne compilation (ainsi que la version du compilateur). Si tu as une suggestion pour la taille des exécutables n' hésites pas à la partager!
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
La question c'est surtout de savoir ce que toi tu peux en conclure.
Ben c'est intéressant de constater des différences entre les langages compilés/pré-compilés et interprétés.
Même si tous n'ont pas le même potentiel (portabilité/GUI/syntaxe facile à assimiler/...) et que les shells sont TRES limités au niveau des tableaux, on peut se demander dans quel cas certains langages sont à privilégier plutôt que d' autres, et pourquoi tous cohabitent
sans prédominance de l' un sur les autres?
Quelques conclusions
1) Les langages compilés sont les plus rapides au chargement. Même si dans l' absolu c'est stupide, c'est à prendre en compte par qui veut écrire l' appli la plus rapide au monde. Certains shells s'en sortent bien quand même.
2) Dans le cadre d'un système comptant plusieurs applications, les langages compilés occupent plus d' espace disque car pour un nombre équivalent d' applications, les langages interpétés n' occupent que la place de leur source et de l' interpéteur.
3) Les langages interprétés ont moins de lignes de code. Donc un temps de développement inférieur? Ca dépend surtout du programmeur. Cet été sur le forum "langage C" on a testé l' implémentation d'un algorithme par plusieurs programmeurs C. Ce que certaines implémentations font en 20ms, d' autres le font en 300. C'est pourquoi le "hello world" est la seule chose qui soit vraiment comparable entre plusieurs langages car pour un langage donné, il y a autant de façons d' écrire un programme qu'il y a de programmeurs. Et autant de différences de vitesse. Je n' avais pas compris ça au début... c'est con à dire mais c'est vrai.
4) La présentation des résultats est nulle, est-ce que la forme est plus importante que le fond?
5) Ce que fait Java sur une application minimale, le C a le temps de le faire 26 fois. Ce n'est pas si anecdotique que ça: beaucoup d' applications système ont un rôle ultra-précis comme d'envoyer une seule chaîne sur la sortie standard. Java rame au démarrage, probablement à cause de son garbage collector. Mais il se rattrape sur la portabilité, qui a un prix. Une appli java est portable au niveau binaire, alors que le C est portable au niveau source.
etc, etc ...
pour java, tu pourrais preciser directement que tu utilises Kaffe, c'est pas le plus commun pour faire tourner ce langage, et surement pas le plus rapide non plus d'ailleurs
sinon, je pense aussi que faire du test sur hello world, ben ca n'a aucun interet
Rien d'intéressant.
Qu'est-ce qui te fait croire que tes mesures sont caractéristiques de ce qui se passe pour de plus gros programmes?Quelques conclusions
1) Les langages compilés sont les plus rapides au chargement. Même si dans l' absolu c'est stupide, c'est à prendre en compte par qui veut écrire l' appli la plus rapide au monde. Certains shells s'en sortent bien quand même.
Et les bibliothèques partagées?2) Dans le cadre d'un système comptant plusieurs applications, les langages compilés occupent plus d' espace disque car pour un nombre équivalent d' applications, les langages interpétés n' occupent que la place de leur source et de l' interpéteur.
Et "hello world" n'est en rien caractéristique de vrais programmes. Donc les conclusions que tu peux tirer d'une comparaison basée sur ça me semblent suspectes a priori.3) Les langages interprétés ont moins de lignes de code. Donc un temps de développement inférieur? Ca dépend surtout du programmeur. Cet été sur le forum "langage C" on a testé l' implémentation d'un algorithme par plusieurs programmeurs C. Ce que certaines implémentations font en 20ms, d' autres le font en 300. C'est pourquoi le "hello world" est la seule chose qui soit vraiment comparable entre plusieurs langages car pour un langage donné, il y a autant de façons d' écrire un programme qu'il y a de programmeurs. Et autant de différences de vitesse. Je n' avais pas compris ça au début... c'est con à dire mais c'est vrai.
S'il y a bien une chose à laquelle je n'attribuerais pas la lenteur de Java au démarrage, c'est au garbage collector. Sur quelque chose d'aussi simple, il ne se met pas en route...5) Ce que fait Java sur une application minimale, le C a le temps de le faire 26 fois. Ce n'est pas si anecdotique que ça: beaucoup d' applications système ont un rôle ultra-précis comme d'envoyer une seule chaîne sur la sortie standard. Java rame au démarrage, probablement à cause de son garbage collector.
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Au moin maintenant, si on veut faire un Hello world, on sais quel language utiliser !
et pour PHP, tu as fait comment ?
tu as chronométré le temps que mettait ton browser pour afficher "hello world" ?
Dans ce cas tu aurais aussi pu tester le HTML !
petite contribution (Matlab)
sur un P4 à 3ghz
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3>> tic;disp('hello world');toc hello world Elapsed time is 0.000038 seconds.
Conclusion : Quand on a un PC rapide, Matlab est un excellent langage pour faire des Hello World !
ce test il a sa place dans la taverne avec les blagues !!!
Deja rien entre le fait d'appeler une seule commande et celui de faire tourner tout un programe il y a de la marge (un langage interprété est certes plus long au démarrage ... initialisation de machine virtuelle etc...) mais est-ce que les écarts ne tendent pas à diminuer lorsque cette initialisation est faite (donc en répétant pa smal de fois la commande ?)
Ensuite un langage comme java a plusieurs implémentation de JVM.
Ensuite il faut préciser ce qu'on cherche a tester car les temps de réponse relatifs entre 2 langages ne sont pas necessairement les mêmes entr eun Hello World et un appel récursif assez profond.
Ensuite, si un langage assembleur doit etre comparé au Java il faut aussi préciser dans quel contexte car meme si l'assembleur etait 100 fois plsu rapide je l'utiliserais pas pour une application de gestion s'il me faut 400 fois plus de temsp pour la développer ( tout le monde n'a pas des besoins en performance qui sont ceux de la programmation systèmes ...)
Bref sans précision de contexte ce test seul ne me semble effectivement rien apporter mais c'est un avis ...
Chef de Projet SAP. Certifié Prince2 Practitioner
---------------------------------------------------
Anakin Skywalker turned to the Dark Side after his failed attempt to upgrade R/2-D2 to R/3-D2.
le pauvre quand même
il a dut s'embêter à faire tout ça.
Et nous on lui dit que ça n'a servi à rien...
Oui c'est vrai que ca a du demander pas mals d'efforts mais rien n'est perdu. La présentation des résultats est correctes, la démarche pour effectuer les test est connue. Il ne reste plus qu'à recommencer ces tests avec de smorceaux de code significatifs en prenant les remarques en compte et ca pourra devenir très interessnat
Chef de Projet SAP. Certifié Prince2 Practitioner
---------------------------------------------------
Anakin Skywalker turned to the Dark Side after his failed attempt to upgrade R/2-D2 to R/3-D2.
Très bon test ( "C language Rulz !!") mais il manque C# et .NET qui sont encore plus lents que VB6
et pour PHP, tu as fait comment ?
tu as chronométré le temps que mettait ton browser pour afficher "hello world" ?
Dans ce cas tu aurais aussi pu tester le HTML !
petite contribution (Matlab)
sur un P4 à 3ghz
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3>> tic;disp('hello world');toc hello world Elapsed time is 0.000038 seconds.
Conclusion : Quand on a un PC rapide, Matlab est un excellent langage pour faire des Hello World !
PHP fonctionne sur les entrées/sorties uniquement. En version CGI bien sûr. En tant que module Apache c'est une autre affaire. Donc il a été testé exactement comme les autres.
Par contre tu as compris pourquoi HTML ne figure pas dans la liste.
Il faut dire que je n' y ai passé que le temps de cliquer sur une icone
C'est vrai Matt (on a posté en même temps). Sur les tests windows, VB6 est 3 fois plus rapide au chargement que C#, VB.NET, et C++managed. Et Java montre le même écart, JDK2 sur wiondows. Je reste convaincu que ça provient de l'initialisation du garbage collector et du chargement de multiples sous-couches de librairies.
Je pense plutôt que ça vient du JIT (Just In Time Compiler). En fait, le code est compilé "dynamiquement" pour être exécuté rapidement quand nécessaire...
Et puis bon, dans le temps indiqué par java, je suis sûr qu'à 99% c'est le temps de chargement de la VM, et qui ne dépend quasiment pas de la complexité du programme... Donc c'est sûr sur un println...
D'ailleurs, y'a le System.out.printf(...) qui est un peu plus rapide, mais tu ne t'en apercevra pas à cette échelle...
Il ne se met pas en route non plus sur un exemple aussi simple.
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
OK, je ne connais pas son fonctionnement en détail...
Donc ça doit être le chargement de la VM...
Si si la différence se verra avec printf: si les deux fonctions ne sont pas strictement identiques, l' écart sera forcément visible sur 1000 tests. Mais pour ce type de mesure il faut lancer le chrono en interne, ne pas mesurer le process complet. Le problème, c'est que printf ne fonctionne que sous le JDK2. Va falloir que je l' installe celui-là si j'ai du temps à perdre.
JM t'es marrant: tout ce qu'on dit est toujours faux, mais en revanche tu ne dis pas ce qui serait la cause. La vraie. Pour ceux que ça intéresse voici un lien vers le cursus 375 d'une fac en Utah (écriture de compilateurs) je conseille de lire jusqu'à la page 189
http://www.cs.utexas.edu/users/novak/cs375187.html
Ce n'est pas tout: la classe produite par le compilateur Java est du bytecode pré-compilé, il DOIT être recompilé par le JIT. Ajoutez à ça les librairies à charger en mémoire, quelques fichiers de configuration à lire... Ca fait beaucoup. Ca justifie au moins les 300 ms même si à l' échelle humaine, ce n'est pas grand chose
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager