Fourberies et subtilités de ce cher nvc++

Chapter 5.7 : Fourberies et subtilités de ce cher nvc++

Comme nous l'avons vu dans les sections précédentes nvc++ est un compilateur ultra-puissant mais il faut quand même faire attention à ce que l'on fait et ne pas avoir de mauvais réflexes.

Privilégier l'exécution avec l'option std::execution::par_unseq plutôt que std::execution::par sinon le GPU sera utilisé séquentiellement.
Il ne faut surtout pas ajouter une quelconque bibliothèque CUDA au linkage d'un programme compilé avec nvc++ sinon, tout compilera, mais l'exécution plantera. nvc++ se charge de tout. C'est très bien, mais ce n'est pas intuitif à cause du linkage explicite de TBB en C++17.
L'utilisation de nvc++ ne fonctionne qu'avec des GPU assez récents, qui ont des compute capabilities supérieures ou égales à 6. Donc, pas de K80 (compute capabilities=3.7) ou autre Quadro M2200 (compute capabilities=5.0). D'ailleurs tant que l'on y est, la version de Cuda 11 ne supporte que les GPU qui ont des compute capabilities >= 3.5, autant dire que les K80 sont sur la scelette.

Pour le moment ^{noteEn tout cas à l'heure ou j'écris ces lignes}, seul nvc++ est capable de porté du C++17 sur GPU nativement, mais Intel et Cray planchent sur des compilateurs similaires, y compris pour Fortran 2020.

Comme évoqué au début de cette partie, de plus en plus de projets basés sur la LLVM et Vulkan commencent à faire de même (nous avions déjà évoqué SpirV, Kompute ou encore SharkTank ^{noteMais ça sera pour un autre cours.}.