Performances des langages

**Jean-Marc.Bourguet** · 12/09/2006, 20h40

Envoyé par Lunixinclar

JM t'es marrant: tout ce qu'on dit est toujours faux,

Non. Par exemple le chargement de la VM et surtout de la bibliothèque ne me semble pas criticable a priori. Peut-être après mesure.

mais en revanche tu ne dis pas ce qui serait la cause. La vraie.

Pour ça il faudrait que je fasse des mesures et le problème d'un hello world ne m'intéresse pas. Je pourrais spéculer mais je n'ai pas réellement de base pour ça. Le problème avec les deux propositions que j'ai critiquée, c'est qu'elles sont criticables a priori.

L'initialisation d'un GC et l'allocation sont très simples. Sur un exemple aussi petit il est douteux que le GC se mette en route.

Le principe même des compilateurs JIT comme Hot Spot, c'est d'attendre d'avoir identifié les zones critiques pour les compiler plutôt qu'interpréter le byte code. A nouveau, avec un exemple aussi simple, il n'a pas le temps d'identifier quoi que ce soit.

mat.M · 12/09/2006, 21h25

Envoyé par Lunixinclar

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.

Oui mais j'avais fait des tests avec une appli fenêtrée avec VB.NET ; et c'était pas seulement au démarrage

Ce test il provient d'un test pris dans un tutoriel sur VB.NET de...DVP

Sinon si qq'un peut éclairer ma lanterne , c'est quoi tcc sous Linux ?

**Jean-Marc.Bourguet** · 12/09/2006, 21h49

Envoyé par mat.M

Sinon si qq'un peut éclairer ma lanterne , c'est quoi tcc sous Linux ?

Tiny CC

mat.M · 13/09/2006, 16h36

Envoyé par Jean-Marc.Bourguet

Tiny CC

merci cela m'intéresse énormément surtout s'il y le code source du compilo

**Lunixinclar** · 13/09/2006, 16h40

Tcc est un compilateur C ANSI:

de petite taille. Idéal pour les mini distros linux ou distros embarquées, ou pour tenir sur une disquette,
qui compile très vite, en un seul passage sur le fichier source
qui peut interpréter du C (avec de bons résultats)
écrit par un français. A ce sujet, trois des langages testés ont été écrits par des français, on s'en sort pas trop mal. C'est pas à la portée de tous d' écrire un compilateur/interpréteur

Et... il ne s'agit pas de spéculations,

il n' y a qu'à regarder le code source!

**Woufeil** · 13/09/2006, 19h31

Le truc, c'est que les différents langages ne sont pas performannts dans les mêmes domaines...
Par exemple, à une époque (je ne sais pas si c'est encore valable), on avait remarqué que .NET avait beaucoup de mal avec la trigo... C'est pour çq aussi que je trouve qu'un appel type Hello World ne veut pas dire grand chose à mon sens...

**Lunixinclar** · 13/09/2006, 21h01

Oui, et plus important: il ne décrit pas l' interface offerte au programmeur, comme l' orienté objet. Quitte à écrire un moteur 3D, mieux vaut le faire en orienté objet, donc choisir Java ou le C++ plutôt que le C. De plus certains langages sont très richement fournis en bibliothèques qu'il faudrait carrément ré-écrire pour un programme C.
Le hworld n'a d' autre prétention que de comparer le temps de chargement d'une application minimale. La différence entre le code natif et non-natif est flagrante.
Dans l' absolu c'est inutile puisque l'application "hello world" ne sert à rien, sinon à tester l'installation d'un compilateur/interpréteur. On peut quand même se poser la question de savoir si toutes les applications naissent libres et égales, à la base?

**Woufeil** · 13/09/2006, 21h52

J'avais lu le topic en diagonale, désolé

Oui, bien sûr, ce test permet de s'apercevoir qu'un programme en langage non natif met plus de temps à se lancer qu'un en langage natif.

**davcha** · 14/09/2006, 00h54

Envoyé par Lunixinclar

Le hworld n'a d' autre prétention que de comparer le temps de chargement d'une application minimale.

T'as testé ces différences sous différents environnements ?
Genre Linux, Windows, Solaris...
Je demande parce qu'en définitive, tes résultats sont susceptibles de changer sous différents environnements.

Sinon, concernant le test en lui-même, si ton but était de tester le chargement de l'appli, tu aurais sûrement mieux fait de te passer du "hello world", parce que là, en définitive, tu testes à la fois le chargement et l'affichage.

Enfin, le chargement d'un programme c'est pas seulement l'appel initial du point d'entrée du programme en question, c'est surtout le chargement, par le programme, des ressources nécessaires à son utilisation, et ce jusqu'à ce qu'on rende la main à l'utilisateur.
Savoir que ton programme, parce qu'écrit en tel ou tel langage, parcourt le point d'entrée en 38 milliardièmes de secondes, y'a que toi que ça intéresse.
Savoir que ton programme met 5 secondes ou 2 minutes à se charger avant d'être utilisable, ça c'est important.

**Lunixinclar** · 14/09/2006, 07h58

Envoyé par davcha

T'as testé ces différences sous différents environnements ?
Genre Linux, Windows, Solaris...
Je demande parce qu'en définitive, tes résultats sont susceptibles de changer sous différents environnements.

Si un jour tu vois un test qui place Java devant le C tu nous le dis, on relira

Envoyé par davcha

Sinon, concernant le test en lui-même, si ton but était de tester le chargement de l'appli, tu aurais sûrement mieux fait de te passer du "hello world", parce que là, en définitive, tu testes à la fois le chargement et l'affichage.

Pour un script shell, comment faire moins qu'afficher un string sur la sortie standard? Ah oui, rien. La critique est aisée.

Envoyé par davcha

Savoir que ton programme, parce qu'écrit en tel ou tel langage, parcourt le point d'entrée en 38 milliardièmes de secondes, y'a que toi que ça intéresse.

Aha... un lien? http://shootout.alioth.debian.org/gp4/
Chez eux Java est 91 fois plus lent que le C. Il faut cliquer en bas à gauche. Bon c'est une bécanne à 3GHz aussi. Finalement, une confirmation complémentaire.
Il faut apprendre à marcher avant de courrir. Ca non plus ça n'a pas été compris, au début.

Envoyé par davcha

Savoir que ton programme met 5 secondes ou 2 minutes à se charger avant d'être utilisable, ça c'est important.

C'est ce qui justifie l' emploi d'un processeur à 1GHz pour le test, bien vu!

**Sivrît** · 15/09/2006, 14h53

Envoyé par Lunixinclar

Aha... un lien? http://shootout.alioth.debian.org/gp4/
Chez eux Java est 91 fois plus lent que le C. Il faut cliquer en bas à gauche.

...pour démarrer, ce qui est assez peu contesté.

Envoyé par Lunixinclar

Si un jour tu vois un test qui place Java devant le C tu nous le dis, on relira

Y'a qu'à demander.

http://shootout.alioth.debian.org/gp...nbody&lang=all
http://shootout.alioth.debian.org/gp...ssage&lang=all
http://shootout.alioth.debian.org/gp...lnorm&lang=all

Je connais le site et il est assez intéressant. Il s'efforce autant que possible de faire des comparaisons viables (tout en mettant en garde contre la futilité de l'exercice

). On peut y découvrir que OCaml est intéressant, que Clean n'a pas l'air mal du tout, et que sur des applications non triviales (cad plus lourde et plus réelles qu'un "Hello World") java peut briller malgrès son temps de démarrage et de compilation. En fait passé le lancement de la JVM java est compétitif avec le C (en général et si on ne fait pas nimporte quoi dans le code ; beaucoup des facilités qu'il offre - collections, etc. - ont un coût par rapport à des structures plus basiques).

