(les processeurs modernes supportent des "paliers" de puissance), de quel types de matériels parlent-ils ?
Les processeurs x86 au moins, ça me parait assez évident qu'il possèdent ce genre de fonction
- Est-il possible de généraliser ceci à l'ensemble du sytème GNU/Linux, d'avoir un aperçu de la puissance nécessaire et de régler la puissance de la machine en conséquence ?
Oui et non.
Réussir à généraliser implique de disposer d'une couche de réflexivité assez poussé sur le code.
On fait on a trois voies qu'on peut mixer :
1) On fait des statistiques sur le code, et on règle en conséquence. Sur un lecteur vidéo, en très gros c'est possible parce qu'un flux à décoder tourne toujours autour du même ordre de grandeur.
Dès que tu tombes sur un programmes qui joue aux montagnes russes en terme de consommation avec en plus la problématique de ses autres petis copains qui tournent à côté et qui ont faim eux aussi, là ça risque de devenir ingérable.
2) Le compilateur évalue à la compilation la comlpexité du code. *
En pratique c'est quasiment impossible à faire sur la plupart des langages et certainement en C, à moins qu'une équipe de fou furieux y passe 10 ans.
C'est possible de le faire que sur un langage assez minimaliste qui donc te permet de faire une analyse de flot assez profonde (ie. analyse du graphe du code en analysant toutes les branches possibles du code avec à chaque embranchement le devenir possible de chaque variables, des supputations sur le résultat d'un switch, etc...).
Bref avec 4 Go de consommation mémoire pour compiler 2000 lignes de code (la combinatoire est exponentielle), ça monte très vite..
Avec un moteur pareil, tu peux embarquer dans le code une estimation, un ordre de grandeur de la complexité de ton algo. Tiens celui-ci est un o(n2), celui-ci un o(e^n) (aïe..).
Là le sheduleur calcul rapidement (on lui donne n) et affecte la consommation en conséquence
3) au début t'es à 50 % de la fréquence. Le décodeur vidéo te dit "il me faut assez de ressource pour avoir fini de décoder mon image dans 50 ms". Tu donne la main au bout de code en question. 30 ms passe pas fini. Tu augmente la fréquence de 25 %.
On est à 42 ms. toujours pas fini.
Tu montes à 100 % de puissance
48 ms, il a fini
C'est bon tu redescend à 50 % de fréquence.
C'est une pure supposition hein.
- Si cela est possible est-ce réellement économe en énergie et dans quelle proportion ?
Dans la même proportion de gain de consommation en fonction de la fréquence de ton processeur, de sa charge, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: API d'annonce de contrainte
Posté par Ontologia (site web personnel) . En réponse à la dépêche Nouvelle version 2.6.19 du noyau Linux. Évalué à 6.
Les processeurs x86 au moins, ça me parait assez évident qu'il possèdent ce genre de fonction
- Est-il possible de généraliser ceci à l'ensemble du sytème GNU/Linux, d'avoir un aperçu de la puissance nécessaire et de régler la puissance de la machine en conséquence ?
Oui et non.
Réussir à généraliser implique de disposer d'une couche de réflexivité assez poussé sur le code.
On fait on a trois voies qu'on peut mixer :
1) On fait des statistiques sur le code, et on règle en conséquence. Sur un lecteur vidéo, en très gros c'est possible parce qu'un flux à décoder tourne toujours autour du même ordre de grandeur.
Dès que tu tombes sur un programmes qui joue aux montagnes russes en terme de consommation avec en plus la problématique de ses autres petis copains qui tournent à côté et qui ont faim eux aussi, là ça risque de devenir ingérable.
2) Le compilateur évalue à la compilation la comlpexité du code. *
En pratique c'est quasiment impossible à faire sur la plupart des langages et certainement en C, à moins qu'une équipe de fou furieux y passe 10 ans.
C'est possible de le faire que sur un langage assez minimaliste qui donc te permet de faire une analyse de flot assez profonde (ie. analyse du graphe du code en analysant toutes les branches possibles du code avec à chaque embranchement le devenir possible de chaque variables, des supputations sur le résultat d'un switch, etc...).
Bref avec 4 Go de consommation mémoire pour compiler 2000 lignes de code (la combinatoire est exponentielle), ça monte très vite..
Avec un moteur pareil, tu peux embarquer dans le code une estimation, un ordre de grandeur de la complexité de ton algo. Tiens celui-ci est un o(n2), celui-ci un o(e^n) (aïe..).
Là le sheduleur calcul rapidement (on lui donne n) et affecte la consommation en conséquence
3) au début t'es à 50 % de la fréquence. Le décodeur vidéo te dit "il me faut assez de ressource pour avoir fini de décoder mon image dans 50 ms". Tu donne la main au bout de code en question. 30 ms passe pas fini. Tu augmente la fréquence de 25 %.
On est à 42 ms. toujours pas fini.
Tu montes à 100 % de puissance
48 ms, il a fini
C'est bon tu redescend à 50 % de fréquence.
C'est une pure supposition hein.
- Si cela est possible est-ce réellement économe en énergie et dans quelle proportion ?
Dans la même proportion de gain de consommation en fonction de la fréquence de ton processeur, de sa charge, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker