Le principe est le suivant :
Il execute 32 threads sur 8 cores, donc 4 thread par core.
Les 4 threads d'un core sont exécuté successivement.
Les instructions de chaque thread sont exécutés après les rapatriements de données dans le cache. Les accès mémoires ne pénalisent donc pas le core car, pendant ce temps il exécute une instruction des chacun des 3 autres threads.
C'est du moins le principe. Cela nécessite donc un cache moins grand qu'un processeur monothread.
Si une instruction a besoin d'accèder à 2 adresses mémoires, et qu'il y en a déja une en cache il n'y a pas d'attente par exemple.
Par ailleurs le fait que l'entrelacement des threads soit systématique pemet de l'implémenter très simplement dans le processeur. Il suffit (en très très gros) de basculer a un jeu de registre parmi quatre à chaque période d'horloge.
La contrepartie des 8 cores, c'est qu'ils sont très simple (comparé à un x86-64 ou équivalent).
La performance n'est donc pas identique à un monocore ultra rapide avec un cache monstrueux.
C'est très adapté à des serveurs gérant des processus simple (et si possible identique car besoin de moins de cache d'instruction) en grand nombre, genre serveur web ( Sun n'a pas fait ça par hasard), peut être moins à un desktop quoi que le nombre de processus activé sur un desktop linux classique est non négligeable. Sur des programmes effectuant du calcul intensif et non programmé en multithread la puissance disponible est de 1/32 de la puissance total du processeur.
[^] # Re: C'est bien mais
Posté par bertrand . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 10.
Il execute 32 threads sur 8 cores, donc 4 thread par core.
Les 4 threads d'un core sont exécuté successivement.
Les instructions de chaque thread sont exécutés après les rapatriements de données dans le cache. Les accès mémoires ne pénalisent donc pas le core car, pendant ce temps il exécute une instruction des chacun des 3 autres threads.
C'est du moins le principe. Cela nécessite donc un cache moins grand qu'un processeur monothread.
Si une instruction a besoin d'accèder à 2 adresses mémoires, et qu'il y en a déja une en cache il n'y a pas d'attente par exemple.
Par ailleurs le fait que l'entrelacement des threads soit systématique pemet de l'implémenter très simplement dans le processeur. Il suffit (en très très gros) de basculer a un jeu de registre parmi quatre à chaque période d'horloge.
La contrepartie des 8 cores, c'est qu'ils sont très simple (comparé à un x86-64 ou équivalent).
La performance n'est donc pas identique à un monocore ultra rapide avec un cache monstrueux.
C'est très adapté à des serveurs gérant des processus simple (et si possible identique car besoin de moins de cache d'instruction) en grand nombre, genre serveur web ( Sun n'a pas fait ça par hasard), peut être moins à un desktop quoi que le nombre de processus activé sur un desktop linux classique est non négligeable. Sur des programmes effectuant du calcul intensif et non programmé en multithread la puissance disponible est de 1/32 de la puissance total du processeur.