Bibliothèques mathématiques pour OpenCL?

Je recherche des informations auprès de tous ceux qui ont essayé d’utiliser OpenCL dans leur code scientifique. Quelqu'un a-t-il essayé (récemment) ViennaCL ? Si oui, comment se compare-t-il à la cuspide ?

Qu'en est-il de OCLTools ? Est-ce qu'il respecte la promesse? Si tel est le cas, serait-il un moyen envisageable de commencer à écrire des noyaux mathématiques dans OpenCL?

Tout d'abord, je souhaite remercier Aron Ahmadia de m'avoir indiqué ce fil.

En ce qui concerne OpenCL dans le code scientifique: OpenCL est censé être une API de bas niveau. Il est donc crucial d’envelopper cette fonctionnalité d’une manière ou d’une autre afin d’atteindre une productivité raisonnable. De plus, dès que plusieurs noyaux de calcul sont impliqués, le code peut devenir TRÈS sale si le noyau OpenCL et les descripteurs de mémoire doivent être fortement échangés au sein d'une application. Je ne connais pas OCLTools, donc je ne peux pas dire s'ils sont utiles à cet égard.

En ce qui concerne ViennaCL: je suis à la tête de ViennaCL, j'ai donc récemment travaillé avec la bibliothèque. :-) Dans ce qui suit, je traiterai la demande de comparaison avec la cusp dans un champ légèrement plus large, à savoir ViennaCL par rapport aux bibliothèques de mathématiques cusp CUDA et MAGMA . Seul l'état actuel est pris en compte, même s'il y a beaucoup de développement en cours (du moins de notre côté).

Fonctionnalité . MAGMA fournit la fonctionnalité BLAS pour les matrices denses via les interfaces de fonction habituelles. ViennaCL 1.2.0 fournit également la plupart de ces fonctionnalités en utilisant des surcharges d’opérateurs et d’autres sucres syntaxiques.

Les trois mêmes solveurs itératifs (CG, BiCGStab, GMRES) sont fournis avec Cusp et ViennaCL. L'ensemble de préconditionneurs diffère notamment: Cusp fournit des préconditionneurs diagonaux, SA-AMG et divers Bridson. ViennaCL propose des factorisations LU incomplètes, des préconditionneurs diagonaux, ainsi que divers arômes AMG et préconditionneurs Sparse Approximate Inverse récemment. À ma connaissance, tous les préconditionneurs de points de rebroussement fonctionnent entièrement sur le GPU, alors que ViennaCL s'appuie particulièrement sur les calculs basés sur le processeur pendant la phase de configuration. Actuellement, le nombre de formats de matrice clairsemés est plus grand en point de rebroussement: COO, CSR, DIA, ELL, HYB, alors que ViennaCL 1.2.0 fournit des COO et des CSR.

ViennaCL fournit un certain nombre de fonctionnalités supplémentaires, qui ne font pas partie ni de MAGMA ni des points de rebroussement: types de matrices structurées (Circulant, Hankel, etc.), transformation rapide de Fourier, algorithmes de réorganisation (p. Ex. Cuthill-McKee) et wrappers pour l'algèbre linéaire types d'autres bibliothèques.

Performance. Les fonctionnalités et la prise en charge matérielle plus étendues de ViennaCL se traduisent généralement par une baisse des performances par rapport aux implémentations basées sur CUDA. Cela est également dû en partie au fait que CUDA est adapté à l'architecture des produits NVIDIA, alors qu'OpenCL représente en quelque sorte un compromis raisonnable entre différentes architectures multicœurs.

Dans l’ensemble, ViennaCL est actuellement plus lent que MAGMA, en particulier au niveau 3 de BLAS. La raison en est l’objet différent de ViennaCL (algèbre linéaire creuse au lieu de dense) et donc le degré plus élevé d’optimisation dans MAGMA. En particulier, les opérations de niveau 3 de BLAS sont considérablement plus rapides dans MAGMA.

