Julien Jorge a écrit 528 commentaires

Je suis un peu entre-deux au sujet des jumbo builds. Mon expérience me dit que c'est vraiment efficace pour réduire les temps de builds, et j'apprécie quelques effets comme l'idée de ne pas mettre de using namespace à un niveau global. D'un autre côté ça vient avec son lot de surprises que tu as très bien décrites dans ce billet.

Au niveau des intérêts il y a aussi une réduction des temps de link (i.e. ce n'est pas qu'une question de parsing de headers). Par exemple, dans un code plein de templates, on se retrouve avec ces derniers instanciés avec les mêmes types dans plein de .o, puis le linker doit faire le tri dans tout ça. Avec un unity build il n'y a qu'une seule instanciation du template dans le gros .o, ce qui est plus simple à gérer pour le linker (en plus de ne pas avoir à charger 2000 .o en premier lieu). Je n'ai pas mesuré mais je serais surpris que cela ne soit pas un avantage dans le cadre de LTO aussi.

Mon top des trucs pénibles serait les #include manquants qui cassent le build incrémental, les fonctions static avec le même nom et la même signature dans plusieurs .cpp, et des #define qu'on retrouve dans plusieurs .cpp aussi. Ce sont les premiers problèmes que je rencontre quand je passe un projet en unity builds.

Et puis il y a aussi le problème des devs qui s'en fichent pas mal : « Le build est lent ? Achète plus de machines, et des plus grosses. Moi je continue à mettre des using namespace partout et à mettre mes templates sans instanciation explicite. »

Au final on se retrouve à faire deux builds, un incrémental et un jumbo, pour être sûr que ça fonctionne dans tous les cas, et je me demande si on y gagne vraiment :)

unity build implies a slight overhead during incremental builds

Ça dépend du projet ! Même en dev quotidien, en recompilant avec quelques fichiers modifiés ici et là, ça peut aller plus vite de passer par un unity build.

J'aurais misé sur une histoire d'aliasing aussi mais vu que les valeurs des paramètres ne sont pas modifiés par les appels je ne vois pas comment ça pourrait être un problème.

Est-ce que ça pourrait être l'inlining ? Si le compilo considère que ack peut être « inlinée » dans ackermann, est-ce qu'il n'essaye pas aussi d'inliner les appels récursifs dans la foulée et conclut que ça ne passe pas ?

En tout cas je me dis qu'on fait peut-être un peu trop confiance au compilateur pour les optims. Ça vaut le coup de vérifier l'assembleur émis :)

Intéressant, mais pourquoi le compilateur a-t-il du mal à générer le même code ?

Pour les jeunes qui se demandent encore comment on en est arrivé là, je recommande l'excellent How to invent everything de Ryan North. On y apprend à fabriquer un ordinateur, mais aussi à produire de l'électricité, fabriquer du plastique, extraire des métaux, fabriquer une machine à vapeur, du charbon, un four, trouver des antibiotiques, sélectionner les plantes et animaux pour se nourrir efficacement, inventer la température… Bref, tout ce qu'il faut pour construire notre belle civilisation. À garder près de soi lors du grand reboot.

Je pense que tu n'as pas compris ce qu'elle critique, tout comme ceux qui ramènent ça à la somme des gains. Une grosse somme gagnée pour peu d'efforts, qu'elle aurait pu reverser aux assos. Ce n'est pas le sujet.

Ce que Blanche Gardin critique, ce ne sont ni les montants ni leurs proportions. Ce qu'elle critique c'est l'ensemble de ce qu'est la sociéte Amazon.

C'est son avis, elle a un moyen de l'exprimer et en profite. Peut-être se trompe-t-elle ? Si ça se trouve Amazon c'est plutôt une bonne chose ? Malheureusement ce n'est pas la question pour les habituels clowns d'internet qui vont plutôt la tacler en fantasmant un manquement à son intégrité supposée. Eh j'suis sûr qu'elle a déjà commandé un truc sur Amazon ! Et même qu'une fois elle a fait un truc sur le web et sa requête est passée par AWS ! Non mais pour qui elle se prend…

Oui, enfin je n'ai pas fait le diff :) Perso ça m'embêtait de lire le texte de l'article alors que l'info qui m'intéressait est la lettre de l'auteure.

En cherchant sur Google je n'ai trouvé que des articles du même genre : « Blanche Gardin à dit un truc sur Facebook ». C'est un peu le zéro de l'info à mon avis, et puis je trouve que les incises des auteurs de ces articles orientent la lecture, ce que je souhaite éviter.

Après c'est Facebook, et tous les problèmes qui vont avec, mais c'est le support qu'elle a choisi, donc soit.

Pour ceux qui veulent lire le message de Blanche Gardin plutôt qu'un article qui dit que Blanche Gardin a écrit un truc, c'est publié sur son compte Facebook.

On pourra débattre de la question de publier une lettre ouverte sur une plate-forme fermée, ou laisser le messager de côté et discuter du contenu :)

