几个影响 cpu cache 性能因素及 cache 测试工具介绍

1 cache 性能及影响因素

1.1 内存访问和性能比较

有如下测试代码:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

int main(int argc, char *argv[])
{
    long length = 64 * 1024 * 1024;
    int *arr = malloc(64 * 1024 * 1024 * sizeof(int));
    long i=0, j=0;
    struct timeval tv1, tv2;
    struct timezone tz;
    unsigned long sec, usec;

    for (i = 0; i < length; i++) arr[i] = i;

    // 循环1
    gettimeofday (&tv1, &tz);
    for(j = 0; j < 10; j++) {
        //每取一次arr[i], 通过 cache_line 顺便把后面 15 个 arr[i] 都取过来了
        for (i = 0; i < length; i++) arr[i] *= 3;
    }
    gettimeofday (&tv2, &tz);

    if (tv2.tv_usec < tv1.tv_usec) {
        usec = 1000000 + tv2.tv_usec - tv1.tv_usec;
        sec = tv2.tv_sec - tv1.tv_sec - 1;
    } else {
        usec = tv2.tv_usec - tv1.tv_usec;
        sec = tv2.tv_sec - tv1.tv_sec;
    }
    printf("time %ld.%06ld s\n", sec, usec);

    // 循环2
    gettimeofday (&tv1, &tz);
    for(j = 0; j < 10; j++) {
        for (i = 0; i < length; i += 16) arr[i] *= 3;
    }
    gettimeofday (&tv2, &tz);

    if (tv2.tv_usec < tv1.tv_usec) {
        usec = 1000000 + tv2.tv_usec - tv1.tv_usec;
        sec = tv2.tv_sec - tv1.tv_sec - 1;
    } else {
        usec = tv2.tv_usec - tv1.tv_usec;
        sec = tv2.tv_sec - tv1.tv_sec;
    }
    printf("time %ld.%06ld s\n", sec, usec);

    return 0;
}

该测试代码预先分配大量内存,并与一个数组指针管理,使其可以通过数组索引访问该片申请内存,接着对该内存域进行预读写,使其在测试中不受 pagefault 影响测试结果。
该测试主要的测试点:

  1. 第一个循环按照字节顺序读写相同固定数量的数据。
  2. 第二个循环跨 cacheline 读取比第一次少 16 倍的数据量。

理论不考虑 cache 则读写时间应该是 第二次 * 16 = 第一次,实际测试结果如下:

(1)HUAWEI Kunpeng 920

# ./a.out
time 2.522369 s
time 0.339671 s

# perf stat -- ./a.out
time 2.623479 s
time 0.307353 s

 Performance counter stats for './a.out':

          3,154.14 msec task-clock                #    0.992 CPUs utilized
                 7      context-switches          #    0.002 K/sec
                 1      cpu-migrations            #    0.000 K/sec
             6,024      page-faults               #    0.002 M/sec
     8,200,710,113      cycles                    #    2.600 GHz
    15,203,228,361      instructions              #    1.85  insn per cycle
   <not supported>      branches
            76,472      branch-misses

       3.180782182 seconds time elapsed

       3.084959000 seconds user
       0.069436000 seconds sys

(2)Phytium S2500(飞腾 S2500)

# ./a.out
time 5.085658 s
time 1.352258 s

# perf stat -- ./a.out
time 5.535788 s
time 0.826428 s

 Performance counter stats for './a.out':

          6,930.59 msec task-clock                #    0.999 CPUs utilized
                50      context-switches          #    0.007 K/sec
                25      cpu-migrations            #    0.004 K/sec
            14,731      page-faults               #    0.002 M/sec
    14,552,534,159      cycles                    #    2.100 GHz
    15,281,585,654      instructions              #    1.05  insn per cycle
   <not supported>      branches
           254,832      branch-misses

       6.934533427 seconds time elapsed

       6.481427000 seconds user
       0.450099000 seconds sys

可以看到两台机器第一次循环花费时间都远小于第二次的 16 这个倍数。

原因是第一次循环读写会从内存按照 cacheline 大小加载连续内存到 cache 中,如果后续读写数据在 cache 中则可以高效读写数据,而不会从内存中读取。

而第二次循环跨 cacheline 读写数据,每次均有可能从内存读写数据。

从上述测试中可以看到,cache 读 cpu 读写性能影响非常大。并且从测试也可以看到鲲鹏机器的 cache 读写速率高于飞腾机器。

1.2 cache line 对性能的影响

1.1 中的测试能够看到 cache 对性能的影响,而 cache 的 cacheline 的大小对性能提升也有着直接作用。
cache line 对 cache 性能影响尤为重要, 程序对 cacheline 的优化会大幅提升运行性能, 这里对 1.1 中的例子进行测试, 将步长 16 从 1 依次成倍增长测试不同步长,测试相同次数获取时延:

脚本如下:

# ./example2.sh
#set -x

work=./a.out
stride=1
for i in `seq 1 15`; do
    perf stat -e cache-misses -e cache-references -e cpu-cycles -e instructions -e L1-dcache-load-misses -e L1-dcache-loads -e L1-dcache-store-misses -e L1-dcache-stores  -- $work $stride
    stride=$(($stride*2))
done

(1)HUAWEI Kunpeng 920

# ./example2.sh
stride = 1, time 2.817894 s
stride = 2, time 2.920336 s
stride = 4, time 3.495400 s
stride = 8, time 4.565321 s
stride = 16, time 6.297579 s
stride = 32, time 7.362044 s
stride = 64, time 7.982766 s
stride = 128, time 10.473204 s
stride = 256, time 9.676618 s
stride = 512, time 12.120638 s
stride = 1024, time 13.391726 s
stride = 2048, time 17.123795 s
stride = 4096, time 23.674495 s
stride = 8192, time 24.273880 s
stride = 16384, time 28.081542 s

可以看到读写时间随读写的步进大小逐渐递增至最后趋近平稳。而在 16,1024 步进时有大幅变化。
上述现象说明 cacheline 大小对性能影响的变化。

当步进在 Dcache-L1 时,比如 64 字节,此时在 Dcache-L1 中读写数据整体性能会非常好。
当步进从 L2 跨度到从 Dcache-L2 读写数据时,此时读写性能将会有一个明显降低,同理 L3 时会继续有个明显变化幅度,直至最后趋于稳定时,只能每次都从内存读写数据。

1.3 L1 和 L2 缓存大小

1.2 测试中,当在 cacheline 范围内读写数据时性能最好,那么 cacheline 越大性能则会越好。

1.4 指令集并行性对 cache 性能的影响

有如下代码:

int steps = 256 * 1024 * 1024;
int a[2];

// Loop 1
for (int i=0; i<steps; i++) { a[0]++; a[0]++; }

// Loop 2
for (int i=0; i<steps; i++) { a[0]++; a[1]++; }

循环上 loop2 比 loop1 更快两个代码有如下依赖:

  1. loop1 依赖关系
    x = a[0] -> x++ -> a[0] = x -> y = a[0] -> y++ -> a[0] = y
  2. loop2 依赖关系
    x = a[0] -> x++ -> a[0] = x
    y = a[1] -> y++ -> a[1] = y

即机器具有有并行性,它可以同时访问 L1 中的两个内存位置,loop1 中处理器无法利用这种指令级并行性,但是 loop2 可以,代码如下:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define barrier() __asm__ __volatile__("": : :"memory")

static long timediff(clock_t t1, clock_t t2)
{
    long elapsed;
    elapsed = ((double)t2 - t1) / CLOCKS_PER_SEC * 1000;
    return elapsed;
}

