Pour couper une horloge, il suffit de mettre une porte devant.
Nous sommes bien d'accord. :-)
Pour en changer la fréquence, il faut modifier la pll qui peut mettre un certain temps à se stabiliser. Le pire est de couper la pll pour la rallumer (~100ms de mémoire).
Oui.
Concernant la tension, tu peux couper des power domaine entier.
Oui, aussi. Jusqu'à il y a ~1 an, mon labo bossait avec une équipe d'Intel qui fait de la recherche pour les processeurs de machines « exascale » (voir ici par exemple : http://extremescale.cs.illinois.edu/thrifty/PUBLICATIONS/iacoma-papers/hpca13_1.pdf). L'un des principes de base de la machine est que le processeur sera « sur-provisionné ». En d'autres termes : « les calculs seront gratuits comparés à l'énergie dépensée en transferts de données ». Un block de 8+1 cœurs (1 cœur de contrôle, et 8 cœurs de calcul) aurait plusieurs domaines de puissance, où on pourrait commuter plus ou moins facilement. Le tout repose sur des technos de tension au seuil (et à l'époque, une partie de la recherche portait sur les « soft errors » qui en résulteraient).
Souvent les points de fonctionnement à 100, 50 ou 25 % de la clock max ne concernait que le cpu et non les caches (omap3).
Dans la puce « théorique » Runnemede (maintenant c'est « Traleika Glacier » parce que le projet est passé de DARPA à DOE), le principe est que tu pouvais couper les unités fonctionnelles individuelles, faire du clock gating sur un cœur de calcul (y compris son scratchpad), faire du power gating (avec les latences que ça engendre quand tu le rallumes, ainsi que le besoin de sauver/restaurer les données) sur des cœurs, passer un bloc de cœurs en NTV, ou bien changer le domaine de puissance parmi un sous-ensemble de domaines prédéfinis par bloc de cœurs, voire faire du power gating sur des bancs mémoire du « L2 » (la mémoire locale au bloc de cœurs, un plus gros scratchpad en gros).
De plus, les ordres de grandeur qu'on nous avait donnés étaient : à fréquence/tension « nominale », la fuite/leakage est de ~20% (pour une fréquence de ~4 GHz). En NTV, on passe à ~50% (pour une fréquence de ~500 MHz).
À côté de ça, Intel bosse/bossait sur le réseau d'inter-connexion entre les blocs, avec la notion de « bandwidth tapering » (« bande passante dégressive »), où la combinaison HW/SW décideraient de quand désactiver les composants de l'interconnect, mais aussi de quel besoin de bande-passante serait satisfait (c-à-d que la BP théorique pourrait être énorme, mais pour des raisons d'enveloppe thermique/conso de puissance, on pourrait limiter la BP dans certains endroits du chip, entre différents blocs).
Ainsi, l'énergie nécessaires par instructions ne baissait pas comme le prévois la formule linéairement à la tension. Donc, les points de fonctionnement à 50 et 25%, si on tient compte de la puce entière ne consomme pas forcément moins. Il faut donc mieux jouer sur allumer et éteindre le chip (avec nettoyage du cache si nécessaire).
Toujours pour la puce Runnemede/TG :-), comme on avait 256 blocs de 8 cœurs de calcul chaque, c'est plus ou moins ce qu'on considérait : au minimum, on « suspend » (clock-gate) tout le bloc, voire on l'éteint (power gate). Possiblement, on éteint les cœurs, mais on laisse la mémoire de bloc allumée, comme ça les autres blocs qui ont besoin des données stockées dedans peuvent toujours piocher.
Mais l'idée était qu'effectivement avec les problèmes de « dark silicon » etc., la majorité du chip serait en mode basse tension/fréquence, avec juste quelques parties qui seraient en haute tension/fréquence (principalement pour faire tourner les parties du code qui sont peu parallèles). De même, l'idée était que le réseau d'interconnexion devrait être coupé le plus souvent possible. Il y aurait aussi une barrière matérielle par bloc, histoire d'automatiquement suspendre les cœurs qui l'utilisent, et automatiquement reprendre le calcul une fois que tous les cœurs ont atteint la barrière (chépassichuiclair).
Intel a fait des progrès, je n'en doute pas. Surtout qu'ils ont récupérer l'équipe low power de TI, après leur fermeture à Sophia Antipolis en 2009.
Comme je bossais avec Intel Research, je ne sais pas si ces ingés étaient là-bas ou bien en prod. :-)
J'avais entendu parler aussi des gains de puissance, si on jouait sur le rapport entre la vitesse de la DRAM et la vitesse du cpu. En général, ils sont au max tous les 2, à 100% de l'horloge. Mais les taches peuvent être cpu bound ou memory bound. Cela permet de baisser une fréquence par rapport à l'autre sans perte de performance ou presque, le papier citait 20% de gain d'énergie sur le mode 100%.
Oui, il y a pas mal de travail autour du DVFS avec une analyse des « phases » d'un programme : si tu peux déterminer (par profilage ou autre méthode) qu'une phase dans un programme est memory-bound, tu peux passer en tension/fréquence plus basse sans perte de perf, vu que le goulot d'étranglement est la mémoire ou les I/O. Le problème survient lorsque les phases sont entrelacées et trop courtes pour tenir les 100ms dont tu parlais. C'est en particulier problématique avec les codes dont les motifs d'accès aux données sont irréguliers et difficilement prévisibles (typiquement, les codes itératifs à base d'équations différentielles partielles et codes de maillage adaptatif, où tu te retrouves à faire du a[ b[i] ] sans savoir si tu as un stride/pas d'avancement régulier dans le tableau). Du coup, p'tet que tu vas avoir une super localité et tes caches seront super utiles, ou bien p'tet que tu vas avoir une localité de merde, et tu vas passer ton temps à résoudre des cache misses.
[^] # Re: Remarque à la c...
Posté par lasher . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 3.
Nous sommes bien d'accord. :-)
Oui.
Oui, aussi. Jusqu'à il y a ~1 an, mon labo bossait avec une équipe d'Intel qui fait de la recherche pour les processeurs de machines « exascale » (voir ici par exemple : http://extremescale.cs.illinois.edu/thrifty/PUBLICATIONS/iacoma-papers/hpca13_1.pdf). L'un des principes de base de la machine est que le processeur sera « sur-provisionné ». En d'autres termes : « les calculs seront gratuits comparés à l'énergie dépensée en transferts de données ». Un block de 8+1 cœurs (1 cœur de contrôle, et 8 cœurs de calcul) aurait plusieurs domaines de puissance, où on pourrait commuter plus ou moins facilement. Le tout repose sur des technos de tension au seuil (et à l'époque, une partie de la recherche portait sur les « soft errors » qui en résulteraient).
Dans la puce « théorique » Runnemede (maintenant c'est « Traleika Glacier » parce que le projet est passé de DARPA à DOE), le principe est que tu pouvais couper les unités fonctionnelles individuelles, faire du clock gating sur un cœur de calcul (y compris son scratchpad), faire du power gating (avec les latences que ça engendre quand tu le rallumes, ainsi que le besoin de sauver/restaurer les données) sur des cœurs, passer un bloc de cœurs en NTV, ou bien changer le domaine de puissance parmi un sous-ensemble de domaines prédéfinis par bloc de cœurs, voire faire du power gating sur des bancs mémoire du « L2 » (la mémoire locale au bloc de cœurs, un plus gros scratchpad en gros).
De plus, les ordres de grandeur qu'on nous avait donnés étaient : à fréquence/tension « nominale », la fuite/leakage est de ~20% (pour une fréquence de ~4 GHz). En NTV, on passe à ~50% (pour une fréquence de ~500 MHz).
À côté de ça, Intel bosse/bossait sur le réseau d'inter-connexion entre les blocs, avec la notion de « bandwidth tapering » (« bande passante dégressive »), où la combinaison HW/SW décideraient de quand désactiver les composants de l'interconnect, mais aussi de quel besoin de bande-passante serait satisfait (c-à-d que la BP théorique pourrait être énorme, mais pour des raisons d'enveloppe thermique/conso de puissance, on pourrait limiter la BP dans certains endroits du chip, entre différents blocs).
Toujours pour la puce Runnemede/TG :-), comme on avait 256 blocs de 8 cœurs de calcul chaque, c'est plus ou moins ce qu'on considérait : au minimum, on « suspend » (clock-gate) tout le bloc, voire on l'éteint (power gate). Possiblement, on éteint les cœurs, mais on laisse la mémoire de bloc allumée, comme ça les autres blocs qui ont besoin des données stockées dedans peuvent toujours piocher.
Mais l'idée était qu'effectivement avec les problèmes de « dark silicon » etc., la majorité du chip serait en mode basse tension/fréquence, avec juste quelques parties qui seraient en haute tension/fréquence (principalement pour faire tourner les parties du code qui sont peu parallèles). De même, l'idée était que le réseau d'interconnexion devrait être coupé le plus souvent possible. Il y aurait aussi une barrière matérielle par bloc, histoire d'automatiquement suspendre les cœurs qui l'utilisent, et automatiquement reprendre le calcul une fois que tous les cœurs ont atteint la barrière (chépassichuiclair).
Comme je bossais avec Intel Research, je ne sais pas si ces ingés étaient là-bas ou bien en prod. :-)
Oui, il y a pas mal de travail autour du DVFS avec une analyse des « phases » d'un programme : si tu peux déterminer (par profilage ou autre méthode) qu'une phase dans un programme est memory-bound, tu peux passer en tension/fréquence plus basse sans perte de perf, vu que le goulot d'étranglement est la mémoire ou les I/O. Le problème survient lorsque les phases sont entrelacées et trop courtes pour tenir les 100ms dont tu parlais. C'est en particulier problématique avec les codes dont les motifs d'accès aux données sont irréguliers et difficilement prévisibles (typiquement, les codes itératifs à base d'équations différentielles partielles et codes de maillage adaptatif, où tu te retrouves à faire du
a[ b[i] ]sans savoir si tu as un stride/pas d'avancement régulier dans le tableau). Du coup, p'tet que tu vas avoir une super localité et tes caches seront super utiles, ou bien p'tet que tu vas avoir une localité de merde, et tu vas passer ton temps à résoudre des cache misses.