CPU-bound(计算密集型) 和I/O bound(I/O密集型)/数据密集型

https://blog.csdn.net/q_l_s/article/details/51538039

I/O密集型 (CPU-bound)
I/O bound 指的是系统的CPU效能相对硬盘/内存的效能要好很多，此时，系统运作，大部分的状况是 CPU 在等 I/O (硬盘/内存) 的读/写，此时 CPU Loading 不高。
CPU bound 指的是系统的硬盘/内存效能相对 CPU 的效能要好很多，此时，系统运作，大部分的状况是 CPU Loading 100%，CPU 要读/写 I/O (硬盘/内存)，I/O在很短的时间就可以完成，而 CPU 还有许多运算要处理，CPU Loading 很高。

计算密集型 (CPU-bound)
在多重程序系统中，大部份时间用来做计算、逻辑判断等CPU动作的程序称之CPU bound。例如一个计算圆周率至小数点一千位以下的程序，在执行的过程当中

绝大部份时间用在三角函数和开根号的计算，便是属于CPU bound的程序。
It is because the performance characteristic of most protocol codec implementations is CPU-bound, which is the same with I/O processor threads.

根据以上分析，可以认为通常情况下，大部分程序针对某个特定的性能metric而言
都可分为CPU bound 和 I/O bound两类。
CPU bound的程序一般而言CPU占用率相当高。这可能是因为任务本身不太需要访问I/O设备，也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间。
而I/O bound的程序一般在达到性能极限时，CPU占用率仍然较低。这可能是因为任务本身需要大量I/O操作，而pipeline做得不是很好，没有充分利用处理器能力

转自http://blog.chinaunix.net/space.php?uid=13714918&do=blog&id=2875404

进程 vs. 线程

我们介绍了多进程和多线程，这是实现多任务最常用的两种方式。现在，我们来讨论一下这两种方式的优缺点。

首先，要实现多任务，通常我们会设计Master-Worker模式，Master负责分配任务，Worker负责执行任务，因此，多任务环境下，通常是一个Master，多个Worker。

如果用多进程实现Master-Worker，主进程就是Master，其他进程就是Worker。

如果用多线程实现Master-Worker，主线程就是Master，其他线程就是Worker。

多进程模式最大的优点就是稳定性高，因为一个子进程崩溃了，不会影响主进程和其他子进程。（当然主进程挂了所有进程就全挂了，但是Master进程只负责分配任务，挂掉的概率低）著名的Apache最早就是采用多进程模式。

多进程模式的缺点是创建进程的代价大，在Unix/Linux系统下，用fork调用还行，在Windows下创建进程开销巨大。另外，操作系统能同时运行的进程数也是有限的，在内存和CPU的限制下，如果有几千个进程同时运行，操作系统连调度都会成问题。

多线程模式通常比多进程快一点，但是也快不到哪去，而且，多线程模式致命的缺点就是任何一个线程挂掉都可能直接造成整个进程崩溃，因为所有线程共享进程的内存。在Windows上，如果一个线程执行的代码出了问题，你经常可以看到这样的提示：“该程序执行了非法操作，即将关闭”，其实往往是某个线程出了问题，但是操作系统会强制结束整个进程。

在Windows下，多线程的效率比多进程要高，所以微软的IIS服务器默认采用多线程模式。由于多线程存在稳定性的问题，IIS的稳定性就不如Apache。为了缓解这个问题，IIS和Apache现在又有多进程+多线程的混合模式，真是把问题越搞越复杂。

计算密集型 vs. IO密集型

是否采用多任务的第二个考虑是任务的类型。我们可以把任务分为计算密集型和IO密集型。

计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。

计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。Python这样的脚本语言运行效率很低，完全不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。

第二种任务的类型是IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。

IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少，因此，用运行速度极快的C语言替换用Python这样运行速度极低的脚本语言，完全无法提升运行效率。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言，脚本语言是首选，C语言最差。

总之，计算密集型程序适合C语言多线程，I/O密集型适合脚本语言开发的多线程。

数据密集（Data-Intensive）

在2011年，"大数据"的概念已经赚足了人气，调研机构IDC数字宇宙在2011年6月的报告显示，全球数据量在2011年已达到1.8ZB,在过去5年里增加了5倍，而到2015年将达到近8ZB.进入2012年，大数据丝毫不会放慢增长的步伐，全球制造业、政府、零售商、金融等众多机构已经陷入"数据爆炸"的困境。随着数据量的急剧增长，以及对数据在线处理能力的要求不断提高，海量数据的处理问题越来越受到关注。在金融、电信等领域，都需要通过对大量的用户数据进行分析，才能做出相应的决策。对互联网数据进行存储和处理的海量数据处理系统也开始向数据密集型计算系统发展。

数据密集型应用与计算密集型应用是存在区别的，传统的计算密集型应用往往通过并行计算方式在紧耦合的超级计算机上运行少量计算作业，即一个计算作业同时占用大量计算机节点；而数据密集型应用的特点主要是：

大量独立的数据分析处理作业可以分布在松耦合的计算机集群系统的不同节点上运行；
高度密集的海量数据I/O吞吐需求；
大部分数据密集型应用都有个数据流驱动的流程。

数据密集型计算指能推动前沿技术发展的对海量和高速变化的数据的获取、管理、分析和理解。这包含了三层含义：

● 它所处理的对象是数据，是围绕着数据而展开的计算。它需要处理的数据量非常巨大，且快速变化，它们往往是分布的、异构的。因此，传统的数据库管理系统不能满足其需要。

● "计算"包括了从数据获取到管理再到分析、理解的整个过程。因此它既不同于数据检索和数据库查询，也不同于传统的科学计算和高性能计算。它是高性能计算与数据分析和挖掘的结合。

● 它的目的是推动技术前沿发展，要想推动的工作是那些依赖传统的单一数据源、准静态数据库所无法实现的应用。

数据型密集计算的典型应用可概括为以下三类：

1）Web应用：无论是传统的搜索引擎还是新兴的Web 2.0应用，它们都是以海量数据为基础，以数据处理为核心的互联网服务系统。为支持这些应用，系统需要存储、索引、备份海量异构的Web页面、用户访问日志以及用户信息(Profile)，并且还要保证对这些数据快速准确的访问。显然，这需要数据密集型计算系统的支持，因而WEB应用成为数据密集型计算发源地。

2）软件即服务（Software as a Service, SaaS）应用：SaaS通过提供公开的软件服务接口，使得用户能够在公共的平台上得到定制的软件功能，从而为用户节省了软硬件平台的购买和维护费用，也为应用和服务整合提供了可能。由于用户的各类应用所涉及的数据具有海量、异构、动态等特性，有效地管理和整合这些数据，并在保证数据安全和隐私的前提下提供数据融合和互操作功能需要数据密集型计算系统的支持。

3）大型企业的商务智能应用：大型企业往往在地理上是跨区域分布的，互联网提供了统一管理和全局决策的平台。实现企业商务智能需要整合生产、销售、供应、服务、人事、财务等一系列子系统。数据是整合的对象之一，更是实现商务智能的基础。由于这些系统中的数据包括产品设计、生产过程以及计划、客户、订单、售前后服务等数据，除类型多样，数量巨大外，结构也是复杂、异构的。数据密集型计算系统是实现跨区域企业商务智能的支撑技术。