Je suis pas tout à fait d'accord. Une question que je me pose depuis l'annonce d'OpenCL c'est à qui ça se destine. Je travaille sur des codes écrits généralement par des spécialistes de leurs domaines mais pas des informaticiens donc les codes fonctionnent (Fortran, C voir C++), mais ne sont pas optimisés. Ces personnes là font aussi un peu du MPI mais généralement synchrone, et de l'OpenMP, peut être un peu de CUDA, mais ne font pas d'OpenCL. Ceux qui optimisent vont généralement utiliser des technos ad-hoc : des intrinsics pour la vecto, peut être de l'assembleur (quand le compilo n'y arrive pas), du CUDA bien optimisé, etc, mais peu d'OpenCL (sauf pour les archis qui ne supportent que ça) car c'est verbeux, ça oblige à écrire un code optimisé par architecture et pour la portabilité, souvent on ne tourne que sur 1 ou 2 architectures (dans mon domaine au moins).
Concernant les gains en optimisant pour son architecture, c'est généralement pas marginal du tout, même sur des codes très simples et sans descendre au niveau assembleur. Il suffit de prendre une simple réduction pour s'en convaincre, écrite "naïvement" on est assez loin de la bande passante disponible. Un peu d'intrinsics, plusieurs variables temporaires pour accumuler et profiter du pipeline des unités de calcul, des "mov" non temporels si on ne réutilise pas les données ensuite, et le code est tout de suite beaucoup moins lisible mais beaucoup plus rapide. Et pour CUDA je vous laisse réfléchir aux optimisations proposées par M. Harris et à la tête du code final.
Donc la promesse d'OpenCL (en fait pas vraiment d'OpenCL, c'est plutôt ce que beaucoup pensent d'OpenCL) d'écrire un seul code qui passe pas trop mal partout avec des perfs (80% des perfs?) me semble illusoire.
Concernant la rentabilité, ceux qui ont investi dans CUDA il y a 10 ans s'en sortent à mon avis pas mal. Par contre OpenCL, on voit bien le déclin des drivers, du support par les fabricants, de l'utilisation dans des applis comme Blender, etc. Et je pense que SYCL ne résoudra pas non plus le problème. Si on veut des perfs il faut du code spécifique. Après, on peut toujours croire aux compilateurs "automagiques" qui vont automatiquement transformer les structures de données du code, vectoriser, faire les "mov" non temporels quand il faut, dérouler et casser les dépendances correctement, etc. Mais, je pense avoir encore pas mal de boulot pour des années !
[^] # Re: OpenCL, portabilité et performance en général
Posté par sjub . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 3.
Je suis pas tout à fait d'accord. Une question que je me pose depuis l'annonce d'OpenCL c'est à qui ça se destine. Je travaille sur des codes écrits généralement par des spécialistes de leurs domaines mais pas des informaticiens donc les codes fonctionnent (Fortran, C voir C++), mais ne sont pas optimisés. Ces personnes là font aussi un peu du MPI mais généralement synchrone, et de l'OpenMP, peut être un peu de CUDA, mais ne font pas d'OpenCL. Ceux qui optimisent vont généralement utiliser des technos ad-hoc : des intrinsics pour la vecto, peut être de l'assembleur (quand le compilo n'y arrive pas), du CUDA bien optimisé, etc, mais peu d'OpenCL (sauf pour les archis qui ne supportent que ça) car c'est verbeux, ça oblige à écrire un code optimisé par architecture et pour la portabilité, souvent on ne tourne que sur 1 ou 2 architectures (dans mon domaine au moins).
Concernant les gains en optimisant pour son architecture, c'est généralement pas marginal du tout, même sur des codes très simples et sans descendre au niveau assembleur. Il suffit de prendre une simple réduction pour s'en convaincre, écrite "naïvement" on est assez loin de la bande passante disponible. Un peu d'intrinsics, plusieurs variables temporaires pour accumuler et profiter du pipeline des unités de calcul, des "mov" non temporels si on ne réutilise pas les données ensuite, et le code est tout de suite beaucoup moins lisible mais beaucoup plus rapide. Et pour CUDA je vous laisse réfléchir aux optimisations proposées par M. Harris et à la tête du code final.
Donc la promesse d'OpenCL (en fait pas vraiment d'OpenCL, c'est plutôt ce que beaucoup pensent d'OpenCL) d'écrire un seul code qui passe pas trop mal partout avec des perfs (80% des perfs?) me semble illusoire.
Concernant la rentabilité, ceux qui ont investi dans CUDA il y a 10 ans s'en sortent à mon avis pas mal. Par contre OpenCL, on voit bien le déclin des drivers, du support par les fabricants, de l'utilisation dans des applis comme Blender, etc. Et je pense que SYCL ne résoudra pas non plus le problème. Si on veut des perfs il faut du code spécifique. Après, on peut toujours croire aux compilateurs "automagiques" qui vont automatiquement transformer les structures de données du code, vectoriser, faire les "mov" non temporels quand il faut, dérouler et casser les dépendances correctement, etc. Mais, je pense avoir encore pas mal de boulot pour des années !