sjub a écrit 42 commentaires

J'ai eu aussi cette incitation chez mon ancien employeur, avec une instance interne mais qui n'a pas le niveau des ChatGPT, Gemini et autres, donc pas très utile, augmentation de la productivité nulle.
Je pense que l'objectif est aussi l'affichage "Nous on utilise de l'IA".
Dans la même veine j'ai eu des entretiens avec des boîtes qui se vantent d'avoir plein de GPU pour faire leurs calculs et rapidement le retour c'était "on a beaucoup de GPU mais on commence à avoir des remarques d'en haut car ça a coûté cher mais les codes ne tournent pas encore dessus"…
Et je passe sur un autre ancien employeur qui affichait son gros calculateur GPU partout alors qu'en interne les codes ne tournaient pas non plus sur les GPU et certaines personnes en interne ne croyaient même pas aux GPU pour accélérer leurs codes (ça bricole à coup de pragmas OpenACC donc on ne peut pas espérer grand chose en terme de perforrmance) et il n'y avait aucune personne spécialisée dans le domaine pour porter efficacement les codes.

Beaucoup d'entreprises "encouragent" à utiliser l'IA, à partir d'un certain point ça devient absurde, par exemple chez AWS d'après cette news.
J'ai quelques retours de personnes dans des cas similaires, avec des managers (qui ne savent pas forcément justifier cela) qui veulent voir de la consommation de tokens…
Bref, la demande crée le besoin, il faut bien justifier de ses investissements dans l'IA ! Économiquement et écologiquement c'est quand même pas glop.

Merci à toi pour avoir relayé mes interrogations sur les NPU et à Andréas pour son retour d'expérience !
Je trouve dommage que les CPU embarquent tout ça, pour un usage limité et un matériel qui risque de devenir obsolète rapidement. Une solution NPU à brancher sur un port M2 façon NVMe serait nettement plus souple.
Personnellement je n'en ai pas l'utilité, pas de traitement d'images, de conversion, … beaucoup de transistors inutilisés !

Le fait qu'une carte GPU AMD ne suffise pas (lent et pas pertinent d'après l'auteur) pour l'utilisation la plus courante en local pose la question de l'utilité des NPU dans les processeurs actuels.
Est-ce que quelqu'un a un retour sur leur utilisation ?
En plus il faut de la mémoire pour faire tourner tout ça donc avec le prix de la mémoire en ce moment est-ce que ce ne sera pas plus utile de virer les NPU et mettre plus de coeurs ou d'unités GPU qui servent à plein d'autres choses (ou juste les virer et faire payer moins cher…) ?

Je viens de trouver un comparatif des consommations des box ici.
La consommation de base semble tourner autour de 8 à 10W pour les dernières box, même la Ultra.

De toute façon, la box sera toujours présente dans l'équation (sauf peut être à prendre une box basique comme la Pop ?), même s'il y a un RPI derrière, donc il faudrait voir si en ajoutant par exemple des disques sur la Delta on consomme toujours moins que le RPI avec disque + Delta.
Effectivement, les 27W de la Delta ça fait beaucoup pour une box avec juste un Snapdragon dedans et 1GB de RAM en comparaison avec les 2 à 9W du RPI 5.
Le lien ne donne malheureusement aucune idée sur le pourquoi de cette conso qui semble énorme, surtout quand rien n'est connecté dessus (le WIFI ???).
Si on veut vraiment réduire peut être que la solution est une petite box qui consommerait moins de 15W avec un RPI derrière.

C'est intéressant !
Ce qu'il faudrait voir aussi c'est s'il existe des réglages pour limiter la conso en idle, comme baisser la fréquence, mettre certains sous systèmes en veille, …
Il y a aussi un lien entre la fréquence, la tension et la conso. Si on baisse la fréquence sur N150 ou i7 ou autre, on peut se rapprocher des performances du RPI et quand on baisse la fréquence on abaisse la tension et comme la puissance consommée c'est une formule P=cFU^2, avec c l'inductance (dépend du nombre de composants dans le circuit), F la fréquence, et U la tension, on voit que la puissance va diminuer plus rapidement que la performance.
Par exemple si on a une puissance P0 de base et qu'on réduit la fréquence de 20%, et que la tension diminue de 10%, on va avoir P1=0.8*0.9*0.9*P0=0.648*P0, donc une réduction de 35% environ pour seulement 20% de perf en moins.
Après on peut jouer avec ces paramètres pour trouver le plus intéressant suivant l'application attendue.

