[zeromq-dev] 0MQ for hard real time applications: the inproc communication

[Timothee Besset]

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 <hurtonm at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130418/57cb21b0/attachment.htm>