Some questions about CAF
105 views
Skip to first unread message
De Pizzottri
May 19, 2016, 12:48:59 AM5/19/16
to actor-framework
Hi, I have some questions about future of the CAF:
1. Do you consider to change queue of work-stealing sheduler from lock-based to lock-free? It is likely that it gives an increase in performance.
2. Do you plan to make some kind of multithread IO multiplexor to handle high network load? And what is the status of asio_multiplexor?
3. Further, having good ASIO multiplexor it may be useful to create new coroutines based scheduler?
Dominik Charousset
May 19, 2016, 10:40:57 AM5/19/16
to actor-f...@googlegroups.com
Hi,
> 1. Do you consider to change queue of work-stealing sheduler from lock-based to lock-free? It is likely that it gives an increase in performance.
Lock-free queues can in theory be more efficient for high contention, yes. However, lock-free algorithms can also be slower for low-concurrency scenarios due to their high complexity. As long as stealing is a rare event (which it should), the job queues are accessed by a single thread (the worker itself) most of the time.
Also, existing lock-free algorithms (due to the lack of DCAS in practice) are complex and often have a lot of limitations. Boost.Lockfree for instance only supports FIFO, while the work-stealing scheduler uses a mix of LIFO and FIFO operations (LIFO for on-thread messaging in order to optimize for cache locality). Other implementations like Facebook.Folly are often singe-reader-single-writer queues or are bounded.
That being said, I'm of course open to alternative implementations. If you can point us to a queue that yields better performance in benchmarks, I'm happy to replace the existing one (given that the license on that queue permits it). The same is true for a different policy/queue mix in general.
> 2. Do you plan to make some kind of multithread IO multiplexer to handle high network load? And what is the status of asio_multiplexer?
There are currently no ongoing efforts to make the I/O multiplexer multi-threaded. Since the I/O performance is limited by the the network card, multi-threading probably only makes sense for multiple I/O devices. As long as brokers do minimal work on the CPU and spawn "regular" actors for actual tasks.
The main problem one had to solve for a multi-threaded multiplexer is that Brokers must never run in two separate threads at once. Regardless of how many connections they manage. Since there is no synchronization taking place in CAF to enforce this, simply using the ASIO multiplexer multi-threaded is unsafe. I think having a multi-threaded I/O backend available would be great, but it's not a high priority to us, currently. We are of course always happy for contributions.
As far as the ASIO multiplexer is concerned: 0.15 will allow you to switch between the default and the ASIO implementation per config parameter if CAF was built with ASIO. Otherwise, it requires a few lines of code to plug it in (or any other custom multiplexer). I don't have benchmark results available as to which implementation is faster. My guess is the default multiplexer, because ASIO heap-allocates a lot of small function objects internally.
> 3. Further, having good ASIO multiplexer it may be useful to create new coroutines based scheduler?
I don't see how coroutines would be beneficial to CAF. Actors (Brokers in this case) are designed as event-based resumables. This means we don't pay for context switches and also don't need to allocate a stack for each actor.
Or did you suggest to only get the I/O events from the OS and then schedule the brokers along other actors?
FWIW, CAF used to include an actor implementation based on Boost.Context (AFAIR) to have "pseudo-blocking", cooperatively-scheduled actors. They hadn't much application scenarios, because they are outperformed by their event-based counterparts. They are also expensive in terms of memory, since you need a full stack allocated per actor. The final nail in the coffin, however, was the unstable API of Boost.Context. Almost each new release broke code in CAF. So we made the decision to drop context-switching actors altogether (little gain for too much maintenance work).
If you want the scheduler of CAF to run your coroutines alongside event-based actors, all you need to do is to implement the abstract class resumable. I would advise you to wait for the first pre-release of 0.15 before starting such a project, though.
Dominik
> 1. Do you consider to change queue of work-stealing sheduler from lock-based to lock-free? It is likely that it gives an increase in performance.
Also, existing lock-free algorithms (due to the lack of DCAS in practice) are complex and often have a lot of limitations. Boost.Lockfree for instance only supports FIFO, while the work-stealing scheduler uses a mix of LIFO and FIFO operations (LIFO for on-thread messaging in order to optimize for cache locality). Other implementations like Facebook.Folly are often singe-reader-single-writer queues or are bounded.
That being said, I'm of course open to alternative implementations. If you can point us to a queue that yields better performance in benchmarks, I'm happy to replace the existing one (given that the license on that queue permits it). The same is true for a different policy/queue mix in general.
> 2. Do you plan to make some kind of multithread IO multiplexer to handle high network load? And what is the status of asio_multiplexer?
There are currently no ongoing efforts to make the I/O multiplexer multi-threaded. Since the I/O performance is limited by the the network card, multi-threading probably only makes sense for multiple I/O devices. As long as brokers do minimal work on the CPU and spawn "regular" actors for actual tasks.
The main problem one had to solve for a multi-threaded multiplexer is that Brokers must never run in two separate threads at once. Regardless of how many connections they manage. Since there is no synchronization taking place in CAF to enforce this, simply using the ASIO multiplexer multi-threaded is unsafe. I think having a multi-threaded I/O backend available would be great, but it's not a high priority to us, currently. We are of course always happy for contributions.
As far as the ASIO multiplexer is concerned: 0.15 will allow you to switch between the default and the ASIO implementation per config parameter if CAF was built with ASIO. Otherwise, it requires a few lines of code to plug it in (or any other custom multiplexer). I don't have benchmark results available as to which implementation is faster. My guess is the default multiplexer, because ASIO heap-allocates a lot of small function objects internally.
> 3. Further, having good ASIO multiplexer it may be useful to create new coroutines based scheduler?
I don't see how coroutines would be beneficial to CAF. Actors (Brokers in this case) are designed as event-based resumables. This means we don't pay for context switches and also don't need to allocate a stack for each actor.
Or did you suggest to only get the I/O events from the OS and then schedule the brokers along other actors?
FWIW, CAF used to include an actor implementation based on Boost.Context (AFAIR) to have "pseudo-blocking", cooperatively-scheduled actors. They hadn't much application scenarios, because they are outperformed by their event-based counterparts. They are also expensive in terms of memory, since you need a full stack allocated per actor. The final nail in the coffin, however, was the unstable API of Boost.Context. Almost each new release broke code in CAF. So we made the decision to drop context-switching actors altogether (little gain for too much maintenance work).
If you want the scheduler of CAF to run your coroutines alongside event-based actors, all you need to do is to implement the abstract class resumable. I would advise you to wait for the first pre-release of 0.15 before starting such a project, though.
Dominik
Reply all
Reply to author
Forward
0 new messages