Optimisation pour core A2 2.10
Introduction
Les problèmes de performances du core A2 2.10 sur Dual Core sont du passé : tear, utilisateur du forum officiel, a découvert une variable liée à la couche MPI qui semble résoudre le problème de performances du core A2 sur Dual Core natif et machines virtuelles.
Techniquement, cette variable change le comportement du core vis à vis de la gestion de la mémoire pour les processus MPI. Par défaut, le core Folding@Home utilise la mémoire partagée (shared memory) pour échanger les informations entre les processus. Cette mémoire partagée est une zone mémoire non réservée (par un processus donné) accessible par tous les processus (chacun peut y lire et y écrire).
Après activation de la variable, MPI utilise une gestion plus classique de la mémoire : la mémoire partagée n’est plus utilisée, chaque processus bénéficie donc de son espace mémoire réservé, et les échanges se font en utilisant des connexions TCP/IP (via le localhost en l’occurrence). MPI retrouve ici un fonctionnement pour lequel il a été prévu : l’échange de données entre processus répartis sur un réseau (par exemple, un cluster).
Mise en place
La mise en place de cette variable est très simple. Avant de lancer votre client, vous devez taper la commande suivante, puis lancer votre client comme d’habitude :
Code :
export MPICH_NO_LOCAL=1
Cette commande doit être tapée dans le contexte qui lancera le client. Si vous utilisez un sript automatisé, placez-la avant la commande de lancement du client. Si vous lancez votre client en utilisant un terminal, tapez-la avant de lancer le client dans le même terminal dans lequel vous lancerez le client.
Résultats pratiques
Les tests ont été effectués sur la configuration suivante :
- VMWare Workstation 6.5.2, 640 Mo de RAM, 2 cores.
- Hôte Windows XP SP3 32bits
- Invité Ubuntu Server 9.04 64bits, kernel d’origine 2.6.28-15-server
- Core Linux A2 2.10, Project: 2662 (Run 1, Clone 98, Gen 56)
- Processeur Q6600 @ 3 GHz (333*9), RAM DDR2 400 MHz (4-4-4-10)
Résultat avant mise en place de la variable :
Citation:
[17:14:20] Completed 7500 out of 250000 steps (3%)
[17:27:42] Completed 10000 out of 250000 steps (4%)
[17:41:06] Completed 12500 out of 250000 steps (5%)
[17:55:31] Completed 15000 out of 250000 steps (6%)
[17:27:42] Completed 10000 out of 250000 steps (4%)
[17:41:06] Completed 12500 out of 250000 steps (5%)
[17:55:31] Completed 15000 out of 250000 steps (6%)
Temps par frame : 13:22, 14:24 et 14:25.
Cliquez sur l'image pour l'agrandir.
Dans cette configuration, il semblerait qu’un processus soit assigné à un core (la colonne P correspond au processeur sur lequel le processus s’exécute) et que les trois autres se partagent le deuxième core.
Résultats après mise en place de la variable :
Citation:
[19:41:23] Completed 35000 out of 250000 steps (14%)
[19:53:42] Completed 37500 out of 250000 steps (15%)
[20:05:59] Completed 40000 out of 250000 steps (16%)
[20:17:53] Completed 42500 out of 250000 steps (17%)
[19:53:42] Completed 37500 out of 250000 steps (15%)
[20:05:59] Completed 40000 out of 250000 steps (16%)
[20:17:53] Completed 42500 out of 250000 steps (17%)
Temps par frame : 12:19, 12:17 et 12:54
Cliquez sur l'image pour l'agrandir.
Ici, les processus sont correctement répartis : deux par core physique.
Conclusion
A final, le gain varie entre 28 secondes (3.5%) et 2 minutes et 8 secondes (14.8%) par frame. Le gain est donc significatif, et le ressenti des premiers tests par les utilisateurs semble être un retour au niveau des performances du core A2 2.08. Vu la simplicité de la manipulation, pourquoi s’en priver ?
Attention ! Cette optimisation a un mauvais coté : elle rend le core sensible aux évènement réseaux (déconnexion de cable/wifi, renouvellement DHCP avec changement d'adresse IP, ...), ce qui peut provoquer un plantage du core et la perte de la WU. A éviter sur une machine connectée en Wifi ... et il est recommandé de passer votre machine en IP fixe.
Ecrit par: toTOW, Le: 21/10/09