Java 8, c’est pour 2013 d’après les annonces d’Oracle. Autant dire pour demain. De nombreuses choses sont déjà sur les rails, dont les évolutions du framework Fork / Join, dont je t’ai déjà beaucoup parlé, cher et précieux lecteur. Alors pourquoi revenir encore sur le sujet ? Simplement parce que le célèbre Brian Goetz, auteur du non moins célèbre Java Concurrency in Practice, nous a décrit par le menu ce qui nous attendait sur le front des calculs en parallèle dans Java 8. C’était le 16/11/2011, lors de Devoxx, à Anvers. D’ailleurs, si tu n’es pas encore au courant, je te signale, précieux lecteur, que Devoxx va s’importer à Paris en avril 2012, puisque Devoxx France est maintenant officiellement lancée !
Archives par mot-clé : Programmation concurrente
Java 7 : fork / join et parallel arrays – 2
Cet article est la deuxième partie de la présentation des parallel arrays de la JSR 166, dirigée par Doug Lea. . Nous en étions restés au début de la présentation des opérations disponibles sur les parallel arrays. Continuons en terminant notre tour d’horizon des opérations disponibles sur ces tableaux, avant de donner une idée des gains en performance.
Continuer la lecture de Java 7 : fork / join et parallel arrays – 2
Java 7 : fork / join et parallel arrays – 1
Le pattern fork / join, nouveauté de Java 7 et création de Doug Lea a déjà fait l’objet de quatre articles sur ce blog, et tu pourrais penser, précieux et rare lecteur, que j’en ai assez dit sur le sujet, qu’il est temps de passer à autre chose.
En fait il n’en est rien, car, bien que déjà très complète, l’API Fork / join telle que livrée par Doug Lea pour Java 7 ne comporte pas tous les éléments du package JSR-166, notamment un morceau très intéressant pour nous : les parallel arrays.
Dans nos précédents articles, nous prenions comme exemple le calcul intensif sur des tableaux. La parallélisation semble simple : il suffit de découper le tableau en morceaux, de les traiter, puis de regrouper les résultats. Simple mais pas tant que ça, car nous avions vu que la stratégie de découpage a une influence sur la performance globale du processus et que des problèmes de synchronisation pouvaient se poser.
Ce découpage ressemble au pattern map / reduce, dont nous allons reparler plus loin. En fait, nous avions mis en évidence que les problèmes de synchronisation pouvait surgir dans cette approche, et que les résultats des calculs, de ce fait, devenaient fragiles.
Et nous n’avons pas encore parlé de l’influence de la parallélisation sur le résultat d’un calcul sur un tableau, qui, dans certains cas, peut changer du tout au tout ! Mais ça, ça sera pour une autre fois.
Je te propose, cher lecteur, un petit voyage au cœur des parallel arrays, qui résolvent ces problèmes.
Continuer la lecture de Java 7 : fork / join et parallel arrays – 1
Java 7 : le fork / join divise pour mieux régner
Dans la continuité de mes deux précédents articles, je voudrais aborder ici les bonnes approches de division en tâches dans le cadre du framework fork / join. Cela me permettra aussi de répondre ici à des questions envoyées par quelques précieux lecteurs (car oui, ce blog est lu par plusieurs personnes !). Le framework fork / join a pour objet de traiter de très grandes quantités de données, dans de très nombreuses tâches, tout en conservant le principe qu’une tâche doit effectuer un « petit » traitement. L’une des difficultés est de garantir que la quantité d’opérations réalisées par une tâche donnée reste limitée, et, surtout, n’augmente pas avec la taille globale du traitement.
Par exemple, dans un calcul matriciel, on ne veut pas que le temps de traitement d’une tâche dépende de la taille de la matrice à traiter.
Continuer la lecture de Java 7 : le fork / join divise pour mieux régner
Java 7 : plus loin dans le fork / join
La présentation du framework fork / join, objet de notre épisode précédent ne comportait qu’un seul exemple. Cet exemple était simple, mais non trivial tout de même. J’y avais glissé une remarque, que, précieux et averti lecteur, tu n’auras pas manqué de relever en te disant : « encore une remarque en l’air, qui tombe à plat, ces blogs techniques, tous les mêmes ! ».
Cette remarque est la suivante :
Chaque calcul et chaîne de calcul doivent être exécutés dans la même réserve, pour des raisons que nous verrons plus loin.
Eh bien nous y sommes, au « plus loin ». Je te propose, précieux lecteur, d’explorer plus avant les choses, afin qu’aucune zone d’ombre ne subsiste dans ce merveilleux framework.
Continuer la lecture de Java 7 : plus loin dans le fork / join
Java 7 : fork / join
Un précédent article, Synchronisation et volatilité, traitait de programmation concurrente, et de la façon dont le JMM (Java Memory Model), avait été entièrement réécrit en Java 5 (JLS v3). Il laissait complètement de côté l’API java.util.concurrent, nouveauté de Java 5, écrite par Doug Lea, et conçue à partir de l’API edu.oswego, disponible en Java 4. Cette API a subi quelques évolutions entre Java 5 et Java 6 , et en subit encore en Java 7.
C’est à un petit bilan de l’existant, et un rapide tour de table des nouveautés que je te convie aujourd’hui, cher et précieux lecteur. Je parlerai surtout du framework fork / join, et de la façon dont on peut l’utiliser. Pour une fois, dans Java le Soir, on va parler de l’avenir. Note bien, que, plus le temps passe, et plus l’avenir a tendance à devenir le passé, ce qui finira aussi par arriver à ce qui est écrit ici !
Synchronisation et volatilité
Les deux notions de synchronisation et de volatilité sont en train de prendre, depuis quelques années, une importance croissante. La généralisation des processeurs multicœurs, jusque dans les téléphones portables, fait surgir des bugs dans les applications Java, qui ne s’observaient pas auparavant.
Nous avons de la chance, nous autres développeurs Java, pour deux raisons. La première, c’est que nous avons une doc, la JLS (Java Language Specification, nous vivons sous le règne de la v3), qui spécifie tous les aspects du langage. La deuxième, c’est que cette doc comporte un chapitre 17, qui traite précisément des problématiques de la programmation concurrente.
Nous avons aussi deux malchances. La première, c’est que la JLS est vraiment un document pénible à lire. Et la deuxième, c’est que le chapitre 17 est totalement hermétique. Finalement, traiter des problèmes complexes dans des documents illisibles a au moins un mérite : ça peut justifier l’écriture d’articles dans des blogs techniques.
Donc, ne reculant devant rien pour te satisfaire, précieux et intrépide lecteur, je te propose une petite explication de texte sur la synchronisation en Java, qui, je l’espère éclairera ta lanterne sur une problématique majeure du développement, actuellement et pour les années qui viennent.