Auteur/autrice : Regulus Page 1 of 4

Il faut bien l’admettre, mais l’optimisation des performances logicielles est bien souvent ignorée. De nos jours, cette activité est souvent peu pratiquée, sacrifiée sur l’autel de la simple mise en ligne de nouvelles fonctionnalités à toute allure. Pendant ce temps, les logiciels, en majeure partie peu performants, brassent les octets des processeurs. La faute à des développeurs peu formés, connaissant peu les algorithmes essentiels, les structures de données principales et leur performance, mais aussi à des langages parfois très peu adaptés, et bien sûr le manque de volonté ou même de besoin. Dans un monde qui s’agite – à juste titre – autour de la durabilité, on ne peut qu’être surpris de la situation en cours.

Mais la situation pourrait changer. Les IAs pourraient sérieusement aider à améliorer la situation, selon plusieurs axes d’ailleurs. Certaines des IAs actuelles les plus performantes (Claude 4 ou Google Gemini 2.5 Pro) sont maintenant capables d’être interrogées sur des morceaux de code de plusieurs centaines de ligne, de comprendre leur fonctionnement (et donc de commenter ligne par ligne ce qui est fait) et de proposer des changements parfois pertinents.

Ces mêmes IAs interrogées alors sur la façon d’améliorer les performances vont bien sûr commencer par suggérer de profiler l’application. C’est évidemment la première chose à faire. On peut pas travailler à améliorer des performances sans mesure précise permettant de savoir où focaliser les efforts. Ensuite, les IAs sont capables de faire des propositions, plus ou moins pertinentes et intéressantes, mais le plus souvent à creuser. Leur utilité est donc non négligeable.

Enfin, là où les IAs peuvent se montrer remarquables, c’est dans la phase finale d’optimisation, lorsque tout a été tenté avec un langage taillé pour les performances (tel que C++, C ou Rust) : l’utilisation des intrinsics est souvent le dernier recours, et avec des gains parfois énormes. Les processeurs modernes sont bourrés des ces instructions (voir le cas d’Intel ou d’AMD) que les compilateurs essaient d’utiliser du mieux qu’ils peuvent. Certaines IAs se débrouillent avec une facilité remarquable pour transformer un code classiques et code vectorisé avec ces instructions très peu connues. Y compris savoir jongler avec les processeurs supportant ou non certains groupes de ces instructions (très utile notamment avec les processeurs Intel qui ont abandonné le support de l’AVX-512).

L’utilisation toujours croissante des IAs dans le secteur du logiciel est donc un bienfait au service des logiciels mieux relus, mieux optimisés et plus sobres.

La série Rematch diffusée notamment sur Arte revisite les combats entre l’ancien champion du monde des échecs Garry Kasparov contre les ordinateurs d’IBM Deep Blue puis Deeper Blue. Cette série sympathique montre la tension lors des matchs d’échecs. Elle cherche aussi à montrer l’enjeu du combat entre l’homme et la machine, le tout dans un contexte où les intelligences artificielles génératives efficaces viennent d’apparaître largement il y a à peine 2 ans.

Si le scénario est plutôt acceptable, l’image est travaillée et les acteurs jouent bien. En revanche, côté informatique, notamment côté programmation, il y a – comme d’habitude au cinéma / à la télé – beaucoup à dire.

En effet, l’écran de contrôle de Deep Blue est divisé en 3 zones. La partie gauche montre l’échiquier en cours, la partie supérieure droite affiche la liste des coups des deux camps. Enfin, la partie inférieure droite est animée. Dans la phase de réflexion, on voit tout un texte défiler et qui s’arrête lorsque Deep Blue a choisi con coup.

Ce texte mystérieux qui défile est manifestement du code C++. On voit sur cette capture d’écran notamment une déclaration de la méthode static bool add_pawn_moves(list_t * list, const board_t * board, int to, bool legal, bool stop)

On retrouve le code associé par exemple sur https://fossies.org/linux/gnuchess/src/engine/move_evasion.cpp (voir la ligne 164). Ce code correspond au code source du programme de jeu d’échecs appelé GnuChess.

Bien sûr, faire défiler un code informatique sur cet écran de contrôle est aussi aberrant qu’inutile. Et ce, même si ce code correspond à un programme de jeu d’échecs. Ce programme GnuChess est gratifié d’un score ELO de 2661 en 2023, ce qui est bien sûr un très bon score, mais loin derrière Kasparov avec ses 2800 points ELO et quelques. Ce n’est certainement pas Kasparov qui aurait pu être inquiété par Gnuchess il y a 25 ans.

