Navigation

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

Débats sur le développement - Le Best Of Discussion :

Programmation : une étude révèle les langages les plus voraces en énergie


Sujet :

Débats sur le développement - Le Best Of

  1. #121
    Membre émérite
    Bonjour.

    Citation Envoyé par Uther Voir le message
    ...
    Du coup je me demande pourquoi tous ces langages à GC n'utilisent pas un algorithme plus approprié.

    Parce que lancer le GC toutes les X minutes, c'est pas très compliqué comme algorithme. Depuis le temps, personne n'y a réfléchi ?

  2. #122
    Expert éminent
    Citation Envoyé par Uther Voir le message
    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.
    Citation Envoyé par moldavi Voir le message
    Du coup je me demande pourquoi tous ces langages à GC n'utilisent pas un algorithme plus approprié.
    Parce que lancer le GC toutes les X minutes, c'est pas très compliqué comme algorithme. Depuis le temps, personne n'y a réfléchi ?
    Je vais parler de .NET car Java je ne connais pas.
    Mais à priori, ils sont assez jumeaux maintenant en terme de fonctionnement.

    Le GC ne tourne pas à intervalle régulier. Il tourne "quand on en a besoin".
    Si j'écris un "hello world" qui n'alloue pour ainsi dire pas de mémoire, ne fait rien et ne libère jamais d'objet, alors le GC ne va JAMAIS tourner (sauf quand le programme va s'arrêter).

    En revanche, si j'ai un traitement qui crée des collections de milliers d'objets puis les libère sans arrêt dans une boucle, le GC va se lancer toutes les quelques secondes, voir plusieurs fois par secondes.

    Le déclenchement du GC, en .NET est piloté par au moins 3 éléments :
    - La pression mémoire "libérable" : tout au long du traitement, le GC calcule quelle taille il serait capable de libérer s'il se déclenchait. Quand ce nombre devient important par rapport à la taille mémoire disponible, alors le GC se déclenche.
    - La charge CPU : quand le programme est dans un "creux d'utilisation" (attente saisie utilisateur par exemple) alors le GC va se déclencher avec un seuil plus faible que si on est en plein calcul multi-threadé.
    - A la demande. Il est possible à tout moment, en tant que développeur, de piloter le déclenchement du GC. Ceci permet notamment de garantir qu'il va tourner "au moins quand le programme ne fait rien", et ainsi éviter de tourner par manque de mémoire ne plein milieu d'un traitement intensif.

    Cependant, comme il a été mentionné à de nombreuses reprises, ce benchmark est totalement foiré car il permet l'utilisation de librairies qui ne font pas partie du langage lui-même.
    Ainsi, si un programme en PHP ou même VBScript fait appel à une librairie codée en ASM par un fondu de l'optimisation, ces programme abominables en termes de performance vont paraître plus rapide, moins coûteux en mémoire que leur équivalent codé en C purement natif, ce qui est une hérésie.

    Bref, c'est un peu comme la Formule 1 : on ne teste pas la voiture, on ne teste pas le pilote, mais on teste un mélange des deux, et pas moyen de savoir ce qui fait qu'une écurie a gagné : meilleure voiture ou meilleur pilote ?
    On ne jouit bien que de ce qu’on partage.

  3. #123
    Expert éminent sénior
    Citation Envoyé par moldavi Voir le message
    Du coup je me demande pourquoi tous ces langages à GC n'utilisent pas un algorithme plus approprié.

    Parce que lancer le GC toutes les X minutes, c'est pas très compliqué comme algorithme. Depuis le temps, personne n'y a réfléchi ?
    Parce ça n'est pas un problème si simple qu'il n'y parait. Le fait de libérer la mémoire a intervalle régulier, c'est bien sur la première chose qui a été essayée, et si les algo de GC sont passé à des techniques plus complexes, c'est parce que ça n'est
    clairement pas suffisant pour être fiable et efficace.

    Ça fait des années que Java, .net, Go, ... améliorer leurs algorithmes de GC pour essayer le plus efficace possible dans le cas général. Mais il n'y a malheureusement pas un algorithme idéal qui répondrait parfaitement à toutes les situations. Il y a énormément de paramètres qui peuvent jouer. Certains programmes allouent la mémoire par petits bloc, d'autre par gros. Certains libèrent et ré-allouent beaucoup de mémoire, d'autres travaillent quasiment entièrement sur les même blocs, ...
    Les objectifs de performances peuvent aussi varier. Certain programmes ont intérêt a éviter les pause longues pour éviter que le comportement du programme paraisse saccadé. Ainsi il peut être intéressant de faire des pauses plus courtes, mais plus nombreuses, même les performance globales sont moins bonnes,

  4. #124
    Membre éclairé
    Surpris
    Pour C, conçu initialement pour écrire des systèmes d'exploitation en substitution de l'assembleur, les résultats sont conformes.

    En revanche, les performances du Pascal m'étonnent. Moins bonnes que Java qui travaille avec une machine virtuelle.
    En supposant l'usage de Free Pascal, il y a peut être un surcoût dû au multi-cible (limitation des optimisations de bas niveaux ?) mais quand même. Je me demande si le code pascal était de qualité.

    Auquel cas c'est plus un bench des langages les mieux maîtrisés et des meilleurs compilateurs (en laissant de coté les langages interprétés qui ne jouent pas dans la même cour car ils ne visent pas les mêmes objectifs) que celui d'un langage extrinsèque.
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  5. #125
    Membre éclairé
    Citation Envoyé par StringBuilder Voir le message
    ... ce benchmark est totalement foiré car il permet l'utilisation de librairies qui ne font pas partie du langage lui-même...
    Si je suis d'accord avec l'esprit de cette assertion, je le suis moins avec la forme. Ainsi le langage C ne sait pratiquement rien faire par lui-même. Même un simple printf dépend d'une librairie.

    Aussi je propose que le bench ne devrait porter que sur un source intégralement dans le langage en test, y compris les bibliothèques (exit les wrappers en tout genre). Par ailleurs, il faudrait garantir le "toutes choses étant égales par ailleurs" : machine (processeur, mémoire, type disque etc.) et OS notamment.

    Le problème serait alors que beaucoup de langages disparaîtraient de la liste. Par exemple, beaucoup de langages proposent des fonctions qui n'existent pas en natif mais proviennent de librairies écrites dans un autre langage, généralement le C (la plupart des grep par exemple).

    Mais cela ne paraît pas choquant.
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  6. #126
    Expert éminent sénior
    Citation Envoyé par Guesset Voir le message
    Même un simple printf dépend d'une librairie.
    pour faire un printf en langage C il faut appeler oui une bibliothèque contenant du code en assembleur.
    Et ce code en assembleur appelle les interruptions du BIOS le cas échéant.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  7. #127
    Expert éminent sénior
    Citation Envoyé par Guesset Voir le message
    En revanche, les performances du Pascal m'étonnent. Moins bonnes que Java qui travaille avec une machine virtuelle.
    En supposant l'usage de Free Pascal, il y a peut être un surcoût dû au multi-Bcible (limitation des optimisations de bas niveaux ?) mais quand même. Je me demande si le code pascal était de qualité.

    Auquel cas c'est plus un bench des langages les mieux maîtrisés et des meilleurs compilateurs (en laissant de coté les langages interprétés qui ne jouent pas dans la même cour car ils ne visent pas les mêmes objectifs) que celui d'un langage extrinsèque.
    Le benchmark game est en effet avant tout, comme son non l'indique, un jeu poussant les communauté autour de chaque langages a produire un code le mieux optimisé possible. Donc les langages qui ont une communauté nombreuse, partageuse et qui sait optimiser finissent par atteindre un niveau quasi optimal. Par contre, les langages moins courants ont, en effet, parfois des benchmarks pas forcément au niveau qu'ils méritent. Le Pascal étant passé de mode ces dernières années, je ne serais pas surpris que les contributeurs n'aient pas le même niveau de compétence en optimisation que ceux de langages plus en vue. Si vous vous en sentez capable de faire mieux en Pascal que le code actuel, vous pouvez contribuer, le principe du benchmark game est qu'il est ouvert au soumission extérieures.

    Citation Envoyé par Guesset Voir le message
    Aussi je propose que le bench ne devrait porter que sur un source intégralement dans le langage en test, y compris les bibliothèques
    Formulé comme cela, ça revient de facto a éliminer tous les langages sauf le C vu que pour accéder aux appel systèmes de manière stable, la plupart des OS ne fournissent que la libc ou une API maison sous forme de bibliothèque C.

  8. #128
    Membre éclairé
    Bonjour,

    Citation Envoyé par Uther Voir le message

    Formulé comme cela, ça revient de facto a éliminer tous les langages sauf le C vu que pour accéder aux appel systèmes de manière stable, la plupart des OS ne fournissent que la libc ou une API maison sous forme de bibliothèque C.
    Même si des langages autres que c permettent d'appeler directement des API système, celles-ci restent majoritairement écrites en c. C'est pourquoi j'avais isolé l'OS et hésité également à isoler les api graphiques liées à un pilote qui n'est pas strictement du système (exemple : l'accès à l'usage de cuda). Mais c'est un vrai problème car dans les API d'un système, il y a celles du noyau et d'autres qui sont en concurrence avec des librairies classiques.

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  9. #129
    Expert éminent sénior
    @Guesset je suis d'accord avec vos propos mais je ne saisis pas trop bien à quelle conclusion vous voulez arriver ?
    En développement informatique on peut tout faire ou presque.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  10. #130
    Membre éclairé
    Bonjour Mat,

    Citation Envoyé par Mat.M Voir le message
    @Guesset je suis d'accord avec vos propos mais je ne saisis pas trop bien à quelle conclusion vous voulez arriver ?
    En développement informatique on peut tout faire ou presque.
    Je n'ai pas d'objectif particulier car tous ces benchs me laissent perplexe (mais j'y jette un œil quand même ).

    Mettre dans un même comparatif, des compilateurs en natif avec des générateurs de code intermédiaires (pour machine virtuelle comme Java, ou restant à finaliser comme un PCode) et avec des langages interprétés ne me semble pas avoir beaucoup de sens. Ils n'ont pas les mêmes objectifs d'efficacité, de portabilité et de rapidité de mise au point. De même le degré d'abstraction d'un langage est important : comparer de l'assembleur (tiens il n'est pas dans le bench) avec du prolog serait au mieux risible.

    En résumé, il faudrait comparer des objets de même nature et de même objectif : par exemple comparer les langages procéduraux (impératifs) compilés entre eux (c, c++, rust, ada, pascal...). Et l'objectif ne me semble pas de désigner le meilleur langage mais de détecter les points forts et faibles relatifs afin de leur permettre d'améliorer leurs outils (compilateurs, dévermineurs, lieurs etc) plus que la nature même des langages (même si ce n'est pas à exclure).

    Ayant utilisé pas mal (en quantité sinon en qualité) de langages, je suis assez peu sensible aux chapelles. Le bon langage change selon l'objectif.

    C'était mon quart d'heure philosophique.

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  11. #131
    Expert éminent sénior
    bonsour Guesset merci pour la réponse.
    Quoiqu'il en soit je vais me mettre à Direct X version 11 et je ne pense pas programmer le SDK en COBOL ( mais plutôt en C++)
    Bonne soirée
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

###raw>template_hook.ano_emploi###