对于多核程序设计的一点总结

scutan

各位好，今天看到有朋友提了一下多核程序设计方面的东西，恰好前段时间看过相关的内容，所以就花了一个晚上，总结了一下。可能写得不是很好，不过但愿能够起到抛砖引玉的效果。希望各位都谈谈自己对于多核程序设计的一点想法，这样大家都能够有所提高。
谢谢！

We are dedicating all of our future product development to multicore designs. We believe this is a key inflection point for the industry.
                                                Intel President  
                                                        Paul Otellini
                                                Describing Intel’s future direction at the Developers Forum 2005

    多核下的多线程程序设计与传统的单核下的多线程程序设计有着一定的差别，在单CPU下，是多个线程在同一个CPU上并发地执行，而在多核下，则是由多个线程在多个核上并行地执行。
    但是，目前的程序设计中对于多核的利用并没有达到预期的效果。因此，为了能够在多核的环境下设计出更适合多核系统的程序，则是一个挑战。
    要做到这一点，就必须将应用程序看做是众多相互依赖的任务的集合，将应用程序划分成多个独立的任务，并确定这些任务之间的相互依赖关系，这就称为分解(decomposition)。如下如示：

分解方式                                  设计                                            说明
任务分解                    不同的程序行为采用不同的线程实现               常用于GUI应用程序
数据分解                   多个线程对不同的数据块执行相同的操作               常用于音频、图像处理和科学计算应用程序
数据流分解                   一个线程的输出作为另一个线程的输入               应注意尽量避免延迟


    任务分解：对应用程序根据其执行的功能进行分解的过程称为任务分解(task decomposition)。根据这种方法，就能够对众多的独立任务进行分类。如果其中两个任务能够同时运行，那么开发人员就应该对其进行调度，形成二者之间的并行执行。

    数据分解：数据分解也称为数据级并行(data-level parallelism)。是将应用程序根据各任务所处理的数据而非按任务来进行分解的方法，即以数据为中心。一般而言，能够按照数据分解方式进行分解的应用程序都包含多个线程，这些线程分别对不同的数据对象执行相同的操作。

    数据流分解：在很多情况下，当对一个问题进行分解时，关键问题不在于采用一些什么任务来完成这个工作，而在于数据在这些任务之间是如何流动的。这个时候就要采用数据流分解方式，如典型的生产者/消费者问题。

    对于任务分解，有两个需要注意的地方：
    1. 划分的对象是计算，将计算划分为不同的任务
    2. 划分后，研究不同任务所需的数据，如果这些数据不相交，则证明划分是成功的，如果数据有相当程序的相交，意味着要重新进行数据划分和功能划分。
    如在一个气候模型中，需要考虑到地表模型、水文模型与海洋模型等多种情况，那么就应该将这几种模型划分成不同的任务，再分别进行并行地运算。

    对于数据分解，划分的对象是数据，可以是算法的输入数据、中间处理数据和输出数据。在划分时应该考虑到数据上的相应操作。
    最简单的情况下，比如对1000万个数进行相加，可以对其进行数据上的分解，用多个线程来分别计算不同批次的数据。然后再将计算的中间数据加到一起成为最终的结果。

scutan

1. 线程过多
        线程并不是越多越好，对于某个程序，如果线程过多反而会严重地降低程序的性能。这种影响主要在于：
        将给定的工作量划分给过多的线程会造成每个线程的工作量过少，因此可能导致线程启动和终止的开销比程序实际工作的时间还要多。
        同时，太多并发线程的存在将导致共享有限硬件资源的开销增大。如保存和恢复寄存器状态的开销、保存和恢复线程cache状态的开销、废除虚存的开销、线程聚集在一起等待获取某个锁。
        怎样解决这个问题：
        限制可运行线程的个数
        将计算线程与I/O线程分离开
        使用已有的技术，如OpenMP，线程池等

2. 数据竞争、死锁
        死锁，想必大家都很熟悉。这里谈谈一些简单的避免死锁的规则：
        加锁的顺序是关键，使用嵌套的锁时必须保证以相同的顺序获取锁
        防止发生饥饿：即这个代码的执行是否一定会结束。
        不要重复请求同一个锁
        越复杂的加锁方案越有可能造成死锁—设计应力求简单

3. 竞争激烈的锁
        即使是正确使用锁来避免数据竞争，但如果各线程对锁的竞争很激烈，那么也会引发性能问题。即很多个线程来竞争同一个锁。在这个情况下，可以考虑将资源划分成若干个部分，然后用彼此独立的锁分别保护各个部分。即合理地安排加锁粒度的问题。在早期的Linux内核中就使用了大内核锁，现在已经把锁给细划到不同的子系统中去了。
        如果一个数据结构被频繁读取但不被频繁写入，就可以使用读写锁来解决竞争。

4. 线程安全函数
        已有的一些函数并不是线程安全的，具体的线程安全函数可以参考APUE2上面的线程一章。

