Discussion :

[dourouc05]

OpenMP 5.0 est prévu pour novembre 2018,
avec l'ajout d'interfaces pour le débogage et l'analyse poussée de la performance

OpenMP est la norme actuelle pour la programmation parallèle à mémoire partagée, c’est-à-dire sur les différents cœurs d’une même machine. Ce genre de technologie permet de tirer parti des machines actuelles, dont le nombre de cœurs ne cesse d’augmenter, même si OpenMP a d’abord été développé pour exploiter les supercalculateurs. La version 4.5 de la norme a étendu les possibilités vers un déchargement de l’exécution du code sur un accélérateur, comme un processeur graphique, disponible dans la machine.

La version 5.0 est annoncée pour la fin de l’année et un nouveau brouillon public est disponible (TR7). Elle apporte bon nombre de nouveautés, comme deux nouvelles interfaces pour la définition d’outils : OMPT pour ceux fournis par l’implémentation d’OpenMP, OMPD pour les outils tiers. Ces outils sont prévus pour inspecter l’état d’OpenMP pendant l’exécution : quand l’objectif d’OMPT est de faciliter l’analyse poussée de la performance du code OpenMP (pourquoi un cœur doit-il attendre ?), celui d’OMPD est plutôt orienté vers le débogage d’applications (pour afficher plus précisément la pile au niveau d’un point d’arrêt, par exemple).

OpenMP 5.0 se focalise aussi sur les accélérateurs. Notamment, la norme introduit des constructions pour gérer les systèmes qui disposent de plusieurs niveaux de mémoire, sous la forme d’espaces de mémoire différents. La clause map sert à transférer les données entre les banques de mémoire. Également, la synchronisation a été revue afin de gérer plus de mécanismes pour acquérir et libérer les droits d’écriture.

Toujours au niveau de la mémoire, la programmation orientée objet est mieux gérée, grâce à la directive declare mapper : elle sert à déclarer la manière de transférer les données d’une structure complexe, c’est-à-dire d’un objet, par exemple vers un accélérateur.

La clause depend gère des dépendances entre tâches plus précises : outre les types entrée-sortie, l’exclusion mutuelle et des dépendances dynamiques ont été ajoutées.

Sources : Technical Report 6 is a preview of OpenMP 5.0, expected in November 2018, OpenMP ARB Releases Technical Report with Support for a Tool Interface, OMPT and OMPD: Emerging Tool Interfaces for OpenMP.

Et vous ?

Qu'en pensez-vous  ?
Quelles nouveautés souhaiteriez-vous avoir dans cette nouvelle version d'OpenMP ?

Voir aussi
La spécification complète.

[Matthieu76]

OpenMP c'est une bibliothèque C++ et Fortran ?

[dourouc05]

Non, c'est une norme qui permet d'annoter du code C, C++ ou Fortran ("la boucle qui suit doit être parallélisée"), si le compilateur l'implémente.

[Matthieu76]

Mais donc il y a un compilateur qui va avec ? Ça fonctionne avec G++, Clang, Visual C++ ?

[dourouc05]

C'est plutôt le contraire : certains compilateurs gèrent OpenMP, d'autres pas. Par exemple, Clang, GCC et Visual C++ l'implémentent tous (mais pas la même version : VC est limité à OpenMP 2.0, les deux autres étant plus à jour). Liste officielle : https://www.openmp.org/resources/ope...mpilers-tools/

[Matthieu76]

Et c'est beaucoup utilisé ? Es-ce vraiment avantageux ? Désolé de poser tous ces questions mais je ne connais pas du tout alors que ça ressemble une solution miracle :
On met une instruction pré-processeur devant toutes les boucles for et paf le code et beaucoup plus rapide !
Genre dans ma library de réseaux de neurones ça serait bien pour paralléliser le travail sur une couche ?

Si c'est si bien que ça pourquoi n'en ai-je jamais entendu parler ?

[Madmac]

