Concernant les histoires de spéculation pour Itanium, ça n'a RIEN à voir avec de l'out-of-order. Un Itanium 2 est un VLIW : le parallélisme d'instruction est explicite, et oui, tout repose donc sur le compilateur.
Comment ca, RIEN?
Pour faire du parallelisme explicite, il faut savoir, statiquement and non dynamiquement, quelles sont les instructions que tu peux deplacer afin de faire des groupes d'instructions les plus grand possibles, et de mettre un maximum de distance entre un chargement de valeur depuis la memoire et son utilisation effective afin de ne pas bloquer le pipeline.
Tout cela necessite une analyse prealable poussee afin de determiner quels sont les deplacements d'instruction autorises qui ne vont pas modifier le resultat de l'execution. Ces meme informations peuvent etre utilisees par un non-VLIW, in order pipeline.
Exemple trivial:
A et B sont des tableaux d'entiers. C un pointeur d'un entier.
for(i=0; i<n; ++i) {
A[i]=(*C)*B[i];
}
Si tu ne peux pas prouver que C ne pointe pas sur une valeur de A[i], tu dois charger la valeur pointee par C a chaque iteration.
Un pipeline Out-of-order va se rendre compte, en regardant l'adresse de A[i] que *C n'est pas modifie et va donc annuler le chargement. Il sera meme capable d'executer le chargement de B[i+1], le calcul de (*C)*B[i] et le stockage de A[i-1] en meme temps.
Dans le cas d'un VLIW, si tu peux prouver que c'est different, ca se fera dans le meme cycle aussi.
Dans le cas d'un non-VLIW, in-order, au moins tu fais juste le chargement de *C avant la boucle, et t'affranchis du chargement dans la boucle.
Donc la meme information (pas d'alias entre A et C) va donner certes des resultats differents, mais benefiques pour les deux.
Donc oui, au moins dans ce cas, les development actuels pour Itanium auront des consequences sur d'autres architectures.
Cela est d'ailleur une source de ralentissement (sain) pour le development de ceux qui travaillent pour Itanium: Il serait beaucoup plus simple de ne se pencher que sur le cas de l'Itanium. Mais ils travaillent de facon generique afin que d'autres architectures puissent en profiter. Et comme un meme concept se traduit par des approches differentes au niveau des instructions, c'est un peu plus complexe a developer.
[^] # Re: Itanium
Posté par mdlh . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 5.
Comment ca, RIEN?
Pour faire du parallelisme explicite, il faut savoir, statiquement and non dynamiquement, quelles sont les instructions que tu peux deplacer afin de faire des groupes d'instructions les plus grand possibles, et de mettre un maximum de distance entre un chargement de valeur depuis la memoire et son utilisation effective afin de ne pas bloquer le pipeline.
Tout cela necessite une analyse prealable poussee afin de determiner quels sont les deplacements d'instruction autorises qui ne vont pas modifier le resultat de l'execution. Ces meme informations peuvent etre utilisees par un non-VLIW, in order pipeline.
Exemple trivial:
A et B sont des tableaux d'entiers. C un pointeur d'un entier.
for(i=0; i<n; ++i) {
A[i]=(*C)*B[i];
}
Si tu ne peux pas prouver que C ne pointe pas sur une valeur de A[i], tu dois charger la valeur pointee par C a chaque iteration.
Un pipeline Out-of-order va se rendre compte, en regardant l'adresse de A[i] que *C n'est pas modifie et va donc annuler le chargement. Il sera meme capable d'executer le chargement de B[i+1], le calcul de (*C)*B[i] et le stockage de A[i-1] en meme temps.
Dans le cas d'un VLIW, si tu peux prouver que c'est different, ca se fera dans le meme cycle aussi.
Dans le cas d'un non-VLIW, in-order, au moins tu fais juste le chargement de *C avant la boucle, et t'affranchis du chargement dans la boucle.
Donc la meme information (pas d'alias entre A et C) va donner certes des resultats differents, mais benefiques pour les deux.
Donc oui, au moins dans ce cas, les development actuels pour Itanium auront des consequences sur d'autres architectures.
Cela est d'ailleur une source de ralentissement (sain) pour le development de ceux qui travaillent pour Itanium: Il serait beaucoup plus simple de ne se pencher que sur le cas de l'Itanium. Mais ils travaillent de facon generique afin que d'autres architectures puissent en profiter. Et comme un meme concept se traduit par des approches differentes au niveau des instructions, c'est un peu plus complexe a developer.