为什么cpu绑定对于阻止I/O会更好，而I/O绑定对于非阻止I/O会更好 [英] Why cpu bound is better with blocking I/O and I/O bound is better with non blocking I/O
问题描述
有人告诉我，对于受I/O约束的应用程序，非阻塞I/O会更好.对于受CPU约束的应用程序，阻塞I/O更好.我找不到这种说法的原因.尝试过使用google，但是很少有文章能以很少的细节触及该主题.有人可以提供其深层原因吗?
I have been told that for I/O bound applications, non blocking I/O would be better. For CPU bound applications, blocking I/O is much better. I could not find the reason for such a statement. Tried google, but few articles just touches the topic with not much details. Can someone provide the deep depth reason for it?
有了这个，我也想弄清楚非阻塞I/O的缺点.
With this, I want to clear myself with what are the short coming of non blocking I/O as well.
经过另一个线程后在这里，我可以联系的一个原因是，如果I/O流程足够繁重，那么只有我们可以看到使用非阻塞I/O带来的显着性能改进.它还指出，如果I/O操作的数量很大(典型的Web应用程序场景)，其中有许多请求在寻找I/O请求，那么我们也将看到使用非阻塞I/O的显着改进.
After going through another thread here,a reason I could relate was out was if the I/O process is heavy enough then only we can see significant performance improvements using non blocking I/O. It also states that if the number of I/O operations is large(a typical web application scenario) where there are many requests looking out for I/O requests, then also we see significant improvements using non blocking I/O.
因此，我的问题归结为以下列表:
Thus my questions boil down to the following list:
-
对于CPU密集型应用程序，最好启动一个 线程池(或scala的executionContext)并在 线程池的线程.(我想它肯定有一个 产生自己的线程并划分工作的优势 手动.还使用未来的异步概念，甚至占用大量CPU 可以使用回调返回工作，从而避免了问题 与阻止多线程有关?).另外，如果有I/O 这足够快，然后使用 线程池本身的线程.我说的对吗?
In case of a CPU intensive applications, is it better to start a threadpool(or executionContext of scala) and divide the work between the threads of the threadpool.(I guess it has definitely an advantage over spawning your own threads and dividing the work manually. Also using asyn concepts of future, even CPU intensive work can be returned using callbacks hence avoiding the issues related to blocking of multi threading?). Also if there is a I/O which is fast enough, then do the I/O using blocking principles on the threads of thread pool itself. Am I right?
使用非阻塞的实际缺点或开销是什么 从技术上讲I/O?为什么我们看不到使用性能有多少提高 如果I/O足够快或很少，则为非阻塞I/O 需要I/O操作吗?最终是操作系统在处理 I/O的.不管I/O数量大还是I/O数量大 小，让OS处理那种痛苦.这有什么不同?
What are actually short comings or overheads of using a non blocking I/O technically? Why we don't see much performance gains of using non blocking I/O if the I/O is fast enough or if there are very less I/O operations required? Eventually it is the OS which is handling I/O's. Irrespective of whether the number of I/O's are large or small, let OS handle that pain. What makes the difference here.
推荐答案
从程序员的角度来看，阻塞I/O比非阻塞I/O更易于使用.您只需要调用读/写功能，当它返回时就可以完成.使用非阻塞I/O，您需要检查是否可以读取/写入，然后读取/写入，然后检查返回值.如果没有读取或写入所有内容，则需要一种机制可以再次读取或现在或以后在可以完成写入时再次写入.
From a programmer's perspective blocking I/O is easier to use than nonblocking I/O. You just call the read/write function and when it returns you are done. With nonblocking I/O you need to check if you can read/write, then read/write and then check the return values. If not everything was read or written you need mechanisms to read again or to write again now or later when write can be done.
关于性能:在一个线程中非阻塞I/O不会比在一个线程中阻塞I/O快. I/O操作的速度由读取或写入的设备(例如硬盘)确定.速度不是由等待(阻止)或不等待(阻止)的人确定的.同样，如果您调用阻塞I/O函数，则OS可以非常有效地进行阻塞.如果您需要在应用程序中执行阻止/等待操作，则可能会做得与操作系统差不多，但是您也可能做得更糟.
Regarding performance: nonblocking I/O in one thread is not faster than blocking I/O in one thread. The speed of the I/O operation is determined by the device (for example the hard disc) that is read from or written to. The speed is not determined by someone waiting for (blocking on) or not waiting for (nonblocking on) it. Also if you call a blocking I/O function then the OS can do the blocking quite effectively. If you need to do the blocking/waiting in the application you might do that nearly as good as the OS, but you might also do it worse.
那么，程序员为什么要增加生活并实现无阻塞I/O?因为并且这是关键点，所以他们的程序要做的不只是单个I/O操作.使用阻塞I/O时，您需要等待直到阻塞I/O完成.使用非阻塞I/O时，您可以进行一些计算，直到完成阻塞I/O.当然，在非阻塞I/O期间，您还可以触发其他I/O(阻塞或非阻塞).
So why do programmers make their life harder and implement nonblocking I/O? Because, and that is the key point, their program has more to do than only that single I/O operation. When using blocking I/O you need to wait until the blocking I/O is done. When using nonblocking I/O you can do some calculations until the blocking I/O is done. Of course during nonblocking I/O you can also trigger other I/O (blocking or nonblocking).
另一种非阻塞I/O的方法是通过阻塞I/O抛出更多线程，但正如
Another approach to nonblocking I/O is to throw in more threads with blocking I/O, but as said in the SO post that you linked threads come with a cost. That cost is higher is than the cost for (OS supported) nonblocking I/O.
如果您的应用程序具有大量I/O，但CPU使用率较低，例如具有多个并行客户端的Web服务器，则请使用一些具有非阻塞I/O的线程.使用阻塞的I/O，您将得到很多线程->高成本，因此仅使用几个线程->需要非阻塞的I/O.
If you have an application with massive I/O but only low CPU usage like a web server with lots of clients in parallel, then use a few threads with nonblocking I/O. With blocking I/O you'll end up with a lot of threads -> high costs, so use only a few threads -> requires nonblocking I/O.
如果您具有CPU密集型应用程序，例如读取文件，对完整数据进行密集型计算并将结果写入文件的程序，则有99％的时间将花费在CPU密集型部分中.因此，创建几个线程(例如，每个处理器一个线程)并并行执行尽可能多的计算.关于I/O，您可能会坚持阻塞I/O，因为它更易于实现，并且程序无需并行执行.
If you have an application that is CPU intensive like a program that reads a file, does intensive calculations on the complete data and writes the result to file, then 99% of the time will be spent in the CPU intensive part. So create a few threads (for example one per processor) and do as much calculation in parallel. Regarding the I/O you'll probably stick to blocking I/O because it is easier to implement and because the program has nothing to do in parallel.
如果您的应用程序占用大量CPU和I/O，那么您还将使用一些线程和非阻塞I/O.您可能会想到一个具有许多客户端和网页请求的Web服务器，您需要在其中使用cgi脚本进行大量的计算.在等待连接上的I/O时，程序可以计算另一个连接的结果.或考虑一个程序，该程序读取一个大文件，并且可以对文件块进行大量计算(例如，计算平均值或对所有值加1).在这种情况下，您可以使用非阻塞读取，而在等待下一个读取完成时，您已经可以根据可用数据进行计算.如果结果文件只是一个较小的压缩值(如平均值)，则可以对结果使用阻塞写入.如果结果文件与输入文件一样大，并且类似于所有值+1"，那么您可以无阻塞地写回结果，并且在写入完成后，您可以自由地在下一个块上进行计算.
If you have an application that is CPU intensive and I/O intensive then you'ld also use a few threads and nonblocking I/O. You could think of a web server with lots of clients and web page requests where you are doing intensive calculations in a cgi script. While waiting for I/O on on connection the program could calculate the result for another connection. Or think of a program that reads a large file and could do intensive calculations on chunks of the file (like calculating an average value or adding 1 to all values). In that case you could use nonblocking reads and while waiting for the next read to finish you could already calculate on the data that is available. If the result file is only a small condensed value (like an average) you might use blocking write for the result. If the result file is as large as the input file and is like "all values +1", then you could write back the results nonblocking and while the write is being done you are free to do calculations on the next block.
这篇关于为什么cpu绑定对于阻止I/O会更好，而I/O绑定对于非阻止I/O会更好的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
