Ramenons les temps d'accès d'une machine à l'échelle humaine, en posant qu'un accès à un registre dure une seconde.

Le chapitre 5 a nommé le problème — le processeur attend la mémoire. Le voici chiffré : entre un registre et la mémoire vive, il y a le rapport d'une seconde à trois minutes. Aucune astuce de programmation ne comble un tel écart. Ce qui le comble, c'est une hiérarchie de mémoires, et un pari statistique sur la façon dont les programmes accèdent aux données.

La pyramide, et pourquoi elle existe

On voudrait une mémoire à la fois rapide, vaste et bon marché. Les trois sont incompatibles : la technologie qui va vite coûte cher au bit et consomme, donc on n'en met pas beaucoup.

La solution est de superposer plusieurs technologies, la plus rapide et la plus petite au plus près du processeur :

1        registres      ~ 1 Kio        le plus rapide, le plus cher2        cache L1       ~ 64 Kio3        cache L2       ~ 512 Kio4        cache L3       ~ 32 Mio       partagé entre les cœurs5        mémoire vive   ~ 16 Gio6        SSD / disque   ~ 1 Tio        le plus lent, le moins cher

Chaque niveau contient un sous-ensemble du niveau inférieur, et sert de tampon pour lui. L'objectif est de donner l'illusion d'une mémoire aussi vaste que le disque et presque aussi rapide que le cache. Ce n'est pas une illusion gratuite : elle repose sur une propriété observée des programmes réels.

Le principe de localité

Un programme n'accède pas à la mémoire au hasard. Il le fait suivant deux régularités, et toute la hiérarchie repose sur elles.

La localité temporelle. Une case qui vient d'être utilisée a de fortes chances de l'être à nouveau bientôt. Une variable de boucle, un compteur, l'adresse de retour d'une fonction : on y revient à chaque tour.

La localité spatiale. Si une case est utilisée, ses voisines le seront probablement. Parcourir un tableau, exécuter des instructions consécutives, lire les champs d'une structure : tous ces accès sont contigus.

Le programme du chapitre 6 en est l'illustration parfaite. Les cinq instructions du corps de la boucle sont relues à chaque tour — localité temporelle — et se suivent en mémoire — localité spatiale. Les registres $t0 et $t1 sont écrits et relus sans cesse.

De là découle la décision de conception la plus importante du cache : on ne transfère jamais un mot isolé, on transfère une ligne de 32 ou 64 octets. Puisque les voisines seront probablement demandées, autant les rapporter tout de suite — le coût dominant est celui du déplacement, pas celui de la quantité.

Comment fonctionne un cache

Le cache est un petit tableau de lignes. Le processeur demande une adresse ; s'il la trouve c'est un succès (hit), sinon un échec (miss) et il faut aller au niveau inférieur.

Pour savoir où chercher, l'adresse est découpée en trois champs, et ce découpage est exactement la somme pondérée du chapitre 1 coupée en morceaux :

1        ┌──────────────┬──────────┬──────────────┐2adresse │   étiquette  │  index   │  déplacement │3        └──────────────┴──────────┴──────────────┘4             qui ?        où ?        quel octet5                                      dans la ligne

Le déplacement désigne l'octet dans la ligne : pour une ligne de 64 octets, 6 bits. L'index désigne l'emplacement du cache où cette adresse a le droit de se trouver : pour 128 emplacements, 7 bits. L'étiquette est tout le reste, et elle est stockée avec la ligne pour savoir laquelle des nombreuses adresses possibles y réside.

Trois organisations existent, et elles se distinguent par le nombre d'emplacements où une adresse peut aller.

La correspondance directe : un seul emplacement possible, calculé par l'index. Recherche immédiate, matériel minimal — mais deux adresses de même index se chassent mutuellement, même si le reste du cache est vide. C'est le conflit, et il est spectaculaire sur les parcours dont le pas est une puissance de deux.