Ce qu'il faut retenir à mon avis c'est que suivant les cas à peut près tous les langages compilés sont succeptibles de prendre la première place (OCaml, C, C++, Java, Pascal... ont tous un test où ils sont premiers ou presque). Et les différentes versions des programmes de test parfois disponibles montrent aussi que, comme cela a déjà été dit ici, l'implémentation de l'algorithme peut avoir une grande importance pour le résultat.

**Woufeil** · 16/09/2006, 18h44

Envoyé par Sivrît

Et les différentes versions des programmes de test parfois disponibles montrent aussi que, comme cela a déjà été dit ici, l'implémentation de l'algorithme peut avoir une grande importance pour le résultat.

Bah pour le coup, heureusement, sinon on aurait plus besoin de vrai développeurs, juste de gars qui codent à la rache, et tout le monde ici connaît la diférence entre les deux

**Lunixinclar** · 23/09/2006, 16h15

Du nouveau!

Quatre langages ont été ajoutés: Neko, Ruby, OCaml, YaBasic
La durée de compilation est à présent elle aussi mesurée
Un lien pointe vers le second test: récursivité. En l' occurence la suite de Fibonacci.
Les programes en code natif se démarquent très nettement.

Le test sur Fibonacci n'est pas terminé: si quelqu'un veut ajouter un code il est assuré de figurer dans la liste des contributeurs. C'est important de citer ses sources.

Revoici le lien de la page pour ceux qui ne l' auraient pas vu.

**InOCamlWeTrust** · 28/09/2006, 22h03

Comme tou les programmeurs, je me suis intéressé à la performance des langages de programmation. Le résultat est cuisant : c'est tout simplement une question débile, et ce pour plusieurs raisons !

Pour un même programme et un même compilateur, les performances sont parfois très différentes selon le système d'exploitation, même si on active les optimisations qui vont bien avec la machine

Ensuite, un langage... ça reste de l'ASCII... et l'ASCII, on ne peut trop rien en dire ! Ce que fait à juste titre le site du Shootout language est intéressant : ils comparent (et c'est dit explicitement) des "implantations de langages". En effet, on parle de la lenteur de Java, et c'est vrai, sa JVM est loin d'être efficace (surtout son Garbage Collector), mais on oublie aussi que compilé avec gcj, c'est tout autre chose. Aujourd'hui avec Jazelle fait par ARM, on trouve même des processeurs temps réel / critique qui comprennent le Java !

La question de la performancedes langages est en réalité une fausse question, non seulement parce qu'il y a souvent un manque d'homogénéité (bien que GHC soit un modèle en termes de stabilité des performances !) mais aussi parce qu'il y a le problème de l'interprétation de la sémantique véhiculée par ledit langage.

On dit souvent que le C est bas niveau... faux ! Ce sont ses implantations qui le définissent de façon à être bas niveau, mais rien (et surtout pas la norme ANSI) n'empêcherait de l'implanter avec des structures telles les blocs à cartouche (ce qui est déjà fait par malloc et mmalloc), etc... un peu à la OCaml !

D'ailleurs, les exemples de Garbage Collector pour C ne manquent pas... ce qui prouve qu'il y a un grand fossé entre l'idée que l'on se fait d'un langage et son interprétation effective.

**HanLee** · 29/09/2006, 00h09

Au fait, pourquoi Java n'a toujours pas un GC aussi performant que celui d'OCaml ?
Les recherches de l'INRIA pour OCaml sont inaccessibles ou non ?

**InOCamlWeTrust** · 29/09/2006, 11h54

N'importe qui peut avoir accès au code du Garbage Collector de OCaml, et ses principes sont tout à fait connus dans les moindres détails : d'ailleurs, ils sont même expliqués dans le livre de O'Reilly.

Le principal problème, je pense, doit se situer au niveau de la rétro-compatibilité et de la compatibilité avec les documents définissant Java et son comportement dans les moindres détails.

Performances des langages

Langages de programmation

Discussions similaires

Partager

Partager