int main(int argc, char *argv[])
{
    long i=0, j=0;
    clock_t start, end;
    int a[2] = {0};

    unsigned long steps = 2000 * 1024 * 1024;

    // loop1
    start=clock();
    for (i = 0; i < steps; i++) {
        a[0]++;
        barrier();
        a[0]++;
        barrier();
    }
    end =clock();
    printf("%lu\n", timediff(start,end));

    // loop2
    start=clock();
    for (i = 0; i < steps; i++) {
        a[0]++;
        barrier();
        a[1]++;
        barrier();
    }
    end =clock();
    printf("%lu\n", timediff(start,end));

    return 0;
}

测试如下:
(1)HUAWEI Kunpeng 920

loop1 time 11.611784 s
loop2 time 6.526364 s

(2)Phytium S2500

loop1 time 15.546450 s
loop2 time 7.637472 s

(3)Intel® Xeon® Gold 5218

loop1 time 8.084105 s
loop2 time 6.649898 s

可以看到指令集并行性在能够并行时性能都会有明显提升,另外三台机器中并行性最好的是华为鲲鹏,然而最好的并行性和因特尔 5218 持平,非并行性下 intel 具有最好的读写性能。

1.5 缓存关联性对 cache 的影响

目前有三种映射缓存方式:

  1. 直接映射缓存

    每个内存块只能存储在缓存中的一个特定插槽中。一种简单的解决方案是将索引为 chunk_index 的块映射到缓存槽 (chunk_index % cache_slots)。映射到同一插槽的两个内存块不能同时存储在缓存中。

  2. N路组相联高速缓存

    每个内存块都可以存储在缓存中 N 个特定插槽中的任何一个中。例如,在 16 路缓存中,每个内存块可以存储在 16 个不同的缓存槽中。通常,具有相同最低位的索引的块将共享 16 个槽。

  3. 全关联缓存

    每个内存块都可以存储在缓存中的任何槽中。实际上,缓存的运行方式类似于哈希表。

直接映射缓存可能会发生冲突,当多个值竞争缓存中的同一个插槽时,它们会不断相互驱逐,命中率直线下降。

全关联高速缓存在硬件中实现起来既复杂又昂贵。

N 路组关联高速缓存是处理器高速缓存的典型解决方案,因为它们在实现简单性和良好的命中率之间取得了很好的平衡。

当前所有测试机器都是 N路组相联,需要计算每个 way,sets 使用 bit 再去推算每一组可能丢失命中的字节步长,这里没有计算,略过。

1.6 错误的 cacheline 共享 (缓存一致性)

在多核机器上,缓存会遇到另一个问题,缓存一致性,也就是说多线程,多核之间并行对 cache 访问一致性问题对性能同样会造成严重影响。
在测试机器中,有 L1 L2 独占的,也有超线程下共享 L1的。
这里有如下测试:

for ( int j = 0; j < 100000000; j++)  { 
    s_counter[position] = s_counter[position] + 3; 
} 

使用四个不同的线程参数 0,1,2,3调用上述代码和使用16,32,48,64调用上述代码,16,32,48,64耗时比第一组小很多,这就是缓存一致性引起,代码如下:

// example6.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <pthread.h>
#include <unistd.h>
#include <stdio.h>

static int s_counter[1024] __attribute__ ((aligned (64)));

int aaa = 1;

static void update_counter(int posion)
{
    for (int i = 0; i < 100000000; i++) {
        s_counter[posion] = s_counter[posion] + 3;
    }
}

static void *thread_func1(void *param)
{
    if (aaa)
	    update_counter(0);
    else
        update_counter(16);
	return NULL;
}

static void *thread_func2(void *param)
{
    if (aaa)
	    update_counter(1);
    else
        update_counter(32);
	return NULL;
}

static void *thread_func3(void *param)
{
    if (aaa)
	    update_counter(2);
    else
        update_counter(48);
	return NULL;
}

static void *thread_func4(void *param)
{
    if (aaa)
	    update_counter(3);
    else
        update_counter(64);
	return NULL;
}

int main(int argc, char *argv[])
{
	pthread_t tid1, tid2, tid3, tid4;

    if (argc != 1)
        aaa = 0;
    pthread_create(&tid1, NULL, thread_func1, NULL);
	pthread_create(&tid2, NULL, thread_func2, NULL);
    pthread_create(&tid3, NULL, thread_func3, NULL);
    pthread_create(&tid4, NULL, thread_func4, NULL);
	pthread_join(tid1, NULL);
	pthread_join(tid2, NULL);
	pthread_join(tid3, NULL);
    pthread_join(tid4, NULL);

    return 0;
}

测试如下:
(1)HUAWEI Kunpeng 920

# gcc -O0 -g example6.c -lpthread
[root@node-3 test_cache]# time ./a.out	// 0,1,2,3

real    0m1.889s
user    0m6.994s
sys     0m0.000s
[root@node-3 test_cache]# time ./a.out  1	// 16,32,48,64

real    0m0.451s
user    0m1.439s
sys     0m0.000s

[root@node-3 test_cache]# time taskset -c 0 ./a.out

real    0m1.251s
user    0m1.240s
sys     0m0.000s
[root@node-3 test_cache]# time taskset -c 0 ./a.out  1

real    0m1.250s
user    0m1.239s
sys     0m0.000s

(1)Phytium S2500

# gcc -O0 -g example6.c -lpthread
[root@node-1 test_cache]# time ./a.out

real    0m0.467s
user    0m1.829s
sys     0m0.011s
[root@node-1 test_cache]# time ./a.out 1

real    0m0.432s
user    0m1.720s
sys     0m0.001s

[root@node-1 test_cache]# time taskset -c 0 ./a.out

real    0m1.724s
user    0m1.722s
sys     0m0.001s
[root@node-1 test_cache]# time taskset -c 0 ./a.out 1

real    0m1.727s
user    0m1.714s
sys     0m0.011s
1.7 硬件设计

在某些处理器上,如果 L1 缓存访问来自不同 bank 的缓存行,则它们可以并行处理两个访问,如果它们属于同一 bank,则可以串行处理,这是“硬件怪异”的一个奇怪例子:

static int A, B, C, D, E, F, G;
static void Weirdness()
{
    for (int i = 0; i < 200000000; i++)
    {
        <something>
    }
}

<something>     	 Time
A++; B++; C++; D++;	 719 ms
A++; C++; E++; G++;	 448 ms
A++; C++;	         518 ms

递增字段 A、B、C、D 比递增字段 A、C、E、G 花费的时间更长。

仅递增 A 和 C 比递增 A 和 C 以及 E 和 G花费的时间更长

2 cpu cache benchmark 工具

2.1 使用 llcbench 工具对 cache 进行性能测试

LLCbench (底层表征基准测试 Low-Level Characterization Benchmarks) 是一个基准测试工具, 集成了 MPBench, CacheBench 和 BLASBench 测试方法。这里只使用其中的 CacheBench 测试缓存性能。(llcbench 工具目前可能需要一些科学上网才能获取)
测试步骤:

# tar -xvf llcbench-20170104.tar.gz
# cd llcbench;make;make linux-lam;make cache-bench;make cache-run
# make cache-scripts
# make cache-graph

测试大致原理: 对不同字节长度数组进行同样步长的循环读写测试统计时间(同 11.1 测试类似,不过 llcbench 工具更加标准和准确),生成的测试数据如下:
(1)HUAWEI Kunpeng 920

  1. 全局测试
    在这里插入图片描述
  2. numa 绑定最近节点: numactl -C 24 -m 1 make cache-run distances 10
    在这里插入图片描述
  3. numa 绑定最远节点: numactl -C 24 -m 3 make cache-run distances 24
    在这里插入图片描述
    通过跳变位置可以看到每个 cache 级别的大小,以及内存读写速率位置。同样的 numa 对性能影响也是明显的(体现在图标最后一个坡段)。
2.2 使用 pts 工具对内存缓存带宽进行测试

pts (phoronix-test-suite) 的 cachebench 测试底层同样使用 llcbench 进行测试, 这里使用 pts 测试各平台内存缓存带宽。

