lasher a écrit 2738 commentaires

Dis, je ne te connais pas, je ne me souviens pas avoir vu ton pseudo souvent dans les journaux, mais une chose est sûre : si à chaque fois que tu te fais moinsser tu commences à attaquer l'intégralité du site, alors que les gens te répondent indépendamment de la note de tes posts, c'est pas étonnant que tu continues à t'enfoncer niveau notes de pertinence.

Personne n'aime un pleurnicheur.

Mais non tu ne passes pas pour un gros rat. :-) Et la question est légitime. Ceci étant dit, faire du dev noyau c'est évoluer dans un monde assez restraint, mais généralement demandé. Donc à moins d'être vraiment « junior » (i.e., aucune expérience dans le domaine) le salaire devrait être décent comparé aux salaires « locaux » (pBpG a raison de faire remarquer que les salaires d'un pays à l'autre varient pas mal).

Dans ce cas, si tu sais à l'avance que tu veux voir un programme précis, tu peux utiliser des solutions « locales » comme un appareil pour faire du time-shifting, non ? Comme ça, tu évites de consommer de la bande-passante « inutile » alors que tu es une « exception » et que les autres sont là à l'heure.

Donc l'idée serait : « diffusion massive » et principalement unidirectionnelle (avec un coût global « réduit »), et si besoin particulier, utilisation d'outils locaux (« magnétoscopes », outils de time-shifting, etc.), ou bien utilisation point-à-point (et bi-directionnelle) pour voir un programme à une heure différente de la diffusion massive.

Je pense que ces idées sont une bonne base, et à moins de voir des défauts fondamentaux, elles devraient être implémentées en premier avant de vouloir en rajouter une couche. :-)

Le support ODF de MS-Office est franchement pas top. On pourrait bien sûr émettre une théorie complotiste pour dire que MS sabote volontairement le développement de la fonctionnalité. D'une part, je ne pense pas qu'un développeur MS serait franchement super jouasse de devoir volontairement saboter la fonctionnalité. D'autre part, il me semble plus réaliste de penser que MS a peut-être simplement et pragmatiquement affecté seulement un ou deux développeurs (ou cinq hein, là n'est pas la question) à la tâche, et comme ODF n'est pas simple à supporter (mais alors, pas du tout), et comme la part des clients qui réclament le support ODF est faible (mis à part le gouvernement UK si j'ai bien compris), alors MS ne fait pas beaucoup d'efforts et n'y affecte pas plus de personnel (y compris testeurs, contrôle qualité, etc.).

Bon, puisqu'on repart sur un trollàlacon : en préambule, si je dois utiliser une suite bureautique, j'utilise LibreOffice et quasi-jamais Windows/MS-Office. Je ne suis pas un vendu à la cause du grand Satan, et j'ai pas de parts chez Microsoft.

Ceci étant dit : combien de softs permettent d'importer du format OpenDocuments avec un rendu proche (je demande même pas parfait hein, mais suffisamment proche) de ce que produisent OOo/LO ? La documentation du format pour générer des documents Writer, etc., est-elle tellement plus simple que celle d'OOXML ?

Bon, question conne, mais, lorsque tu utilises tout le temps le même paramètre, est-ce qu'il n'est pas d'usage d'utiliser des fermetures dans ce cas (ou des foncteurs, ou…)? Genre, en Perl:

my %context = ( prop1 => val1, prop2 => val2, ... );
# on fait des trucs avec le contexte, 
# bla
# bla
# bla
# Puis :

my $applyCtxt = sub { 
    my ($funcref, $fieldname) = @_;
    &$funcref($context{$fieldname});
};

#exemple à la con qui ne sert vraiment à rien
for my $fieldname (sort keys %context)
    for my $func (\&readStuff, \&writeStuff, \&squareMe, \&doTheBoogieWoogie) {
        &$applyContxt($func, $fieldname);
    }
}

… Chépasichuiclair. J'ai pas relu le journal, donc j'ai peut-être raté une partie du contexte, mais quand je relis ton résumé de ce que tu cherchais à faire, il me semble que ton contexte est « global », et peut donc être « raccourci » par l'utilisation de fermetures. Évidemment, dans le contexte de Perl, il n'y a pas la possibilité de proposer un opérateur infixe qui ferait le pipelining des fonctions comme en OCaml, mais je n'ai pas l'impression que ce soit ce que tu cherchais à faire de toute manière.

Qu'est-ce que j'ai raté ?

Il s'agit plus d'une absence de volonté politique. Aux USA, tu as globalement AMTRAK et SEPTA comme compagnies de chemin de fer, par exemple. AMTRAK propose l'équivalent de trains Corail en termes de vitesse (mais la 2nde classe est bien plus confortable que l'équivalent Corail, avec sièges larges, des prises électriques, etc. — ceci dit, ils ont p'tet modernisé les Corail, j'ai pas repris ces trains depuis un bail). Par contre, le prix est extrêmement élevé : ~100$ pour un A/R entre Wilmington (Delaware) et New York City, pour une durée de 2h (qui aurait pu être réduite à 45 minutes avec un train de type TGV ou Shinkansen). SEPTA est beaucoup moins cher, mais s'arrête partout. Un ami prenait un train SEPTA pour aller dans le New Jersey, car c'était moins cher. En voiture, ça prenait ~2h/2h30. En train, il mettait facilement 5h ou 6h. Un peu comme lorsqu'on veut aller (par exemple) de Compiègne à Amiens en train : le plus rapide est de prendre un Corail pour Paris (~40 minutes), puis un TGV — mais c'est cher. Ou alors, on prend des Corail, l'un pour aller à Noyon, puis l'autre pour Amiens. C'est beaucoup moins cher, mais prend facilement 5h (dans des trains franchement pas confortables).

Les compagnies de bus se débrouillent un peu mieux. Grey Hound et Megabus proposent des trajets Wilmington-New York City pour ~10-50 dollars (A/R). Mais si on regarde les « petits » trajets (par exemple pour aller de Wilmington vers Newark, les deux dans le Delaware), on se retrouve avec certes un prix ridiculement bas (1,5$), mais un temps de trajet de 1h30 alors que Wilmington-Newark prend 20 minutes en voiture. Sans compter le fait que les bus « locaux » ont tendance à être très imparfaits en termes de ponctualité.

Bref : il est parfaitement possible d'avoir des transports en commun potables. Il suffit de monter les impôts locaux, et évidemment c'est pour ça que personne n'acceptera.

Et donc, un juge qui signe un mandat ça empêche une perquise de déraper et le coup de partir ?

Oui. Je connais quelques personnes bossant à des niveaux suffisamment hauts (assistant du procureur, etc.), et tu n'as pas idée du nombre de fois où un flic arrête quelqu'un, demande au juge/proc/blah, et on lui demande sur quelles preuves il s'appuie. Et là, c'est marrant, le flic murmure un truc du genre « il avait l'air louche » et le procureur lui dit de relâcher le suspect (qui peut être réellement coupable hein, juste que y'a aucune preuve réelle qu'il l'est).

Pour les perquisitions, c'est exactement le même raisonnement : « on a dit à un flic que » (pour reprendre l'expression de Zenitram), le flic veut vérifier (jusque là, why not). Sauf que s'il n'a pas d'autre preuve tangible (genre, des mains courantes, des arrestations dans le passé, des témoignages, etc.), je ne vois pas trop pourquoi un juge laisserait faire une perquisition. État de droit, tout ça.

Je suis d'accord sur l'aspect gouvernance : une démocratie « totale » n'est pas souhaitable dans un environnement qui est censé évoluer très vite, très souvent.