Le totalement associatif : n'importe quelle ligne peut aller n'importe où. Aucun conflit, mais il faut comparer l'étiquette à toutes les lignes en parallèle — trop coûteux au-delà de quelques dizaines d'entrées.

L'associatif par ensembles est le compromis universellement retenu : le cache est découpé en ensembles de $k$ lignes, l'index désigne l'ensemble, et l'adresse peut occuper n'importe laquelle des $k$ voies. Avec $k = 4$ ou 8, les conflits deviennent rares pour un coût de comparaison modeste.

Mesurer, et les deux politiques

Le taux de succès $t$ est la proportion d'accès trouvés dans le cache. Le temps d'accès moyen s'en déduit :

Le calcul réserve une surprise, et c'est le point à retenir du chapitre. Avec un cache à 1 ns et une mémoire à 60 ns : à 95 % de succès, on obtient 3,95 ns ; à 99 %, 1,59 ns. Passer de 95 % à 99 % divise le temps moyen par 2,5, alors que le taux ne progresse que de quatre points. C'est parce que le terme d'échec est pondéré par un coût soixante fois supérieur — raison pour laquelle on parle plutôt du taux d'échec que du taux de succès : c'est lui qui pilote la performance.

Deux politiques restent à fixer.

Le remplacement : quelle ligne évincer quand l'ensemble est plein ? LRU (least recently used), qui sacrifie la moins récemment utilisée, est le choix naturel — c'est un pari direct sur la localité temporelle. Le cours de systèmes reprendra exactement cette question au chapitre 6, pour les pages en mémoire.

L'écriture : que faire quand le processeur écrit ? En écriture immédiate (write-through), on écrit dans le cache et dans la mémoire à la fois — simple, cohérent, lent. En écriture différée (write-back), on n'écrit que dans le cache, on marque la ligne « sale », et on ne recopie en mémoire qu'à son éviction — rapide, mais il faut gérer la cohérence, question qui devient épineuse dès qu'il y a plusieurs cœurs partageant des données.

ROM, SRAM, DRAM

Trois technologies, trois rôles, et les distinguer évite bien des confusions.

La ROM est non volatile : elle survit à la coupure de courant. Elle contient le micrologiciel qui démarre la machine — le processeur, au premier front d'horloge, va chercher son instruction à une adresse fixe qui pointe dans la ROM. Ses variantes modernes, EEPROM et mémoire flash, se réécrivent, ce qui permet les mises à jour de micrologiciel et fonde les SSD.

La SRAM stocke chaque bit dans une bascule — celle du chapitre 4, six transistors. Elle est rapide et tient son état tant qu'elle est alimentée, mais elle est encombrante et chère. C'est la mémoire des caches et des registres.

La DRAM stocke chaque bit dans un condensateur, avec un seul transistor. D'où sa densité, donc son prix bas au gigaoctet, donc son emploi comme mémoire principale. Mais le condensateur se décharge : il faut le rafraîchir toutes les quelques dizaines de millisecondes, en relisant et réécrivant chaque ligne. Ce rafraîchissement coûte du temps et de l'énergie, et c'est la raison de fond pour laquelle la DRAM est plus lente que la SRAM.

Toutes deux sont volatiles : contenu perdu à l'extinction. C'est ce qui rend nécessaire le système de fichiers du chapitre 7 du cours de systèmes.

Un mot de mémoire virtuelle

Le même raisonnement se rejoue un cran plus bas, entre la mémoire vive et le disque, et il porte alors le nom de mémoire virtuelle.

Chaque programme manipule des adresses logiques, qu'un composant matériel — l'unité de gestion mémoire — traduit en adresses physiques. La mémoire est découpée en pages de 4 Kio, et toutes les pages n'ont pas besoin d'être en mémoire vive : les autres attendent sur le disque, et le matériel signale un défaut de page quand on touche l'une d'elles.

Les analogies avec le cache sont exactes, terme à terme : la page est la ligne, le défaut de page est l'échec, l'algorithme de remplacement est le LRU, et la localité est ce qui rend le tout viable. Seuls les ordres de grandeur changent — et ils changent tellement, un facteur cent mille sur le coût de l'échec, que la gestion passe du matériel au logiciel. C'est pourquoi la mémoire virtuelle est traitée en détail par le cours de systèmes d'exploitation, chapitre 6, et seulement introduite ici.

À vous

L'exercice construit un simulateur de cache : découpage d'adresse en étiquette, index et déplacement, puis comptage des succès et des échecs sur une trace d'accès.

Deux expériences valent le détour, et ce sont celles du TD. La première compare la correspondance directe et l'associatif à deux voies sur un motif qui provoque des conflits. La seconde parcourt une matrice par lignes puis par colonnes : même nombre d'accès, même tableau, et un taux de succès qui s'effondre dans le second cas — c'est la localité spatiale rendue mesurable, et l'argument le plus convaincant du chapitre.

// Un cache associatif par ensembles. voies = 1 donne la correspondance
// directe, voies = nbLignes donne le totalement associatif.
function creerCache({ tailleLigne, nbLignes, voies }) {
  const ensembles = nbLignes / voies;
  const table = Array.from({ length: ensembles }, () => []);  // [etiquette, ...] par ensemble
  let succes = 0, echecs = 0;

  return {
    acceder(adresse) {
      // Découpage de l'adresse. Le déplacement dans la ligne ne sert pas à
      // localiser la ligne : on le jette en divisant.
      const numeroLigne = Math.floor(adresse / tailleLigne);
      const index = numeroLigne % ensembles;
      const etiquette = Math.floor(numeroLigne / ensembles);

      const jeu = table[index];
      const place = jeu.indexOf(etiquette);
      if (place !== -1) {
        succes++;
        // ← LRU : la ligne qu'on vient d'utiliser redevient la plus récente
        return true;
      }
      echecs++;
      jeu.push(etiquette);
      if (jeu.length > voies) jeu.shift();   // évince la plus ancienne
      return false;
    },
    bilan(nom) {
      const total = succes + echecs;
      const taux = ((succes / total) * 100).toFixed(1);
      console.log(nom.padEnd(34) + succes + " succès / " + total +
                  "  ->  " + taux + " % de succès");
      return succes / total;
    },
  };
}

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Le LRU est incomplet : en cas de succès, la ligne touchée doit
//    redevenir la plus récente. Sans cela, la politique est un simple FIFO.
// 2. Expérience 2 : écrivez le parcours PAR COLONNES et comparez.

const MOT = 4, LIGNE = 64, LIGNES = 64;

// Expérience 1 — deux tableaux distants d'un multiple exact de la taille du
// cache : leurs cases de même rang tombent sur le même index.
function alternance(voies) {
  const c = creerCache({ tailleLigne: LIGNE, nbLignes: LIGNES, voies });
  const A = 0, B = LIGNE * LIGNES;
  for (let tour = 0; tour < 4; tour++) {
    for (let i = 0; i < 64; i++) { c.acceder(A + i * MOT); c.acceder(B + i * MOT); }
  }
  return c.bilan("alternance, " + voies + " voie(s)");
}
alternance(1);
alternance(2);

// Expérience 2 — une matrice 64 x 64 d'entiers, rangée ligne par ligne.
const N = 64;
const adresseMatrice = (i, j) => (i * N + j) * MOT;

function parLignes() {
  const c = creerCache({ tailleLigne: LIGNE, nbLignes: LIGNES, voies: 2 });
  for (let i = 0; i < N; i++) for (let j = 0; j < N; j++) c.acceder(adresseMatrice(i, j));
  return c.bilan("matrice parcourue par lignes");
}
parLignes();
// ← écrivez parColonnes() : mêmes accès, ordre des boucles inversé

