Moore's Law and The Future of [Technology] Economy

Outre les fonctionnalités décrites ci-dessus, indiquant de quoi une infrastructure est faite, celle-ci doit posséder des propriétés qualitatives qui la rendent adaptées à son utilisation. Il y en a de plusieurs types, liés à la performance et à la façon dont elle est atteinte, à la façon dont le système évolue dans le temps, à son adaptation à un usage, à la sûreté et la sécurité.

Regardons les performances tout d’abord. Il est intéressant de constater que certaines mesures de performance constituent un argument publicitaire, comme les gigahertz (GHz), les gigaoctets (Gbytes) ou les gigabits par seconde (Gbit/s). Mais une question essentielle est de savoir comment ces performances sont obtenues, et finalement ce qu’elles signifient. Sans parler des éventuelles publicités mensongères, il y a en fait deux sortes d’informatiques tout à fait distinctes.

Il y a d’abord l’informatique « mainstream » (principale), dite « best effort », ou « je fais au mieux », qui consiste à tenter d’avoir les meilleures performances possibles en moyenne. Mais autour de la moyenne la variance peut être grande. Ainsi, si votre ligne ADSL est censée avoir un débit de 4 Mbit/s, il est tout à fait possible qu’un téléchargement de 4 Mbit prenne plus (ou moins) d’une seconde. Pourquoi ? Parce que votre requête au gigantesque système que constitue Internet n’est pas la seule, et que l’ensemble de ce système va essayer de répondre à toutes ces requêtes au mieux, globalement et en moyenne. Mais cela ne signifie rien pour votre requête particulière. Cependant, si vous exécutez la même requête un grand nombre de fois, et étant donné que le système n’est pas censé vous avantager ou vous désavantager systématiquement – s’il applique de façon juste la Net Neutrality, qui oblige à traiter tous les flux et toutes les requêtes de la même façon – alors la moyenne des temps de réponse devrait vous faire retomber sur le flux annoncé[1].

Mais il y a une autre informatique, dite « worst case », c’est-à-dire « cas au pire », qui est là au contraire pour garantir des performances de votre action ou requête singulière. Ainsi, en reprenant notre exemple d’un acheminement à 4 Mbit/s, on admettra un débit supérieur mais pas un débit inférieur : le débit annoncé est une borne garantie. On peut avoir de la même façon des bornes en temps d’exécution, en quantité de mémoire nécessaire ou utilisée, etc. Cette informatique-là, aujourd’hui très minoritaire, est destinée notamment aux applications dites critiques, où la sûreté des personnes et des biens doit être garantie. Prenons un autre exemple. Entre votre pédale de frein dans votre voiture et les freins effectifs sur ses roues, il y a un système informatique avec un logiciel qui comprend, transmet et traduit votre ordre, avec éventuellement une correction, comme par exemple dans un ABS. Chacun a déjà fait l’expérience d’une tâche par exemple sur un PC qui habituellement apparaît immédiate et qui une fois, pour des raisons inexpliquées, prend un temps très long – par exemple une minute. Soulignons que cela n’est pas dû à un défaut du système, car, par principe, cela peut se produire, et cela se produit effectivement : c’est la rançon des optimisations best effort,  qui sont néanmoins en moyenne efficaces[2]. Bien sûr un tel comportement de votre système de freinage serait très désagréable, et si l’on avait conçu ces systèmes de cette façon il n’y aurait plus de voitures sur les routes, ou les constructeurs proposant ce type de système seraient en faillite. L’infrastructure qui gère votre freinage sur votre voiture est donc worst case, c’est-à-dire qu’il est garanti que l’ensemble des traitements entre le moment où vous appuyez sur la pédale et le moment où la voiture freine – de façon adéquate – va prendre moins d’un certain temps, d’ailleurs probablement largement sous dimensionné, avec une grande marge de sécurité.

Ces systèmes worst case sont notamment utilisés dans les systèmes dits temps réel. Un système temps réel n’est pas un « système qui va vite », mais un système qui va à une vitesse garantie – elle peut être de plusieurs minutes voire heures dans certaines applications, ou dans les centièmes de seconde, voire moins, pour d’autres.

Les cas où un système worst case est indispensable ne sont pas si fréquents, car un système best effort est très souvent surdimensionné de telle façon qu’il apparaît worst case. En effet, si un système utilise normalement une ressource (par exemple un temps d’exécution) de 1, et que l’on pense qu’il est très peu fréquent que le temps effectif soit de 4 ou plus, il suffit de surdimensionner l’infrastructure pour le faire descendre en dessous d’un seuil souhaité, par exemple ici en surdimensionnant d’un facteur 4 pour faire descendre la consommation de ressource sous le seuil de 1. Un surdimensionnement coûte normalement cher, mais avec la loi de Moore il est pratiquement gratuit : le marché des applications correspondantes est simplement décalé dans le temps, ici de trois ans. Bien sûr le premier qui saura mieux dimensionner aura un avantage en prenant tout le monde de vitesse.

