C++ 与子流程通信的最快方式

我有一个父进程，它产生几个子进程来做一些CPU密集型的工作。对于每一批工作，父进程需要向子进程发送几个100MB的数据（作为一个块），完成后，它必须接收大约相同数量的数据（同样作为一个块）。 父进程和子进程是不同的应用程序，甚至是不同的语言（Python和C++），但是如果我在C/C++中有任何解决方案，我可以在需要时编写Python包装器。 我认为最简单的方法是使用管道。这有很多优点，比如主要是跨平台的、简单的、灵活的，而且我甚至可以在以后扩展我的代码，而不需要太多的工作来通过网络进行通信

然而，现在我正在分析整个应用程序，我看到通信中有一些明显的开销，我想知道是否有更快的方法。我的案例（科学研究）并不真正需要跨平台，如果它能在Ubuntu>=12左右运行就足够了（尽管MacOSX也不错）。原则上，我认为将一大块数据复制到管道中并在另一端读取它所花费的时间不应该比设置一些共享内存和执行

memcpy

花费的时间多。我错了吗？或者，如果情况更糟，您会期望有多大的表现

分析本身很复杂，我没有可靠准确的数据，只有线索（因为这是一个非常复杂的系统）。我不知道我现在应该在哪里消磨时间。试图获得更精确的分析数据？尝试实现一些共享内存解决方案，看看它有多大改进？。还是别的什么？我还考虑在库中包装和编译子流程应用程序，并将其链接到主流程中，从而避免与另一个流程的通信——在这种情况下，我只需要一个

memcpy

---

这里有很多关于StackOverflow的相关问题，但我还没有看到不同通信方法的性能比较。

好的，所以我编写了一个小型基准测试工具，它通过共享内存或管道复制一些数据（~200MB），10次

使用MacOSX在我的MacBook上的结果：

Shared memory:
   24.34 real        18.49 user         5.96 sys
Pipe: 
   36.16 real        20.45 user        17.79 sys

因此，首先我们看到共享内存明显更快。请注意，如果复制较小的数据块（~10MB），我几乎看不到总时间的差异

---

第二个明显的区别是在内核中花费的时间。预计管道需要更多的内核时间，因为内核必须处理所有这些读写操作。但我没想到会有这么多。

可能是共享内存。如果可能，请不要将memcpy放入共享内存中-将数据放入共享内存中作为开始。@immibis:考虑到我仍然需要memcpy，两端都需要。它比通过管道复制二进制数据快多少？从理论上讲，没有复制，数据同时存在于两个进程中。那么什么都不做有多快？我不知道管道有多快。你是不是在接收端从管道中积极地读取数据？我知道管道在输入数据量方面有一些限制，但现在我想不起来了。