De même, la cuspide offre une performance globale légèrement meilleure en général. Cependant, étant donné que les opérations matricielles éparses sont généralement limitées en bande passante mémoire, les différences sont considérablement plus petites et souvent négligeables par rapport à la configuration de données et autres. Le choix du préconditionneur et de ses paramètres a généralement un impact plus important sur le temps d’exécution global que toute différence de performance dans les multiplications maigres matrice-vecteur.

Portabilité . En ce qui concerne la portabilité matérielle, ViennaCL peut utiliser des processeurs et des GPU de tous les principaux fournisseurs grâce à OpenCL. En revanche, CUSP et MAGMA s’appuient sur un GPU NVIDIA approprié.

ViennaCL ne contient que des en-têtes, peut être compilé sur un grand nombre de compilateurs C ++ et ne doit être lié à la bibliothèque OpenCL que si un support GPU est requis. En principe, les algorithmes génériques de ViennaCL peuvent également être utilisés sans aucune liaison OpenCL, tandis que cusp et MAGMA requièrent le compilateur NVIDIA pour la compilation et la bibliothèque CUDA sur le système cible pour son exécution. MAGMA requiert également une bibliothèque BLAS, ce qui peut parfois être un peu fastidieux à trouver ou à installer sur un nouveau système.

API . MAGMA fournit des interfaces de fonction de style BLAS pour la fonctionnalité BLAS. L’interface C ++ de cusp utilise également certaines fonctions de BLAS, mais aucune surcharge d’opérateur. Puisque la plupart des interfaces de ViennaCL sont intentionnellement similaires à Boost.uBLAS et comportent un sucre syntaxique tel que des surcharges d’opérateurs, ViennaCL est également destiné à être utilisé comme Boost.uBLAS. Ainsi, en plus d'appeler simplement un ensemble prédéfini d'opérations et d'algorithmes, notre intention est de rendre aussi simple que possible le passage d'une exécution purement CPU à un code GPU, même si des algorithmes non standard doivent être utilisés. Dans le cas où un noyau OpenCL dédié est requis, il existe également un cadre pour l'intégration de vos propres noyaux OpenCL dans ViennaCL. ViennaCL vise donc beaucoup plus versune productivité élevée en ce sens que le temps requis pour la mise en œuvre de nouveaux algorithmes sur le GPU est réduit au minimum . Ces économies peuvent largement compenser toute perte de performance (le cas échéant) par rapport à CUSP et à MAGMA. (Il a également été mentionné dans le fil de discussion sur les tests unitaires que le temps de développement de code est une ressource précieuse en science.)

Il existe certes un certain nombre de problèmes idéologiques (par exemple, CUDA vs OpenCL, interface BLAS contre des surcharges d’opérateurs) tout au long de ma comparaison, mais leur discussion dépasse le cadre de la question initiale.

OpenCL peut être utilisé, cependant, il y a un manque d’infrastracture, par exemple d’importantes bibliothèques mathématiques matures standard avec des composants d’algèbre linéaire réglés de facto et, dans une certaine mesure, de bons outils de profilage, bien que ce dernier problème se soit considérablement amélioré pour les GPU. Ce logiciel est disponible dans CUDA à ce jour et peut contribuer à une partie du succès de Nvidia avec ce modèle de programmation. Cependant, OpenCL semble rattraper (lentement).

Aujourd'hui, comme point de départ pour la programmation GPU, CUDA convient, et si cela est nécessaire, rien n'empêche d'utiliser OpenCL comme alternative, par exemple pour rendre le code plus portable. Le même code de noyau peut être utilisé à la fois dans CUDA et OpenCL. Par conséquent, passer de CUDA à OpenCL ne devrait pas être un problème majeur. Ceci est confirmé par nos propres expériences. Du point de vue des performances, les mêmes techniques d’optimisation peuvent être utilisées. Pour les compilateurs triviaux de code concurrent, le travail doit être parfait (par exemple, déroulement de la boucle, etc.).