C'est vrai que les cours de techno sur PC de marque Kenitec en 94-95 ça vendait déjà moins du rêve ! C'était assez fragile, le bouton de démarrage qui te reste dans la main…

J'ai l'impression que les enfants en primaire ne font plus du tout de travail sur ordinateur (pas dans l'école de mes enfants en tout cas), alors qu'on bricolait sur des MO5 et TO7 dans les années 80…
C'est peut être pour limiter l'exposition aux écrans LCD qui ont l'air aujourd'hui plus nocifs que les écrans CRT monochromes de l'époque…

Un petit exemple qu'on retrouve souvent : la barrière de synchro dont on ne sait pas si elle est nécessaire ou non, mais bon, dans le doute l'ajouter ne peut pas faire de mal.
Ici dans un code High Performance Linpack en précision mixte, avec le commentaire qui va bien :
MPI_Barrier(MPI_COMM_WORLD); // for extra safety

Fortran pour calculer vite… dans le domaine du HPC, Calcul Haute Performance, généralement ça ne va pas vite du tout !
Mais c'est vrai que c'est plus à cause du développeur qui est généralement matheux ou physicien et dont la préoccupation est déjà que le code tourne et n'a pas les connaissances en optimisation. Il faut voir tous les anti-patterns de perfs qu'on peut trouver dans ces codes : accès à la mémoire/aux caches non efficace, allocations dynamiques partout, boucles non fusionnées, … et je ne parle pas des communications avec MPI. Et c'est pareil pour les codes HPC en C ou C++.

C'est bien pour étendre la capacité mais c'est moins bien pour la bande passante si la machine à plusieurs canaux, généralement 2 sur les machines de base Intel/AMD ce qui permet en théorie de doubler la bande passante au passage.
Et pour que les 2 canaux soient activés il faut 2 barrettes identiques (ou avec des caractéristiques très très proches), sinon le système fonctionne sur un seul canal.
Si ce n'est pas critique ce n'est pas très grave mais c'est un truc à garder en tête pour des applications où la bande passante est critique et surtout sur des serveurs avec 8 ou 12 canaux quand les barrettes ne sont pas installées dans les bons slots.
Il me semble qu'un appel à dmidecode -t memory permet d'obtenir les infos sur les barrettes et le canal associé.

Est ce que ça offre la garantie qu'un compilo ne supprime pas le code ?
Sinon dans un bout de code assembleur ? normalement le compilo n'y touche pas…

De mon point de vue, le risque est la prolifération de plein de microarchitectures différentes supportant la même ISA. Une même ISA, c'est bien pour la portabilité du code mais pas pour la portabilité des perfs. Et il va y avoir celles qui seront documentées, et les autres bien opaques : c'est in/out of order ? combien de ports FMA ? c'est quoi la latence/throughput de tes instructions ? la largeur de ton unité SIMD ? etc. Un peu comme sur Arm entre un Cortex et des designs customisés genre M1, Graviton4, A64FX, etc. Et après dans le compilo il faudra un flag pour chaque type, comme c'est déjà le cas aujourd'hui mais sans doute avec un encore plus grand nombre de "saveurs". Bref, encore du boulot !

Je n'y connais absolument rien mais un ami m'avait parlé de ses travaux sur de la recoloration à la volée donc pas à la charge de chaque appli : https://research.nvidia.com/index.php/publication/2023-05_daltonization

J'ai cherché le livre sur une plateforme de commerce bien connue et j'en ai aussi trouvé un qui s'appelle "Pingouin manchot", de Philippe de Kemmeter, et là stupéfaction : le pingouin semble être en fait un manchot…

Merci pour les liens ! De mon côté je suis assez bloqué sur VULFPECK /// Live at Madison Square Garden en ce moment, ça funk bien aussi !

La réforme du DUT et Licence Pro en BUT maintient effectivement la possibilité d'obtenir le DUT au bout de 2 ans, mais ce n'est pas pour autant que cela sera considéré comme le même DUT par tout le monde. Certaines écoles indiquent que comme les enseignements sont étalés sur 3 ans, le niveau DUT sera acquis à la fin du BUT et donc les étudiants seront acceptés dans les écoles en 1ère année du cycle ingénieur, donc 6 ans pour obtenir le titre : CPU vs CDEFI

Je n'enseigne plus cette année en IUT mais j'y ai passé environ 15 ans donc voici mon analyse de la réforme et mon ressenti.

Le niveau des étudiants devient plus hétérogène avec l'obligation d'accepter 50% de BAC STI alors que dans pas mal d'IUT on pouvait remplir avec 100% de BAC S car beaucoup d'étudiants de S qui aiment l'info préfèrent passer 2 ans à faire ça plutôt que de passer par des prépas, ou des licences avec beaucoup de maths, physique, etc.
Et maintenant on a des bons étudiants avec un BAC S, toutes les options maths + info qui se retrouvent face à des BAC STI de différents niveaux et c'est pas simple à gérer.
Pour l'instant il faut attendre de voir quelles sont les filières qui vont accepter les étudiants de BUT : les écoles, les L3 informatique, les masters ???
De mon point de vue, la réforme n'est pas là pour aider les étudiants, ni fournir des moyens de mieux les former.
Il faut aussi voir comment ça a été mené en plein COVID avec des infos contradictoires ou des interprétations différentes des textes, l'introduction de pleins de projets comme ça ça coûte moins cher en heures, un stage de 8 semaines non obligatoirement rémunéré en 2ème année, un stage plus long en 3ème année et on peut se demander comment les étudiants vont trouver autant de stages.
Toute cette réforme évidemment élaborée en lien étroit avec les équipes pédagogiques concernées sur le terrain… ou pas !
La prochaine étape sera peut être d'imposer des taux de réussite (le rectorat a cette possibilité apparemment) pour assurer que 80% des étudiants obtiennent un BAC+3 qui ne sera pas une licence.
Ou alors je n'ai pas très bien compris l'intérêt de la réforme…
De toute façon, les équipes pédagogiques vont tout faire pour ne pas lâcher les étudiants, donc ça va donner l'apparence que la réforme fonctionne, mais c'est très difficile sur le terrain, dans mon IUT on a par exemple abandonné la formation en Année Spéciale qui permettait à des étudiants ayant un BAC+2 non info ou une expérience professionnelle de suivre une formation intensive d'1 an pour obtenir le DUT et une double compétence ou se réorienter.

Je ne connais pas les paquets spécifiques à installer mais c'est possible !
L'outil clinfo permet de lister les "plateforms" et "devices" disponibles sur la machine.

Après vérification le intel-oneapi-runtime-opencl c'est pour le CPU :
intel-oneapi-runtime-opencl/all,now 2022.0.2-3658 amd64 [installé]
Intel® CPU Runtime for OpenCL(TM) Applications runtime

Cette news m'a donné envie de laisser une nouvelle chance à OpenCL, au moins de retester quelques bouts de codes qui traînent !
J'avais bricolé avec OpenCL sur mon vieux Broadwell avec du HD Graphics 5300 Gen8 avec Beignet à l'époque, j'ai vu passer l'initiative NEO, mais je ne trouve plus de paquet pour ma Debian, intel-opencl-icd n'est plus dispo, j'ai aussi essayé un obscur intel-oneapi-runtime-opencl sans succès.

J'ai loupé un truc ? Est-ce que vous avez des retours sur Intel et OpenCL plus récents ? Est-ce qu'il faut envisager une autre publi dans la même lignée "OpenCL sous Linux : l'état des pilotes Intel, c'était mieux avant" ?

J'ai pas regardé, comme peu de personnes… en fait personne n'utilise des GPU AMD dans mon entourage ! Mais c'est un point un peu rageant de savoir que les GPU AMD sur le papier ont des specs très intéressantes mais qu'on est toujours bloqué par un driver qui est pas stable, une install qui passe pas, une API pas très pratique, pas beaucoup de doc, ou des libs qui n'existent pas.

Avec un matériel comparable, mais en offrant du soft qui répond aux besoins, Nvidia a réussi a prendre le marché du calcul sur GPU. J'ai commencé, sur des GTX 285, c'était pas très stable mais on pouvait tester et rapidement c'est devenu bien stable. Sur des GTX 480 dans un serveur, j'ai fait des TP CUDA avec une trentaine d'étudiants sans que ça bronche.

En plus Nvidia proposait un partenariat académique Nvidia Teaching Center et m'a envoyé des dizaines de cartes gratuitement (bon d'accord à l'époque ils ne savaient pas quoi faire de leur stock de GTX 480 et ça permettait de chauffer les salles l'hiver) et même une Tesla, et des bouquins pour les étudiants. Il y a aussi plein de webinaires, des exemples, des ressources. Intel, AMD et ARM n'ont pas mis en place de partenariat similaire, c'est sans doute aussi ce positionnement qui a pas mal aidé à l'installation de CUDA.

