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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

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


Sujet :

Java

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 385
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 385
    Points : 196 440
    Points
    196 440
    Par défaut 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.


    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé Avatar de TNT89
    Inscrit en
    Juillet 2007
    Messages
    358
    Détails du profil
    Informations personnelles :
    Âge : 34

    Informations forums :
    Inscription : Juillet 2007
    Messages : 358
    Points : 615
    Points
    615
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    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 ?

    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.

  3. #3
    Membre actif
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Octobre 2012
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2012
    Messages : 82
    Points : 277
    Points
    277
    Par défaut
    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.

  4. #4
    Membre régulier
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2013
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Mai 2013
    Messages : 42
    Points : 80
    Points
    80
    Par défaut Salut
    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é.

  5. #5
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    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.

  6. #6
    Membre confirmé Avatar de TNT89
    Inscrit en
    Juillet 2007
    Messages
    358
    Détails du profil
    Informations personnelles :
    Âge : 34

    Informations forums :
    Inscription : Juillet 2007
    Messages : 358
    Points : 615
    Points
    615
    Par défaut
    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.

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    41
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2005
    Messages : 41
    Points : 70
    Points
    70
    Par défaut
    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?

  8. #8
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    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.

  9. #9
    Membre expérimenté
    Avatar de Gouyon
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2003
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Novembre 2003
    Messages : 1 076
    Points : 1 521
    Points
    1 521
    Billets dans le blog
    5
    Par défaut
    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.
    Il y a des jours où j'éprouve une haine profonde envers microsoft et Apple c'est pas mieux
    Mon modeste site et mes modestes oeuvres sont
    Rémi

  10. #10
    Membre chevronné
    Inscrit en
    Mai 2006
    Messages
    1 364
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 1 364
    Points : 1 984
    Points
    1 984
    Par défaut
    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...

  11. #11
    Membre expérimenté
    Avatar de Gouyon
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2003
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Novembre 2003
    Messages : 1 076
    Points : 1 521
    Points
    1 521
    Billets dans le blog
    5
    Par défaut
    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
    Il y a des jours où j'éprouve une haine profonde envers microsoft et Apple c'est pas mieux
    Mon modeste site et mes modestes oeuvres sont
    Rémi

  12. #12
    Invité
    Invité(e)
    Par défaut
    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.

Discussions similaires

  1. Un support natif à l’accélération parallèle dans les JVM d'ici 2015
    Par Stéphane le calme dans le forum Actualités
    Réponses: 4
    Dernier message: 28/08/2013, 11h49
  2. Graal : le compilateur dynamique Java pourrait être utilisé dans les JVM
    Par Hinault Romaric dans le forum Général Java
    Réponses: 40
    Dernier message: 05/04/2012, 00h59
  3. Réponses: 5
    Dernier message: 20/03/2012, 15h24
  4. [XUL] FireFox 1.5.0.4 ne supporte plus les treeview dans les appli web
    Par ultraboa dans le forum Autres langages pour le Web
    Réponses: 9
    Dernier message: 23/11/2006, 11h52
  5. support des espaces dans les noms de fichiers
    Par menuge dans le forum Langage
    Réponses: 9
    Dernier message: 25/10/2006, 10h02

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo