Re: ForkJoin refresh

On 1/17/20 5:11 PM, Francesco Nigro wrote:

> How these results are been obtained?

I'm not set up to report performance on a published benchmark suite, so
just informally characterized results. Checking the Renaissance suite is
helpful in avoiding over-reliance on microbenchmarks that might not
capture typical uses. But coming up with results people could readily
compare with others is a lot of work. It would be great if anyone wants
to take this on.

Also currently, some programs in the suite (version 0.10) don't work
with JDK12+. To run the ones that appear to work (although in two cases
with warnings that might bear on results), and use FJ (in a few cases
not all that much) try:

java --patch-module java.base=jsr166.jar [... gc settings ...] \
  -jar renaissance-gpl-0.10.0.jar \

fj-kmeans,future-genetic,scrabble,reactors,par-mnemonics,neo4j-analytics,finagle-http,finagle-chirper

With --csv option for results, and/or use their instructions to run
under JMH at https://github.com/renaissance-benchmarks/renaissance/
> 
> Thanks,
> Francesco
> 
> Il ven 17 gen 2020, 22:40 Doug Lea via Concurrency-interest
> <[email protected]
> <mailto:[email protected]>> ha scritto:
> 
> 
>     Now committed in jsr166 are extensions of the AQS refresh of last fall
>     to also cover ForkJoin; among other things removing reliance on builtin
>     monitors  The extra few months were mainly a result of noticing that the
>     initial way I did this increased performance differences across garbage
>     collectors. These are now reduced (not increased), but still worth
>     noting: FJ programs are relatively sensitive to GC choice because they
>     entail work-stealing duels between program and collector. On hotspot,
>     usually the best throughput for divide-and-conquer style usages
>     (including parallelStreams) is with -XX:+UseParallelGC. For unstructured
>     computations with lots of little tasks (for example little
>     CompletableFutures), UseShenandoahGC (and/or if needing more than 32GB
>     heap, UseZGC) are often better choices.  UseParallelGC meshes well with
>     highly generational structured parallelism, but is prone to
>     card-mark-contention with small tasks (even with -XX:+UseCondCardMark)
>     and long pauses. The default UseG1GC tends to be somewhere in the
>     middle. Also, on linux, using -XX:+UseTransparentHugePages seems to
>     always be a good idea for programs using FJ. (Other switches seem to
>     have less consistent positive effects.)
> 
>     These days, it is almost impossible to quantify exactly how much better
>     performance is, but it's likely that your usages are faster. For
>     example, about half of the programs in the recent Renaissance Suite
>     (https://renaissance.dev/) somehow use FJ, and most of these have
>     improved scores on most machines, most JVMs (including OpenJ9 and
>     Graal), most collectors, most phases of the moon....
> 
>     It would be great to get feedback from other usages before integrating
>     into OpenJDK. As usual, you can try it with any JDK11+ JVM by grabbing
>     http://gee.cs.oswego.edu/dl/concurrent/dist/jsr166.jar and running "java
>     --patch-module java.base="$DIR/jsr166.jar", where DIR is the full file
>     prefix. (Although beware that using --patch-module slows down startup,
>     and occasionally entire test runs. For other options, see
>     http://gee.cs.oswego.edu/dl/concurrency-interest/index.html).
> 
>     -Doug
> 
>     _______________________________________________
>     Concurrency-interest mailing list
>     [email protected]
>     <mailto:[email protected]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 


_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest