对于 IPC 共享对象 -ZeroMQ 或 Boost::interprocess 哪个更快？

Question

我正在考虑自定义对象的进程间共享。我当前的实现使用 ZeroMQ，其中对象被打包成一条消息并从进程 A 发送到进程 B。

我想知道使用 boost::interprocess 实现并发容器是否会更快（其中进程 A 将插入到容器中，进程 B 将从中检索）。不确定这是否比在进程 A 中序列化对象然后在进程 B 中反序列化它更快。

只是想知道是否有人做过基准测试？比较两者在概念上是否正确？

Answer 1

原则上，ZeroMq 应该更慢，因为它使用的比喻是消息的传递。这些类型的库不是为了共享内存区域，也不是为了让不同的进程能够同时修改它们。

具体来说，您提到了“包装”。在共享内存区域时，您可以 - 理想情况下 - 避免任何打包并按原样处理数据（当然，在并发使用相同的数据结构时需要小心，使用偏移量而不是指针等）

还要注意的是，即使共享是一个单向的来回（即一次只有一个进程访问任何数据），ZeroMq也只能匹配IPC共享内存的使用，如果它支持一路零复制下。从关于零复制的常见问题页面我不清楚这一点（但无论如何可能是这种情况）。

Answer 2

我同意尼姆的观点，他们太不同了，很难比较。

ZeroMQinproc使用共享内存作为字节传输。

Boost.Interprocess 似乎主要是在共享内存中构造对象，可供多个进程/线程访问。然而它确实有消息队列，但它们也只是需要序列化对象的字节传输，就像您必须使用 ZeroMQ 一样。它们不是对象容器，因此与 ZeroMQ 更具可比性，但与 Boost.Interprocess 所代表的内容相去甚远。

我已经完成了 ZeroMQ / STL 容器混合。耶克。我使用 C++ STL 队列来存储对象，然后使用 ZeroMQ PUSH/PULL 套接字来控制哪个线程可以从该队列读取。读取线程在 ZeroMQ 轮询中被阻止，当它们收到消息时，它们会锁定队列并从中读取对象。这避免了序列化对象，这很方便，所以速度相当快。这不适用于 PUB/SUB，这意味着在接收者之间复制对象，这需要对象序列化。