macsim使用心得记录

2022.5.31

一. 解决 运行./macsim后params.out、NULL、trace_debug.out直接输出在./bin目录下 的问题。

1. 因为在哪里运行就输出到哪里，所以第一想法是在目的文件想要存到的目标文件夹执行macsim二进制文件。但是执行失败，总结是必须在./bin中执行。

2. tutorial文件里面说，"setting the STATISTICS\_OUT\_DIRECTORY"，但是找了很久都没找到这么个参数。后来发现\是不用输入的，只是一个单词区分标识而已。

在macsim/src/all_knobs.h找到了KNOB_STATISTICS_OUT_DIRECTORY，并且得知macsim/def/general.param.def有传入定义。

原来在params.in中可以写入out变量来指定输出目录。

经过运行测试发现只有trace_debug.out用这种方法有效。。params.out、NULL还是直接输出到./bin文件中。

于是经过手动调试魔改macsim/src/knob.cc，重新编译，终于将params.out的输出目录也改好。

最终NULL文件也没有找到解决办法，只好每次跑完程序都手动修改。但是未来并行跑很多程序的话，NULL一定会互相冲突重写，这是一个问题。

不知道是我没理解STATISTICS\_OUT\_DIRECTORY的究极奥义还是开发bug?

为了方便，现在out变量都制定在bin/myresults文件下，147后续也需这样修改。

2022.6.1

一. 跑通MonteCarlo的trace.txt

它不属于rodinia，拥有下载比较顺利的trace。

1. 报错trace_read_cpu.cc:1177断言。

warning过trace reader和trace generator版本不匹配，暴力修改trace.txt为1.3不行。

trace.txt中是x86，这是CPU还是GPU的benchmark? 搜不到，遂放弃，回到rodinia。

二. 跑通下载好的backprop的trace

1. 它的trace.txt也是x86，遂放弃，决定自己跑rodinia的trace，版本应该不会有问题，而且也可以亲眼见证x86对不对。

三. 搞懂gpuocelot，跑一个trace

1. 进容器找gpuocelot, 自己编译。

2. 阅读gpu_tracen.py，学习nvcc编译的含义。

CUDA程序有两种代码：CPU上的host代码，GPU上的device代码。

搞不懂gpu_tracen.py的ver、inc，花大量时间纠结什么含义，后发现没啥用。

3. 研究tutorial的

输入执行失败。.cu是rodinia的源代码。 通过之前查阅的资料了解到-ocelotTrace是个错误参数，要加l。但是不知道boost libraries是什么。

4. 编译backprop

libcudart.so找不到。各种链接报错。

此日翻墙失败。

2022.6.2

一. 在macsim之外跑一波backprop

1. docker内 macsim之外跑，缺libcudart.so.7.0。查无此文件，放到/usr/local/lib也说缺。

发现cuda路径就是不对的。

2. 或许不应该在docker中跑。exit到服务器上重新来。文件路径依然不对。

3. 翻墙就是失败，找到163历史收件尝试使用glados。

找到域名、重新登录、配置文件。

无论如何配置文件都是失败的，无法启用管理员模式将配置文件写入。win11家庭版没有组管理功能，找大量教程后成功找到组管理。

最后成功删除以前配置不完全的配置文件，成功开启代理。

弊端：以后每次开机都要的手动开代理，不然浏览器打不开lgn，而且需要每天签到续命。

2022.6.3

一. 服务器搞nvidia驱动

在docker中运行nvcc -V发现没有。exit回到服务器。发现nvcc -V没有，nvidia-smi也没有。魔改操作删除。

通过命令了解205服务器：GP100GL Tesla P100 PCIe 16GB；Ubuntu 20.04；gcc 9.4.0；但是nvidia-smi就是找不到，于是重新装nvidia驱动。

更新CUDA版本；根据服务器硬件配置下载.run文件。

但是需要reboot强制重启，需要禁用nouveau。

二. 回到docker使用gpu_tracen.py跑trace

1. 应该是在服务器上的容器里的模拟器跑程序，于是放弃直接使用服务器的硬件环境。

使用rodinia_3.1的很多benchmark进行测试生成trace，每个目录下都有了trace文件夹，但都是空的。

2022.6.4

