On Tue, Mar 17, 2009 at 2:44 PM, Rutger ter Borg
[...] You're saying that it is taken for granted that ASIO is bad at handling a great deal of (small) tasks? Taken that for true, then asio also must be bad at handling a large number of small network messages. I.e., I shouldn't try handling all data of a couple of NICs with ASIO, at least not using a threadpool setup?
As I said, perhaps someone more familiar with it could comment; that assessment was from trying out the sample code, playing around with it, and playing around with TBB. There appears the be a 2-lock queue implementation for the handler_queue that is used by the io_service for dispatching handlers; I can't really tell if it is being used or not, or if it has to be enabled manually. This might help performance in the sample.
I was under the impression that ASIO is a high-performance asynchronous event and IO library, and as such, is good at everything it does... Perhaps a lock-free task-queue would change things for the better.
You should maybe develop a more realistic test. The sample code was testing the parallelism of the dispatching code in a sort of worst-case (trivial CPU-bound operation that probably doesn't even need to access any memory), and seemingly it doesn't scale well to multi-core hardware. But unless you're doing something just as trivial in the handlers as you are in the sample, so what? Having written similar things (i.e., asynchronous message-passing to/from network sockets), I've never really found much use, performance-wise, for any more than one thread for dealing with select/poll/epoll/etc on a pool of sockets, compared to the overhead of computation/IO associated with actually doing something with what gets read off the wire. Anyway, I'm not trying to dissuade you from using ASIO, nor trying to imply that it isn't high-performance (high-performance compared to what, for example). I have no idea what you're intended use is. I do notice that the ASIO documentation doesn't really focus on use beyond device IO, and it seems perfectly suitable to that. I would tend to prefer using something like TBB or a simple thread-pool implementation for dispatching the computational work, rather than doing it in ASIO, based solely on that documentation and having now looked a bit at the implementation.
Thanks for pointing out TBB, I'll take a look -- however I'm primarily interested in taking message handling/event handling to the max.
Depends on what happens in the event handling; if you're doing something to disk or a database, I'd suggest you not worry about this aspect of it. If you're doing some sort of computation, bundle up more work per message.