[wg-parallel] About Lwt and Async

[Jeremie Dimino]

On Mon, Apr 29, 2013 at 3:57 PM, Anil Madhavapeddy <anil at recoil.org> wrote:
> Got it. I don't have a feel for the performance impact of such deferred
> scheduling, except that the difference between busy-spinning if there are
> outstanding requests, vs dropping into select/kqueue/epoll more frequently
> is very significant.

As Stephen said there shouldn't be more select/kqueue/epoll calls.
The idea is to run all jobs until there is no one left (with a limit)
before doing the blocking select/kqueue/epoll call.

> For example, the Arakoon folks anecdotally reported a 20x performance loss
> between a direct Unix implementation of their database layer vs an Lwt
> one.  A loss that large can only be explained by context switching or
> pathological scheduling somewhere (given we know that Lwt doesn't result
> in a lot more allocation on the major heap).
> http://www.slideshare.net/eikke/arakoon (slide 14/15)
> (I'm CCing Romain, who might have details).

I believe this was about the disk IO.  Disk IO are done using
preemptive threads since unix doesn't support asynchronous disk IO.
When data are cached it is indeed much slower.  You can get about the
same as direct IO after some tweaking: set the async_method to
'switch' and force the process to run only on one cpu. But the switch
method doesn't work with the threaded runtime.