测试步骤如下:

# ./install-sh	# 安装 pts
# phoronix-test-suite install pts/cachebench  # 下载 cachebench 测试用例
# phoronix-test-suite run pts/cachebench   # 运行 cachebench 测试

(1)HUAWEI Kunpeng 920

  1. 读测试:
    在这里插入图片描述
  2. 写测试
    在这里插入图片描述
  3. 读-修改-写测试:
    在这里插入图片描述
  4. 测试报告: https://openbenchmarking.org/result/2302010-NE-KUNPENG3610
2.3 lmbench 对 L1, L2, L3 cache 时延及带宽测试

lmbench 是一个微型评测工具, 它衡量两个关键特征: 反应时间和带宽。

使用工具集中的 stream 测试带宽,对应的时延是在带宽跑满下的时延。

使用工具集中的 lat_mem_rd 测试时延,主要对应不同数据大小下的时延。

2.3.1 工具常规测试步骤
# 编译问题
# make results LDFLAGS=-ltirpc
# yum -y install libtirpc libtirpc-devel
# cp /usr/include/tirpc/rpc/* /usr/include/rpc/ -rf
# ln -s /usr/include/tirpc/netconfig.h /usr/include


# 测试
# cd src
# make results
# make rerun; make rerun; make rerun; cd results; make LIST=<OS>; make ps;

一个示例对应结果如下:
Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
easystack Linux 5.15.79  4083 1.2130 2.5860 8.6590       161.1

显示结果分别为(单位纳秒):
L1: L1 cache 时延
L2: L2 cache 时延
Main mem: 顺序读内存时延
Rand mem: 随机访问内存时延
Guesses: 当 L2 不存在时, 可能会打印 No L2 cache?

对应分布图如下:
在这里插入图片描述
lmbench 常规测试可以很好反应各级别 cache 时延, 以及不同数据跨度下 cache 时延的变化, 不过 lmbench 测试对 arm64 平台测试有问题, 且每次测试时间过长, 这里直接使用 stream 和 lat_mem_rd 进行测试。

2.3.2 stream 带宽及时延测试

HUAWEI Kunpeng 920(同一个 numa 到不同 cpu 的时延及带宽 (node -> cpux))

# for i in $(seq 0 24 95); do echo "cpu:$i -> node0"; numactl -C $i -m 0 ./stream -W 50 -N 50 -M 64M; done
cpu:0 -> node0
STREAM copy latency: 1.28 nanoseconds
STREAM copy bandwidth: 12546.05 MB/sec
STREAM scale latency: 1.31 nanoseconds
STREAM scale bandwidth: 12207.16 MB/sec
STREAM add latency: 1.94 nanoseconds
STREAM add bandwidth: 12381.71 MB/sec
STREAM triad latency: 2.18 nanoseconds
STREAM triad bandwidth: 11019.52 MB/sec
cpu:24 -> node0
STREAM copy latency: 1.47 nanoseconds
STREAM copy bandwidth: 10851.14 MB/sec
STREAM scale latency: 1.51 nanoseconds
STREAM scale bandwidth: 10610.51 MB/sec
STREAM add latency: 2.03 nanoseconds
STREAM add bandwidth: 11812.86 MB/sec
STREAM triad latency: 2.34 nanoseconds
STREAM triad bandwidth: 10247.19 MB/sec
cpu:48 -> node0
STREAM copy latency: 1.75 nanoseconds
STREAM copy bandwidth: 9152.87 MB/sec
STREAM scale latency: 2.54 nanoseconds
STREAM scale bandwidth: 6298.64 MB/sec
STREAM add latency: 2.35 nanoseconds
STREAM add bandwidth: 10191.17 MB/sec
STREAM triad latency: 3.81 nanoseconds
STREAM triad bandwidth: 6303.67 MB/sec
cpu:72 -> node0
STREAM copy latency: 1.84 nanoseconds
STREAM copy bandwidth: 8699.05 MB/sec
STREAM scale latency: 2.83 nanoseconds
STREAM scale bandwidth: 5661.04 MB/sec
STREAM add latency: 2.56 nanoseconds
STREAM add bandwidth: 9362.28 MB/sec
STREAM triad latency: 4.14 nanoseconds
STREAM triad bandwidth: 5792.24 MB/sec
2.3.2 lat_mem_rd 不同数据长度的时延测试

