Julien Jorge a écrit 526 commentaires

Merci, je vais essayer :)

J'ai mis un bépo sur mon téléphone mais j'ai l'impression que même une fois que je serai habitué au layout ça ne sera pas aussi efficace que sur l'ordi. Je me retrouve souvent à utiliser un seul côté du clavier, ce qui fonctionne bien quand on a tous les doigts sur le clavier mais pas quand on n'y met que deux pouces.

C'est un peu le problème avec cette tendance à vouloir tout réécrire. Une fois passée la hype il n'y a plus grand monde. En attendant, GNU ls est toujours maintenu 30 ans après :)

Le compilateur n'a aucune obligation de conserver l'ordre des variables locales ou globales.

J'allais le dire ! La direction de la pile n'est pas spécifiée dans le standard si je me souviens bien. En plus des arguments que tu as listé.

Mais ce int* const b non initialisé m'embête. Je suis surpris que ça compile.

a est un entier de valeur indéterminée.
b est un pointeur constant vers un entier, l'adresse pointée est, heu…, indéterminée mais fixe ?
c est, heu…, un tableau de 10 pointeurs non initialisés de fonctions sans paramètres qui retournent un pointeur vers un entier.
d est un tableau de deux pointeurs sur entiers, le premier est l'adresse de a et le second est null.

J'ai bon ? C'est pas facile de tête sur téléphone en vacances :)

Idem, ça me manque aussi. Ça m'a beaucoup motivé à écrire sur des sujets qui m'intéressaient, ce qui par effet de bord m'a obligé à creuser ces sujets et donc à m'améliorer. Maintenant même de simples blogs ont des bandeaux cookies ou des overlays pour s'inscrire à une newsletter. C'est nul.

Oui, ça ne change pas la taille de mon binaire. J'imagine que CMake a déjà émis une commande similaire. Par contre ça fait une recherche surprenante quand on oublie le tiret.

J'ai testé sur une machine plus récente, avec de plus gros caches (sauf L1, celui là ne grossi pas d'une génération à l'autre) et le problème était toujours présent :) Pas de tests sur un AMD par contre.

Il me semble que la LTO à l'époque de GCC 4.8, c'était pas extraordinaire.

Je ne suis pas allé dans les détails mais en réalité j'utilise ICC 18, qui s'appuie sur le GCC du système pour la lib standard, en l'occurrence GCC 4.8. Par conséquent c'est ICC qui s'occupe du LTO. J'ai testé dans un autre cadre avec des compilateurs plus récents (GCC 11, Clang 7, ICX 22, ICC 22) et ils donnent tous de meilleurs résultats, sauf ICC 22 !

Est-ce que tu utilises function-sections, data-sections et gc-sections pour découper les fichiers .o en sections séparées et supprimer les sections inutiles?

Pas encore ! J'aimerais bien tester mais avec un compilateur récent. Tant que la boîte ne fait pas la transition c'est pas très motivant d'aller fouiller dans les options des compilateurs.

Faut-il répondre à un journal déjà noté -15 en écrivant un autre journal ?

Non.

Perso j'ai convergé vers CMake + Ninja + Ccache + Bash. Le premier s'améliore sans cesse et répond à quasiment tous les cas. Pour le second j'ai une légère préférence par rapport à make car il ne flood pas mon terminal, et je peux utiliser ninjatracing avec. Le troisième me rend la vie plus agréable quand je passe d'une branche à l'autre.

Et puis il y a Bash pour tout le reste. Par exemple, Ccache a beau être très efficace il ne gère pas le link, donc j'en viens souvent à mettre en place un petit cache de binaires pour les dépendances ou pour des builds complets. Par exemple au boulot sur la CI on se compare à une branche de référence. Le fait de conserver les artefacts de build et de les restaurer plutôt que de recompiler ladite branche fait gagner environ 15 minutes (sur 15) pour les builds suivants. Sur un projet perso j'ai le même genre de choses pour les dépendances.

De même pour les 50 options CMake des multiples variantes de build. Plutôt que de configurer ça à la main je fais un petit script que je lance avec l'option qui va bien pour lancer la config qui correspond ; par exemple ./setup.sh --build-type tsan configure le projet en debug, active ThreadSanitizer, et lance le build. Ça n'empêche pas d'utiliser CMake pour les intégrateur mais pour mon quotidien ça simplifie bien la vie.

Ah cool un journal de serge_sans_paille, je vais apprendre des trucs.

Merci pour ce super journal qui me fait découvrir un nouvel outil :) Mais tu oublies de nous parler d'un autre moyen d'éviter le conflit de noms à l'édition des liens : utiliser le mot clé static. Et oui, ainsi la fonction aura la visibilité hidden dans chaque unité de compilation qui inclut l'entête et pour peu qu'il n'y ait pas de problème de gardes d'inclusions ça devrait passer.

Bon évidemment il ne faut pas faire cela. Déjà parce que sémantiquement c'est tordu, et aussi parce qu'on passe pour un débutant qui débarque d'un de ces langages ésotériques où la déclaration et la définition sont dans le même fichier. Mais surtout, il faut éviter d'implémenter les fonctions dans les entêtes parce que ça crée du couplage entre l'implémentation de la fonction et le code qui inclut l'entête ; et y'en a ras la casquette de recompiler la terre entière dès qu'on touche à un entête, non mais, hein !

À part ça je regardais le style-check.yml de xsimd et puisque j'en suis à donner mon avis alors que personne ne le demande, je vais vous dire deux choses les enfants : Premièrement, n'écoutez pas les inconnus qui affirment des trucs sur Internet. Deuxièmement : les étapes de votre CI doivent être lançables par les devs sur leurs machines. Ici on a un bon exemple puisque l'étape qui vérifie l'oubli d'inline dans les entêtes consiste à lancer un script bash dispo dans le dépôt. Je suis plus mitigé pour le clang-format qui lance une action GitHub tirée d'un autre dépôt ; impossible de lancer ça simplement en local. Quant à cross.yml et ses commandes shell qui s'étalent sur 40 lignes… bien malheureux celui qui aura à reproduire le build sur sa machine. À mon humble avis, ces 40 lignes devraient plutôt ressembler à sh ./test/cross-compile.sh --compiler ${matrix.sys.compiler} --compiler-version {matrix.sys.version} …

Pourquoi faut-il sortir les scripts des fichiers de config de la CI vous demandez-vous?

Déjà comme on vient de le voir, pour que les développeurs puissent lancer les tâches sur leur machines de développement. Pourquoi attendre d'avoir poussé sa branche, lancé la CI, construit 50 images Docker, exécuté 30 étapes de configs, pour au final apprendre que le fichier foo.cpp n'est pas bien formaté ; alors qu'on peut avoir l'info lors du commit en configurant une hook Git qui lance exactement le même script que la CI ? C'est une perte de temps pour les devs.

D'autre part, vous souvenez-vous de Jenkins ? De Travis-CI ? Des autres outils de CI qui promettaient une config déclarative hyper simple ? Peu importe :) La CI ça va ça vient, et c'est bien dommage de lier ses tests avec une CI donnée. Que va-t-il se passer quand Elon Musk achètera GitHub et que tout le monde partira sur GitLab ? Il faudra encore réécrire tous ces fichiers de config. Adieu l'action clang-format, adieu cross.yml, il faut trouver autre chose. Mais on peut faire mieux ! Si tous ces tests étaient dans des scripts, ça marcherait partout ; et la config de la CI ne serait qu'une légère couche pour faire la glu entre les deux.

Bon j'ai l'air d'un vieux râleur mais franchement merci pour ce journal, je suis impatient de lire les suivants :)

Moi ça me gêne un peu d'affirmer que c'est quelque chose qui n'est visiblement pas représenté. Je suis d'accord sur le fait que le café passe bien pour le grand public mais dès lors que l'on dit que c'est autre chose, les possibilités sont infinies. Pourquoi de l'alcool plutôt qu'un autre stupéfiant ?

En fait je crois que c'est tout l'intérêt d'utiliser un truc commun ou ambigu : ça en dit autant sur l'auteur que sur le spectateur. Au final ce qu'on y voit est un bout de réponse à la question : si moi spectateur je me trouvais dans un tel état de tristesse, vers quel échappatoire me dirigerais-je ? Alcool, drogues, travail, isolement… Les possibilités ne manquent pas.

Je l’interprète aussi comme ca. Par contre je comprends pas bien pourquoi il y a la poussette si l'enfant est mort a l’hôpital avec la couveuse et tout.

D'après moi le bébé est sorti en souffrance, a survécu quelques mois, puis il est décédé. La tristesse de la scène de la couveuse serait plutôt due à la difficulté de l'épreuve d'avoir un bébé qui entre dans la vie dans la douleur.

Tiens je n'aurais pas pensé que c'était autre chose que du café, en plus elle le prend dans un café et le contenant ressemble pas mal à un gobelet de café. Cela dit ça ne m'étonne pas qu'il y ait confusion pour quelqu'un qui trouve que Sprite Fright est marrant alors que ARGH! BON SANG MAIS C4EST DÉGUEUX ! :p

Il y a un truc qui me perturbe dans l'ordre des événements tels qu'ils sont présentés. On a : déprime dans le fauteuil, accouchement, couveuse, dispute, mariage (elle a l'air d'être enceinte non ?), enterrement, puis une sortie avec la poussette, et enfin la demande en mariage. Ça n'a pas l'air bien ordonné, mais c'est peut-être justement parce qu'elle est tourmentée ?

Ton journal se fait moinser et c'est un peu dommage parce que quand on lit ce commentaire, c'est très intéressant.

je ferais peut être des journaux plus détaillés pour quelques uns des sujets abordés ici.

Go ! Go ! Go !

Après le journal qui nous informe qu'il paraîtrait que deux figures du libre seraient à ce qu'on dit des autistes Asperger, puis un commentaire qui nous apprend qu'un membre de l'équipe de modération d'un célèbre site francophone sur Linux et les logiciels libres serait un meurtrier sexiste homophobe raciste ; voici le journal qui affirme qu'Albert Einstein était l'auteur d’un précis de soumission à l’usage du couple.

C'est fou l'information qu'on peut diffuser quand on ne s'embête pas à avec les sources.

