Le gros souci de ces technologies c'est que cela manque d'outils.
Du coté "carte graphique", c'est Cuda ou meurt. Tout ce qui contient "Open" dans le nom manque d'outils. À une époque, Nvidia fournissait les mêmes outils de diagnostics pour Cuda et pour OpenCL, mais depuis peu (sous Linux en tout cas), les outils nvidia ne sont plus capables de me faire un diagnostic sur mes kernel OpenCL...
Pour ceux qui n'en ont jamais fait, en gros Cuda/OpenCL/OpenGL Compute c'est simple, vous écrivez un code compact, léger, joli, de 30 lignes pour faire une addition de vecteur et cela tourne relativement vite. Après vous, regardez ce que disent les outils, et vous vous rendez compte que vous n'utilisez que 5% de la puissance théorique de votre GPU... Bon, on améliore un peu son code, au final il fait 500 lignes, contient des "barrier()" de partout, des copies de mémoire de partout et quelques bits hacks et l'on est content. En Cuda c'est simple parce que nvidia fourni des outils qui te disent presque quels bithack seront efficaces. En OpenCL, c'est dans le flou artistique... Et une fois que tu as fini de coder, tu as 2**N façon de lancer ton code et en fonction de la façon dont tu le fais, c'est plus ou moins lent, et cela dépend de la carte utilisée... ARGGGG. (Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)
Maintenant, j'ai craqué, je fais tous mes kernel en OpenGL compute, et je ne fais que des codes "simples et intuitifs", en acceptant de ne tourner qu'à 10% de la puissance théorique..
Côté CPU, OpenMP c'est vraiment sympa, mais je lui préfère intel TBB qui, au lieu d'être à base de directive de précompilateur, est une librairie. Sur le papier, j'aime moins, mais c'est subjectif.
Ma petite réflexion du jour s'adresse aux décideurs qui ont entendu parler du GPGPU : "Un GPU n'est pas un tool magique qui multiplie votre puissance de calcul par plusieurs millions. Oui, c'est intéressant, oui c'est puissant, mais cela vient avec un cout de dev/maintenance non négligeable et cela ne règle pas tous les problèmes. Et si vous preniez autant de temps pour optimiser vos codes CPU que vos codes GPU, sans doute que vous ne vous poseriez pas la question d'utiliser un GPU". (PS: oui, j'en ai marre des comparaisons qui bench du code CPU de merde, sans SIMD, sans thread, avec des patterns d'accès mémoire naze, sur un cpu à 30 euros avec un TDP de 3 Watt et qui les comparent à 2 ans de dev sur un code GPU optimisé au poil pour une gamme de cartes particulières, qui coute 600 euros et consomme 400 Watts !)
# Manque d'outils !
Posté par Guillaum (site web personnel) . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 6.
Le gros souci de ces technologies c'est que cela manque d'outils.
Du coté "carte graphique", c'est Cuda ou meurt. Tout ce qui contient "Open" dans le nom manque d'outils. À une époque, Nvidia fournissait les mêmes outils de diagnostics pour Cuda et pour OpenCL, mais depuis peu (sous Linux en tout cas), les outils nvidia ne sont plus capables de me faire un diagnostic sur mes kernel OpenCL...
Pour ceux qui n'en ont jamais fait, en gros Cuda/OpenCL/OpenGL Compute c'est simple, vous écrivez un code compact, léger, joli, de 30 lignes pour faire une addition de vecteur et cela tourne relativement vite. Après vous, regardez ce que disent les outils, et vous vous rendez compte que vous n'utilisez que 5% de la puissance théorique de votre GPU... Bon, on améliore un peu son code, au final il fait 500 lignes, contient des "barrier()" de partout, des copies de mémoire de partout et quelques bits hacks et l'on est content. En Cuda c'est simple parce que nvidia fourni des outils qui te disent presque quels bithack seront efficaces. En OpenCL, c'est dans le flou artistique... Et une fois que tu as fini de coder, tu as 2**N façon de lancer ton code et en fonction de la façon dont tu le fais, c'est plus ou moins lent, et cela dépend de la carte utilisée... ARGGGG. (Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)
Maintenant, j'ai craqué, je fais tous mes kernel en OpenGL compute, et je ne fais que des codes "simples et intuitifs", en acceptant de ne tourner qu'à 10% de la puissance théorique..
Côté CPU, OpenMP c'est vraiment sympa, mais je lui préfère intel TBB qui, au lieu d'être à base de directive de précompilateur, est une librairie. Sur le papier, j'aime moins, mais c'est subjectif.
Ma petite réflexion du jour s'adresse aux décideurs qui ont entendu parler du GPGPU : "Un GPU n'est pas un tool magique qui multiplie votre puissance de calcul par plusieurs millions. Oui, c'est intéressant, oui c'est puissant, mais cela vient avec un cout de dev/maintenance non négligeable et cela ne règle pas tous les problèmes. Et si vous preniez autant de temps pour optimiser vos codes CPU que vos codes GPU, sans doute que vous ne vous poseriez pas la question d'utiliser un GPU". (PS: oui, j'en ai marre des comparaisons qui bench du code CPU de merde, sans SIMD, sans thread, avec des patterns d'accès mémoire naze, sur un cpu à 30 euros avec un TDP de 3 Watt et qui les comparent à 2 ans de dev sur un code GPU optimisé au poil pour une gamme de cartes particulières, qui coute 600 euros et consomme 400 Watts !)