Pentiment

Que voici une belle claque vidéoludique. J'avais vu passer Pentiment sur CanardPC, et je l'avais gardé dans un coin de ma mémoire, jusqu'à ce que je voie qu'il était disponible sur le XBox GamePass. Ni une, ni deux, je l'installe, je l'essaie, et je suis scotché.

Pentiment est un jeu d'enquête qui se passe dans un village de Bavière au XVIème siècle, dans lequel on incarne l'artiste Andreas, qui se retrouve malgré lui au milieu d'une affaire criminelle qu'il devra tenter de résoudre.

Tout d'abord, c'est graphiquement que c'est magnifique. Un jeu entier dans le style des enluminures du Moyen-Âge, avec exploration d'une abbaye, d'un village, de ruines romaines, le tout entrecoupé de séquences oniriques plutôt émouvantes, ça fait quelque chose. Ensuite, l'histoire est prenante : il y a le mystère, la vie difficile des différents protagonistes, et et l'impression constante que l'on est en train de faire des erreurs et de condamner des innocents. Cet impact constant sur l'histoire est ce qui fait le charme du jeu : l'on doit en permanence faire des choix qui vont changer, pour le meilleur et pour le pire, le destin des habitants du lieu. C'est aussi assez frustrant lorsque l'on a l'impression de rater étape après étape, mais cela fait partie du jeu : il n'est pas possible de reprendre à un point précédent de l'histoire, et nous sommes donc condamnés à vivre avec les conséquences de nos décisions.

Il y a probablement un potentiel de rejouabilité, pour découvrir tous les chemins possibles, tenter de sauver un personnage et d'en condamner un autre, ou explorer certaines scènes que l'on a raté. En effet, limité par le temps, il n'est juste pas possible de tout voir en une seule partie. Cependant, il y aura nécessairement des redondances, et pour ma part, une seule session sera suffisante !

Et Novembre ?

Rien publié en Novembre ! Ça alors. Qu'ais-je donc fait ? J'ai joué à Pentiment, dont il faudra que je vous en dise plus. J'ai fait un peu plus de X-Plane 12, en particulier sur le sympathique Phenom 300 d'Aerobask. Du côté du C++, je m'attelle à une grosse conversion vers GCC 13, qui va me permettre d'utiliser std::format et std::date à la place de fmt::format et date. En attendant, préparons Noël !

Lego nous gâte

Quand on pensait qu'ils ne pouvaient pas faire mieux, Lego continue de faire plaisir aux space geeks. On connaissait la Saturn V et la navette spatiale américaine, voici maintenant le rover martien Perseverance que j'ai découvert dans une vitrine récemment, avec son drone. Belle bête !

Palonnier MFG Crosswind

C'était ma petite folie de la rentrée : je me suis offert un palonnier MFG Crosswind, fabriqué par une toute petite boite en Croatie, mais qui envoie du pâté. Du solide, tout en métal, à part les pédales qui sont en impression 3D d'excellente qualité, avec un amortisseur optionnel (et donc essentiel). C'est un plaisir de l'utiliser, c'est d'une précision redoutable, et en plus c'est plutôt esthétique.

J'ai choisi les pédales Airbus et les pédales "chasse". Joli, non ?

Seul petit souci, le palonnier se met facilement à glisser sur la moquette, et donc je ne dois pas trop serrer l'amortisseur, sinon c'est tout qui bouge !

Accolades et std::optional

La nouvelle manière unifiée d'initialiser les valeurs en C++, c'est super. Bim, on met deux accolades, et on a gagné. Vraiment ?

Sur le papier, c'est bath, on peut pas se tromper:

int a = {};
std::string b = {};
std::optional<int> c = {};
MonObjectQuIlEstBeau d = {};

Sauf qu'il a danger ! C'est que lorsque l'on fait un changement de type quelque part, mettons un paramètre de fonction, et que l'on s'attend à ce que le compilo nous indique gentiment tous les endroits à changer, eh bien il est possible en fait que le compilo accepte le changement sans broncher, mais en changeant la sémantique. Et boum ! C'est ce qui m'est arrivé la semaine dernière, heureusement rapidement détecté. Voyez plutôt cet innocent programme, l'on a une fonction f qui prend un optionel, et on l'appelle en initialisant notre optionel sur vide.

#include <optional>

void f(std::optional<int> a);

int main()
{
    f({});
    return 0;
}

Un peu plus tard, l'on change la signature de f:

void f(int a);

Et boum, l'on initialise maintenant a avec la valeur 0, ce qui pourrait bien être complètement faux.

Que faire alors ? Eh bien, utilisons std::nullopt ! Ainsi, notre appel f(std::nullopt) fonctionnera correctement dans le premier cas, et causera une erreur de compilation dans le deuxième.

Conclusion : mangez du {}, mais avec les optionels, préférez std::nullopt !

Noexcept - Ce n'est pas gratuit !

Je parle régulièrement de culte du cargo dans le domaine informatique, où l'on a souvent ses petites marottes que l'on applique sans comprendre. Et j'ai un chef dont la marotte c'est d'exiger l'ajout du mot-clé "noexcept" un peu partout, avec l'espoir d'augmenter les performances.

Et c'est le cas, parfois. Par exemple, une réallocation d'un std::vector après un dépassement de capacité lors de l'ajout d'un élément sera bien plus efficace si le type de l'élément a un move constructor designé comme noexcept, car dans ce cas, l'algorithme de réallocation du vecteur peut utiliser le move. Il faut donc bien se rendre compte qu'au sein du code de std::vector, il y a une condition qui vérifie à la compilation si le type a son move constructor designé ainsi, et décide d'utiliser l'algo efficace ou non. Ce n'est donc pas une optimisation du compilateur, mais bien un choix de code au sein de la bibliothèque standard, et c'est complètement indépendant du niveau d'optimisation, de l'inlining...

Et surtout, noexcept n'est pas gratuit ! Si le compilo ne peut déterminer si effectivement la fonction marquée noexcept ne lance pas d'exception (disons, elle appelle simplement une autre fonction pas inlinée qui n'est pas déclarée noexcept), il lui faut rajouter du code pour pouvoir attraper cette exception et terminer le programme à la place. Voyons ce que dit notre ami Godbolt sur ce tout petit programme:

void f();

void g()
{
    f();
}

L'assembleur généré est celui-là, c'est à dire un bête jump et puis c'est tout !

g():
        jmp     f()

En revanche, si l'on dit maintenant que g() est noexcept:

void f();

void g() noexcept
{
    f();
}

Alors l'assembleur généré nous montre bien que l'on fait un peu plus de travail, en poussant la frame sur la pile, afin que si une exception était lancée dans f(), il soit possible de l'arrêter dans g().

g():
        subq    $8, %rsp
        call    f()
        addq    $8, %rsp
        ret

Conclusion que ne renieraient pas Plic et Ploc : réfléchir avant d'agir !

Fontes pour programmer

C'est en lisant un article de Slashdot sur une nouvelle fonte mono particulièrement lisible que je me suis mis à reconsidérer mes choix. Jusqu'à présent, j'étais plutôt satisfait des fontes par défaut pour coder dans Emacs, mais de plus en plus, j'étais frustré par la ressemblance du 1 et du l ainsi que du 0 et du O. C'était donc l'occasion d'en changer.

J'ai découvert qu'il existait 2 fontes souvent citée dans ce domaine, Consolas sous Windows et Inconsolata sous Linux. Après quelques tentatives, je confirme que l'essayer, c'est l'adopter.

Regardez-donc Inconsolata: c'est beau, non ?

Architecture CPU et optimisation du compilo

Et on continue de jouer avec Godbolt, en particulier la capacité de gcc d'optimiser du code numérique. Prenons par exemple une version simplifiée de la résolution d'une équation quadratique :

#include <cmath>

double calc(double a, double b, double c)
{
    double delta = b * b - 4 * a * c;
    return (-b + sqrt(delta)) / (2 * a);
}

Je vous laisserai aller voir sur Godbolt, mais en gros, ça nous fait une 30aine d'instructions assembleur.

La première grosse optimisation, c'est la combinaison de -O3 et de -ffast-math. On passe à 18 lignes (dont 12 seulement font quelque chose d'intéressant), et le compilo utilise l'instruction assembleur sqrtsd plutôt que d'appeler le sqrt de la libc. Mais l'on peut faire encore mieux ! Avec un -march=skylake, on perd 2 instructions, et la machine passe alors sur des instructions vectorisées. Plus rapide ? Moins rapide ? Je suppose que ça va dépendre ! On retrouve un code équivalent en passant chez AMD et -march=znver3.

Maintenant, le souci, c'est que je si, comme dans mon cas, je dois compiler du code qui tournera à la fois sur des machines récentes de chez Intel et AMD, eh bien je suis obligé de garder une architecture générique et de perdre l'avantage de toutes ces instructions magiques... Quand bien même elles sont peut-être en commun ?

Frustrant, donc. Mais probablement pas catastrophique, car le code que j'optimise n'est de toutes façons pas très numérique, et se vectorise probablement mal. Tant pis !

Gitversion prend ses aises, partie 2

Juste un rebond sur mon fil précédent : je suis allé voir ce qu'il en était de git lui même. Et bien, je n'ai pas été déçu : avec grosso modo une dépendance sur la libc, sur zlib, et sur les regex perl, git tient dans à peine plus que 3 megs. Il fait donc à peu près 100 fois plus que gitversion, en 20 fois moins de place. Yay !

Gitversion prend ses aises

Gitversion est un outil ma foi plutôt malin qui regarde un dépôt git et décide du prochain numéro de version, en se basant sur une série de règles, typiquement le tag précédent et certains mots-clé dans les messages de commit. Comme l'outil, ou du moins sa version en ligne de commande (parce qu'il est également disponible en intégration continue par exemple) est plutôt simple, je me suis demandé quelle était la techno derrière.

Un petit ldd plus tard, premier bon point : en fait de dépendances, c'est minimal, en gros libstdc++. Je regarde donc le binaire en lui même, c'est du bon vieux elf, mais les chaines présentes dedans contiennent beaucoup de références à Microsoft. Mhh... Allons donc voir le source.

Et en effet, c'est du C#. Beaucoup de C#, d'ailleurs. Pris d'un doute, je regarde donc la taille du binaire... 66 megs !

Les types ont donc embarqué un interpreteur mono plus tout une palanquée de bibliothèques .NET pour lire quelques lignes de log et générer 3 malheureux nombres qui se battent en duel...

Portabilité, que de disques on a rempli en ton nom !

Question C++ toute bête

Qu'est ce qui est le plus rapide ?

bool a = ...
if (a)
{
  a = false;
}

ou

bool a = ...
a = false;

En gros: est-ce que la lecture est significativement moins chère que l'écriture, et que cela vaut donc le coup de vérifier avant d'écrire la valeur ? Pour l'instant, je l'ignore. M'en vais faire tourner quelques benchmarks pour tenter d'élucider cette question...

Godbolt

Je vous ai déjà dit à quel point ce site était une tuerie ? L'idée de base est géniale : fournir une interface web permettant de tester un programme sur une grande variété de compilateurs, d'en voir l'assembleur généré, et le résultat. Avec une grande quantité de languages (C++, D, Java, Objective-C, Ocaml...) et une grande quantité de compilos (Pour le c++, nous avons pratiquement chaque version de gcc, de llvm, et du compilo de Microsoft, plus tout un tas de variations).

C'est vraiment très, très sympa pour bidouiller, tester une fonctionnalité à venir, vérifier un bug, faire de la micro-optimisation, ou juste partager une idée de code avec quelqu'un d'autre, parce qu'en plus chaque programme est enregistré via un lien unique. Très, très pratique.

125 GB !

J'avais 15 minutes à tuer l'autre soir, et en traînant dans le Gold Pass de la XBox, je me suis dit que c'était l'occasion de tester un jeu de bagnoles. Je vois Forza, je lance l'installation, et je vois que le jeu fait 125 GB. Alors, voyez vous, ça m'a sérieusement refroidi. Parce que bon, même avec une bonne connection, ça fait quand même un bon moment à passer à télércharger toutes ces cochonneries. Serieusement, il y a quoi, là dedans ? Il y a carrément la texture 4K de chaque brin d'herbe et de chaque caillou ?

Alors j'ai laissé tomber, et j'ai plutôt installé un jeu de rallye et un jeu de F1, qui se contentaient de quelques dizaines de GB.

Et puis j'ai découvert qu'en fait je n'aime pas les jeux de voiture.

Addiction à Civilization 6

C'est terrible... À peine sorti de ma 3ème partie de 20 heures, je pense déjà à la prochaine ! Il va falloir que je trouve un moyen de me calmer. Je trouve ce jeu de plus en plus sympa, et en particulier sa variété : un petit peu de city builder, un petit peu de wargame, un petit peu d'exploration... Parfait pour un dilettante comme moi. Venant de remporter une victoire militaire avec les Romains, je tente pour la prochaine la victoire culturelle avec la France sur une carte avec plein d'îles !

C++20 - std::source_location

J'ai eu l'occasion d'expérimenter avec la structure std::source_location, qui est très bien fichue puisqu'elle s'initialise avec les informations courantes de fonction, de fichier source, et de ligne et de colonne dans le source.

Là où c'est très sympa, c'est qu'il est possible en utilisant un paramètre par défaut d'obtenir dans une fonction les informations de l'appelant ! C'est particulièrement pratique, par exemple, pour implémenter une fonction de log qui ne soit pas une immonde macro.

#include <source_location>
#include <iostream>
#include <string>

void log(std::source_location location = 
         std::source_location::current())
{
    std::cout << location.function_name() << std::endl;
}

void f()
{
    log();
}

template<typename T>
void g()
{
    log();
}

int main()
{
    f();
    g<std::string>();
    g<int>();
    return 0;
}

Et voilà le résultat :

void f()
void g() [with T = std::__cxx11::basic_string<char>]
void g() [with T = int]

Là où ça devient intéressant, c'est quand on veut le combiner avec une fonction de log variadique, de type std::format. Puisque l'on ne peut pas mettre le paramètre par défaut à la fin, car c'est ambigu, il faut ruser, et transformer le premier paramètre, typiquement la chaîne de formattage, en un objet spécial qui prend en premier paramètre la chaîne de formattage et en deuxième le paramètre std::source_location par défaut. Puis combiner tout cela avec du consteval et l'empaqueter dans un std::identity_type_t afin qu'il ne participe pas à la résolution des types variadiques, sinon ça ne marche pas !

Je posterai à l'occasion un exemple un peu plus complet. D'ici là, compilez bien.

Un Arduino dans le tiroir

C'est mon côté polarisé qui reprend le dessus - Je viens de ranger les divers composants électroniques de mon Arduino dans des petits casiers, et cela me remplit de joie.

En particulier, je galère moins quand je cherche la bonne résistance. Les anneaux de couleur, c'est sympa, mais à moins de sortir la loupe, je trouve ça tout de même plutôt ardu à déchiffrer.

J'en suis maintenant au montage numéro 6, tout en faisant mes recherches sur la meilleure manière de multiplexer un grand nombre de boutons et d'encodeurs rotatifs. Le hardware, c'est pas facile !

Arduino

Et voilà, j'ai commené à jouer avec mon Arduino ! Les projets sont sympa, et permettent de comprendre pas à pas comment interfacer des composants electroniques standard (diodes, interrupteurs, capteurs de température, de position...) avec l'Arduino, et d'écrire le code qui va bien. Je continue à apprendre, avant de me lancer dans mon projet principal de panneau de contrôle pour la simu aérienne. Il faudra que j'aille faire mon marché pour acheter boutons et encodeurs rotatifs. Je me tâte même à tenter d'intégrer un afficheur 7 segments pour l'altitude, le cap, la vitesse ascensionelle... Mais c'est plus compliqué à intégrer ensuite depuis l'ordinateur, donc on verra !