gpt4 book ai didi

c - 使用 gettimeofday 的初始计时结果较慢 - 在 RHEL6 服务器下更糟

转载 作者:可可西里 更新时间:2023-11-01 11:47:29 26 4
gpt4 key购买 nike

我正在使用 gettimeofday() 为一个简单的矩阵乘法示例计时,但我得到的结果最初接近两倍的时间。在 RHEL6 Server 机器上,我得到了将近 1 秒的“坏”计时结果(在这个例子中大约有 65 个单独的计时)。我们所有其他机器都是 RHEL5 Workstation 机器,这段代码在它们上运行得好得多;我最初只得到几个“坏”结果(前 ~20 毫秒)。

从该站点上的帖子来看,我认为这可能与操作系统进程调度程序有关。如果我取消注释下面的第一个“for”语句(从而通过重复初始化矩阵 a、b 和 c 来插入一个初始繁忙循环),我在 RHEL5 工作站和 RHEL6 服务器下得到零“坏”结果。或者,如果我取消注释 sleep 语句,我会得到 RHEL5 和 RHEL6 的所有“坏”计时结果。

出于某种原因,我的进程最初只有大约一半的 CPU 访问权限启动,然后只要进程保持忙碌,它就会“完全”访问 CPU。如果它“休眠”然后恢复计时,它再次暂时只能获得大约一半的 CPU 完全访问权限。

机器上没有其他事情发生(X 没有运行)。我试过“chrt”来控制进程的优先级,但没有任何改变。我已经验证 GCC 4.4.6 和 ICC 12.1.0 都会出现这种情况。我也试过“nice”。

代码如下:

#include <stdio.h>
#include <unistd.h>
#include <sys/time.h>
#define N 225
#define DELAY_LOOPS 8000
main() {
struct timeval _t0, _t1, _t2;
double a[N][N], b[N][N], c[N][N];
double millisec, cum_ms;
int i, j, k, l, m=0;
gettimeofday( &_t0, NULL );
// for( l=0; l<DELAY_LOOPS; l++ )
for( i=0; i<N; i++ )
for( j=0; j<N; j++ ) {
a[i][j]=0;
b[i][j]=i;
c[i][j]=j;
}
for( l=0; l<75; l++ ) {
gettimeofday( &_t1, NULL );
for( i=0; i<N; i++ )
for( j=0; j<N; j++ )
for( k=0; k<N; k++ )
a[i][j]+=b[i][k]*c[k][j];
gettimeofday( &_t2, NULL );
millisec = 1000*(_t2.tv_sec-_t1.tv_sec);
millisec += 1e-3*(_t2.tv_usec-_t1.tv_usec);
cum_ms = 1000*(_t2.tv_sec-_t0.tv_sec);
cum_ms += 1e-3*(_t2.tv_usec-_t0.tv_usec);
printf( "%d: duration %fms, cumulative %fms\n",
m++, millisec, cum_ms );
// sleep( 2 );
}
printf( "a[%d][%d]=%f\n", N/2, N/2, a[N/2][N/2] );
}

结果如下:

% icc -O2 -o test main.c; ./test
0: duration 13.049000ms, cumulative 13.677000ms
1: duration 13.026000ms, cumulative 26.753000ms
2: duration 12.911000ms, cumulative 39.668000ms
3: duration 12.913000ms, cumulative 52.584000ms
4: duration 12.914000ms, cumulative 65.501000ms
5: duration 12.911000ms, cumulative 78.415000ms
6: duration 12.912000ms, cumulative 91.331000ms
/* snip */
64: duration 12.912000ms, cumulative 840.633000ms
65: duration 10.455000ms, cumulative 851.092000ms
66: duration 5.910000ms, cumulative 857.004000ms
67: duration 5.908000ms, cumulative 862.914000ms
68: duration 5.907000ms, cumulative 868.823000ms
69: duration 5.908000ms, cumulative 874.732000ms
70: duration 5.912000ms, cumulative 880.646000ms
71: duration 5.907000ms, cumulative 886.554000ms
72: duration 5.907000ms, cumulative 892.462000ms
73: duration 5.908000ms, cumulative 898.372000ms
74: duration 5.908000ms, cumulative 904.281000ms
a[112][112]=211680000.000000

无论优化级别如何(-O0、-O1、-O2 等),我都会遇到此问题。

有谁知道在 RHEL6 Server 下是如何进行调度的?它与 RHEL5 Workstation 有很大不同吗?我认为我看到的差异更多是因为一个盒子是 RHEL 的服务器版本,另一个是工作站版本(而不是版本 5 与版本 6 之间的区别)。有没有一些简单的方法可以减少 RHEL6 服务器下的这种影响并使其更像 RHEL5 工作站盒?

有什么想法吗?谢谢。

最佳答案

不要使用 gettimeofday(2) 进行性能测量。它太慢了,根本不适合这项工作。

改用clock_gettime(2)。它允许您从多个系统定义的计时器中选择一个。 CLOCK_REALTIME 是最简单的选择,但如果有 CLOCK_PROCESS_CPUTIME_ID 可能会更好。

关于c - 使用 gettimeofday 的初始计时结果较慢 - 在 RHEL6 服务器下更糟,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8683724/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com