Ceci étant posé : il y a une différence entre dire « Daniel, le bug X et le bug Y sont bloquants. Tu ne les as toujours pas adressés. Il faut que live-build génère une image qui soit capable de gérer l'UEFI comme debian-cd le peut déjà. Si tu ne règle pas ce bug en priorité, nous allons devoir chercher à développer une solution alternative. » et « hey, on crée live-build-ng, et à partir de maintenant, live-build est déprécié ».

Dans le fil de discussion, les mainteneurs Debian disent qu'ils ont tenté de communiquer avec le mainteneur de live-build, mais on leur fait assez justement remarquer qu'ils n'ont pas essayé de communiquer directement sur la ML dédiée, ce qui aurait permis à d'autres gens de se dévouer par exemple (si le mainteneur principal était trop occupé). Je sais qu'il arrive souvent que je « saute » des emails (je veux y répondre, mais j'oublie, autre chose prend priorité, etc.). N'importe quel système de communication efficace va renvoyer au moins un mail/message/whatever pour me dire que si je ne me bouge pas, quelque chose de déplaisant va arriver.

C'est important pour deux raisons : (1) Comme ça l'aspect CYA (cover your ass) achevé, et (2) ça permet de documenter ce qui s'est passé, lorsque les gens commencent à gueuler.

Pour ce produit, je suis un utilisateur, pas un développeur.

J'ai bien compris. Mais à l'époque où Intel ne proposait que des RPM pour son compilo, et que notre système était debian/ubuntu, j'étais utilisateur aussi, et ça m'aurait fait une belle jambe de pester contre le format. Et dans ce cas précis, alien a fait le plus gros du boulot, mais il avait malgré tout fallu que je passe par des bidouilles infâmes pour modifier les noms de certains chemins.

Note : je n'ai pas demandé de bidouille pour que ça marche

J'ai bien compris, et ce n'était pas le propos. Cependant, j'avoue que lorsqu'alien fonctionne du premier coup pour faire la conversion deb ←→ RPM, certes c'est sans doute une étape de trop, mais c'est suffisamment facile/sans douleur pour que j'oublie que j'ai eu à passer par cette étape.

