Comment gérer les différentes rapidités des composants dans un ordinateur ?

Bonjour,

en concevant des circuits qui ne seront jamais réalisés en vrai, je me suis rendu compte que pour un système synchrone, le délai le plus grand conditionne la fréquence d’horloge, c’est-à-dire que même si je suis capable de faire des additions très rapidement, la fréquence d’horloge étant fixée, si la mémoire est lente, je vais devoir ralentir la fréquence d’horloge pour qu’il ne se passe pas n’importe quoi. J’ai aussi été étonné par l’absence de composants avec des délais en dessous de 1ns, alors que les CPU actuels dépasse largement le GHz.

Comment s’en sort-on ?

Merci !

Bonjour,

Parmi les éléments qui te permettent de répondre :

Il faut distinguer la latence et la fréquence d’horloge. Un processeur est plus compliqué qu’une machine qui exécute instruction par instruction. Il y a un découpage de son fonctionnement en plusieurs étapes (pipeline). Par exemple le pipeline classique sur ARM est le Fetch, Decode, Execute. Il effectue a chaque coup d’horloge ces 3 opérations. Plus tu augmentes la taille de ton pipeline, et plus tu vas pouvoir augmenter ta fréquence d’horloge puisque tu vas travailler sur plus d’instructions en même temps. Néanmoins, avec un pipeline long tu enchaînes beaucoup de composants et tu te prends le temps de réponse de tous les composants en latence (on peut en très gros dire que ta latence va être le temps pour traverser tout le pipeline, en oubliant pleins de trucs).

Ca permet notamment de comprendre que les performances d’un processeur ne viennent pas vraiment que de sa fréquence d’horloge. Par exemple, Intel a essayé de faire des processeurs à plus de 100 étapes de pipeline à une époque, juste parce que c’était l’argument qui permettait de vendre. Ça n’a pas très bien fonctionné pour eux et ils sont revenu à des pipelines plus conventionnels.

Bref, c’est possible, parce que ce sont des notions assez déliées dans les architectures processeurs actuelles.

Merci de la réponse,

mais je ne comprends pas très bien. Du coup, de quoi parle-t-on quand on parle de la fréquence d’horloge d’un CPU, s’il n’y rien qui fonctionne vraiment à la fréquence d’horloge ?

L’autre partie de la question est comment tout cela fonctionne-t-il avec des périphériques externes qui ont un temps de réponse bien plus lent (RAM, et tout le reste).

Merci !

Bah c’est pourtant simple, qui peut le plus, peut le moins.

Le CPU ne communique pas avec les périphériques externes à la fréquence d’horloge maximale. En fait le CPU a une horloge de base (souvent à 21 MHz environ) et grâce à des mécanismes internes (des PLL), il peut générer d’autres fréquences dont celle au delà du GHz pour le fonctionnement interne mais aussi celles pour la mémoire, le PCIe, etc.

En fait, chaque zone du CPU a sa propre fréquence d’horloge pour communiquer correctement avec les autres périphériques extérieurs comme la RAM. La fréquence d’horloge commerciale n’est qu’une fréquence parmi d’autres pour le processeur. Cependant cette fréquence conditionne les performances du processeur car de nombreuses opérations utilisent un cycle du processeur à cette fréquence donnée (des opérations simples, notamment au sein du pipeline).

Du coup, avoir une fréquence d’horloge plus grande que celle de la RAM n’a d’intérêt que si on stocke des instructions qui prennent plusieurs coups d’horloge (et c’est le cas de toutes, en faites), c’est ça ?

Comment est-on sûr, du point de vue du CPU, d’avoir reçu les informations de la RAM ? Rien ne garantit que l’on n’y accède pas trop rapidement, vu qu’on ne connaît pas la fréquence maximale d’accès de la RAM, si ?

Plus généralement, comment fait-on, techniquement, pour faire fonctionner un composant avec un autre qui est plus rapide ou plus lent ? Il faut bien que le plus lent informe le plus rapide de ralentir les échanges et à quel point, non ?

Merci beaucoup ?

Du coup, avoir une fréquence d’horloge plus grande que celle de la RAM n’a d’intérêt que si on stocke des instructions qui prennent plusieurs coups d’horloge (et c’est le cas de toutes, en faites), c’est ça ?

Déjà tu oublies qu’un processeur a de la mémoire cache pour permettre de travailler un peu dans son coin sans solliciter la RAM et les temps d’accès à la cache est très rapide (plus que la RAM, logique).

Ensuite le processeur a bien entendu assez d’instructions stockés pour travailler sans solliciter la RAM systématiquement et n’enregistrer ou lire les valeurs suivantes que quand ce sera nécessaire.

Comment est-on sûr, du point de vue du CPU, d’avoir reçu les informations de la RAM ? Rien ne garantit que l’on n’y accède pas trop rapidement, vu qu’on ne connaît pas la fréquence maximale d’accès de la RAM, si ?

Bah si, le processeur sait à quelle vitesse fonctionne tous les composants avec qui il communique, RAM incluse. Soit via un protocole standard, soit fixé par le constructeur / programmeur soit par une ligne d’horloge. Du coup il sait dialoguer avec sans difficulté vu qu’il le fera à la bonne vitesse.

En théorie, l’accès à la ram prend environ 800 cycles. En pratique, on utilise un cache au niveau du processeur pour stocker les instructions/données qui vont potentiellement être utilisées dans un futur proche. Cela réduit drastiquement les accès en cas de cache hit.

Pour répondre à ta question, la fréquence à laquelle communiquer est connue des deux périphériques (processeur, mémoire). Je connais très mal les architectures PC mais certains microchips en ARM ont des circuits dédiés à la manipulation de la mémoire et peuvent même bypasser le processeur pour aller plus vite sur les opérations type copie (DMA, pour direct memory access). Lorsque le processeur aura besoin des données, il vérifiera si elles sont disponibles, sinon il essayera de faire autre chose, sinon il "stall" et ne fait rien tant que les données sont absentes.

D’accord, merci beaucoup !

Une question : comment ils savent, du coup, la vitesse de communication ? Sur mon ordinateur, si je change de RAM, je peux en mettre une plus rapide, comment le processeur saura-t-il ?

Merci !

Pour la RAM (modules DIMM et SO-DIMM) d’un PC les informations comme le type de RAM (DDR, DDR2, etc.) le nombre de banques, certains timings, etc. sont stockées sur une petite mémoire EEPROM accessible par I2C/SMBus.

C’est standardisé par le JEDEC sous le nom de SPD (Serial Presence Detect).

Le BIOS vient lire les infos au POST et configure le contrôleur mémoire.

https://en.wikipedia.org/wiki/Serial_presence_detect
https://www.jedec.org/standards-documents/docs/spd-40102 (faut s’enregistrer (gratuitement) pour télécharger la norme)

Sur des cartes embarqués, quand on soude directement les modules mémoires, en général on rentre la configuration (timings) en dur dans le bootloader qui vient initialiser le contrôleur mémoire.

D’accord ! Merci beaucoup !

Donc au moment où le processeur lit une instruction qui lui dit de lire sur la RAM, par exemple, il doit se mettre dans un état dans lequel il saura qu’il doit attendre qu’un cycle d’horloge plus lent se soit déroulé, c’est juste ?

Comment il s’y prend, en pratique ?

Merci !

Le problème de ta question c’est que tu simplifie l’accès à la RAM à "le processeur lit une instruction qui lui dit de lire sur la RAM", ce n’est pas comme cela que ça fonctionne.

La RAM est gérée par un contrôleur (car je parle de DDR, DDR2, DDR3, etc. et non de RAM interne), c’est donc un module comme un autre et l’accès va être fait de manière "classique" en demandant un accès en lecture ou en écriture à la RAM.

Le processeur va envoyer les données à écrire, par exemple, au contrôleur RAM et ce dernier va gérer tout l’accès physique à la RAM pour que ce soit transparent. Je ne m’intéresse pas suffisamment au fonctionnement interne des processeur, mais je suppose que derrière le contrôleur va prévenir quand l’écriture est finie, si elle s’est bien passée, etc.
Je suppose aussi que le contrôleur dispose d’interruptions pour éviter de bloquer le processeur : ce dernier envoie les données au contrôleur et peut faire autre chose en attendant l’interruption indiquant que le transfert est fini.

De même pour la lecture, le processeur va faire une demande pour venir lire les données à une adresse spécifique et le contrôleur va se charger de l’accès physique et renvoyer la donnée.

Pour le détail, il faut aller lire les reference manual.

Par exemple le NXP i.MX6 Ultra Lite : http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6ULRM.pdf (Chapter 33, page 2003 pour le contrôleur mémoire)

zeqL a tout dit. Grossomodo, sur ARM tu as lesdites instructions "le processeur lit une instruction qui lui dit de lire sur la RAM". C’est "LDR" et ses variantes. Tu peux avoir plusieurs politiques, mais c’est en gros des circuits supplémentaires qui s’intègrent sur les différentes étages du pipeline. Les autres processeurs ont généralement une gestion différente de la mémoire. La plupart du temps les processeurs qu’on utilise ont une MMU qui est le circuit qui va protéger et gérer la mémoire, et dialoguer avec le processeur pour les accès mémoires.

Merci beaucoup de ces réponses !

Donc quand je fais un mov entre une adresse qui désigne la RAM et un registre, il y a en fait derrière plusieurs instructions ?

zeql, tu dis que le contrôleur dispose certainement d’interruption pour ne pas bloquer le processeur. Une interruption, c’est pas une routine indépendante qui est lancée pendant un programme, qui bloque celui-ci en sauvant son état et qui a sa fin restaure son état ? Le CPU ne peut rien faire d’autre, vu qu’il est occupé à la routine (je considère un CPU pas parallèle du tout), c’est ça ? Ou alors, il existe d’autre type d’interruptions, mais je ne comprends pas bien.

Merci beaucoup !

EDIT: en fait, j’ai dit nawak sur les interruptions, donc je retire ma remarque.