[concurrency-interest] ForkJoinPool seems lead to a worselatencythan traditional ExecutorServices
viktor.klang at gmail.com
Tue Apr 17 09:51:06 EDT 2012
2012/4/17 Gregg Wonderly <gregg at cytetech.com>
> On 4/17/2012 8:22 AM, √iktor Ҡlang wrote:
>> On Tue, Apr 17, 2012 at 2:51 PM, David Holmes <davidcholmes at aapt.net.au
>> <mailto:davidcholmes at aapt.net.**au <davidcholmes at aapt.net.au>>> wrote:
>> Sorry that was somewhat terse.
>> ForkJoinPool is not a drop-in replacement as an arbitrary
>> It is specifically design to efficiently execute tasks that implement
>> fork/join parallelism. If your tasks don't perform fork/join
>> parallelism but
>> are plain old Runnables/callables that do blocking I/O and other
>> programming operations then they will not likely see any benefit from
>> a ForkJoinPool.
>> I disagree:
> That has nothing to do with the use of ForkJoin it appears to me. It is
> simply a thread use efficiency change that causes a scheduled thread to do
> enough work that the latency of scheduling becomes a small enough component
> that it disappears from view because the other thread is running (2 are
> available per core) while scheduling occurs.
> This would happen no matter what kind of thread pool was used, with
> appropriate timings/thread-scheduling that created the same effect.
No, the scalability of the ForkJoinPoll is extremely much better than other
> Gregg Wonderly
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest