You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Repeatedly, the scheduler turns out to be a bottleneck in performance tests, and -S 1 (schedule everything on one thread) consistently yields better results than -S 2 (or more). I believe that we need a less greedy work-stealing algorithm, so that tasks will tend to stay on the same thread more often; because otherwise we will end up with too many cache misses between the cores.
There must be some simple way to utilize the excellent work by Doug Lea on efficient fork/join and taskstealing.
Hi Kresten.
You might want to take a look at Quasar. It uses fork/join to schedule its fibers (and the actors running in fibers).
When I have some time I'd like to port erjang to use Quasar rather than Kilim to see the effect on performance. It should be promising, as we're constantly working on improving Quasar.
In any case, I can probably help you if you have any questions regarding FJ. For example, in a ring benchmark, FJ also performs best when using only one thread (and for a good reason).
Repeatedly, the scheduler turns out to be a bottleneck in performance tests, and
-S 1
(schedule everything on one thread) consistently yields better results than-S 2
(or more). I believe that we need a less greedy work-stealing algorithm, so that tasks will tend to stay on the same thread more often; because otherwise we will end up with too many cache misses between the cores.There must be some simple way to utilize the excellent work by Doug Lea on efficient fork/join and taskstealing.
Mind you, this is really an issue with Kilim (https://github.com/kilim/kilim), who's scheduler we're using.
The text was updated successfully, but these errors were encountered: