Comment structurer les données pour une vitesse optimale dans une application CUDA

Question

Je tente d'écrire un système de particules simple qui utilise CUDA pour effectuer la mise à jour des positions des particules. En ce moment je définis une particule avec un objet avec une position définie avec trois valeurs flottantes, et une vitesse également définie avec trois valeurs flottantes. Lors de la mise à jour des particules, j'ajoute une valeur constante à la composante Y de la vitesse pour simuler la gravité, puis j'ajoute la vitesse à la position actuelle pour trouver la nouvelle position. En termes de gestion de la mémoire, il est préférable de maintenir deux tableaux de flottants séparés pour stocker les données ou pour les structurer de manière orientée objet. Quelque chose comme ceci:

struct Vector 
{ 
    float x, y, z; 
}; 

struct Particle 
{ 
    Vector position; 
    Vector velocity; 
}; 

Il semble que la taille des données est le même que soit la méthode (4 octets par flotteur, 3 flotteurs par vecteur, 2 vecteurs par particule totalisant au total 24 octets) Il semble que le OO Cette approche permettrait un transfert de données plus efficace entre le CPU et le GPU car je pourrais utiliser une seule instruction de copie mémoire au lieu de 2 (et à long terme plus, car il y a quelques autres informations sur les particules qui deviendront pertinentes, comme Age , Durée de vie, poids/masse, température, etc) Et puis il ya aussi juste la lisibilité simple du code et la facilité de traiter avec cela qui me fait aussi incliner vers l'approche OO. Mais les exemples que j'ai vus n'utilisent pas de données structurées, donc je me demande s'il y a une raison. Donc, la question est de savoir lequel est le meilleur: tableaux individuels de données ou d'objets structurés?

Answer 1

Il est courant en programmation parallèle de données de parler de "Struct of Arrays" (SOA) par rapport à "Array of Structs" (AOS), où le premier de vos deux exemples est AOS et le second SOA. De nombreux paradigmes de programmation parallèle, en particulier les paradigmes de type SIMD, préféreront SOA.

Dans la programmation GPU, la raison pour laquelle SOA est généralement préférée est d'optimiser les accès à la mémoire globale. Vous pouvez voir la présentation enregistrée sur Advanced CUDA C de GTC l'année dernière pour une description détaillée de la façon dont le GPU accède à la mémoire.

Le point principal est que les transactions de mémoire ont une taille minimale de 32 octets et que vous voulez maximiser l'efficacité de chaque transaction.

Avec AOS:

position[base + tid].x = position[base + tid].x + velocity[base + tid].x * dt; 
//^write to every third address     ^read from every third address 
//       ^read from every third address 

Avec SOA:

position.x[base + tid] = position.x[base + tid] + velocity.x[base + tid] * dt; 
//^write to consecutive addresses    ^read from consecutive addresses 
//       ^read from consecutive addresses 

Dans le second cas, la lecture des adresses consécutives signifie que vous avez une efficacité de 100% par rapport à 33% dans le premier cas. Notez que sur les anciens GPU (capacités de calcul 1.0 et 1.1), la situation est bien pire (13% d'efficacité).

Il y a une autre possibilité - si vous aviez deux ou quatre flotteurs dans le struct, vous pouvez alors lire l'AOS avec une efficacité de 100%:

float4 lpos; 
float4 lvel; 
lpos = position[base + tid]; 
lvel = velocity[base + tid]; 
lpos.x += lvel.x * dt; 
//... 
position[base + tid] = lpos; 

Encore une fois, consultez la présentation CUDA avancée C pour les détails .