Il y a d’autres propriétés qui peuvent être désirables, que les systèmes soient temps réel ou pas, comme par exemple lorsque plusieurs processus indépendants sont en cours, que tous soient traités de façon juste, c’est-à-dire que chacun se voie allouer des ressources à son tour, que personne ne soit oublié indéfiniment.

Une autre propriété qui se rapproche des propriétés worst case est le déterminisme. En général, un système informatique n’est pas déterministe, ce qui signifie que si on l’exécute deux fois avec exactement les mêmes conditions extérieures, il peut ne pas donner le même résultat. Cette propriété peut paraître troublante, mais elle est en réalité assez normale : on n’attend pas en général un résultat parfaitement défini, mais un résultat parmi une collection de résultats admissibles. Par exemple, une requête lancée sur un moteur de recherche sur le web peut avoir plusieurs résultats notamment quant à l’ordre de présentation – et les moteurs utilisent cette possibilité pour engranger des revenus, en faisant payer ceux qui souhaitent être en haut de la liste. Un autre exemple dans un tout autre domaine : votre réfrigérateur possède probablement un contrôle de température intérieure permettant de maintenir celle-ci autour de la consigne – et très probablement ce contrôle est aujourd’hui mis en œuvre par du logiciel sur un petit processeur. Mais il y a en réalité une certaine latitude sur le moment auquel on doit démarrer le système de refroidissement : un peu plus tôt ou un peu plus tard; c’est d’ailleurs de cette propriété que des systèmes de gestion de la demande électrique peuvent tirer parti pour déplacer des charges électriques dans des millions de points de consommation, et ainsi alléger le système électrique global à un moment de pointe.

Il est donc normal qu’un système informatique puisse avoir plusieurs réponses, lorsqu’exécuté plusieurs fois sur des conditions initiales identiques. En pratique son comportement précis peut dépendre dans les limites admises de fonctionnement d’un état interne par exemple dans une mémoire – et cet état est par exemple laissé par le programme qui a été précédemment exécuté.

Un système déterministe est au contraire un système où cela ne peut pas se produire. Ainsi, on exige de lui qu’il ait exactement le même comportement à conditions initiales identiques, autant de fois qu’on l’exécute. La raison pour laquelle il peut être souhaitable d’avoir un système déterministe est justement que l’on souhaite qu’il soit reproductible, en particulier en cas d’erreur – de crash. Si cela se produit, trouver la cause de l’erreur peut être particulièrement épineux avec un système complexe. Aussi avoir la possibilité de tester plusieurs fois le système, éventuellement en y introduisant des sondes (matérielles ou  logicielles) sans non plus remettre en cause son comportement apparent est extrêmement précieux.

Mentionnons cette blague caractérisant bien l’importance des systèmes critiques, dont la prise en compte est venue après les formidables gains de performance de l’informatique : « Si l’automobile avait progressé de la même façon que l’informatique, une Rolls-Royce coûterait aujourd’hui 100 dollars, ferait 300 000 kilomètres avec un seul litre d’essence et exploserait une fois par an en tuant tous ses passagers. » Heureusement, s’ils sont bien faits, les systèmes informatiques n’ont pas de raison de tuer leurs utilisateurs.

Du côté matériel, la performance implique aussi le poids, les dimensions, l’énergie consommée par le système. L’environnement d’utilisation peut être difficile. Ainsi les conditions d’utilisation sur le terrain peuvent être exigeantes – chaleur ou froid, humidité, chocs. L’environnement électromagnétique peut être sévère, c’est le cas par exemple dans les voitures. Le système peut devoir résister aux rayonnements, c’est le cas pour les avions et les systèmes spatiaux qui sont soumis aux rayons cosmiques, ou les systèmes proches de sources radioactives – réacteurs nucléaires, systèmes médicaux.

A cela s’ajoutent bien sûr les éventuels facteurs de forme et les éléments de marketing.

Regardons maintenant la vie du système dans le temps. Il y a deux cas : ceux de systèmes qui doivent accomplir une fonction à partir de leur mise en route, jusqu’à ce qu’ils soient déclassés, mais sans changement majeur; ceux dont on sait qu’ils vont évoluer plus ou moins fortement, voire en étant « éternels ».

