[concurrency-interest] Performance regression in newest (6/20/2013) jsr166 update
ron.pressler at gmail.com
Wed Jun 26 11:13:45 EDT 2013
> ... async mode (which is not common) ...
AFAIK, all actor/messaging libraries that on FJ (like Akka and Quasar) use
FJPool in async mode.
> Most of this can be reinstated though, which on a quick check of a quick
touch-up recovers performance on your test case. Stay tuned.
Obviously, FJ is mostly intended for batch parallelization, but it's such a
good scheduler that online, low latency software is relying on FJ for
scheduling. It would be a shame to sacrifice the async mode for the sake of
the default mode. If it has to be done, maybe we should have different
class for the async case?
On Wed, Jun 26, 2013 at 3:03 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 06/22/13 20:42, Ron Pressler wrote:
>> A couple of months ago I described the behavior detailed in the email
>> below. The newest update causes a slowdown of about 25% of this benchmark:
> static ForkJoinPool fjPool = new ForkJoinPool(PARALLELISM,
>> ForkJoinPool.**defaultForkJoinWorkerThreadFac**tory, null, true);
> Yes, some handling for pools run in async mode (which is not common)
> got a little worse in the course of improving vastly more common cases.
> Most of this can be reinstated though, which on a quick check of
> a quick touch-up recovers performance on your test case. Stay tuned.
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest