La mémoire cache est un composant majeur des processeurs et sa mauvaise utilisation peut entraîner une baisse importante des performances d’un programme. Nous allons voir dans cet article quelques astuces pour mesurer les performances liées aux caches et éviter certains écueils.

Dans les épisodes précédents, le « Single Stack Syndrome » a été décrit et poussé à son paroxysme en essayant (en vain) d’apprendre de nouveaux tours à GCC. Ensuite, après le « quoi », nous avons exploré le « pourquoi » de cette dystopie, tissée tout au long de l’histoire de l’informatique, du côté matériel comme logiciel. Devant une telle débâcle, c’est le moment ou jamais de garder ce qui marche et de faire l’inverse de ce qui ne va pas. Nous allons donc imaginer un « nouveau » type de pile qui pourrait trouver sa place dans de futurs microprocesseurs.

En 1843, Edgar Allan Poe écrivait une nouvelle policière intitulée The Gold Bug. La nouvelle dispose d’une traduction en français de Charles Baudelaire en 1856. Deux grands noms de la littérature, certes, mais quel lien avec GLMF ? Eh bien, il se trouve qu’un des ressorts de cette nouvelle repose sur l’analyse fréquentielle, un domaine historique de la cryptographie, ce qui nous offre un angle assez peu commun sur une pratique bien établie.

Dans GLMF 270, nous avons intégré au code de démarrage du noyau NetBSD, locore.S, les modifications nécessaires pour permettre à ce dernier de trouver les informations relatives à une VM et ainsi booter en mode PVH. Muni de ces informations et de cette nouvelle fonctionnalité, le code plus haut niveau du noyau va pouvoir avancer dans le processus de boot.

L’autre jour, en passant dans le couloir, j’ai vu Peter apparemment très concentré sur son écran. Je me suis dit qu’il devait faire un truc intéressant, lui. En comparaison, moi j’avais épuisé les derniers travaux intéressants : il ne me restait plus qu’à écrire de la doc ou bien préparer mon entretien annuel. Clairement, la tentation était trop grande et je suis entré dans son bureau pour en savoir plus…

À quoi peut bien servir un installeur graphique...

... si ce n'est à ajouter des bugs à corriger et du code à maintenir ? Voilà une question dont la réponse relève réellement du mystère pour moi. Le phénomène n'est pourtant pas nouveau et je me souviens très clairement de l'arrivée de ces premiers installeurs clic-clic dans le monde GNU/Linux, il y a bien des années. Tout autant que je me remémore clairement cette même interrogation à cette époque lointaine : mais que pourrait bien fournir un installeur graphique qui ne peut l'être avec un bon vieux dialog ou un code basé sur ncurses ? Une interface graphique ne simplifie rien. N'importe quel utilisateur basculant de Windows à un système digne de ce nom le sait.

Dans un premier article [0], nous avons analysé les performances de l’addition dans un compteur pour faire clignoter une LED. Dans ce second opus, nous allons voir qu’il est possible d’accélérer grandement la vitesse de l’horloge en changeant la manière de compter les cycles pour éviter d’avoir à additionner. Nous en profiterons également pour tester les performances de ces compteurs sur deux autres modèles de FPGA.

Dans un précédent article, nous avons découvert l'alimentation DP100 d'ALIENTEK, pris en main son fonctionnement de base, utilisé un outil écrit en Rust pour contrôler son comportement depuis un PC ou un SBC et avons même poussé le vice jusqu'à en faire un périphérique utilisable via le réseau grâce à USBIP. Ayant de grands projets pour cet appareil, je pense qu'il est temps de fouiller un peu davantage dans son fonctionnement, et le protocole qu'il utilise via USB...