Tout d’abord le système peut être plus ou moins disponible. La disponibilité du système de vol d’une fusée ou d’un avion a une certaine importance. Pour améliorer la disponibilité, le premier réflexe (juste) est de mettre en place de la redondance de matériel. Mais cela ne suffit pas. Il faut en effet prévoir les systèmes capables de gérer cette redondance de diverses façons – par exemple en faisant « voter » des systèmes indépendants pour prendre une décision importante, ou en étant capable de constater une panne, récupérer un état cohérent des calculs et de la mémoire, et redémarrer l’exécution des tâches en cours – tout cela avec en outre des garanties de service. Mais surtout il faut prendre en compte la disponibilité du logiciel. Or cela n’a pas du tout le même sens que pour du matériel : le logiciel ne tombe pas en panne, il peut par contre être incorrect par conception (bug). C’est la non prise en compte de l’indisponibilité du logiciel qui a été à l’origine de l’accident spectaculaire du premier vol d’Ariane 5[3]. Il y a désormais toute une panoplie d’outils et de méthodes pour « lutter contre les bugs ». Cela va de la preuve de propriétés sur le logiciel – qui permettent donc d’écarter toute une catégorie de bugs d’un coup – à des méthodes de test et de supervision du logiciel.

Joseph Sifakis

Le scientifique grec et français Joseph Sifakis a ainsi reçu en 2007 le prix Turing considéré comme le Nobel de l’informatique, avec ses collègues américains Edmund Clarke et Allen Emerson pour ses travaux sur le Model Checking, qui permet de vérifier et prouver le comportement temporel de programmes embarqués. Les résultats de Sifakis et de ses collègues ont été intensivement utilisés par Airbus pour le logiciel embarqué dans ses avions.

Ces questions de disponibilité ne se posent pas que pour les systèmes critiques comme les avions, mais par exemple aussi pour toutes les grandes infrastructures (énergie, télécoms, finance, etc.).

Outre être disponible, le système doit être capable d’évolution. En effet, il est rare qu’un

IP on everything

système reste inchangé durant toute sa durée de vie si celle-ci dépasse quelques années. Un des premiers facteurs d’évolution est la panne matérielle d’un de ses composants. Si celle-ci intervient on doit être capable de changer le composant. Le problème est qu’il peut arriver que ce composant ne soit plus disponible, en particulier pour des systèmes à durée de vie très longue comme des avions ou des systèmes électriques[4]. Dans ce cas il faut soit avoir prévu d’acheter à l’avance et de stocker pendant une durée très longue un grand nombre de composants (sous azote pour les composants électroniques voire pour les ordinateurs complets, afin d’éviter l’oxydation). Sinon il faut reconcevoir en partie le système, en étant capable de substituer le composant d’infrastructure incriminé par un autre à moindre coût. Les techniques de virtualisation, aident à cela, mais il s’agit d’un problème mal résolu à ce jour.

Pour ce qui concerne les évolutions logicielles, vous devez savoir que votre garagiste lorsque vous lui confiez votre voiture y charge les dernières versions des logiciels embarqués fournies par le constructeur – la voiture a quelque part une prise informatique pour cela. Mais les problèmes peuvent être complexes, car les logiciels modernes sont construits en utilisant un grand ombre de composants et d’outils sophistiqués. Or ceux-ci évoluent très rapidement, ainsi d’ailleurs que les environnements où ils s’exécutent – qui ont également une durée de vie plus courte qu’une voiture. La gestion de ces contraintes de durée de vie est donc complexe, à l’instar du matériel, et peut conduire à reconcevoir une partie du système.

Un élément à la fois de bonne conception et d’adaptation au cycle de vie est la modularité du système. Comme dans tout système industriel, cela est souhaitable. Le logiciel a cependant cette propriété de malléabilité extrême qui permet de générer du code à partir de briques de spécifications. On peut donc avoir des outils sophistiqués qui permettent à moindre coût de reconstruire le logiciel en changeant les paramètres ou briques indiquant par exemple le type de plate-forme sur laquelle il doit s’exécuter.

Au-delà de systèmes à cycle de vie constant, prévisible ou planifiable, on a les systèmes qui évoluent fortement. Le passage à l’échelle constitue la dimension quantitative de cette capacité d’évolution. Par exemple, l’Internet, initialement prévu pour quelques dizaines de machines, a subi un passage à l’échelle phénoménal (demain des dizaines de milliards d’objets avec une adresse IP). On a raison d’honorer son créateur, Vinton Cerf, notamment en lui ayant remis le prix Turing, car il s’agit d’un travail scientifique, de conception et d’ingénierie exceptionnel. Mais la question du passage à l’échelle se pose pour de nombreux autres systèmes, par exemple en terme de volume de données, d’utilisateurs connectés, de nombre de transactions, etc.

La capacité du système d’évoluer qualitativement est plus générale et plus difficile à définir. On sait par exemple que les objets intelligents qui vont équiper nos foyers et nos villes vont beaucoup évoluer, mais on ne sait pas comment. La durée de vie de ces systèmes est assez longue, au regard de celle des composants informatiques. Il va pourtant falloir résoudre cette quadrature du cercle.

Enfin pour clore cette liste non exhaustive, la sécurité constitue un des grands domaines de garantie de fonctionnement d’un système.