Articles : Langages et performances : les Français à l'honneur !
Posté par Lionel Draghi (page perso, ). Modéré le 19 mai 2005.
Le dernier site similaire n'étant plus mis-à-jour depuis 2003, Brent Fulgham a repris le flambeau, et s'est installé sur un serveur Debian.
Ce site permet de soumettre des benchs, de proposer des réalisations de ces benchs pour un langage, et surtout de consulter les résultats sous différentes formes (y compris graphiques) suivant différents critères (en particulier CPU et utilisation mémoire).
La base des résultats actuels est bien remplie, de nombreux langages et compilateurs y figurant avec un bon nombre de benchmarks (il n'est pas nécessaire de tous les réaliser pour figurer dans le classement).
Surprise, juste derrière un C à la domination chancelante, figurent trois technologies dans lesquelles les Français jouent un rôle important (voire qui sont exclusivement française). Il s'agit respectivement de OCaml, Ada et Eiffel.
![[en]](../images/en.png)
Shootout (6308 hits)-
OCaml (1286 hits)
-
SmartEiffel (968 hits)
-
GNAT (Ada) (905 hits)
> Lire la dépêche (179 commentaires, moyenne: 2,5).
Vous avez demandé le commentaire #578063.
Run by 
Cette page a été générée par Templeet en 0.0742s (dont 0.0077 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Dommage ...
Salut,
Je suis un peu déçu par la rédaction de la news. En effet, elle insiste beaucoup sur l'aspect benchmark lui-même, sans ouvrir le débat plus large sur l'utilisation de langages de haut-niveau. Du coup, le débat tient plus du troll mon langage est mieux que le tien, non, c'est le mien qu'il est le mieux, etc... (trolls qu'on a déjà dans la news sur OpenOffice et Java).
Ce qui est intéressant, c'est de voir que les langages de haut niveau ne sont plus sous-performants par rapport à des langages comme le C de base. L'important, ce n'est pas de savoir si Ocaml s'exécute 0.5% plus vite que du Java ou du C++ dans tel cas précis, mais bien de voir que les performances globales des langages de haut niveau sont tout à fait honnêtes.
À partir de là, on pourrait se demander si il ne serait pas judicieux d'arrêter de développer tous les logiciels avec des langages préhistoriques comme le C. Je ne dis pas ça parce que je ne sais pas programmer en C (je bosse sur de la programmation système, donc que du C), mais parce que pour moi coder gkrellm, thunderbird ou grisbi en C, c'est une perte de temps. Des langages de haut niveau existent, ils rendent le code plus lisible, plus abordable pour des contributeurs et ils permettent d'éviter les bugs foireux de débordement de buffers, de mémoire pas libérée et autres. Pour moi, ces langages de haut niveau, c'est vraiment un atout pour le programmeur. Pourquoi ne pas les utiliser plus massivement pour toutes les applications de bureau ?
La performance ne me semble pas être la bonne raison : la plupart des logiciels "de bureau" ne font pas du calcul scientifique qui nécessite d'être optimisés aux petits oignons.
En fait, j'ai l'impression que pour l'instant, le langage C est pris parce que c'est le seul suffisamment répandu. Aucun langage de haut niveau n'a vraiment réussi à s'imposer : ni Ocaml, ni Eiffel, ni Java, ni C#.
Quand je vois Novell qui essaie d'utiliser C# et Mono dans ses nouveaux outils et logiciels, je trouve que c'est plutôt une bonne idée. Une bonne idée dans le principe d'utiliser un langage de haut niveau, mais on sait tous que C# et Mono peuvent peut-être poser des problèmes (pouvoir de Microsoft ? brevets ?).
Qu'en pensez-vous ? Pourquoi les applications sont-elles toutes développées en C ?
[^]Re: Dommage ...
tout dépent des applications, il y a de moins en moins qui sont écrit en c
dans le commerce c'est haut la main C++ qui gagne...
faut pas raconter n'importe quoi, java s'est imposé en entrerprise, dans les gros système
s'imposerra-t'il sur le marché du bureau avec mustang et dolphin?
gnome utilisera t'il java ou mono?
www.laboiteaprog.com
[^]Re: Dommage ...
Moi j'aime bien la news:
L'aspect langage pour ses capacités d'expression mérite d'être développé.
Quand à savoir pourquoi le C est utilisé, il faut dire qu'il est facilement identifiable et qu'il permet de rassembler des contributeurs plus facilement. Et il permet d'écrire du code qui sera facilement lib-ifié et pourra s'imposer. En ce qui concerne ses qualités propres, il ne rend pas impossible la programmation de haut niveau (mais sans garde fou).
Par contre, utilisé en tant que langage de haut niveau il coûte beaucoup plus en refactorisation, il est difficile à faire évoluer et à réutiliser. Donc les nouveaux projets ont intérêt à éviter.
[^]Re: Dommage ...
Qu'en pensez-vous ? Pourquoi les applications sont-elles toutes développées en C ?
Au hasard :
Disponibilité de compilateurs nombreux, efficaces et sûrs (enfin, raisonnablement) => indépendance vis-à-vis du fournisseur du compilateur.
Disponibilité de nombreux développeurs => indépendance (relative) vis-à-vis des développeurs (je parle du point de vue de la méchante entreprise, s'entend), facilité à auditer le code (essayez d'auditer une jvm codée en whitespace :-D ... )
Expérience disponible en interne.
Forte quantité de code libre de qualité facilement réutilisable ("On s'en fout, que ce soit du GPL, puisqu'on le garde en interne", "Tiens? du BSD!"); bibliothèques nombreuses.
Technologie éprouvée, parfaitement maitrisée, problèmes connus (tout le monde sait que le C est sensible aux problèmes de dépassement de tableaux, il suffit d'y faire attention); frilosité des décideurs ou des codeurs.
Maîtrise du code produit, et liberté de faire ce que l'on veut dans le programme (comment fait-on pour faire un lien matériel entre deux fichiers en Java, déjà? - Je VEUX faire un buffer overflow à cet endroit, et je ne comprend pas pourquoi je n'y arrive pas dans en Ada).
Portabilité raisonnable.
Tous les arguments qui précèdent, réunis dans un seul langage.
[^]Re: Dommage ...
Je VEUX faire un buffer overflow à cet endroit, et je ne comprend pas pourquoi je n'y arrive pas dans en Ada).
C'est une caractéristique essentiel d'Ada : tout est possible, y compris un buffer overflow.
Mais pour faire une goretterie pareille il faut faire un effort une fois. (Je me demande bien pourquoi, au passage).
Dans d'autre langage c'est pour éviter le buffer overflow qu'il faut faire des efforts... tout le temps.
L'esprit n'est pas le même, et ca fait une grosse différence.
[^]Re: Dommage ...
Rofl, bientôt un troll OCaml contre Whitespace :-)))
Pour ma part, je pense qu'au dela de la disponibilité en nombre de programmeurs, bien que de plus en plus de jeunes en fassent à l'école, il manque aussi à OCaml certains critères pour que le patron moyen (et un patron, c'est malheureusement un patron) ose se pencher un peu dessus :
- Une réputation... actuellement c'est plus du genre "un truc de chercheurs"
- Une belle IDE présente sous Win, Mac et Linux, qui soit pleinement fonctionnelle
- Un débuggeur potable et visuel (i.e. facile à utiliser)
Montrez moi les trois et je tente le coup avec mon patron (on passe notre code delphi en OCaml - ça peut pas être pire que Delphi 5.0 !)
[^]Re: Dommage ...
Peut être parceque les developpeurs de LL font généralement ça pour le plaisir (et pas pour le rendement, les deadlines etc.) ?
Je pense aussi qu'un grand plaisir est d'utiliser un langage dont l'apprentissage permet aussi de mieux maitriser et comprendre le système sur lequel on l'execute. Ici le C est roi.
Et puis je pense que les devs de LL n'ont pas besoin de se conformer aux lubies des decideux préssés comme en entreprise ; et qu'on ne leur vend pas si facilement du java-c-est-portable et autre c-sharp-c-est-universel à coup de campagnes de marketing sur 01.net ...
[^]Re: Dommage ...
Je comprends bien ce que tu dis sur l'aprentissage.
Mais concernant le développement, il ne s'agit de rien d'autre que de ton temps : tu le gaspilles ou tu l'utilises.
Débuggez ou développez, that is the question.
La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.
Et pour ta dernière phrase, je me félicite que les dev de LL ne fassent pas le même choix que les entreprises, car curieusement les entreprises ne sont que rarement rationnelles, et elles vivent dans la psychose de prendre du retard et ne pas être dans le "mainstream".
[^]Re: Dommage ...
La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.
J'fais la meme chose en C, incroyable non ? :)
Globalement je pense qu'un langage permissif permet certe de faire n'importe quoi facilement, mais qu'un peu de rigueur suffit à creer des trucs fiable et bien écrit pas trop lentement. Mais je ne me fait pas d'illusion, le haut niveau permet de bonne économie de temps de devel, et force les gens à ne pas écrire n'importe comment. J'insiste sur le fait que cela a un cout à l'execution (quelqu'il soit : empreinte mémoire, charge CPU, pires cas, ...) ou un cout à l'acces au langage (changement de modèle de developpement, framework), et qu'il faut determiner son degré d'acceptabilité.
[^]Re: Dommage ...
J'insiste sur le fait que cela a un cout à l'execution
Tout à fait, mais justement le bench montre que ce coût peut-être faible.
Par ailleurs, dans le cas de Ada, de nombreux checks sont fait à la compilation, car le source est sémantiquement riche. Ceci est sans conséquence au niveau du code généré.
Quand aux vérifications à l'exécution, tu as la possibilité de les enlever là ou tu le souhaite, soit par les options de compilation, soit directement par des pragmas dans le source. Ceci est utile par exemple lorsque qu'un outils externe te fournit une preuve formelle de ce que ces vérifiations sont inutiles.
Mais en fait, c'est rarement utile, car le compilateur fait un très bon boulôt d'optimisation.
Tu as donc le beurre et l'argent du beurre :
- vérif en abondance à la compil,
- vérif à l'execution pour le reste,
- performance quand il le faut.
Pour finir, il y a un compilateur Ada qui fait très fort car il ajoute de nombreux warnings et optimisations par dessus ce qui est imposé par le langage (et même des suggestions de corrections pour les erreurs bateau et les typos).
Et pour la chance du monde du libre, il se trouve que c'est justement GNAT, le compilo Ada de gcc.
[^]Re: Dommage ...
Salut Thomas,
Tu as raison, j'en ai trop fait sur le bench, et les précautions pour éviter les trolls sont parfaitement inutiles sur ce genre de sujets. J'ai en fait commencé une réponse dans la discussion Java et OOo, mais ca m'embettait de participer à ce troll.
Alors, j'ai fais un article.
Toutefois, ce que tu dis est exactement la première moitié de la news. Ta conclusion sur la l'inutilité de C dans la plupart des développement moderne est exactement l'essence de l'article.
L'autre message que je voulais faire passer, c'est que les solutions "mainstream" ne sont pas forcément les meilleures, mais, bon, c'est si rassurant d'être dans la masse. Utiliser une solution originale demande d'être cultivé déjà rien que pour en avoir eu connaissance, encore plus pour bâtir un argumentaire comparatif (alors que si tu fais du C personne ne te demande rien).
Faut être un peu couillus ou associable, je trouve :-).
Tiens, sans le faire exprès je t'ai donné une réponse à ta question sur pourquoi C domine toujours outrageusement :-)
[^]Re: Dommage ...
Mets-toi à la place du programmeur débutant. Pour se mettre à programmer, quelles docs trouve-t-il en premier à Carrouf dans le rayon des bouquins Sybex/Microapp à 10 euros -> C++/Java ! Et même s'il a appris que OCaml est un super langage, et qu'il se décide à acheter un bouquin pour s'y mettre (50 euros mini quand même), quel genre de bouquin trouve-t-il ? Une grosse intro très rigoureuse à la programmation fonctionnelle (voire au lambda-calcul), de l'algorithmique avec des arbres/listes chaînées, etc. Des choses très bien pour comprendre, acquérir de la rigueur et devenir un bon programmeur mais qui vont décourager notre programmeur débutant qui voudrait savoir rapidement faire des applis qui cartonnent comme avec Python... A quand un "Ocaml pour les nuls" ? :o)
Et si le programmeur connaît le C/C++ (comme moi), il veut aussi pouvoir s'y mettre rapidement en se raccrochant autant que possible à ce qu'il connaît. Ce serait une bonne chose si les concepteurs de OCaml écrivaient un bouquin/tutoriel visant le programmeur moyen (pas forcément étudiant en informatique) avec un peu plus de concrêt, genre un "OCaml pour les programmeurs C/C++, avec des exemples utilisant QT, OpenGL, SDL...
Enfin, apparemment (je ne maîtrise pas le sujet) il semble y avoir une véritable barrière à l'entrée pour les débutants qui voudraient utiliser OCaml avec des libs en C (pour lesquelles aucun binding officiel n'aurait été écrit). Notamment je crois qu'il faut faire gaffe à des détails liés au gc...
[^]Re: Dommage ...
Je suis d'accord. Même si ce n'est sûrement pas aux programmeurs de caml d'écrire ce livre, ils ont probablement beaucoup mieux à faire.
Cela dit, le livre O'Reilly sur OCaml (dispo en ligne) est assez facile d'abord et ne part pas dans des considérations trop théoriques (même s'il manque une partie lablgtk2 pour faire de vraies interfaces graphiques).
[^]Re: Dommage ...
Je ne parlais pas forcément d'Ocaml. J'ai également beaucoup de mal à me faire à ce langage. Je parlais en général des langages de haut-niveau sans présumer d'un quelconque choix.
Des langages comme Ada ou C# sont par exemple des langages assez simples, mais proposant des abstractions et une bibliothèque moderne.
En fait, dans le C, ce qui m'embête, ce n'est pas seulement le langage en lui-même et la manipulation des pointeurs, mais c'est aussi la bibliothèque standard C, en particulier la manipulation de chaînes de caractères : fgetc, getc, gets, fgets, putc, puts, fputs, fputc, getchar, putchar, toutes les fonctions genre strncpy qui font pas bien le boulot, sans parler des sockets qui sont assez difficiles à utiliser correctement, etc... Il me semble qu'il y a des langages de plus haut niveau proposant des bibliothèques standard mieux conçues, permettant de développer plus vite, avec moins de bugs.
Le problème, c'est qu'aucun langage ou plateforme ne s'est réellement imposé à ce jour pour développer des applications "de bureau" avec un langage de haut-niveau. Je veux développer une appli simple avec une interface graphique. Je dois le faire en quel langage si je veux un langage de haut-niveau, avec de nombreuses bibliothèques et connu par de nombreux développeurs ? Ruby ? Python ? Java ? C# ? Ada ? Ocaml ?
Actuellement, je le fais en Python, mais l'absence de typage et de déclaration de variable me gêne vraiment.
[^]Re: Dommage ...
Je proteste, tu n'as pas cité Perl :)
Surtout que dans ton cas, ça peut régler le problème des déclarations de variables (et éventuellement celui du typage avec "use types" et compagnie).
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.