如何获得最快的数据处理方式：fork or/and 多线程
How to get the fastest data processing way: fork or/and multithreading
想象一下，我们有一个客户端，不断发送大量双倍数据。
现在我们正在尝试做一个服务器，它可以接收和处理来自客户端的数据。
这是事实：
服务器可以在很短的时间内收到双倍
服务端有处理double的功能，只处理一个double需要3分钟以上
我们需要让服务器尽可能快地处理来自客户端的 1000 double 数据。
我的想法如下：
使用线程池创建多个线程，每个线程可以处理一个double
所有这些都在Linux.
我的问题：
现在我的服务器只是一个包含多线程的进程。我正在考虑如果我使用 fork()，会不会更快？
我认为只使用 fork() 而不使用多线程应该是个坏主意，但是如果我创建两个进程并且每个进程都包含多线程怎么办？这种方法可以更快吗？
顺便说一句，我已阅读：
What is the difference between fork and thread?
Forking vs Threading
fork 这样做比启动一个线程要慢得多。线程比完整的 OS 进程更轻量级（传统上，尽管进程在过去几年有所赶上），不仅在 CPU 要求方面，而且在内存占用和一般方面OS开销。
当您考虑预先安排的线程或进程池时，设置时间 在您的程序运行期间不会占太多，因此您需要查看 "what is the cost of interprocess communications" - 线程之间（本地）通常比进程之间更便宜（线程不需要通过 OS 来交换数据，仅用于同步，在某些情况下你甚至可以不用那）。但不幸的是，您没有说明是否需要 IPC between 工作线程。
总结：我看不出使用fork()有什么好处，至少在效率方面没有。
在某种程度上，这在很大程度上取决于底层硬件。它还取决于内存限制、IO 吞吐量、...
示例：如果您的 CPU 有 4 个内核，并且每个内核能够 运行 两个线程（并且该系统上没有太多其他事情）；那么您可能更希望有一个包含 4 个进程的解决方案；每个 运行 两个线程！
或者，在使用 fork() 时，您将 fork() 4 次；但是在每个分叉进程中，您应该将您的工作分配给两个线程。
长话短说，你真正想做的是：不要把自己锁在某个角落。您想要创建一个具有 声音 和合理设计的服务（如前所述，您正在构建服务器，而不是客户端）。
根据您的要求，您希望以一种允许您配置 多少个进程的方式构建该应用程序。它将使用的线程。然后你开始分析（意思是：你测量发生了什么）；也许你做实验来找到给定硬件/OS堆栈的最佳选择。
编辑：我很想说——欢迎来到现实世界。您正面临满足产品精确 "performance goals" 的要求。如果没有这样的目标，程序员的生活会很轻松：大多数时候，一个人只是坐下来，组装一个合理的产品，并考虑到当今硬件的强大功能，"things are good enough"。
但是如果事情还不够好，那么只有一个方法：你必须学习所有在这里发挥作用的东西。从事物 "which system calls in my OS can I use to get the correct number of cores/threads?"
开始
换句话说：您 "got away" 不知道所用硬件的确切容量的日子...已经结束了。如果你打算 "play this game";那么就没有弯路：你必须学习规则！
最后：最这里最重要的不是进程与线程。你要明白，这里需要把握全图。如果您调整客户端以获得最大 CPU 性能，这并没有帮助...然后发现网络或 IO 问题导致 "loss" 的 10 倍 CPU 与您通过查看 CPU 获得的结果相比只要。换句话说：您必须查看系统中的所有部分；然后你需要衡量以了解你的瓶颈在哪里。 然后你决定要采取的行动！
Michael Nygard 的 "Release It" 是一本很好的读物。当然，他的书主要是关于 Java 世界中的模式；但他做得很好 "performance" 的真正含义。
想象一下，我们有一个客户端，不断发送大量双倍数据。
现在我们正在尝试做一个服务器，它可以接收和处理来自客户端的数据。
这是事实：
服务器可以在很短的时间内收到双倍
服务端有处理double的功能，只处理一个double需要3分钟以上
我们需要让服务器尽可能快地处理来自客户端的 1000 double 数据。
我的想法如下：
使用线程池创建多个线程，每个线程可以处理一个double
所有这些都在Linux.
我的问题：
现在我的服务器只是一个包含多线程的进程。我正在考虑如果我使用 fork()，会不会更快？
我认为只使用 fork() 而不使用多线程应该是个坏主意，但是如果我创建两个进程并且每个进程都包含多线程怎么办？这种方法可以更快吗？
顺便说一句，我已阅读：
What is the difference between fork and thread?
Forking vs Threading
fork 这样做比启动一个线程要慢得多。线程比完整的 OS 进程更轻量级（传统上，尽管进程在过去几年有所赶上），不仅在 CPU 要求方面，而且在内存占用和一般方面OS开销。
当您考虑预先安排的线程或进程池时，设置时间 在您的程序运行期间不会占太多，因此您需要查看 "what is the cost of interprocess communications" - 线程之间（本地）通常比进程之间更便宜（线程不需要通过 OS 来交换数据，仅用于同步，在某些情况下你甚至可以不用那）。但不幸的是，您没有说明是否需要 IPC between 工作线程。
总结：我看不出使用fork()有什么好处，至少在效率方面没有。
在某种程度上，这在很大程度上取决于底层硬件。它还取决于内存限制、IO 吞吐量、...
示例：如果您的 CPU 有 4 个内核，并且每个内核能够 运行 两个线程（并且该系统上没有太多其他事情）；那么您可能更希望有一个包含 4 个进程的解决方案；每个 运行 两个线程！
或者，在使用 fork() 时，您将 fork() 4 次；但是在每个分叉进程中，您应该将您的工作分配给两个线程。
长话短说，你真正想做的是：不要把自己锁在某个角落。您想要创建一个具有 声音 和合理设计的服务（如前所述，您正在构建服务器，而不是客户端）。
根据您的要求，您希望以一种允许您配置 多少个进程的方式构建该应用程序。它将使用的线程。然后你开始分析（意思是：你测量发生了什么）；也许你做实验来找到给定硬件/OS堆栈的最佳选择。
编辑：我很想说——欢迎来到现实世界。您正面临满足产品精确 "performance goals" 的要求。如果没有这样的目标，程序员的生活会很轻松：大多数时候，一个人只是坐下来，组装一个合理的产品，并考虑到当今硬件的强大功能，"things are good enough"。
但是如果事情还不够好，那么只有一个方法：你必须学习所有在这里发挥作用的东西。从事物 "which system calls in my OS can I use to get the correct number of cores/threads?"
开始换句话说：您 "got away" 不知道所用硬件的确切容量的日子...已经结束了。如果你打算 "play this game";那么就没有弯路：你必须学习规则！
最后：最这里最重要的不是进程与线程。你要明白，这里需要把握全图。如果您调整客户端以获得最大 CPU 性能，这并没有帮助...然后发现网络或 IO 问题导致 "loss" 的 10 倍 CPU 与您通过查看 CPU 获得的结果相比只要。换句话说：您必须查看系统中的所有部分；然后你需要衡量以了解你的瓶颈在哪里。 然后你决定要采取的行动！
Michael Nygard 的 "Release It" 是一本很好的读物。当然，他的书主要是关于 Java 世界中的模式；但他做得很好 "performance" 的真正含义。