Coucou c'est re moi, je viens pas pour faire la guerre, mais juste il faut que je vous dise que Casey a sorti une vidéo qui montre que faire du clean code ça fait du code lent https://www.computerenhance.com/p/clean-code-horrible-performance. Alors ça c'est ce qu'il dit mais je suis pas à 100% d'accord, car on peut avoir du code propre sans pour autant faire une hiérarchie de classes (d'ailleurs souvent composition > héritage) mais il a quand même raison sur le fond.
Si un débutant demande comment organiser son projet où il a différentes formes et il veut pouvoir faire tel ou tel chose sur la forme (comme calculer son aire), les pratiques de clean code auront tendance à lui suggérer de faire une classe abstraite "Shape" qui définit des fonctions virtuelles qui seront override par les shapes concrètes, comme ça on peut rajouter une nouvelle shape sans devoir mettre à jour tout le reste du code etc.
Contrairement à Casey qui est un peu extrémiste, je pense pas qu'il faille systématiquement rejeter tout concept moderne, mais au minimum, il faut savoir ce que ça fait et si ça ne posera pas de problème par la suite pour optimiser si nécessaire et pas juste se dire "j'ai un truc propre donc mon code est optimal". Quand vous suggérez aux débutant de suivre les bonnes pratiques, oui je dit pas que c'est mal, mais dites leur aussi que ce n'est pas le fin mot de l'histoire et qu'il si ils veulent faire un truc plus sérieux et aller plus loin pour obtenir un meilleur résultat, il faudra nécessairement qu'il se posent plus de question que ça (je dis ça sur le forum C++ car là on peut obtenir un bon résultat contrairement à d'autre trucs comme javascript ou python).
Après il faut pas prendre son exemple au pied de la lettre, il faut comprendre l'intention derrière. L'idée c'est que le clean code encourage à séparer les fonctions, avoir plusieurs classes, chacune dans son propre fichier etc, et le problème en faisant ça c'est qu'on passe à côté d'optimisations possibles. Ici tout le calcul peut se résumer en "constante * width * height". Encore une fois, je dit pas qu'il faut partir là dessus dès le début, je trouve même que c'est complètement idiot puisqu'il suffit qu'on veuille supporter des polygones et ça tombe à l'eau. Oui le passage du switch au tableau est trop aggressif, c'est le genre de chose qu'on aurait fait si on savait que la performance à ce niveau là était un problème et qu'on acceptait en connaissance de cause de restreindre les formes supportées.
Mais justement c'est pas ça que Casey veut montrer, toute l'idée de sa démonstration c'est que partir sur une classe Shape abstraite comme recommandé dans les bonnes pratiques par rapport à un simple switch, ça fait qu'on aurait pas immédiatement vu le pattern apparaître permettant l'optimisation avec le tableau (qui est donc 20x plus rapide). Encore une fois sur cet exemple, n'importe qui aurait pu triviallement faire l'optimisation, mais imaginez un gros projet avec des milliers de petites classes éparpillées dans plein de fichiers, on n'aurait probablement pas remarqué l'optimisation possible.
Ca c'est le premier problème mais il y a aussi le problème que quelqu'un à qui on enseigne que "ça c'est du code propre" fait qu'il sera complètement à l'ouest quand il s'agira d'optimiser etc, et il sera même surpris d'apprendre que son code propre génère un ASM abominable. Donc moi je rejette pas les pratiques modernes ni le fait d'enseigner comme ça aux débutants (d'ailleurs ça leur permettra sans doute d'éviter des bugs ou autre dans un premier temps), mais il faut quand même qu'ils aient en tête que oui peut être que le code est "propre" mais non il n'y a pas de quoi être fier de l'exécutable qu'on obtient car il est probablement moins bon que ce qu'il pourrait.
Et Vittorio c'est un petit rigolo ! https://twitter.com/cmuratori/status/1631045864558051328 Oui il obtient un truc 5x plus rapide que Casey puisqu'il évite de devoir déterminer dynamiquement le type de la forme mais le but était d'avoir les mêmes contraintes que la version clean code. Sinon tant qu'à faire autant faire le calcul en avance et juste afficher le résultat ça sera encore plus rapide (oh wait il l'a fait aussi https://twitter.com/supahvee1234/status/1631105700037382144)
Mais attendez vous avez rien vu et moi non plus, là on parle juste de performance mais Casey pousse le truc plus loin et affirme que c'est également mauvais pour l'architecture du code !! https://twitter.com/cmuratori/status/1631187145762443269
J'aimerais trop qu'il fasse une autre vidéo mais sur l'architecture parce que je suis pas sure de bien comprendre pourquoi le clean code est mauvais en architecture alors que c'est justement ce qu'il vise à faire bien.
Casey a juste découvert que la perte de perf, c'est l'éparpillement dans les caches
Un boost.Polycollection et c'est réglé: plus de cache miss, branch-predictor-friendly, et memes perfs (ou mieux? EDIT: mêmes avec un chouilla d'huile de coude pour compléter des algos qui manquent! https://godbolt.org/z/ej613jYhe ) que Casey qui a des Cercles à 2 paramètres au passages (mais tout va bien).
Et on a des variant aussi qui marchent bien (au détail de visit qui coute un chouilla, mais on le sait et il y a des alternatives...; et que comme Casey c'est moyennement ouvert aux évolutions, voire pas du tout)
La propreté du code n'a jamais été le vrai problème ici.
Bonne question. Voici une définition (tirée de "Clean Code" de C Martin)
Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language
I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.
Pour Casey et Jade, du "Clean code" est un code qui utilise massivement la POO, l'héritage, les fonctions virtuelles, etc. Ils confondent le but et les moyens.
Pour ca que Vittorio disait dans ses tweets que c'était juste un homme de paille.
A un moment de la discussion Casey montre une vidéo de lui en train de taper sa réponse et on voit que c'est super lent, donc une fois de plus, on remarque que le software moderne a un problème et que en 2023 on ne peut pas taper du texte en temps réel sur une machine capable de faire des milliers de milliards de calculs par seconde. Comment ça se fait que vous trouvez ça normal et que vous l'acceptez ? C'est bien la preuve qu'il y a un problème quelque part, comment se fait il qu'on en soit rendu à ce point où on peut même pas faire une tâche basique comme taper du texte c'est fou quand même.
edit : la discussion va partir sur l'architecture ohlala j'ai hâte de voir comment Casey va défendre son architecture (oui je reconnais et j'ai toujours reconnu que c'est moins "lisible" de faire du code ultra optimisé)
Il y a un aspect que tu néglige complètement (peut-être n'y es tu pas exposé): Le coût financier.
Oui, coder ca coûte cher, très cher selon la spécialité (par exemple un développeur VBA c'est minimum 450€ par jour).
Le code sale (par opposition au code propre), ca coûte des milliards chaque année, à maintenir des usines à gaz que peut de personne ne comprend, ce qui engendre des bidouilles (lire: du code encore plus dégueux) pour parvenir au comportement attendu, ce qui amène encore plus de complexité et donc plus de coûts de maintenance.
De plus, la part de logiciels qui requièrent des performances absolues, dans le monde actuel, c'est peanuts. La part des jeux vidéos (puisque ton gouroux préféré s'appuie la dessus) dans l'industrie informatique, c'est minime, juste le sommet de la partie émergée de l'iceberg.
Donc le code propre (supposé lent ?) maintenable et évolutif: Oui. Le code sale super performant, inmaintenable: Non.
Pourquoi ne pas retourner 50 ans en arrière: coder en assembleur. Ça te prends deux ans pour mettre au point quelque chose que tu coderais en deux semaines en langage "propre".
- Edité par PierrotLeFou 10 mars 2023 à 2:55:39
Le Tout est souvent plus grand que la somme de ses parties.
De plus, la part de logiciels qui requièrent des performances absolues, dans le monde actuel, c'est peanuts.
La part des jeux vidéos (puisque ton gouroux préféré s'appuie la dessus) dans l'industrie informatique, c'est minime, juste le sommet de la partie émergée de l'iceberg.
Oui c'est vrai que tous les logiciels ne sont pas des jeux et n'ont pas besoin de réagir dans la milliseconde mais du coup le problème à force de penser comme ça sans arrêt, c'est qu'on se retrouve à ne pas pouvoir taper du texte à vitesse humaine dans une interface en 2023, en sachant que vitesse humaine = ~10 caractères par seconde au mieux, ce qui est très très lent par rapport à la puissance d'une machine. Pourquoi vous n'admettez pas que les pratiques clean n'encouragent pas le code à être performant ? Prenez n'importe quel logiciel moderne il va forcément mettre 10 plombes à se lancer, à faire la moindre action, et va même probablement être bugué de partout, malgré les bonnes pratiques et le clean code. Donc peut être que ça veut dire que finalement ces pratiques ne produisent pas de si bons logiciels que ça. À l'inverse, les logiciels pensés en mode Handmade (https://handmade.network/) genre RemedyBG, 4coder, ..., sont fiables et performants. Ce n'est qu'un constat objectif !
Ce n'est pas la cleanitude de la pratique que l'on paie (genre vecteur VS new+delete (peut-etre... et sans oublier les crochets...)), c'est une feature en particulier, et ici: la possibilité d'avoir des points de variation dynamiques et extensibles. Et c'est le dernier point qui est payé: l'extensibilité. En langage SOLID, c'est l'OCP appliqué à l'OO.
Avec du code clean qui s'assoie aussi sur l'extensibilité dynamique (~> boost::poly_collection + un peu de magie template (qui vire l'OCP) + des classes (diantre!) avec des fonctions virtuelles (fichtre!)), j'avais des perf équivalentes, voire meilleures (c'est terrible les instabilités des mesures....) que les `union**`.
Pire, la solution propre est 2 fois plus rapide en `-Ofast -march=native` avec clang (et gcc aussi on dirait)... https://godbolt.org/z/8d6Ej8495
On attend toujours un code "sale" qui poutre un code "clean" de ta part, qui n'est pas dû à ton ignorance ou à une définition flou de "performance" que ton esprit unidirectionnel doit nous définir précisément (nombre de cycle ? délai entre la premier et dernier instruction ? GPU ? nombres de Watt consommé ? etc...)
Pour l'instant, tout cela, c'est du pipeau.
(Et comme ma définition d'un code "clean" est très lâche, j'ai toutes les chances de te poutrer avec un code que je considérerais comme clean et en utilisant la définition de la "performance" qui m'arrange, vu que les définitions précises, tu t'en fous, que ça servent aussi pour nous.)
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Je suis aussi cette discussion et j'avais peur (et le message de Jade me donne raison) que ce soit utilise par les idiots-fanboys de Casey pour dire "regardez, il a raison". Je vais pas ressortir l'image du pigeon qui chie sur un jeu d’échec mais l’idée est la : quoi qu'on dise, ça sera déformée pour correspondre a ce que les idiots-fanboys veulent entendre. (On voit le même comportement chez les idiots-conspis).
Pour ceux qui ont répondu a cette discussion, j'ai l'impression que vous n'avez pas lu la conversation entre Bob et Casey, non ? Sérieusement, ne vous fiez pas aux interprétations complètement a cote de la plaque de Jade, lisez la conversation. Bob dit explicitement que la performance n'est pas critique dans la majorité des cas et que c'est un compromis a faire entre les ressources de dev et les performances ("It is economically better for most organizations to conserve programmer cycles than computer cycles."). Il ne donne pas du tout raison a Casey, qui pense que les perfs passent avant tout. Ensuite la conversation continue sur les cas ou les perfs sont critiques, pas du tout le cas general.
A mon avis, Bob pèche par naïveté, en pensant pouvoir avoir une conversation intelligente avec Casey. (Ou ici avec Jade).
Un exemple d'argument idiot volontairement a cote de la plaque :
JadeSalina a écrit:
A un moment de la discussion Casey montre une vidéo de lui en train de taper sa réponse et on voit que c'est super lent, donc une fois de plus, on remarque que le software moderne a un problème et que en 2023 on ne peut pas taper du texte en temps réel sur une machine capable de faire des milliers de milliards de calculs par seconde. Comment ça se fait que vous trouvez ça normal et que vous l'acceptez ? C'est bien la preuve qu'il y a un problème quelque part, comment se fait il qu'on en soit rendu à ce point où on peut même pas faire une tâche basique comme taper du texte c'est fou quand même.
Pour ceux qui n'ont pas vu la video en question, il s'agit de GitHub.
Combien d'entre nous ont déjà utilise GH et n'ont jamais constate de probleme de performances ? J'utilise un ordi perso premier prix (300$ EDIT : 400$. J'ai change le DD d'origine pour un SSD) et j'ai pas de probleme avec GH. (A la rigueur, avec un RPi, je verrais un probleme de perfs).
Prendre cet exemple particulier comme argument pour dire qu'il y a un probleme général de performances dans les softs modernes, c'est juste con et de mauvaise foi.
Vous pouvez discuter autant que vous voulez avec Jade, mais ne vous attendez pas a avoir une conversation intelligente.
lmghs a écrit:
Ce n'est pas la cleanitude de la pratique que l'on paie
Jade a tres bien compris que les fonctionnalites ne sont pas les memes entre le code POO et le code de Casey. Il le dit lui meme :
JadeSalina a écrit:
je trouve même que c'est complètement idiot puisqu'il suffit qu'on veuille supporter des polygones et ça tombe à l'eau.
Jade a tres bien compris que ces 2 approches ont des fonctionnalités différentes et que cela impact les perfs.
La seule question pertinente est de savoir si Jade trolle volontairement ou s'il est juste complètement idiot.
Deedolith a écrit:
peut-être n'y es tu pas exposé
Jade ne bosse pas et ne veut pas. Il a déjà dit qu'il ne voulait pas, parce que les contraintes du monde pro l’empercherait de faire ce qu'il veut en termes de dev.
Donc il a très bien compris que ce qu'il raconte n'a aucun sens dans le monde du dev pro. Et que ce que fait Casey n'est pas du tout efficace pour réussir a sortir un logiciel qui fonctionne (Jade a déjà explique que c’était pas le but de Casey, qu'il faisait ça pour la pédagogie).
Bref, Jade a très bien compris que en dehors d'un dev qui fait des petits projets pour lui même, ses arguments sont complètement bidons.
Comme il a été dit, malgré tout le sujet est intéressant.
Même si d'entrée, à la PREMIERE PHRASE, ça parle de Casey.
J'ai toujours cette image : quand tu veux démontrer qu'un truc est mieux qu'un autre, tu en prends un autre pas bien fait.
Un code minimaliste avec du polymorphisme alors qu'il n'y en a pas besoin, c'est pas si propre que ça, je pense.
Souvent on voit des codes "chiadés" avec des std::map, des machins en amont les remplir efficacement, avec une complexité en O(log2(n)), et tu te dis que c'est optimal, alors que la map est une map de int avec des indices de 0 à n, et qu'un bête tableau de taille n serait plus efficace en complexité O(1).
.... mais mettre un tableau est encore plus propre, plus simple, plus efficace,...
Autre chose sinon :
Je veux bien croire que parfois un code mystique est plus efficace
Mais il faut garder en tête que seule une toute petite partie de code vaut le coup d'être optimisée de la sorte. C'est ce qu'on appelle une section critique : la ou il faut gratter au maximum, et dans un programme c'est une toute, toute petite partie. Le reste peut être optimisé mais avec du code propre ça va très bien.
Vous pouvez discuter autant que vous voulez avec Jade, mais ne vous attendez pas a avoir une conversation intelligente.
Pourquoi donc ? Elle est si stupide que ça ?
Il y a débat sur pourquoi les gens en arrivent à penser autant de travers (pas qu'en info). Problème d'éducation, de manipulation par d'autres, pour des raisons idéologiques plus ou moins volontaires et plus ou moins de mauvaise foi ? En tout cas, on ne peut pas exclure l'idiotie.
Pour Casey, c'est en partie parce qu'il est arrogant et donc ne peut pas se remettre en question et apprendre. Et en partie parce que c'est son business, il vend des vidéos et formations par l'effet de halo qu'il a, effet qui est renforcé en partie par son coté "anti-système" qui plait aux rebels en herbe.
Pour Jade, je sais pas. Mais l'idiotie me semble le plus probable.
Fvirtman a écrit:
quand tu veux démontrer qu'un truc est mieux qu'un autre, tu en prends un autre pas bien fait.
On est bien d'accord que le terme "démontrer" est incorrect, c'est juste de l'argumentation de mauvaise foi, qui ne convaincs que ceux qui sont déjà convaincu ?
Fvirtman a écrit:
Un code minimaliste avec du polymorphisme alors qu'il n'y en a pas besoin, c'est pas si propre que ça, je pense.
L'argument de Casey, c'est de dire que le "clean code", c'est du polymorphisme et que c'est ce qui est conseillé de faire. Et que lui fait du "non clean code" qui est plus performant. Alors que :
- sa définition de "clean code" est juste un homme de paille
- ce qu'il propose est une approche assez classique en C++.
La différence est qu'on va préférer les variant aux unions (plus safe) et le pattern visitor au switch (parce que c'est mieux encapsulé). Ca existe depuis longtemps dans le standard et encore plus longtemps dans boost (20 ans !). A la rigueur, on peut critiquer l'implementation de std::visit, mais l'approche en elle-même est assez classique. Alors que Casey présente ça comme une façon nouvelle et différentes de coder.
Fvirtman a écrit:
Mais il faut garder en tête que seule une toute petite partie de code vaut le coup d'être optimisée de la sorte. C'est ce qu'on appelle une section critique : la ou il faut gratter au maximum, et dans un programme c'est une toute, toute petite partie. Le reste peut être optimisé mais avec du code propre ça va très bien.
C'est ce qu'on explique tous a Jade depuis des mois. Et c'est ce que Bob dit aussi a Casey. Et c'est complétement l'opposé de ce que dit Casey ("la perf tout le temps").
Alors quand Jade dit que Bob est d'accord avec Casey, c'est quand même du beau foutage de gueule.
Le code propre c'est là pour simplifier le travail, améliorer la productivité (fournir du code maintenable qui marche, dans les délais)
Effectivement si on se permet des trucs crades, on peut gratter de la performances du code
Ça se fait aux dépends de la productivité des programmeurs (en temps de travail nécessaire pour réaliser une version plus rapide)
Donc l'intérêt est limité à certaines parties de quelques applications critiques
Autrement dit, la performance du code n'est qu'un facteur, il y a aussi le coût de développement. Faut tenir compte des deux, arbitrer, et ça dépend du contexte.
Donc, il faut se poser la question de ce qui vaut vraiment la peine. Exemple qui est donné : pour lire un fichier de configuration, ce n'est probablement pas le cas.
C'est le contraire, un code plus performant fournit le même service avec un matériel moins puissant et/ou en consommant moins d'énergie. Si on réfléchit au coût non pas dans la simple perspective du marché pour le client, mais en terme de coût pour la société en ressources utilisées, en pollution générée, alors optimiser peut avoir un intérêt... Après je suis d'accord pour dire qu'il ne faut pas tout optimiser, plus une portion de code est exécutée fréquemment, plus il faut y prêter attention.
@michelbillaud Donc la productivité du programmeur, ok, mais il y a aussi la productivité de la machine qui nous rend un service de calcul. Il faut prendre en compte les deux. S'il faut dépenser dix fois plus de temps et d'argent pour optimiser un code qui pourra tourner sur des machines 2 fois moins puissantes ou en consommant 2 fois moins d'énergie, ça peut vite valoir le coût (pas pour le client, mais pour la société dans son ensemble).
Pour illustrer je ne comprends pas pourquoi certaines app qui tournaient sans problème il y a 15 ans sur les premiers smartphones se sont mises à ramer de plus en plus, forçant les utilisateurs à racheter sans cesses de nouveaux modèles de téléphones... Je pense à google map, aux navigateurs web, même chose avec les PC. À moins qu'on soit gamer, l'utilisateur lambda, qui consulte et écrit des mails, navigue sur internet, utilise word et excel a besoin de quelle puissance de calcul ? Sans parler des systèmes d'exploitation qui sont devenus obèses. Au lycée on est équipé avec des i3, on peut perdre la moitié d'un cours à allumer les pc (merci windows) et lancer une app... Alors je ne connais pas Casey et je ne suis qu'un utilisateur lambda, mais je me demande s'il n'y a pas effectivement un problème de perf quelque part...
@michelbillaud Donc la productivité du programmeur, ok, mais il y a aussi la productivité de la machine qui nous rend un service de calcul. Il faut prendre en compte les deux.
Les deux. Ce qui est bien, c'est que c'est exactement ce que je disais, et je suis ravi que tu t'y mettes aussi, sachant que ce que tu racontais (et Casey), ça ne parlait que du côté machine.
S'il faut dépenser dix fois plus de temps et d'argent pour optimiser un code qui pourra tourner sur des machines 2 fois moins puissantes ou en consommant 2 fois moins d'énergie, ça peut vite valoir le coût (pas pour le client, mais pour la société dans son ensemble).
Avec des "si"... Où est-il le code en question ? Quel pourcentage ça représente du code qui est développé quotidiennement ? Plus de 1% ? Est-ce que ça justifie de proclamer que le clean code, c'est de la daube; et qu'il ne faut pas en faire pour les 99% qui restent?
Et quelle boite va multiplier son budget de développement par 10 "parce que c'est bon pour la planète d'économiser des cycles" ?
Pour illustrer je ne comprends pas pourquoi certaines app qui tournaient sans problème il y a 15 ans sur les premiers smartphones se sont mises à ramer de plus en plus.
Qui c'est "certaines apps" ?
On me dirait que les fabricants de téléphone, qui ont intérêt à en vendre un maximum, ne font aucun effort pour optimiser la version d'android (par exemple) qu'ils distribuent, que je ne serai pas étonné.
La dernière fois que j'ai changé de téléphone, c'est que la mise à jour par Samsung prenait tellement de place que je ne pouvais même pas installer d'autres applications que celles préinstallées.
Aussi : le code des jeux de smarphone, développés à l'arrache (ni propres, ni optimisés). Leur besoin: sortir le plus fréquemment possible de la nouveauté pour attirer le client, et lui balancer des vidéos de pub qui chargent le réseau, consomment du courant et plongent le pigeon dans les affres du consumérisme.
---
Sinon, on peut ajouter que le code écrit en C/C++/Java/cequevousvoulez est moins performant que de l'assembleur bien fignolé. Conclusion à en tirer ?
certaines app qui tournaient sans problème il y a 15 ans sur les premiers smartphones se sont mises à ramer de plus en plus
Encore une fois, c'est le problème de base qu'il y a dans l'article de blog de Casey : on compare des choses qui n'ont rien a voir. Les fonctionnalités proposées par un Windows, un Word, un Excel ou n'importe quel logiciel récent n'ont rien a voir aux équivalents de ces logiciels il y a 15 ans.
Regarde les services qui tournent en arrière sur Windows ou Chrome. Tu as de la reconnaissance vocale (je crois que Corona n'est pas désactivable), de l'indexation des fichiers, de la recherche de périphériques connectés, etc. Il y a 15 ans, tu devais attendre plus longtemps pour faire une recherche de fichiers, parce qu'ils n'étaient pas indexés.
C'est un peu comme si tu prenais une voiture et que tu ajoutais dessus une benne, un bras mécanique de pelleteuse, une rotative pour faire du béton, etc. Ta voiture va faire beaucoup plus de choses, mais elle fera 10 tonnes au final et sera un veau pour avancer. Pour autant, ca veut pas dire que le problème vient d'un manque d'optimisation du moteur.
Le problème dans l'attitude de Casey, c'est qu'il n'a aucune mesure dans sa façon de penser. Ce qu'il propose en gros, c'est d'optimiser encore plus le moteur de ta voiture, parce qu'avec tel réglage du carburateur, telle huile, etc. il va gagner en performance du moteur. Ce qu'on explique, c'est que c'est débile parce que ca va prendre du temps pour faire de telles optimisations et que c'est anecdotique (ca va faire gagner quelques % de puissance) et donc que ca changera rien au final (ta voiture fera toujours 10 tonnes et sera toujours aussi lente).
Que l'on soit d'accord ou pas sur les fonctionnalités proposées sur les logiciels modernes, les problèmes de performances des logiciels dont tu parles sont des choix de fonctionnalités, pas de problème d'optimisation (la majorité du temps). Chercher a optimiser chaque service ne fera gagner que tres peu de temps, très probablement que l'utilisateur n'aura aucun impact visible.
Ca n'a juste aucun sens de comparer des choses différentes.
(Et j'ai aussi un i3 sur mon ordi a 300$, avec 8Go de RAM. Et aucun problème pour démarrer et avec Chrome et google maps. Par contre, j'ai remplacé le DD par un SSD)
Umbre37 a écrit:
S'il faut dépenser dix fois plus de temps et d'argent pour optimiser un code qui pourra tourner sur des machines 2 fois moins puissantes ou en consommant 2 fois moins d'énergie, ça peut vite valoir le coût (pas pour le client, mais pour la société dans son ensemble).
Tu semble n'avoir aucune notion des gains de performances dont on parle. En réalité, les micro optimisations comme celles proposées par Casey vont apporter quelques %, voire moins de 1%. Ca arrive que des applications soient écrites avec le cul et soient sous performantes, mais il faut bien comprendre que plus une application va être utilisée, plus elle va avoir des moyens de devs importants et plus elle aura de chances d'être optimisée. (Même l'utilisation de langages interprétés ou de JVM ne sera pas forcement un problème)
Il faut bien comprendre qu'on est complètement sur une échelle différente en 15 ans. Quoi que l'on fasse, avoir des vidéos en ligne en 4k de nos jours, ca consomme plus d'énergie que les vidéos en 720p il y a 15 ans. Faire une recherche d'une fichier sur un disque de 10 To consomme plus d'énergie que faire une recherche sur un disque de 100 Mo. Faire une recherche sur internet de nos jours consomme plus qu'il y a 15 ans.
Mais c'est une erreur d'en conclure que c'est parce que les softs sont moins optimisés de nos jours. Casey est a coté de la plaque pour comprendre la problématique et donc les solutions qu'il propose (en plus du fait que ca n'a rien de nouveau) sont a coté de la plaque aussi.
Et regarde l'impact des choix de Casey sur le dev de son jeu. En terme de gestion de projet, c'est de la merde (10 ans et le jeu est loin d'être fini). Et visuellement, son jeu n'a rien d'extraordinaire (il est clairement pas plus performant qu'un jeu fait avec un moteur par exemple). On peut même pas dire "waouh, son jeu explose tout en terme visuel ou de performances, ses choix ont un impact réel sur la qualité".
Les deux. Ce qui est bien, c'est que c'est exactement ce que je disais, et je suis ravi que tu t'y mettes aussi, sachant que ce que tu racontais (et Casey), ça ne parlait que du côté machine.
Comment ça ce que je racontais ? Je n'ai rien raconté du tout moi, et je ne connais pas Casey, si ce n'est par ce qui en est dit ici sur le forum.
michelbillaud a écrit:
La dernière fois que j'ai changé de téléphone, c'est que la mise à jour par Samsung prenait tellement de place que je ne pouvais même pas installer d'autres applications que celles préinstallées.
Pareil pour moi. Effectivement je me demande s'il n'y a pas complot pour pousser toujours à acheter la nouvelle génération de téléphones et d'ordis.
gbdivers a écrit:
Encore une fois, c'est le problème de base qu'il y a dans l'article de blog de Casey : on compare des choses qui n'ont rien a voir. Les fonctionnalités proposées par un Windows, un Word, un Excel ou n'importe quel logiciel récent n'ont rien a voir aux équivalents de ces logiciels il y a 15 ans.
Je ne suis pas tout à fait sûr de cela. Je me demande si le problème ne vient pas aussi du nombre de couches, d'abstractions qui tournent les unes sur les autres, même si à chaque niveau le code est "propre" et "optimisé"... Cela vient peut-être aussi parfois de la qualité des algos, vous parlez de quelques % à gagner seulement, je veux bien le croire, mais est-on sûr de cela ? Y a-t-il des études sur le sujet ?
Au sujet des nouvelles fonctionnalités (je change de sujet, en laissant les perfs de côté). Le problème est que bien souvent je n'en ai pas besoin, que je n'ai rien demandé, mais que je suis quand même obligé de payer pour ça (les softs et le hard !). 99% de mes besoins pourraient être satisfaits avec un pc et des softs des années 2000 voire 90. La course à la puissance me semble parfois un peu absurde. Les videos en 720p me suffisent amplement. Ce que je voudrais c'est que les choses qui fonctionnaient continuent à le faire, sans avoir sans cesse à jeter et racheter (je ne parle pas de pannes, mais d'obsolescence programmée). J'ai un voisin, prof de philo à la retraite qui utilise des macros sur word sous XP pour écrire du grec, ça lui allait très bien... Jusqu'à ce qu'il soit contraint d'acheter une nouvelle machine (les navigateurs n'étaient plus mis à jours et la navigation devenait très difficile). Certaines personnes sont trop âgées pour apprendre à maîtriser de nouvelles technologies et sont victimes de cette fuite en avant.
Je ne connais pas le jeu de Casey. De quoi s'agit-il ? peut-être que le problème vient du dessin (a-t-il des compétences dans le domaine ?) et non des perfs du moteur en lui-même. Après s'il fait tout "from scratch" c'est normal que ce soit long. C'est peut-être la bonne méthode pour faire des petits jeux retros, mais pour un jeu plus gros, tout seul...10 ans ? Pas très surprenant. La vraie raison est peut-être autre : il aime concevoir les choses lui-même c'est tout. C'est certainement plus une question de plaisir que de qualité logiciel ou d'efficacité (même s'il prétend le contraire).
Les deux. Ce qui est bien, c'est que c'est exactement ce que je disais, et je suis ravi que tu t'y mettes aussi, sachant que ce que tu racontais (et Casey), ça ne parlait que du côté machine.
Comment ça ce que je racontais ? Je n'ai rien raconté du tout moi, et je ne connais pas Casey, si ce n'est par ce qui en est dit ici sur le forum.
Je me suis peut être un peu embrouillé :-)
gbdivers a écrit:
Encore une fois, c'est le problème de base qu'il y a dans l'article de blog de Casey : on compare des choses qui n'ont rien a voir. Les fonctionnalités proposées par un Windows, un Word, un Excel ou n'importe quel logiciel récent n'ont rien a voir aux équivalents de ces logiciels il y a 15 ans.
Je ne suis pas tout à fait sûr de cela. Je me demande si le problème ne vient pas aussi du nombre de couches, d'abstractions qui tournent les unes sur les autres, même si à chaque niveau le code est "propre" et "optimisé"... Cela vient peut-être aussi parfois de la qualité des algos, vous parlez de quelques % à gagner seulement, je veux bien le croire, mais est-on sûr de cela ? Y a-t-il des études sur le sujet ?
Un des problèmes, c'est le code
qui existe depuis très longtemps
qui avait été "optimisé" par des "astuces géniales" (de goret) à l'époque
et dont les objectifs ont évolué depuis.
non seulement les "optimisations" sont à côté de la plaque, mais c'est un frein à l'évolution de l'existant : faut faire avec le merdier parce qu'on n'a pas le temps de défaire et refaire, et le résultat n'est ni joli, ni optimisé, finalement.
non seulement les "optimisations" sont à côté de la plaque, mais c'est un frein à l'évolution de l'existant : faut faire avec le merdier parce qu'on n'a pas le temps de défaire et refaire, et le résultat n'est ni joli, ni optimisé, finalement.
A cote de la plaque, pas forcément. Peut être sur du code vieux de 30 ans, mais j'ai jamais rencontré de code old school qui était intrinsèquement sous performant. C'est surtout des problèmes de maintenabilité du code et de mises à jour.
Ce qui peut avoir un impact sur les performances, pas parce que l'ancien code était mauvais (il peut être correctement optimisé pour l'époque où il a été écrit) mais parce qu'il empêche d'utiliser les nouvelles fonctionnalités des ordis modernes.
Un exemple concret que j'ai déjà rencontré, c'est un logiciel de décodage et rendu vidéo, qui faisait tout en software. Ce qui était ok à l'époque et le code ne semblait pas présenter en lui même de problème de performances, pour un décodage/rendu software. Mais il était impossible a faire évoluer, pour utiliser du décodage (nvdec) et rendu (opengl) hardware.
Umbre37 a écrit:
Je me demande si le problème ne vient pas aussi du nombre de couches, d'abstractions qui tournent les unes sur les autres, même si à chaque niveau le code est "propre" et "optimisé"...
Difficile à dire, parce qu'on peut pas faire des généralités sur un truc aussi vaste. Certaines couches peuvent ralentir le soft, c'est sur. Mais dans ce cas, un gros boulot est fait pour justement minimiser ce coût.
Si on prend par exemple la couche système pour la mémoire virtuelle, forcement que cela a un cout. C'est physiquement impossible de faire autrement. Mais mais ca permet d'avoir des logiciels qui arrivent a tourner même quand la mémoire est saturée. Il y a 20 ans, quand tu n'avais plus de mémoire, ton application crashait. Si c'était pendant l'écriture d'un fichier, tu pouvais perdre toutes tes données. Si c'était une app système, tu pouvais avoir un blue screen et même parfois devoir réinstaller windows.
C'était clairement pas mieux. Et ceux qui ont déjà perdu des heures de travail a cause d'un crash ne regrettent pas ce bon vieux temps.
Umbre37 a écrit:
Cela vient peut-être aussi parfois de la qualité des algos, vous parlez de quelques % à gagner seulement, je veux bien le croire, mais est-on sûr de cela ? Y a-t-il des études sur le sujet ?
Pas d'étude (je n'ai pas cherché) mais l'expérience pro. En général, on sait très bien les parties du code qui vont être critiques (une string pour le titre d'une fenêtre ne le sera pas. Une string pour représenter les 100To des génomes connus, ça le sera). Ca arrive souvent qu'on implémente un nouvel algo plus performant et en général, on s'attend pas à des perfs qui vont être x2 ou x3. (Sauf cas critiques, qu'on connait en général a l'avance). Et quand on a un problème d'implémentation sous performantes, on le voit généralement très vite. (Idem, en fonction de la criticité).
Mais probablement que le critère le plus important au final, c'est ce que fait la concurrence. Si un concurrent fait un logiciel qui est 2-3 fois plus rapide, on perd des clients et donc on bosse pour optimiser notre propre soft, pour essayer de faire pareil que la concurrence. (Remarque sur Casey : comme son jeu est pas sorti, personne ne peut vérifier si ce qu'il dit par rapport aux performances est concret ou si c'est juste du vent. Et c'est les benchs tout moisis qu'il présente dans son article qui va convaincre beaucoup de monde).
Donc juste ça : dans la pratique, on voit rarement des nouveaux algos/implémentations qui déchire tout. (J'exclue bien sur les évolutions matérielles)
Umbre37 a écrit:
Au sujet des nouvelles fonctionnalités (je change de sujet, en laissant les perfs de côté). Le problème est que bien souvent je n'en ai pas besoin, que je n'ai rien demandé, mais que je suis quand même obligé de payer pour ça (les softs et le hard !). 99% de mes besoins pourraient être satisfaits avec un pc et des softs des années 2000 voire 90. La course à la puissance me semble parfois un peu absurde. Les videos en 720p me suffisent amplement. Ce que je voudrais c'est que les choses qui fonctionnaient continuent à le faire, sans avoir sans cesse à jeter et racheter (je ne parle pas de pannes, mais d'obsolescence programmée). J'ai un voisin, prof de philo à la retraite qui utilise des macros sur word sous XP pour écrire du grec, ça lui allait très bien... Jusqu'à ce qu'il soit contraint d'acheter une nouvelle machine (les navigateurs n'étaient plus mis à jours et la navigation devenait très difficile). Certaines personnes sont trop âgées pour apprendre à maîtriser de nouvelles technologies et sont victimes de cette fuite en avant.
Alors, pour faire une réponse directe et franche : on s'en fout de toi. (Déso)
Plus précisément, si un service fournit du 720p et qu'un concurrent fournit du 1080p et que tous les clients vont vers le concurrent, alors tu fais en sorte de proposer aussi du 1080p. En fonction de la demande. Si quelques personnes sont préfèrent le 720p, alors osef. Elles suivront le mouvement.
On est plus sur une problématique de programmation mais sur des questions marketing. Et le critère est de savoir l'impact économique des choix. Pas les avis particuliers de quelques personnes.
Et pour l'obsolescence programmée, tu le dis toi même : "sans cesse à jeter et racheter". Quel est l'intérêt pour un constructeur de se focaliser sur ceux qui ne rapporte pas d'argent. Le développement de nouvelles fonctionnalités coute de l'argent. Il faut bien que ce cout soit amorti financièrement. Et ca peut être que par ceux qui renouvellent leur matos et achètent les nouvelles versions.
L'obsolescence programmée est juste au final de proposer de nouvelles choses qui va intéresser les gens, de façon à les faire dépenser de l'argent.
Umbre37 a écrit:
Je ne connais pas le jeu de Casey. De quoi s'agit-il ? peut-être que le problème vient du dessin (a-t-il des compétences dans le domaine ?) et non des perfs du moteur en lui-même. Après s'il fait tout "from scratch" c'est normal que ce soit long. C'est peut-être la bonne méthode pour faire des petits jeux retros, mais pour un jeu plus gros, tout seul...10 ans ? Pas très surprenant. La vraie raison est peut-être autre : il aime concevoir les choses lui-même c'est tout. C'est certainement plus une question de plaisir que de qualité logiciel ou d'efficacité (même s'il prétend le contraire).
Il a des graphistes dans sa boite. Donc pas un problème de compétences en dessin. C'est juste que c'est un jeu qui date d'il y a plus de 10 ans.
Et oui, il aime concevoir les choses lui même. Et on a le droit d'aimer le rétro. Mais dans ce cas, on prétend pas que SA façon de développer un logiciel est la BONNE méthode et que tout le monde devrait faire pareil. Je lui reproche pas de faire un jeu pourri en 10 ans. Je lui reproche de prendre ça comme un exemple a suivre pour le développement en général. (Dans la conversation avec Bob, ils parlent pas que de jeux rétros, mais de softs modernes, comme Word ou Visual Studio).
C'est le coté tres arrogant de Casey : croire que son avis est supérieur a tout le monde. Il a même sorti que les gens du comité C++ ne savent pas dev (alors que certains sont plus anciens et expérimenté que lui, dans de nombreux domaines d'utilisation des logiciels)
Pour ce qui est du greenIT, quand on programme pour faire de 100% CPU, on peut difficilement éteindre des coeurs.
Les "anciens" appareils ont des performances énergétiques par instructions calamiteuses par rapport aux nouvelles architectures (sauf pour ces couillons de g@mers).
La performance, ce n'est pas que des cycles d'horloge, bordel.
Le time to market est bien plus important que l'ego du développeur d'avoir utilisé une astuce qui ne fonctionne que dans 0.001% du temps critique, sur 1% des matériels qui datent de plus de 3 mois (ou 10 ans dans le cas du jeu de Casey).
- Edité par bacelar 12 mars 2023 à 23:08:10
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Les "anciens" appareils ont des performances énergétiques par instructions calamiteuses par rapport aux nouvelles architectures (sauf pour ces couillons de g@mers).
Je ne suis pas contre le progrès technique non plus. Encore heureux que les nouveaux processeurs consomment moins par instruction que les anciens. (pourquoi pas pour les gamers, j'ai pas compris ?)
gbdivers a écrit:
Alors, pour faire une réponse directe et franche : on s'en fout de toi. (Déso)
Je sais bien que c'est le marché qui compte, et pas mon usage marginal. Mais justement, ce que je dis c'est que cette logique de marché nous emmène dans le mur, notamment d'un point de vue écologique, et aussi que ça isole des gens qui parfois ne peuvent pas suivre. (et ça impacte peut-être aussi les perfs, même si ça se discute et que la concurrence pousse parfois à chercher justement plus de perfs, comme tu l'as dit, mais parfois le marché pousse juste à dev n'importe quoi n'importe comment le plus vite possible). Peut-être qu'il faudrait moins de marché et plus d'Etat, parce que l'impact sur la société est trop important, ce devrait être une question politique aussi. Dire le marché impose telle pratique et donc ça ne peut pas être autrement, ça ne me semble pas juste non plus. On peut aussi considérer les choses sous un autre angle que le fric. Mais je m'éloigne du sujet de départ. C'est juste pour discuter . Merci pour vos réponses, c'est très intéressant. Bonne soirée à tous !
@Umbre37: > Certaines personnes sont trop âgées pour apprendre à maîtriser de nouvelles technologies Certaines, ouais ... merci pour moi. Et puisqu'on parle de nouvelles technologies "inutiles", que dire du Lidar sur le iPhone 14 pro qui fait de la reconnaissance de forme surprenante avec l'appli Seeing AI. Mais comme tout le monde l'a dit, on s'en fiche
Le Tout est souvent plus grand que la somme de ses parties.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Si vous ne trouvez plus rien, cherchez autre chose.
Discord NaN. Mon site.
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.