De nos jours le programme d’échecs ayant le score ELO le plus élevé de nos jours est Stockfish. Son score ELO estimé étant de 3640. Même si les scores ne sont pas directement comparables, Stockfish est tout de même capable de battre largement n’importe quel humain. Sur ce point, le match est plié.

Tous les programmes de jeu d’échecs actuels sont basés sur de l’algorithmique qui a fait ses preuves. À savoir, des opérations de bitboard pour calculer rapidement l’état du jeu après un coup, des tables de transposition pour éviter d’avoir à calculer des coups similaires, des algorithmes de recherche tels que le MiniMax, la recherche arborescente de Monte Carlo, etc. Et parfois même de la véritable intelligence artificielle afin d’évaluer l’état d’un plateau. Hélas, tous ces aspects n’apparaissent pas la série Rematch. On a plutôt droit à un mystérieux programme qui se modifierait lui-même.

On pourrait aussi parler des écrans d’ordinateur qui fluctuent entre écrans cathodiques et écrans plats alors qu’aussi bien en 1996 qu’en 1997, les écrans plats étaient plutôt inexistants.

On pourrait aussi évoquer la présence inappropriée à l’écran de code javascript et d’erreur de compilation C++. Mais c’est une autre histoire.

Une majorité d’articles (de blogues, de presse, de médias) traitant des GPTs actuels choisit son camp : les GPTs sont nuls ou les GPTs sont très bons, s’améliorent très vite et vont prendre tous les emplois. La vérité est probablement entre les deux.

