On that subject are there straightforward ways to tweak inproc latency in the ZMQ configuration, besides msg and socket options?
On Thu, Apr 18, 2013 at 8:46 AM, Martin Hurton <[email protected]> wrote: > You have some control over memory allocation when transporting message > using ypipes. > See message_pipe_granularity parameter in config.hpp. > > - Martin > > On Thu, Apr 18, 2013 at 5:26 PM, Timothee Besset <[email protected]> wrote: > > Isn't the memory allocation part of those inproc exchanges blowing away > any > > speed advantages of the lockless pipes in the first place anyway? > > (I haven't looked at the innards of the implementation) > > > > TTimo > > > > > > > > On Thu, Apr 18, 2013 at 10:23 AM, Martin Hurton <[email protected]> > wrote: > >> > >> > My main question at the moment is about the current implementation of > >> > INPROC > >> > transport. > >> > Digging it seems like the actual implementation is the class pipe_t, > am > >> > I > >> > right? > >> > >> Yes, producer side writes the message to the pipe and consumer reads > >> it from it. The pipe is implemented as lockfree on some platforms. > >> There is some overhead when the consumer is sleeping, as a "wakeup" > >> control message has to be delivered. > >> > >> > I have done some benchmark using the perf tool (inproc_lat) and I get > an > >> > average latency of 8 usec. > >> > It is not bad, but using lockfree FIFO I can achieve times that are > TWO > >> > orders of magnitude lower. > >> > >> You mean 80 ns? > >> > >> > I know that the beauty of ZeroMQ it is that it doesn much more for me, > >> > but I > >> > would like to understand better the current implementation of INPROC > >> > sockets > >> > to see if I can contribute with a more efficient implementation. > >> > >> The lock-free fifo is implemented in ypipe.hpp. > >> This is used to implement pipes (message queues). These are > >> bi-directional and implement internal signalling which is used for > >> flow control (so that producer is woken up when more messages can be > >> pushed and consumer is woken up when another message can be pulled). > >> The inproc is implemented using a pipe. > >> Socket.cpp contains the code contains plumbing + implementation of API > >> layer. > >> > >> I hope this can help you start with your changes. > >> Do not hesitate to ask should you have more questions. > >> > >> - Martin > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
