Pour le contexte,je n'aimais pas cette vidéo au début, d'une part parce que l'on parle de Visual Studio, et que ça sentait un peu le refrain du "C T mieux avant !".
Cela dit, il y a une partie de vrai dans ce qui est dit, et est généralisable, puis la dernière partie de la vidéo est intéressante : l'interviewé, essaie d'expliquer, pourquoi, aujourd'hui, certains logiciels sont devenus lents, affreusement lent, par rapport à ce qu'ils étaient début 2000.
Les arguments avancés (ça permet d'éviter de voir la vidéo, que je comprends, ne plait pas, mais tout va bien !) :
Les développeurs d'aujourd'hui apprennent beaucoup de chose, mais pas ce qu'est un CPU, ni comment optimiser ;
Il y a d'autres centres d'intérêt, plus rémunérateur, qui focalise l'attention ailleurs, il trouve le CSS par exemple plus complexe que l'assembleur ;
Les erreurs de certains projets s'accumulent, et le mal devient irréversible, il faut souvent trop de travaille pour revenir à quelque chose de performant et on dépense en vain pour corriger à posteriori ;
Les performances ne sont pas une priorité, parce que l'on vit sur la certitude que la puissance évolue toujours de façon exponentielle (puis ça fait vendre).
Voila, il y aurait pu y avoir un débat inter-générationnelle, pour ou contre les accolades en fin de ligne et tout.
Perso, j'évite de moinsser (ce serait d'ailleurs intéressant de connaître les statistiques de son propre compte à ce sujet), mais il faut bien avouer que ma position est très claire vis-à-vis des liens youtube — appuyée par le fait que je ne compile pas de codecs vidéo sur mon pc, ou en tout cas pas adaptés à ça — « les liens youtube c'était mieux à l'époque où ça pointait vers des textes en UTF-8, voire en ascii. » :-)
Pareil pour moi, je vois un lien vidéo (surtout youtube, qui coumule les inconvénients de la vidéo avec ceux d'appartenir à google), je passe mon chemin (sans moinser).
Un texte, on peut le survoler pour voir ce qu'il vaut, une vidéo, c'est plus dur.
Un texte a souvent besoin d'être mieux pensé et mieux construit qu'une vidéo, qui est souvent plus immédiatiste. Attention, je dis souvent, parce que les textes mal torchés et les vidéos super-intéressantes, il y en a, et plus qu'à leur tour. Mais dans mon cas, quand je cherche des infos et des développement sur un sujet, je favorise toujours les textes et ne me rabats sur les vidéos que quand je n'ai pas le choix.
En fait, ici, l'idéal serait d'éviter les liens vers les vidéos et faire à la place un court journal résumant la vidéo et qui donnerait envie de la voir. Ou non. Ça permettrait d'avoir l'équivalent du survol du texte. Par exemple, le message de YBoy360 qui résume la vidéo aurait été bienvenu dans son entrée de lien (qui serait alors devenu un journal).
Casey Muratori est un programmeur que je qualifierai, entre autres choses et sans vouloir le limiter à cela, de militant en faveur de programmes plus efficaces. C'est loin d'être un clown et je lui attribue des qualités de pédagogue.
Il a notamment échangé publiquement avec Robert C. Martin au sujet du livre Clean Code de ce dernier, de l'impact négatif en termes de performance que les conseils du livre ont généré. Là où beaucoup de programmeurs dégagent un air prétentieux et supérieur en méprisant Clean Code, Casey a opté pour une approche critique en échangeant ouvertement et poliment avec le premier concerné : https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md
C'est un peu dommage que le lien soit moinsé parce que le gars vaut le coup d'être écouté. Ce n'est pas son intervention la plus instructive mais un bon point d'entrée. Une citation de cette vidéo :
The idea that programmers are too lazy, or something, to learn and employ the stuff is simply false. It is that culturaly they have been taught, and are working with peers, who think that somehow it's virtuous to not know how a computer works. And that is a problem.
De mon expérience c'est tout à fait juste. Entre l'éducation universitaire qui pense en complexité algorithmique et en machine abstraite, l'industrie qui pousse pour des solutions vite implémentées pour pas cher en jetant des « Engineering time is expensive, memory is cheap », le délire de la montée en puissance considérée comme acquise, la culture du one-liner et le fantasme du compilateur qui optimise tout ; aucun doute que l'éducation des programmeurs va à l'opposé de l'écriture de programmes efficaces.
Entre l'éducation universitaire qui pense en complexité algorithmique et en machine abstraite
Je ne pense pas qu'il faille opposé la complexité algorithmique et en mémoire sur la compréhension du CPU.
l'industrie qui pousse pour des solutions vite implémentées pour pas cher en jetant des « Engineering time is expensive, memory is cheap »
Les utilisateurs aussi poussent à cela.
le délire de la montée en puissance considérée comme acquise
Parce qu'elle l'est encore plus ou moins et l'a était pendant des décennies.
la culture du one-liner
Souvent aussi poussé par le même genre de personnes qui ont une bonne maîtrise du CPU
le fantasme du compilateur qui optimise tout
Jamais entendu ça, j'ai entendu "si tu veux pas t'y intéressé plus, écris un code simple, ça aidera le compilateur".
La performance en informatique est immensément plus complexe que ce que la majorité des gens qui en parlent décrivent. Il y a un paquet de façon de comprendre ce qu'est la performance (amélioration de la latence, du débit, de la consommation de ressources, du temps d’exécution,…) et je n'ai jamais vu de critique prendre véritablement le temps de se poser sur ces questions, d'ensuite décrire comment est-ce qu'on mesure (Mozilla s'est cassé les dents à être plus rapide avec un ressenti plus lent que son adversaire) pour ensuite expliquer comment est-ce qu'on y parvient.
Dire que les gens ne comprennent pas les CPU c'est vrai je suis d'accord, mais c'est sauter à la conclusion, ils ne comprennent pas plus les IO par exemple, ni leur stack d'affichage,… selon ce qu'ils écrivent comme logiciel le CPU ne sera pas forcément le plus important.
Et la performance n'est pas le seul critère, la sécurité est très largement ignorée, on parle vite fait de performance, mais que ce soit avoir un code véritablement sûr ou supprimer les supply chain attack ça ne fait parler que vite fait quand un drame se produit sans pour autant dire qu'il y a de solution sûre à ce sujet. Il en existe pas, mais est-ce que c'est une bonne raison pour ne pas s'attaquer au sujet ?
Je suis personnellement beaucoup plus pour un processus d'amélioration où on pose la question de qu'est-ce qui est important (rapidité, efficacité, sûreté, réactivité,…) et qu'on regarde comment l'améliorer ou le maintenir dans le temps. Ça peut consister à connaître le CPU ou peut être à en faire tout simplement moins (et à considérer que des fonctionnalités n'ont pas leur place) ou tout un tas d'autres choses.
Clean code met l'accent sur la maintenabilité du code, lui reprocher son manque de performance est une évidence, c'est toujours une histoire de compromis. Personnellement tu ne me verra pas écrire un duff's device sans qu'il y ai un besoin absolument critique de cette ignominie.
Posté par YBoy360 (site web personnel) .
Évalué à 6 (+4/-0).
Dernière modification le 17 décembre 2024 à 09:17.
Merci, pour moi ce qu'il dit est cathartique. Avoir le courage d’argumenter fasse au "ne pas faire de micro-optimisations" (ce qui est une bonne pratique "clean", qui se transforme en "ne pas les faire trop tôt …") est courageux, même si tout est question d’équilibre, il faut les faire en cas de gains significatifs.
Pour avoir fait beaucoup d'optimisation CPU, il est clair que la moyenne des développeurs ne se soucis plus d'optimisations et de spécificités d'architecture. Cela dit, les articles traitant d'optimisation CPU / GPU ont souvent du succès, même aujourd'hui.
l'IA, les Rust, Java et autres, prouve que l'on isole plus le compilateur, l'IDE, le langage et le HW. Et c'est très prometteur pour le future.
Une de mes grandes fiertés de cette année, c'est d'avoir sur quelques mois :
réalisé une analyse statistiques de données de prod
choisi un modèle mathématiques en rapport avec ce que j'observais
évalué la viabilité de mon modèle par des benchmark et des expérience pour vérifier la fiabilité fonctionnelle (comme ça utilise des proba vérifier qu'on ne tombe véritablement pas dans les cas problématiques)
choisi un meilleure architecture lié à ce modèle mathématiques pour réduire la taille des données manipulées
utilisé des optimisations bas niveau accessibles grâce au fait d'avoir réduit la taille des données (pour faire simple chaque élément tiens maintenant dans un registre)
et ainsi obtenu des gains de 50% de nos débits (sous charge sinon ça se voit pas) sur un pan assez important de notre logiciel.
C'est une illustration de ce que je décrivais, il ne faut pas opposé la complexité algo et le CPU, il faut les coordonner pour arriver au résultat que tu attends.
J'ai l'impression qu'on cadre beaucoup cette discussion comme si c'était (uniquement) un problème de compétence des développeurs. Je pense que ce n'est pas vraiment le cas, il y a plein d'autres choses qui rentrent en jeu.
La première, c'est que dans beaucoup de cas, les optimisations ne sont pas nécessaires ou pas prioritaires. Optimiser le code, concevoir l'architecture la plus efficace, ça prend du temps. Souvent, c'est plus important de livrer des nouvelles fonctionnalités très vite (avant les concurrents). Et en plus, on travaille avec des spécifications changeantes (les fameuses méthodes agiles), alors que pour faire de l'optimisation, il faut souvent pouvoir considérer un problème dans son intégralité pour bien déterminer la solution optimale. Si tu passes un mois à écrire la structure de donnée parfaite, mais que la semaine suivante, finalement ton programme doit faire autre chose, tu peux tout jeter et recommencer.
Il y a aussi une certaine tolérance des utilisateurs. C'est vrai en informatique mais aussi dans d'autres domaines. Par exemple, les téléphones mobiles modernes ont une latence plus importante que les anciens téléphones fixes à réseau par commutation de circuits. On s'est habitué, les usages ont évolué, et maintenant on arrive même à faire des visioconférences à plusieurs avec une latence encore plus importante. Il en va de même pour l'informatique, les gens développent une tolérance aux interfaces lentes et on peut se permettre d'être de pire en pire sans que ça fasse fuir tous les clients.
Du côté des développeurs, par contre, il y a quelques domaines où ça ne marche pas comme ça: le jeu vidéo, ou les systèmes embarqués/temps réel par exemple. Dans ces contextes là, il y a moins de problème pour passer du temps à optimiser les choses, il y a le budget pour, parce que sinon, le projet de marche pas.
Une solution serait de rendre les choses obligatoires. Pour la sécurité ça commence à se faire par exemple avec le Cyber Resilience Act qui va pousser les entreprises à assurer les mises à jour de sécurité. Du côté des performances, il pourrait y avoir des équivalents pour l'éco-conception (soit avec des obligations, soit avec un étiquettage/certification de type "nutri score"). En fait, c'est aussi déjà le cas dans certains domaines, les développeurs de frigo connectés sont très bons pour faire de l'électronique et du logiciel à basse consommation pour pouvoir afficher le score A++ en consommation d'énergie.
Au final, le problème ce n'est pas vraiment les développeurs, ce sont les clients qui ne veulent pas payer pour avoir des logiciels performants, ils préfèrent avoir un truc moins cher et livré plus tôt, et payer un peu plus de matériel. Là, une autre solution serait de rééquilibrer le coût du matériel (vraiment pas cher actuellement) et le coût du travail humain. Si les développeurs étaient payés moins cher, on pourrait leur faire passer du temps pour faire des économies sur le matériel. Ce n'est clairement pas l'équilibre actuel des choses.
ce sont les clients qui ne veulent pas payer pour avoir des logiciels performants
Toute notre économie est tournée vers la production de masse au meilleur coût pour dégager un max de bénéfice, quel que soit le coût en certains autres termes qui ne comptent pas, les coûts environnementaux par exemple.
Les développeurs d'aujourd'hui apprennent beaucoup de chose, mais pas ce qu'est un CPU, ni comment optimiser ;
Ceux qui essayent s'y brûlent, on perd du temps à améliorer le tout avec ses 2 machines de test, on déploie, bam perte de performance sur une machine ailleurs, on râle, puis on comprend que le meilleur compromis sur toutes les machines c'était celui fait par le compilo sur notre "mauvais" code, et on n'a pas l'argent illimité pour optimiser pour chaque CPU donc on se dit qu'on aurait dû faire comme les autres et ne pas chercher à optimiser car c'est de nos jours pas bien rentable.
(quoi? Oui, je suis en plein dedans en ce moment, je m'arrache les cheveux à tester plein de machines différentes, entre CPU et aussi GPU)
Si ton optimisation n'est pas celle du compilo. y'a des chances pour que tu te sois foiré quelque part.
Pour avoir appris sur mon temps libre l'assembleur, je peux dire qu'il n'est pas si difficile d'optimiser un code. La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU (y compris les questions de latence sur les IO car ces accès sont explicites - et on distingue bien un accès en lecture et en écriture).
À partir de là :
L'exercice consiste à étudier la sortie d'un compilo sur du code simple.
Par obligation on est amené à réimplémenter des fonctionnalités très simple. Autre exercice : étudier comment la libc ou autres fait ça.
Spoiler alert : il y'a quantité d'optimisations qui ne sont pas déléguées au compilo. Alors à moins de considérer que les devs de la libc sont des branques…
Trois trucs avec le compilo :
Tu ne le maîtrises pas ni le contrôle. Alors à moins de délivrer qu'un binaire final, tu ne peux préjuger des optimisations appliquées. Les compilos modernes sont devenus horriblement complexes… et LENTS !
À force de déléguer on finit par avoir des CPUs complètement troués parce qu'on pense que la prédiction de branche automatique c'est bien plutôt que de prendre 5s pour signifier au CPU que ce code-ci sera l'exception et l'autre la règle (donc non optimiser un code nécessite pas d'avoir forcément un bagage technique de fou). Sur ce point la causalité est inversée : si c'est le foutoir dans les CPU à tel point qu'un dev n'est pas capable de prédire à l'avance quel code sera performant sur telle machine (manque de prédictibilité du matériel et absence de modèle simple du comportement d'un CPU), c'est bien parce que les concepteurs de CPU y vont chacun de leur petites trouvailles pour obtenir les meilleures perf. malgré du code claqué au sol. On retrouve la même blague sur le nombre de cycle horloge par instructions. Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que… "c'est trop compliqué un CPU".
Ce qui nous amène au dernier point : le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait. Seul l'usager sait ce qu'il va en faire et le boulot d'un dev. c'est aussi d'optimiser son temps, savoir quand et où il a intérêt à lever les automatismes et prendre en charge lui-même les micro-optimisations (car faut-il encore le rappeler une énième fois la micro-optimisation c'est que dalle en terme de gain de performance face aux choix de conception - sélection des algorithmes, arbitrage entre le besoin et les moyens, etc.) C'est pas la compilo qui va te dire si ton algo de tri doit être économe en espace ou en temps, si t'es données sont presque triées ou totalement aléatoire, etc. Il pourra toujours essayer de le deviner mais cela impliquera une surcharge qui ne sera pertinente que sur de gros volumes (information que le compilo ne connaît pas…).
La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU
Pas vraiment. Les CPU modernes:
N'exécutent pas les instructions dans l'ordre,
Ont plus de registres en interne que ce qui est disponible dans le jeu d'instruction, et renomment/réassignent les registres à la volée,
Sont fabriqués par plusieurs fabricants implémentant le même jeu d'instruction, avec des nombre de cycles CPU par instruction pas forcément identiques,
Partagent les unités d'exécution entre plusieurs threads, donc on ne peut même pas savoir quelles ressources vont être disponibles,
De toutes façons, le problème est probablement la bande passante de la mémoire et rendre l'exécution du code sur le CPU plus rapide va juste faire que le CPU passe plus de temps à attendre au lieu d'exécuter du code.
Au final, l'assembleur est un langage de programmation comme un autre, il n'est même plus "proche du matériel". Donc autant choisir un langage plus confortable.
Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que… "c'est trop compliqué un CPU".
Faire du code optimisé pour un modèle de CPU, une taille de cache fixe, une mémoire avec une bande passante bien déterminée: facile.
Faire du code optimisé dans tous les cas, y compris pour des CPU qui ne sont pas encore fabriqués: impossible.
Ces optimisations dans les CPU sont ce qui permet d'avoir du matériel moderne qui continue d'exécuter le code existant avec de meilleures performances. Je trouve ça mieux que de dire "ah on a rajouté 1Mo de mémoire cache dans le nouveau CPU, mais tu dois réécrire tout ton code pour l'exploiter, parce que c'est à toi de dire explicitement quelles variables il faut stocker dans le cache".
Le problème est simple: il vaut mieux optimiser le temps de travail des développeurs, plutôt que quelques cycles CPU. Et donc, ne pas avoir à réécrire tout le code à chaque nouvelle génération de CPU, c'est bien.
le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait.
C'est faisable, on peut donner à gcc une trace d'exécution du code et recompiler une deuxième fois, et il va ajouter automatiquement les instructiosn de prédiction de branchement. Est-ce que des gens s'embêtent à le faire? Non, parce que même cette procédure entièrement automatisée n'a aucun intérêt économique dans la plupart des cas. Le temps passé par le développeur à mettre en place ça va coûter plus cher que les 0.1% de performance qu'on va pouvoir gagner. Sauf dans quelques cas particuliers où ces micro optimisations vont faire la différence entre "ça ne marche pas du tout" et "ça passe de justesse", ou là, le développeur peut être payé très cher pour passer du temps à ce genre de choses.
Et de toutes façons le problème de l'optimisation n'est même pas là la plupart du temps. Il y a des problèmes beaucoup plus bêtes de mauvais choix de structures de données, ou de mauvaise utilisation de structures de données. Par exemple, faire plusieurs fois de suite une recherche d'un objet dans une map, au lieu de le trouver une fois et de garder une référence. Là on peut avoir des gains de plusieurs dizaines de % de performances, et ça peut être intéressant d'y passer du temps.
Et pour faire ce genre de choses, c'est plus facile si on travaille avec un langage haut niveau ou au moins qui propose un bon choix de structures de données disponibles dans sa bibliothèque standard (C++ ou Python par exemple). Sinon, le coût de développer ne serait-ce qu'une hash map n'en vaut peut-être même pas la peine.
Il y a quand même des cas où le passage par l’assembleur reste efficace : c’est les codes qui peuvent massivement gagner en performances en utilisant énormément les instructions SIMD (SSE, AVX…) typiquement les codev vidéo (exemples : https://github.com/xiph/rav1e, https://code.videolan.org/videolan/dav1d).
ça c'est ce que tu fais uniquement lorsque le reste n'a pas permis d'atteindre les performances nécessaire.
Et ça implique de devoir différencier les binaires selon la plateforme (processeur), au risque d'avoir un crash franc de l'application; une solution est de vérifier les capacité du proc et choisir la bonne fonction, mais c'est rarement fait dans le cas des développement particuliers.
typiquement https://code.videolan.org/videolan/dav1d ne tournerai pas sur mon ancien proc qui ne gérait que l'AVX, et non l'AVX2. C'est dommage car il serait normalement amplement suffisant pour le décodage des vidéos.
Ou pour faire plus simple, dans le but de rendre le truc performant sur les anciennes plateforme, tu a fais un code qui ne tourne plus dessus :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Et encore tu oublies que pas mal d'appli doivent pouvoir tourner sur plusieurs archi mac, PC, téléphone, console… avec des spécificité propres.
Et de toutes façons le problème de l'optimisation n'est même pas là la plupart du temps. Il y a des problèmes beaucoup plus bêtes de mauvais choix de structures de données, ou de mauvaise utilisation de structures de données. Par exemple, faire plusieurs fois de suite une recherche d'un objet dans une map, au lieu de le trouver une fois et de garder une référence. Là on peut avoir des gains de plusieurs dizaines de % de performances, et ça peut être intéressant d'y passer du temps.
Je ne compte plus le nombre de if(map.existe('machin')) { Plop zut = map.get('machin'); } que je trouve dans le code, ou les push_back sauvage dans un vecteur sans avoir réservé la taille nécessaire alors qu'elle est connue.
J'ai aussi trouvé des vérification de clé unique via un parcours dans tableau (non trié cela va de soi), lorsqu'on augmentait un peu la taille des données ça explosait le temps de vérification.
Y'a aussi la manie de garder le xml source de données qu'on reparse à chaque fois pour en récupérer une valeur.
Ouais avant de descendre à l'assembleur, inutile dans l'immense majorité des cas, se pencher sur le code, ses structures, et ses tâches sont bien plus rentable. Si on a pas de quoi instrumenter le code, un bon vieux debugger avec arret, print stack trace de tous les thread, continue, et on recommence, permet de facilement trouver là où l'on passe du temps (a vu de nez) (les mesure exacte ça reste mieux)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Posté par BAud (site web personnel) .
Évalué à 4 (+2/-0).
Dernière modification le 17 décembre 2024 à 16:58.
Ces optimisations dans les CPU sont ce qui permet d'avoir du matériel moderne qui continue d'exécuter le code existant avec de meilleures performances.
de toute façon — me concernant — j'ai croisé plus d'applications I/O bound (le CPU passe son temps à attendre des données à traiter) que CPU bound…
déjà pour celles CPU bound savoir gérer le mulithreading (avec la démultiplication des cœurs) ou au minumum le multi-process ce serait bienTM : cas réel, une appli calculatoire qui fonctionnait mieux sur un CPU à 3,6 GHz que sur un CPU plus récent multicœur (6 ou 8) mais à 1,6 GHz : 3h de traitement contre 4 à 5h, 8 mois après et 4 changements de CPU, le projet a enfin eu son budget pour passer en multithread :/ (ce qui était ma recommandation initiale…)
pour celles I/O bound :
relire un répertoire de 10000 fichiers à chaque fois qu'on traite un fichier, autant en mettre 9000 de côté et les fournir par paquets de 1000 pour accélérer les traitements de rattrapage…
savoir optimiser des requêtes SQL : ça me prenait parfois jusqu'à 3 semaines pour disposer d'un DBA compétent, mais passer de 10 sec à 100 ms pour des requêtes conséquentes réutilisées, ça peut valoir le coup (tant que les requêtes sont fonctionnellement équivalentes) et j'ai maudit pas mal d'ORM pour leurs requêtes imbriquées aux plans d'exécution douteux)
lenteur d'affichage de page : connaître le problème des écrivains / lecteurs et les optimisations de moteur SQL, ça peut aider… en plus de la gestion basique des locks (pas forcément qu'au niveau ligne, parfois niveau bloc :/)
bref, la gestion des perfs : un bon profiler de code pour savoir où tu passes le plus de temps et savoir organiser des tests/benchmarks avec des volumétries représentatives…. (mais c'est un autre métier que développeur en tant que tel)
La recherche des fichiers n’est pas si consommatrice. La structure des répertoires est très légères et, sauf le premier accès, va être pauvre en IO. Ce qui va se jouer c’est le syscall (permutation user-kernel mode), et les différents algo. en œuvre pour la résolution du chemin, la vérification des droits, etc. Par défaut, par exemple, la liste des fichiers est très souvent triée dans le monde Unix, au lieu d’être restituée dans l’ordre présent sur le disque (± l’ordre dans lequel ça a été écrit). Il y a de quoi accélérer tout ça, ne pas constamment demander au kernel une résolution de chemin encore faut-il y avoir accès (donc probablement qu’en C ?) et les connaître. Ça demande une compréhension fine du système, un profiler n’est qu’une aide qui ne répond que, très mal, qu’à une partie du problème. Au mieux du mieux, il te donne une piste sur les bouts de code à optimiser. Mais rien ne garantit que ce bout de code n’est pas tout simplement bon à jeter à la poubelle, au lieu de passer du temps dessus pour grapiller quelques pourcents. Ton truc de modifier la structure de tes répertoires, c’est typique d’une fausse bonne idée : un répertoire c’est juste une liste de fichiers, et une liste de 10k éléments (×255 octets / noms de fichiers = 2,55Mo) c’est que dalle à l’heure actuelle. Si t’es limité par une aussi petite liste, c’est clairement que y’a une couille dans ton programme (ie. si t’as un problème d’IOs, c’est parce que tu fais des IOs à tort). Quand t’as 16Go de données, oui là tu peux mettre en place une stratégie de segmentation pour traiter par partie…
Pour SQL c’est encore pire. Dans tous les cas il ne faut pas préjuger du facteur limitant d’une application. Dans ma vie, j’ai connu exactement le contraire. Faut dire que j’ai travaillé sur des applis scientifiques (donc totalement limitées par le calcul) et du traitement batch de données dans la banque/assurance (donc masse de SQL en ce qui me concerne), où un problème d’IO a toujours relevé, très clairement, d’une mauvaise conception : car le principe de base dans mon domaine, c’est un accès/traitement/mise-à-jour totalement séquentiel et linéaire des données (l’enjeu sera de dimensionner correctement capacité de calcul et débits, et dans ce cas cela relève des choix de production). Si tu demandes un accès random, tu vas être à la ramasse sur les IOs, mais ton problème n’est absolument pas un problème d'IOs, le problème c’est l’accès random sur xGo de données…
Dans 99% des cas que je rencontre en pratique, c’est codé avec les pieds, avec un modèle physique de données inadapté (je plaide coupable : je normalise systématiquement pour privilégier la maintenance, ce qui multiplie les jointures…) et le compilateur, CPU, n’y peuvent absolument rien. Remet tes données à plat, maintien un journal des mouvements, traités en batch à postériori, comme on peut le faire dans le monde bancaire, tu va voir que les IOs ne seront plus ton (seul) problème. Ouah t’as optimisé un code sous-optimal ? La bonne affaire ! et si je le vire pour faire la même chose de manière autrement plus efficace ?
Bien que le constat ne soit pas joyeux, il me semble économiquement inévitable.
D'une part, à cause du rapport entre le coût de développement et le coût du matériel dans le contexte actuel. Si on doit choisir entre payer un développeur qualifié pour optimiser le code, payer pour avoir des machines plus performantes, ou laisser les utilisateurs passer une minute par jour à regarder des barres de progression, la première option sera rarement la plus avantageuse économiquement.
D'autre part, à cause de la place croissante de l'informatique dans nos vies : comme on peut (et doit) faire de plus en plus de chose avec l'informatique, les utilisateurs consentent à investir de plus en plus dans leurs équipements. Et, là aussi, s'ils doivent choisir entre attendre 10 secondes que leur appli se charge, renouveler leur téléphone plus souvent, ou utiliser une appli moins populaire mais mieux optimisée, c'est rarement la dernière option qui sera favorisée.
C'est triste et complètement contraire à mes valeurs, mais je ne pense pas qu'en général, on puisse blâmer les développeurs, car il s'agit d'un phénomène essentiellement économique.
# Who's that guy ?
Posté par Luc-Skywalker . Évalué à 2 (+2/-2).
J'ai regardé 1mn et je me suis posé cette question.
Après une rapide recherche j'ai trouvé çà: https://www.youtube.com/watch?v=OHnXY9F7m9c
Pas sur que ce soit pertinent, les censeurs décideront. Moi ça me va.
Quoi qu'il en soit, un peu de mise en situation m'aurait aidé à comprendre les tenants et aboutissants.
Bonne soirée malgré le moinssage.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Who's that guy ?
Posté par YBoy360 (site web personnel) . Évalué à 8 (+7/-1).
Je ne sais pas qui c'est :/
Pour le contexte,je n'aimais pas cette vidéo au début, d'une part parce que l'on parle de Visual Studio, et que ça sentait un peu le refrain du "C T mieux avant !".
Cela dit, il y a une partie de vrai dans ce qui est dit, et est généralisable, puis la dernière partie de la vidéo est intéressante : l'interviewé, essaie d'expliquer, pourquoi, aujourd'hui, certains logiciels sont devenus lents, affreusement lent, par rapport à ce qu'ils étaient début 2000.
Les arguments avancés (ça permet d'éviter de voir la vidéo, que je comprends, ne plait pas, mais tout va bien !) :
Voila, il y aurait pu y avoir un débat inter-générationnelle, pour ou contre les accolades en fin de ligne et tout.
[^] # Re: Who's that guy ?
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
OK, merci pour les précisions.
Du coup, j’interprète le moinssage comme le:
"on en a soupé"
Ce qui se comprend très bien ;)
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Who's that guy ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10 (+8/-0).
Perso, j'évite de moinsser (ce serait d'ailleurs intéressant de connaître les statistiques de son propre compte à ce sujet), mais il faut bien avouer que ma position est très claire vis-à-vis des liens youtube — appuyée par le fait que je ne compile pas de codecs vidéo sur mon pc, ou en tout cas pas adaptés à ça — « les liens youtube c'était mieux à l'époque où ça pointait vers des textes en UTF-8, voire en ascii. » :-)
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Who's that guy ?
Posté par sebas . Évalué à 10 (+8/-0).
Pareil pour moi, je vois un lien vidéo (surtout youtube, qui coumule les inconvénients de la vidéo avec ceux d'appartenir à google), je passe mon chemin (sans moinser).
Un texte, on peut le survoler pour voir ce qu'il vaut, une vidéo, c'est plus dur.
Un texte a souvent besoin d'être mieux pensé et mieux construit qu'une vidéo, qui est souvent plus immédiatiste. Attention, je dis souvent, parce que les textes mal torchés et les vidéos super-intéressantes, il y en a, et plus qu'à leur tour. Mais dans mon cas, quand je cherche des infos et des développement sur un sujet, je favorise toujours les textes et ne me rabats sur les vidéos que quand je n'ai pas le choix.
En fait, ici, l'idéal serait d'éviter les liens vers les vidéos et faire à la place un court journal résumant la vidéo et qui donnerait envie de la voir. Ou non. Ça permettrait d'avoir l'équivalent du survol du texte. Par exemple, le message de YBoy360 qui résume la vidéo aurait été bienvenu dans son entrée de lien (qui serait alors devenu un journal).
Mes 2 centimes
[^] # Re: Who's that guy ?
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+9/-0).
Casey Muratori est un programmeur que je qualifierai, entre autres choses et sans vouloir le limiter à cela, de militant en faveur de programmes plus efficaces. C'est loin d'être un clown et je lui attribue des qualités de pédagogue.
Il a notamment échangé publiquement avec Robert C. Martin au sujet du livre Clean Code de ce dernier, de l'impact négatif en termes de performance que les conseils du livre ont généré. Là où beaucoup de programmeurs dégagent un air prétentieux et supérieur en méprisant Clean Code, Casey a opté pour une approche critique en échangeant ouvertement et poliment avec le premier concerné : https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md
Il a aussi fait une vidéo sur le sujet des propositions de Clean Code : "Clean" Code, Horrible Performance, à nouveau très pédagogique.
Il est aussi plus ou moins à l'origine du concept de GUI en mode immédiat : Immediate-Mode Graphical User Interfaces.
C'est un peu dommage que le lien soit moinsé parce que le gars vaut le coup d'être écouté. Ce n'est pas son intervention la plus instructive mais un bon point d'entrée. Une citation de cette vidéo :
De mon expérience c'est tout à fait juste. Entre l'éducation universitaire qui pense en complexité algorithmique et en machine abstraite, l'industrie qui pousse pour des solutions vite implémentées pour pas cher en jetant des « Engineering time is expensive, memory is cheap », le délire de la montée en puissance considérée comme acquise, la culture du one-liner et le fantasme du compilateur qui optimise tout ; aucun doute que l'éducation des programmeurs va à l'opposé de l'écriture de programmes efficaces.
[^] # Re: Who's that guy ?
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Je ne pense pas qu'il faille opposé la complexité algorithmique et en mémoire sur la compréhension du CPU.
Les utilisateurs aussi poussent à cela.
Parce qu'elle l'est encore plus ou moins et l'a était pendant des décennies.
Souvent aussi poussé par le même genre de personnes qui ont une bonne maîtrise du CPU
Jamais entendu ça, j'ai entendu "si tu veux pas t'y intéressé plus, écris un code simple, ça aidera le compilateur".
La performance en informatique est immensément plus complexe que ce que la majorité des gens qui en parlent décrivent. Il y a un paquet de façon de comprendre ce qu'est la performance (amélioration de la latence, du débit, de la consommation de ressources, du temps d’exécution,…) et je n'ai jamais vu de critique prendre véritablement le temps de se poser sur ces questions, d'ensuite décrire comment est-ce qu'on mesure (Mozilla s'est cassé les dents à être plus rapide avec un ressenti plus lent que son adversaire) pour ensuite expliquer comment est-ce qu'on y parvient.
Dire que les gens ne comprennent pas les CPU c'est vrai je suis d'accord, mais c'est sauter à la conclusion, ils ne comprennent pas plus les IO par exemple, ni leur stack d'affichage,… selon ce qu'ils écrivent comme logiciel le CPU ne sera pas forcément le plus important.
Et la performance n'est pas le seul critère, la sécurité est très largement ignorée, on parle vite fait de performance, mais que ce soit avoir un code véritablement sûr ou supprimer les supply chain attack ça ne fait parler que vite fait quand un drame se produit sans pour autant dire qu'il y a de solution sûre à ce sujet. Il en existe pas, mais est-ce que c'est une bonne raison pour ne pas s'attaquer au sujet ?
Je suis personnellement beaucoup plus pour un processus d'amélioration où on pose la question de qu'est-ce qui est important (rapidité, efficacité, sûreté, réactivité,…) et qu'on regarde comment l'améliorer ou le maintenir dans le temps. Ça peut consister à connaître le CPU ou peut être à en faire tout simplement moins (et à considérer que des fonctionnalités n'ont pas leur place) ou tout un tas d'autres choses.
Clean code met l'accent sur la maintenabilité du code, lui reprocher son manque de performance est une évidence, c'est toujours une histoire de compromis. Personnellement tu ne me verra pas écrire un duff's device sans qu'il y ai un besoin absolument critique de cette ignominie.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Who's that guy ?
Posté par YBoy360 (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 17 décembre 2024 à 09:17.
Merci, pour moi ce qu'il dit est cathartique. Avoir le courage d’argumenter fasse au "ne pas faire de micro-optimisations" (ce qui est une bonne pratique "clean", qui se transforme en "ne pas les faire trop tôt …") est courageux, même si tout est question d’équilibre, il faut les faire en cas de gains significatifs.
Pour avoir fait beaucoup d'optimisation CPU, il est clair que la moyenne des développeurs ne se soucis plus d'optimisations et de spécificités d'architecture. Cela dit, les articles traitant d'optimisation CPU / GPU ont souvent du succès, même aujourd'hui.
l'IA, les Rust, Java et autres, prouve que l'on isole plus le compilateur, l'IDE, le langage et le HW. Et c'est très prometteur pour le future.
[^] # Re: Who's that guy ?
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Une de mes grandes fiertés de cette année, c'est d'avoir sur quelques mois :
et ainsi obtenu des gains de 50% de nos débits (sous charge sinon ça se voit pas) sur un pan assez important de notre logiciel.
C'est une illustration de ce que je décrivais, il ne faut pas opposé la complexité algo et le CPU, il faut les coordonner pour arriver au résultat que tu attends.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # à qui la faute?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
J'ai l'impression qu'on cadre beaucoup cette discussion comme si c'était (uniquement) un problème de compétence des développeurs. Je pense que ce n'est pas vraiment le cas, il y a plein d'autres choses qui rentrent en jeu.
La première, c'est que dans beaucoup de cas, les optimisations ne sont pas nécessaires ou pas prioritaires. Optimiser le code, concevoir l'architecture la plus efficace, ça prend du temps. Souvent, c'est plus important de livrer des nouvelles fonctionnalités très vite (avant les concurrents). Et en plus, on travaille avec des spécifications changeantes (les fameuses méthodes agiles), alors que pour faire de l'optimisation, il faut souvent pouvoir considérer un problème dans son intégralité pour bien déterminer la solution optimale. Si tu passes un mois à écrire la structure de donnée parfaite, mais que la semaine suivante, finalement ton programme doit faire autre chose, tu peux tout jeter et recommencer.
Il y a aussi une certaine tolérance des utilisateurs. C'est vrai en informatique mais aussi dans d'autres domaines. Par exemple, les téléphones mobiles modernes ont une latence plus importante que les anciens téléphones fixes à réseau par commutation de circuits. On s'est habitué, les usages ont évolué, et maintenant on arrive même à faire des visioconférences à plusieurs avec une latence encore plus importante. Il en va de même pour l'informatique, les gens développent une tolérance aux interfaces lentes et on peut se permettre d'être de pire en pire sans que ça fasse fuir tous les clients.
Du côté des développeurs, par contre, il y a quelques domaines où ça ne marche pas comme ça: le jeu vidéo, ou les systèmes embarqués/temps réel par exemple. Dans ces contextes là, il y a moins de problème pour passer du temps à optimiser les choses, il y a le budget pour, parce que sinon, le projet de marche pas.
Une solution serait de rendre les choses obligatoires. Pour la sécurité ça commence à se faire par exemple avec le Cyber Resilience Act qui va pousser les entreprises à assurer les mises à jour de sécurité. Du côté des performances, il pourrait y avoir des équivalents pour l'éco-conception (soit avec des obligations, soit avec un étiquettage/certification de type "nutri score"). En fait, c'est aussi déjà le cas dans certains domaines, les développeurs de frigo connectés sont très bons pour faire de l'électronique et du logiciel à basse consommation pour pouvoir afficher le score A++ en consommation d'énergie.
Au final, le problème ce n'est pas vraiment les développeurs, ce sont les clients qui ne veulent pas payer pour avoir des logiciels performants, ils préfèrent avoir un truc moins cher et livré plus tôt, et payer un peu plus de matériel. Là, une autre solution serait de rééquilibrer le coût du matériel (vraiment pas cher actuellement) et le coût du travail humain. Si les développeurs étaient payés moins cher, on pourrait leur faire passer du temps pour faire des économies sur le matériel. Ce n'est clairement pas l'équilibre actuel des choses.
[^] # Re: à qui la faute?
Posté par Thomas Douillard . Évalué à 8 (+5/-0).
Toute notre économie est tournée vers la production de masse au meilleur coût pour dégager un max de bénéfice, quel que soit le coût en certains autres termes qui ne comptent pas, les coûts environnementaux par exemple.
[^] # Re: Who's that guy ?
Posté par Zenitram (site web personnel) . Évalué à 2 (+3/-3).
Ceux qui essayent s'y brûlent, on perd du temps à améliorer le tout avec ses 2 machines de test, on déploie, bam perte de performance sur une machine ailleurs, on râle, puis on comprend que le meilleur compromis sur toutes les machines c'était celui fait par le compilo sur notre "mauvais" code, et on n'a pas l'argent illimité pour optimiser pour chaque CPU donc on se dit qu'on aurait dû faire comme les autres et ne pas chercher à optimiser car c'est de nos jours pas bien rentable.
(quoi? Oui, je suis en plein dedans en ce moment, je m'arrache les cheveux à tester plein de machines différentes, entre CPU et aussi GPU)
[^] # Re: Who's that guy ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Sans aller jusque là, on a énormément de cas où la consommation CPU / ram / I/O est absurdement élevée par rapport à ce qui est réellement fait.
Beaucoup de développeurs gagneraient à avoir ces ordres de grandeur en tête.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Who's that guy ?
Posté par Nicolas . Évalué à 2 (+3/-1).
Si ton optimisation n'est pas celle du compilo. y'a des chances pour que tu te sois foiré quelque part.
Pour avoir appris sur mon temps libre l'assembleur, je peux dire qu'il n'est pas si difficile d'optimiser un code. La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU (y compris les questions de latence sur les IO car ces accès sont explicites - et on distingue bien un accès en lecture et en écriture).
À partir de là :
L'exercice consiste à étudier la sortie d'un compilo sur du code simple.
Par obligation on est amené à réimplémenter des fonctionnalités très simple. Autre exercice : étudier comment la libc ou autres fait ça.
Spoiler alert : il y'a quantité d'optimisations qui ne sont pas déléguées au compilo. Alors à moins de considérer que les devs de la libc sont des branques…
Trois trucs avec le compilo :
Tu ne le maîtrises pas ni le contrôle. Alors à moins de délivrer qu'un binaire final, tu ne peux préjuger des optimisations appliquées. Les compilos modernes sont devenus horriblement complexes… et LENTS !
À force de déléguer on finit par avoir des CPUs complètement troués parce qu'on pense que la prédiction de branche automatique c'est bien plutôt que de prendre 5s pour signifier au CPU que ce code-ci sera l'exception et l'autre la règle (donc non optimiser un code nécessite pas d'avoir forcément un bagage technique de fou). Sur ce point la causalité est inversée : si c'est le foutoir dans les CPU à tel point qu'un dev n'est pas capable de prédire à l'avance quel code sera performant sur telle machine (manque de prédictibilité du matériel et absence de modèle simple du comportement d'un CPU), c'est bien parce que les concepteurs de CPU y vont chacun de leur petites trouvailles pour obtenir les meilleures perf. malgré du code claqué au sol. On retrouve la même blague sur le nombre de cycle horloge par instructions. Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que… "c'est trop compliqué un CPU".
Ce qui nous amène au dernier point : le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait. Seul l'usager sait ce qu'il va en faire et le boulot d'un dev. c'est aussi d'optimiser son temps, savoir quand et où il a intérêt à lever les automatismes et prendre en charge lui-même les micro-optimisations (car faut-il encore le rappeler une énième fois la micro-optimisation c'est que dalle en terme de gain de performance face aux choix de conception - sélection des algorithmes, arbitrage entre le besoin et les moyens, etc.) C'est pas la compilo qui va te dire si ton algo de tri doit être économe en espace ou en temps, si t'es données sont presque triées ou totalement aléatoire, etc. Il pourra toujours essayer de le deviner mais cela impliquera une surcharge qui ne sera pertinente que sur de gros volumes (information que le compilo ne connaît pas…).
[^] # Re: Who's that guy ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+4/-1).
Pas vraiment. Les CPU modernes:
Au final, l'assembleur est un langage de programmation comme un autre, il n'est même plus "proche du matériel". Donc autant choisir un langage plus confortable.
Faire du code optimisé pour un modèle de CPU, une taille de cache fixe, une mémoire avec une bande passante bien déterminée: facile.
Faire du code optimisé dans tous les cas, y compris pour des CPU qui ne sont pas encore fabriqués: impossible.
Ces optimisations dans les CPU sont ce qui permet d'avoir du matériel moderne qui continue d'exécuter le code existant avec de meilleures performances. Je trouve ça mieux que de dire "ah on a rajouté 1Mo de mémoire cache dans le nouveau CPU, mais tu dois réécrire tout ton code pour l'exploiter, parce que c'est à toi de dire explicitement quelles variables il faut stocker dans le cache".
Le problème est simple: il vaut mieux optimiser le temps de travail des développeurs, plutôt que quelques cycles CPU. Et donc, ne pas avoir à réécrire tout le code à chaque nouvelle génération de CPU, c'est bien.
C'est faisable, on peut donner à gcc une trace d'exécution du code et recompiler une deuxième fois, et il va ajouter automatiquement les instructiosn de prédiction de branchement. Est-ce que des gens s'embêtent à le faire? Non, parce que même cette procédure entièrement automatisée n'a aucun intérêt économique dans la plupart des cas. Le temps passé par le développeur à mettre en place ça va coûter plus cher que les 0.1% de performance qu'on va pouvoir gagner. Sauf dans quelques cas particuliers où ces micro optimisations vont faire la différence entre "ça ne marche pas du tout" et "ça passe de justesse", ou là, le développeur peut être payé très cher pour passer du temps à ce genre de choses.
Et de toutes façons le problème de l'optimisation n'est même pas là la plupart du temps. Il y a des problèmes beaucoup plus bêtes de mauvais choix de structures de données, ou de mauvaise utilisation de structures de données. Par exemple, faire plusieurs fois de suite une recherche d'un objet dans une map, au lieu de le trouver une fois et de garder une référence. Là on peut avoir des gains de plusieurs dizaines de % de performances, et ça peut être intéressant d'y passer du temps.
Et pour faire ce genre de choses, c'est plus facile si on travaille avec un langage haut niveau ou au moins qui propose un bon choix de structures de données disponibles dans sa bibliothèque standard (C++ ou Python par exemple). Sinon, le coût de développer ne serait-ce qu'une hash map n'en vaut peut-être même pas la peine.
[^] # Re: Who's that guy ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Il y a quand même des cas où le passage par l’assembleur reste efficace : c’est les codes qui peuvent massivement gagner en performances en utilisant énormément les instructions SIMD (SSE, AVX…) typiquement les codev vidéo (exemples : https://github.com/xiph/rav1e, https://code.videolan.org/videolan/dav1d).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Who's that guy ?
Posté par fearan . Évalué à 4 (+1/-0).
ça c'est ce que tu fais uniquement lorsque le reste n'a pas permis d'atteindre les performances nécessaire.
Et ça implique de devoir différencier les binaires selon la plateforme (processeur), au risque d'avoir un crash franc de l'application; une solution est de vérifier les capacité du proc et choisir la bonne fonction, mais c'est rarement fait dans le cas des développement particuliers.
typiquement https://code.videolan.org/videolan/dav1d ne tournerai pas sur mon ancien proc qui ne gérait que l'AVX, et non l'AVX2. C'est dommage car il serait normalement amplement suffisant pour le décodage des vidéos.
Ou pour faire plus simple, dans le but de rendre le truc performant sur les anciennes plateforme, tu a fais un code qui ne tourne plus dessus :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par fearan . Évalué à 6 (+3/-0).
Et encore tu oublies que pas mal d'appli doivent pouvoir tourner sur plusieurs archi mac, PC, téléphone, console… avec des spécificité propres.
Je ne compte plus le nombre de if(map.existe('machin')) { Plop zut = map.get('machin'); } que je trouve dans le code, ou les push_back sauvage dans un vecteur sans avoir réservé la taille nécessaire alors qu'elle est connue.
J'ai aussi trouvé des vérification de clé unique via un parcours dans tableau (non trié cela va de soi), lorsqu'on augmentait un peu la taille des données ça explosait le temps de vérification.
Y'a aussi la manie de garder le xml source de données qu'on reparse à chaque fois pour en récupérer une valeur.
Ouais avant de descendre à l'assembleur, inutile dans l'immense majorité des cas, se pencher sur le code, ses structures, et ses tâches sont bien plus rentable. Si on a pas de quoi instrumenter le code, un bon vieux debugger avec arret, print stack trace de tous les thread, continue, et on recommence, permet de facilement trouver là où l'on passe du temps (a vu de nez) (les mesure exacte ça reste mieux)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 17 décembre 2024 à 16:58.
de toute façon — me concernant — j'ai croisé plus d'applications I/O bound (le CPU passe son temps à attendre des données à traiter) que CPU bound…
bref, la gestion des perfs : un bon profiler de code pour savoir où tu passes le plus de temps et savoir organiser des tests/benchmarks avec des volumétries représentatives…. (mais c'est un autre métier que développeur en tant que tel)
[^] # Re: Who's that guy ?
Posté par Nicolas . Évalué à -2 (+0/-2).
La recherche des fichiers n’est pas si consommatrice. La structure des répertoires est très légères et, sauf le premier accès, va être pauvre en IO. Ce qui va se jouer c’est le syscall (permutation user-kernel mode), et les différents algo. en œuvre pour la résolution du chemin, la vérification des droits, etc. Par défaut, par exemple, la liste des fichiers est très souvent triée dans le monde Unix, au lieu d’être restituée dans l’ordre présent sur le disque (± l’ordre dans lequel ça a été écrit). Il y a de quoi accélérer tout ça, ne pas constamment demander au kernel une résolution de chemin encore faut-il y avoir accès (donc probablement qu’en
C?) et les connaître. Ça demande une compréhension fine du système, un profiler n’est qu’une aide qui ne répond que, très mal, qu’à une partie du problème. Au mieux du mieux, il te donne une piste sur les bouts de code à optimiser. Mais rien ne garantit que ce bout de code n’est pas tout simplement bon à jeter à la poubelle, au lieu de passer du temps dessus pour grapiller quelques pourcents. Ton truc de modifier la structure de tes répertoires, c’est typique d’une fausse bonne idée : un répertoire c’est juste une liste de fichiers, et une liste de 10k éléments (×255 octets / noms de fichiers = 2,55Mo) c’est que dalle à l’heure actuelle. Si t’es limité par une aussi petite liste, c’est clairement que y’a une couille dans ton programme (ie. si t’as un problème d’IOs, c’est parce que tu fais des IOs à tort). Quand t’as 16Go de données, oui là tu peux mettre en place une stratégie de segmentation pour traiter par partie…Pour SQL c’est encore pire. Dans tous les cas il ne faut pas préjuger du facteur limitant d’une application. Dans ma vie, j’ai connu exactement le contraire. Faut dire que j’ai travaillé sur des applis scientifiques (donc totalement limitées par le calcul) et du traitement batch de données dans la banque/assurance (donc masse de SQL en ce qui me concerne), où un problème d’IO a toujours relevé, très clairement, d’une mauvaise conception : car le principe de base dans mon domaine, c’est un accès/traitement/mise-à-jour totalement séquentiel et linéaire des données (l’enjeu sera de dimensionner correctement capacité de calcul et débits, et dans ce cas cela relève des choix de production). Si tu demandes un accès random, tu vas être à la ramasse sur les IOs, mais ton problème n’est absolument pas un problème d'IOs, le problème c’est l’accès random sur xGo de données…
Dans 99% des cas que je rencontre en pratique, c’est codé avec les pieds, avec un modèle physique de données inadapté (je plaide coupable : je normalise systématiquement pour privilégier la maintenance, ce qui multiplie les jointures…) et le compilateur, CPU, n’y peuvent absolument rien. Remet tes données à plat, maintien un journal des mouvements, traités en batch à postériori, comme on peut le faire dans le monde bancaire, tu va voir que les IOs ne seront plus ton (seul) problème. Ouah t’as optimisé un code sous-optimal ? La bonne affaire ! et si je le vire pour faire la même chose de manière autrement plus efficace ?
[^] # Re: Who's that guy ?
Posté par ff9097 . Évalué à 1 (+0/-1).
Quand tu fais du python ou du javascript c'est pas hyper essentiel non plus
# Est-ce bien un problème de développeur ?
Posté par sobriquet . Évalué à 1 (+0/-0).
Bien que le constat ne soit pas joyeux, il me semble économiquement inévitable.
D'une part, à cause du rapport entre le coût de développement et le coût du matériel dans le contexte actuel. Si on doit choisir entre payer un développeur qualifié pour optimiser le code, payer pour avoir des machines plus performantes, ou laisser les utilisateurs passer une minute par jour à regarder des barres de progression, la première option sera rarement la plus avantageuse économiquement.
D'autre part, à cause de la place croissante de l'informatique dans nos vies : comme on peut (et doit) faire de plus en plus de chose avec l'informatique, les utilisateurs consentent à investir de plus en plus dans leurs équipements. Et, là aussi, s'ils doivent choisir entre attendre 10 secondes que leur appli se charge, renouveler leur téléphone plus souvent, ou utiliser une appli moins populaire mais mieux optimisée, c'est rarement la dernière option qui sera favorisée.
C'est triste et complètement contraire à mes valeurs, mais je ne pense pas qu'en général, on puisse blâmer les développeurs, car il s'agit d'un phénomène essentiellement économique.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.