De ce que je comprend par « scatter/gather » (en français disperser/rassembler), avoir des des données éparpillées au hasard et récupérer tout ça pour le traitement, c'est une bonne idée si on veut sortir des caches et multiplier les temps de calculs. Organiser les données en mémoire fait parti du travail d'optimisation d'une application.
Les mémoires des processeurs graphiques par exemple contiennent ce que l'on appelle en OpenGL des VBO (Vertex Buffer Object=Objet tampon de vecteurs), qui sont des tables de vecteurs. Le processeur graphique peut appliquer linéairement un changement sur l'ensemble des points d'un objet en une seule boucle. C'est le type de tampon qu'on initialise lors de la création de l'objet qui reste dans la carte graphique, et dont on charge le processeur graphique d'effectuer des traitements sur ses données.
Dans les premières version d'OpenGL on poussait tous les points dans la pile OpenGL à chaque image à générer (transfert de la ram principale vers la ram graphique) ce qui était vraiment contre-productif. De plus les données n'ont pas forcément à être modifiées systématiquement. Par contre à chaque rendu, le GPU va appliquer les transformations (rotation/échelle/déformation+perspective) sur l'ensemble des vecteurs de l'objet, qu'il appliquera via une boucle. Il en va de même dans quasiment tous les domaines je pense. Comme évoqué précédemment, chaîne de caractères, informations venant linéairement de capteurs, ou bien encore échantillon sonore, etc.
Le principe d'un processeur vectoriel est de définir, comme expliqué dans le document :
* Le type de donnée
* Une suite d'instruction à effectuer sur ce type de données dans une boucle
* la longueur de la boucle.
Et de laisser le processeur vectoriel effectuer cette boucle sur l'ensemble des données.
À la premier lecture les blocs de mémoire contenant les données seront mis en cache données et le processeur pourra boucler sur les données avec ces instructions contenues dans le cache instruction. On économise toutes les instructions d'incrémentation/chargement qui peuvent être fait en parallèle aux instructions de traitement avec un cycle d'avance.
Si on utilise ce type de processeur sur des données ponctuelles éparpillées la différence de cycle de traitement ne sera en revanche pas énorme, ça se joue à 2 ou 3 instructions comme montré dans les exemples, ce qui est négligeable par rapport au temps de lecture aléatoire en RAM ou dans des caches de niveaux intermédiaires. Ces cycles sont par contre à multiplier par le nombre de boucles dans le cas de données organisées pour un traitement linéaire.
[^] # Re: Et RISC-V?
Posté par tao popus . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 5.
De ce que je comprend par « scatter/gather » (en français disperser/rassembler), avoir des des données éparpillées au hasard et récupérer tout ça pour le traitement, c'est une bonne idée si on veut sortir des caches et multiplier les temps de calculs. Organiser les données en mémoire fait parti du travail d'optimisation d'une application.
Les mémoires des processeurs graphiques par exemple contiennent ce que l'on appelle en OpenGL des VBO (Vertex Buffer Object=Objet tampon de vecteurs), qui sont des tables de vecteurs. Le processeur graphique peut appliquer linéairement un changement sur l'ensemble des points d'un objet en une seule boucle. C'est le type de tampon qu'on initialise lors de la création de l'objet qui reste dans la carte graphique, et dont on charge le processeur graphique d'effectuer des traitements sur ses données.
Dans les premières version d'OpenGL on poussait tous les points dans la pile OpenGL à chaque image à générer (transfert de la ram principale vers la ram graphique) ce qui était vraiment contre-productif. De plus les données n'ont pas forcément à être modifiées systématiquement. Par contre à chaque rendu, le GPU va appliquer les transformations (rotation/échelle/déformation+perspective) sur l'ensemble des vecteurs de l'objet, qu'il appliquera via une boucle. Il en va de même dans quasiment tous les domaines je pense. Comme évoqué précédemment, chaîne de caractères, informations venant linéairement de capteurs, ou bien encore échantillon sonore, etc.
Le principe d'un processeur vectoriel est de définir, comme expliqué dans le document :
* Le type de donnée
* Une suite d'instruction à effectuer sur ce type de données dans une boucle
* la longueur de la boucle.
Et de laisser le processeur vectoriel effectuer cette boucle sur l'ensemble des données.
À la premier lecture les blocs de mémoire contenant les données seront mis en cache données et le processeur pourra boucler sur les données avec ces instructions contenues dans le cache instruction. On économise toutes les instructions d'incrémentation/chargement qui peuvent être fait en parallèle aux instructions de traitement avec un cycle d'avance.
Si on utilise ce type de processeur sur des données ponctuelles éparpillées la différence de cycle de traitement ne sera en revanche pas énorme, ça se joue à 2 ou 3 instructions comme montré dans les exemples, ce qui est négligeable par rapport au temps de lecture aléatoire en RAM ou dans des caches de niveaux intermédiaires. Ces cycles sont par contre à multiplier par le nombre de boucles dans le cas de données organisées pour un traitement linéaire.