5. 存储效率问题       
        目前，处理器的速度已经比存储器快很多，一个处理器从内存中读或写一个值的时间内可以完成上百次的操作。因此，现在的程序往往受限于存储器的瓶颈。
        首先，可以通过节省带宽，可以减少与存储器的数据交换数量，要节省带宽就要将数据压缩得更加紧凑。
        其次是cache的利用。可以减少数据在不同CPU的cache间的移动。CPU亲合力(CPU Affinity)就是指在Linux系统中能够将一个或多个进程绑定到一个或多个处理器上运行。一个进程的CPU亲合力掩码决定了该进程将在哪个或哪几个CPU上运行，在一个多处理器系统中，设置CPU亲合力的掩码可能会获得更好的性能。
        在下面的例子中讲解了如何利用将某个进程绑定以某个CPU上运行的实例。
http://linux.chinaunix.net/bbs/v ... p%3Bfilter%3Ddigest

scutan

由于CPU运算速度的增长远远大于内存速度的增长，同时由于程序运行的局部性原理，所以现代计算机体系结构中引入了cache。
        其实系统的存储器本身就是一个层次结构，从寄存器->高速缓存->主存->本地磁盘->颁布式文件系统。
        在下面的贴子中的一个文档对cache方面讲解得非常不错，可以看看：
http://bbs.chinaunix.net/viewthr ... mp;highlight=scutan

        高速缓存的性能主要有以下几个方面：

1. 高速缓存的大小：
        当CPU接收到指令后，它会最先向CPU中的一级缓存去寻找相关的数据，如果未命中，则继续向下一级的二级缓存中寻找。所以高速缓存越大，命中的机率也就越高。

2. 块大小的影响
        大的块有利有弊，一方面，较大的块能利用程序中可能存在的空间局部性，帮助提高命中率。不过，对于给定的高速缓存的大小，块越大就意味着缓存行数越小，这会损害时间局部性比空间局部性更好的程序中的命中率。同时，因为块越大，传达时间也就越长。

3. 相联度的影响
        较高的相联度的优点的降低了高速缓存由于冲突不命中出现抖动的可能性。不过，较高的相联度会造成较高的成本。

4. 前端总线的影响
        现在的CPU技术发展很快，运算速度提高很大，而足够大的前端总线可以保障有足够的数据供给CPU，较低的前端总线将无法供给足够的数据给CPU，限制了CPU性能的发挥。

        最后谈谈程序性能优化的相关内容。
        对于程序性能的优化，首先应该考虑的架构以及算法这两方面的优化，最后再来考虑下面所讲述的这些优化。
        消除连续的函数调用
        消除不必要的存储器引用
        通过展开循环降低循环开销
        提高并行性
        重新排列循环以提高空间局部性
        让最常运行部分运行得更快


参考资料：
[1]. John L. Hennessy, David A. Patterson. 计算机体系结构：量化研究方法. 第4版
[2]. Shameem Akhter, Jason Roberts. 多核程序设计技术—通过软件多线程提升性能
[3]. Randal E. Bryant, David O’Hallaron. 深入理解计算机系统
[4]. Daniel P.Bovet, Marco Cesati. 深入理解Linux内核 第3版

tassard

为了发挥双核的性能使得程序结构大大复杂，但性能却没有提高多少，这也是为什么双核没怎么影响传统的程序设计方法的原因。

我觉得如果cpu能集成几百个核那才会引起软件开发的革命。

void_while

楼主工作需要用到多核开发吗?
intel 06年就开始推这套东西,我怎么感觉国内好象没啥用人到呢

flw2

写的很好，支持一个

scutan

没有用到, 主要是兴趣.

[ 本帖最后由 scutan 于 2008-7-9 22:22 编辑 ]

zx_wing

原帖由 tassard 于 2008-7-9 22:01 发表
为了发挥双核的性能使得程序结构大大复杂，但性能却没有提高多少，这也是为什么双核没怎么影响传统的程序设计方法的原因。

我觉得如果cpu能集成几百个核那才会引起软件开发的革命。

对于应用程序员来说，这些都不是他考虑的东西，不会增加多少复杂性。
对于内核程序员，或线程库的程序员来说，这些又是他必然要考虑的，实际上内容也不多。
我认为，技术角度要考虑的东西就两点：局部性和锁。对于前者，调度器懒点，CPU亲和力强点，不要频繁做负载平衡。对于后者，目前锁粒度已经越来越小（例如连页表锁的粒度都已经细化到页表页粒度，只要不死锁，竞争激烈的问题已经大大减小。
最重要的问题，还是应该从设计上找，算法当然是最重要的，其次是尽量减小内存拷贝、I/O的开销（这些才是最大的）。
至于其它细节上的优化，真的不见得能带来多大的性能提高。现在CPU速度太快了，你把一个函数的执行时间从2000多个cycle优化到50个cycle，感觉很牛B了，然后函数执行1000万次，根据CPU频率一换算，发现时间提高不到0.1%，那是多郁闷的事情。所以真正需要的优化，不是让几条指令执行时间减少多少，而是想方设法的减小访存时间

tyc611

参考文献2看过，这本书可以作为科普吧

[ 本帖最后由 tyc611 于 2008-7-9 22:29 编辑 ]

scutan

原帖由 zx_wing 于 2008-7-9 22:27 发表

对于应用程序员来说，这些都不是他考虑的东西，不会增加多少复杂性。
对于内核程序员，或线程库的程序员来说，这些又是他必然要考虑的，实际上内容也不多。
我认为，技术角度要考虑的东西就两点：局部性和锁 ...

嗯, 是的. 算法的设计是最重要的. 还有就是CPU和内存之间的数据交换, 也会是瓶颈.