Discussion :

[Mickael Baron]

SOAT, société d'expertise et de conseil en informatique, et Matthieu Lefèvre, vous propose un tutoriel pour comparer les performances entre les Java lambdas et les classes anonymes en utilisant JMH pour la phase de benchmark.

Voici l'URL du tutoriel : http://soat.developpez.com/tutoriels...classeanonyme/

Si vous avez des commentaires, profitez de cette discussion

Merci d'avance

L'équipe Java

Retrouver les meilleurs cours et tutoriels pour apprendre Java : http://java.developpez.com/cours/

[Philippe Bastiani]

Petite coquille dans la conclusion : Arrays.parallelSort utilise bien l'API fork-join ! et puis les Lambdas utilisent déjà invokeDynamic !

Arrays.parallelSort(), Stream.parallel() CompletableFuture, etc utilisent un pool de thread fork-Join par défaut dont le nombre de threads possibles est dépendant de Runtime.getRuntime().availableProcessors ! L'auteur utilise un i5-2500K avec 4 CPUs et 4 threads/CPU... par défaut le nombre de threads pour la // sera égal à 15 (i.e. 4x4 -1 sachant qu'un thread reste réservé pour l'appelant)...

Arrays.parallelSort() s'appuie sur ForkJoinPool.getCommonPoolParallelism() pour déterminer si la // doit être effective: bref sur dual core (et biensûr un single core) aucune chance d'avoir une quelconque // !

Par défaut nous disposons d'un seul pool de thread fork-join : donc les performances vont être dépendantes du nombre de tâches à paralléliser.

En se qui concerne l'API stream les résultats vont aussi être dépendants de la source de données (par exemple, à la différence d'un Array, une LinkedList se prêtera mal à la // - il en sera de même pour une source de flux I/O - etc). Attention aussi aux opérations longues lors d'une //... de telles opérations seront pénalisantes et le résultat risque fort d'être décevant. Au final Stream.parallel() est facile d'utilisation; mais les résultats sont souvent décevants

a+
Philippe

[Bruno DOOLAEGHE]

Bonjour Philippe,

Petite coquille dans la conclusion : Arrays.parallelSort utilise bien l'API fork-join ! et puis les Lambdas utilisent déjà invokeDynamic !

Sur le fond, nous sommes d'accord. Ce qu'il fallait comprendre dans la conclusion :

(...) l'apparition dans le JDK 8 du tri parallèle sans fork/join pool, par la méthode Arrays.parallelSort()

En effet, fork/join est utilisé dans Arrays.parallelSort() ... Ce que je voulais dire par là, c'est que désormais l'écriture du fork/join n'est plus à la charge du développeur qui souhaite faire un tri parallélisé ; elle est encapsulée dans la méthode Arrays.parallelSort() du JDK8.

Néanmoins, les expressions lambda étant encore bien jeunes dans le monde Java, on est en droit d'espérer des optimisations notables sur leur invocation, dans les prochaines versions de JVM (optimisations qui seront prises en compte dynamiquement, sur un bytecode Java déjà « lambda ready », grâce à l'utilisation d'invokeDynamic !).

InvokeDynamic est effectivement déjà utilisé quand on écrit une lambda. Ce qu'il fallait comprendre ici, c'est que c'est grâce à cela que les futures optimisations de la JVM (sans changement sur le SDK) pourront voir le jour.

Enfin, je suis d'accord sur le fait que même si les API facilitent grandement le travail de découpage et d’exécution d'un traitement en parallèle, elles ne nous dispensent pas de résoudre les problèmes classiques liés à la parallélisation (tels que les goulots d'étranglement)

[Pill_S]

Après une première lecture, je me suis dit "tiens, mais en fait les différences sont vraiment minimes voir insignifiantes..."

Ensuite, j'ai remarqué que l'échelle était logarithmique... Et ça, ça change tout

Du coup, je me demande si ce serait pas mieux d'avoir une échelle normale (quitte à découper les graphiques en morceaux plus petits)? ça rendrait l'interprétation plus naturelle...