IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Java : support natif de l'accélération parallèle dans les JVM d'ici 2015
D'après la feuille de route de la HSA

Le , par Stéphane le calme

51PARTAGES

6  1 
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.


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 ?

Que pensez-vous de cette initiative ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 28/08/2013 à 10:49
Citation Envoyé par TNT89 Voir le message
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.
2  1 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 30/08/2013 à 16:24
Citation Envoyé par lmontout Voir le message
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.
1  0 
Avatar de squizer
Membre actif https://www.developpez.com
Le 28/08/2013 à 10:14
Citation Envoyé par TNT89 Voir le message
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.
0  0 
Avatar de fab_hunter1100
Membre régulier https://www.developpez.com
Le 28/08/2013 à 10:28
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. ".

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é.
1  1 
Avatar de lmontout
Membre régulier https://www.developpez.com
Le 29/08/2013 à 18:29
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?
0  0 
Avatar de Gouyon
Membre expérimenté https://www.developpez.com
Le 02/09/2013 à 14:58
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.
0  0 
Avatar de hwoarang
Membre chevronné https://www.developpez.com
Le 02/09/2013 à 15:13
Citation Envoyé par TNT89 Voir le message
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...
1  1 
Avatar de Gouyon
Membre expérimenté https://www.developpez.com
Le 04/09/2013 à 18:45
Citation Envoyé par hwoarang Voir le message
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 .
Ceci dit je me vois mal développer une application multitache utilisant des GPU en assembleur
Citation Envoyé par hwoarang Voir le message

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
0  0 
Avatar de
https://www.developpez.com
Le 05/09/2013 à 13:34
Citation Envoyé par TNT89 Voir le message
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.
0  0 
Avatar de TNT89
Membre confirmé https://www.developpez.com
Le 28/08/2013 à 17:14
Citation Envoyé par fab_hunter1100 Voir le message
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.
0  1