Je suis aussi d'accord, cependant si tu test du C++ en dédiant tout à des librairies C, est-ce qu'on peut appeler cela un test C++ ?
Si on veut parler d'écologie, il faut pas oublier d'inclure toute la chaîne de production, et aux nombres de personnes requises pour développer et maintenir par exemple une application en C par rapport à du C#/Java, il n'est pas certain d'être gagnant. On peut aussi mentionner le Cloud, faire payer à la consommation de CPU/RAM/Stockage ça a eu l'avantage de pousser en avant des solutions qui gaspillent moins.
Petite question : que fait typescript dans le lot ? Ce n'est pas censé être transpilé en Javascript avant d'être interprêté ?
On peut noter que Java est supérieur au C# en énergie/temps mais pas en espace. Ce qui en soit est logique. J'aurai eu quelque doute si Java était autant en avance que le C# sur les 3.
Le truc c'est qu'il faut garder une approche pragmatique. Il est clair que le Python ne doit pas être utilisé directement pour le calcul intensif. Mais il peut tout a fait servir pour piloter des composants qui sont écrits dans des langages de plus bas niveau.
C'est en grande partie vrai : la qualité de l'implémentation est essentielle et laisse planer un doute sur la pertinence de certaines mesures de cette étude. Mais il faut aussi reconnaître que le langage utilisé a quand même une influence sur les performances possibles. A un même niveau d'effort d'optimisation, un langage comme JavaScript ne pourra pas être, de manière consistante, aussi performant que des langages bas niveau comme C, C++ ou Rust. La nature de chaque langage fait que les possibilités d'optimisation offertes au compilateur sont différentes.
L'utilisation de la libc n'est pas une limitation technique de Rust. Il est tout a fait capable de se passer de la libc, c'est d'ailleurs ce qui se passe en mode nostd (indépendant de l'OS).
Le problème est juste que la plupart des OS (Windows, macOS, *BSD) n'ont pas une API noyau stable. Donc il faut passer par la libc (qui,elle est stable) pour ne pas risquer de voir son programme cassé par une upgrade du système. Comme tu le dis, avec Redox, un OS qui a une api système faite pour le Rust, le problème ne se pose pas.
De toute façon, en soi, utiliser la libc, n'a aucun impact technique sur le Rust.
Ces langages ont les mêmes contraintes que Rust vis a vis de l'OS. Je dirais même que si les liens entre le Rust et le C te posent problème, ils devraient être encore plus problématiques pour toi, vu que certains d'entre eux sont carrément transpilés en C.
Pas étonnant vu que dans la bibliothèque standard de Python, l'implémentation des regex est faite en C.
Si l'essentiel du travail de ton programme repose sur des expressions régulières, en effet, tu ne verras pas de différence. Mais si tu avais utilisé une bibliothèque de regex écrite en pur Python, je suis prêt a parier que les performances auraient été pire.
Pour ce qui est d'obtenir des performances similaires aux langages du top du tableau, c'est loin d'être suffisant. Le Python est bâti sur des choix techniques (typage dynamique, GC,...) qui font qu'il ne sera jamais optimal pour faire de la performance brute.
En effet c'est quelque chose d'important a considérer, mais ça serait a étudier de manière séparée : l'impact de la puissance de calcul employée et du travail d'une équipe de développeur sont deux choses différentes et qui peuvent être très variable d'un projet à l'autre.
On peut avoir, par exemple, un travail de simulation physique qui demandera peu de codage mais qui nécessitera énormément de temps de calcul machine, ou inversement une interface de saisie complexe qui ne demandera peu de temps processeur mais beaucoup de travail aux développeurs.
Tout comme le code compilé n'a pas forcément la même qualité d'optimisation en fonction du langage d'origine, le code transpilé est rarement similaire à du code idiomatique, notamment du point de vue performance
Il faut voir le python comme une glue, son but est de remplacer le bash. Pour ce qui est des algorithmes il s'appuie sur le C ou (certainement) le rust, le fortran ou ce qu'on veut (aller voir le code source numpy par exemple, je suis sur que c'est du C).
Pourquoi le langage C++ demeure incontournable 35 ans après sa sortie ?
Tout simplement parce que c'est le meilleur langage !
What else ?![]()
Je ne comprend pas la place du Pascal et du Fortran.
C'est, pour moi, des langages équivalent au C. Mais avec un domaine de prédilection différent (Le Fortran est très utilisé en calcul scientifique, par exemple).
Et je ne comprend pas également la place du Java, car quand on voit une pile d'appel en Java, on pend peur. De mon point de vue, il devrait être plus ou moins à la même place que le C#.
Surtout, rien que pour le C, entre une compilation avec Visual Studio, en cochant ou décochant certaines cases, on arrive à un binaire avec un rapport de 1 pour 2. Sans parler de ce qu'on obtient avec gcc, sous Linux ou sous Windows... et je ne parle pas de ma myriade d'options de compilations qui peuvent drastiquement changer les performances mais pas forcément être utilisées en production... genre le contrôle des dépassements lors des opérations... si on les désactive, évidement que ça va plus vite, mais à quel prix ?
Bref, résultats au mieux surprenants, probablement totalement décorrélés de la réalité.
Le 'C' avec ou sans ++, va rester le langage des langages en informatique (ca fait 30 ans qu'on le dit). Pour des questions d’universalité, de maitrise et enfin on en parle : de dépense énergétique !
En effet, c’est l’axe de recherche qui pourrait changer les rapports de force, notamment pour l’Europe qui pourrait revenir dans la course si nos industrie IT se mettaient à refaire tout ce qui est déjà fait , mais programmé comme il faut, avec donc une dépense énergétique 2 fois, 10 fois, 100 fois moindre dans certain cas.
S’il reste des programmeurs dans ce pays… foncez sur l’industrialisation optimisée!
Etant plutot a l'origine dev C/C++ je me renseigne sur RUST qui a l'air prometteur en terme de perfs... et quel ne fut pas ma grande deception !
Franchement je ne comprends pas la logique a part inventer un nouveau langage pour faire le contraire des autres.
Ou l'on apprend qu'une variable est par defaut CONSTANTE (alors que dans la plupart des programmes c'est l'inverse - plus de variables que de constantes).
Du coup on ajoute un mot clé MUT a chaque variable pour signaler qu'elle est mutable/variable (donc mot cle requis dans 95% des cas et non pas les 5%).
Et c'est comme ca tout le long sur quasiment chaque sujet, les tableaux memoires etc.
Hallucinant.
Pourquoi allez passer des heures sur un langage si c'est pour obtenir les memes perfs que quelque chose qui existe deja, qui n'impose pas de reinventer toute une gesticulation cerebrale pour reinventer des syntaxes toute plus ou moins barbares. Au final a part reinventer la roue carree, aucun gain.
Ou je comprends mieux maintenant le gars qui a inventé python.
Le gars se faisait chier, a decidé pour s'occuper d'inventer un langage.
""I didn't have a very rich social life at the time. So, instead of just watching TV, I would be coding, or sometimes doing both at the same time," he admits.'
https://www.techrepublic.com/article...2c8QQRks4f_cRg
un peu de hype et quelques articles et voila son truc lancé. Ca ne resoud rien qu'on ne savait pas resoudre auparavant (meme de maniere aussi elegante). Le plus important est SURTOUT de faire l'inverse de ce qu'ont fait les autres (meme si la logique au final ne ressemble a rien) sinon ca n'a aucun interet.
Pas sur que ce soit bien rentable de passer du temps sur un langage a la mode a la syntaxe douteuse. Bref des fois il faut savoir sauter des "technos/langages"
Pour avoir l'assurance de l'état de la mémoire. Puis au final, le borrow checker, une fois compris, c'est surtout quelque chose qui te permet de moins te prendre la tête justement.
Pour le surplus de syntaxe :
- ça dépend énormément de comment tu codes.
- ça permet d'avoir une variable mut avec la garanti d'un seul accès concurrent et plusieurs en lecture. Ce qui veut dire moins se prendre la tête pour la concurrence.
Bref l'avantage de Rust par rapport à C, c'est pas du tout les perfs. L'histoire d'être proche en perf, c'est juste le minimum pour être un concurrent de C
Ce qui me surprend, c'est qu'il n'y a pas eu de comparatif avec le langage D alors que ces gourous le vantent comme un moyen de conserver 90% de l'efficacité du C mais de n'en garder que 10% de sa complexité.
Si quelqu'un à la réponse, je suis preneur.
Je suis loin d'être une expert du Pascal, mais de ce que j'en connais, il est en effet techniquement a ranger dans les langage potentiellement proches du C. Je vois deux principales pistes d'explication a ces faibles performances.
Premièrement, je ne suis pas sur du niveau d'efficacité des compilateurs actuels. Les compilateurs C ont fait des progrès énormes et Pascal ayant moins le vent en poupe, je ne sais pas si les compilateurs Pascal ont suivi. Beaucoup de langages modernes (dont Rust) ont fait le choix de s'appuyer sur des backend de compilateur C (GCC, LLVM, ...) pour pouvoir bénéficier à moindre frais de leur capacité d'optimisation.
Une autre piste serait que la communauté n'a tout simplement pas soumis des programmes suffisamment optimisés au Bechmark game. Le Benchmarck game étant participatif les langages qui ont une communauté active est plus intéressée par les performances ont potentiellement de meilleurs résultats.
Les piles d'appel à rallonge ne sont pas une propriété intrinsèque de Java, mais de la façon dont il est souvent utilisé : pour faire des choses très simples en apparence, de manière terriblement compliquée en interne via des frameworks complexes tels que Spring.
Le benchmark game c'est l'inverse : aucune architecture, juste un algo qui nécessite beaucoup de puissance de calcul.
Pour l'universalité, en effet, le C est roi : tous les langages qui communiquent entre eux le font par son ABI. Par contre, pour le C++ ça n'est pas le cas.
Pour ce qui est de la maitrise, le C++ est en effet bon, mais il y a quand même d'autres langages dans le coup notamment Ada et Rust.
On a pas du voir les même références alors. JavaScript était peut-être lent au début des années 2000, mais ça fait un moment que les développeurs de navigateur se battent pour booster ses performances. Sans ça, il n'aurait probablement jamais quitté les navigateurs.
Au contraire, j'ai toujours entendu parler de Python et PHP comme des langages plutôt lents.
Je pense que tu n'as pas compris quel est le but de Rust. Le but premier n'est pas de simplifier l'écriture de n'importe quel code, mais de t'aider a produire du bon code.
Je ne sait pas si tu as travaillé avec longtemps, mais pour moi à l'usage le mot clé mut n'est clairement pas requis dans 95% des cas. A vue de nez je dirais qu'il est vraiment utile dans un peu moins de la moitié des cas. Le problème des variables mutable par défaut, c'est que l'on peut facilement oublier de déclarer comme 'const' une variable qui aurait du l'être alors que l'inverse est immédiatement détecté par un erreur de compilation. Et avoir les variables immuables a des avantages que tu ne vois pas forcément, au niveau des optimisations et des risques de mauvaise utilisation notamment.
Sauf que les gesticulations cérébrales que tu fais en Rust, tu doit faire les mêmes en C++ si tu veux faire un code de qualité. Rust t'interdit juste de faire du code potentiellement problématique.
C'est simplement que le langage D n'est pas dans le Benchmark Game.
@cecedu26 , pour moi l'objectif de Rust est de tirer le meilleur du C++, il ne s'agit pas simplement d'inverser des concepts mais de mettre à disposition des mécanismes qui par défaut rendront ton code plus safe, plus de débat NULL/nullptr, un type unique_ptr via une lib, du code avec des const T* partout etc
N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java
Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ?Contacter Gokan EKINCI
Bonjour.
Ce test donne l’impression que le langage interprété java est super performant.
Est-ce que ce test prend en compte l'utilisation cpu de la jvm ?
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
Ça fait plus de 20 ans que Java n'est plus interprété, du moins dans le sens traditionnel du terme. La Java Virtual Machine fait de la compilation à la volée.
Et oui, les mesures du benchmark game tiennent bien compte de la consommation intrinsèque liée à la JVM, pour la simple et bonne raison que ça n'est pas vraiment possible de la mesurer séparément du reste.
Bonjour.
Je ne comprends pas le, c'est possible, c'est pas vraiment possible ou c'est impossible.ça n'est pas vraiment possible
De mes connaissances, la JVM, c'est un process. Et un process, ça consomme du cpu.
Tu lances un programme Java, c'est aussi un process, qui consomme du cpu, ou alors il me manque une subtilité. Ce qui est possible.
Du coup, je m'attends, pour une comparaison honnête avec des langages sans JVM, à : consommation cpu (JVM) + consommation cpu (Java programme) vs consommation cpu (langage non interprété).
C'est le sens de ma question initiale.
Vu que Java, au niveau consommation mémoire soit dans le bas du tableau, confirmerait qu'ils en tiennent compte en effet. Je pose donc cette question parce que je ne suis pas en mesure de la vérifier.
Cordialement.
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
Je pense que la subtilité qui te manques, c'est que le programme Java n'est pas un processus séparé de sa JVM.
A chaque fois que l'on lance un programme en Java, on crée une nouvelle JVM avec son propre processus. La JVM charge le bytecode de son application java, et le compilera au fur et a mesure des besoins. Le code compilé est exécuté, dans le processus de la JVM. On ne peut pas donc mesurer séparément le programme Java et sa JVM vu qu'ils sont intimement liés. Quand on mesure les performance processeur et la consommation mémoire d'un programme Java, on analyse en fait le processus de sa JVM.
Le mieux que l'on puisse faire pour étudier l'impact spécifique de la VM sur les performance serait d'estimer le temps et la mémoire que consomme la JVM pour faire la compilation JIT. Il n'y a pas, à ma connaissance, d'outil pour mesurer ça et ça serait certainement imprécis et pas forcément significatif.
Bonjour.
Merci pour cette précision, je comprends mieux maintenant.
Du coup, si tu mesures les performances cpu pendant que le Garbage Collector fait son travail, les résultats vont être désastreux.
De ce que je vois avec les serveurs Java, le GC se manifeste à intervalle très régulier. Cela pourrait expliquer certains comportements lorsque tu fais du test de performance sur ces serveurs. Par exemple, la non linéarité des résultats.
Là j'ai un doute qui ne demande qu'à être comblé. D'accord c'est le même processus, mais sont-ils aussi le même thread ? Parce que l'on sait mesurer aussi les performances de chaque thread.
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
En effet c'est un problème connu des langages à GC, les performances sont moins prédictible vu que le GC impose des pauses de durée et de fréquence variable en fonction des stratégies adoptées. C'est en parti pour ça que ces langages sont a éviter pour les usages qui réclament une trop grande prédictibilité des performances. En tout cas ça ne serait pas honnête de vouloir sortir le coût du GC de l'analyse des performance d'un programme vu que la gestion mémoire fait partie de son bon fonctionnement.
Même dans les langages sans GC, la gestion de la mémoire a aussi des coûts (allocation, désallocation, comptage de référence,...), c'est juste qu'ils sont généralement plus prédictibles.
Bonne question. Je ne connais pas assez les détails spécifiques du fonctionnement des JVM pour répondre. Je ne crois pas que la spec de Java garantisse l'usage de thread particuliers pour les taches spécifique de la JVM.
Partager