之前有研究过这个，居然忘记了，看来确实是老了，没有盘过来。
如何下载，见 linux下载网页上的文件夹以及删除文件（stream）
出现了好几个问题
1.
error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
编译选项加入-static
2.
Segmentation fault
貌似和STREAM_ARRAY_SIZE，NTIME以及OFFSET有关
1）STREAM_ARRAY_SIZE 这个是测试数据集的大小，该大小应该遵循以下两条规则。
A. 数据集大小应不小于L3 cache大小的4倍。举例来说某10核Power机器中L3 cache为8MB/core，共80MB L3 cache，因此数据集的大小至少为80MB*4=320MB。由于数据集中每个元素大小为64bits，即8B。故数据集大小应设置为不小与320MB/8B=40M （40million或40000000）。
A. 数据集大小应不小于L3 cache大小的4倍。举例来说某10核Power机器中L3 cache为8MB/core，共80MB L3 cache，因此数据集的大小至少为80MB*4=320MB。由于数据集中每个元素大小为64bits，即8B。故数据集大小应设置为不小与320MB/8B=40M （40million或40000000）。
256KB*4/8B=128K 128000
B. 数据集大小应能确保程序输出时间大于20个时钟周期。该时钟周期可在程序输出信息中看到，如“Your clock granularity/precision appears to be 1 microseconds.“ 表示时钟周期为1微秒，20个时钟周期为20微秒。如果你的测试机器有200GB/s的带宽，那你的数据集大小应不小于4MB，即0.5million个元素。
B. 数据集大小应能确保程序输出时间大于20个时钟周期。该时钟周期可在程序输出信息中看到，如“Your clock granularity/precision appears to be 1 microseconds.“ 表示时钟周期为1微秒，20个时钟周期为20微秒。如果你的测试机器有200GB/s的带宽，那你的数据集大小应不小于4MB，即0.5million个元素。
2） NTIME 该参数为kernel执行的次数，程序将输出除第一次外其他结果中最好的结果，所以NTIME必须要大于1。该值默认为10，通常不需要修改。
3）OFFSET。该值为数组的偏移量，修改此值可改变数组的对齐，从而在一定程度上改变输出的性能结果。一定程度在这指的是也许会改变，也许不会改变。本人在Power上的测试是没有很大的改变。如果需要修改该参数，通常将其设置为靠近2^n的数，例如使用-DOFFSET=1022 （靠近2^10=1024）。
4） STREAM_TYPE。我们可以通过修改该参数设置测试集的数据类型，默认是double(8B)。如果将其改为float则数据集大小减少一半。
arm-linux-gnueabihf-gcc -O -static -fopenmp -DSTREAM_ARRAY_SIZE=128000 -DNTIME=10 -DOFFSET=0 stream.c -o stream_omp_exe
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 2362 microseconds.
(= 2362 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
Each test below will take on the order of 2362 microseconds.
(= 2362 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
2362 clock ticks已经大于20 clock ticks
STREAM_ARRAY_SIZE=128000 够了。