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.
[^] # Re: Who's that guy ?
Posté par barmic 🦦 . En réponse au lien Software is Way Less Performant Today. Évalué à 8.
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