Bonsoir,
 
Que fait le CPU si une lecture en RAM prend plus que le temps d'un cycle d'horloge (la majorité des cas si hors cache L1 ou L2) en assembleur, il fait un nop ?
Sous la coupe d'un OS, il fait une interruption ?
 
Cdlt
GS

Généralement, oui, il attend  
Avec le "out of order", il va peut être exécuter d'autres instructions (indépendantes de l'instruction en attente), mais le délai de réponse de la RAM étant relativement long, je pense qu'il va très vite être bloqué.
Avec l'hyper-threading, par contre, l'autre thread peut en profiter pleinement
 
Par contre, ca ne dépend pas de l'OS. Il n'y a pas de code assembleur NOP qui est envoyé au proc. C'est lui qui gère en interne.

Avec un OS adapté moderne, je pense que même sans hyperthreading, ou sans processeur superscalaire, le cpu peut très bien envoyer une interruption (comme toutes les E/S asynchrones qui sont bloquantes) et provoquer un changement de thread, voir de contexte processus. L'accès à la RAM est forcemment asynchrone. Ca impliquerait un switch de thread à chaque accès en RAM (à l'exclusion des fameux caches biensûr) et ce sur au moins plusieurs threads. On parle d'un accès mémoire en RAM bien souvent 40 fois plus lent que l'accès au registre.
 
Apparemment l'essentiel serait donc dans le concept "out-of-order" dont tu parles. Je viens de survoler http://en.wikipedia.org/wiki/Out-of-order_execution. C'est vrai que brut de fonderie, c'est pas évident à imginer dans la structure d'un programme avec les dépendance plus le pipelining surtout dans la façon que peut se permettre le cpu de réagencer les instructions. Mais, tous les CPU n'en bénéficieraient pas pour économiser notamment de la surface de core. Notamment le Sparc de SUN ou encore l'itanium, rien que ça.
 
Accessoirement : les compteurs de cycles cpu consommés comme le gestionnaire de tâches de windows ou le vmstat de solaris, sait-on si le temps d'accès à la RAM est effectivement compté comme activité CPU ou Idle ou encore wio ?
 
Il me reste du boulot pour comprendre tous ces mécanismes.

Le problème, c'est qu'un changement de contexte (mettre un autre thread en exécution), c'est couteux aussi. Alors si on change de contexte à chaque accès, je sais pas si on y gagnera vraiment  
(surtout si la donnée qu'on attendait n'est plus dans le cache lorsque le thread revient)
 
C'est vrai que tous les procs n'ont pas le out-of-order. C'est très utile pour le x86, à cause de sa complexité. Sur ce point le principe de l'Itanium est très intéressant : l'idée d'Intel était que ce soit le compilateur qui fasse la recherche du meilleur ordonnancement des instructions, en économisant ainsi de la complexité au niveau du processeur  
 
Pour les compteurs, c'est du temps que le CPU passe dans le traitement de ce thread. Donc, je pense que c'est considéré comme activité CPU  
(idle, c'est quand il n'y a aucun thread en cours d'exécution sur le processeur)

Il faudrait que je remette la main sur les valeurs de changement de contexte thread/processus.
 
Windows et Linux programmeraient des interruptions vers des changements de contexte uniquement dans le cadre d'I/O autres que l'accès à la RAM ?
 
Concernant l'itanium, j'ai lu quelques trucs mais pourquoi ne s'est-il pas encore "imposé" ?
Comment se fait-il qu'on continue sur PC avec du CISC (uniquement pour la compatibilité du code binaire) ?

Oui, la compatibilité.
Et puis, ca marche pas si mal que ca, en fait