function creerCache({ tailleLigne, nbLignes, voies }) {
  const ensembles = nbLignes / voies;
  const table = Array.from({ length: ensembles }, () => []);
  let succes = 0, echecs = 0;

  return {
    acceder(adresse) {
      const numeroLigne = Math.floor(adresse / tailleLigne);
      const index = numeroLigne % ensembles;
      const etiquette = Math.floor(numeroLigne / ensembles);

      const jeu = table[index];
      const place = jeu.indexOf(etiquette);
      if (place !== -1) {
        succes++;
        // LRU : on retire la ligne de sa position et on la remet en queue,
        // qui est le bout « le plus récemment utilisé ». Sans ce geste, la
        // politique dégénère en FIFO et perd la localité temporelle.
        jeu.splice(place, 1);
        jeu.push(etiquette);
        return true;
      }
      echecs++;
      jeu.push(etiquette);
      if (jeu.length > voies) jeu.shift();
      return false;
    },
    bilan(nom) {
      const total = succes + echecs;
      const taux = ((succes / total) * 100).toFixed(1);
      console.log(nom.padEnd(34) + succes + " succès / " + total +
                  "  ->  " + taux + " % de succès");
      return succes / total;
    },
  };
}

const MOT = 4, LIGNE = 64, LIGNES = 64;

function alternance(voies) {
  const c = creerCache({ tailleLigne: LIGNE, nbLignes: LIGNES, voies });
  const A = 0, B = LIGNE * LIGNES;
  for (let tour = 0; tour < 4; tour++) {
    for (let i = 0; i < 64; i++) { c.acceder(A + i * MOT); c.acceder(B + i * MOT); }
  }
  return c.bilan("alternance, " + voies + " voie(s)");
}
alternance(1);   // conflit systématique : chaque accès chasse le précédent
alternance(2);   // deux voies suffisent à loger les deux tableaux

const N = 64;
const adresseMatrice = (i, j) => (i * N + j) * MOT;

function parLignes() {
  const c = creerCache({ tailleLigne: LIGNE, nbLignes: LIGNES, voies: 2 });
  for (let i = 0; i < N; i++) for (let j = 0; j < N; j++) c.acceder(adresseMatrice(i, j));
  return c.bilan("matrice parcourue par lignes");
}

function parColonnes() {
  const c = creerCache({ tailleLigne: LIGNE, nbLignes: LIGNES, voies: 2 });
  // Mêmes 4096 accès, dans un autre ordre. Chaque accès saute 64 mots, donc
  // change de ligne de cache : la ligne rapportée ne sert qu'une fois.
  for (let j = 0; j < N; j++) for (let i = 0; i < N; i++) c.acceder(adresseMatrice(i, j));
  return c.bilan("matrice parcourue par colonnes");
}

const a = parLignes();
const b = parColonnes();
console.log("Même tableau, mêmes accès, ordre inversé : " +
  (a / b).toFixed(1) + " fois plus de succès par lignes.");

En travaux pratiques

/* par lignes : voisins en mémoire */
for (i = 0; i < N; i++)
  for (j = 0; j < N; j++)
      somme += m[i][j];        /* 0,08 s */

/* par colonnes : un saut de N entiers à chaque accès */
for (j = 0; j < N; j++)
  for (i = 0; i < N; i++)
      somme += m[i][j];        /* 0,94 s  → 12 fois plus lent */

perf stat -e cache-misses ./parcours

par lignes   :     4 200 000 défauts de cache
par colonnes : 16 800 000 défauts de cache   (×4)

une ligne de cache fait 64 octets = 16 entiers
par lignes   : 1 défaut pour 16 éléments utilisés
par colonnes : 1 défaut pour 1 seul élément utilisé,
             les 15 autres sont chargés puis jetés

taille du tableau | ns par accès
    16 Ko       |  1,1     ← tient en L1
    64 Ko       |  1,2
   256 Ko       |  3,8     ← marche : on est passé en L2
     2 Mo       |  4,1
    16 Mo       | 14,7     ← marche : on est passé en L3
   128 Mo       | 92,3     ← marche : mémoire centrale

