Malgré les énormes progrès technologiques, pourquoi certains appareils modernes peuvent-ils encore se sentir plus lents qu’un ZX Spectrum de 1982?

Appuyez sur une touche d’un ZX Spectrum sorti en 1982, et un personnage est très susceptible d’apparaître à l’écran pas plus d’une image vidéo – c’est-à-dire un vingt-cinquième de seconde, ou 40 ms, plus tard. C’est presque suffisant pour se sentir plus ou moins instantané, mais on ne peut souvent pas en dire autant des appareils modernes, qui peuvent parfois se sentir – bien – à la traîne.

Ce n’est pas ce à quoi nous nous attendions compte tenu de ce qui est arrivé à la technologie à cette époque. Au moment de la rédaction de cet article, le smartphone Google le moins cher, une option raisonnable du marché intermédiaire, était le Pixel 4A. Il dispose d’un processeur Snapdragon 730G avec huit cœurs 64 bits, quatre cadencés à 2,2 GHz et quatre à 1,8 GHz. Nous pourrions essayer de calculer à quel point il y a de l’eau claire entre cela et le seul Z80 8 bits 3,5 MHz du spectre, mais je suis d’accord qu’il y en a beaucoup. Les smartphones comme le Pixel répondent-ils aux pressions de l’écran dans les 40 ms?

Parfois.

Ensuite, il y a la taille pure. L’affichage d’un compte Yahoo Mail implique environ 7,4 Mo de « sources », comme le dit le navigateur Chrome. La quantité de données réellement impliquée est compliquée, mais c’est probablement un maximum raisonnable; la plupart des demandes seront beaucoup plus petites, et encore moins, car la bande passante coûte de l’argent à Yahoo. Comparé à la taille du même site lors de son lancement en 1997, il est vaste, et bien qu’il ait beaucoup plus de fonctionnalités maintenant, il fait plus ou moins les mêmes choses que l’application Yahoo Mail pour iOS 13 ou version ultérieure, qui, nous informe Apple, pèse 245 Mo avant de commencer à stocker des e-mails. Pourquoi un téléphone qui dispose déjà d’une pile TCP/IP et d’une grande variété de sous-systèmes d’affichage intégrés a-t-il besoin de 245 Mo de ressources supplémentaires pour lire les e-mails basés sur la technologie du début des années 1970 est une question qui mérite d’être posée.

Le Pixel 4A. Image: Shutterstock.

Pourquoi cela arrive-t-il?

Il y a plusieurs raisons à tout cela.

Sur cet ancien spectre ZX, appuyer sur une touche provoque assez directement l’exécution d’un (très) petit morceau de code intégré qui écrit un caractère en mémoire, et lorsque le système d’affichage génère ensuite une image, il lit cette mémoire alors que le faisceau d’électrons du moniteur balaie l’écran et assemble le graphique du caractère en utilisant du silicium câblé. Le spectre n’a pas plusieurs couches de logiciels impliquées dans la lecture du clavier et le filtrage de l’événement résultant vers le bon morceau de code, ni ne construit l’image dans une zone de mémoire, puis analyse cette mémoire sur l’écran.

Les ordinateurs modernes, y compris les téléphones, ont plusieurs couches de code, dont la plupart dépasseraient les limitations de mémoire d’un spectre ZX de centaines de fois, entre le matériel qui lit l’écran tactile et le matériel qui pilote l’affichage. Pire encore, une partie de ce code peut être écrite dans des langages interprétés tels que Java (sur Android) ou C# (sur Windows), ou un langage qui provoque une controverse sans fin sur son interprétation: Objective-C (sur iOS). Les langages interprétés échangent le temps de l’ordinateur contre le temps du programmeur – ils rendent le code plus facile à écrire, mais plus lent à exécuter, une aubaine faustienne.

Le code interprété a tendance à être plus gros et plus lent, mais cela ne tient pas compte des augmentations de la taille du programme que nous avons observées au cours des dernières décennies. Une partie de cela est due à la tendance des logiciels modernes à utiliser beaucoup de grandes images colorées pour faire partie de son interface utilisateur, un développement regrettable qui a émergé à l’époque de Windows XP. Une autre partie de cela est la tendance des ingénieurs en logiciel à vouloir réutiliser des choses que d’autres personnes ont faites. C’est bien; c’est ce qu’est la programmation fonctionnelle moderne, mais il est facile de finir par inclure d’énormes quantités de code et de ressources dans le cadre de frameworks et de boîtes à outils qui peuvent ne pas être utilisés dans leur intégralité.

Ballonnement logiciel

Au moins flatteur, il est difficile d’éviter la réalité que tout cela est en partie dû à une pure négligence. Les choses fonctionnent parce que nous avons tellement de performances à gaspiller, mais il est pénible de réaliser qu’au moins une partie du développement de la capacité de stockage, de la vitesse du processeur et de la bande passante du réseau a été tout simplement absorbée par le géant des logiciels modernes.

Cela pourrait ressembler à l’hectare d’une vraie barbe grise, et dans une certaine mesure, oui, certains des pires exemples sont les choses les plus récentes. Google Docs dans Chrome est un morceau de code Javascript interprété, impliquant plusieurs grandes bibliothèques Javascript, s’exécutant au-dessus du moteur de rendu d’un navigateur Web, s’exécutant au-dessus de plusieurs couches d’API graphiques, s’exécutant sur un ordinateur, et il semble plus lent que Digita Wordworth sur un Amiga du début des années 90 qui avait beaucoup des mêmes fonctionnalités. Certaines – beaucoup-de ces couches sont une contrepartie nécessaire des systèmes d’exploitation modernes, mais il est difficile de ne pas avoir l’impression que quelque chose a été perdu dans la ruée vers les fonctionnalités.

Résoudre tout cela est technologiquement possible, bien qu’une solution complète nécessiterait une réécriture complète de la plupart de l’informatique moderne. Pourtant, beaucoup pourrait être réalisé par un même légèrement attitude plus rigoureuse à l’égard de l’efficacité. Il ne semble pas trop demander que les interfaces utilisateur semblent au moins aussi réactives qu’il y a trente ou quarante ans.