L'enjeu du Tiling dans l'architecture Ascend

Sur les plateformes Ascend, l'efficacité des opérateurs repose largement sur la stratégie de découpage des données, ou Tiling. Une conception d'algorithme théoriquement parfait peut s'avérer désastreusement lente en pratique si l'AI Core passe l'essentiel de son temps à attendre des données depuis la Global Memory. Le Tiling détermine directement si les calculs s'exécutent de manière fluide dans les mémoires cache ultra-rapides (L1, L0 Buffer) ou s'ils subissent les goulots d'étranglement de l'accès mémoire global. Une stratégie de Tiling rigoureuse peut multiplier les performances d'un opérateur par trois à cinq.

Fondements : Structure TilingData et alignement mémoire

Avant toute optimisation computationnelle, il faut comprendre comment les métadonnées de Tiling transitent entre l'hôte (Host) et l'appareil (Device). La structure TilingData agit comme un manifeste de tâches : l'hôte y encode la logique de découpage (taille des blocs, nombre de subdivisions) pour le Kernel exécuté côté Device.

Surcoût caché et principes d'optimisation

Considérer la taille de TilingData comme négligeable est une erreur fréquente. Cette structure réside en Global Memory (GM) et doit être copiée vers l'espace de pile de l'AI Core avant l'exécution du Kernel. Cette opération de copie, à l'échelle de la microseconde, devient un goulot d'étranglement pour les opérateurs traitant des petits volumes de données. L'optimisation de TilingData repose sur deux piliers : minimiser son empreinte mémoire et garantir un alignement strict sur 8 octets.

Conception d'une structure TilingData optimisée

L'approche ci-dessous illustre une conception sous-optimale, avec des types de données surdimensionnés et des champs redondants :

// Mauvaise pratique : structure gonflée et non optimisée
BEGIN_TILING_DATA_DEF(MyUnoptimizedTiling)
  TILING_DATA_FIELD_DEF(uint64_t, coreCount);       // Redondant, accessible via GetBlockNum
  TILING_DATA_FIELD_DEF(uint64_t, fullBlocksCount); // Type excessif pour un petit nombre
  TILING_DATA_FIELD_DEF(uint64_t, partialBlockCount);
  TILING_DATA_FIELD_DEF(uint64_t, fullBlockSize);
  TILING_DATA_FIELD_DEF(uint64_t, partialBlockSize);
  TILING_DATA_FIELD_DEF(uint64_t, alignmentFactor);
END_TILING_DATA_DEF;

Cette implémentation présente plusieurs défauts. D'abord, l'information sur le nombre de cœurs est superflue car récupérable nativement par le Kernel. Ensuite, les compteurs de blocs ne dépassant jamais la trentaine, l'utilisation de uint64_t gaspille de l'espace. Enfin, l'ordonnancement aléatoire des champs force le compilateur à injecter du bourrage (padding) pour maintenir l'alignement.

Voici la version remaniée et optimisée :

// Bonne pratique : structure compacte et alignée
BEGIN_TILING_DATA_DEF(OptimizedTilingData)
  TILING_DATA_FIELD_DEF(uint8_t, fullBlocksCount);
  TILING_DATA_FIELD_DEF(uint8_t, partialBlockCount);
  TILING_DATA_FIELD_DEF(uint32_t, fullBlockSize);
  TILING_DATA_FIELD_DEF(uint32_t, partialBlockSize);
  TILING_DATA_FIELD_DEF(uint32_t, alignmentFactor);
END_TILING_DATA_DEF;

En regroupant les champs uint8_t et en réduisant les types de données, on limite drastiquement le bourrage mémoire. Un tel remaniement peut faire chuter les octets de remplissage de 10 à 2, réduisant la taille globale de la structure de plus de 20 %. Pour les opérateurs de faible taille appelés de façon intensive, l'impact sur la latence est considérable.

Modèles d'accès mémoire et transferts en bloc

Au-delà de la structure de données, le transfert des blocs de calcul doit tirer parti de la hiérarchie mémoire. L'architecture Ascend maximise l'utilisation de la bande passante lorsque les accès mémoire portent sur des segments conséquents. Les directives d'optimisation recommandent de transférer au moins 16 Ko par itération depuis la Global Memory vers l'Unified Buffer (UB). La stratégie de Tiling doit donc équilibrer la capacité de traitement des unités de calcul et le dimensionnement optimal des segments de données à copier.