blocking - 为什么 cpu bound 对阻塞 I/O 更好，而 I/O bound 对非阻塞 I/O 更好

Question

有人告诉我，对于 I/O 绑定(bind)的应用程序，非阻塞 I/O 会更好。对于 CPU 密集型应用程序，阻塞 I/O 会好得多。我找不到这种说法的原因。试过谷歌，但很少有文章只是触及这个话题而没有太多细节。有人可以提供深层原因吗？

有了这个，我想弄清楚非阻塞 I/O 的缺点是什么。

经过另一个线程后here ，我可以联系的一个原因是，如果 I/O 进程足够重，那么只有使用非阻塞 I/O 才能看到显着的性能改进。它还指出，如果 I/O 操作的数量很大(典型的 Web 应用程序场景)，其中有很多请求在寻找 I/O 请求，那么我们也看到使用非阻塞 I/O 的显着改进。

因此，我的问题归结为以下列表:

如果是 CPU 密集型应用程序，最好启动一个
线程池(或scala的executionContext)并在
线程池的线程。(我想它肯定有一个
优于产生自己的线程和划分工作的优势
手动。还使用 future 的异步概念，甚至是 CPU 密集型
可以使用回调返回工作，从而避免问题
与多线程阻塞有关？)。此外，如果有 I/O
这足够快，然后使用阻塞原则执行 I/O
线程池本身的线程。我对吗？

使用非阻塞的实际缺点或开销是什么
技术上的 I/O？为什么我们看不到使用的性能提升
如果 I/O 足够快或者如果 I/O 非常少，则为非阻塞 I/O
需要 I/O 操作吗？最终是操作系统正在处理
I/O 的。无论 I/O 的数量是大还是
小，让操作系统处理这种痛苦。这里有什么不同。

Answer 1

从程序员的角度来看，阻塞 I/O 比非阻塞 I/O 更容易使用。你只需调用读/写函数，当它返回时你就完成了。对于非阻塞 I/O，您需要检查是否可以读/写，然后读/写，然后检查返回值。如果不是所有内容都被读取或写入，您需要机制来再次读取或现在或稍后在可以完成写入时再次写入。
关于性能:一个线程中的非阻塞 I/O 并不比一个线程中的阻塞 I/O 快。 I/O 操作的速度由读取或写入的设备(例如硬盘)决定。速度不是由等待(阻塞)或不等待(非阻塞)它的人决定的。此外，如果您调用阻塞 I/O 函数，那么操作系统可以非常有效地执行阻塞。如果您需要在应用程序中进行阻塞/等待，您可能会做得几乎与操作系统一样好，但您也可能做得更糟。
那么为什么程序员要让他们的生活变得更加艰难并实现非阻塞 I/O 呢？因为，这是关键点，他们的程序要做的不仅仅是单一的 I/O 操作。使用阻塞 I/O 时，您需要等到阻塞 I/O 完成。使用非阻塞 I/O 时，您可以进行一些计算，直到阻塞 I/O 完成。当然，在非阻塞 I/O 期间，您还可以触发其他 I/O(阻塞或非阻塞)。
非阻塞 I/O 的另一种方法是使用阻塞 I/O 引入更多线程，但正如 SO post that you linked 中所述。线程是有代价的。该成本高于(操作系统支持的)非阻塞 I/O 的成本。
如果您的应用程序具有大量 I/O，但 CPU 使用率较低，例如具有大量并行客户端的 Web 服务器，那么请使用一些具有非阻塞 I/O 的线程。使用阻塞 I/O，你最终会得到很多线程 -> 成本很高，所以只使用几个线程 -> 需要非阻塞 I/O。
如果您有一个 CPU 密集型应用程序，例如读取文件、对完整数据进行密集计算并将结果写入文件的程序，那么 99% 的时间将花费在 CPU 密集型部分。因此，创建几个线程(例如每个处理器一个)并并行执行尽可能多的计算。关于 I/O，您可能会坚持使用阻塞 I/O 的一个主线程，因为它更容易实现并且因为主线程本身与并行无关(假设计算是在其他线程中完成的)。
如果您的应用程序是 CPU 密集型和 I/O 密集型的，那么您还将使用一些线程和非阻塞 I/O。您可以想象一个具有大量客户端和网页请求的 Web 服务器，您在其中使用 cgi 脚本进行密集计算。在等待连接上的 I/O 时，程序可以计算另一个连接的结果。或者考虑一个读取大文件并可以对文件 block 进行密集计算的程序(例如计算平均值或将所有值加 1)。在这种情况下，您可以使用非阻塞读取，并且在等待下一次读取完成时，您已经可以计算可用的数据。如果结果文件只是一个小的压缩值(如平均值)，您可能会使用阻塞写入来获取结果。如果结果文件与输入文件一样大并且类似于“所有值+1”，那么您可以非阻塞地写回结果，并且在写入完成时您可以自由地对下一个 block 进行计算。