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