Je suis pas tout à fait d'accord. Une question que je me pose depuis l'annonce d'OpenCL c'est à qui ça se destine. Je travaille sur des codes écrits généralement par des spécialistes de leurs domaines mais pas des informaticiens donc les codes fonctionnent (Fortran, C voir C++), mais ne sont pas optimisés. Ces personnes là font aussi un peu du MPI mais généralement synchrone, et de l'OpenMP, peut être un peu de CUDA, mais ne font pas d'OpenCL. Ceux qui optimisent vont généralement utiliser des technos ad-hoc : des intrinsics pour la vecto, peut être de l'assembleur (quand le compilo n'y arrive pas), du CUDA bien optimisé, etc, mais peu d'OpenCL (sauf pour les archis qui ne supportent que ça) car c'est verbeux, ça oblige à écrire un code optimisé par architecture et pour la portabilité, souvent on ne tourne que sur 1 ou 2 architectures (dans mon domaine au moins).

Concernant les gains en optimisant pour son architecture, c'est généralement pas marginal du tout, même sur des codes très simples et sans descendre au niveau assembleur. Il suffit de prendre une simple réduction pour s'en convaincre, écrite "naïvement" on est assez loin de la bande passante disponible. Un peu d'intrinsics, plusieurs variables temporaires pour accumuler et profiter du pipeline des unités de calcul, des "mov" non temporels si on ne réutilise pas les données ensuite, et le code est tout de suite beaucoup moins lisible mais beaucoup plus rapide. Et pour CUDA je vous laisse réfléchir aux optimisations proposées par M. Harris et à la tête du code final.

