www.application-servers.com

Commentaires

1. Le mercredi, septembre 17 2008, 09:32 par Bob

Voila une bonne nouvelle enfin. Seulement le principe n'est vraiment pas récent, en effet si on regarde le mode parallèle de notre moteur SGBD favori (Oracle :) ), je ne crois pas me tromper en disant qu'il gère son parallélisme de requêtage de la même manière.

2. Le mercredi, septembre 17 2008, 10:04 par David MARTIN

Effectivement le principe n'est pas nouveau, sauf pour notre JVM favorie :-)
C'est en 1994 dans les labos du MIT qu'est apparu le premier langage adoptant cette approche. C'est dire que l'idée a eu le temps d'être cogitée avant d'atterrir dans la JSR-166y.

http://supertech.csail.mit.edu/cilk...

3. Le mercredi, septembre 17 2008, 13:38 par Alexis MP

Les coeurs sont comme autant de processeurs vu de l'application et heureusement on a déjà des solutions. java.util.concurrent propose déjà pas mal de choses pour répartir les traitements et puis les serveurs d'applications n'ont aucun mal à "scaler" sur du multi-coeur.

4. Le mercredi, septembre 17 2008, 14:32 par David MARTIN

C'est vrai que Java 5 a apporté des facilités appréciables. Et java.util.concurrent actuel propose des solutions comme l'ExecutorService, laquelle apporte une abstraction déjà satisfaisante pour parallèliser des tâches non corrélées. L'approche proposée par la JSR-166y va cependant plus loin et permet de réduire (quasi) totalement les temps d'attentes qu'une tâche pouvait imposer à un thread ("IO wait") et offre ceci de façon transparente au développeur.

Et les serveurs d'applications, même si déjà hautement multithreadés, pourront encore bénéficier de cette nouveauté, au même titre que tout autre programme Java (on élargit aussi ainsi sensiblement la cible ainsi en ne restant pas que dans le périmetre des applications sous serveurs d'app.)

5. Le mercredi, septembre 17 2008, 23:29 par Dominique De Vito

L'avantage de par la JSR-166 sera sans doute négligeable pour les serveurs d'application qui peuvent dors et déjà utiliser un thread par requête et l'API NIO. Une autre partie de l'utilisation de la JSR-166 sera sans doute masquée par l'utilisation des workflow et des moteurs de chorégraphie ou d'orchestration. Bref, dans un premier temps, cette JSR-166 ne devrait pas être utlisée par le développeur lambda.

Quant aux applications clients, il y a pas mal d'autres pbs à résoudre aussi.

Pourquoi ne pas utiliser les annotations pour gérer les threads ? Cela serait sans doute possible pour SwingWorker and co, i.e. pour gérer correctement l'EDT, mais quid des autres cas ?

6. Le mercredi, septembre 17 2008, 23:53 par Dominique De Vito

Comme dit l'autre, en matière de multi-core, "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" : http://www.gotw.ca/publications/con...

Un besoin particulier se fait sentir dans le domaine des jeux (cas particulier du calcul intensif). Un des exposés le plus complet que j'ai lu à ce sujet est "The Next Mainstream Programming Language: A Game Developer's Perspective", de Tim Sweeney (Epic Games) : http://www.st.cs.uni-sb.de/edu/semi...

De fait, dans le domaine du jeu, les besoins sont tellement forts afin d'exploiter toute la puissance des (nombreux) multi-core dispos que l'industrie du jeu pourrait aller vers des langages exotiques comme le langage fonctionnelle Hashkell !

OK, la JSR-166 est intéressante mais bon, cela ne me fait pas envie : trop bas-niveau. Pourquoi pas s'il faut aller vers là, i.e. mettre à ce point les mains dans le cambouis, mais quid de l'exploitation du parallélisme implicite du code Java ; c'est à dire quid de la détection automatique (ou semi-automatique via les annotations ?) du parallélisme du code Java écrit actuellement, sans avoir recours à une nouvelle API ? Il y a déjà des papiers là-dessus. Peut être que dans un premier temps, la JSR-166 ne serait pas nécessaire tant que cela...

7. Le jeudi, septembre 18 2008, 00:39 par Alexis MP

GlassFish + jsr166y = fishfarm.dev.java.net

8. Le jeudi, septembre 18 2008, 11:37 par Dominique De Vito

Tiens, je viens de me rappeller que Jini peut être utilisé pour faire du fork/join et il y a déjà eu des présentations à JavaOne sur l'utilisation combinée de Java et de Jini (il y a qques années maintenant), par ex, pour des simulations de Monte-Carlo à Wall Street.

Jini and JavaSpaces on Wall Street (TS-5471)
Frank Greco - Chairman - NYJavaSIG
JavaOne 2005

Bref, vu de loin, la JSR-166 a l'air d'être une variante du fork/join de Java+Jini/JavaSpace, dans le contexte mono-programme et mono-processeur.

Réflexion_1 : est-ce que l'approche Java/Jini ne suffirait pas (sachant que même dans un contexte mono-truc, on a des multi-coeurs), combinée avec du parallélisme implicite ? Cela éviterait d'avoir plusieurs variantes de fork/join.

Réflexion_2 : au delà de Java/Jini, le fork/join, c'et l'affaire du grid computing, non ? Vu que les processeurs ont maintenant plusieurs coeurs, on a donc potentiellement du grid computing dans nos machines de tous les jours. Faut-il temporiser selon le mode de programmation actuel (quitte à "tordre" un peu le bras de ce mode de programmation), en utilisant JSR-166, ou y aller carrément, et changer de mode en allant plus vers du grid computing à la Java/Jini ?

Apparemment, on n'a pas l'air d'aller vers du grid computing comme mode de programmation de tous les jours. Bref, la JSR-166 a l'air d'être là pour éviter, si possible, de changer de paradigme de programmation et de langage (Java). Apparemment, on est encore à chercher à faire du grid computing en exprimant aisément du parallélisme mais sans trop changer de programmation. Pas facile : l'adaptation aux multi-coeurs ne fait que commencer.

PS : avec Glassfish (mais Jini plutôt que JSR-166), il y a aussi :
Flashgridding with Java: Using Project GlassFish, JavaSpaces and Groovy in an Open Source Supercomputer (TS-3714)
Van Simmons, Sean Merritt and Jim Gammill
Project Leaders of ComputeCycles Project : http://computecycles.dev.java.net
JavaOne 2006

Recherche