De ce que j'en ai compris (il est possible que le post contienne des erreurs) , le deuxième thread est créé uniquement quand le premier a besoin de données qui ne sont pas disponibles (typiquement des données de la mémoire non en cache). Et c'est fait automatiquement par le processeur.
Alors, le premier se met en sommeil et le deuxième thread continue ce qu'il est possible de faire du premier sans utiliser ces données (par exemple, quelques unes instructions suivantes ne font pas tout de suite appel aux données manquantes et peuvent être calculées pendant ce temps ; mais il s'agit également de calculer des adresses de sauts (prédiction de chanchement), du chargement des instructions suivantes, du prefetch de cache). Elles n'ont pas besoin d'être recalculées ensuite par le thread initial, qui dès qu'il aura récupéré la donnée de la mémoire, pourra utiliser immédiatement les précalculs effectués par le thread de surveillance et continuer sa tâche.
Toutes les instructions qui n'ont pas pu être exécutées car dépendantes de la donnée manquante sont chargées dans une file qui sera parcourue par le thread principal quand il aura obtenu ses données. Les autres peuvent être exécutées tout de suite.
C'est une sorte d'out-of order simplifié : l'out-of-order traditionnel cherche à effectuer tout de suites les instructions dont les opérandes sont immédiatement disponibles, et à conserver les résultats. Cela revient à se dire : "j'ai telle et telle donnée en registre, qu'est-ce que je pourrais faire avec avant de les envoyer dans le cache ou ailleurs pour faire autre chose ? Y a-t-il une instruction qui les utilise quelque part dans la suite, et que je pourrais faire tout de suite pour gagner du temps après ?"
Alors qu'ici, l'approche serait plutôt : "Il me manque une donnée. Dans le flot d'instructions, quelles sont les instructions suivantes qui n'en dépendent pas et que je peux effectuer en attendant ?"
(et mon avis personnel serait qu'idéalement le travail d'ordonnancement des instructions soit fait par le compilateur. En effet, il devrait pouvori déterminer lui-même quelles sont les instructions qui ne dépendent pas d'une autre, et prévoir quand les fautes de cache arrivent.)
[^] # Re: "scout" thread ?
Posté par khivapia . En réponse au journal Sun Rock : Les détails arrivent. Évalué à 4.
Alors, le premier se met en sommeil et le deuxième thread continue ce qu'il est possible de faire du premier sans utiliser ces données (par exemple, quelques unes instructions suivantes ne font pas tout de suite appel aux données manquantes et peuvent être calculées pendant ce temps ; mais il s'agit également de calculer des adresses de sauts (prédiction de chanchement), du chargement des instructions suivantes, du prefetch de cache). Elles n'ont pas besoin d'être recalculées ensuite par le thread initial, qui dès qu'il aura récupéré la donnée de la mémoire, pourra utiliser immédiatement les précalculs effectués par le thread de surveillance et continuer sa tâche.
Toutes les instructions qui n'ont pas pu être exécutées car dépendantes de la donnée manquante sont chargées dans une file qui sera parcourue par le thread principal quand il aura obtenu ses données. Les autres peuvent être exécutées tout de suite.
C'est une sorte d'out-of order simplifié : l'out-of-order traditionnel cherche à effectuer tout de suites les instructions dont les opérandes sont immédiatement disponibles, et à conserver les résultats. Cela revient à se dire : "j'ai telle et telle donnée en registre, qu'est-ce que je pourrais faire avec avant de les envoyer dans le cache ou ailleurs pour faire autre chose ? Y a-t-il une instruction qui les utilise quelque part dans la suite, et que je pourrais faire tout de suite pour gagner du temps après ?"
Alors qu'ici, l'approche serait plutôt : "Il me manque une donnée. Dans le flot d'instructions, quelles sont les instructions suivantes qui n'en dépendent pas et que je peux effectuer en attendant ?"
(et mon avis personnel serait qu'idéalement le travail d'ordonnancement des instructions soit fait par le compilateur. En effet, il devrait pouvori déterminer lui-même quelles sont les instructions qui ne dépendent pas d'une autre, et prévoir quand les fautes de cache arrivent.)