[Linux利用多核多线程进行程序优化.docxVIP

利用多核多线程进行程序优化简介：?大家也许还记得 2005 年 3 月 C++ 大师 Herb Sutter 在 Dr.Dobb’s Journal 上发表了一篇名为《免费的午餐已经结束》的文章。文章指出：现在的程序员对效率、伸缩性、吞吐量等一系列性能指标相当忽视，很多性能问题都仰仗越来越快的 CPU 来解决。但 CPU 的速度在不久的将来，即将偏离摩尔定律的轨迹，并达到一定的极限。所以，越来越多的应用程序将不得不直面性能问题，而解决这些问题的办法就是采用并发编程技术。样例程序程序功能：求从1一直到?APPLE_MAX_VALUE (100000000)?相加累计的和，并赋值给 apple 的?a?和?b?；求 orange 数据结构中的 a[i]+b[i ] 的和，循环?ORANGE_MAX_VALUE?(1000000)?次。说明：由于样例程序是从实际应用中抽象出来的模型，所以本文不会进行 test.a=test.b= test.b+sum 、中间变量(查找表)等类似的优化。以下所有程序片断均为部分代码，完整代码请参看本文最下面的附件。清单 1. 样例程序#define ORANGE_MAX_VALUE 1000000#define APPLE_MAX_VALUE 100000000#define MSECOND 1000000struct apple{ unsigned long long a;unsigned long long b;};struct orange{int a[ORANGE_MAX_VALUE];int b[ORANGE_MAX_VALUE];};int main (int argc, const char * argv[]) { // insert code here... struct apple test;struct orange test1;for(sum=0;sumAPPLE_MAX_VALUE;sum++){test.a += sum;test.b += sum;} sum=0;for(index=0;indexORANGE_MAX_VALUE;index++){sum += test1.a[index]+test1.b[index];} return 0;}回页首K-Best 测量方法在检测程序运行时间这个复杂问题上，将采用 Randal E.Bryant 和 David R. O’Hallaron 提出的 K 次最优测量方法。假设重复的执行一个程序，并纪录 K 次最快的时间，如果发现测量的误差 ε 很小，那么用测量的最快值表示过程的真正执行时间， 称这种方法为“ K 次最优（K-Best）方法”，要求设置三个参数：K: 要求在某个接近最快值范围内的测量值数量。ε 测量值必须多大程度的接近，即测量值按照升序标号 V1, V2, V3, … , Vi, … ，同时必须满足（1+ ε）Vi = VkM: 在结束测试之前，测量值的最大数量。按照升序的方式维护一个 K 个最快时间的数组，对于每一个新的测量值，如果比当前 K 处的值更快，则用必威体育精装版的值替换数组中的元素 K ，然后再进行升序排序，持续不断的进行该过程，并满足误差标准，此时就称测量值已经收敛。如果 M 次后，不能满足误差标准，则称为不能收敛。在接下来的所有试验中，采用 K=10，ε=2%，M=200 来获取程序运行时间，同时也对 K 次最优测量方法进行了改进，不是采用最小值来表示程序执行的时间，而是采用 K 次测量值的平均值来表示程序的真正运行时间。由于采用的误差 ε 比较大，在所有试验程序的时间收集过程中，均能收敛，但也能说明问题。为了可移植性，采用 gettimeofday() 来获取系统时钟（system clock）时间，可以精确到微秒。回页首测试环境硬件：联想 Dual-core 双核机器，主频 2.4G，内存 2G软件：Suse Linunx Enterprise 10，内核版本：linux-2.6.16回页首软件优化的三个层次医生治病首先要望闻问切，然后才确定病因，最后再对症下药，如果胡乱医治一通，不死也残废。说起来大家都懂的道理，但在软件优化过程中，往往都喜欢犯这样的错误。不分青红皂白，一上来这里改改，那里改改，其结果往往不如人意。一般将软件优化可分为三个层次：系统层面，应用层面及微架构层面。首先从宏观进行考虑，进行望闻问切，即系统层面的优化，把所有与程序相关的信息收集上来，确定病因。确定病因后，开始从微观上进行优化，即进行应用层面和微架构方面的优化。系统层面的优化：内存不够，CPU 速度过慢，系统中进程过多等应用层面的优化：算法优化、并行设计等微架构层面的优化：分支预测