Mais bon, pour ma part, tant qu'à acheter en ligne, je vais direct sur lalibrairie.com, qui fonctionne avec des librairies physiques. Pour le choix ou la recherche des livres, babelio.

Ma seule expérience avec lalibrairie.com était plutôt négative. J'ai reçu ce mail :

Nous avons procédé le 08/07/2022 à l'expédition de votre commande lalibrairie.com.

Celle-ci sera à votre disposition dans un délai de 24h à 48 heures chez votre point libraire.

La commande est arrivé 12 jours après :( Entre temps j'ai du faire des aller-retours chez le commerçant. « Toujours pas arrivé ? Ah bon, parce que j'ai pourtant le mail de confirmation… ». Commerçant antipathique qui plus est.

Maintenant pour les livres c'est Recyclivre, Momox Shop, ou Rakuten. Et s'il n'y a pas, Amazon. Au moins avec ceux-là ça arrive vite et le livreur est sympa.

Je crois que ce que Zenitram veut dire avec sa remarque sur le patch en GPLv3 est qu'il y a un petit truc qui coince sur la double licence et les contributions externes (mais pas pour slint, j'y reviens plus bas).

Si je soumets du code en GPL car j'adhère à l'idée que je donne parce que le receveur donne aussi en échange, c'est à dire que personne ne s'approprie le travail des autres et qu'on contribue ensemble à créer quelque chose pour tout le monde ; alors je ne vois pas comment ce code que j'ai écrit et partagé peut se retrouver dans un produit fermé. Ça va à l'encontre de l'intention initiale.

Pour slint c'est un poil différent car il est bien indiqué dans le contributor license agreement que le contributeur cède des droits de redistribution sous les termes d'autres licences :

2.3 Outbound License

Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses.

À partir de là peu importe l'intention du contributeur.

Cette nouvelle version m'a l'air au poil.

Tiens j'aimerais bien avoir ton point de vue sur cette histoire de rémunération via les articles.

De mon côté je ne publie plus sur Medium et je n'ai pas l'intention de retourner vers un autre site proposant d'héberger mes articles en dehors de LinuxFr.org. Globalement j'en ai un peu ma claque des bandeaux cookies, du tracking, des paywalls, etc. J'ai récupéré à peu près tout ce que j'ai publié sur différents sites et j'ai tout ramené sur un serveur que je gère. Alors certes ça me coûte pas loin de 5 € par mois mais au moins je n'ai plus l'impression de contribuer à un web qui me déplaît. Et surtout, quand ces sites fermeront, j'aurais toujours mes articles.

Avant cela je me suis posé la question de passer en mode rémunéré sur Medium, avec un article qui tire dans les 300 vues par semaines depuis des années il y a peut-être moyen de gratter quelque chose, mais finalement j'ai fait demi-tour. En fait je ne suis pas auteur moi, si je fais des articles c'est pour échanger, discuter, avoir un peu de feedback, profiter de l'expérience des autres, contribuer de mon humble expérience, m'améliorer, apprendre des choses…

Et toi, qu'est-ce qui te motives à écrire ? Pourquoi Medium ? Que feras-tu quand tu seras riche ?

Ce billet est très plaisant, merci pour le partage :)

Ton commentaire est inutilement agressif. Était-ce une tentative d'humour ?

C'est intéressant que tu lui trouves de la mauvaise foi, je trouve au contraire qu'il est de bonne volonté :) Il me semble bien documenté, a clairement lu le livre, et il a regardé les présentations d'Uncle Bob. Il y a beaucoup d'aller-retours au début de la discussion avec des listes de logiciels mais non pas parce qu'ils sont lents, plutôt pour s'assurer que les deux parlent du même type de logiciels. La question étant : qu'est-ce qui a besoin d'un niveau de performance à la nanoseconde, a la milliseconde, ou plus. J'aime beaucoup l'approche d'Uncle Bob aussi, qui distingue le niveau de perf en fonction de la fonctionnalité (i.e. la fenêtre de préférences de Chrome n'a pas besoin d'une réactivité folle, mais le rendu d'une page web doit être le plus efficace possible).

Je ne sens pas de fort désaccord entre les deux. L'un comme l'autre considère que la perf est importante, tant d'un point de vue algorithmique que d'implémentation, et j'en ressors plutôt que l'intention d'Uncle Bob avec Clean Code était plutôt d'améliorer la clarté des parties non impactantes sur les perfs, pour les programmeurs de tous les jours. C'est un peu dommage que ça ait été interprété comme la méthode de développement à appliquer par défaut.

Ça vaut le coup de lire aussi la discussion qu'il a eu avec Robert C. Martin, l'auteur de Clean Code, le livre qui a posé les bases de ce qu'on appelle du code "clean" : https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md

Je suppose que l'une des prochaines optimisations sera d'utiliser stringview pour éviter les copies?

Tout à fait, c'est la prochaine étape :)

