5.6.10 : Performances obtenues sur MUST
La figure 17 montre les premières performances que nous avons obtenues :
Figure 17 : Premières performances obtenues avec nvc++ sur un produit de Hadamard. Le temps total est donné à gauche noteOu en haut si votre écran est trop petit et le temps par élément est donné à droite noteOu en bas si votre écran est trop petit.
Soyons un peu critique vis à vis de ces résultats :
- Il n'y a aucune raison que les GPU calculent tous à la même vitesse tant leur caractéristiques sont défférentes. Pour que ce soit le cas, il y a manifestement un problème d'optimisation.
- Les calculs par éléments sont extrèmement lent : 20 ns par élément. Comme à pratiquement chaque coût d'horloge des milliers de coeurs sont sensés faire des calculs, cela paraît pour le moins étrange qu'un seul calcul, ou le calul moyen sur un élément, soit si lent. Il doit vraiment y avoir un problème d'optimisation.
La figure 18 montre les performances obtenues en utilisant l'option std::execution::par_unseq plutôt que std::execution::par.
Figure 18 : Performances obtenues avec nvc++ sur un produit de Hadamard avec l'option de parallélisation std::execution::par_unseq. Le temps total est donné à gauche noteOu en haut si votre écran est trop petit et le temps par élément est donné à droite noteOu en bas si votre écran est trop petit.
Tout de suite, on remarque que les performances sont bien meilleures d'environ un facteur 1000. Les GPU ont des temps de calcul différents en fonction de leur performance respective ce qui est déjà plus raisonnable comme résultat.
Petite explication sur ce qu'il s'est passé, en tout cas dans la version 21.9 du HPC_SDK. Lorsque l'on utilise l'option std::execution::par les calculs sur GPU seront effectués de manière séquentielle, donc sur un seul coeur. Ce qui n'est bien entendu par très efficace, surtout quand on en a des milliers à disposition. Donc ce n'était pas un problème d'optimisation mais bien un problème d'exécution.