sjub a écrit 28 commentaires

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.

Je développe en CUDA depuis presque le début, vers 2009-2010, et je me suis intéressé aussi à OpenCL, pour l'aspect portabilité en plus, mais j'ai fait face à beaucoup de problèmes de drivers, de performance, etc, et je suis finalement resté sur CUDA (je sais Nvidia pas bien, pas libre, etc, mais ça marche, il y a plein d'outils qui fonctionnent très bien, et c'est ce qui est installé sur les machines auxquelles j'ai accès).
Suite à mes déboires, j'avais recherché un peu d'autres expériences sur le sujet et je suis tombé sur cette présentation qui résume bien les problèmes avec OpenCL : l'API est libre, ok, les implantations peuvent l'être, ok, mais chaque implanteur est aussi libre d'interpréter certains aspects de la spec comme il l'entend, de ne supporter qu'une version de l'API (Nvidia reste en 1.2 il me semble) et évidemment d'introduire ses propres bugs. Donc la portabilité annoncée, c'est pas garantie.
Une erreur toute bête à mes débuts sur laquelle j'étais tombé entre Intel et Nvidia, je précise que c'est de ma faute, j'étais pressé : les fonctions OpenCL retournent un code erreur sous la forme d'un int : cl_int err = clMaFonctionOpenCL(…), et pour traiter l'erreur j'ai supposé que, comme d'habitude, 0 c'était ok, donc if( err ) {// je traite l'erreur}. Mais rien ne précise la valeur dans la spec, donc un des 2 vendeurs a choisi une autre valeur que 0 quand tout va bien donc il faut faire explicitement if( err != CL_SUCCESS ) {…}.
Ce n'est pas grand chose, mais ça ajoute à la verbosité d'OpenCL.

Heureusement SYCL est là pour résoudre tous ces problèmes… ou pas…
Personnellement, je ne comprends pas l'acharnement à faire vouloir mettre une API portable partout alors que pour avoir les performances il faut de toute façon réécrire des kernels optimisés pour presque chaque architecture.

Quand j'ai besoin d'infos pour les procs Intel (et au regard de la nomenclature super claire sur les différentes gammes…) pour connaître l'archi, les jeux d'instructions AVX supportés, les caches, etc, je me tourne vers le site Intel Ark. Par contre, je ne sais pas si on peut extraire les données proprement.

Petite parenthèse : pour les derniers Alder Lake, les coeurs "Performance" ont de l'AVX-512 dedans, mais pas les petits coeurs "Eco" donc c'est désactivé, par contre pour les versions d'entrée de gamme avec uniquement des coeurs "Performance", on aurait pu espérer pouvoir activer l'AVX-512 mais Intel semble forcer les fabricants de cartes mères à désactiver cette possibilité…

Ou sur la Tesla l'écran tact

Je préfère ne pas faire de pari ! Et je ne vois pas pourquoi on devrait a priori mettre plus en doute la personne que la machine. La machine est conçue et programmée par des personnes, et est qu'on a confiance dans les développements fait dans l'industrie automobile avec du code fermé, sans garantie présentée à l'acheteur ?

J'ai aussi eu un problème avec mon régulateur qui un jour s'est mis à se désactiver/réactiver sur l'autoroute. Le problème ne venait pas du soft du régulateur ni de moi, mais d'un faux contact dans le bouton du régulateur… La technologie du bouton ne semble toujours pas maîtrisée !

En fait, je souhaiterais supprimer gradle de l'équation et pouvoir utiliser un truc simple comme make par exemple.

Est-ce que quelqu'un a déjà fait la même chose pour compiler des applis Android en Kotlin en ligne de commande ? Comme il y a plein de choses qui passent deprecated en Java (AsyncTasks notamment) on sent bien que ça pousse au basculement vers Kotlin.
Mon principal problème est pas forcément Android Studio mais surtout Gradle qui passe son temps à télécharger des trucs dans tous les sens et passe énormément de temps à faire je sais pas quoi avant de compiler…

Le problème de logistique je sais pas trop quoi en penser. Pour mon portable Lenovo de 2015, mon écran était HS, et la coque était un peu fissurée donc je trouve les pièces sur un site chinois bien connu pour environ 80€, avec les frais de port pas trop élevés, et hop c'est reparti pour quelques années ! Pareil pour mon téléphone et son écran fissuré, 20-30€ et c'est réparé. Par contre pour une pièce pour un truc de cuisine provenant de France, 15€ de frais de port pour une pièce de 20€ ça fait un peu disproportionné.
Évidemment ça m’embête de faire venir ces pièces de l'autre bout du monde pour le bilan carbone, mais d'un autre côté j'évite d'envoyer pas mal de matériel à la poubelle. Donc c'est quoi le mieux ?

Il me semble que dans l'émission suivante La Terre au carré - obsolescence il y a un intervenant qui explique que les fabricants ne prévoient tout simplement pas de circuit de pièces détachées d'où l'impossibilité de trouver des pièces ou alors à des prix pas intéressants.

Sur mon ancienne machine à laver, la carte électronique a lâché 6 mois après la fin de la garantie. Bilan, 300€ pour la remplacer, soit presque le prix de la machine… Après démontage, il s'est avéré que la carte était commune à pas mal de modèles de différentes marques et j'ai trouvé un tuto indiquant comment remplacer les 3 composants grillés. Au passage il y avait une explication sur l'origine de la panne : un composant trop justement dimensionné. Le coût des 3 composants était d'environ 1€, mais ils se commandent par 10, et en soudant ça avec mon gros fer à souder, la machine a encore tourné pendant 10 ans.

J'ai aussi récupéré un écran Dell 30 pouces comme ça : tuto sur le net, même problème de dimensionnement d'un composant, composant de rechange pas cher, j'y connais rien en électronique et j'ai pas de supers outils, et ça fonctionne encore des années !

Évidemment, les modèles plus récents avec USB et écran me laissent un peu plus perplexes question longévité/fiabilité que le TM31 beaucoup plus simple.

J'ai le FPP220 depuis environ 10 ans, les plastiques du bol et du blender se sont fissurés progressivement, aujourd'hui le blender est HS, le bol ne va pas tarder à rendre l'âme. Même constat sur un petit mixer de la même marque. Un petit axe en métal, pour la rotation des pièces, est scellé dans le plastique au fond des bols et ça se fissure petit à petit autour. En regardant les pièces de rechange sur le net, le prix de l'ensemble bol + blender + couvercle est largement supérieur à celui d'un nouveau modèle… Prochain achat un truc en métal ? En tout cas le Thermomix c'est plus cher mais ça tient le coup et on trouve les pièces de rechange moins cher (joints, etc, sauf le bol). Vive le métal !

Ça dépend ce que l'on veut mesurer : si le jeu de données ne tient pas dans le cache on va de toute façon se heurter au coût de l'éviction du cache avec un "mov" standard, qui sera plus faible si on fait un "movntdq" et on peut mesurer la bande passante mémoire max, sinon si le jeu de données tient dans le cache et qu'on fait plusieurs itérations dessus on va mesurer le débit des caches et là il vaut mieux utiliser un "mov" pour que les données soient laissées en cache, sinon avec "movntdq" certaines pages auront tendance à être évincées et le débit va baisser.

Au passage j'ai une petite remarque sur la bande passante du processeur M1 : en lecture je mesure environ 60Go/s (c'est énorme !) et en écriture "seulement" 30Go/s, donc c'est pas symétrique contrairement aux systèmes habituels. Je n'ai pas trouvé de détails sur le pourquoi du comment (et Apple n'est pas très bavard sur son processeur) donc si quelqu'un a une info là dessus je prends !

En fait c'est pas 1,6GHz mais 1,6G transactions de 64 bits donc 8 octets (la fréquence réelle est 800MHz mais on peut faire 2 transactions par cycle), ce qui donne le débit de 12,8Go/s, plus de détails ici : https://en.wikipedia.org/wiki/DDR3_SDRAM.
Comme la mémoire de 8Go est soudée je pense que ce n'est qu'une barrette, on a un seul canal, donc on arrive bien à la bande passante maximale avec le code optimisé. Pas la peine d'essayer de trafiquer encore le code pour gagner des perfs ! Bon après en passant en AVX on peut faire moins d'instructions et donc sans doute pouvoir réduire la fréquence et baisser la conso (j'ai fait des expériences sur Arm et le passage d'un code scalaire à NEON permet de réduire pas mal la conso en baissant la fréquence tout en gardant les performances) ou avoir plus de ressources disponibles pour d'autres processus.

Je n'y crois pas trop moi-même ! Il vaut mieux passer par l'unité SIMD dispo qui est plus large et possède les bonnes instructions.

En plus on peut aussi optimiser les loads : comme on ne fait que lire et qu'on ne réutilise pas les données on va vite remplir le cache pour des tableaux assez grands et donc il faut trouver des lignes dispos pour mettre les nouvelles données ce qui peut prendre un peu de temps. On peut dans ce cas utiliser les loads non temporels via les intrinsics streams (movntdq), c'est à dire qu'on indique au cache qu'il peut évincer sans pitié la ligne de cache que l'on vient juste d'utiliser et ça va un peu plus vite pour trouver de la place dans le cache pour charger de nouvelles données. On retrouve ces instructions notamment dans le code de memcpy.

Effectivement, le plus pratique est de faire un XOR avec deux comparaisons. Si on veut quand même supprimer une comparaison il faut ajouter pas mal d'opérations logiques et des masques donc ce n'est plus rentable. Une idée : "replier" les sous parties 32-bit sur elles-mêmes avec des OR et des masques de manières à tout accumuler dans le bit 0 et le bit 32, puis décaler le bit 32 vers la position 1 et on obtient soit 0 si pas trouvé, soit 1 si trouvé en position basse, soit 2 si trouvé en position haute, il ne reste qu'à comparer avec 0 et retourner i+lavaleurcalculée-1. Bon là on n'est plus dans l'optimisation du tout !