Il y a quelques années j'étais sous Debian. Je venais de Mandrake qui m'avait cassé les pieds avec ses RPMs (sûrement un problème d'utilisateur, tout cela est très loin) alors j'ai migré vers les .deb bien sympathiques. De plus le côté rigoureux de Debian me plaisait beaucoup.

Puis j'en ai eu marre des vieilles versions de logiciels alors j'ai activé le dépôt testing, peut-être d'autres (je ne sais plus, tout cela est très loin) et en quelques manips et upgrades j'ai flingué mon système.

À l'époque Ubuntu me faisait le l'œil avec ses logiciels relativement récents et son installation facile, malgré ses pilotes non libres. J'ai remigré, et je n'en suis pas reparti.

Seulement voilà, depuis quelques temps j'ai l'impression de lutter contre Ubuntu. J'ai viré Unity pour profiter de Gnome 3 (bien avant l'abandon d'Unity), puis j'ai viré snap pour pouvoir lancer la calculatrice de Gnome en moins d'un quart d'heure, puis j'ai modifié la config d'apt pour profiter de Firefox via leur PPA. J'en suis à avoir écrit un script de post-installation pour « nettoyer » l'installation par défaut d'Ubuntu. Je me dis qu'il y a un problème.

Plus ça va et plus je me dis que je devrais revenir à Debian mais j'ai un peu la flemme de migrer mon petit parc. Toi qui est habitué au système, avoir des logiciels récents avec Debian et des pilotes non-libre pour mon matériel qui ne fonctionne de toute façon qu'avec cela, ça demande quoi comme effort ? Est-ce que je pourrais installer des PPAs avec Debian ? (Celui de kdenlive m'intéresse, par exemple).

le mot de passe ressemble à DLKFJOM1lFJOINVDdsflmdksdd!sdfsdjksdflkjZEIEF

Hé ! Colle pas mon mot de passe publiquement sur l'Internet !

Je te rejoins sur la forme, moi aussi ça m'agace d'être pollué par des popups de cookies et des demandes d'inscription à des listes dès que je veux lire un article. Je rêve d'un réveil des techos qui se remettraient à écrire des billets simples sur des blogs simples dans un pur but de partage d'expérience. Malheureusement ça n'arrivera pas :( C'est con parce qu'au delà du partage, écrire un post sur n'importe quel sujet force aussi l'auteur à approfondir et donc à mieux comprendre le sujet. Rien que pour l'amélioration personnelle ça vaut le coup.

Sur le fond j'ai bien aimé ce billet. Le titre me semble relativement juste en cela que ce qu'il a appris durant sa carrière n'a aucun intérêt aujourd'hui. Certes il y a de l'expérience acquise quel que soit l'outil, ça reste du développement ou proche, mais toute l'expertise accumulée sur un outil tel que Silverlight ou Delphi n'a plus vraiment d'intérêt. Pour caricaturer, le seul espoir pour celui qui a misé sa carrière sur ces technos est de rejoindre un projet en maintenance dans une boîte où rien ne bouge.

Je compare aussi avec le C++ puisque c'est mon outil principal, et je me dis qu'on est quand même bien confortable avec du code qui peut traverser quatre décades quasiment sans encombre. Ça n'empêche pas quelques personnes de pousser à casser les choses (e.g. la stabilité de l'ABI, ou plus simplement de pousser des trucs comme Almost Always Auto ou les trailing return types parce que comme ça c'est moderne™) mais globalement c'est solide dans le temps. C'est même encore plus vrai en C : aujourd'hui je peux prendre le code de la zlib et compresser mes données sans problème (probablement pas la meilleure compression cela dit).

Mettre « Le texte que tu as "traduit" » avec des guillemets à « traduit », c'est déjà méprisant. Ça se lit : « le texte que tu as soi-disant traduit, si on peut qualifier de traduction cet assemblage hasardeux de mots ».

Répondre à une demande d'éclaircissement par « Tu veux vraiment une explication ? », c'est aussi très méprisant. Ça se lit : « Tu veux vraiment que je t'explique pourquoi c'est de la crotte ? T'es tellement nul que tu ne le vois pas toi même ? ».

Ce n'est pas être exigeant, c'est juste être désagréable et humiliant. Je t'invite donc à balayer devant ta porte : si tu veux prendre de haut les textes de quelqu'un, commence par les tiens.

"Peinture" car la qualité du code c'est de la déco, c'est à dire que ça ne touche pas le fonctionnel.

"Feu" pour enlever du code dans l'idée qu'on brûle tout ce qui ne sert à rien, genre extermination par le feu.

"Loupe" pour SEO car c'est le symbole de la recherche, comme dans Search Engine Optimization.

":tada:" est une onomatopée utilisée pour appuyer l'apparition d'une chose, comme un magicien qui sort un lapin de son chapeau, ta-da !

Le navigateur est peut-être minimaliste mais les emojis plein les messages de commits et le readme ça ne me donne pas trop envie :)

c'est déjà ce que font les compilos (ils sont multi-threadés).

Es-tu sûr que les compilos soient multi-threadés ? Il me semble que le multi-threading se fait plutôt au niveau de l'outil de build (Make, Ninja) mais que le compilo lui-même est mono-thread.

Après on paye aussi beaucoup au link. Jumbo build ou pas, le link est un goulot d'étranglement où il faut rassembler l'ensemble des unités de compilation. Et bien que le linker lui-même soit multi-threadé (mold sans aucun doute, lld et gold à voir. GCC semble pouvoir paralléliser LTO au moins), ça reste une très grosse étape.

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 :)