In the guide for ZeroMQ, there is this:
If you use
inprocand socket pairs, you are building a tightly-bound application, i.e., one where your threads are structurally interdependent. Do this when low latency is really vital.
I care a lot about latency for my application.
Question:
Is it the "inproc-ness" alone that makes it low-latency?
Or is there something special about "inproc + PAIR" that is faster than inproc + "WHATEVER"?
The inproc-ness is certainly going to be a big part of it. I'm surmising that for the inproc transport there's a bare minimum of interaction with the operating system; thus with the minimum of OS overheads (message transfer is probably little more than memcpy's and possibly a semaphore or two, or similar) it's as fast as can be.
Compared to the other transports, ipc, tcp, etc; they're all reaching down into bits of the OS that are subject to a lot of work. For example, ipc (pipes) involve copying from a source buffer into an OS buffer, and then copying back out from that to the destination buffer, plus all the transitions from user to OS execution contexts, and there's more of those if the messages are > 4kB long (or whatever the system page size is). With the inproc transport the transitions aren't there (maybe one or two for the semaphores) and possibly one less memcpy. Similarly delving into the tcp stack is asking for a lot of variability.
The PAIR too has the minimum of complexity and overhead to the distribution pattern. It's strictly one to one, no more. So that too is low on overhead. That's my reading of this section in The Guide, which you've already come across. PUB/SUB, etc all have more going on, more than is necessary for one-2-one communications.
The minimum of OS interaction and complexity combines to minimise the latency. The minimum of OS interaction will also on some platforms help keep the latency fairly consistent.
I'm not deeply knowledgeable of the innards of ZeroMQ, but there's a good chance that inproc+PAIR on top of an real time OS gives a very good consistency in latency. Often it's the consistency in latency that matters as much as the shortness of the delays.
Q : is it the "
inproc-ness" alone that makes it low-latency?
Yes, . . . as bazza has already put in general yesterday, let me add a few cents :
1) the inproc://-transport-class is the stack-less, protocol-free and a pure ( thus fast & almost zero-latency ) RAM memory-region mapping vehicle and also ( as was asked in the second question )
Q : Or is there something special about "
inproc + PAIR" that is faster thaninproc + "WHATEVER"?
2) the PAIR/PAIR-Scalable-Formal-Communication-Pattern archetype is adding no extra, Pattern's archetype-related, multi-(many)-party behavioural-handshaking ( compared to some of the other, distributed Finite-State-Automata ( expressing the Pattern's archetype behaviour states and transitions among all the distributed peers - not with a PAIR/PAIR exclusive 1-on-1 digital fire-hose ) so nothing gets added here, beyond thread-safe local pointer mechanics on either side plus some Context()-instance signalling.
Incidentally, you may have noticed, that for a pure-inproc://-transport-class application, you may instantiate the Context( 0 ) having Zero-I/O-threads, as in these cases the Context()-signaling does not need them at all, as it just manages pointer-tricks over local-RAM memory-regions -- so cute, isn't it? )