(peut-être, tu n'as pas testé avant de proposer, classique : "tu devrais, mais bon je n'ai pas testé donc en fait je n'en sais absolument rien et je te laisse perdre ton temps sur un piste sans issue", hum non merci)

Tu me prêtes des intentions que je n'ai absolument pas. Au pire, il faudrait lire ma question comme : « si passer par alien fonctionne du premier coup, ce serait p'tet cool de le signaler au dév, comme ça la prochaine fois il fait le paquet une fois, convertit le truc, et tout le monde est content ».

… Mais en fait, ma question initiale était juste ça : une question. J'ai bien compris ce que tu disais sur le fait que ça devrait s'installer direct. Bon. Maintenant, tu as l'air de dire que ça se réduit encore et toujours seulement à Linux/les environnements libres (pour les paquets binaires).

Tiens, un exemple récent qui se passe sous Windows. Je dois enseigner une UV pour la conception numérique en passant par du VHDL et un FPGA. Manque de bol, le soft Xilinx Web ISE qu'on utilisait jusqu'à présent est incompatible avece Windows 8 pour une raison que j'ignore. La solution, c'est de passer par leur nouveau soft, Vivado, qui tourne sur Windows 7 et plus, et ainsi que Linux apparemment (note que Web ISE fonctionne parfaitement sous Linux, même si l'interface est un peu moche). Ah mais voilà, Vivado ne reconnaît pas la carte FPGA qu'on utilise d'habitude avec les élèves (alors que Web ISE, si). Du coup, on va sans doute acheter une trentaine de cartes FPGA de nouvelle génération, parce qu'on peut pas vraiment demander aux élèves de changer d'OS ou même d'utiliser une machine virtuelle (parce qu'il faut une licence Windows idoine, et qu'ils ne l'ont p'tet pas).

Il y avait tout plein de PC sans OS à l'époque. Pourtant, quand tu voulais acheter un OS, l'assembleur du coin te parlait rarement de DR-DOS, car ils savaient que souvent les utilisateurs voulaient pouvoir utiliser Windows…

Donc si, il y avait bien un problème : même quand il y avait encore une vague concurrence entre MS et DR, avec un produit « supérieur » (Windows 3.x) que le concurrent en proposait pas mais qui normalement aurait pu être exécuté depuis son OS.

Acheter un PC nu avec un OS "OEM" fin des année 80 et début des 90, c'était super courant, bien plus que de nos jours.

Mouais, du coup ça force l'utilisateur à passer par des logiciels tiers pour modifier le comportement de l'interface graphique, c'est un peu dommage.

Tu les convainc comment les constructeurs d'installer ton os par defaut, et rien que celui la?

Pour reprendre ce que je dis ailleurs dans ce journal : en leur disant que les autres DOS disponibles ne sont pas capables de lancer Windows 3 (tout en ayant inséré dans le code un truc du genre if (strmcmp(getenv("OS"),"DR-DOS") == 0) critical_failure();).

En empêchant explicitement dans son code Windows 3.x de tourner sur DR-DOS, et ainsi en empêchant d'autres éditeurs de logiciels de systèmes d'exploitation de se faire un trou sur le marché ? Ça a été jugé, MS a été condamné, mais malheureusement, Digital Research avait déjà mis la clef sous la porte après de longues années de procédure.

Sérieusement, MS se comporte franchement comme un caïd de la pègrequi se mettrait à la retraite :

1. Écraser les autres, en usant de pratiques douteuses, voire mafieuses (par exemple, MS vs. DR DOS)
2. Une fois qu'on a pris un peu d'élan, l'utiliser pour pousser les autres sur le bas-côté, voire les écraser sur son passage.
3. Abuser tellement de sa position dominante, que, par jalousie, les autres membres des autres gangs s'allient contre toi (càd : IBM, Sun Microsystems, etc., vs Microsoft dans son procès pour abus de position dominante vers la fin des années 90 — voir aussi Microsoft, le hold-up planétaire.
4. Une fois clairement au-dessus des autres, et clairement hors de danger en général, assainir ses pratiques et devenir « gentil ». Par exemple, arrêter d'assimiler le logiciel libre à un cancer ou une utopie communiste, et même commencer à contribuer à une partie de l'éco-système libre (les contributions de MS sur .Net sont loin d'être négligeables).

Donc oui, de nos jours, Microsoft n'est clairement plus la brute épaisse qu'on a connue dans les années 80 et surtout 90. Mais ça ne veut pas dire qu'il faut oublier comment ils en sont arrivés à pouvoir se permettre de passer de « brute épaisse » à « gentille multinationale qui veut le bien de l'humanité pour un prix raisonable ».

Tiens, hier j'ai voulu tester bigbluebutton sur mon CentOS 7, la réponse est "crève":
"Install BigBlueButton your own server (Ubuntu 14.04 64-bit)."

Question très très con : est-ce qu'alien ne permettrait pas de « facilement » passer à du RPM avec les chemins correc' ? Je sais que ça ne marche pas toujours, mais j'avais eu affaire à quelques packages (dans l'autre sens : RPM -> deb), et ça s'était passé relativement sans douleur à l'époque.

Si tu diffuses un bout de code GPL dans ton code proprio, sans diffuser les sources, le tout sous licence proprio, tu te metsd hors-la-loi.

Bon, je ne suis pas juriste, tout ça.

Mais : est-ce qu'avec les nouvelles dispositions prévues par TISA/TIPP, on ne pourrait pas considérer la GPL (3) comme étant une clause abusive? Un peu comme lorsque ton contrat te dit (en France) que si tu quittes ta boite, tu ne pourras pas te mettre en compétition avec ton ancienne boite pendant 5 ans, mais le contrat ne précise pas la contrainte géographique (ce qui est une faute en France, et rend cette clause caduque : il faut des contraintes en temps et en espace).

Globalement, je crois que je suis d'accord avec le fond de ta pensée, mais c'est dommage que ce soit Renault qui la mette le mieux en valeur ailleurs dans la discussion (parce qu'il ne traite pas les autres de menteurs et implicitement d'abrutis).

pourquoi devrais-je les croire sur leur explication que je n'ai pas encore compris, si j'ai compris qu'elles se foutent déjà de ma gueule sur ce que je connais?

… et c'est comme ça que Galilée a été discrédité : il s'était planté sur ce qui causait les marées, alors franchement, pourquoi le croire sur le fait que la Terre tourne ?¹

Autant si tu parlais (en règle générale) d'un mec qui a constamment et objectivement tort sur presque tous les sujets que tu connais vraiment bien, alors je comprendrais; autant là, tu dis quand même que si un mec a tort (peut-être ment-il; mais peut-être fait-il simplement des extrapolations qu'il estime raisonnables à partir de ce qu'il sait) ne serait-ce qu'une fois, alors tu n'as plus de raison de l'écouter sur d'autres sujets. J'en déduis que tu ne parles qu'à ta femme et tes enfants, vu que franchement, je crois que tout le monde, même des gens raisonnables et éduqués, a tendance à extrapoler et, oui, parfois, mélanger (souvent inconsciemment) un peu son idéologie avec le réel.

Hans Reiser ! C'était 'achement bien ReiserFS. C'est dommage qu'il n'y ait plus d'update.

… Ben quoi, j'ai dit une connerie ?

Je suis globalement d'accord avec ce que tu dis, mais :

Avec 100% des gens inscrits aux mutuelles tu vas même faire baisser l'impact des profiteurs sur le prix des mutuelles (bon malheureusement ça servira sûrement à les engraisser et pas à baisser leurs prix).

… Ou bien, tu as un risque d'effet « monopole » (pas un vrai, vu qu'il y aura plusieurs mutuelles), dans le sens où à partir du moment où c'est obligatoire, y'a intérêt à ce que les boites qui devront passer un contrat cherchent réellement à obtenir le meilleur prix pour un niveau de service acceptable. Sinon, tu risques d'avoir un truc peu onéreux mais qui ne rembourse pas grand chose imposé aux employés. Donc il me semble qu'à moins d'être une grande entreprise/industrie, le pouvoir de négociation sera assez faible. Il faudrait que les patrons de TPE se mettent ensemble pour négocier les contrats de mutuelles pour réellement obtenir des tarifs intéressants auprès de mutuelles, tout en obtenant des services corrects.

Cependant, ne peut-on pas se demander si la charité exercée par le peuple lui-même ne serait-elle pas meilleure, voire peut-être plus efficace ? Je pose sincèrement la question.

Tu as la réponse aux USA, où les coupes sur les impôts des particuliers ont été légion depuis Bush Jr: certes, le PIB des USA est élevé, mais ils ont l'un des plus grands déséquilibres en termes de redistribution des richesses, avec une partie importante des citoyens US qui, même en cumulant 2 jobs (payé le SMIC local, soit ~8$/heure), n'arrivent pas à joindre les deux bouts. À chaque fois qu'on parle de réformer les impôts et qu'on propose de rajouter une tranche pour les plus aisés aux US, on nous rabat les oreilles avec du « nan mais les millionnaires et milliardaires sont les créateurs d'emplois ! » (c'est globalement faux), ou bien « c'est une obligation morale de faire la charité quand on est riche, il faut leur faire confiance ». La vérité, c'est que si certains aisés/riches font bien la charité, c'est (1) proportionnellement bien moins que des gens de la classe pauvre ou moyenne en général, et (2) pas suffisant sans l'aide de l'état US qui a 12000 programmes pour les pauvres (medicare, medicaid, « tickets resto », etc.).

