Bonjour à tous,
 
 
J'ai un petit problème de compréhension sur certaines choses en Assembleur. En effet j'ai étudié l'Assembleur DLX et j'ai quelques notions qui me posent problème.
 
Tout d'abord, je ne comprends pas l'intérêt du "déroulage de boucle" ? De plus de façon générale, comment distinguer efficacement les différents types d'aléas au sein d'un code assembleur afin d'en améliorer l'exécution ?
 
Ceci étant purement à but d'apprentissage
 
Merci d'avance !

le déroulage de boucle te permet d'éviter les instructions de saut. sur des grosses boucles, ça procure un gain assez significatif

Merci pour ta réponse Quelles sont les méthodes principales pour dérouler une boucle ?

recopier chaque itération de la boucle linérairement dans le code

Ok merci c'est bien ce que je pensais aussi.  
 
D'un point de vue théorique, on parle de réordonnancer le code pour éviter les différents aléas (Lecture après Ecriture ...) et ainsi permettre d'éviter des cycles de latence.  
 
Y aurait t-il une technique pour repérer ces problèmes rapidement ?  
 

utiliser un profiler de code peut-être

En fait c'est sur le plan purement théorique, c'est pour des révisions que je me renseigne car c'est du code sur papier

Sur le plan purement théorique (et pratique)
- Le saut vide le pipe.
- L'AGI stall recommence à zéro.
 
l'exemple simple...

 
Dans cet exemple, on va avoir un AGI stall sur mov eax, [esi+ebx] Sa durée est de 2 à 3 cycles (parfois plus suivant la distance à laquelle se trouve la donnée).
 
 
Le fait de dérouler une boucle permet de multipler la vitesse dans des cas utilisant la mémoire de façon linéaire et intensive (FFT, copy, transfert, échange) :

Si on déroule...

petites

Taz+Harko> ça dépend du l'algo.
Mais même sur des grosses boucles (pas trop quand même), le gain est significatif.
Les meilleurs gains sont toujours obtenus sur des boucles occupant énormément la mémoire.
 
A l'inverse, trop dérouler une boucle (courte ou longue) peut la ralentir. Tout est une histoire de contexte, de CPU, dépendances...
 
L'idéal restant de faire plusieurs routines critiques et de choisir la plus rapide selon le contexte (test).

non ça dépend pas. C'est juste une histoire de cache et de si le coût du saut est significatif par rapport à l'exécution du corps de la boucle.

C'est un peu plus compliqué que ça, cher Taz, car les micro-processeurs avancés de notre génération sont très sophistiqués. Par exemple, ils utilisent une méthode appellé "prefectching" qui fait qu'un même saut peut être plus ou moins rapide selon que le CPU a deviné que le saut allait avoir lieu ou pas. Autre chose, le parallelisme. Puisque le microprocesseur possède un certain niveau de parallèlisme, il lui arrive d'exécuter plus ou moins rapidement une instruction en fonction de l'instruction qui la précède ou qui la suit. Donc, de nos jours, il devient quasiment impossible de faire des calculs théoriques justes du temps d'exécution. Il faut tester.

Taz> Il n'y a pas que le coût du saut, il y a aussi les problèmes d'AGI et de parallélisation qui peuvent être améliorés voire résolus en déroulant partiellement les boucles.
 
Dans tous les cas, je ne déroule jamais totalement les boucles, c'est plus néfaste qu'autre chose, et cela salit le code-cache.
 
Souvent un déroulement x2 à x8 est suffisant.
 
Edit:
Taz> En fait tout dépend les algos. Je parle de ma propre expérience et toi de la tienne. Deux points de vue différents puisque l'on ne fait pas les mêmes choses.
 
Re-Edit:

Oui il faut tester, mais il n'est pas impossible de faire des calculs théoriques. Il faut seulement avoir les bonnes docs et les connaissances.
 
Au fait, un processeur ne devine rien, il analyse suivant des algo complexes mais mathématiquement transposable. C'est bien plus pratique.