Donc la promesse d'OpenCL (en fait pas vraiment d'OpenCL, c'est plutôt ce que beaucoup pensent d'OpenCL) d'écrire un seul code qui passe pas trop mal partout avec des perfs (80% des perfs?) me semble illusoire.

Concernant la rentabilité, ceux qui ont investi dans CUDA il y a 10 ans s'en sortent à mon avis pas mal. Par contre OpenCL, on voit bien le déclin des drivers, du support par les fabricants, de l'utilisation dans des applis comme Blender, etc. Et je pense que SYCL ne résoudra pas non plus le problème. Si on veut des perfs il faut du code spécifique. Après, on peut toujours croire aux compilateurs "automagiques" qui vont automatiquement transformer les structures de données du code, vectoriser, faire les "mov" non temporels quand il faut, dérouler et casser les dépendances correctement, etc. Mais, je pense avoir encore pas mal de boulot pour des années !

Il y a une liste chez Khronos, sinon pour ma part j'ai abandonné OpenCL il y a déjà un petit moment. Je regarde plutôt SYCL et oneAPI avec le compilo DPCPP, mais j'attends aussi les prochains GPU Intel pour voir si ça amène enfin un peu de concurrence. Il me semble quand même difficile pour Intel de revenir au niveau de Nvidia qui a du matériel à tous les étages et des softs bien éprouvés. AMD aussi a du matériel dans les cartons mais c'est toujours au niveau bibliothèques et outils qu'il y a un gros manque.

Il y a une suite de tests appelée CTS mais qui semble être arrivée un peu tard.