Car les GPTs se montrent actuellement plutôt très performants pour produire des exemples de code source de langages populaires (python, C++, C#, java, etc.) ou même compléter/adapter/corriger du code source pas trop long.

Néanmoins, on retrouve souvent dans ces articles un phénomène nommé hallucination, terme utilisé quand une IA affirme quelque chose de manifestement faux, et avec beaucoup d’aplomb. Ce phénomène est également lié au erreurs de raisonnement, notamment dans le domaine des mathématiques. Ces erreurs sont particulièrement graves. En voici un exemple :

Ainsi, dans un contexte pas spécialement compliqué, ChatGPT est capable d’affirmer que 0 moins 1 vaut 26. Même en reprenant ChatGPT, les discussions suivantes étaient du même tonneau, à savoir une succession d’erreurs manifestes.

Ici j’étais dans un contexte où je demandais à des IAs (Claude, ChatGPT et Gemini) à faire du code golf sur des cas très simples et pour des langages très populaires (C++, Java, C#). Toutes ces IAs ont beaucoup de difficulté avec le code golf. Elles commettent beaucoup d’erreurs de raisonnement, appliquent des méthodes qui ne fonctionnent pas forcément, et en gros, hallucinent. Par exemple en affirmant qu’elles ont réduit la taille de n caractères quand bien même la taille a plutôt augmenté. Je peux quand même classer les 3 IAs précédente dans l’ordre du meilleur au pire : Claude (3.5 Sonnet), ChatGPT (4) et Gemini.

Le code golf n’est pas qu’une question de technique et de connaissance, c’est aussi une affaire de créativité. Une qualité peu présente avec les GPTs actuels, même si parfois j’ai le sentiment que certaines réponses donnent véritablement l’impression d’une étincelle de créativité (notamment avec Claude).

Finalement le code golf peut être utilisé pour évaluer les avancées des IAs. Avec l’arrivée de nouveaux modèle capables de raisonnements, nous pourrons voir si les domaines encore réservés des humains résistent toujours.

Dans la série des idées que l’on aurait pu découvrir un 1er avril sur le ton de l’humour, on découvre dans l’actualité : On peut « coder sans ordinateur, avec un crayon et un papier ». L’idée va même plus loin et suggère de limiter la bande passante sur Internet à 3 Go par semaine et par personne.

Il est toujours surprenant de voir des personnes faisant preuve d’ultracrépidarianisme. Car non, on ne code pas avec un crayon et un papier, excepté pour les rares cas d’apprentissage (et encore) ou d’entretien d’embauche (là aussi, c’est devenu rare). Coder autrement sans ordinateur est un non sens et une perte de temps totale.

Comment qualifier aussi la limitation de bande passante, à l’heure du télétravail, de la vidéo à la demande ou de l’ère dite du « Big Data » ?

Par exemple, télécharger le catalogue astrométrique Gaia DR3 afin de faire des études sur des catégories d’objets célestes, cela représente un total d’environ 10 To. Soit plus de 3400 semaines (plus de 65 années) à raison de 3 Go par semaine. Bref, une idée à oublier d’urgence.

Contrairement à de nombreux langages, C# (mais aussi VB.NET et F#) disposent d’un support pour les tableaux multidimensionnels. Ainsi, au lieur d’écrire :

double[][] a = new double[n][];
for (int i = 0; i<n; i++)
a[i] = new double[n];

on peut écrire :

double[,] a = new double[n, n];

ce qui simplifie un peu l’écriture et a l’avantage d’avoir un tableau parfaitement rectangulaire par opposition à un tableau irrégulier (jagged array en anglais).

On pourrait s’attendre à ce que ces tableaux multidimensionnels soient plus performants que des tableaux irréguliers, puisqu’il n’y a qu’un seul new à faire, et que l’accès aux valeurs résulte d’une simple opération de type a + b * c.

Hélas, ces tableaux multidimensionnels doivent être absolument évités (en attendant que l’équipe responsable des SDK .NET se penche sur ce sujet). En effet, quelques pages parlent de ce sujet :

• https://stackoverflow.com/questions/468832/why-are-multi-dimensional-arrays-in-net-slower-than-normal-arrays
• https://blog.tedd.no/2021/10/07/why-c-multidimensional-arrays-are-slow/
• https://dev.to/vercidium/improving-performance-of-multidimensional-arrays-in-c-4e9b

En étudiant plb2 sur Github qui est un code destiné à étudier les performances de quelques algorithmes pour 25 langages, j’ai voulu étudier la variation de performance pour les différents types de tableaux, notamment, pour le cas de la multiplication de 2 matrices utilisant l’algorithme naïf.

Voici le code de base qui initialise 2 tableaux (de dimension 1000 par 1000) et effectue la multiplication matricielle le tout en utilisant des tableaux irréguliers :

Et le code équivalent avec des tableaux multidimensionnels :

Or, l’écart de performance est d’un facteur d’environ 3 (environ 1300 ms pour le premier cas et environ 4000 ms dans le second cas sur une machine de test en mode Release et .NET 8, sous Windows), ce qui est loin d’être négligeable.

Donc il est préférable se contenter de la syntaxe verbeuse des tableaux irréguliers.

Les Microsoft Surface sont un ensemble de matériels allant de la mini tablette Android jusqu’aux ordinateurs portables et ordinateurs fixes dont le premier exemplaire est apparu il y a 10 ans, donc en 2013.

De nombreuses générations se sont succédées, de nouveaux matériels sont apparus, parfois dans un esprit inédit avec un marché plutôt peu inventif.

Néanmoins, plusieurs de ces nouveaux matériels ont été critiqués pour leur bogues multiples et leur manque de fiabilité.

On apprend ainsi que Microsoft vient de mettre fin à l’aventure des Surface Duo.

Il existe aussi un aperçu des appareils Surface apparus au fil des années.

On peut maintenant se demander quels seront les prochains appareils qui seront arrêtés. On peut imaginer que ce sera les Surface Book. En effet, ces ordinateurs portables étaient assez originaux à l’origine. Mais ils souffrent de graves défauts de fabrication. Par exemple, la recherche surface batterie gonflée (ou surface battery swollen en anglais) fournit beaucoup de résultats.

Exemple en photo d’une batterie Lithium-ion gonflée d’un Surface Book qui déforme littéralement le boîtier :

On pourrait aussi évoquer les plastiques de nombreux accessoires (clavier et souris) qui deviennent gluants et collants au bout de quelques années seulement.

Dès lors ont peut s’interroger sur l’avenir de cette ligne de produit de plus en plus décriée pour son manque de qualité et durabilité.

Depuis environ une trentaine d’années, le format graphique JPEG règne en leader quasi incontesté. Notamment sur Internet, la majorité des images sont encodées en JPEG.

D’autres formats graphiques cohabitent pour quelques besoins particuliers : PNG (images simples ou besoin du canal alpha) et GIF (petites images animées) notamment. À noter aussi le format TIFF qui bien que très ancien et bien qu’il ne dispose pas de taux de compression intéressants, ni de canal alpha, ses dimensions maximales sont considérables : 2^32-1 x 2^32-1. Et il supporte une très importante profondeur de couleur : jusqu’à 16 bits par canal. Et du coup le format TIFF reste un format populaire pour numériser des documents ou des diapositives.

Si le JPEG était un choix pertinent à l’époque, on peut raisonnablement se demander pourquoi il est encore utilisé de nos jours. En effet, ce format graphique a dorénavant un faible taux de compression face à d’autres formats plus récents, et possède de nombreuses limitations, par exemple :

• Taille maximale de 65535*65535
• Pas de canal alpha
• Profondeur de couleur limitée à 8 bits par canal
• Taux de compression plutôt faible

Depuis sont apparus de nombreux prétendants au remplacement de ce format JPEG. Dont :

• JPEG 2000. Ce format présente peu d’améliorations par rapport au JPEG d’origine, et n’a donc pas pu remplacer son prédécesseur.
• WebP. Surprenamment, ce format est très limité : profondeur de couleur limitée à 8 bits par canal. Taille maximale des images limitée à 16383*16383 seulement. Néanmoins il accepte un canal alpha et a un taux de compression un peu meilleur que le JPEG.
  Une version 2 est en cours mais apporte peu d’évolution (profondeur de couleur légèrement améliorée à 10 bits par canal, taux de compression qui serait un peu amélioré)
• HEIF/HEIC. Taille maximale de 16383*18383. Profondeur de couleur de 10 bits par canal.
• AVIF. Taille maximale de 65535*65535 ou plutôt 8192 x 4352 avec des extensions possibles. Profondeur de couleur de 12 bits par canal.
• JPEG XL. Un format récent mais taillé pour l’avenir tant il cumule les avantages. Dimensions maximales : 2^30-1 x 2^30-1. Profondeur de couleur par canal : 24 bits (entiers) ou 32 bits (flottants). Il supporte aussi pas moins de 4099 canaux (3 + 2^12), et donc le canal alpha est largement supporté. Et en plus il dispose d’un excellent taux de compression, etc.

Bien sûr il existe une multitude d’autres formats graphiques adaptés à des usages bien spécifiques (compression sans perte, support de très grandes dimensions, ou même formats simplement propriétaires).

À noter également que les dimensions maximales dans les 2 dimensions sont impossibles à obtenir en pratique pour de multiples raisons (notamment à cause des limitations d’offsets).

On comprend bien que le format JPEG XL est le format graphique du futur qui cumule quasiment tous les avantages. Ce devrait bien sûr être le format utilisé sur Internet pour réduire les données transmises et réduire la taille des supports mémoire, dans un réflexe de sobriété. Mais aussi le format de base pour les appareils photo, les appareils de numérisation, etc.

Hélas, tel n’est pas le cas. Google a décidé de mettre des bâtons dans les roues de ce format du futur. Sur fond de rivalité avec d’autres formats nettement moins bons (WebP et AVIF), et de sa situation largement dominante dans le domaine des navigateurs internet (Chromium / Chrome), le JPEG XL va avoir bien du mal à se faire la place qu’il mérite. Faudra-t-il que les autorités étatiques s’occupent de ce dossier ?

Intel a supprimé le support de l’AVX-512 à partir de sa 12e génération de processeurs (Alder Lake).

Les bouleversements ne vont pas s’arrêter là. Intel se prépare à faire évoluer les jeux d’instructions de ses processeurs, mentionnant l’APX (Advanced Performance Extensions) et l’AVX10 (Advanced Vector Extensions 10). Et en supprimant les instructions MPX (Memory Protection Extensions) qui étaient pourtant apparues récemment sur les processeurs Skylake (6e génération de processeurs). Sans compter que l’AVX10 va se décliner dans de multiples possibilités selon la catégorie de processeur (grand-public/entreprises) et les générations (AVX10.1 puis AVX10.2). Pour les développeurs pratiquant le langage assembleur ou les intrinsics functions accessibles depuis plusieurs langages (notamment le C++), la situation qui n’était déjà pas simple va nettement se complexifier.

L’utilisateur final devrait quand même voir un avantage au final. Le doublement du nombre de registres généraux (passant de 16 à 32) devrait largement aider à améliorer les performances des processeurs, conjointement aux compilateurs qui auront la lourde tâche de gérer cette évolution. Nouveau point positif, l’AVX10 sera possible sur tous les cœurs, qu’ils soient P-core ou E-core.

Autre changement significatif, mais pour le moment au stade de la rumeur : la fin de l’hyper-threading. De toute façon il n’était utilisé que sur les quelques cœurs de type P-core. La disparition de l’hyper-threading n’aurait donc pas un impact significatif. La simplification des cœurs de type P-core qui en résulterait pourrait permettre d’ajouter davantage de cœurs de type E-core. De nos jours, c’est bien ce que l’on attend, notamment de la part des développeurs : davantage de cœurs, davantage de vitesse et davantage de mémoire centrale.

Le hors-série N°11 de Programmez.com est consacré au langage python. Ce langage qui a connu une popularité croissante est en effet dorénavant utilisé dans de nombreux contextes pour de petits projets, ce qui peut justifier une série d’articles à son sujet.

Néanmoins, plusieurs articles sont rédigés d’une manière maladroite (en étant poli), notamment l’article qui compare la syntaxe de python avec celle de C# ou C++. Comme si on choisissait un langage de programmation en fonction de sa capacité à faire du code golf. Il est vrai que python obtient généralement de bons scores dans le domaine (j’apprécie python notamment pour ça). De mon côté, la capacité à écrire un Hello World de manière succincte n’est pas ma préoccupation première quand je dois résoudre un problème.

Par ailleurs, si un Hello World s’écrit effectivement brièvement en python :

print("Hello World")

Voici la version attribuée au langage C# :

using system;
namespace Hello
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }
}

