Un support natif à l’accélération parallèle dans les JVM d'ici 2015

Version imprimable

27/08/2013, 17h45
Stéphane le calme

Un support natif à l’accélération parallèle dans les JVM d'ici 2015

Un support natif à l’accélération parallèle dans les JVM d'ici 2015,
d'après la feuille de route de la HSA

Le consortium industriel HSA Foundation voudrait apporter un support natif à l’accélération parallèle dans les JVM (Java virtual machines) afin de faciliter la tâche aux développeurs Java qui souhaitent programmer sur une gamme variée de processeurs, parmi lesquels les GPU, sans avoir l’expertise requise en matière d'outils traditionnels de développement parallèle.

Fondée l’année passée par Advanced Micro Devices, Qualcomm, ARM Holdings et d’autres compagnies, la HSA (Heterogeneous System Architecture) Foundation est un groupe de fabricants de puces, sociétés de logiciels, et d'autres qui travaillent pour créer une spécification ouverte qui permettrait au logiciel d'être écrit une seule fois puis déployé à travers tout type de dispositif ; consoles de jeux, appareils mobiles ou même serveurs informatiques.

http://www.developpez.com/public/ima...a_resized.jpeg

Ce dimanche, au symposium Hot Chips à l’université de Stanford, Phil Rogers Président de HSA Foundation, a déclaré que le support natif aux spécifications HSA sera embarqué dans Java 9 en 2015, selon un article de nos confrères. Cela permettra aux algorithmes parallèles d’être exécutés en natif dans les JVM apportant un énorme gain de performance sans nécessiter de couches supplémentaires de code, explique Rogers.

Les GPU demandent souvent des outils spécialisés comme CUDA de Nvidia et l'OpenCL du Khronos Group qu’Intel a adopté avec son architecture MIC (Many Integrated Core) et ses co-processeurs Xeon Phi.

La Fondation HSA a déjà publié sa première spécification et travaille sur sa feuille de route. En plus d’optimiser la programmation pour GPU et CPU, la HSA Foundation a prévu une liste d’améliorations pour toute une série de types de co-processeurs, y compris APU, FPGA (field programmable gate arrays), ASIC (application-specific integrated circuits) et les processeurs réseaux.

Source : InfoWorld

Et vous ?

:fleche: Que pensez-vous de cette initiative ?
27/08/2013, 19h29
TNT89

Citation:

Envoyé par Stéphane le calme

afin de faciliter la tâche aux développeurs Java qui souhaitent programmer sur une gamme variée de processeurs, parmi lesquels les GPU, sans avoir l’expertise requise en matière des outils traditionnels de développement parallèle.

Et vous ?

:fleche: Que pensez-vous de cette initiative ?

Mauvais, mauvais, mauvais... Toutes ces architectures sont tellement spécifiques que si vous ne les connaissez pas vous pouvez *pas* obtenir de bonnes performances. Sans cette expertise (et sans utilisation d'outils "tout fait" mais restreints a des taches spécifiques) vous ne pourrez pas tirer parti de ces plateformes.
28/08/2013, 10h14
squizer

Citation:

Envoyé par TNT89

Mauvais, mauvais, mauvais... Toutes ces architectures sont tellement spécifiques que si vous ne les connaissez pas vous pouvez *pas* obtenir de bonnes performances. Sans cette expertise (et sans utilisation d'outils "tout fait" mais restreints a des taches spécifiques) vous ne pourrez pas tirer parti de ces plateformes.

Si dans le fond je suis d'accord que le manque d'expertise ne va pas améliorer la chose, c'est par contre le fait que l'on puisse le faire qui va permettre de:
1) Gagner de l'expérience
2) Gagner de la performance

L'existence d'api pour titiller ces GPGPU n'impose pas leur utilisation. J'y vois donc un status quo ou un avantage.
28/08/2013, 10h28
fab_hunter1100

Salut

Citation:

