S*A
发帖数: 7142 | 1 我的机器没有Wei 的好，
但是相对结果还是可以看出来的。
原来的测试程序是严格顺序向后找， 虽然看上去
跳了 40 byte, 但是仍然小于 64 byte 的cache line
size. 但是从访问内存的次序来看是严格增加的。
这个是 cache 最爽的状态。
我改变了输入的次序，变成随机定票段，从输入数组
里面进来，其他的不变。构造输入数组的时间是刨去的。
程序里面 USE_RAND = 1 vs 0
仅仅变的是订票的次序，结果呢？
速度差了整整 4 倍。从 28M 暴减少到7M.当然实际订票
更接近与随机分布。谁排好了一个接一个定。
这就是为什么我会担心 IO 是瓶颈的问题。外部进来的数据，
全部都是 cache miss。这些纯计算的模拟还不能很好的代表真实
的负载情况。
程序如下：
比较快的机器建议增加 ITER 大小，使得总共运行时间超过几十秒。
#include
#include
#include
#define SEGMENTS 10000000
#define INPUTS 100000000
#define ITER 2
unsigned short data[SEGMENTS];
int reserveTicket(unsigned short *line, int start, int len)
{
unsigned short *p = line + start;
int i;
for (i=0; i
if (*p == 0)
return 0;
p++;
}
p = line + start;
for (i=0; i
(*p)--;
p++;
}
return 1;
}
int main(int argc, char *argv[])
{
time_t t1, t2;
int i;
double d;
int *input;
for (i=0; i
data[i] = 65535;
input = malloc(sizeof(*input)*INPUTS);
if (!input) {
printf("malloc failedn");
return 0;
}
#define USE_RAND 1
for (i=0; i
input[i] = (USE_RAND ? rand() : i) %(SEGMENTS - 20);
printf("startn");
t1 = time(0);
for (i=0; i
int j;
for (j=0; j
int res = reserveTicket(data, input[j], 20);
if (!res) {
printf("Failed!n");
}
}
}
t2 = time(0);
d = difftime(t2,t1);
printf("Total seconds %f rate %fn", d, INPUTS/d/1000000*ITER);
return 0;
} |
z*******3
发帖数: 13709 | |
T********i
发帖数: 2416 | 3 你这个基本是worst case了。
L3 cache总共20M，你inputs搞400M。init inputs以后L3基本miss。
有7M不错。也就是说我的机器上10m以上。
【在 S*A 的大作中提到】
: 我的机器没有Wei 的好，
: 但是相对结果还是可以看出来的。
: 原来的测试程序是严格顺序向后找， 虽然看上去
: 跳了 40 byte, 但是仍然小于 64 byte 的cache line
: size. 但是从访问内存的次序来看是严格增加的。
: 这个是 cache 最爽的状态。
: 我改变了输入的次序，变成随机定票段，从输入数组
: 里面进来，其他的不变。构造输入数组的时间是刨去的。
: 程序里面 USE_RAND = 1 vs 0
: 仅仅变的是订票的次序，结果呢？
|
T********i
发帖数: 2416 | 4 Sandybridge直接IO到LLC。solarflare就是。
因此10M左右worst case应该差不过。
反正5M是打折扣的。
【在 T********i 的大作中提到】
: 你这个基本是worst case了。
: L3 cache总共20M，你inputs搞400M。init inputs以后L3基本miss。
: 有7M不错。也就是说我的机器上10m以上。
|
g*****g
发帖数: 34805 | 5 别忘了这个线程还要deque, enque，要write result, 都不是免费的。
【在 S*A 的大作中提到】
: 我的机器没有Wei 的好，
: 但是相对结果还是可以看出来的。
: 原来的测试程序是严格顺序向后找， 虽然看上去
: 跳了 40 byte, 但是仍然小于 64 byte 的cache line
: size. 但是从访问内存的次序来看是严格增加的。
: 这个是 cache 最爽的状态。
: 我改变了输入的次序，变成随机定票段，从输入数组
: 里面进来，其他的不变。构造输入数组的时间是刨去的。
: 程序里面 USE_RAND = 1 vs 0
: 仅仅变的是订票的次序，结果呢？
|
n*****t
发帖数: 22014 | 6 写个指针很大开销吗？
【在 g*****g 的大作中提到】
: 别忘了这个线程还要deque, enque，要write result, 都不是免费的。
|
b*******s
发帖数: 5216 | 7 现代处理器差4倍，以前老处理器能差一个量级
其实cache line size影响还不是最大的
大的是L1 cache size
【在 S*A 的大作中提到】
: 我的机器没有Wei 的好，
: 但是相对结果还是可以看出来的。
: 原来的测试程序是严格顺序向后找， 虽然看上去
: 跳了 40 byte, 但是仍然小于 64 byte 的cache line
: size. 但是从访问内存的次序来看是严格增加的。
: 这个是 cache 最爽的状态。
: 我改变了输入的次序，变成随机定票段，从输入数组
: 里面进来，其他的不变。构造输入数组的时间是刨去的。
: 程序里面 USE_RAND = 1 vs 0
: 仅仅变的是订票的次序，结果呢？
|
g*****g
发帖数: 34805 | 8 你为何不试试。
【在 n*****t 的大作中提到】
: 写个指针很大开销吗？
|
q*c
发帖数: 9453 | 9 所有开销都不大，就是放在一起突然就发现不行了
就和你发现日常生活没件事情花钱都不多啊，我收入多的是，等到月末突然就发现月光
了，一个道理。
这种事情万万不能玩理论计算 ～ 你知道操作系统内部有些啥开销？前面还有人说网卡
驱动调用一次几个锁就加上了。 里面问题太多，只分析 cpu 内部时钟数毫无意义。
【在 n*****t 的大作中提到】
: 写个指针很大开销吗？
|
