Nos journées s’organisent en fonction du temps qu’on peut ou on veut accorder à nos tâches quotidiennes. Chercher le pain : 15 minutes ; sortir les poubelles : 5 minutes ; voir un film : 95 minutes.
Ouvrir notre application préférée de «chat» ou du guidage sur la route ? Ouverture instantanée… quand c’est étrangement lent, on se demande immédiatement s’il ne faut pas acheter un nouveau téléphone ou changer d’application. En réalité, le temps des ordinateurs est le même que le nôtre : en demandant une réaction rapide à nos ordinateurs, nous faisons simplement face à une plus forte probabilité d’erreur de la part de l’ordinateur, qui peut mener à un « plantage ».
L’augmentation de cette probabilité se propage à tous les systèmes dotés d’un ordinateur. Si votre système de guidage par GPS plante au beau milieu d’un rond-point est surtout exaspérant, l’idée que l’ordinateur de bord d’un avion puisse planter dissuaderait quiconque d’embarquer.
Moins de temps, plus de risque d’erreurs
C’est bien le temps que l’on accorde à un ordinateur pour effectuer ses tâches qui lie la réaction du système et ses plantages. Plus précisément, le temps nécessaire à l’exécution d’une application sur un ordinateur.
Mesurons par exemple le temps nécessaire à une application de guidage GPS pour calculer un même trajet pendant un mois. Tous les matins à la même heure, en partant du même endroit et vers la même destination, on note le temps dont l’application a besoin pour nous fournir une réponse : on remarque des variations. Il se peut même qu’un beau matin, l’application se plante et doive redémarrer.
La répartition de ces « temps d’exécution » ressemblerait à ceci :
On voit que les temps d’exécution varient. Cette variation est due au « contexte d’exécution », voire à la « structure interne » de l’application. Notamment, la différence entre les valeurs mesurées maximale et minimale permet de comprendre pourquoi et comment l’application a besoin de plus ou moins de temps pour s’exécuter.
Par exemple, si l’application associée à la gestion du moteur d’une voiture doit réagir à deux coups de frein consécutifs de la part d’un conducteur, alors elle prendra un temps différent comparé au cas où le conducteur appuiera qu’une seule fois sur le frein. Le freinage fait partie du « contexte d’exécution ».
Ensuite, la même application aura un temps d’exécution plus long si le conducteur utilise le frein moteur ou au contraire accélère, en fonction des chemins différents proposés dans la structure de l’application.
Read more: Pourquoi l’intelligence artificielle se trompe tout le temps
En voiture ou en avion, on ne fait pas les mêmes choix pour concevoir les systèmes informatiques
De façon cruciale, le concepteur d’un système intégrant un ordinateur utilise la différence entre valeurs maximale et minimale pour dimensionner la puissance de calcul de l’ordinateur afin de permettre une exécution optimale de son système. Il ou elle va prévoir combien de temps l’application peut prendre : soit en choisissant une valeur moyenne, soit en choisissant un temps très long (qu’on appellera le « pire des cas »), si on veut être sûr de laisser assez de temps au système pour finir son calcul – une marge de sécurité en quelque sorte.
Par exemple, dans une application à bord d’une voiture, le concepteur considéra que la valeur « pire des cas » sera égale à (environ) une fois et demie la valeur maximale mesurée pendant des tests.
Dans un avion, la valeur « pire des cas » est estimée en utilisant des analyses beaucoup plus pessimistes. Cela explique notamment qu’aucun avion n’a jamais eu à notre connaissance un accident à cause d’un problème d’une mauvaise prise en compte du temps nécessaire à l’exécution de ses applications.
La situation est différente dans le monde de l’automobile avec un premier exemple des accélérations intempestives des véhicules chez Toyota en 2011. L’autorité américaine de transport a explicitement demandé au constructeur l’analyse des temps d’exécution de certaines applications au bord de ses voitures rencontrant des problèmes d’accélérations intempestives rencontrées par certaines voitures électriques (qui utilisent des programmes pour gérer les impulsions depuis les pédales). Récemment, d’autres constructeurs automobiles rencontrent des problèmes similaires, par exemple Tesla en 2021, mais l’absence d’une analyse disponible publiquement ne nous permet pas d’indiquer le lien possible entre ces incidents et des problèmes d’estimation des temps d’exécution de leurs applications.
De leur côté, les applications disponibles sur nos téléphones ou tablettes sont regardées plutôt du point de vue d’une valeur moyenne pour leur temps d’exécution. Cela explique qu’en général une application aura un bon comportement et que, de temps en temps, elle plante parce qu’elle n’aura pas eu le temps de finir son calcul, qui aura cette fois pris plus de temps que la valeur moyenne utilisée pour le « dimensionnement » du système (ordinateur, téléphone…). Souvent, ceci bloque le système dans sa totalité et il faut alors relancer tout le système, et pas seulement l’application causant le plantage.
Augmenter le nombre de cœurs de ses appareils : gagner du temps ou risquer le plantage ?
Afin d’obtenir des temps moyens d’exécution petits, les concepteurs de nos téléphones ou tablettes utilisent de plus en plus le parallélisme des ordinateurs. De fait, quand on veut choisir son nouvel ordinateur ou téléphone, on compare désormais le fameux « nombre de cœurs » des appareils concurrents. L’idée intuitive est de gagner en vitesse de calcul et d’exécution des applications.
Néanmoins, en diminuant le temps moyen nécessaire à la réalisation d’un programme par une application utilisant plusieurs cœurs, nous augmentons aussi la variabilité du temps d’exécution. En effet, cette diminution du temps moyen d’exécution est obtenue grâce à des mécanismes comme la mémoire cache. Une valeur qui est souvent utilisée par le programme sera gardée dans la mémoire cache, tout en augmentant le temps dédié à la lecture depuis la mémoire principale d’une valeur lue moins souvent. Pour lire cette dernière, le temps d’exécution inclura le temps d’accès à la mémoire cache (pour vérifier sa présence dans cette mémoire) auquel nous ajoutons le temps d’accès à la mémoire principale, en augmentant ainsi le temps d’exécution maximal.
Cela implique que le concepteur doit choisir : soit d’augmenter la puissance de calcul de l’ordinateur pour s’assurer qu’il finira le calcul à temps, soit prendre le risque d’avoir plus de valeurs de temps d’exécution qui dépassent la valeur moyenne choisie pour dimensionner le système, et donc plus de plantages. Ironie du sort, si on augmente la puissance de calcul en augmentant le nombre de cœurs, on étale encore la distribution des temps de calcul, et le problème peut s’amplifier…
On peut en fait comprendre quel choix a été fait par le concepteur d’un système en constatant le nombre de plantages de ce système.
Soyons rassurés, il n’y a toujours pas d’avion avec des applications critiques exécutés sur des ordinateurs à plusieurs cœurs, car leurs concepteurs sont conscients qu’en diminuant le temps moyen d’exécution d’une application, nous augmentons la probabilité d’une erreur temporelle.