Mauvais, mauvais, mauvais... Toutes ces architectures sont tellement spécifiques que si vous ne les connaissez pas vous pouvez *pas* obtenir de bonnes performances. Sans cette expertise (et sans utilisation d'outils "tout fait" mais restreints a des taches spécifiques) vous ne pourrez pas tirer parti de ces plateformes.

Je ne suis pas d accord avec ton point de vue. Ce genre de chose est techniquement possible, pas facile a realiser et surtout pas parfait du premier coup , mais ca reste possible .
Cela dependra de la qualité d abstraction du hardware , la qualité des intepreteurs specifiques a chaques architectures.
Le principe est tres simple "plus vous programmez dans les couches inferieurs, moins le programme est portable. plus il y a d abstraction , et vous vous programmez dans les couches superieures , plus le systeme est portable. ".

Citation:

Code once , ..... blablabla

C est clair que c est un slogan marketing, of course.
utiliser ce genre de technologie ou solution (en pleine proliferation) ne signifie en aucune maniere, que le programmeur devrai s exoneré, de faire attention aux specificités des architectures sur lesquelles il voudrai voir son programme s executé.
28/08/2013, 10h49
Traroth2

Citation:

Envoyé par TNT89

Mauvais, mauvais, mauvais... Toutes ces architectures sont tellement spécifiques que si vous ne les connaissez pas vous pouvez *pas* obtenir de bonnes performances. Sans cette expertise (et sans utilisation d'outils "tout fait" mais restreints a des taches spécifiques) vous ne pourrez pas tirer parti de ces plateformes.

Ce que tu dis vas à l'encontre de l'histoire de l'informatique, et notamment des systèmes d'exploitation, qui sont chargés de gérer les ressources de la machine, afin que les programmeurs puissent se concentrer sur du code ayant plus de valeur ajoutée.

Le début du GPGPU a de ce point de vue été une régression, en contraignant les programmeurs à connaitre les finesses de fonctionnement des puces utilisées pour pouvoir faire quelque chose d'utile. Résultat ? Le GPGPU reste peu utilisé. Pour qu'il se répande, il faut en passer par un niveau d'abstraction plus élevé.

Et si on rentre dans des problématiques de machines hétérogènes, ça deviendra ingérable sans ça.
28/08/2013, 17h14
TNT89

Citation:

Envoyé par fab_hunter1100

Le principe est tres simple "plus vous programmez dans les couches inferieurs, moins le programme est portable. plus il y a d abstraction , et vous vous programmez dans les couches superieures , plus le systeme est portable. ".

Mais plus vous avez un code de haut niveau/bonne abstraction, plus votre code est susceptible dêtre lent car non-adapté à la machine cible. C'est notamment vrai pour ces plateformes et encore plus pour des FPGA.

Pour l'exemple avec du GPGPU et Cuda, si vous vous trompez dans l'ordre d'accès en mémoire de vos kernels, vous perdez un ordre de magnitude en vitesse (10x). Le code est semblable en tout point mais l'ordre de vos instructions est mélangé et vous n'en avez même pas conscience. Et ça n'est pas le seul problème, il y a des méthodes simples pour gagner des coefficients 2x~3x en empilant les instructions d'une façon subtilement différente. Et il aussi très simple de perdre ces coefficients en faisant n'importe quoi (dans le sens du manque d'expertise). Enfin, il existe des outils de plus haut niveau (pour Cuda : CuFFT, CuBLAS, etc.) mais il faudra toujours, à un moment ou un autre, développer votre petit kernel qui va faire une tâche plus spécifique, et aussi l'optimiser.

Alors, oui il faut bien commencer quelque part, cela va de soi. Mais je ne pense pas que l'on puisse se transformer en un développeur de solution parallèle en un claquement de doigt (que ce soit GPGPU mais aussi Many-Core, FPGA, etc.).

Par contre, ce dont je suis d'accord c'est bien l'absence d'interface "bas-niveau" dans les JVM... parce que dans une pyramide (bas-niveau / haut-niveau), il faut toujours commencer par la base.
29/08/2013, 18h29
lmontout

Un des principes de Java c'est de vouloir donner la possibilité d'utiliser les ressources de manières plutôt transparente indépendamment de la machine.
Ca surement moins performants qu'un petit code mitonné par un pro spécialisé sur une plateforme spécifique.
Mais ca sera surement plus performant qu'un mauvais code ou que pas de code.

Ca existe pas en c# par hasard?
30/08/2013, 16h24
Traroth2

Citation:

Envoyé par lmontout

Un des principes de Java c'est de vouloir donner la possibilité d'utiliser les ressources de manières plutôt transparente indépendamment de la machine.
Ca surement moins performants qu'un petit code mitonné par un pro spécialisé sur une plateforme spécifique.
Mais ca sera surement plus performant qu'un mauvais code ou que pas de code.

Ca existe pas en c# par hasard?

...et ça sera sûrement pas mal plus performant que le code pondu par la plupart des programmeurs !

Il est possible de faire du code plus performant en C qu'en Java, mais dans la réalité, c'est souvent le code Java qui est plus performant que le code C réellement écrit.
02/09/2013, 14h58
Gouyon

C'est une très bonne initiative. Ca va permettre d'avoir des JVM plus performantes. Maintenant il y aura peut être quelques mauvaise surprise en ce qui concerne la portabilité. Ce qui n’empêchera pas de devoir mettre les mains dans le cambouis si on veut obtenir les meilleurs performances possible.
02/09/2013, 15h13
hwoarang

Citation:

Envoyé par TNT89

Mais plus vous avez un code de haut niveau/bonne abstraction, plus votre code est susceptible dêtre lent car non-adapté à la machine cible.

Avec cet argument, on prouve que l'assembleur est beaucoup plus efficace que tous les autres langages. Ce qui, en pratique, est faux. Les compilateurs récents ont montré qu'ils optimisaient mieux le code que des experts sur des architectures particulières. C'est d'ailleurs ce qu'à prouvé Java en obtenant de meilleurs résultats que du C sur certains projets...

Pour revenir au sujet de départ, c'est une bonne idée. Les résultats obtenus ne dépendront que des JVM. Après, si on développe sur une architecture ou la JVM implémente mal certaines fonctionnalités, il faut utiliser un autre langage...
04/09/2013, 18h45
Gouyon

Citation:

Envoyé par hwoarang

C'est d'ailleurs ce qu'à prouvé Java en obtenant de meilleurs résultats que du C sur certains projets...

Le C n'est pas de l'assembleur même s'il s'en approche fortement :mouarf3:.
Ceci dit je me vois mal développer une application multitache utilisant des GPU en assembleur :marteau:

Citation:

Envoyé par hwoarang

Pour revenir au sujet de départ, c'est une bonne idée. Les résultats obtenus ne dépendront que des JVM. Après, si on développe sur une architecture ou la JVM implémente mal certaines fonctionnalités, il faut utiliser un autre langage...

Tout à fait d'accord :ccool:
05/09/2013, 13h34
Invité

Citation:

Envoyé par TNT89

Par contre, ce dont je suis d'accord c'est bien l'absence d'interface "bas-niveau" dans les JVM... parce que dans une pyramide (bas-niveau / haut-niveau), il faut toujours commencer par la base.

Il existe déjà plusieurs bindings Java d'OpenCL dont JOCL.