À mon avis, le besoin pour les recherches dans ce domaine est nettement plus criant que pour la IA. Avec la surenchère de CPU multicœur, si rend n'est fait la production va atteindre un mur rapidement. Faute de pouvoir se traduire en gains de performance.

Et c'est beaucoup utilisé ? Es-ce vraiment avantageux ? Désolé de poser tous ces questions mais je ne connais pas du tout alors que ça ressemble une solution miracle :
On met une instruction pré-processeur devant toutes les boucles for et paf le code et beaucoup plus rapide !
Genre dans ma library de réseaux de neurones ça serait bien pour paralléliser le travail sur une couche ?

Si c'est si bien que ça pourquoi n'en ai-je jamais entendu parler ?

Pour commencer, il faudrait que les programmeurs abandonnent l'usage des For, while et Until quand ils travaillent sur des tableaux. Les opérations sur les tableaux son généralement "parallélisables" et un opérateur comme each en Ruby n'est utilisable que pour des listes et tableaux. Par contre for while et until peuvent servir également pour la saisie du clavier.

En somme, il faudrait repenser les langages afin de pourvoir signaler au compilateur la possibilité de faire des opérations en parallèle.

J'ai testé OpenMP 2.0 mais pourtant je ne gagne absolument rien en performance, exactement le même temp de calcul.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#pragma omp parallel for num_threads(7)
for (int n = 0; n < numberOfNeurons; ++n)
{
    // ...
}

Pourtant cela fonction car avec ce #pragma je vois les 8 cœurs de mon pc tourner à 100% au lieu d'un seul en temps normal, extrêmement bizarre. Va falloir que j’investigue....

Rien de bizarre, Tu as assisté à ce qui est défini par le terme "Von Newman bottleneck", concept qui énonce que la vitesse d'un système est toujours limité par l'élément le plus lent de l'ensemble. Et dans le cas présent, c'est ton bus mémoire et ta mémoire vive qui est le maillon faible de ce système. La seule solution imparfaite est l'usage de mémoire-cache. Et encore là, les langages de programmation sont le problème.

Par exemple, pendant l'utilisation et la traversé d'un tableau, la portion de code qui est appliqué (la fonction) pourrait n'être lu qu'une seule fois pour être conservé dans la mémoire-cache.

Premier avantage. puisque la mémoire cache est comme un deuxième bus, le bus mémoire est libre pour un autre coeur
Deuxièmement pendant la lecture de cette fonction depuis la mémoire-cache, cela laisse la possibilité de lire simultanément le prochain élément du tableau.

[Invité]

À mon avis, le besoin pour les recherches dans ce domaine est nettement plus criant que pour la IA. Avec la surenchère de CPU multicœur, si rend n'est fait la production va atteindre un mur rapidement. Faute de pouvoir se traduire en gains de performance.

OpenMP traite justement ce genre de problèmes. Ca existe depuis 20 ans et c'est disponible dans quasiment tous les compilateurs C/C++/Fortran mainstream depuis au moins 10 ans.

OpenMP est utilisé dans de nombreuses bibliothèques scientifiques, notamment d'IA :
https://github.com/tensorflow/tensor...Lists.txt#L212
https://github.com/Microsoft/CNTK/bl...mmon.cmake#L72
https://github.com/apache/incubator-...Lists.txt#L387

[Matthieu76]

Rien de bizarre, Tu as assisté à ce qui est défini par le terme "Von Newman bottleneck", concept qui énonce que la vitesse d'un système est toujours limité par l'élément le plus lent de l'ensemble. Et dans le cas présent, c'est ton bus mémoire et ta mémoire vive qui est le maillon faible de ce système. La seule solution imparfaite est l'usage de mémoire-cache. Et encore là, les langages de programmation sont le problème.

J'ai fait quelques testes et le problème ne vient pas de là. Sur des exemples très simple c'est bien 8 fois plus rapide. Le problème vient de mon code, je dois avoir des variables communes dans ma boucle mais c'est compliqué à détecter car j'utilise plusieurs objets dans ma boucle ce qui fait appel à beaucoup de code.