Commit 2010-03-18

Début de mon boulot fabuleux.

Je suis en train de regarder par où commencer la parallélisation du code. La première étape est une parallélisation sur machine SMP, c'est-à-dire la possibilité d'utiliser plusieurs CPUs sur une même machine. Suivra une parallélisation avec MPI lorsqu'on aura acheté notre super cluster.

Pour la première étape, voici mes premières conclusions:

• OpenMP semble être la solution la plus simple, la plus efficace et la moins chère pour paralléliser. J'ai regardé également TBB (“Threading Building Blocks” d'Intel) et j'ai écarté les solutions de plus bas niveau (pthreads, etc.)
• Les compilateurs gcc 4.2 et Visual C++ qu'on utilise actuellement supportent OpenMP 2.0. Ca semble être suffisant pour ce qu'on veut faire.
• La version actuelle d'OpenMP est la 3.0. Elle est disponible avec gcc 4.4 (Linux) et avec le compilateur d'Intel icc (Window ou Linux). Si j'ai bin compris, cette nouvelle version apporte principalement la possibilité de définir des “tasks” (gestion plus souple de la distribution des tâches dans les boucles).
• Utiliser OpenMP est excessivement simple. Il suffit de l'activer dans les options de compilation.
• Visual C++ semble avoir des difficultés à déboguer les sections parallèles. Ca, c'est plus ennuyeux. Sous Linux, ben c'est comme d'habitude, il n'y a rien de valable qui permet de coder facilement.
• Sous Windows, Intel propose “Parallel Studio”. C'est un add-in du Visual Studio (2005 et 2008) qui contient le compilateur C++ d'intel, des libs (pas MKL, malheureusement), un débogueur parallèle et un outil de profiling assez évolués. L'intérêt ici est uniquement au niveau de la facilité de développement: le code généré peut être compilé sans Parallel Studio (avec le compilateur de Microsot ou le gcc) tant qu'on ne fait que de l'OpenMP.

Bref, j'ai installé Parallel Studio et j'ai compilé Metafor avec le compilateur d'intel. Surprise: ca marche presque tout seul!! (mise à part une chiée de nouveaux warnings).

Au niveau de la batterie, par contre, ça n'a pas vraiment marché tout seul: j'ai dû faire des modifs dans l'élément de contact thermomec du second degré en défo défo, dans la création des matrices défo-défo.

Il reste au moins un BUG: le test newac.tests.enim.enimWear2D plante au pas 324 en optimisé… Il faudra donc le débuguer avant de pouvoir utiliser le compiateur intel pour la batterie (ma batterie est donc toujours VC++).

J'ai remplacé les sets hachés de Google par leur équivalent Qt dans les objets Locinv et DofSet. Ceci dans le but de faciliter la compilation du code. On peut donc supprimer cette lib du projet. Il est toujours possible de compiler sans ces sets (il suffit de supprimer la définition de _WITH_QHASH_). On se retrouve alors avec les implémentations du Visual C++ ou du gcc. Par contre la google hash n'est plus disponible.

Au niveau des perfs, on constate rapidement que les hash de google sont plus légères: les tests paramétriques sont fortement pénalisés (CPUx2!). Pour les autres tests, les diffs ne sont pas énormes (parfois on gagne, parfois on perd). Il faudra voir si les tables de hashage de l'intel c++ sont intéressantes.

Aucune obligation d'utiliser le compilateur d'intel à la place du Visual C++, d'autant plus que la batterie ne passe pas complètement avec ce compilateur.

Si vous voulez le faire quand même (avec mes encouragements):

• installez le Parallel Studio (dispo sur le FTP).
• convertissez la solution. Il y a un bouton prévu pour (seul le .sln va être modifié).
• compilez (incredibuild marche!)
• chez moi, j'ai dû ajouter C:\Program Files (x86)\Intel\Parallel Studio\Composer\bin\IA32_Intel64 dans mon PATH pour que Metafor démarre (bug du Parallel Studio?)

Pour utiliser QHash et QSet:

• définir _WITH_QHASH_ (au lieu de _WITH_GOOGLE_SPARSEHASH_) dans votre entête de config (je l'ai déjà fait pour Luc).
• powergreppez les répertoires d'include google du projet pour les remplacer par un truc du genre “$(MYLIBS)\qt-4.3.2\include\QtCore”; “$(MYLIBS)\qt-4.3.2\include”.
• linkez avec QtCore4(d).lib les DLLs mtFEMBase et mtFEM. Ça devrait suffire.
• supprimez google de vos libs.

Les projets linux sont déjà modifiés.

→ Faut-il merger _WITH_QHASH_ avec _WITH_GUI_?? … ben c'est ce que je suis en train de me demander… (et tant qu'on y est on mergerait _WITH_ZLIB_ aussi)… A discuter.

(j'ai supprimé les résultats de la batterie alpha-linux)

— Romain BOMAN 2010/03/18 09:00