Brevet FR2967800A1 — publié le 20120525

PROCEDE DE SYNCHRONISATION ET DE TRANSFERT DE DONNEES ENTRE DES PROCESSEURS RELIES PAR DES CANAUX DMA La présente invention concerne un procédé de synchronisation et de transfert de données entre des processeurs reliés par des canaux DMA (Direct Memory Access). Elle s'applique notamment dans le domaine de la programmation parallèle des systèmes multiprocesseurs asymétriques. Le "Cell Broadband Engine" (CBE) est une architecture multiprocesseur asymétrique qui combine un élément de traitement à 1 o caractère généraliste, souvent désigné par les expressions anglo-saxonnes "Power Processor" ou "Power Processor Element" (PPE), avec 8 éléments de co-traitement fonctionnant en synergie, souvent désignés par l'expression anglo-saxonne "Synergistic Processing Elements" (SPE). Un CBE vise notamment à accélérer les applications vectorielles et multimédia. 15 En plus d'une mémoire globale au CBE, chaque SPE inclut un espace locale de 256 kilo-octets (Ko) qui agit comme une mémoire cache utilisable par le programmeur, ainsi qu'un contrôleur DMA explicitement programmable. Les SPE supportent également le fonctionnement en mode SIMD (Single Instruction on Multiple Data) sur 128 bits. Tous les SPE sont 20 connectés via un bus interne en anneau comportant 4 canaux unidirectionnels de 16 octets. Les performances théoriques des CBEs actuels comme le PowerXCellBi atteignent 204,8 milliards d'opérations à virgule flottante par seconde (GFlops/s) en simple précision et 102,4 GFlops/s en double précision. A la lumière de cette immense puissance de 25 calcul et du rendement de puissance de l'architecture (0,87 GFlops/s par Watt en double précision pour le BladeCenter QS22 d'IBM), le CBE est encore aujourd'hui une alternative pertinente dans le domaine du calcul haute performance, plus connu sous la terminologie "High Performance Computing" (HPC), spécialement dans les systèmes embarqués nécessitant 30 de bonnes performances en virgule flottante. Malgré ces avantages, l'adoption du CBE a été lente, car la nature asymétrique de son architecture et le caractère distribué de sa mémoire DMA compliquent le développement d'applications performantes. Il s'agit là d'un inconvénient auquel la présente invention se propose de pallier. Depuis la sortie du CBE, une quantité substantielle de recherches ont été menées pour tenter de faciliter le développement d'applications performantes sur le CBE. Des solutions dites implicites ont été proposées, qui délèguent une grande partie de la logique des applications au compilateur. Malheureusement, ces solutions mènent à des applications relativement peu efficaces. Ainsi, pour une application donnée, le débit maximum des échanges entre SPE y est souvent de l'ordre de 500/0 inférieur au débit maximum obtenu par programmation de la même application par un expert. Il s'agit là encore d'un inconvénient auquel la présente invention se propose de pallier. D'autres solutions dites explicites ont été proposées, qui laissent au programmeur le soin d'implémenter l'essentiel de la logique des applications grâce à des librairies. Par exemple, dans un article intitulé "A buffered-mode MPI implementation for the Cell BE TM Processor" (Computational Science - ICCS 2007, 603-610), Kumar et al décrivent une implémentation intéressante du standard MPI (Message Programming Interface). Leur modèle assigne exclusivement une partie de la mémoire globale à chaque SPE et des tampons de messages sont alloués en mémoire globale. Des informations de type métadonnées sont maintenues dans les mémoires locales des SPE. Toutes les fonctionnalités de base de l'interface MPI y sont fournies, ainsi qu'une commande de lancement mpirun customisée, qui gère la création des fils d'exécution et l'allocation de la mémoire. Malheureusement, cette implémentation utilise la mémoire globale de telle sorte que le transfert d'un message d'un SPE à un autre implique de copier d'abord les données de la mémoire globale vers la mémoire locale puis de retour dans la mémoire globale. C'est pourquoi elle ne permet pas de dépasser un taux de transfert des données de 7 Giga-octets par seconde (Gois) pour une communication point-à-point. Il s'agit là encore d'un inconvénient auquel la présente invention se propose de pallier.35 L'invention a notamment pour but, en optimisant la synchronisation des SPE et en autorisant le transfert de données entre les SPE, de permettre le développement d'applications performantes sur le CBE. Pour cela, l'invention propose une méthode de gestion explicite par le programmeur de transferts directs de messages entre les SPE, c'est-à-dire sans utiliser la mémoire globale et le PPE. A cet effet, l'invention a notamment pour objet un procédé de synchronisation et de transfert de données entre N processeurs, où N est un entier supérieur ou égal à 2, 1 o chaque processeur comportant une mémoire locale et les processeurs étant reliés deux à deux par des canaux DMA. Le procédé met en oeuvre un protocole d'échange de messages entre les processeurs via les canaux DMA, chaque message contenant des informations de synchronisation et/ou des données. Le protocole inclut de remplir un entête dans chaque message 15 avant de l'envoyer. Il inclut également d'envoyer un jeton d'un processeur destination vers un processeur source afin d'autoriser le processeur source à envoyer un message au processeur destination. Il inclut aussi de transférer du processeur source au processeur destination un bloc de mémoire non aligné ayant été alloué arbitrairement dans la mémoire locale du processeur 20 source. Avantageusement, le procédé peut inclure de transférer des données contenues dans des zones mémoire bidimensionnelles de la mémoire locale du processeur source vers la mémoire locale du processeur destination. Dans un mode de réalisation préférentiel, le procédé peut inclure 25 de découper la zone mémoire bidimensionnelle en tuiles bidimensionnelles carrées ou rectangulaires, dont le nombre de points de bord est minimal. Par exemple, le procédé peut inclure d'envoyer chaque tuile bidimensionnelle en plusieurs messages via le canal DMA reliant le processeur source et le processeur destination, chaque message contenant une tuile 30 monodimensionnelle linéaire obtenue par découpage de ladite tuile bidimensionnelle. Dans un mode de réalisation préférentiel, le protocole peut être conforme au standard MPI. Par exemple, l'entête de chaque message peut contenir un champ contenant un identifiant de contexte de communication, 35 chaque processeur pouvant être identifié par un rang entre 0 et N-1 et l'identifiant de contexte de communication pouvant être formé au moins à partir du rang du processeur source et du rang du processeur destination. L'entête de chaque message peut également contenir un champ contenant une balise de message, cette balise pouvant être un entier permettant d'identifier le message de manière unique. L'entête de chaque message peut également contenir un champ d'opération contenant une indication d'envoi ou de réception. L'entête de chaque message peut également contenir un champ de contrôle contenant une indication d'un transfert en cours ou d'un transfert de données terminé ou encore d'envoi d'un jeton. L'entête de 1 o chaque message peut également contenir un champ contenant un identifiant de type de données. L'entête de chaque message peut également contenir un champ contenant une taille de données en octets. L'entête de chaque message peut également contenir au moins un champ contenant le nombre d'octets déjà transférés s'il s'agit d'un transfert en cours. L'entête de chaque 15 message peut également contenir un champ contenant la première adresse alignée qui peut être utilisée comme adresse de destination pour transférer des données. Par exemple, le processeur destination peut autoriser le processeur source à lui envoyer un message en lui envoyant un message 20 dont le champ de contrôle dans l'entête indique l'envoi d'un jeton. Le jeton peut alors être consommé par le processeur source dès lors que le processeur source envoie au processeur destination un message dont le champ de contrôle dans l'entête indique un transfert de données terminé ou dès lors que le processeur destination envoie au processeur source un 25 message dont le champ de contrôle dans l'entête indique un transfert de données terminé. Le processeur source peut alors ne plus être autorisé à envoyer de message au processeur destination. Par exemple, après réception par le processeur source du message dont le champ de contrôle dans l'entête indique l'envoi d'un jeton et 30 avant envoi du message dont le champ de contrôle dans l'entête indique un transfert de données terminé, le processeur source peut envoyer au processeur destination au moins un message dont le champ de contrôle dans l'entête indique un transfert en cours. Par exemple, transférer un bloc de mémoire non aligné de la 35 mémoire locale du processeur source à un emplacement donné de la mémoire locale du processeur destination peut inclure que le processeur destination envoie au processeur source un message dont le champ de contrôle dans l'entête indique un transfert en cours, ce message contenant la première adresse mémoire alignée dans le bloc de mémoire non aligné qui doit être transféré, ainsi que le nombre d'octets à ajouter avant et le nombre d'octets à ajouter après ladite première adresse alignée. Le processeur source peut alors en déduire la première et la dernière adresse du bloc mémoire non aligné qui doit être transféré. Transférer un bloc de mémoire non aligné de la mémoire locale du processeur source à un emplacement 1 o donné de la mémoire locale du processeur destination peut également inclure que le processeur source copie dans un premier tampon aligné dans sa mémoire locale, par au moins une opération de mouvement dans sa mémoire locale, les blocs mémoire alignés sur lesquels le bloc mémoire non aligné à transférer se trouve. Transférer un bloc de mémoire non aligné de la 15 mémoire locale du processeur source à un emplacement donné de la mémoire locale du processeur destination peut également inclure que le premier tampon soit transmis vers un second tampon similaire aligné dans la mémoire locale du processeur destination, par une ou plusieurs commandes DMA de mise en mémoire, les adresses desdits tampons ayant été au 20 préalable échangées entre le processeur source et le processeur destination. Transférer un bloc de mémoire non aligné de la mémoire locale du processeur source à un emplacement donné de la mémoire locale du processeur destination peut également inclure que le processeur source informe le processeur destination, en envoyant un message dont le champ 25 de contrôle dans l'entête indique un transfert de données terminé, que les données ont été transférées et combien d'octets ont été transférés. Transférer un bloc de mémoire non aligné de la mémoire locale du processeur source à un emplacement donné de la mémoire locale du processeur destination peut également inclure que le processeur destination 30 copie à l'emplacement donné de sa mémoire locale, par au moins une opération de mouvement dans sa mémoire locale, le bloc de mémoire non aligné transféré et contenu dans le second tampon. Transférer un bloc de mémoire non aligné de la mémoire locale du processeur source à un emplacement donné de la mémoire locale du processeur destination peut 35 également inclure que le processeur destination envoie au processeur source, une fois les données copiées à l'emplacement donné, un message dont le champ de contrôle dans l'entête indique l'envoi d'un jeton. Avantageusement, les données à transférer du processeur source vers le processeur destination peuvent être mises dans au moins deux tampons de mémoire, de manière à permettre des transactions dans les mémoires locales desdits processeurs alors que lesdits processeurs effectuent des calculs. L'adresse du premier tampon dans la mémoire locale du processeur source et l'adresse du deuxième tampon dans la mémoire locale du processeur destination peuvent alors être constantes et 1 o prédéfinies. La présente invention a pour principal avantage que les transferts de données entre les SPE peuvent être quatre fois plus rapides qu'entre les 15 SPE et le PPE. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui 20 représentent : - la figure 1, par un diagramme de séquence, le fonctionnement d'un exemple de sous-système du noyau d'exécution du CBE selon l'invention; - la figure 2, par un schéma, l'arrangement d'un exemple d'entête de 25 message selon l'invention; - la figure 3, par un diagramme de séquence, un exemple d'algorithme d'envoi d'un message selon l'invention; - la figure 4, par un diagramme de séquence, un exemple d'algorithme de réception d'un message selon l'invention; 30 - la figure 5, par un diagramme, comment un bloc de mémoire non aligné, c'est-à-dire d'adresse et/ou de taille non multiple de 16, est transféré d'un SPE source vers un SPE destination selon l'invention; - les figures 6 et 7, par un diagramme de séquence et un schéma, 35 les principes du simple et du "double buffering" respectivement; - les figures 8 et 9, par des schémas, un exemple de mise en oeuvre selon l'invention du "double buffering" avec quatre tampons; - les figures 10a et 10b, par des diagrammes de séquence, un exemple de mise en oeuvre selon l'invention du "double buffering" avec masquage partiel et total des transferts respectivement; - les figures 11 a et 11 b, par des schémas, des exemples de tuilage de zones mémoire; - la figure 12, par des schémas, des exemples de découpage selon l'invention de requêtes DMA 2D en plusieurs requêtes DMA ID. Un exemple de réalisation de l'invention sous la forme d'une bibliothèque est décrit par la suite. Cette bibliothèque utilise avantageusement le Software Development Kit du CBE fournit par IBM, ainsi que les bibliothèques IibSPE et Boost C++ dans certains cas. Cet exemple de réalisation implémente avantageusement une partie du standard MPI, notamment des services de communication point-à-point synchrone et asynchrone, ainsi que des collectives comme allgather, alltoall, barrier, broadcast et reduce. La description qui suit divulgue d'abord un exemple de sous-système du noyau d'exécution du CBE selon l'invention, puis une implémentation du standard MPI selon l'invention. En particulier, il est divulgué comment des transferts asynchrones peuvent être réalisés sans mettre de message dans un tampon de mémoire et comment des données de taille et d'emplacement arbitraires peuvent être transmis. SOUS-SYSTEME DU NOYAU D'EXECUTION La figure 1 illustre schématiquement, par un diagramme de séquence, le fonctionnement d'un exemple de sous-système du noyau d'exécution du CBE selon l'invention. Le noyau d'exécution est géré en utilisant un certain nombre de fonctions qui peuvent être appelées depuis le code des PPE ou des SPE, à savoir PPE_Init, PPE_Run, PPE_Sync, PPE_Finalize, SPE_Init et SPE_Finalize comme illustré par la figure 1. Le modèle d'exécution du noyau du CBE assigne un fil d'exécution à chaque SPE qui devrait exécuter un noyau. Les fils d'exécution sont démarrés comme des fils normaux et puis ils démarrent les noyaux SPE dans le contexte SPE qui leur a été alloué. Le PPE prend soin de toutes les tâches d'entretien concernant les fils d'exécution et les contextes SPE, ainsi que des valeurs retournées par les noyaux et des codes d'erreur. Le PPE prépare aussi une structure de contrôle pour chaque fil d'exécution de noyau. Cette structure est utilisée pour passer de l'information au noyau SPE: le rang des SPE, sa balise (ou son "tag" selon l'expression anglo-saxonne), un pointeur optionnel vers une structure de données définie par l'utilisateur (un pointeur 1 o vers la mémoire principale), la taille de la structure de données définie par l'utilisateur et les adresses correspondantes en mémoire de chaque espace locale de SPE, ainsi que les adresses des registres de signal. Chaque noyau reçoit sa structure de contrôle au démarrage. Elle est utilisée comme un point de départ pour recevoir des données de la mémoire globale et pour 15 faciliter la communication entre les SPE. Après démarrage des noyaux, l'adresse en mémoire globale du bloc de contrôle est passée à la fonction noyau comme un argument, ainsi le noyau peut préparer la structure dans son espace local. A partir de ce bloc de contrôle, le noyau extrait le pointeur et la taille des données utilisateur et 20 charge également ces données dans l'espace local du SPE si les données sont fournies par l'utilisateur. Pendant ce temps, le PPE attend qu'un noyau confirme qu'il a démarré correctement. Le noyau confirme cela en envoyant un message qui utilise la boîte aux lettres sortante. Ensuite le noyau attend lui-même un message du PPE qui est envoyé aux boîtes aux lettres 25 entrantes des SPE indiquant que le noyau devrait commencer à exécuter le code utilisateur. Dès que ce message est reçu, le noyau commence à exécuter le code noyau défini par l'utilisateur. Le code utilisateur a accès aux structures de données définies par l'utilisateur. Après que le noyau a fini d'exécuter le code utilisateur, le noyau envoie un message au PPE. Le 30 message peut contenir une valeur de retour définie par l'utilisateur et un code erreur si une erreur s'est produite pendant l'exécution du code utilisateur. Les deux boîtes aux lettres sortantes sont utilisées pour cette fonctionnalité. Le code d'erreur est transmis en utilisant la boîte à messages activée par les interruptions. Ceci permet au PPE de réagir instantanément aux erreurs des 35 SPE. Le code d'erreur reçu par le PPE est traduit en une exception. A certains moments, le PPE doit se synchroniser avec le noyau pour assurer que le noyau a terminé d'exécuter et que les résultats des calculs du noyau sont disponibles. Le PPE peut se synchroniser en attendant le message contenant la valeur de retour. La valeur retour peut aussi être accédée par des bibliothèques utilisateur. Après l'envoi du message retour, le noyau ne s'arrête pas et les fils d'exécution ne sont pas stoppés. Les fils d'exécution du noyau s'exécutent en boucle et attendent un message du PPE, pour soit leur signaler de sortir, soit s'exécuter à nouveau. De cette façon, on évite la surcharge de création des fils d'exécution et de démarrage du noyau dans le contexte SPE. Avant une seconde exécution, le noyau prépare à nouveau les données définies par l'utilisateur. Ceci permet aux utilisateurs de modifier les données d'entrée du noyau sur le PPE pour une nouvelle exécution du noyau. Si l'utilisateur décide de lancer un autre noyau, le noyau courant peut être terminé. En envoyant un message de sortie, le PPE déclenche la sortie du noyau. Les fils d'exécution gérant les contextes SPE sont joints avec le fil d'exécution du PPE. La figure 1 illustre ce concept. L'avantage de cette méthode est que le fait d'appeler le même noyau plusieurs fois ne crée pas des nouveaux fils d'exécution et ne démarre pas une nouvelle fonction noyau à chaque fois, mais à la place va exécuter la même fonction dans le même contexte de multiples fois. Le pseudo-code qui suit clarifie ce comportement: int main ( ) { while ( true ) { message = wait_for_message _from_ppe (); if ( message == quit ) return 0; else if ( message == run ) { user code ( ); send_return_value _back_to_ppe ( 0 ); 30 } 35 } } Ce pseudo-code illustre le code réel qui est généré si l'utilisateur définit un noyau. Le code d'encadrement autour de user code() est invisible à 40 l'utilisateur de la bibliothèque. A part les appels au noyau consécutifs efficaces, ceci permet aussi aux utilisateurs d'utiliser la mémoire persistante grâce à de multiples appels au même noyau utilisant des variables globales. En supposant par exemple que les utilisateurs ont besoin de préparer une image de l'espace global au début de chaque exécution de noyau pour traitement: quand le noyau est exécuté pour la première fois, un tampon pour stocker l'image peut être alloué et une référence à l'emplacement peut être stockée dans un pointeur global. La mémoire peut ensuite être utilisée dans chaque exécution suivante du noyau. En fait, les utilisateurs de la bibliothèque sont capables d'implémenter un système de calcul et de 1 o transferts s'entrelaçant grâce à l'utilisation de deux ou plusieurs tampons (technique du double buffering selon la terminologie anglo-saxonne ou ping-pong) à travers de multiples appels au même noyau. 15 IMPLEMENTATION DE MPI La section qui suit décrit d'importants aspects du présent exemple d'implémentation de MPI dans le CBE, incluant notamment le contenu et l'arrangement des entêtes, le protocole d'échange, le mécanisme de jetons ainsi que la manière avec laquelle des transferts arbitraires de mémoire sont 20 gérés. Les entêtes Dans le présent exemple de bibliothèque implémentant MPI pour le CBE, les communications MPI sont contrôlées en utilisant des entêtes de 25 message MPI. L'entête de message est utilisé pour déterminer si un message entrant correspond à une réception en cours, en comparant l'identifiant de contexte de communication, la balise de message, le type de donnée dans le message, ainsi que la taille du message. Ces concepts seront explicités par la suite. Par-dessus cela, l'entête est utilisé pour 30 transférer l'adresse de destination ainsi que des informations sur la façon avec laquelle les données sont transférées et en particulier si le transfert des données implique d'utiliser un tampon de mémoire additionnel. L'entête contient également un champ controlflags, qui indique si l'entête est un entête SYN indiquant un message en cours, un entête ACK indiquant un 35 transfert de données terminé ou un entête RDY utilisé pour envoyer des jetons à un SPE comme explicité par la suite. L'entête contient également un champ opflags, qui indique si un entête est associé avec une opération d'envoi ou de réception. La figure 2 illustre l'arrangement de l'entête de message. Le champ communicator identifier sur les 8 premiers octets est utilisé pour l'identifiant de contexte de communication. Le concept de contexte de communication est un concept propre au paradigme MPI, qui désigne un groupe d'entités impliquées dans une communication. Dans le présent exemple de réalisation, l'identifiant de contexte de communication est déduit des rangs SPE qu'il contient et de leur ordre dans le contexte de communication. Chaque demi-octet dans l'identifiant de contexte de communication représente un rang de SPE global, donc si un contexte de communication contient les SPE 1, 2 et 3 dans cet ordre, l'identifiant est Ob100100011 ou 0x123. Après l'identifiant de contexte de communication vient un champ tag sur 32 bits de large. Le champ suivant datatype contient un identifiant de type de données. Les types de données prédéfinis ont un identifiant sur 12 bits bien défini, qui permet une comparaison simple des types de donnée en utilisant les opérations sur les bits. Les utilisateurs de bibliothèques peuvent enregistrer leurs propres types de données. Pour chaque type données utilisateur, un identifiant unique est généré en utilisant le schéma de structure du pseudo-code qui suit : template struct cbe_mpi_user _pod_type _id { static void get ( ) {} }; int32_t id = 0x80000000 (int32_t)(&cbe_mpi_user _pod_type _id ::get); 30 Pour générer l'identifiant unique, l'adresse de la fonction get des structures est combinée avec un marqueur (ou un "flag" selon l'expression anglo-saxonne) du type de données défini par l'utilisateur. Le champ datasize contient la taille des données à transférer en octets. Les 35 champs prependsize et appendsize indiquent combien d'octets ont été transférés dans le tampon de mémoire. Le champ address est la première adresse alignée, c'est-à-dire multiple de 16, qui peut être utilisée pour le transfert de données et est aussi le décalage du tampon dans l'espace local du SPE relatif à son adresse de base correspondante en mémoire. Protocole MPI Le protocole MPI est conçu pour autoriser la communication asynchrone et minimiser la charge de messages. Il permet aux utilisateurs d'envoyer des messages entre les espaces locaux des SPE. Le protocole 1 o utilise des entêtes de messages pour transférer de l'information et contrôler l'état des transferts. Chaque SPE alloue une structure de données qui inclut des entêtes de message pour les tampons (deux tampons pour chaque SPE) et des buffers de données (un tampon de 32 octets pour chaque SPE). Les entêtes 15 de message pour les tampons sont utilisés pour créer de nouveaux entêtes et recevoir des entêtes des SPE distants. Les tampons de données sur 32 octets sont nécessaires si l'utilisateur envoie des messages de tailles et d'adresses non-alignées, c'est-à-dire qui ne sont pas multiples de 16, comme explicité par la suite. 20 Le protocole MPI utilise soit les opérations DMA PUT ou DMA GET pour transférer les données, selon l'ordre dans lequel les deux SPE qui communiquent entrent dans les routines MPI. Si l'émetteur est le premier à appeler la méthode MPI, il calcule l'entête et l'envoie au récepteur. Cet entête est appelé entête SYN. Sur entrée dans la méthode MPI, le récepteur 25 trouve l'entête SYN de l'émetteur, contenant toutes les informations nécessaires au transfert des données. Ainsi le récepteur peut commencer à préparer les données en utilisant DMA GET. Après que les données aient été transférées, l'émetteur est informé que l'opération a réussi : le récepteur envoie un entête ACK à l'émetteur. Dans le cas inverse (le récepteur appelle 30 la méthode MPI en premier), l'émetteur envoie des commandes DMA PUT pour transférer le message et accuse réception du transfert réussi de données au récepteur en envoyant un entête ACK. La figure 3 illustre par un diagramme de séquence l'algorithme d'envoi 35 d'un message selon l'invention et la figure 4 illustre par un diagramme analogue l'algorithme de réception d'un message selon l'invention. Ils diffèrent en ce que une fois que l'opération de réception a envoyé un entête SYN, il attend toujours que l'émetteur exécute un PUT des données et envoie un entête ACK par la suite. Cependant, l'opération d'envoi, après l'envoi de l'entête SYN, peut recevoir soit un ACK indiquant que le transfert s'est terminé avec succès ou un entête SYN. Dans ce dernier cas, cela veut dire qu'un entête SYN a été envoyé et qu'un entête SYN a été reçu par l'émetteur. Dans ce cas, l'opération d'envoi effectue par convention un DMA PUT pour transférer le message et le récepteur attend que l'opération se 1 o termine. Cette convention est nécessaire parce-que émetteur et récepteur peuvent envoyer leurs entêtes à n'importe quel moment. Pendant que l'émetteur transmet son entête SYN au récepteur, le récepteur pourrait lui-même transmettre un entête SYN. L'émetteur et le récepteur s'attendraient l'un et l'autre pour commencer le transfert des données et envoyer un ACK. 15 La modification dans l'algorithme d'envoi assure qu'un tel verrou n'est pas possible. Les contrôleurs DMA des SPE permettent aux utilisateurs de transférer des données en même temps que les calculs. Ceci est possible quand l'utilisation du protocole MPI comme opérations d'envoi et de 20 réception asynchrones sont supportés. Les diagrammes de séquence des figures 3 et 4 sont chacun implémentés dans deux fonctions différentes. Toutes les opérations avant les lignes 31 et 32 de la figure 3 et avant les lignes 41 et 42 de la figure 4 sont implémentées dans des fonctions isend et irecv. Elles peuvent s'exécuter sans délai de manière asynchrone et 25 représentent la première partie de la transmission asynchrone. Toutes les opérations après les lignes 31 et 32 de la figure 3 et après les lignes 41 et 42 de la figure 4 font partie de la synchronisation et sont implémentées dans une seconde fonction (wait). Avant les lignes 31 et 32 de la figure 3 et avant les lignes 41 et 42 de la figure 4, le transfert des données est démarré si 30 possible ou un entête est envoyé pour l'autre partenaire de communication pour commencer le transfert. Les séquences après la ligne 31 ou 32 de la figure 3 ou après la ligne 41 ou 42 de la figure 4 assurent que le transfert des données est terminé et que les données sont au bon emplacement. Un échange d'entêtes SYN et ACK est nécessaire; par conséquent, une opération ne peut se terminer avant que l'opération distante correspondante n'ait démarré. Mécanisme de jeton Le présent exemple d'implémentation de MPI utilise des jetons pour contrôler quand un SPE distant est autorisé à envoyer un nouvel entête. Ceci est nécessaire pour assurer que des entêtes non traités ne soient pas écrasés par de nouveaux entêtes. En particulier, ceci peut arriver si un message est transmis en utilisant PUT : le SPE source termine l'opération MPI dès que la commande DMA PUT est terminée. Le SPE destination doit cependant traiter les données avant qu'elles ne puissent être utilisées. Pour traiter les données, les informations de l'entête contenant le ACK envoyé par le SPE source est nécessaire parce qu'il contient les informations sur comment les données ont été transférées en regard du tampon sur 32 octets. Si le SPE source tente d'envoyer un autre message au même SPE, il commence par envoyer un entête contenant un SYN, puis possiblement écraser l'entête ACK non traité. Le mécanisme de jeton contourne ce problème : un SPE peut seulement envoyer un entête à un autre SPE s'il a un jeton de ce SPE. Selon le type d'entête qui est envoyé, une opération d'envoi d'entête peut ou non consommer le jeton. Si le jeton est consommé, le SPE destination doit fournir un nouveau jeton pour autoriser le SPE à envoyer un nouvel entête. Appliquer ce mécanisme à l'exemple ci-dessus donne le schéma suivant de communication : le SPE source envoie un entête ACK confirmant que le DMA PUT est terminé et que les données sont prêtes à être post-traitées par le SPE destination. En envoyant l'entête, le SPE source consomme le jeton. Si le même SPE veut envoyer un nouveau message, il ne peut envoyer un entête SYN à cette destination tant qu'il n'a pas reçu un nouveau jeton. Le SPE destination envoie un nouveau jeton après qu'il n'ait plus besoin de l'entête. Le mécanisme de jeton est mis en lumière dans les figures 3 et 4. Les cercles jaunes représentent les jetons, les cercles pleins symbolisent les transmissions d'entêtes non consommatrices et les cercles vides marquent les transmissions d'entêtes consommatrices. Le mécanisme de jetons est implémenté en utilisant un entête de 35 message MPI normal avec un marqueur à RDY (READY) dans la section controlflags de l'entête. Tout entête transmis pendant une communication MPI a son marqueur à RDY parce que si un SPE envoie un entête à un autre SPE, il est implicitement prêt à recevoir un nouvel entête. Pour fournir un nouveau jeton à des SPE, un entête vide avec le marqueur à RDY est envoyé. Transfert de mémoire arbitraire Le module MPI autorise le transfert de types de données et d'objets prédéfinis, d'objets POD (Plain Old Data) ou d'objets sérialisables. En 1 o particulier, le transfert de blocs de mémoire non-alignés, c'est-à-dire dont l'adresse et/ou la taille ne sont pas des multiples de 16, est possible en utilisant le présent exemple de bibliothèque, alors que l'architecture du CBE nécessite que la mémoire soit alignée sur des limites de 16 octets, que la taille mémoire soit un multiple de 16 octets ou qu'elle soit naturellement 15 alignée si le tampon est plus petit que 16 octets. Le présent exemple de bibliothèque n'impose pas de telles restrictions. L'algorithme qui autorise le transfert de mémoire allouée arbitrairement est décrit par la suite. La figure 5 illustre comment un bloc de mémoire non aligné est 20 transféré d'un SPE source vers un SPE destination en utilisant des opérations DMA PUT. En effet, l'architecture du CBE amène deux restrictions sur les données à transférer entre les SPE ou entre un SPE et le PPE: o l'adresse de début du bloc de mémoire à transférer doit être alignée 25 sur des limites de 16 octets (les 4 derniers bits de l'adresse mémoire sont à 0); o la taille du bloc mémoire doit être un multiple de 16, ainsi seuls les blocs de taille 16xn, où n>_1, peuvent être transférés. Ces exigences pour le transfert de données restreignent les développeurs 30 quand ils créent des applications pour le CBE. Le module MPI autorise le transfert de types de données et d'objets prédéfinis, d'objets POD (Plain Old Data) ou d'objets sérialisables. Il n'impose pas les restrictions citées précédemment. L'algorithme qui permet le transfert de mémoire localisée arbitrairement et de n'importe quelle taille est décrit ci-après. Il est illustré par 35 la figure 5. L'idée de base est de créer pour les développeurs des opérations transparentes et efficaces de transfert mémoire, mais qui sont compatibles des restrictions du CBE. Dans l'exemple de la figure 5, le transfert d'un bloc mémoire de taille supérieure à 32 octets est considéré. Ce bloc mémoire a au moins un bloc qui est aligné sur les limites requises de 16 octets et qui est de taille 16 octets x n où n>_1. Ce bloc est appelé "bloc mémoire principal". Il va de la première adresse alignée de tout le bloc mémoire (Salignée et Dalignée) à la dernière adresse alignée (Salignée tin et Dalignée Jin). Un bloc mémoire principal de la même taille (±16 octets) peut être calculé à la fois pour l'emplacement 1 o source et pour l'emplacement de destination. Le bloc mémoire principal source peut être transféré directement vers le bloc mémoire principal de destination en utilisant une ou plusieurs commandes DMA PUT. Cependant, les blocs principaux source et destination pourraient ne pas coïncider en termes de décalage par rapport à l'adresse de début du bloc mémoire, 15 comme formalisé dans l'équation (1) suivante: Salignée - Sdébut # Dalignée - Ddébut (1) Les données transférées pourraient être au mauvais emplacement si 20 l'équation (1) ci-dessus était satisfaite. Dans ce cas, les données doivent être déplacées au bon emplacement, par une opération de mouvement en mémoire (MOVE). Ceci prend soin du bloc mémoire principal et laisse les petits "déchets" de données avant et après. Ils ne peuvent être transférés directement parce que, par définition, ils sont non-alignés ou plus petits que 25 16 octets. Pour permettre le transfert de ces données, les déchets de données sont copiés à la source vers un tampon aligné de taille adéquate, c'est-à-dire les 32 octets requis. Le SPE destination a un tampon similaire disponible. La source met les 32 octets du tampon dans le bon tampon de destination. L'architecture du CBE permet le transfert de ce tampon parce 30 qu'il est à la fois aligné et de taille correcte. Une fois que la destination reçoit les données, elle les copie au bon emplacement dans le bloc mémoire. Cette opération termine le transfert des données. Les étapes de l'algorithme de transfert sont résumées ci-après en regard de la figure 5: o les SPE source et destination calculent la première adresse alignée (Salignée et Dalignée) et la taille du bloc principal (Salignée tin - Salignée et Dalignée fin - Dalignée); o le SPE source copie les données de recouvrement (de Saébut à Salignée et de Salignée fin a Stil-1) dans le tampon; o le SPE destination envoie un entête de message SYN à la source, ce message contenant Dalignée et la taille du bloc principal; o le SPE source commence le transfert des données de Salignée a Dalignée 0 le SPE source commence le transfert des données du tampon source au tampon destination (les adresses de tampon sont constantes et communiquées préalablement pour des raisons d'efficacité); o le SPE source informe le SPE destination que les données ont été transférées par un message ACK contenant le nombre d'octets ayant été transférés en utilisant le tampon; o sur réception du message ACK, le SPE destination déplace le bloc principal à l'emplacement correct si l'équation (1) est satisfaite; o le SPE destination copie les octets restant du tampon à l'emplacement correct; 0 le SPE destination envoie un message au SPE source indiquant que des données ont été reçues et traitées correctement (RDY); Pour des blocs mémoire de taille inférieure ou égale à 32 octets, l'intégralité du bloc est copiée dans le tampon source, transférée vers le tampon destination et copiée du tampon destination au bon emplacement de destination. Mise en tampon multiple ou "multi-buffering" Chacun des SPE a son propre espace local de taille limitée à 256 Ko programmable par l'utilisateur. Par conséquent, la plupart des implémentations d'algorithme sélectionnent leurs jeux de données, envoient de petites partitions du PPE vers les SPE, laissent les SPE faire le calcul et puis reçoivent le résultat en retour dans la mémoire globale du PPE. Chaque élément de traitement contient une unité de gestion de la mémoire appelée contrôleur de flux de mémoire (MFC) capable d'accès direct à la mémoire. Le MFC peut être vu comme un contrôleur de mémoire programmable qui fournit une interface asynchrone. Il permet aux développeurs de commencer des transactions en mémoire, de continuer les calculs et d'attendre ultérieurement que la transaction en mémoire se termine. En théorie, la latence de la mémoire peut être complètement cachée si les calculs et les transactions en mémoire peuvent se faire en même temps. Ceci est fait en utilisant plusieurs tampons, parce-que les unités de calcul et les unités de contrôle de la mémoire doivent opérer sur des données différentes. La figure 6 illustre par un diagramme de séquence le modèle du simple buffering. Pour les applications multimédia traitant des flots continus de données, le modèle le plus simple de transfert de données est le modèle dit du simple buffering ayant recours à un tampon mémoire. Avec ce modèle du simple buffering, il y a alternance entre des phases de calcul, notées Ci comme « Calculation » sur la Figure 6 pour i entier variant de 0 à 5, et des phases de transfert de données, notées Li et Si comme « Load » signifiant « chargement des données depuis la mémoire » et comme « Store » signifiant « sauvegarde des données vers la mémoire » respectivement. La cadence T de traitement des données est la somme des trois temps, c'est-à-dire T=TL+Tc+TS. Dans un premier schéma de calcul illustré par la partie haute de la figure 6, les temps de transfert sont supérieurs aux temps de calcul, c'est-à-dire TL+TS>Tc. Alors que dans un second schéma de calcul illustré par la partie basse de la figure 6, c'est l'inverse : TL+TS La figure 7 illustre schématiquement le principe du double buffering. Il s'agit de dédoubler le nombre de tampons mémoires, de manière à réaliser le traitement en deux phases répétées autant de fois que nécessaire. Pour cette raison, le double buffering est aussi appelée "ping-pong". Dans la phase dite de "ping", le premier tampon mémoire est utilisé pour faire des transferts et le second pour faire des calculs. Dans la phase dite de "pong", le rôle de chaque tampon est inversé. La figure 8 illustre un exemple courant de mise en oeuvre du double buffering avec quatre tampons. Deux tampons sont utilisés pour les transferts mémoire, afin de potentiellement charger des données (Load) en 1 o même temps que des données sont sauvegardées (Store). Tandis que deux tampons sont utilisés pour les calculs, afin d'avoir une zone destination différente de la zone source. Les conventions généralement utilisées consistent à dire que si la phase de "ping" est réalisée à l'instant "t", les données 1-1" sont sauvegardées en mémoire, les données "t" sont calculées 15 et les données 1+1" sont chargées. De même pour la phase "pong" à l'instant 1+1", les données "t" sont sauvegardées en mémoire, les données 1+1" sont calculées et les 1+2" sont chargées. 20 La figure 9 illustre le fonctionnement régulier du double buffering à quatre tampons. En effet, afin d'obtenir un fonctionnement régulier où en permanence des calculs et des transferts s'enchaînent, il est nécessaire d'avoir un "ping-pong" pour charger les données dans les deux zones mémoires : c'est le prologue au fonctionnement régulier, comme illustré par 25 la figure 9. Il est nécessaire de faire la même chose pour sauvegarder les dernières données calculées : c'est l'épilogue au fonctionnement régulier, comme illustré par la figure 9. 30 En fonction de la durée des calculs et des transferts, le masquage des transferts par des calculs est plus ou moins efficace. En reprenant les deux cas du simple buffering, le double buffering permet un masquage partiel ou total des transferts. La figure 10a illustre un exemple de double buffering avec masquage partiel des transferts : le calculateur est actif pendant 500/0 35 du temps total, contre seulement 330/0 avec simple buffering. La figure 10b illustre un exemple de double buffering avec masquage total des transferts : 100% de charge contre seulement 50% avec le simple buffering. L'API du présent exemple de bibliothèque MPI pour le CBE est basée sur les concepts d'itérateur et de plage, qui permettent l'interopérabilité avec les algorithmes existant. La table 1 qui suit contient une correspondance entre les tampons et les concepts d'itérateur correspondant. Nom du tampon Concept Nb min tampons Restrictions Tampon d'entrée Itérateur d'entrée 2 Passage unique, accès en lecture seulement Tampon de sortie Itérateur de 2 Passage unique, sortie accès en écriture seulement Tampon Itérateur de 3 Passage unique, d'entrée-sortie transit accès en lecture et en écriture Table 1 Un exemple d'utilisation d'un tampon d'entrée est donné par le pseudo-code qui suit: struct offset_calculator // functor to calculate data source { uint32_t operator () ( uint32_t size , uint32_t n , uint32_t wrap ) { return ( SPE_Rank() ' size + ( ( size ' SPE_Size() ' ( n % remotewrap ) ) ) ) ; } }; // create buffer of T Spe_ppe_inbuffer inbuf ( size , ppe addr , wrap , offset_calculator() , taglist ) ; for () { compute ('inbuf) ; // do computation on data inbuf++; // go to the next buffer } Tout d'abord un objet fonctionnel (functor) est défini, qui calcule le décalage des sources de données pour chaque appel au tampon. Il prend en argument la taille du tampon, combien de fois I'itérateur a été appelé et une valeur qui spécifie après combien d'appels le tampon devrait être recouvert. Ce functor est passé en 4eme argument au constructeur de tampon. Le premier argument (size) est la taille (combien de T un tampon devrait contenir), le deuxième argument (addr) est l'adresse de base de la mémoire distante sur le PPE, le troisième argument (wrap) est le nombre de blocs de données de taille size nécessaire pour recouvrir la totalité des données dans le tampon et le cinquième argument (taglist) est une liste de balises qui devraient être utilisés pour la communication. Le tampon peut ensuite être utilisé juste comme un itérateur : l'opérateur d'indirection retourne un pointeur vers le tampon qui peut être utilisé pour le calcul. En interne, cet opérateur se synchronise sur le tampon de données entrantes courant (si ce n'est déjà fait). L'opérateur de postincrémentation avance sur le tampon suivant en démarrant un transfert de données, pour avoir celui après le suivant et en pointant le tampon courant sur le tampon suivant. Avec un appel qui suit à l'opérateur d'indirection, le tampon courant est synchronisé à nouveau et un pointeur vers le tampon courant est retourné. Utiliser le multi-buffering sur l'architecture du CBE est un compromis entre cacher la latence des accès mémoire et la taille mémoire disponible. Alors que dans de nombreux cas, c'est une option viable pour accélérer significativement une implémentation, dans certains cas cela peut avoir un impact négatif. C'est le cas si une plus petite taille de tampon signifie plus de calculs généraux, ce qui peut par exemple être le cas dans les algorithmes de traitement d'image où l'alignement de fin de ligne des images doit être considéré. DMA 2D On appelle DMA 2D la possibilité de faire des requêtes de transfert de zones mémoires bidimensionnelles. L'utilité du DMA 2D est liée à la nature intrinsèque des opérateurs de traitement d'images bas niveaux. Ces opérateurs, qui sont principalement des convolutions, ont comme caractéristique de consommer plus de données qu'elles n'en produisent: l'image de sortie comporte moins de points que l'image d'entrée Généralement les convolutions sont de taille impaire et produisent un élément en sortie. Ce flot de donnée est souvent noté (kxk)->(1 x1), avec k=2r+1, où r est appelé le rayon de la convolution et k sa taille. Les figures 11 a et 11 b illustrent respectivement les convolutions (3x3)(1 x1) et (5x5)(1 x1). Sur le CBE, comme sur toutes les architectures à mémoire distribuée, il est nécessaire de découper les données en petits paquets appelés des tuiles, dont la taille est compatible avec les mémoires 1 o distribuées de la machine. Cette opération s'appelle le tuilage. Ainsi pour produire une tuile de taille h*w, où h et w sont des entiers non nuls, il est nécessaire d'avoir en entrée de l'opérateur de convolution une tuile de taille plus grande (h+2r)*(w+2r) à laquelle ont été ajoutés des bords qui seront perdus en sortie de convolution. 15 Le temps de transfert d'une tuile est, aux contraintes architecturales près, proportionnel à la surface de la tuile. La surface optimale est le carré, car c'est celle dont le périmètre est minimal, c'est-à-dire dont le nombre de point de bords est minimal. Les figures 11 a et 11 b illustrent des exemples de tuilage 3x3 et 20 5x5 respectivement, avec différentes formes de tuiles possibles. Les tuiles 110a et 110b sont des tuiles carrées, donc optimales. Les tuiles 111 a et 111 b sont rectangulaires, donc sous optimales. Les tuiles 112a et 112b sont "linéaires", ce qui est le pire cas possible. Les deux tables ci dessous donnent, à partir de la hauteur, de la 25 largeur et de la surface de chaque tuile, le ratio entre les surfaces des tuiles d'entrée et de sortie pour des tuiles de surface 16. La table 2 correspond à des convolutions (3x3) et la table 3 correspond à des convolutions (5x5). tuile de sortie tuile en entrée reload hauteur largeur surface hauteur largeur surface ratio 4 4 16 6 6 36 2.25 8 2 16 10 4 40 2.50 16 1 16 18 3 54 3.38 Table 2 30 tuile de sortie tuile en entrée reload hauteur largeur surface hauteur largeur surface ratio 4 4 16 8 8 64 4.00 8 2 16 12 6 72 4.50 16 1 16 20 5 100 6.25 Table 3 Pour des tuiles de plus grande surface, qui maximisent l'utilisation des mémoires internes du CBE du type "Local Store", ces ratios sont plus petits, 5 le pire ratio étant proche de la taille k de la convolution. Optimiser la durée des transferts sur le CBE revient donc à optimiser la surface des tuiles transmises et, aux contraintes architecturales près, à transmettre la tuile dont la forme est la plus proche possible du carré. 10 L'implémentation selon l'invention sur le CBE du standard MPI permet à l'utilisateur de transférer de manière transparente des tuiles 2D carrées ou rectangulaires. Il faut noter que ce n'est pas le cas du Software Development Kit du CBE fournit par IBM, qui ne permet que le transfert de tuiles 1 D linéaires largement sous-optimale vis-à-vis du volume de données à 15 transférer. Pour cela, l'implémentation selon l'invention sur le CBE du standard MPI génère de manière transparente des ensembles de requêtes DMA ID, qui sont vues par l'utilisateur comme une unique requête DMA 2D. La figure 12 illustre le découpage selon l'invention de requêtes DMA 2D en plusieurs requêtes DMA ID, dans le but de transférer une tuile carré 120 et 20 une tuile rectangulaire 121. Pour cela, la tuile carrée 120 est découpée en 6 tuiles linéaires 122, 123, 124, 125, 126 et 127. La tuile rectangulaire 121 est quant à elle découpée en 4 tuiles linéaires 128, 129, 130 et 131. On peut remarquer que le nombre de requêtes DMA ID est égale à la hauteur de la tuile en entrée. 25 Le présent exemple de bibliothèque pour passer des messages de SPE à SPE permet aux programmeurs d'utiliser efficacement la puissance de traitement du CBE. Elle propose une méthode efficace pour le passage 30 de messages asynchrones et synchrones basée sur la technologie DMA. Le présent exemple de bibliothèque constitue un modèle de programmation adapté aux applications pour le CBE. Elle fournit une interface connue et des modules pour la communauté des chercheurs et des développeurs familiers avec M P I . L'invention décrite précédemment a encore pour principal avantage que, en utilisant des techniques modernes de programmation en C++, une interface simple et concise peut être obtenue sans souffrir aucun inconvénient de performance. De plus, elle fournit des modules pour gérer io les exceptions sur les SPE, pour écrire des tests unitaires pour le code des SPE et pour gérer efficacement la mémoire alignée. REVENDICATIONS1. Procédé de synchronisation et de transfert de données entre N processeurs, où N est un entier supérieur ou égal à 2, chaque processeur comportant une mémoire locale et les processeurs étant reliés deux à deux par des canaux DMA, le procédé étant caractérisé en ce qu'il met en oeuvre un protocole d'échange de messages entre les processeurs via les canaux DMA, chaque message contenant des informations de synchronisation et/ou des données, le protocole incluant: - de remplir un entête dans chaque message avant de l'envoyer; - d'envoyer un jeton d'un processeur destination vers un processeur 1 o source afin d'autoriser le processeur source à envoyer un message au processeur destination; - de transférer du processeur source au processeur destination un bloc de mémoire non aligné ayant été alloué arbitrairement dans la mémoire locale du processeur source. 15 2. Procédé selon la revendication 1, caractérisé en ce qu'il inclut de transférer des données contenues dans des zones mémoire bidimensionnelles de la mémoire locale du processeur source vers la mémoire locale du processeur destination. 3. Procédé selon la revendication 2, caractérisé en ce qu'il inclut de découper la zone mémoire bidimensionnelle en tuiles bidimensionnelles carrées ou rectangulaires, dont le nombre de points de bord est minimal. 25 4. Procédé selon la revendication 3, caractérisé en ce qu'il inclut d'envoyer chaque tuile bidimensionnelle en plusieurs messages via le canal DMA reliant le processeur source et le processeur destination, chaque message contenant une tuile monodimensionnelle linéaire obtenue par découpage de ladite tuile bidimensionnelle. 30 5. Procédé selon la revendication 1, caractérisé en ce que le protocole est conforme au standard MPI. 20 6. Procédé selon la revendication 5, caractérisé en ce que l'entête de chaque message contient: - un champ contenant un identifiant de contexte de communication (communicator identifier), chaque processeur étant identifié par un rang entre 0 et N-1 et l'identifiant de contexte de communication étant formé au moins à partir du rang du processeur source et du rang du processeur destination, et/ou; - un champ contenant une balise de message (tag), cette balise étant un entier permettant d'identifier le message de manière 1 o unique, et/ou; - un champ d'opération (opflags) contenant une indication: o d'envoi, ou; o de réception; - un champ de contrôle (controlflags) contenant une indication: 15 o d'un transfert en cours (SYIV), ou; o d'un transfert de données terminé (ACK), ou; o d'envoi d'un jeton (RD1); - un champ contenant un identifiant de type de données (datatype), et/ou; 20 - un champ contenant une taille de données en octets (datasize), et/ou; - au moins un champ contenant le nombre d'octets déjà transférés s'il s'agit d'un transfert en cours (prependsize, appendsize), et/ou; - un champ contenant la première adresse alignée qui peut être 25 utilisée comme adresse de destination pour transférer des données (address). 7. Procédé selon la revendication 6, caractérisé en ce que le processeur destination autorise le processeur source à lui envoyer un message en lui 30 envoyant un message dont le champ de contrôle dans l'entête indique l'envoi d'un jeton (RDY), ledit jeton étant consommé par le processeur source dès lors que: - le processeur source envoie au processeur destination un message dont le champ de contrôle dans l'entête indique un 35 transfert de données terminé (ACK), ou;- le processeur destination envoie au processeur source un message dont le champ de contrôle dans l'entête indique un transfert de données terminé (ACf); le processeur source n'étant alors plus autorisé à envoyer de message au processeur destination. 8. Procédé selon la revendication 7, caractérisé en ce que, après réception par le processeur source du message dont le champ de contrôle dans l'entête indique l'envoi d'un jeton (RD) et avant envoi du message dont le champ de contrôle dans l'entête indique un transfert de données terminé (ACf), le processeur source envoie au processeur destination au moins un message dont le champ de contrôle dans l'entête indique un transfert en cours (SYIV). 9. Procédé selon la revendication 8, caractérisé en ce que transférer un bloc de mémoire non aligné de la mémoire locale du processeur source à un emplacement donné de la mémoire locale du processeur destination inclut: - que le processeur destination envoie au processeur source un message dont le champ de contrôle dans l'entête indique un transfert en cours (SYIV), ce message contenant la première adresse mémoire alignée dans le bloc de mémoire non aligné qui doit être transféré, ainsi que le nombre d'octets à ajouter avant et le nombre d'octets à ajouter après ladite première adresse alignée, le processeur source en déduisant la première et la dernière adresse du bloc mémoire non aligné qui doit être transféré; - que le processeur source copie dans un premier tampon aligné dans sa mémoire locale, par au moins une opération de mouvement dans sa mémoire locale (MOVE), les blocs mémoire alignés sur lesquels le bloc mémoire non aligné à transférer se trouve; - que le premier tampon soit transmis vers un second tampon similaire aligné dans la mémoire locale du processeur destination, par une ou plusieurs commandes DMA de mise en mémoire (PUT), les adresses desdits tampons ayant été au préalableéchangées entre le processeur source et le processeur destination; - que le processeur source informe le processeur destination, en envoyant un message dont le champ de contrôle dans l'entête indique un transfert de données terminé (ACf), que les données ont été transférées et combien d'octets ont été transférés; - que le processeur destination copie à l'emplacement donné de sa mémoire locale, par au moins une opération de mouvement dans sa mémoire locale (MOVE), le bloc de mémoire non aligné 1 o transféré et contenu dans le second tampon; - que le processeur destination envoie au processeur source, une fois les données copiées à l'emplacement donné, un message dont le champ de contrôle dans l'entête indique l'envoi d'un jeton (RD). 15 10. Procédé selon la revendication 1, caractérisé en ce qu'il inclut en outre de mettre les données à transférer du processeur source vers le processeur destination dans au moins deux tampons de mémoire, de manière à permettre des transactions dans les mémoires locales desdits 20 processeurs alors que lesdits processeurs effectuent des calculs. 11. Procédé selon la revendication 10, caractérisé en ce que l'adresse du premier tampon dans la mémoire locale du processeur source et l'adresse du deuxième tampon dans la mémoire locale du processeur 25 destination sont constantes et prédéfinies.