franchement perdre du temps pour ce genre de lapalissade
c'est vraiment ne rien connaitre a la programmation...
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
Discussion :
franchement perdre du temps pour ce genre de lapalissade
Contrairement à d'autres je ne suis pas surpris des bons résultats de Java, son vrai problème est que le code Java est rarement optimisé pour la performance. En revanche je me demande quelle est la JVM utilisée pour les tests? J'avoue ne pas avoir le courage de lire les 267 pages du rapport.
Edition : j'oubliais que de nos jours Open JDK et Hotspot sont quasi identiques.
Bah disons qu'en faisant tourner des services implémentés en C plutôt qu'en Python (par exemple) on consommerait 76x moins d'énergie... sur une planète à ressources limitées, ça compte.Envoyé par darklinux
Certes , mais ni Apple et encore moins Google ne le permettent à cause de la sécurité , chose négligeable il y a trente ans , le C et Python ne permettent pas la sandbox , pas conçus pour . Oui nous sommes dans un environnement limité , mais c 'est pour cela qu ' il faut s ' appuyé sur les GPU .
Le C (même s'il a d'autre défauts) et le Python peuvent tout à fait être sandboxé. Même l'assembleur peut être sandboxé.
Un sandboxing vraiment efficace c'est avant tout du ressort de l'OS pas vraiment du langage.
D’ailleurs sous Android on peut tout a fait utiliser le C et le C++ même si ce n'est pas le langage le plus mis en avant par la documentation. Je connais moins iOS, mais d'après ce que j'ai lu c'est faisable même si c'est compliqué.
Je pense aussi aux serveurs webs. Je me demande quelle est la répartition des langages utilisés pour servir le contenu des sites représentant 90% du trafic mondial.
Par ailleurs j'ai été chercher les sources de test. Le lien donné dans la publi (http://benchmarksgame.alioth.debian.org/) est mort.
Il est maintenant ici https://salsa.debian.org/benchmarksg...benchmarksgame, enfin, presque, c'est le GIT du site web, mais le README donne les sources de test... dans des zip. Bah oui, utiliser GIT pour versionner le code, c'est le passé. D'ailleurs, le README pointe aussi sur un répo "archivé" du benchmarksgame. Comme quoi, les répos, c'est vraiment le passé.
En regardant les sources je n'ai pas trouvé les règles de compilation et d'exécution pour les différents langages (le mainteneur dit ici https://salsa.debian.org/benchmarksg...game/issues/60 qu'il faut le faire soi-même). Du coup on ne sait pas exactement comment ça a été exécuté quand même.
Ou pour dire la même chose d'un point de vue plus égoiste, quand on héberge une application dans le cloud, une application C coûte 76 fois moins cher qu'une application Python. Ce ne sont pas que des scenarios théoriques, je crois que Facebook, à un moment de son histoire, s'est payé un refactoring majeur car le coût des serveurs explosait.
Après, il faut faire un compromis entre la puissance machine, et le temps nécessaire à la programmation. Je crois, pour avoir pratiqué les deux languages, que je préfère java malgré l'overhead de performance pour la facilité de développement apportée.
Open Lowcode Applications sur mesure, résultats rapides et à coûts réduits (repo Github)
Je suis très surpris que personne ne s'offusque des résultats particulièrement décevants de C#... notamment comparé à Java.
J'ai pas suivi l'évolution de Java ces dernières années, mais il y a quelques temps C# était meilleur sur les trois mesures : CPU, temps d'exécution et RAM.
Java a probablement progressé (il ne pouvait de toute façon plus aller dans l'autre sens) mais de là à devenir deux fois meilleur que C# sur chacun des trois critères, je suis perplexe…
Ne serait-ce que d'un point de vue architecture, Java est de facto plus lent que C#, dans la mesure où Java reste en bytecode tout le long de l'exécution, là où C# est compilé nativement au moment de l'exécution…
Sur un for (int i = 1; i < 10; ++i) { write(i); } cette étape de compilation JIT pénalise C#, je veux bien, mais sur un véritable programme qui tourne plusieurs heures ou jours, ça ne peut être que le contraire…
Le meilleur exemple, c'est feu les Windows Phone : pour du matériel d'entrée de gamme, on avait les mêmes performances que sur du haut de gamme avec Android… C# d'un côté, Java de l'autre.
On ne jouit bien que de ce qu’on partage.
L'explication a déjà été donnée pour d'autres langage est reste tout aussi valable pour C# : les benchmarks ont été effectués à partir du "benchmark game" ou tous les langages n'ont pas bénéficié du même niveau d'optimisation. Si vous vous sentez assez fort pour faire du C# bien optimisé, rien ne vous empêche de soumettre vos programmes.
Java a en effet bien progressé, mais il n'a jamais été aussi à la ramasse que la réputation que lui faisaient les trolls habituels.
Seules les toutes premières versions de Java interprétaient directement le bytecode. La JVM de référence fonctionne par défaut avec du JIT depuis 1996, soit six ans avant la sortie de C#.
En fait, c'est surtout que les languages interprétés sont encore bien pires pour ce qui concerne la mémoire / la CPU, et à mon avis, ce qui est presque plus grave, aussi pour le temps de débugage.
Je ne suis pas d'accord avec certaines remarques sur le fait que le hardware n'a plus d'importance: le coût total du hardware dans un projet n'est pas négligeable côté serveur, surtout avec les offres cloud qui vendent l'aspect pratique du cloud assez cher. Cela fait partie du top 10 du gaspillage en informatique de gestion. ON peut donc payer cher à la fin l'utilisation d'une technologie pas efficace.
Open Lowcode Applications sur mesure, résultats rapides et à coûts réduits (repo Github)
C'est d'autant plus vrai que de nombreux outils éditeurs (OS, base de données, etc.) sont vendus avec des licences par coeur, ou avec des limitations en termes de coeurs et mémoire selon les éditions.
Par conséquent, un programme mal optimisé qui nécessite plus de puissance risque d'impliquer des coûts logiciels supérieurs uniquement car il a besoin de plus de hardware pour travailler.
On ne jouit bien que de ce qu’on partage.
Si je programme ( et j'aime ça ) en python, suis-je considéré comme un criminel pour notre planet ?
Tout dépend du programme. Si c'est un Hello World, sa consommation sera négligeable par rapport a ce qu'ont consommé ton IDE, ton compilateur,... Par contre si c'est un programme qui doit tourner des semaines sur un énorme cluster de serveurs, en effet tu as fait un gros gaspillage.
Grep etc.
Bonjour,
J'aime bien la réflexion sur les traitements de chaînes par les expressions régulières qui seraient particulièrement efficaces dans certains langages interprétés. Quand on sait qu'ils s'appuient sur des fonctions écrites en C...
Même si cela peut apparaître marginal, l'analyse ne travaille pas en coûts complets (charges de dévelopement, charges de maintenance, charge de portabilité, occupation mémoire des machines virtuelles et des interpréteurs, espaces de caches...). Par exemple, des charges humaines de réalisation multipliées par deux ont un impact direct sur la consommation d'énergie (transports, bureaux, poste de travail etc.) sans compter les délais de mise à disposition.
Et je ne parle pas des charges induites coté utilisateur qui sont souvent très difficiles à cerner sans être négligeables pour autant. Par exemple au delà de 4s d'attente (les estimations varient entre 3s et 5s) l'attention de l'utilisateur n'est plus assurée, il y aura donc en sus un délai humain de remise en contexte.
Salutations
Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)
En même temps, ça dépend totalement du programme.
Si c'est un script qui tourne pendant 5 secondes 2 fois par an, alors oui, les charges humaines ont un très grand impact.
Si c'est un OS comme Windows ou Linux, ou un outils de bureautique tel que Microsoft ou Open Office, alors que les développeur passe 100 fois moins ou plus de temps à les développer, c'est moins d'une goutte d'eau comparé à l'énergie consomme par la simple utilisation.
C'est d'ailleurs la même chose pour le Hello World cité plus haut. Si c'est la popup de notification de réception d'un SMS sur Android, même si elle consomme 0,001 milliampère/heure, multiplié par les milliards de fois qu'elle est affichée à l'échelle mondiale dans une journée, il doit falloir pas loin d'une centrale à charbon entière pour la faire tourner.
La consommation liée à Internet a explosé littéralement depuis que Facebook lit directement les flux vidéos et que presque tous les jeunes passent leur journée sur Snapchat. La consommation liée aux mails à côté, c'est de l'ordre du milliardième.
On ne jouit bien que de ce qu’on partage.
Optimisations maîtrisées ?
Bonjour,
Je suis curieux de lire les conclusions originales ainsi que la méthodologie complète car de mon constat, Perl (bien utilisé) atteint 99% des performances du C compilé et je ne conçois pas qu'il puisse être classé dernier.
En général, Java est ultra lourd niveau CPU (à cause de la JVM) et le C++ est très proche du C quand bien implémenté.
Cette "étude" me semble assez légère d'un point de vue rigueur dans la méthodologie.
Encore faut-il maîtriser un langage avant de vouloir en mesurer l'efficacité...
Bref.
Si on se place dans le cas où les pauses IO (accès disques, réseau, ...) prennent bien plus de temps que les traitements effectués par le code, avec Perl, comme avec n'importe quel langage, on a en effet des temps de fonctionnement proche du natif. Mais bon dans ce cas là l'étude n'a pas vraiment de sens, vu que tous les langages sont équivalent.
Par contre Perl n'est absolument pas un langage taillé pour les performances de manière générale. Dans les cas où il faut exploiter au mieux la puissance du processeur, il n’atteint clairement pas 99% des performances de Java, encore moins du C. C'est pour cela qu'on l'utilise plutôt en tant que langage de script pour l'administration ou du traitement de document textes plutôt que pour des calcul processeurs complexes.
En gros on peut approximativement classer les langages dans 3 catégories vis à vis des performances :
- les langages orientés vers le développement rapide : Python, Perl, Ruby, Visual Basic...
Ces langages visent avant tout à être accessibles, et pour simplifier la tache du programmeurs, ils n'hésitent pas à recourir à des techniques qui ont des impacts sur les performances : typage dynamique, Garbage collector, ...
Ils se contentent généralement de macro taches et se reposent sur des modules écrits dans d'autres langages pour les parties intensives en calcul.
- les langages orientés performance avec un Runtime lourd : Java, C#, Go, ...
Ces langages visent en partie les performance en faisant moins de concessions que la catégorie précédente. Il utilisent généralement un typage statique. Cependant ils reposent quand même sur un Runtime lourd (code exécute en supplément du code utilisateur, notamment pour gérer la mémoire) qui a un impact sensible, notamment sur l'utilisation mémoire et la prédictibilité des performances.
- les langages sans Runtime : C, C++, Rust.
Ces langage sont compilés sans quasiment aucun Runtime et ont la capacité d'être utilisé à bas niveau. Il ont généralement des performance optimales mais obligent le développeur a prendre en compte beaucoup de point gérés automatiquement par les langages des catégories précédentes.
Même si, comme son nom l'indique, le test ci-dessous n'est pas franchement probant (quoique réussir à faire aller plus vite du C# sous Mono en 2010 que du C++ sur une machine Linux, ça promet avec du .NET Core...) il met en lumière certains aspects qui sont souvent "oubliés" quand on compare les langages.
https://florent.clairambault.fr/stup...ce-comparison/
Ce qu'il ressort de ce test, c'est qu'avant tout, c'est que tous les contextes d'exécution ne se valent pas, et que certains langages à priori plus rapide que d'autres peuvent s'avérer plus lents.
Mais aussi qu'optimiser son code "pour le benchmark qui va bien" n'est pas forcément significatif, mais ça, j'en reparlerai plus tard.
Première chose qui ressort : C# est réellement portable, là où C++ ne l'est pas. En effet, qu'on soit sur un CPU 32 bits ou 64 bits, le type "long" sera le même en C# (64 bits) alors qu'en C++ il sera de la taille du registre CPU.
Donc autant ça permet au C++, de prime abord, pulvériser le C# qui s'emmerde à gérer du 64 bits sur un CPU 32 bits, autant cela fera planter le programme C++ lorsqu'on sera en exploitation et qu'on aura réellement besoin d'un long 64 bits.
Ceci implique qu'en temps de développement, C# sera de facto plus rapide, car sans connaissances complémentaires, sans se poser des questions métaphysiques de la plateforme finale (et ses éventuelles évolutions), C# produira un code se comportant pareil quel que soit le CPU ciblé, là où C++ nécessitera d'y réfléchir et adapter son code.
La seconde qui ressort : C# arrive à être plus rapide que C++, y compris sur une bête boucle d'incrémentation d'entier. Ceci est en grande partie dû à un avantage indéniable de C# (ou Java) par rapport au C/C++ : la compilation JIT permet d'adapter le code machine au contexte. Le runtime sera donc capable par exemple de transformer une fonction en inline en fonction du nombre d'appels à cette dernière. Idem pour les Array.Sort() par exemple : dynamiquement, en fonction du nombre d'élément, le runtime va changer d'algorithme de tri. Ceci va souvent ajouter un peu de lourdeur lorsque le programme fait peu de choses, mais drastiquement améliorer les performances lorsque le programme travaille intensivement.
La troisième, qu'on ne voit pas ici, c'est le temps perdu à gérer la mémoire : en C++, lorsque je crée un objet, je dois déclarer à la mimine exactement à quel moment réserver la mémoire pour son utilisation, et à quel moment la libérer.
Ainsi, je suis à tout moment tiraillé entre "m'étaler en mémoire, et faire du ménage quand j'ai plus rien à faire, au risque de bouffer 64 Go de RAM, ou au contraire consommer 64 Ko de mémoire, et passer 99% de mon temps à recycler les quelques octets de mémoire dont je n'ai plus besoin. Avec C#, non seulement on ne s'en soucie pas, mais surtout... le runtime va adapter le moment où on doit attribuer et libérer de la mémoire en fonction de la charge et des ressources à l'instant T... ce qu'un programme C++ ne saura pas faire (à moins de se lancer dans une usine à gaz maison).
Ainsi, autant pour moi il est très compliqué de dire quel langage est plus rapide ou plus consommateur en ressources que tel autre, autant il me semble assez surprenant de retrouver, j'insiste, C# aussi bas dans le classement... à moins que "ne pas se poser de question" se soit appliqué à l'ensemble du programme C# et qu'il en résulte un code abominable.
On ne jouit bien que de ce qu’on partage.
Oui, le contexte est fondamental. En COBOL, j'ai toujours écrabouillé tous les JAVAistes opposés sur le plan des performances... mais ça ne prouve pas pour autant la supériorité du COBOL sur JAVA dans tous les contextes. Ni même ma propre supériorité sur ces gens-là. Ca prouve juste que dans les contextes ou j'étais, moi+COBOL était un combo plus performant que autres+JAVA. Et ça vaut pour tous les langages.
D'ailleurs, tu parles de "code abominable" - à ma connaissance, le code le plus affreux n'est pas forcément le plus lent. C'est orthogonal. Un code très élégant peut être plus rapide - ou plus lent - suivant les manies de l'artiste. Et certaines horreurs cachent des optimisations bien pensées, tandis que d'autres...sont juste des horreurs.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Oui rien de bien nouveau : on sait bien qu'en choisissant le bench qui va bien on peut toujours trouver un cas particulier ou le pire langage arrivera a faire l'optimisation parfaite, mais en général dès que l'on va changer quelque détails, ça ne marche plus.
Certains langages ont bien plus de potentiel que d'autre pour permettre de meilleures optimisations de manière plus consistantes.
En C et C++, avec les types de base comme "long", c'est même pire que ça niveau portabilité : chaque compilateur est libre de faire ce qu'il veux (le standard impose juste des tailles minimales). Un même type peut avoir des tailles différentes en fonction de l'OS et de l'archi matérielle.
Heureusement depuis la fin du siècle précédent, le standard a introduit "stdint" qui permet d'utiliser des types de taille garantie, Donc cet argument particulier n'est plus vraiment recevable si on prend la peine d'utiliser des fonctions qui sont standard depuis plus de vingt ans.
Il reste cependant des centaines de comportement non définis par la spécification de C et C++ qui font que ces langages sont clairement moins bon en matières de portabilité que la plupart des langages modernes.
Déjà, comme expliqué ci dessus, "long" ne fait pas forcément la taille d'un registre, mais en plus, la taille d'un registre processeur n'est pas forcément la taille idéale pour faire des calculs.
Utiliser des types plus petits est plus rapide avec certaines instructions, peut permettre une meilleure auto-vectorisation, et peut réduire les "cache misses" en économisant la mémoire. En général, en C++ comme en C#, mieux vaut utiliser des types fixes mieux adaptés à la logique de l'application et laisser le compilateur décider de faire les optimisations qu'il faut. Même si on veut faire de l'optimisation manuelle, stdint est plus intéressant car il permet un meilleur contrôle.
Comme déjà dit, en effet dans certains cas bien choisis, une bonne optimisation particulière va permettre à un langage de s'en tirer particulièrement bien. Dans ton exemple le JIT est efficace, mais on pourrait aussi faire de l'optimisation dirigée par les profils pour bénéficier le ce genre d'optimisation en AOT.
Le Runtime n'est pas une solution magique qui va résoudre les problèmes. Ça en résout cretains, mais il a un cout moyen le plus souvent supérieur aux gains qu'il apporte en terme de performance. C'est un choix qu'il faut assumer.
Sauf que là on est en total hors sujet. Certes économiser sur le temps de développement est important dans énormément de situations, c'est même la principale raison d'exister des langages avec des performance moindres (même si là encore il y a beaucoup a discuter), mais là le sujet c'est les performance et l'impact sur la consommation en énergie.
Preuve s'il en falait que le Runtime n'est pas un faiseur de miracle absolu en matière d'optimisation du code. Le code du Benchmark Game est dispo et ouvert aux contributions, libre a toi de prouver que le C# peut faire mieux si tu le veux.
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