Oui, pour ça que je fais pas pas plus que 2 instructions/cycles
Sinon pour ton code, c'est un peu faux, on peut le faire sur 3 cycles (et ça demande pas une grosse implémentation):
A = B E = B
C = D E++
A += C D = E
Et je ne pense pas qu'un OoO fasse mieux ici, pour moi l'avantage d'un OoO est ailleurs.
Elle est sur son exécution spéculative (qui du coup permet un meilleur ILP), sur ces prefetch, sur pouvoir continuer a exécuter du code malgré un cache miss.
Sinon pour le reste un OoO n'apporte pas grand chose comparé à un in order (si le compilo fait son taff).
Alors je ne pense pas que tout faire statiquement soit la solution, pour cela que je voudrais améliorer mon proc pour gérer les 3 cas en haut (de façon différente , mais de le gérer quand même).
[^] # Re: Ok, le hardware pourrait être fait, mais le software ?
Posté par Kannagichan . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 4. Dernière modification le 22 juin 2023 à 15:05.
Oui, pour ça que je fais pas pas plus que 2 instructions/cycles
Sinon pour ton code, c'est un peu faux, on peut le faire sur 3 cycles (et ça demande pas une grosse implémentation):
A = B E = B
C = D E++
A += C D = E
Et je ne pense pas qu'un OoO fasse mieux ici, pour moi l'avantage d'un OoO est ailleurs.
Elle est sur son exécution spéculative (qui du coup permet un meilleur ILP), sur ces prefetch, sur pouvoir continuer a exécuter du code malgré un cache miss.
Sinon pour le reste un OoO n'apporte pas grand chose comparé à un in order (si le compilo fait son taff).
Alors je ne pense pas que tout faire statiquement soit la solution, pour cela que je voudrais améliorer mon proc pour gérer les 3 cas en haut (de façon différente , mais de le gérer quand même).