HUAWEI Kunpeng 920(同一个 numa 到不同 cpu 的时延 (node -> cpux))

# for i in $(seq 0 24 95); do echo "cpu:$i -> node0"; numactl -C $i -m 0 ./lat_mem_rd -W 10 -N 10 -t 64M; done
cpu:0 -> node0
"stride=64
0.00049 1.552
0.00098 1.552
0.00195 1.552
0.00293 1.552
...
0.10938 1.552
0.11719 1.552
0.12500 3.104
0.14062 3.104
0.15625 3.103
0.17188 3.104
...
0.46875 3.104
0.50000 3.106
0.56250 7.389
0.62500 9.385
0.68750 10.238
0.75000 11.680
0.81250 11.735
0.87500 13.077
2.3.2.1 lat_mem_rd 替代实验

使用 memory_latency.c 对不同数据长度进行相同步长测试:

#include <sys/types.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#include <sys/time.h>
#include <unistd.h>

#define ONE p = (char **)*p;
#define FIVE    ONE ONE ONE ONE ONE
#define TEN FIVE FIVE
#define FIFTY   TEN TEN TEN TEN TEN
#define HUNDRED FIFTY FIFTY

static void usage()
{
    printf("Usage: ./mem-lat -b xxx -n xxx -s xxx\n");
    printf("   -b buffer size in KB\n");
    printf("   -n number of read\n\n");
    printf("   -s stride skipped before the next access\n\n");
    printf("Please don't use non-decimal based number\n");
}


int main(int argc, char* argv[])
{
    unsigned long i, j, size, tmp;
    unsigned long memsize = 0x800000; /* 1/4 LLC size of skylake, 1/5 of broadwell */
    unsigned long count = 1048576; /* memsize / 64 * 8 */
    unsigned int stride = 64; /* skipped amount of memory before the next access */
    unsigned long sec, usec;
    struct timeval tv1, tv2;
    struct timezone tz;
    unsigned int *indices;

    while (argc-- > 0) {
        if ((*argv)[0] == '-') {  /* look at first char of next */
            switch ((*argv)[1]) {   /* look at second */
            case 'b':
                argv++;
                argc--;
                memsize = atoi(*argv) * 1024;
                break;
            case 'n':
                argv++;
                argc--;
                count = atoi(*argv);
                break;
            case 's':
                argv++;
                argc--;
                stride = atoi(*argv);
                break;
            default:
                usage();
                exit(1);
                break;
            }
        }
        argv++;
    }

    char* mem = mmap(NULL, memsize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
    // trick3: init pointer chasing, per stride=8 byte
    size = memsize / stride;
    indices = malloc(size * sizeof(int));

    for (i = 0; i < size; i++)
        indices[i] = i;

    // trick 2: fill mem with pointer references
    for (i = 0; i < size - 1; i++)
        *(char **)&mem[indices[i]*stride]= (char*)&mem[indices[i+1]*stride];
    *(char **)&mem[indices[size-1]*stride]= (char*)&mem[indices[0]*stride];

    register  char **p = (char **) mem;
    tmp = count / 100;

    gettimeofday (&tv1, &tz);
    for (i = 0; i < tmp; ++i) {
        HUNDRED;  //trick 1
    }
    gettimeofday (&tv2, &tz);

    char **touch = p;

    if (tv2.tv_usec < tv1.tv_usec) {
        usec = 1000000 + tv2.tv_usec - tv1.tv_usec;
        sec = tv2.tv_sec - tv1.tv_sec - 1;
    } else {
        usec = tv2.tv_usec - tv1.tv_usec;
        sec = tv2.tv_sec - tv1.tv_sec;
    }

    printf("Buffer size: %ld KB, stride %d, time %ld.%06ld s, latency %.2f ns\n",
            memsize/1024, stride, sec, usec, (sec * 1000000  + usec) * 1000.0 / (tmp *100));
    munmap(mem, memsize);
    free(indices);
}

mem-lat.sh

#set -x

work=./a.out
buffer_size=1
stride=64

for i in `seq 1 15`; do
    taskset -ac 0 $work -b $buffer_size -s $stride
    buffer_size=$(($buffer_size*2))
done

HUAWEI Kunpeng 920

# ./mem-lat.sh
Buffer size: 1 KB, stride 64, time 0.001627 s, latency 1.55 ns
Buffer size: 2 KB, stride 64, time 0.001627 s, latency 1.55 ns
Buffer size: 4 KB, stride 64, time 0.001637 s, latency 1.56 ns
Buffer size: 8 KB, stride 64, time 0.001627 s, latency 1.55 ns
Buffer size: 16 KB, stride 64, time 0.001626 s, latency 1.55 ns
Buffer size: 32 KB, stride 64, time 0.001627 s, latency 1.55 ns
Buffer size: 64 KB, stride 64, time 0.001664 s, latency 1.59 ns
Buffer size: 128 KB, stride 64, time 0.003489 s, latency 3.33 ns
Buffer size: 256 KB, stride 64, time 0.003542 s, latency 3.38 ns
Buffer size: 512 KB, stride 64, time 0.003605 s, latency 3.44 ns
Buffer size: 1024 KB, stride 64, time 0.004646 s, latency 4.43 ns
Buffer size: 2048 KB, stride 64, time 0.004625 s, latency 4.41 ns
Buffer size: 4096 KB, stride 64, time 0.005523 s, latency 5.27 ns
Buffer size: 8192 KB, stride 64, time 0.006047 s, latency 5.77 ns
Buffer size: 16384 KB, stride 64, time 0.007000 s, latency 6.68 ns
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
为了进行Cache存储模拟器实验,我们需要先构建一个基于指令和数据访问模式的Cache存储器模型。然后,我们可以使用实际的程序来模拟Cache存储器的行为,并对其进行测试和评估。 以下是一个Cache存储模拟器实验的实验结果及分析: 我们使用的Cache模型是一个4路组相联、每路有16个块的Cache,块大小为32字节。我们使用了SPEC CPU2006测试套件中的一些程序来进行测试,包括bzip2、gcc、hmmer和mcf。 我们对这些程序进行了多次运行,并记录了Cache的命中率和访问时间。在这里,我们使用命中率和访问时间这两个指标来评估Cache性能。 实验结果显示,Cache的命中率和访问时间与程序的访问模式密切相关。对于一些具有较好空间局部性的程序,例如bzip2和hmmer,我们观察到Cache的命中率非常高,通常在95%以上。这意味着大多数的数据和指令都可以从Cache中获取,从而大大缩短了访问时间。 然而,对于一些具有较差空间局部性的程序,例如gcc和mcf,我们观察到Cache的命中率相对较低,通常在50%到70%之间。这是由于这些程序需要频繁地访问不同的数据和指令,从而导致了Cache中的块被频繁地替换。 此外,我们还观察到Cache的访问时间也与程序的访问模式密切相关。对于那些具有较好空间局部性的程序,Cache的访问时间通常在几个CPU周期内完成。然而,对于那些具有较差空间局部性的程序,Cache的访问时间需要更长的时间,通常在10到20个CPU周期之间。 综合以上结果,我们可以得出结论:Cache性能取决于访问模式。对于具有较好空间局部性的程序,Cache可以显著提高程序的性能。然而,对于具有较差空间局部性的程序,Cache的效果可能不太明显。因此,在设计计算机系统和优化程序时,需要充分考虑Cache影响

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值