Mais cette version ne représente pas la situation courante. En l’état actuel, un développeur C# écrirait plutôt simplement :

Console.Write("Hello World");

Le deuxième exemple choisi reprend la célèbre Conjecture de Collatz appliquée au nombre 299999. Et en comparant python avec C++ cette fois-ci.

Côté python, ça donne :

n=2999999
i=0
print(i,">",n)
while n!=1
    if n%2==0:
        n=n//2
    else:
        n=(3*n+1)//2
    i+=1
print(i,">",n)

Côté C++, voici le code verbeux attribué à C++ :

#include <iostream>
using namespace std;
int main()
{
    unsigned int n=2999999;
    unsigned int i=0;
    cout<<i<<">"<<n<<endl;
    while(n!=1)
    {
        if(n%2==0)
        {
            n=n/2;
        }
        else
        {
            n=(3*n+1)/2;
        }
        ++i;
    }
    cout<<i<<">"<<n<<endl;
    return 0;
}

Pourtant ce code peut être amélioré :

#include <iostream>
int main()
{
    int n=2999999, i=0;
    std::cout<<i<<">"<<n<<std::endl;
    while(n!=1)
    {
        n = n%2==0 ? n/2 : (3*n+1)/2;
        i++;
    }
    std::cout<<i<<">"<<n<<std::endl;
}