Bonnes remarques, je vais ajouter les infos dans les posts. La commande perf mesure donc les cycles, sur l'ensemble du programme (y compris le chargement du fichier donc). Par contre le temps rapporté dans les tables et représenté sur les graphes correspond au temps de traitement de l'input après qu'il ait été entièrement copié dans une std::string. Il n'y a donc pas d'IO dans ces métriques.

Est-ce que les mesures faites avec perf prennent en compte uniquement le temps cpu utilisé?

Il me semble que perf compte juste des événements, sans notion de temps. Par défaut il compte les cycles CPU.

Il y a des trucs à gagner avec les streams oui. J'en parlerai dans un futur billet mais ce n'est pas encore dans le top des trucs coûteux.

(note: le lien est indiqué en français, mais il est en anglais)

C'est corrigé, merci :)

Je pense qu'il y a plusieurs raisons pour que le type « tableau associatif » du C++ soit un arbre binaire plutôt qu'une table de hachage. Entre autre choses il faut voir que cela date du début des années 90, quand il n'y avait même pas de standardisation du langage. Ensuite il faut voir qu'un arbre binaire c'est intellectuellement plaisant, et les gens qui ont produit la base du C++ à cette époque étaient plutôt intellos, du genre à considérer que tous les algos en O(n) se valent. À côté de ça une table de hachage c'est un peu bête : c'est juste un gros tableau. Et encore ça ne résout que la moitié du problème puisqu'il faut en plus lui donner une fonction de hachage rapide et avec peu de collisions. Pas simple. Dans le pire des cas on a une recherche en O(n) (toutes valeurs ont le même hash), là où l'arbre binaire est en O(log(n)) (qu'on va déguiser en O(1) en le qualifiant d'« amorti »).

C'est déjà overkill puisque cela couvre des cas non nécessaires :)

Mais cela n'est pas équivalent puisque la version originale retourne la chaîne alors que toi tu l'affiches directement :)

Idem, je suis un fervent défenseur de l'utilisation (raisonnée bien évidemment) des goto, des variables globales, et même du code à plat.

Je ne connaissais pas cet exemple, ça fait 10 minutes que je boucle entre « c'est pourri » et « c'est parfait » :D D'un côté c'est très répétitif et on a envie d'y mettre une boucle, de l'autre côté c'est tellement simple qu'on comprend l'intention au premier coup d'œil.

Lisez bien les commentaires : les vraies corrections (la partie && pourcentage <= est inutile, et il affiche la barre complète alors qu'on n'est qu'à 91%) sont arrivées bien tard dans la conversation.

Mmmh on ne va pas sortir trop tôt si on enlève le && percentage <= ? J'aurais plutôt enlevé le percentage > x &&.

Pour la barre complète à 91% je pense que ça peut s'expliquer par un ressenti utilisateur. Vaut-il mieux afficher 100% dès 91% (et l'utilisateur se demande « bah alors c'est fini ou pas ? » pendant 10%) ou rester à 0% jusqu'à avoir atteint 10% (et l'utilisateur se demande « bah alors ça commence ou quoi ? » pendant 10%) ?

Ça permet de commenter les objets mais pas les champs. Le commentaire que tu as mis au dessus de buffer sera placé ailleurs selon que l'outil utilisé pour afficher le Json réordonne les clés ou pas.

Très intéressant :) Sur le sujet des données embarquées dans le binaire, as-tu regardé les travaux de JenHeyd Meneide ? Il semblerait que l'approche xxd soit la plus chère en temps de compilation.

Concernant cette histoire de bitcoins, je crois que c'est un problème qui va au delà de la monnaie ; c'est à dire que les réactions seraient les mêmes si GIMP avait reçu directement un million d'euros de dons.

Vous pourriez décider de dépenser le million en un salaire confortable pour, au hasard, le principal développeur, qui en plus a un impact positif et énorme sur la visibilité et l'image du projet. Sans partir dans des sommes énormes, lui donner une rémunération semblable à celle d'un poste équivalent dans une entreprise classique permettrait de le sécuriser pendant quelques années. Ça ne me semblerait pas déconnant mais je suis certain que vous vous feriez lyncher :)

C'est un peu un problème dans le libre qui marche. Vu que c'est un grand projet communautaire avec plein de contributions, il y a cette règle implicite que ce que tu reçois de la communauté doit repartir dans la communauté. Ça doit repartir quasiment tel quel ; le fait d'améliorer le logiciel n'est pas considéré comme un vrai retour, puisque de toute façon il aurait été amélioré même sans les dons.

Si quelqu'un tire un bénéfice des dons, tel que pouvoir en vivre, la question se pose de pourquoi cette personne et pas une autre. Pourquoi les sous n'iraient pas directement aux fondateurs du projet ? Pourquoi ça n'irait pas à telle autre personne qui, certes, soumet moins fréquemment des patchs, mais résout des problèmes sacrément difficiles ?

Au final toute décision est mauvaise dans un sens ou un autre, alors on dépense les sous pour des à côtés : serveurs, prestas pour un logo, quelques aides pour des conférences, etc. En tout cas rien qui ne sert directement à aider les principaux contributeurs à s'investir sur le projet.