一. 用docker使用gpu_tracen.py跑trace

1. 所有benchmark都有trace文件夹和occupany.txt文件。只有hotspot的occupany有东西。

二. 搞懂gpu_tracen.py的内容

1. -cmd是benchmark中run这个二进制文件的内容。 -inc -I增加编译器标志。 

        cwd是当前工作目录的绝对路径。

GPU的kernel是什么？是硬件概念（哪个核心寄存器？）还是软件概念（CPU指定在GPU上运行哪些代码称作内核）？

2. 试着读懂get_kernel_information

subprocess.Popen(args.....）:子进程、管道等等概念。

re.compile（）:对一个正则表达式进行编译，让字符串变成pattern实例。

三. 重新看macsim中gpu trace的生成文档

试图搞清楚具体怎么生成gpu trace。搞清楚GPUocelot和tracegenerator的关系。

2022.6.6

一.阅读ocelot的疑问列表

1. docker中cuda 4.2; unbuntu 14.04.4; g++ 4.4.7

ptxas也是一个编译工具。

 nvcc负责将不同虚拟机器合并到一起。

2. 找到了ptxtracegeneration的wiki

https://code.google.com/archive/p/macsim/wikis/PTXTraceGeneration.wiki

理清了gpu_tracen.py是负责最后两步的。

二.按照wiki梳理trace生成步骤

1. 编译的时候找不到lib/modules文件目录

5.13.0-41-generic:操作系统的发行版号。

我把这个目录也挂载到docker，还是报错，205服务器内核部分缺失,nvidia-smi也没有。

2.换147服务器

新建用户，重新拉macsim镜像，下载rodinia_3.1。

3. 147服务器的CUDA有问题

/usr/local/cuda是一个失效的软链接；nvcc目录也不对。

2022.6.7

一. 解决147中cuda软链接失效的问题

没有库文件，但是有nvcc。nvcc的cuda和nvidia的cuda不一样，不是同一个。

重新安装CUDA10.1，魔改一通不知道怎么就从不行到软链接对劲了。。。

二. 挨个编译rodinia_3.1

在147服务器上编译，还写了一篇CSDN解决大部分的问题，一共编译18个。

并且将configure.ocelot修改并拷贝到每个benchmark目录中。

三. 链接-locelot -locelotTrace

SDK：软件开发工具包

API：程序进行系统调用的接口

.LIB：为了在程序中找到API的入口点

.so: linux就是动态链接库，是.LIB程序对应着的东西；windows的.dll和这个差不多

2022.6.8

一. 链接-locelot -locelotTrace

1.按照邮件列表里面的建议更改rodinia/common/make.config，LIB增加ALL_LIB变量，等于ocelot库文件目录。

2.在doctor中编译，用ldd 二进制文件发现库已经导入。

二. 跑hotspot的trace

nvcc版本不适配？说识别不出正确语法。邮件列表说需要用5.0以下版本的cuda。但是docker是4.2没问题。gpu_tracen.py写的也是sm_20没错。无解，换benchmark。

三. 跑backprop的trace

1.docker检测不到nvidia设备。

需要把gpu硬件环境也挂载到docker中。查找资料说直接输入参数就可以。

输入后发现还是不行，查找资料需要重新下载docker并且进行配置。

下载好需要重启docker才可以，205的docker不可以重启。遂换147服务器，魔配重启，gpu导入docker成功，docker终于可以识别nvidia-smi指令。

2. 没有链接lboost库

trace文件夹还是空的，重新修改make.config文件增加链接参数。重新编译链接成功。还是空的。

2022.6.9

一. 链接参数增加`OcelotConfig -l -t`

在common中增加后编译成功，虽然没看出来有啥区别。

-lz参数是一个压缩库，添加后就报错，tutorial有，wiki中没让增加。所以不加了。

二. 对比测试程序的configure

/gpuocelot/test/cuda4.1sdk那个目录里面有测试程序，找到了configure.ocelot，文本对比了一下它的和我backprop的，把我的database改成它的了。跑trace还是空的。

三. 跑spec06的trace

1. 去wiki中盘查找到了

下载解压，得到trace! 

2. 运行，果然版本太老，说1.4什么的。

阅读源代码，手动找bug位置，排查原来是Trace.txt文件格式不对。

1

x86

要像这样，不要摆在同一行。

3. 重新运行，还是报错。

 一个是warning，另一个是断言error。需要排查。

2022.6.10

一. 排查SPEC06运行时的问题

1. 看error: 线程数少于0

观察trace.txt文件并没有小于0的数字，觉得很奇怪。

2. 看warning：版本不适配

之前跑完的401的trace.txt文件被删除了，看不了具体的格式。于是新建会话使用pin重新跑，不过跑的太慢了，好几个小时都没有输出。

3. 找邮件列表

下载了一个2点几版本的spec int trace，一共9个。看了一下trace.txt内容有变化，跑了一下还是一样的报错。

4.重新看error缘故

看process_manage.cc，加了很多report输出从trace.txt文件中读取到的变量值到底是什么。发现了两个相悖的函数：create_process和setup_process。手动debug试图理解代码逻辑无果。另外用./build.py -d模式似乎没什么用。

5.观看test文件中的示例trace.txt

区别是第一行x86后面有一个1.3。我将自己的spec int的trace.txt照着改了一下，并且使用trace converted工具进行trace.raw文件的转换。

6.改trace!

使用converted后，trace.raw目录下会有新的raw文件。跑了一下发现运行的还是旧raw，于是将旧raw删除，新的raw改名为旧的。跑通！

只是不知道这样的魔改方式：加1.3有没有问题。但是跑完得到的general.stat.out有指令数，据说是对的？先这样。

二.运行所有int spec06

步骤如下：

1. 使用converted挨个弄raw文件，删除旧的，将新的改名为旧的。只是不知道第二个参数应该拟定什么值，只好默认。

2.改out的目录（params.in中）  ；改trace_file_list--trace.txt的文件数也要改  ；改trace.txt加1.3

3. 运行

4. 移动NULL文件，因为这个原因所以只能一个一个地运行。

2022.6.11-2022.6.12

一.跑spec06fp

下载到的文件中只有7个benchmark。

有个疑问：这是不是打过点的？如果是，多数目录下只有一个txt文件是对的吗？打点之后的权重怎么看？

2022.6.13

一. 整理论文

把之前组会汇报过的论文记录了一下，用NoteExpress稍作记录

二.读论文

PACMan: Prefetch-Aware Cache Management for High Performance Caching

1. 是同构还是异构？  同构

2. 缓存替换。按照请求类型是预取还是普通请求进行划分，使用不同的替换策略。基于RRIP替换策略进行调整。

RRIP：默认值为2。

SRRIP：插入者一定的概率值为3，大概率是2。BRRIP：插入者值为3。二者命中时值为0。

PACMan：PACHit 普通请求命中置为0，预取请求不变; PACMiss：预取请求插入时就置为3。

                 采用组决斗，三种方法----SRRIP+PACHit、SRRIP+PACHitMiss、BRRIP+PACHit。

其实就是相比于普通请求，降低预取请求的优先级。

2022.6.14

一.统计Spec06的实验数据

1.数据和在1.2版本macsim中跑出来的差距很大，怀疑是计算方法或者魔改造成了失误

得知运行时命令行的输出就包含了ipc这一统计结果，因此建立nohup脚本，将每个benchmark重跑一遍，得到nohup文件以便统计数据时使用。

nohup中，>后面跟着想要输出的目录，没有会直接新建。&这个字符放在最后表示后台运行，还可以继续执行其它命令不耽误。

二.执行1.2中示例GPU benchmark

1. 1.2版本的trace文件夹有kernel_config.tXt作为trace.txt。kernel_config.txt和occupany.txt中的内容有很大关系，gpu_tracen.py值得分析

2. 在邮件列表中发现--no_llvm这个参数如果加上，occupany.txt中就不会有内容。但是据说--no_llvm这个参数是和CPU有关系的。

2022.6.15

一.画图统计spec06数据

1.spec06是单线程程序，如果只跑一个其实只会用到一个核。

2.对于有很多trace的spec06，只挑选其中一个trace就行，不用都跑。

所以重跑。

3. LLC hit数和miss数的和就是访问LLC的次数？但是高的离谱。

二.研究GPU trace

没有眉目。