Et si le but est de faire un code court, alors allons-y en 7 lignes en C++ au lieu de 10 lignes en python :

#include<iostream>
int i,n=2999999;
main()
{
    for(printf("%d>%d\n",i,n);n>0;i++)n=n%2?(3*n+1)/2:n/2;
    printf("%d>%d\n",i,n);
}

Sachant que l’on peut encore faire mieux (ce qui veut dire pire en terme de lisibilité).

Ceci démontre que la longueur d’un programme n’est pas un argument en faveur d’un langage de programmation.

De toute façon, comparer les langages de programmation et arriver à la conclusion qu’un langage serait meilleur qu’un autre est une faute grave pour un développeur (c’est plutôt que le développeur devrait s’extérioriser). Tout ce qu l’on peut dire, c’est que certains langages sont plus adaptés que d’autres dans certains contextes. Par exemple, on évitera d’utiliser le langage interprété qu’est python pour de trop gros projets (ou simplement pour sauver la planète, cf. l’article Pourquoi l’utilisation du langage de programmation Python serait en train de « détruire la planète »). Par ailleurs, il ne faut pas oublier que la plupart des langages évoluent de nos jours rapidement (y compris python). Et du coup, les syntaxes attribuées a C++ pour les listes et les dictionnaires ont dorénavant des syntaxes améliorées ce qui annihile les critiques inutiles contre cet excellent langage. Sinon, pourquoi ne pas avoir utilisé la syntaxe de python par exemple version 2.7 ?

Enfin, concernant le supposé « coup de grâce » de python contre les autres langages au sujet de sa bibliothèque, il est difficile de faire ce genre de comparaison. D’autant plus que si C++ a a effectivement une bibliothèque standard incomplète, bien d’autres impressionnantes bibliothèques viennent en renfort (l’auteur semble ignorer boost).

En conclusion, un article, voire un hors-série, à ignorer.