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 expert
    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,