Il faut aussi rajouter l'effet psychologique du « moi j'y suis arrivé, si les autres n'y arrivent pas, c'est qu'ils ne font pas assez d'efforts. » C'est évidemment complètement débile, et faux (j'ai la flemme d'expliquer pourquoi en détails, mais entre autres, beaucoup de millionnaires et milliardaires ont construit leur fortune par dessus un héritage lui-même assez élevé, des connexions avec les gens du bon milieu, etc.).

TL;DR: non, laisse les gens faire la charité n'aidera pas, car l'aide apportée n'est pas suffisante en proportion du nombre de gens qui en ont besoin.

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.

Je ne connais pas bien la techno derrière DCM sur Haswell (je veux dire, au niveau micro-électronique), mais le papier que j'ai donné en référence confirme plus ou moins ce que tu dis à propos de DVFS: c'est tros « gros grain » pour être utile dans des cas de calcul intensif avec des changements de « phase » trop rapprochés. Par exemple, si des threads attendent tous à une barrière, utiliser DVFS et baisser la fréquence/la tension risquent de ne rien apporter, vu que le temps passé à basculer d'une fréquence à l'autre est grosso-modo celui passé dans la barrière. Par contre, en passant par DCM, vu qu'on n'a qu'à attendre, c'est plus ou moins logique de faire une boucle d'attente active qui suspend l'horloge.

