Je ne comprends pas bien cette phrase, si le but est de baisser la consommation de la puce, baisser uniquement la fréquence fait augmenter la consommation de la puce (à cause des fuites statiques, la conso dynamique étant proportionnel à la fréquence et la durée d'une tache augmente avec la baisse de la fréquence).
Alors d'une, je ne suis pas un expert, loin de la (d'ailleurs si tu regardes mes commentaires sur LinuxFR, j'ai plus tendance à parler compilos et programmation parallèle avec des bouts d'archi haut-niveau que de machins genre conception des processeurs ;-)). Donc je vais très probablement dire des conneries, et ce sera uniquement ma faute, pas celle des ingénieurs avec qui je bosse et qui expliqueraient ça bien mieux que moi.
Tu as raison, en baissant la fréquence, on ne change rien a la conso statique. Cependant, l’idée est de pouvoir déterminer dynamiquement la charge des coeurs, et d'adapter en conséquence la fréquence du processeur. L'autre idée est que parfois, avec des puces qui contiendront des centaines, voire des milliers de coeurs, que la puce chauffera un peu trop. Plusieurs mécanismes devront du coup être disponibles sur architectures "manycore": la possibilité de couper un (ensemble de) CPU mais pas le cache/scratchpad ("clock gating"), couper totalement le cpu+mémoire locale ("power gating"), mais aussi simplement réduire la tension appliquée à un (ensemble de) coeur(s), ou simplement réduire la fréquence. La réduction de fréquence peut être utile si un coeur est peu chargé (mais a quand même du boulot ca faire qui arrive régulièrement) et attend que des requêtes vers la mémoire reviennent (le plus souvent des requêtes de type DMA, ou bien si tu as une techno de type SMT, un autre thread prend la main). La réduction de tension est bien entendu bien plus efficace, mais de ce que j'ai compris, c'est loin d’être instantané, i.e. pour la fréquence, on peut s'arranger en quelques cycles, alors que pour la tension, il faut attendre plusieurs centaines/milliers de cycles (encore une fois, j'ai peut-être mal compris ce que m'expliquaient les ingés).
Concernant la présentation que tu donnes en lien : j'avais vu d'autres présentations par la même personne je crois bien (il a des présentations intéressantes en règle générale). Perso je déteste Cuda. C'est un mal nécessaire en attendant que certains modèles de programmation arrivent à s'imposer (ou que les langages "standard" intègrent ce qu'il faut de constructions concurrentes/parallèles pour devenir utilisables en environnement multithreadé), mais l'idée de devoir gérer explicitement ca peu pres tout, j'ai vraiment horreur de ça. D'ailleurs, Nvidia le sait bien, et ils se sont alliés avec Cray et 2-3 autres boites pour proposer une sorte de "standard" concurrent à OpenCL, mais plutôt à base de pragmas que d'API (comme cela si tu as un compilo intelligent, il peut générer de l'OpenMP, du Cuda, ou d'autres trucs en fonction du type d'accélérateur dispo sur la machine).
Par contre, pour bosser sur un projet de système (système = cpu + softs bas-niveau + compilateurs haut niveau + demos sur applications réelles) "manycore" d'ici à l'horizon 2020, je pense que le monsieur ne se rend pas du tout compte de ce qui va être proposé et des contraintes dont il va falloir jouer pour arriver à produire des puces réellement dotées de centaines ou milliers de coeurs. Il veut absolument de la cohérence de cache par exemple, et tout laisse à penser que celle-ci ne sera au mieux que partielle -- i.e. soit on aura des scratchpads, soit des caches gérés par un logiciel (donc en gros il faudra un cache logiciel, ou bien l'application se chargera elle-même d'invalider les lignes), soit un hybride entre les deux. La cohérence totale est très probablement impossible pour un nombre de coeurs par puce élevé. J'aurais vraiment plein plein plein d'autres trucs à dire sur le sujet, mais j'ai déjà écrit un roman ... :-P
[^] # Re: Bof
Posté par lasher . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 5.
A propos de fréquence vs tension:
Alors d'une, je ne suis pas un expert, loin de la (d'ailleurs si tu regardes mes commentaires sur LinuxFR, j'ai plus tendance à parler compilos et programmation parallèle avec des bouts d'archi haut-niveau que de machins genre conception des processeurs ;-)). Donc je vais très probablement dire des conneries, et ce sera uniquement ma faute, pas celle des ingénieurs avec qui je bosse et qui expliqueraient ça bien mieux que moi.
Tu as raison, en baissant la fréquence, on ne change rien a la conso statique. Cependant, l’idée est de pouvoir déterminer dynamiquement la charge des coeurs, et d'adapter en conséquence la fréquence du processeur. L'autre idée est que parfois, avec des puces qui contiendront des centaines, voire des milliers de coeurs, que la puce chauffera un peu trop. Plusieurs mécanismes devront du coup être disponibles sur architectures "manycore": la possibilité de couper un (ensemble de) CPU mais pas le cache/scratchpad ("clock gating"), couper totalement le cpu+mémoire locale ("power gating"), mais aussi simplement réduire la tension appliquée à un (ensemble de) coeur(s), ou simplement réduire la fréquence. La réduction de fréquence peut être utile si un coeur est peu chargé (mais a quand même du boulot ca faire qui arrive régulièrement) et attend que des requêtes vers la mémoire reviennent (le plus souvent des requêtes de type DMA, ou bien si tu as une techno de type SMT, un autre thread prend la main). La réduction de tension est bien entendu bien plus efficace, mais de ce que j'ai compris, c'est loin d’être instantané, i.e. pour la fréquence, on peut s'arranger en quelques cycles, alors que pour la tension, il faut attendre plusieurs centaines/milliers de cycles (encore une fois, j'ai peut-être mal compris ce que m'expliquaient les ingés).
Concernant la présentation que tu donnes en lien : j'avais vu d'autres présentations par la même personne je crois bien (il a des présentations intéressantes en règle générale). Perso je déteste Cuda. C'est un mal nécessaire en attendant que certains modèles de programmation arrivent à s'imposer (ou que les langages "standard" intègrent ce qu'il faut de constructions concurrentes/parallèles pour devenir utilisables en environnement multithreadé), mais l'idée de devoir gérer explicitement ca peu pres tout, j'ai vraiment horreur de ça. D'ailleurs, Nvidia le sait bien, et ils se sont alliés avec Cray et 2-3 autres boites pour proposer une sorte de "standard" concurrent à OpenCL, mais plutôt à base de pragmas que d'API (comme cela si tu as un compilo intelligent, il peut générer de l'OpenMP, du Cuda, ou d'autres trucs en fonction du type d'accélérateur dispo sur la machine).
Par contre, pour bosser sur un projet de système (système = cpu + softs bas-niveau + compilateurs haut niveau + demos sur applications réelles) "manycore" d'ici à l'horizon 2020, je pense que le monsieur ne se rend pas du tout compte de ce qui va être proposé et des contraintes dont il va falloir jouer pour arriver à produire des puces réellement dotées de centaines ou milliers de coeurs. Il veut absolument de la cohérence de cache par exemple, et tout laisse à penser que celle-ci ne sera au mieux que partielle -- i.e. soit on aura des scratchpads, soit des caches gérés par un logiciel (donc en gros il faudra un cache logiciel, ou bien l'application se chargera elle-même d'invalider les lignes), soit un hybride entre les deux. La cohérence totale est très probablement impossible pour un nombre de coeurs par puce élevé. J'aurais vraiment plein plein plein d'autres trucs à dire sur le sujet, mais j'ai déjà écrit un roman ... :-P