567
社区成员
发帖
与我相关
我的任务
分享一段OpenMP程序在Linux与Windows系统下的加速性能不同
一个四路4核的工作站，装有windows与linux两个操作系统，都是64位的。但同一段OpenMP程序，在Windows中使用VS 2010或Intel C++编译器编译，能达到比较良好的加速比，8个线程在7.5左右，16个线程在12左右。反而在linux下，无论是g++还是icpc编译，2个线程1.6左右，4个线程1.2左右，8个线程与16个线程的执行时间要远大于串行执行。
用Vtune性能分析器分析Hotspots与Locks and Waits，发现：
在Windows下主要是Omp barrier的开销增加了wait time影响了性能，这个很正常；
在Linux下Locks and Waits分析得出的wait time只是显示了几毫秒的IO开销，但在Hotspots中，占用时间最长的已经不是程序本身的计算，在centOS系统中运行下占用时间最多的是VDSO开销，随线程数线性增长，8个线程时占用总CPU时间已经达到70%；在RedHat系统下运行则是属于libc-2.5.so的两个函数，分别是_lll_unlock_wake_private与_lll_lock_wait_private,执行时间与VDSO开销类似。
在循环中使用到的shared变量在一次循环的计算过程中均是只读的，只是在最后的循环结束处需要将计算的结果填入到一个数组中，而这个数组是共享的。那么，linux环境下的开销到底可能是来自哪里呢？
用Vtune性能分析器分析Hotspots与Locks and Waits，发现：
在Windows下主要是Omp barrier的开销增加了wait time影响了性能，这个很正常；
在Linux下Locks and Waits分析得出的wait time只是显示了几毫秒的IO开销，但在Hotspots中，占用时间最长的已经不是程序本身的计算，在centOS系统中运行下占用时间最多的是VDSO开销，随线程数线性增长，8个线程时占用总CPU时间已经达到70%；在RedHat系统下运行则是属于libc-2.5.so的两个函数，分别是_lll_unlock_wake_private与_lll_lock_wait_private,执行时间与VDSO开销类似。
在循环中使用到的shared变量在一次循环的计算过程中均是只读的，只是在最后的循环结束处需要将计算的结果填入到一个数组中，而这个数组是共享的。那么，linux环境下的开销到底可能是来自哪里呢？
...全文
请发表友善的回复…
发表回复
zkbit1988 2011-12-07
- 打赏
- 举报
发现问题了，循环中使用了rand()函数来获取随机数，但是这个函数不是多线程安全的，换成rand_r()就好了
