#Architecture & systèmesCopier le lien

Ce cours met des images mentales derrière les mots « CPU », « mémoire », « E/S », « processus ». L'idée: comprendre juste assez du matériel pour expliquer des phénomènes invisibles (latences de cache, blocages d'E/S) et prendre de meilleures décisions côté logiciel.

Contexte pédagogique: ce module s'inscrit dans les attentes de L1 de la Licence d'Informatique (Valrose — UCA) pour asseoir des bases solides utilisables ensuite en programmation, systèmes et réseaux.

#Prérequis et objectifsCopier le lien

Prérequis: savoir écrire un petit programme (variables, boucles, fonctions), connaître la représentation binaire des entiers et se servir d'un terminal.

À l'issue du module, vous devez savoir:

• dérouler le cycle fetch–decode–execute d'un programme simple et dire ce que le matériel exécute réellement;
• expliquer pourquoi un parcours séquentiel est plus rapide qu'un parcours par sauts, en parlant lignes de cache et localité;
• décrire les services d'un OS (processus, mémoire virtuelle, fichiers, E/S) et observer un appel système avec strace;
• distinguer processus et threads, et protéger une section critique partagée.

#CPU et mémoire: pourquoi c'est rapide… et parfois nonCopier le lien

Le CPU enchaîne des instructions et lit des données depuis la mémoire. Comme la mémoire principale est trop lente, des caches (L1/L2/L3) gardent au chaud ce qui vient d'être utilisé. L'architecture de Von Neumann met code et données dans le même espace: simple, mais cela demande de la prudence (prédiction de branchement, invalidation de cache) pour garder le pipeline bien rempli.

Le point clé pour le développeur: chaque niveau de la hiérarchie est 3 à 10 fois plus lent que le précédent, sur plusieurs ordres de grandeur. Un même algorithme peut varier d'un facteur 10 selon l'ordre des accès mémoire, sans changer une ligne de logique.

#Entrées/sorties: parler avec le mondeCopier le lien

Disques et réseaux traversent des bus (PCIe). Les interruptions réveillent le CPU quand « quelque chose s'est passé ». Le DMA autorise les périphériques à déposer des blocs en mémoire sans monopoliser le CPU. D'où un conseil pratique: lisez/écrivez en blocs raisonnables, et tamponnez ce qui peut l'être.

Conséquence directe: un programme qui lit octet par octet paie un aller-retour système par octet, un programme qui lit par blocs de 64 KiB amortit ce coût. La page « Systèmes d'exploitation » montre comment le voir avec strace.

#L'OS comme traducteur haut niveauCopier le lien

Le noyau expose des abstractions: processus, fichiers, sockets. Il planifie le CPU, gère la mémoire (pagination, TLB), arbitre les E/S et isole les applis. Vous entrez dans ce monde via des appels système (read, write, fork, exec). Savoir que read peut, selon le cache, ne pas toucher le disque, aide à expliquer vos profils de performance.

#Processus et threads: isolation vs concurrenceCopier le lien

Un processus est un espace mémoire isolé; un thread est un flux d'exécution qui partage la mémoire du processus. Les threads permettent de paralléliser mais exigent une synchronisation explicite (mutex, sémaphores). Concevoir l'ordre de prise de verrous et limiter les sections critiques évite les conditions de course et les interblocages.

#Mini-atelier observableCopier le lien

Objectif: mesurer, pas croire. Chaque_question se vérifie par une commande et un chiffre.

1. E/S par blocs: écrivez un lecteur de fichier ligne par ligne, puis un lecteur par blocs de 64 KiB, en chronométrant avec time.perf_counter(). Faites varier la taille de bloc (4 KiB, 64 KiB, 1 MiB) et notez le débit en Mo/s.
2. Condition de course: lancez deux threads qui incrémentent 100 000 fois chacun un compteur partagé, sans verrou, puis avec threading.Lock.
3. Appels système: observez la différence avec strace -c -e trace=read python3 lecteur.py entre les deux versions.

Résultats attendus (à vérifier chez vous): la lecture par blocs affiche un débit nettement supérieur à la lecture ligne à ligne sur un gros fichier; sans verrou, le total final est souvent inférieur à 200 000 et varie entre deux exécutions; avec verrou, le total vaut exactement 200 000 à chaque exécution. Si vos chiffres ne suivent pas ces tendances, demander pourquoi est exactement le but de l'atelier.