解决方法
虽然这里的其他答案一般都很有用,但问题的具体答案是你不应该使用clock()来比较时间. clock()测量跨线程累加的cpu时间.在核心之间拆分作业时,它至少使用尽可能多的cpu时间(通常由于线程开销而更多).在this页面上搜索clock(),找到“如果进程是多线程的,则添加所有单个进程线程占用的cpu时间”.
只是作业在线程之间分配,所以你需要等待的总时间就少了.你应该使用壁挂时间(挂钟上的时间). OpenMP提供了一个例程omp_get_wtime()来完成它.以下面的例程为例：
#include <omp.h> #include <time.h> #include <math.h> #include <stdio.h> int main(int argc,char *argv[]) { int i,nthreads; clock_t clock_timer; double wall_timer; for (nthreads = 1; nthreads <=8; nthreads++) { clock_timer = clock(); wall_timer = omp_get_wtime(); #pragma omp parallel for private(i) num_threads(nthreads) for (i = 0; i < 100000000; i++) cos(i); printf("%d threads: time on clock() = %.3f,on wall = %.3f\n",\ nthreads,\ (double) (clock() - clock_timer) / CLOCKS_PER_SEC,\ omp_get_wtime() - wall_timer); } }
结果是：
1 threads: time on clock() = 0.258,on wall = 0.258 2 threads: time on clock() = 0.256,on wall = 0.129 3 threads: time on clock() = 0.255,on wall = 0.086 4 threads: time on clock() = 0.257,on wall = 0.065 5 threads: time on clock() = 0.255,on wall = 0.051 6 threads: time on clock() = 0.257,on wall = 0.044 7 threads: time on clock() = 0.255,on wall = 0.037 8 threads: time on clock() = 0.256,on wall = 0.033
你可以看到clock()时间没有太大变化.我没有编译指示得到0.254,所以使用openMP和一个线程比没有使用openMP要慢一点,但是每个线程的挂壁时间都会减少.
由于例如计算的部分不平行(见Amdahl’s_law)或不同的线程在同一内存上作战,因此改进并不总是这么好.
编辑：对于Grand Central Dispatch,GCD reference指出,GCD使用gettimeofday作为挂号时间.所以,我创建了一个新的Cocoa App,并且在applicationDidFinishLaunching中我放了：
struct timeval t1,t2;
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0);
for (int iterations = 1; iterations <= 8; iterations++) {
int stride = 1e8/iterations;
gettimeofday(&t1,0);
dispatch_apply(iterations,queue,^(size_t i) {
for (int j = 0; j < stride; j++) cos(j);
});
gettimeofday(&t2,0);
NSLog(@"%d iterations: on wall = %.3f\n",iterations,\
t2.tv_sec+t2.tv_usec/1e6-(t1.tv_sec+t1.tv_usec/1e6));
}
我在控制台上得到以下结果：
2010-03-10 17:33:43.022 GCDClock[39741:a0f] 1 iterations: on wall = 0.254 2010-03-10 17:33:43.151 GCDClock[39741:a0f] 2 iterations: on wall = 0.127 2010-03-10 17:33:43.236 GCDClock[39741:a0f] 3 iterations: on wall = 0.085 2010-03-10 17:33:43.301 GCDClock[39741:a0f] 4 iterations: on wall = 0.064 2010-03-10 17:33:43.352 GCDClock[39741:a0f] 5 iterations: on wall = 0.051 2010-03-10 17:33:43.395 GCDClock[39741:a0f] 6 iterations: on wall = 0.043 2010-03-10 17:33:43.433 GCDClock[39741:a0f] 7 iterations: on wall = 0.038 2010-03-10 17:33:43.468 GCDClock[39741:a0f] 8 iterations: on wall = 0.034
这与我上面的情况大致相同.
这是一个非常人为的例子.实际上,您需要确保将优化保持在-O0,否则编译器将意识到我们不进行任何计算而根本不进行循环.另外,我在两个例子中使用cos的整数是不同的,但这并不会对结果产生太大影响.有关如何正确执行此操作的信息,请参阅联机帮助页上的STRIDE以及为什么迭代在这种情况下与num_threads大致相当.
编辑：我注意到雅各布的回答包括
I use the omp_get_thread_num()
function within my parallelized loop
to print out which core it’s working
on… This way you can be sure that
it’s running on both cores.
这是不正确的(它已被编辑部分修复).使用omp_get_thread_num()确实是一种确保代码是多线程的好方法,但它没有显示“它正在处理哪个核心”,只是哪个线程.例如,以下代码：
#include <omp.h> #include <stdio.h> int main() { int i; #pragma omp parallel for private(i) num_threads(50) for (i = 0; i < 50; i++) printf("%d\n",omp_get_thread_num()); }
打印出它使用线程0到49,但这并没有显示它正在处理哪个核心,因为我只有8个核心.通过查看活动监视器(OP提到GCD,因此必须在Mac上 – 进入窗口/ cpu使用率),您可以看到在核心之间切换的作业,因此核心！=线程.
