c++ - 在 Linux 上的进程之间传递消息的最快技术？

Question

在 Linux 上，在 C++ 应用程序进程之间发送消息的最快技术是什么？我隐约知道有以下技术可供使用:

• TCP
• UDP
• 套接字
• 管道
• 命名管道
• 内存映射文件

还有其他方法吗？最快的方法是什么？

Answer 1

虽然上述所有答案都非常好，但我认为我们必须讨论什么是“最快”[它必须是“最快”还是“足够快”？]

对于 LARGE 消息，毫无疑问，共享内存是一种非常好的技术，并且在很多方面都非常有用。

但是，如果消息很小，则必须提出自己的消息传递协议(protocol)和通知其他进程有消息的方法是有缺点的。

在这种情况下，管道和命名管道更容易使用 - 它们的行为与文件非常相似，您只需在发送端写入数据，然后在接收端读取数据。如果发送方写了一些东西，接收方会自动唤醒。如果管道已满，则发送端被阻塞。如果发送方没有更多数据，接收方将自动被阻止。这意味着这可以用相当少的代码行来实现，并且可以很好地保证它每次都可以正常工作。

另一方面，共享内存依赖于一些其他机制来通知其他线程“你有一个数据包要处理”。是的，如果您要复制大量数据包，它会非常快 - 但如果管道存在巨大差异，我会感到惊讶，真的。主要好处是对方不必将数据从共享内存中复制出来——但它也依赖于有足够的内存来保存所有“正在运行”的消息，或者发送者有能力保留东西.

我并不是说“不要使用共享内存”，我只是说没有“一种解决方案可以‘最好’解决所有问题”之类的东西。

澄清一下:我将首先使用管道或命名管道[取决于哪个适合目的]实现一个简单的方法，然后测量它的性能。如果实际复制数据花费大量时间，那么我会考虑使用其他方法。

当然，另一个考虑因素应该是“我们是否会使用两台独立的机器 [或同一系统上的两台虚拟机] 来解决这个问题。在这种情况下，网络解决方案是更好的选择 - 即使它是不是最快的，我在我的机器上运行了一个本地 TCP 堆栈以进行基准测试，并获得了一些 20-30Gbit/s (2-3GB/s) 的持续流量。同一进程中的原始 memcpy 大约为 50- 100GBit/s (5-10GB/s) (除非 block 大小非常小并且适合 L1 缓存)。我没有测量标准管道，但我预计这大致在这两个数字的中间。[这个数字对于许多不同的中型相当现代的 PC 来说是正确的 - 显然，在 ARM、MIPS 或其他嵌入式 Controller 上，所有这些方法的数字都较小]