/* ordre i, j, k : B parcouru par COLONNES */
for (i…) for (j…) for (k…) C[i][j] += A[i][k] * B[k][j];   /* 8,2 s */

/* ordre i, k, j : B parcouru par LIGNES */
for (i…) for (k…) for (j…) C[i][j] += A[i][k] * B[k][j];   /* 2,1 s */

for (ii = 0; ii < N; ii += B)
for (kk = 0; kk < N; kk += B)
  for (jj = 0; jj < N; jj += B)
    for (i = ii; i < ii+B; i++)
      for (k = kk; k < kk+B; k++)
        for (j = jj; j < jj+B; j++)
          C[i][j] += A[i][k] * B[k][j];

B = 64 → 0,7 s   (3 blocs de 64×64 entiers ≈ 48 Ko, tiennent en L2)

Ce que la suite en fait

Le chapitre 8 termine le tour de la machine par les entrées/sorties, dont les temps sont ceux de la dernière ligne du tableau d'ouverture — d'où les interruptions et l'accès direct à la mémoire, qui existent précisément pour ne pas faire attendre le processeur.

La loi d'Amdahl y formalisera ce que le calcul du taux d'échec a déjà fait pressentir : accélérer une partie d'un système donne un gain global borné par la part que cette partie occupe. Et le pipeline montrera la dernière raison d'être du cache : sans lui, un processeur capable de terminer une instruction par cycle passerait l'essentiel de son temps arrêté.

À retenir

Un processeur à 3 GHz exécute environ trois milliards d'opérations élémentaires par seconde. Entre deux frappes au clavier d'un utilisateur rapide, il en a le temps de trois cents millions. S'il attendait cette frappe en surveillant le clavier, il consumerait trois cents millions de cycles à ne rien faire d'utile.

Ce dernier chapitre traite de cette disproportion, et de la question qu'elle pose : comment une machine dialogue-t-elle avec un monde des milliers de fois plus lent qu'elle sans s'y aligner ? Puis il donne les outils pour répondre à la question qui clôt le cours : cette machine, finalement, est-elle rapide ?

Contrôleurs et bus

Le processeur ne parle jamais directement à un périphérique. Entre les deux se trouve un contrôleur, circuit spécialisé qui connaît les détails électriques et mécaniques du matériel et présente au processeur une interface uniforme : quelques registres.

Trois registres suffisent à décrire presque tout contrôleur. Un registre de commande, où le processeur écrit ce qu'il veut. Un registre d'état, qu'il lit pour savoir où en est l'appareil — prêt, occupé, en erreur. Un registre de données, par lequel l'information transite.

Reste à savoir comment le processeur atteint ces registres. Deux écoles. Les entrées/sorties mappées en mémoire leur donnent des adresses ordinaires, dans le même espace que la mémoire : un lw ou un sw du chapitre 6 suffit, sans instruction spéciale, et une partie de l'espace d'adressage est réservée à cet usage. Les entrées/sorties par ports leur donnent un espace d'adressage séparé, avec des instructions dédiées. La première approche domine, parce qu'elle n'ajoute rien au jeu d'instructions — et le cours de systèmes montrera qu'elle permet à un pilote de manipuler un périphérique comme une structure en mémoire.

Trois façons d'attendre

Voilà le cœur du chapitre. Le processeur a demandé une lecture au disque ; celle-ci prendra dix millisecondes, soit trente millions de cycles. Que fait-il pendant ce temps ?

La scrutation (polling). Il boucle sur le registre d'état jusqu'à ce que le bit « prêt » passe à 1. C'est trivial à programmer et parfaitement inefficace : trente millions de cycles brûlés à relire la même case. La scrutation garde pourtant deux usages légitimes — les systèmes sans interruptions, et les périphériques si rapides que le détour par une interruption coûterait plus cher que l'attente.

Les interruptions. Le processeur lance l'opération et passe à autre chose. Quand le périphérique a fini, il lève un signal sur le bus de contrôle. Le processeur termine l'instruction en cours, sauvegarde son état — compteur ordinal, registres, registre d'état —, exécute la routine de traitement de cette interruption, puis restaure l'état et reprend exactement où il en était.

Ce mécanisme est bien plus qu'une optimisation d'entrées/sorties : c'est la condition d'existence du multitâche. Une interruption d'horloge périodique permet au système d'exploitation de reprendre la main à intervalles réguliers, donc de retirer le processeur à un programme qui ne le rend pas. Le chapitre 4 du cours de systèmes en fera le fondement de la préemption.

L'accès direct à la mémoire (DMA). Les interruptions règlent l'attente, pas le transfert : sans DMA, le processeur doit encore copier lui-même chaque mot du contrôleur vers la mémoire. Pour un fichier de dix mégaoctets, c'est deux millions et demi de transferts. Le contrôleur DMA prend ce travail en charge — le processeur lui indique adresse, taille et sens, puis retourne à son calcul ; une seule interruption signale la fin du bloc entier.

Mesurer la performance

Le chapitre 5 a donné la formule ; il est temps de s'en servir et d'en tirer les conséquences.

Trois facteurs, et trois responsables différents. Le nombre d'instructions dépend du programme, du compilateur et du jeu d'instructions. Le CPI dépend de la microarchitecture — un processeur pipeliné vise 1, voire moins. La fréquence dépend de la technologie de gravure.

D'où la mise en garde centrale : comparer deux machines sur leur seule fréquence n'a pas de sens, puisqu'il manque deux facteurs sur trois. Un processeur à 2 GHz avec un CPI de 1 est plus rapide qu'un processeur à 3 GHz avec un CPI de 2.

Les indicateurs synthétiques ont le même défaut. Les MIPS — millions d'instructions par seconde — ne comparent que des machines de même jeu d'instructions, sans quoi on compte des instructions qui ne font pas la même chose. Les FLOPS ne mesurent que le calcul flottant. Seule mesure honnête : le temps d'exécution d'un programme réel et représentatif de l'usage visé, ce que cherchent les jeux d'essai normalisés comme SPEC.

La loi d'Amdahl

Reste le résultat le plus utile du chapitre, et le plus souvent ignoré en pratique. On accélère une portion d'un programme d'un facteur $k$ ; cette portion représente une fraction $p$ du temps total. L'accélération globale vaut :

Le passage à la limite est brutal. Si $k$ tend vers l'infini — la portion devient instantanée — l'accélération plafonne à $1/(1-p)$. Ce qu'on n'accélère pas fixe le plafond.

Un exemple, avec $p = 0{,}6$ et $k = 10$ : on divise par dix les trois cinquièmes du temps, et l'accélération globale n'est que de $1/(0{,}4 + 0{,}06) = 2{,}17$. Même en rendant cette portion instantanée, on ne dépasserait jamais 2,5.

La leçon pratique tient en une phrase : mesurer avant d'optimiser. Diviser par cent une fonction qui occupe 2 % du temps fait gagner 2 %. L'intuition du programmeur sur l'endroit où son programme passe son temps est, statistiquement, fausse.

Pipeline et parallélisme

Une dernière question : comment descendre le CPI en dessous de 1 par instruction ?

Le pipeline répond en découpant l'exécution en étages — typiquement recherche, décodage, exécution, accès mémoire, écriture du résultat — et en les faisant travailler simultanément sur des instructions différentes. C'est la buanderie : pendant que le second tambour lave, le premier sèche, et le troisième se plie. La latence d'une instruction n'a pas diminué, mais le débit est multiplié par le nombre d'étages.

Trois obstacles, appelés aléas, l'empêchent d'atteindre ce facteur idéal. Les aléas de données : une instruction a besoin d'un résultat que la précédente n'a pas encore écrit. Les aléas de contrôle : après un branchement, on ne sait pas quelle instruction charger — et le chapitre 6 a montré que les branchements sont partout, d'où la prédiction de branchement, qui parie sur l'issue et annule les instructions engagées si le pari est perdu. Les aléas structurels : deux étages veulent la même ressource matérielle au même cycle.

Au-delà du pipeline, trois formes de parallélisme se cumulent. Le superscalaire duplique les unités pour lancer plusieurs instructions par cycle. Les instructions vectorielles appliquent une même opération à plusieurs données à la fois. Et le multicœur met plusieurs processeurs complets sur la même puce — la voie choisie depuis 2005, quand l'augmentation des fréquences s'est heurtée au mur de la consommation thermique.

Le multicœur ramène directement à Amdahl, et c'est sur ce lien que le cours se referme : doubler le nombre de cœurs ne double la performance que si le programme est parallélisable d'un bout à l'autre. Il ne l'est jamais. La partie séquentielle — lecture du fichier d'entrée, synchronisation entre tâches, écriture du résultat — impose son plafond, et c'est elle, pas le matériel, qui décide de ce que la machine vaudra.

À vous

L'exercice met en chiffres les deux résultats du chapitre. D'abord la loi d'Amdahl, appliquée à plusieurs scénarios d'optimisation, dont un piège classique : accélérer énormément une portion minuscule. Ensuite un compteur de cycles de pipeline, qui compare l'exécution séquentielle, le pipeline idéal, et le pipeline avec les bulles qu'imposent les aléas.

Le second calcul donne le chiffre que le cours cherchait depuis le chapitre 5 : le CPI réel, et l'écart entre la promesse du pipeline et ce qu'il tient.

// ── 1. La loi d'Amdahl ────────────────────────────────────────────────────
// p : fraction du temps occupée par la portion accélérée
// k : facteur d'accélération de cette portion
function amdahl(p, k) {
  return 0;   // ← à écrire : 1 / ((1 - p) + p / k)
}

const SCENARIOS = [
  { nom: "60 % du temps, accéléré x10", p: 0.60, k: 10 },
  { nom: "60 % du temps, accéléré x1000", p: 0.60, k: 1000 },
  { nom: "2 % du temps, accéléré x100", p: 0.02, k: 100 },
  { nom: "95 % du temps, accéléré x8", p: 0.95, k: 8 },
];

for (const s of SCENARIOS) {
  const a = amdahl(s.p, s.k);
  const plafond = 1 / (1 - s.p);
  console.log(s.nom.padEnd(34) + "accélération x" + a.toFixed(2) +
              "   (plafond x" + plafond.toFixed(1) + ")");
}

// ── 2. Cycles d'un pipeline ───────────────────────────────────────────────
// n instructions, e étages. Sans pipeline chacune prend e cycles. Avec
// pipeline, le premier résultat sort après e cycles puis un par cycle —
// sauf quand un aléa impose des bulles.
function cycles(n, e, bulles) {
  const sequentiel = n * e;
  const pipeline = 0;   // ← à écrire : e + (n - 1), plus les bulles
  return { sequentiel, pipeline };
}

// Le programme du chapitre 6 : 12 instructions exécutées, dont 3 branchements.
// Un branchement mal prédit coûte 2 bulles.
const N = 12, ETAGES = 5, BRANCHEMENTS = 3;

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Écrivez amdahl et cycles.
// 2. Comparez le CPI avec une prédiction parfaite, puis avec une prédiction
//    qui se trompe une fois sur deux. Que devient l'écart au pipeline idéal ?

const r = cycles(N, ETAGES, 0);
console.log("séquentiel :", r.sequentiel, "cycles | pipeline idéal :", r.pipeline);

function amdahl(p, k) {
  // La portion accélérée passe de p à p/k ; le reste, (1 - p), ne bouge pas.
  // L'accélération est l'inverse du nouveau temps total.
  return 1 / ((1 - p) + p / k);
}