J'ai parlé avec les auteurs du papier en question, et ils ont des applications même pour les comms entre nœuds de calcul, genre des nœuds connectés avec de l'Infiniband (et donc de courtes latences).

Intel a vraiment fait beaucoup de progrès niveau gestion d'énergie et puissance. Pas seulement avec les P-state, C-state, etc., mais aussi avec les « boutons » qu'on peut utiliser en tant que root (ou avec un driver). C'est juste qu'ils doivent composer avec des aspects sécurité difficiles à gérer (genre timing attacks, tout ça). Leurs cœurs sont de plus en plus indépendants en termes de gestion de fréquence, tension, et gestion de l'horloge. Ils ont aussi développé tout un tas de trucs pour permettre de n'activer que les fils qui sont intéressants même pour des opérations flottantes (genre instruction FMA qui n'active que 16, 32, ou 64 fils et les composants associés en fonction de la précision voulue pour l'opération). Je ne sais pas s'ils l'ont déjà intégrée pour les instructions SSE/AVX/blah, mais en tout cas ils avaient un papier en 2012 pour expliquer le principe, avec les chiffres concernant la réduction en conso d'énergie statique et dynamique.

Si tu lis le manuel d'Intel, section 14.5.1, ils décrivent les instructions pour utiliser la DCM. D'après cette thèse on a une notion de modulation de cycle d'horloge depuis au moins le Pentium 4, mais l'utilisation des « C-States » est récente.

DCM est utilisable sur les derniers x86 d'Intel (Haswell & co). Il faut écrire un driver parce qu'au moins pour le moment, l'instruction nécessite un accès ring0. Si tu coupes tout (power gating), tu perds l'état du processeur. Avec DCM, tu suspends le proc, sans pour autant perdre les données du L1. C'est quand même 'achement plus pratique.

Ce papier explique comment ils utilisent DCM pour les synchros entre thread et certaines opérations à latence longue mais pas forcément « inconnue »:

Wei Wang, Allan Porterfield, John Cavazos, Sridutt Bhalachandra, "Using Per-Loop CPU Clock Modulation for Energy Efficiency in OpenMP Applications,” at 2015 International Conference on Parallel Processing (ICPP 2015), Beijing, China, 2015.

Les slides de sa présentation sont aussi dispo

Il y a aussi des chercheurs qui montrent qu'en exploitant le DCM (Duty-Cycle Modulation) on peut « suspendre » l'horloge pour quelques cycles lorsque tu as des latences longues (accès mémoire, E/S), et effectivement réduire la conso d'énergie des cœurs sans pour autant à avoir à passer par du DVFS (dynamic voltage and frequency scaling), qui prend trop de temps si la latence est longue, mais pas trop longue.