CODEWITHSUNDEEP
c++11ipczeromqboost-interprocess
L.Koh
L.Koh

Reputation: 109

Which is faster for IPC sharing of objects -ZeroMQ or Boost::interprocess?

I am contemplating inter-process sharing of custom objects. My current implementation uses ZeroMQ where the objects are packed into a message and sent from process A to process B.

I am wondering whether it would be faster instead to have a concurrent container implemented using boost::interprocess (where process A will insert into the container and process B will retrieve from it). Not sure if this will be faster than having to serialise the object in process A and then de-serialising it in process B.

Just wondering if anyone has done benchmarking? Is it conceptually right to compare the two?

Upvotes: 5

Views: 8018

Answers (3)

einpoklum
einpoklum

Reputation: 131808

In principle, ZeroMq should be slower, because the metaphor it's using is the passing of messages. These kinds of libraries are not intended for sharing regions of memory, in place, and for different processes to be able to modify them concurrently.

Specifically, you mentioned "packing". When sharing memory regions, you can - ideally - avoid any packing and just work on data as-is (of course, with the care necessary in concurrent use of the same data structures, using offsets instead of pointers etc.)

Also note that even when sharing is a one-directional back-and-forth (i.e. only one process at a time accesses any of the data), ZeroMq can only match the use of IPC shared memory if it supports zero-copying all the way down. This is not clear to me from the FAQ page on zero-copying (but may be the case anyway).

Upvotes: 5

Eric Xu
Eric Xu

Reputation: 79

ZMQ IPC is effective only in linux(using UNIX domain socket) The performance is slower than boost::interprocess shared_memory

Upvotes: 1

bazza
bazza

Reputation: 8414

I agree with Nim, they're too different for easy comparison.

ZeroMQ has inproc which uses shared memory as a byte transport.

Boost.Interprocess seems to be mostly about having objects constructed in shared memory, accessible to multiple processes / threads. However it does have message queues, but they too are just byte transports requiring objects to be serialised, just like you have to with ZeroMQ. They're not object containers, so are more comparable to ZeroMQ but is quite a long way from what Boost.Interprocess seems to represent.

I have done a ZeroMQ / STL container hybrid. Yeurk. I used a C++ STL queue to store objects, but then used a ZeroMQ PUSH/PULL socket to govern which thread could read from that queue. Reading threads were blocked on a ZeroMQ poll, and when they received a message they'd lock the queue and read an object out from it. This avoided having to serialise objects, which was handy, so it was pretty fast. This doesn't work for PUB/SUB which implies copying objects between recipients, which would need object serialisation.

Upvotes: 3

Related Questions