const SCENARIOS = [
  { nom: "60 % du temps, accéléré x10", p: 0.60, k: 10 },
  { nom: "60 % du temps, accéléré x1000", p: 0.60, k: 1000 },
  { nom: "2 % du temps, accéléré x100", p: 0.02, k: 100 },
  { nom: "95 % du temps, accéléré x8", p: 0.95, k: 8 },
];

for (const s of SCENARIOS) {
  const a = amdahl(s.p, s.k);
  const plafond = 1 / (1 - s.p);
  console.log(s.nom.padEnd(34) + "accélération x" + a.toFixed(2) +
              "   (plafond x" + plafond.toFixed(1) + ")");
}
// Deux enseignements. Accélérer x1000 au lieu de x10 sur la même portion ne
// fait passer que de 2,17 à 2,49 : on est déjà collé au plafond. Et une
// portion de 2 % accélérée x100 ne rapporte que 2 % — c'est l'optimisation
// que le programmeur choisit spontanément, et elle ne sert à rien.

function cycles(n, e, bulles) {
  const sequentiel = n * e;
  // Le premier résultat sort après e cycles de remplissage, puis un par
  // cycle pour les n - 1 suivants. Chaque bulle décale tout d'un cycle.
  const pipeline = e + (n - 1) + bulles;
  return { sequentiel, pipeline };
}

const N = 12, ETAGES = 5, BRANCHEMENTS = 3;

console.log("");
for (const [nom, tauxErreur] of [["prédiction parfaite", 0], ["une erreur sur deux", 0.5]]) {
  const bulles = BRANCHEMENTS * tauxErreur * 2;
  const r = cycles(N, ETAGES, bulles);
  console.log(
    nom.padEnd(22) +
    "séquentiel " + String(r.sequentiel).padStart(3) +
    " | pipeline " + String(r.pipeline).padStart(3) +
    " | CPI " + (r.pipeline / N).toFixed(2) +
    " | accélération x" + (r.sequentiel / r.pipeline).toFixed(2)
  );
}
// Le CPI idéal de 1 n'est jamais atteint : les 4 cycles de remplissage le
// tirent à 1,33 sur douze instructions seulement, et les branchements mal
// prédits ajoutent leurs bulles. Sur un programme long, le remplissage
// s'amortit — les branchements, non.

En travaux pratiques

write octet par octet   : 2,84 s   1 048 576 appels système
write par blocs de 4 Ko : 0,004 s        256 appels système
fputc octet par octet   : 0,012 s        256 appels système

(2,84 - 0,004) s / (1 048 576 - 256) appels ≈ 2,7 µs par appel

pourquoi : passage en mode noyau, changement de contexte,
vérification des arguments, retour en mode utilisateur
soit environ 8 000 cycles pour écrire UN octet

sans fsync : 0,004 s
avec fsync : 3,10 s   (×775)

sans fsync, « écrit » signifie : le noyau a la donnée en cache
avec fsync, « écrit » signifie : le disque l'a réellement

opération                      temps      à l'échelle d'une seconde
accès registre                0,3 ns     1 seconde
accès cache L1                  1 ns     3 secondes
accès mémoire centrale        100 ns     5 minutes
appel système                 2,7 µs     2,5 heures
lecture SSD (4 Ko)             80 µs     3 jours
aller-retour réseau local     500 µs     19 jours
lecture disque mécanique       10 ms      1 an

Ce que la suite en fait

Ce chapitre clôt l'architecture, mais il ouvre le cours de systèmes d'exploitation, et de façon très directe. L'interruption d'horloge y devient l'ordonnancement préemptif du chapitre 4. Le contrôleur et ses registres y deviennent le pilote de périphérique du chapitre 8. Les entrées/ sorties mappées en mémoire y rencontrent la pagination du chapitre 6.

Et la disproportion par laquelle ce chapitre commençait — trois cents millions de cycles entre deux frappes — y trouve sa véritable réponse : elle ne se comble pas, elle se remplit, en donnant le processeur à un autre programme pendant l'attente. C'est le multitâche, et c'est tout le sujet du cours suivant.

À retenir