I would like to extend my deepest gratitude to my two mentors, Patrick and Karthik, who are both esteemed developers at GitLab. Their expertise and guidance are invaluable, and I am incredibly fortunate to have the opportunity to learn from such experienced professionals in the field.

The primary purpose of this page is to serve as an archive for my weekly reports throughout the GSoC journey. These reports will detail my progress, challenges encountered, solutions devised, and learnings acquired each week. The intention behind maintaining this archive is twofold:

1. Transparency: To keep a transparent record of my contributions and progress throughout the project. This will allow my mentors, peers, and anyone interested in the project to track its development and my growth as a developer.
2. Reflection: To serve as a reflective journal for myself. Documenting my journey will help me analyze my approaches, celebrate milestones, and learn from the challenges I face.

You may access all related pages by visiting the GSoC 2024 category.

逃离

我为什么第一个想到的词就是逃离呢？因为我自己在2023年4月份的时候，已经疲倦了。每当疲倦的时候，我都不禁地反问自己，打代码的意义是什么呢？在面实习的过程中基本没有得到什么正反馈，不知道自己该为何而战。心里开始烦躁了，焦急了，幸福的口袋似乎什么东西都没有装下。不经让我想起《Rewrite》游戏里面的经典话语：

有一天，察觉到自己一无所有。

发现本以为堆满着幸福的口袋，其实空无一物。

因为我没为在口袋里塞些什么而努力，所以是理所当然的。

我一直以打代码自豪，这是我重要的存在意义。然而，我深刻地记得我当时对自我的怀疑，我真的能够打代码一辈子吗？我真的喜欢代码吗？我真的不是通过代码来逃避自我吗？我很迷惘。于是乎我决定逃离，本来不打算五一回家的我，以逃离为目的踏上了回家的旅程。

与挚友的交谈

从西安到成都的高铁很快，我简单地背了个包就回到了成都。和我的挚友见面了，他仍然是往常一样，我也如往常一样。吃喝玩乐过后，我和他在他那租的一套一里面聊着天。我们从初中聊到高中再聊到大学，我第一次知道了他在初中的细腻情感，第一次知道了他在高中时候将自己的情感诉诸于暴力的悔恨。我许久没有如此真挚的聊天了。我不仅又反思了自己的傲慢与偏见，我们真的能够轻易地了解一个人吗？我们总是凭借一些自己或他人的所见，就轻易对一个人下定义。

不禁意间，天就变亮了，我的挚友给我说不要逃避自己的感情，既然无法开辟一段新的未来，就认真地审视自己的过去。我一下就想到了我这次回家的主题：逃离。我不由黯然伤神。这几年，我不知道自己是否前进了。我的一些朋友一直认为我是在原地踏步，说实话，我很讨厌听到这样的话。但是反过来想，如果是一个不那么了解我的人，也确实很容易得出这样的结论。

回家的反思

家永远是最温暖的港湾，不论哪个时间回家都会有这样的感慨。和父母聊了聊天，见了见外公，吃到了熟悉的香味。我的烦恼与疑惑已然被抛在了脑后。然而，我不由自主地又翻阅了我和曾经的她在高中时期写的书信，所有的信都用一种巧妙的方式送回到了我的手里。我每次都觉得这是命运使然，似乎可能在那时她就已经决定分手了。

我每次看信的内容，涌起的都是极其复杂的感情。好的方面有对往日回忆的追忆，对昔日温暖的遗憾。坏的方面，我不禁质疑这份感情的真假，我无法分清什么是假什么是真。每次一想到这个，我感觉到极其的厌倦，爱过的人和事物为什么这么让人扫兴。

五一节和另外的挚友相见了，我说起了我的迷惘，对代码的疑惑，自己能否将其作为终生的事业而奋斗呢？对困扰自己多年的感情的疑惑，自己是真的在前进，还是在逃避自己的内心呢？

重返重庆

为什么突然想去重庆呢？没有理由，就是想去了。见到了自己的大学室友，他没什么变化，一如既往地真诚。我才明白我追求的是什么，我希望能与人建立真诚的关系，希望我真诚待别人，也希望别人真诚待我。然而，我追求的这个东西确实这个世间最为宝贵的东西，我矛盾的地方就在于明知有些东西难以强求却想强求。

回到了自己本科的母校，见到了那个时候对我启发甚大的学业导师。他仍然是对科研保留着属于他的纯粹。我很羡慕他，我觉得我的科研生涯完全没有去解决过一个真正的科学问题，从来没有去探索过计算机科学应该去解决的问题。他推荐我去滑铁卢大学读博士，我说我硕士期间的科研素养积累的不够，他批评了我的想法，我现在都记得他的话语：

你为什么不去看看国外是怎么搞科研的呢？如果你觉得不合适，退学就行了啊。而且去国外体会一下别人的文化，别人的生活，感受一下也是一个好事。

我才意识到自己的局限性，才意识到自己在西电读研失去的一个最宝贵的东西：勇气。我自己扼杀了自己的可能性。我老师问我，你觉得一个博士最重要的是什么？我已经忘记我怎么回答的呢？他给我说了一个我很震撼的话，博士最重要的是去研究真正的科学问题。实际上，我在读研之前他应该也给我说过，但是在当时我很难理解这句话的真正含义。我不禁再次反思，我想成为一个纯粹的人，然而我的逃离证明了我对代码并不纯粹。

当我沉溺于另一个世界中的时候，我另一位朋友带着她的男朋友来了西安，突然将我从这段妄想拉回了现实，我急忙买了一张从重庆到西安的动车票回到了西安。似乎给我这段旅程画上了句号。

正视

五一的逃离让我认识了许多东西，我才发现所谓的实习和秋招我不应该焦虑，我保持我自己，做好我自己该做的事情。

• ehForwarderBot社区贡献：抽空认真地阅读了efb-qq-plugin-go-cqhttp的源码，给所有的方法添加了注解，并提供了发送文件和视频的功能。
• database-systems-complete-book-solutions：基本完成了这本讲数据库原理的课后习题答案。

当时我自己也学了很多东西，毕竟我还是很热爱coding的。

婚礼

来西安的朋友结婚了，在9月份给我发了请帖国庆她要结婚了，我由衷地为她感到高兴，她找到了属于自己的归宿。我曾经去过她家拜访，那个时候我只觉得自己格格不入，那种生活的气息甚至让我觉得有些许的窒息。我突然意识到自己是不是离小小的幸福越来越远了。

本以为能高兴去参加的婚礼，更多的却是给自己带来的痛苦。当我知道伴娘是我的前女友的时候，内心是一丝丝的期待，主要是好奇这五年的时间她变成了一个什么样的人。同时，我也很想见我的哥们儿。来到成都东站的时候，兄弟们已经在等着我了，然而殊不知噩梦才刚刚开始。

到了婚礼前一天晚上的时候，我一个哥们儿突然说，我的前女友叫我们过去玩。实际上，对于我来说我的内心是不愿意的，我或多或少觉得有点尴尬。我不知道我该说些什么，所以在与她见面的那一瞬间，我有逃避的想法，不过既然来了，肯定不能逃避了，我现在都能清晰地记得我内心所说的话：

人不能逃避自我。

然而，我的前女友只叫了我另外四个兄弟的名字，而忽略了我的名字，我一瞬间就语塞了。因为我的存在在此时此刻已经被她恶意地抽离了。于是乎，大家热烈地讨论明天早上堵门的事情，商量着小游戏该如何安排，而我并不存在，这让我第一次意识到了我似乎成为了《局外人》这本小说的主人公。只不过，他是主动的，而我是被动的。最讽刺的是，我一个兄弟对我所说的话：

这么多年了，你还没走出来吗？

我已经无法解释什么了，我第一次意识到了距离。然而，也是有开心的事情。第二天我听到新娘的致辞的时候，我才明白这份幸福属于她是应该的。真挚的情感表达，她放弃成为一个医生，选择了其他职业，感谢了她的父母对她职业选择的理解。感谢与她老公的相遇。说实话，我的眼睛湿润了，唯独真挚的情感能让人心震撼。

结婚的当天下午，他们都去打牌了，我自己选择了逃离。把我的MBP打开，写了一下午的MIT 6.824。这可谓是我最快乐的时光了，我终于找回了属于自己的存在。我从来不讨厌孤独一人，而是厌恶被人恶意的孤立。

工作

人生第一次参加了真正意义上的工作，然而第一份实习在NVIDIA，可能直接会把我惯坏吧。不如说已经把我惯坏了。上班的体验是很好的，然而晚上一个人待在上海小小的出租屋里面，感受到的确实实在的寂寞。突然急切地希望自己身边能有一个人陪伴，然而我却厌恶自己的想法，如果是因为寂寞就去靠近一个人，对她来说这是一个不公平的事情。所以由衷地觉得，晚上的时间要好好把握。要去充实自己的生活。不禁苦笑，说总是比做起来容易。

小结

人的一年说多也多，说少也少。然而，正如我开头所讲，简单地记录自己的存在。

What I cannot create, I do not understand

The Minimal Setup

In this tutorial, we will use the c++ as the language to write the shell. So at we should use cmake to construct the build environment. If you are not familiar with cmake, don’t worry about it. It’s easy to understand. For convenience, I hope you can just use the following commands to initialize the repository.

1
2
3
4

mkdir miniShell && cd miniShell
git init
git remote add upstream https://github.com/shejialuo/miniShell
git pull upstream start-code

At this time, you will find the miniShell.cpp under the root tree, the functionality of the miniShell.cpp is simple enough. Because this is tutorial, we just simplify the program. We assume miniShell would have only two modes like any shell:

• Interactive
• Batch mode

The idea is actually the same. However, at now. We do not implement any functionality.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#include <iostream>

void printUsage() { std::cout << "Usage: ./miniShell [file]\n"; }

int main(int argc, char *argv[]) {
  if (argc != 1 && argc != 2) {
    printUsage();
  }

  if (argc == 1) {
    std::cout << "This is a mini shell\n";
  } else {
    std::cout << "This is a mini shell called with a file " << argv[1] << '\n';
  }

  return 0;
}

If you are interested in the CMakeLists.txt. You could just provide its content to the ChatGPT, it will give you a wonderful explanation. At now, you could build this program:

1

mkdir build && cd build && cmake .. && cmake --build .

Under the build directory, you will find the miniShell executable.

The Parser

We have already set up a minimal development environment, now we need to parse the shell script. Actually, writing a parser could be another theme. So in this tutorial, we will just use native way to parse the shell script.

So we should first make sure the functionality of the shell. I don’t think it’s a good idea to support the condition or loop control. It’s not the point. We just want to learn the system programming. Below is the spec:

1. The operations for variables.

   1 2 3 4 5

   variable=5 echo $variable # 5 echo ${variable} # 5 echo '${variable}' # ${variable} echo "${variable}" # 5

2. Command substitution

   1 2	variable=`echo 5` # variable=5 variable=$(echo 5) # variable=5

3. Redirection

   1 2 3

   echo '5' > /tmp/txt echo '55' >> /tmp/txt cat < /tmp/txt

4. Pipe

   1	command1 | command2 | command3 | command4

5. Job control

   1 2	sleep 100 & bg %1

As you can see, actually we could simplify the question. We first split the script line by line. For each line, we split the line by |. And we will generate the following classes for further process:

1. Variable: handle the a=3.
2. Command: handle the <command> <argument1> <argument2>.
3. PipeCommand: handle the Command1 | Command2 | Command3.

I will not dive into this part, because it would be annoying and far away from the theme of this tutorial. Here, I give a snippet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class Command : public CommandBase {
private:
  std::string command;
  std::vector<std::string> arguments;
  std::optional<std::string> redirectFile;
  RedirectStatus redirectStatus;

public:
  Command() = delete;
  Command(std::string &&c, std::vector<std::string> &&ar, std::optional<std::string> &&rf, RedirectStatus status)
      : CommandBase{}
      , command{std::move(c)}
      , arguments{std::move(ar)}
      , redirectFile{std::move(rf)}
      , redirectStatus{status} {}

  virtual void execute() final;
  virtual std::string inspect() final {
    std::string result = command;
    for (const auto &argument : arguments) {
      result += " " + argument;
    }
    return result;
  }
  virtual ~Command() = default;
};

From the above snippet, all we need to do is define the execute function. For each line, we will call the execute function. You could use the following command to pull the latest code:

1

git pull upstream add-parser

Below is the code hierarchy, if you are interested about the detail, you could see the parser directory.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

.
├── CMakeLists.txt
├── command
│   ├── CMakeLists.txt
│   ├── command.cpp
│   └── command.hpp
├── miniShell.cpp
├── parser
│   ├── CMakeLists.txt
│   ├── parser.cpp
│   ├── parser.hpp
│   └── tests
│       ├── CMakeLists.txt
│       └── parserTest.cpp
└── README.md

Look at the miniShell.cpp:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

#include "parser/parser.hpp"

#include <fstream>
#include <iostream>
#include <stdlib.h>
#include <string>

void printUsage() { std::cout << "Usage: ./miniShell [file]\n"; }

void start(std::istream &is, bool isFile = false) {
  Parser parser{};
  while (true) {
    if (!isFile) {
      std::cout << "$ ";
      std::cout.flush();
    }
    std::string script{};
    std::getline(is, script);

    if (script.empty()) {
      return;
    }

    if (!script.empty() && script.back() == '\n') {
      script.erase(script.length() - 1);
    }

    auto command = parser.parseScript(script);
    if (command != nullptr) {
      command->execute();
    }
  }
}

int main(int argc, char *argv[]) {
  if (argc != 1 && argc != 2) {
    printUsage();
  }

  if (argc == 1) {
    start(std::cin);
  } else {
    std::ifstream ifs{argv[1]};
    if (!ifs.is_open()) {
      std::cout << "Cannot open file " << argv[1] << '\n';
      exit(1);
    }
    start(ifs, true);
  }

  return 0;
}

Due to the nice abstraction from cpp, the file stream and standard input stream are all the istream. So we define a start command to abstract the process. The most important function you could see is the execute function.

A Simple Start

Now we try a simple command /usr/bin/ls, we will write the method Command::execute. We will use fork system call to create a child process and waits for its action which would use exec system call for /usr/bin/ls. If you do not understand these concepts, you could read the man page of the fork or just read Advanced Programming in the UNIX Environment chapter 8.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

void Command::execute() {
  pid_t pid = fork();
  if (pid == -1) {
    std::cout << "[fork error]: cannot fork\n";
    exit(EXIT_FAILURE);
  } else if (pid == 0) {
    std::vector<char *> argv{};
    argv.resize(arguments.size() + 2);

    argv[0] = const_cast<char *>(command.c_str());
    for (size_t i = 0; i < arguments.size(); i++) {
      argv[i + 1] = const_cast<char *>(arguments[i].c_str());
    }

    argv.back() = nullptr;

    execv(command.c_str(), argv.data());
  } else {
    wait(NULL);
  }
}

However, the above code is clear. What we do is simply pass the command and arguments to the execv system call. Like the following figure illustrates, when we type /usr/bin/ls, the result is OK. However, when we type ls, there is no result. This is because we need to search the $PATH environment. We will improve our code for part 2.

As usual, you could use the following command to get the code:

1

git pull upstream simple-ls

暑期实习

其实投暑期实习的时候，我还是十分自信的，觉得靠着自己的能力拿下一个暑期实习是没有什么问题的。国内的大厂我投了百度、美团、阿里和腾讯。拼多多还有字节我直接选择没投，我觉得我没有那个命，而且我很不认同拼多多对不懂计算机的人群的歧视（参考2022年度最不可赦漏洞）。同时我也投了一些外企的暑期实习，比如说亚马逊，英伟达和Paypal这些公司。

由于我本科双非，阿里实习简历过不了（面了个所谓的电话面），外企的面试属于可遇不可求。我总共只面试了百度，美团和腾讯这三个公司的暑期实习。

百度

百度是我最开始投的公司，当时我选择的岗位是C++软件研发工程师，做笔试的时候运气好，三道算法题我做出了两道算法题，拿到了面试机会。我现在已经记不清楚面试的内容了，我只记得一面做的是LeetCode 143，二面做的是LeetCode 25。由于当时就没刷题，在只有20分钟左右的时间下，我很难写出在ACM模式下的LeetCode 25题。同时由于我自己自言自语地说了一句，感觉思路不对，然后面试官回了一句，“确实思路肯定有问题，你想一想”。又浪费了不少的时间。

题做不起，自然而然就被挂了。实际上二面的面试官问我做的科研横向项目在分布式集群下怎么收集的数据（实际上这个横向项目技术含量比较低，苦于没有实习经历，我还是得写一个看起来正经的项目吧），我说是使用python来收集的，他反问我为什么不适用Kafka。最后结束的时候他给我说搞工程和搞学术是不一样的。

其实，我很不能理解这些面试官的心态，没有必要教育我一顿。我的业务场景根本不需要那么重的东西，我只需要收集点数据处理就行了。

美团

美团我的笔试做的一塌糊涂，100分拿了个40分？美团我进行到了第二面，由于是投的基础研发部，所以面试需要进行三轮。

一面的面试官，主要是询问我做的国外公开课的CS149中的能够解析任务依赖的异步Fork-Join任务库是怎么实现的，我记得当时我是把整个数据结构怎么设计的，以及同步的过程详细给面试官说了。可能因为回答的好，后面面试官给了我一个很简单的算法题。

然而，最令我震撼的是那个面试官在反问环节对我说的一番话（当时我问了他，你工作的时候觉得做的最有意思的事情是什么？）：

你做的这个东西，我们一般都是直接用别人的库，平时我们很少写这些。可能你因为还是学生，没有上班，可能还比较幼稚，工作本身就是没有意义的，可能最大的乐趣就是解决了一个BUG。

实际上，我被这句话震撼了。我其实并不是不明白上面这句话的道理。我感到了深深的悲哀，我一下意识到了我如果从事互联网的工作，可能也是这样。我该追求什么呢？

二面就比较抽象了，面试官一上来就问我我为什么笔试做的这么糟糕，我说题比较难，我尽力了。然后让我写了一个简化的我没有做的笔试题，然后他说我函数参数传错了。我或多或少写了5年的cpp了，真的不至于传参数都能传错。然后我直接说我确实参数传错了，然后面试就这样结束了，时间不到30分钟。

腾讯

腾讯是面的最舒服的，因为他直接问我现在能来实习吗？我说不能，然后面试就结束了。多好不要浪费大家的时间。

小结

我在面完上面三家公司，感到了深深的疲倦。于是在当时我在朋友圈发了以下的内容：

从2月份到现在，面试了百度，腾讯，阿里这三家公司。我的体会是，面试变成了一件相当无聊的事情，二十分钟不明所以聊一下你做的项目，然后给你一道LeetCode的中等题目或者hard的题目让你做一做，然后你就一直做，面试官几乎不说话，做得起就继续，做不起就拜拜。如果你做起了，还会因为你现在不能来实习成为廉价劳动力直接挂你。

我在想这些面试官对我的了解基本等于0，就因为我能做起一个题就让我继续下一轮……，我是真心觉得无语。问些八股还要去找公司里面的题库，问new和malloc的区别这种无聊的问题。

从现在的经验来看，国内的互联网做的东西真心很无聊。还是思考一下换赛道吧，还是希望能做点有意思的东西的。

于是乎，我做了一个很不理智的决定，直接放弃了其他大厂的暑期实习。根本不想面，我觉得面试毫无意义，同时去这些大厂实习也是毫无意义（当然，我肯定是偏激的观点）。不如在学校做点有意思的事情。

差不多从四月份开始我就开始学习Writing An Interpreter in Go和Writing A Compiler In Go，我用cpp进行了自己的一个实现（见cppmpiler）。

然后，给ehForwarderBot社区做了一些贡献，主要是给slave端的QQ添加发送文件的支持。

当然，我不得不刷LeetCode。这可谓是我秋招过程中做的最痛苦的事情。让我回想起高中为了成绩不得不刷题的感觉。明明我还想写一个模拟器，还想去探索一下内存模型和缓存一致性。

秋招

秋招是从7月份就开始的，因为很多公司已经开始提前批了。还是希望自己能毕业进大厂的，至少平台要高一些。所以还是采取了海投策略。

百度提前批

百度提前批约我面试的时间应该是2023年7月中旬左右，一面的面试官是一位女生，我已经记不清她开了摄像头还是没开摄像头，听着她虚弱的声音，我就觉得她已经很累了。她问了我一些并行计算的项目，然后就让我做两道算法题了。我直接把两道算法题秒了，毕竟我不是在做题，我只是在默写。

二面咋说了，面试官还是比较有水平的，问了我并行计算，怎么使用CUDA的，然后怎么做Reduce操作。然后问了我个CPU指令乱序，回答不上（那个时候体系结构方面的知识确实忘了许多）。然后写了个LRU，给我介绍了一下部门的情况，面完二面就直接挂了。

要说我不觉得不甘，那肯定是扯淡的。不过从实习我得到的一个宝贵的经验就是面试也就是这个样，主要还是看顺眼了就行了。许多东西都是强求不得的。

美团

美团由于填写简历的时候填错了，学历填成了非统招，所以做完笔试就没有后续了，实际上我觉得cpp面美团也没有什么优势，毕竟java基本不懂，数据库也只会底层的原理，不懂上层的东西。

阿里

阿里总共有6个部门，因为阿里卡第一学历，所以我阿里的简历筛选一个都通过不了。我其实觉得这个公司的HR挺无能的，作为一个公司核心就应该是选择人才，如果通过卡第一学历甚至那什么28所名单来进行筛选，只能够体现这个公司的无能。

腾讯

腾讯我投的是后台开发，说实在的，我觉得cpp就不应该投后台开发，然而我没有更好的选择。腾讯第一次捞我，把我调到技术运营的岗位去了，我研究生做的是云方面的研究，这个岗位就是针对内部系统的运营维护的，面试了就是聊天加项目加八股。没什么新意。然后二面也比较常规，三面主管面没发挥好，可能主管觉得我go语言基础不是那么好加上iptables的实现没有解释的清楚（我忘了），三面就给我挂了。

后面第二次捞我，是腾讯健康的部门的后台开发，第一面面了两个小时，当时我就知道多半这次面试就已经结束了。实际上这个题的代码很不好写，内存有限制，面试官一定要让我把代码写出来。前面八股问了半个小时，我和他讨论思路用了50分钟，怎么设计数据结构是合理的，怎么避免内存限制，怎样效率最高。然后我就开始写了，这个代码很不好调试，从4点开始面到5点50左右，我的精神已经开始恍惚了。我主要想吃饭了，然后我主动给面试官说我写不了了，就这样结束吧，大家好吃饭。

B站

B站由于认识HR，虽说简历全挂了，还是给了我一个分布式存储开发岗位的机会。一面的话是八股加体系结构，这可以说是我进行的最有深度的一次面试了，给面试官讲解内存子系统。当然二面只进行了20分钟就结束了，显然B站不招人嘛。但是我觉得这是给我想法转变一次的面试，cpp真的要搞后台开发吗？我学的技能就不是互联网的东西。

龙芯

龙芯的面试我是已经在英伟达实习的时候面的了，这个岗位相当有意思，名字叫基础软件研发，主要做gcc和ocaml的编译器适配和优化，你可知对于一个学习过Haskell的人并接触过一些ocaml语言的人来说，这个岗位有多么的吸引。面试的过程还是主要考察体系结构的知识，以及询问我怎么在CPU上实现矩阵的乘法的优化。二面主要问我调试器是怎么实现的，怎么做并行计算的，怎么实现SUNDR（一个安全方面课程的最后的作业），然后问了我个在Linux系统上用鼠标左键点击PPT翻页，从设备到内核态到用户态的整个过程（这是一个很有意思的问题）。目前，状态在泡池子中。

其他

实际上，我还投了许多公司。

• 简历挂的：字节，拼多多，京东，滴滴，小米，米哈游，大疆，网易。
• 泡池子的：华为（云计算开发工程师），比亚迪（操作系统研发工程师）。

英伟达

我在秋招的时候仍然是投了英伟达的实习岗位，其实我只是抱着试一试的心态，无论是学历还是经历，我比起申请的人都差了不少。但是英伟达给了我面试的机会，这个岗位是Software Intern - CUDA Test Development。实际上英伟达的面试能够让我感受到很重要的一点，就是注重对基础的考察，而且在面试过程中与面试官的交流才是最重要的，怎么去解决问题。面试官会和你一起去沟通解决这个问题。

实际上我在面完这个岗，是给我发了拒信的。当时候另外一个实习岗位Software Intern - Autonomous Vehicles给了我面试机会。然而，好巧不巧，HR找到我，说上一个岗位准备给我发offer了（其实是有人鸽了），在确定性和不确定性之间，我选择了确定性的offer。因为已经9月份底了，加上英伟达的光环，我还是非常希望能够转正的，毕竟我没拿到一个大厂的offer（或者说，他们连面试的机会都不愿意给我）。于是我选择放弃了当前的面试，接受了这个offer。实际上目前回想，我不应该做这个选择，我应该坚持我想要的。

正式入职英伟达的时候已经10月中旬了，软件测试的工作说来有趣说来也无趣，公司的同事以及主管都对我很好，英伟达给的福利待遇也很好。我其实已经十分地幸运了，能够拿到这样的实习，能够有转正的机会。这是我敢都不敢想的事情。然而，我的主管很大方地支持我去投内部的秋招，我是非常的感动。而且，实习也会给你自己探索的机会，我就在实习期间写了个python的命令行工具来自动化流程，提升大家的效率。主管还给了我20分钟的时间作汇报，我当时才进组两周左右。

于是乎，我投递了System Software Engineer, SoC - New College Grad的岗位，我为什么想投这个岗位，是因为我内心想做的事情驱动着我。我非常感谢能给我这个面试机会，如果不是因为我能够拿到英伟达实习的机会，我是绝对拿不到秋招的面试机会。面试主要还是问体系结构方面的知识，我最感动的是第一位面试官对我的评价：

从你的身上，我感受到你对技术的热爱与热情。

我从来没有得到过这么高的评价，在我看来，这是对我很高的认可。然后就是二面从1点进行到5点，仍然是我所说的，交流沟通才是最重要的，在会议室和面试官一起在白板上写代码，一起讨论问题。英伟达的面试体验可谓是我面过的公司最好的，二面基本都是4个小时，足以体现对面试者相当高的尊重。

我最终也是幸运地拿到了这份offer，我做梦也不敢想的事情发生到了自己的身上。

感想

我的秋招并不是那么顺利，因为第一学历的限制我几乎没有什么好的选择，加上我学的东西几乎与业务无关（我在整个学生生涯写的web后端还有sql几乎等于没有），我几乎拿不到大厂的offer，如果没有英伟达的offer，我就只能等华为，龙芯还有比亚迪了。

然而，我一直在思考我自己想要的是什么，我前段时间看到的文章每个人每天都只有24小时，希望我的选择真的是我的选择让我深思了不少，正如同文章的题目一样，对自我的叩问才是成长，做什么样的事，成为什么样的人，需要用一辈子的时间去寻找答案。我为什么面试互联网大厂几乎到主管面就不行，我思考过这个问题，是因为我没有态度，我内心其实一直在排斥。如果我去做后台开发自己学的这些底层知识还有什么用。所以我面试的时候很多时候遇到无语的问题，我一般不会反驳，而是说“嗯嗯，你说得对”。

在整个秋招期间，我看到了本硕西电的有些朋友学java能够拿很多大厂的offer，我的内心难免会有嫉妒之情，对自己第一学历被卡的无奈，以及底层知识远离业务的无奈。每当面试官面试的时候问我，你做这个东西有什么意义的时候，我总是无奈一笑，说我挺喜欢做这些没有意义的活。

后面我意识到了不能着急，于是我仍然按照我自己的步骤走，因为学习并行计算，认识到了必须要去深入了内存子系统才能提高程序性能，于是我认真了学习了这两本书（从9月份到现在，实际上正是因为这两本书让我在英伟达秋招的这个岗位占了优势）：

• UNIX systems for modern architectures: symmetric multiprocesssing and caching for kernel programmers.
• A Primer on Memory Consistency and Cache Coherence.

实际上，我觉得人生就应该做一些没有意义的事情。这些没有意义的事情总会在运气到来的时候给予我们或多或少的帮助。在我看来，面试还是运气大于实习，我不喜欢超人的想法，觉得努力就能够有所收获，这是一种傲慢的想法。失去了同理心的想法。我一点也不觉得我能拿到这个offer是我的实力占主要因素，能够得到面试机会的人，没有人实力很差，至少我觉得大家都差不多。

我最后想用《三傻大闹宝莱坞》中的结尾话作为总结：

追求卓越，成功将不期而至。

What I cannot create, I do not understand.

本教程的代码位于topKProblem仓库中。

最经典的Top K问题

最经典的Top K问题忽略任何机器的限制，也就是从一个数组中得到前K大的数。有两种经典的方法：

• 快速选择
• 堆排序

快速选择

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

static int partition(std::vector<int> &data, int start, int end) {
  int pivot = data[end];

  int i = start - 1, j = start;
  while (j < end) {
    if (data[j] > pivot) {
      i++;
      std::swap(data[i], data[j]);
    }
    j++;
  }

  std::swap(data[i + 1], data[end]);
  return i + 1;
}

static int helper(std::vector<int> &data, int k, int start, int end) {
  if (start == end) {
    return start;
  }

  int mid = partition(data, start, end);
  int index = mid - start + 1;

  if (index == k) {
    return mid;
  } else if (index > k) {
    return helper(data, k, start, mid - 1);
  } else {
    return helper(data, k - index, mid + 1, end);
  }
}

std::vector<int> topKUsingPartition(std::vector<int> &data, int k) {
  int index = helper(data, k, 0, data.size() - 1);
  return std::vector<int>{data.cbegin(), data.cbegin() + index + 1};
}

堆排序

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

std::vector<int> topKUsingHeap(const std::vector<int> &data, int k) {
  std::vector<int> ans(k, 0);

  std::priority_queue<int, std::vector<int>, std::greater<int>> heap{};

  for (int i = 0; i < k; i++) {
    heap.push(data[i]);
  }

  for (int i = k; i < data.size(); i++) {
    if (data[i] > heap.top()) {
      heap.pop();
      heap.push(data[i]);
    }
  }

  for (int i = k - 1; i >= 0; i--) {
    ans[i] = heap.top();
    heap.pop();
  }

  return ans;
}

受限环境下的Top K问题

假设我们的机器只有30M的内存，我们希望处理500M的int_32类型的数据，这些数据存储在文件中。我在此处假设k的大小是我们能够接受的，也就是k的大小对于内存而言可以忽略。

此部分的代码可以直接在仓库中查看。

使用堆排序

最简单的方式可能仍然是使用堆排序，因为我们仅仅只需要在内存中维护$O(k)$的大小，对于大文件我们每次只需要读取20M即可，因此内存永远不会超过。然而我们必须思考一个问题，数字是以什么形式保存在文件中。我在这让假设数字都是通过二进制方式的形式存储的，减少分割等操作。

我采取了如下的思路实现，在Linux系统下通过setrlimit限制进程的内存大小，使用c++17的filesystem标准库在临时文件中写入数据，进行操作。

使用快速选择

对于大文件我们每次只需要读取20M即可，然后选择前k大的数。我们就能得到一系列的数组，然后我们直接将数组合并，得到一个新的数组，其大小不可能超过内存，然后再次选择前k大的数，从而得出答案。当然我们也可以使用堆来处理，毕竟这属于一个子问题。

效率对比

执行的结果如下所示：

1
2
3

=== Result
Heap average time: 1.4765 s
Select average time: 1.90026 s

可以看出，使用堆还是要快一些的，这是因为减少了内存的拷贝。

受限条件下基于多线程的快速选择

基于快速选择的方法可以使用多线程进行加速，这是使用堆比不上的优势，现在的处理器基本上都是多核，此处使用多线程进行加速，如何构建多线程是一个问题。首先每个线程即是生产者也是消费者，这样代码写出来就极其的复杂，所以我的一个思路还是确定需要完成的任务数，通过任务数来实现线程之间的同步。

问题变种

所谓的问题变种，无非就是通过哈希得到频率，然后根据频率来得到Top K。没有任何本质的区别。

思考

实践出真知。

源码阅读

MIT6.858提供了基本的文件系统代码，了解这个文件系统是如何构建的，对于代码实现的相当重要。

基本的类型定义

在SUNDR中，有用户和群组的划分。同时每一个文件都是由<principal, i-number>对应的。显然，每个用户和群组都可以有多个文件，所以只需要再定义一个类包含用户（群组）和所有的文件个数。故源代码中定义了三个类型：

• User：继承于Principal。
• Group：继承于Principal。
• I：包含Principal和n。

基本的存储实现

在文件系统中，最基本的存储单元是Block类，其可以存储数据、inode等信息。由于SUNDR基于快照的机制保障安全，故其与git的实现机制相似，基于content-hash机制对每一个Block进行哈希。故Block类提供了两个函数：

• store(blob)：blob是存储的数据，其为二进制数据。其返回值为二进制内容的sha1sum。
• load(chash)：根据哈希值找到相应的block，进而读取block中的二进制数据。

同时，文件系统定义了Inode类，用于作为元数据。其包含了某一个文件或者目录的基本信息，例如类型，创建的时间，修改的时间及其对应的所有的block的哈希值。

1
2
3
4
5
6
7
8

class Inode:
    def __init__(self):
        self.size = 0
        self.kind = 0 # 0 is dir, 1 is file
        self.ex = False
        self.ctime = 0
        self.mtime = 0
        self.blocks = []

显然，Inode类也是存储在block中的，所以我们需要基于ihash通过调用block.load(chash)函数得到其二进制数据，然后进行反序列化得到其字段值。当我们想要获得文件的值时，我们直接使用如下的函数即可：

1
2

def read(self):
    return b"".join([secfs.store.block.load(b) for b in self.blocks])

然而，我们必须考虑目录这种情况。在SUNDR中，目录的每一项元素都是一个元组(filename, I)。其中其定义了add函数来实现在一个目录里面添加一个新项。同时定义了find_under函数用来查找目录。

Itable

每个用户和群组都拥有一个i-table。对于用户而言，i-table保存的是i-number到ihash的映射。对于群组而言，i-table保存的是i-number到I的映射。因此对于Itable类而言，源码利用了python的动态性，直接定义了一个dict。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Itable:
    def __init__(self):
        self.mapping = {}

    def load(ihandle):
        b = secfs.store.block.load(ihandle)
        if b == None:
            return None

        t = Itable()
        t.mapping = pickle.loads(b)
        return t

    def bytes(self):
        return pickle.dumps(self.mapping)

然后，其定义了一个关键的函数resolve，基于i-table解析得到ihash或者I。同时，该函数支持递归地解析I最终得到ihash。其思路实现比较简单。

最关键的在于modmap(mod_as, i, ihash)函数，对于某个用户mod_as而言，给定一个I类，需要修改或者创建其在i-table中的映射。然而关键在于I有两类情况，一种是用户，另一种是群组。

• 对于用户而言，其mod_as和i.p必须相等。我们需要修改或者创建其在i-table中的映射，这个过程相当简单。
• 对于群组而言，情况就会比较复杂了。我们首先需要基于提供的i找到其对应的I，也就是调用resolve函数并进行一层的解析。如果I.p = mod_as，证明群组的修改和用户的修改是一致的，我们一定会最先对用户的修改进行处理，所以此处不需要进行任何操作。如果不是那么证明我们需要创建一个新的I，于是调用modmap(mod_as, I(mod_as), ihash)在mod_as用户的i-table中添加映射。

文件系统API接口

源码已经给出了某些文件系统接口的实现，例如link函数，link函数的作用即将一个I添加到当前目录中，其原理很简单，首先需要基于当前目录构建一个Directory。然后调用add函数添加目录，并使用modmap修改映射关系。

1
2
3
4

# Omit syntax check and write check
def link(def link(link_as: User, i: I, parent_i: I, name: str):
    parent_ihash = secfs.store.tree.add(parent_i, name, i)
    secfs.tables.modmap(link_as, parent_i, parent_ihash))

在SUNDR论文中，文件系统的初始化是root用户生成一对私钥/公钥，同时创建.users和.groups文件，存储相应的公钥及印映射信息。文件系统使用init函数提供了接口。其首先需要创建一个类型为目录的inode，然后添加.和..目录。同时需要创建.users和.groups文件，调用link函数添加到根目录中。

在了解了基本的数据结构以及映射关系后，我们就可以开始编写自己的代码。

实现

实现创建文件和目录的功能

我们需要所做的第一个工作就是实现创建文件和目录。无论是文件还是目录我们都需要首先创建一个Inode。然后我们需要将其存储在文件系统中，并得到其hash值ihash。然后我们需要调用modmap修改itable的映射关系。对于目录而言，我们需要做更多额外的工作。我们需要添加在当前目录创建.和..，并调用modmap修改itable的映射关系。然后我们调用link维护目录结构关系。

然而，我们需要考虑如果是为一个群组创建文件和目录呢？实际上面的流程都是一样的，因为对于群组来说，itable是存储的映射，所以我们仅仅只需要更新这个映射关系即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

def _create(parent_i: I, name: str, create_as: User, create_for: Principal, isdir: bool):
    ...
    ihash = secfs.store.block.store(node.bytes())
    store_i = secfs.tables.modmap(create_as, I(create_for), ihash)

    if isdir:
        new_ihash = secfs.store.tree.add(store_i, b'.', store_i)
        secfs.tables.modmap(create_as, store_i, new_ihash)
        new_ihash = secfs.store.tree.add(store_i, b'..', parent_i)
        secfs.tables.modmap(create_as, store_i, new_ihash)

    if create_for.is_group():
        secfs.tables.modmap(create_as, I(create_for), store_i)

    link(create_as, store_i, parent_i, name)

    return store_i

Version Structure List实现

目前所有的映射关系都是存储在current_table中的，其是存储在内存中的，当有其他客户端时，其访问服务端，得不到current_table的信息，所以需要对current_table进行修改，其需要存储在文件系统中。在这个过程中，我们不考虑任何安全方面的实现。

我们首先需要认识到current_table保存的是Principal到Itable的映射。由于函数resolve以及modmap严重依赖于current_table，所以应该尽可能合理地设计数据结构，减少代码的更改。

在SUNDR原论文中，其提供的数据结构VersionStructure包含每一个用户的i-handle，所属的群组的g-handle以及version_vector。这是与当前的逻辑矛盾的，当前的映射单独保存了用户和群组的，为了简便起见，我没有采取这样的数据结构。我仍然按照当前的逻辑进行实现。因此，我定义了如下的数据结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class VersionStructure:
    """
    `VersionStructure` is the most important data structure in this lab. In
    the original SUNDR paper, the version structure is specified only for
    the `User`. Each user could have one and more group handles. However,
    it's a bad idea for the current code. Because the `current_itables`
    mapping the `I` to the inode. The `I.p` could be user or the group.
    """

    version_vector : dict[Principal, int]
    # It could be the user or the group, it is only the hash, should
    # later read from
    i_handle: str

    def __init__(self):
        self.version_vector = {}
        self.i_handle = ""

根据SUNDR论文，每次每个客户端对文件系统进行操作之间，都需要从服务器下载最新的VSL，当进行了修改需要对VSL进行验证，如果验证通过，则进行数字签名，上传VSL。从性能的角度来说，传递单独的VersionStructure是节省带宽的，然而我认为此处不是这个lab的核心，因此我才用了最粗暴的方式，即上传整个VSL。故定义了如下的数据结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

class VersionStructureList:
    """
    `VersionStructureList` is the core data structure here, It
    contains the the user or the group `VersionStructure`.
    """

    version_structures: dict[Principal, VersionStructure]

    def __init__(self) -> None:
        self.version_structures = {}

    def download(self) -> None:
        """
        Download the `version_structure_list` from the server, it should
        be called every time it operates on the file system. It's may
        be a bad idea, but it is simple.
        """

        global server
        blob = server.read_version_structure_list()

        if blob == None:
            return

        if "data" in blob:
            import base64
            blob = base64.b64decode(blob["data"])

        self.version_structures = pickle.loads(blob)

    def upload(self) -> None:

        global server
        blob = pickle.dumps(self.version_structures)
        server.store_version_structure_list(blob)

我们要在server端添加store_version_structure_listRPC调用，以及read_version_structure_listRPC调用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class SecFSRPC():
    ...
    @Pyro4.expose
    def read_version_structure_list(self):
        chash = self.version_structure_list_hash
        if chash != None and chash in self.blocks:
            return self.blocks[chash]
        return None

    @Pyro4.expose
    def store_version_structure_list(self, blob):
        if "data" in blob:
            import base64
            blob = base64.b64decode(blob["data"])

        import hashlib
        chash = hashlib.sha224(blob).hexdigest()
        self.blocks[chash] = blob
        self.version_structure_list_hash = chash

现在到达了最关键的一步，也就是我们需要修改resolve和modmap中的代码，我们需要替换掉current_table。我们需要一点即可，即VersionStructure存储的是i-handle我们必须进行磁盘的读写，而不是类似源码中直接存储Itable（实际上这一步是可以优化的，如果其i-handle没有发生变化，我们可以实现缓存，而不是从磁盘中实现读写，然而我忽略了因为这并不是这个lab的核心）。

1
2
3
4
5
6
7
8
9
10

def resolve(i: I, resolve_groups = True):
    ...
    global version_structure_list
    if principal not in version_structure_list.version_structures:
        # User does not yet have an itable
        return None

    i_handle = version_structure_list.version_structures[principal].i_handle
    t = Itable.load(i_handle)
    ...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

def modmap(mod_as: User, i: I, ihash) -> I:

    ...
    # find (or create) the principal's itable
    t = None
    global version_structure_list
    if i.p not in version_structure_list.version_structures:
        if i.allocated():
            # this was unexpected;
            # user did not have an itable, but an inumber was given
            raise ReferenceError("itable not available")
        t = Itable()
        version_structure_list.version_structures[i.p] = VersionStructure()
        print("no current list for principal", i.p, "; creating empty table", t.mapping)
    else:
        i_handle = version_structure_list.version_structures[i.p].i_handle
        t = Itable.load(i_handle)

    ...

    i_handle = secfs.store.block.store(t.bytes())
    version_structure_list.version_structures[i.p].i_handle = i_handle

    return i

到了此处，我们就可以通过百分之87的测试。可见，我们已经完成了大部分的工作。剩下的就是实现安全方面的功能，这个lab最难的并不在于代码，而是你如何进行数据结构的设计。

安全方面实现

要实现安全方面就很简单了，需要考虑如下两个（由于时间关系，此处我并没有进行验证）：

1. 验证服务器端的身份
2. 实现SUNDR协议

• blislab

The native implementation

We do not use 2-D array, we flat the array to one dimension. We assume that $A$ is $M \times K$, $B$ is $K \times N$, and $C$ is $M \times N$. We need to implement the $\alpha A \times B + \beta \times C$.

We could calculate the following:

• $C[0] = A[0]B[0] + A[1]B[N] + \cdots + A[K - 1]B[(K - 1)N]$
• $C[1] = A[K]B[1] + A[K + 1]B[N + 1] + \cdots + A[2K - 1]B[(K - 1)N + 1]$

Thus, we could writing the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

class Gemm {
public:
  /**
   * @brief Disable constructor
   *
   */
  Gemm() = delete;

  /**
   * @brief Calculate the GEMM sequentially
   *
   * @details The matrix A, B, C are all one-dimensional array, so the need
   * to find the way to calculate the matrix multiplication.
   *
   */
  static void gemm(int m, int n, int k, double *A, double *B, double *C,
                   double alpha, double beta) {
    for (int i = 0; i < m; i++) {
      for (int j = 0; j < n; j++) {
        double inner_pod = 0;
        for (int kk = 0; kk < k; kk++) {
          inner_pod += A[i * k + kk] * B[kk * n + j];
        }
        C[i * n + j] = alpha * inner_pod + beta * C[i * n + j];
      }
    }
  }
};

void gemm(int m, int n, int k, double *A, double *B, double *C, double alpha,
          double beta) {
  Gemm::gemm(m, n, k, A, B, C, alpha, beta);
}

We assume that $A$ is $1024 \times 1024$ and $B$ is $1024 \times 1024$, we could see that the Intel mkl library would only execute 18ms, the reference implementation would execute 62ms. However, the native implementation executes 5746ms.

Blocked matrix multiplication

The efficiency is low because we do not use the cache. So the idea is use the blocked matrix multiplication thus improving the cache hit rate. The idea is intuitive. If you’are not familiar with the
blocked multiplication, I recommend you to read some materials.

From the below figure, we first need to split the matrix into the blocked matrices. We assume each block would be the $size \times size$. For $A$, we first need to split for the row $M$. And for $B$, we need to split for the col $N$. And for both $A$ and $B$, we could simultaneously handle $K$. However, the trouble is that we need to know each block top-left coordinate, because we need to find the absolute position. So we should define the coordinates for the absolute position.

1
2
3
4
5
6
7
8
9

/**
 * @brief A wrapper to wrap the coordinates for indicating the
 * start left-top point for the current blocked matrix.
 *
 */
struct Point2D {
  int i{}; /**< The absolute i */
  int j{}; /**< The absolute j */
};

So we need to first split for $M$ and for $N$, then for $K$, we could get the following incomplete c++ code:

1
2
3
4
5
6
7

for (int i = 0; i < m; i += size;) {
  for (int j = 0; j < n; j += size;) {
    for (int kk = 0; kk < k; k += size) {
      ...
    }
  }
}

In the first loop, we should set the $A$’s start point of i and we also need to tell whether i + size < m. Similarly, in the second loop, we should set the $B$’s start point of j and we also need to tell whether j + size < n. In the last loop, we should set the $A$’s start point of j and $B$’s start point of i and also need to tell whether k + size < kk.

It’s easy to calculate the start points of $C$. It is dependent on the i and j. Thus we could have the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Point2D a{}, b{}, c{};
const int size = 6;
for (int i = 0; i < m; i += size) {
  int mBlock = i + size < m ? size : m - i;
  a.i = i;
  c.i = i;
  for (int j = 0; j < n; j += size) {
    b.j = j;
    c.j = j;
    int nBlock = j + size < n ? size : n - j;
    for (int kk = 0; kk < k; kk += size) {
      a.j = kk;
      b.i = kk;
      int kBlock = kk + size < k ? size : k - kk;
    }
  }
}

At now, it’s not hard to write the calculate:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

class GemmBlock {
public:
  /**
   * @brief Disable constructor
   *
   */
  GemmBlock() = delete;

  /**
   * @brief Apply the C = beta C, it should be calculated at first.
   *
   */
  static void scalarMultiplication(int mBlock, int nBlock, int n, Point2D &c,
                                   double *C, double beta) {
    for (int i = 0; i < mBlock; i++) {
      for (int j = 0; j < nBlock; j++) {
        C[(i + c.i) * n + (j + c.j)] = beta * C[(i + c.i) * n + (j + c.j)];
      }
    }
  }

  /**
   * @brief Matrix multiplication with block
   *
   * @details In order to implement the block matrix multiplication, we need
   * to calculate the blocked matrix A and blocked matrix B. For example
   * A11 A12  B11 B12  C11 C12
   * A21 A22  B21 B22  C21 C22
   * C11 = A11 X b11 + A12 X B21
   *
   */
  static void matrixMultiplicationBlock(int mBlock, int nBlock, int kBlock,
                                        int n, int k, Point2D &a, Point2D &b,
                                        Point2D &c, double *A, double *B,
                                        double *C, double alpha) {

    for (int i = 0; i < mBlock; i++) {
      for (int j = 0; j < nBlock; j++) {
        double inner_pod = 0;
        for (int kk = 0; kk < kBlock; kk++) {
          inner_pod +=
              A[(i + a.i) * k + (kk + a.j)] * B[(kk + b.i) * n + (j + b.j)];
        }
        C[(i + c.i) * n + (j + c.j)] += alpha * inner_pod;
      }
    }
  }

  /**
   * @brief Split the matrix
   *
   */
  static void gemmUsingBlock(int m, int n, int k, double *A, double *B,
                             double *C, double alpha, double beta) {
    Point2D a{}, b{}, c{};
    const int size = 6;
    for (int i = 0; i < m; i += size) {
      int mBlock = i + size < m ? size : m - i;
      a.i = i;
      c.i = i;
      for (int j = 0; j < n; j += size) {
        b.j = j;
        c.j = j;
        int nBlock = j + size < n ? size : n - j;
        scalarMultiplication(mBlock, nBlock, n, c, C, beta);
        for (int kk = 0; kk < k; kk += size) {
          a.j = kk;
          b.i = kk;
          int kBlock = kk + size < k ? size : k - kk;
          matrixMultiplicationBlock(mBlock, nBlock, kBlock, n, k, a, b, c, A, B,
                                    C, alpha);
        }
      }
    }
  }

  static void gemm(int m, int n, int k, double *A, double *B, double *C,
                   double alpha, double beta) {
    gemmUsingBlock(m, n, k, A, B, C, alpha, beta);
  }
};

Then executing ./gemm 1024. As the result shows, we execute 843ms. It is much better than the native implementation.

Blocked matrix multiplication with memory layout change

We can still improvement the efficiency, we still access the matrix $B$ with col. However, when the matrix size is big, it would cause cache miss. When executing ./gemm 2048. The program would cause 7476ms. This is because the memory layout of $B$ is bad for cache hit. So we could change the layout of $B$.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

class GemmBlockWithMemoryLayoutChange {
public:
  /**
   * @brief Disable constructor
   *
   */
  GemmBlockWithMemoryLayoutChange() = delete;

  static void scalarMultiplication(int mBlock, int nBlock, int n, Point2D &c,
                                   double *C, double beta) {
    for (int i = 0; i < mBlock; i++) {
      for (int j = 0; j < nBlock; j++) {
        C[(i + c.i) * n + (j + c.j)] = beta * C[(i + c.i) * n + (j + c.j)];
      }
    }
  }

  static void matrixMultiplicationBlock(int mBlock, int nBlock, int kBlock,
                                        int n, int k, Point2D &a, Point2D &b,
                                        Point2D &c, double *A, double *B,
                                        double *C, double alpha) {

    for (int i = 0; i < mBlock; i++) {
      for (int j = 0; j < nBlock; j++) {
        double inner_pod = 0;
        for (int kk = 0; kk < kBlock; kk++) {
          inner_pod +=
              A[(i + a.i) * k + (kk + a.j)] * B[(j + b.i) * n + (kk + b.j)];
        }
        C[(i + c.i) * n + (j + c.j)] += alpha * inner_pod;
      }
    }
  }

  static void gemmUsingBlock(int m, int n, int k, double *A, double *B,
                             double *C, double alpha, double beta) {
    Point2D a{}, b{}, c{};
    const int size = 6;
    for (int i = 0; i < m; i += size) {
      int mBlock = i + size < m ? size : m - i;
      a.i = i;
      c.i = i;
      for (int j = 0; j < n; j += size) {
        b.i = j;
        c.j = j;
        int nBlock = j + size < n ? size : n - j;
        scalarMultiplication(mBlock, nBlock, n, c, C, beta);
        for (int kk = 0; kk < k; kk += size) {
          a.j = kk;
          b.j = kk;
          int kBlock = kk + size < k ? size : k - kk;
          matrixMultiplicationBlock(mBlock, nBlock, kBlock, n, k, a, b, c, A, B,
                                    C, alpha);
        }
      }
    }
  }

  static void gemm(int m, int n, int k, double *A, double *B, double *C,
                   double alpha, double beta) {

    double *newB = new double[n * k];

    for (int j = 0; j < n; j++) {
      for (int i = 0; i < k; i++) {
        newB[j * k + i] = B[i * n + j];
      }
    }

    gemmUsingBlock(m, n, k, A, newB, C, alpha, beta);

    delete[] newB;
  }
};

Then executing ./gemm 1024. As the result shows, we execute 478ms. We gain more performance.

Blocking for multiple levels of cache

It’s hard to explain this idea, you should carefully read the blislab tutorial and read the following paper carefully:

• Anatomy of High-Performance Matrix Multiplication

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129

class GemmBlockWithThreeCacheLevel {
public:
  /**
   * @brief Disable constructing this class
   *
   */
  GemmBlockWithThreeCacheLevel() = delete;

  static void matrixMultiplicationBlock(int mBlock, int nBlock, int kBlock,
                                        int n, int k, Point2D &a, Point2D &b,
                                        Point2D &c, double *A, double *B,
                                        double *C, double alpha) {

    for (int i = 0; i < mBlock; i++) {
      for (int j = 0; j < nBlock; j++) {
        double inner_pod = 0;
        for (int kk = 0; kk < kBlock; kk++) {
          inner_pod +=
              A[(i + a.i) * k + (kk + a.j)] * B[(j + b.i) * k + (kk + b.j)];
        }
        C[(i + c.i) * n + (j + c.j)] += alpha * inner_pod;
      }
    }
  }

  /**
   * @brief Use five loop tp calculate the matrix-matrix multiplication, for
   * simplicity here, I only implement C = alpha AB.
   *
   */
  static void gemmUsingBlock(int m, int n, int k, double *A, double *B,
                             double *C, double alpha, double beta) {

    const int sizeN = 4096;
    const int sizeK = 256;
    const int sizeM = 96;

    Point2D a{}, b{}, c{}, ra{}, rb{}, rc{};

    const int rSizeN = 4;
    const int rSizeM = 8;

    // We need to create pack A and pack B. It's a bad idea to allocate
    // memory in the loop.
    double *packedA = new double[sizeM * sizeK];
    double *packedB = new double[sizeN * sizeK];

    for (int j = 0; j < n; j += sizeN) {
      // In this loop, we only handle for the matrix B, it would
      // be split up by `sizeN` for the col.
      b.j = j;
      c.j = j;
      int nBlock = j + sizeN < n ? sizeN : n - j;

      for (int kk = 0; kk < k; kk += sizeK) {
        // In this loop, we handle for the matrix A and matrix B.
        // For the matrix A it would be split up by `sizeK` for the col
        // For the matrix B it would be split up by `sizeK` for the row
        a.j = kk;
        b.i = kk;
        int kBlock = kk + sizeK < k ? sizeK : k - kk;

        // At here, we should pack the B into a consecutive memory, in
        // order to improve the cache hit rate and avoid TLB miss. We make
        // `packedB` into the L3 cache, So the L3 size should be greater
        // than the `sizeN * sizeK`. So in the following `for` loop all
        // the access to the `packedB` would gain great efficiency. And we
        // will convert the row-major to the col-major.

        for (int j_ = 0; j_ < nBlock; j_++) {
          for (int i_ = 0; i_ < kBlock; i_++) {
            packedB[j_ * sizeK + i_] = B[(b.i + i_) * n + (b.j + j_)];
          }
        }

        for (int i = 0; i < m; i += sizeM) {
          // In this loop, we handle for the matrix A, it would be split
          // up by the `sizeI` for the row.
          a.i = i;
          c.i = i;
          int mBlock = i + sizeM < m ? sizeM : m - i;

          // At here, we should pack the A into a consecutive memory, in
          // order to improve the cache hit rate and avoid TLB miss. We
          // make `packedA` into the L2 cache, so the L2 cache must be
          // greater than `sizeM * sizeK`. So the following `for` loop
          // for accessing to the `packedA` would get great efficiency.
          for (int i_ = 0; i_ < mBlock; i_++) {
            for (int j_ = 0; j_ < kBlock; j_++) {
              packedA[i_ * sizeK + j_] = A[(a.i + i_) * k + (a.j + j_)];
            }
          }

          // Here, we already split the matrix A and matrix B into the block.
          // However, we need to split again just like the above, this would
          // be super easy.
          for (int jr = 0; jr < nBlock; jr += rSizeN) {
            int rNBlock = jr + rSizeN < nBlock ? rSizeN : nBlock - jr;
            rb.i = jr;
            rc.j = jr + c.j;

            for (int ri = 0; ri < mBlock; ri += rSizeM) {
              int rMBlock = ri + rSizeM < mBlock ? rSizeM : mBlock - ri;
              ra.i = ri;
              rc.i = ri + c.i;

              for (int internalK = 0; internalK < kBlock; internalK++) {
                ra.j = internalK;
                rb.j = internalK;

                matrixMultiplicationBlock(rMBlock, rNBlock, 1, n, sizeK, ra, rb,
                                          rc, packedA, packedB, C, alpha);
              }
            }
          }
        }
      }
    }

    delete[] packedA;
    delete[] packedB;
  }

  static void gemm(int m, int n, int k, double *A, double *B, double *C,
                   double alpha, double beta) {

    gemmUsingBlock(m, n, k, A, B, C, alpha, beta);
  }
};

缓存一致性问题

假设我们运行一个进程，其有两个线程，一个线程运行在C1，另一个线程运行在C2。从程序员的观点出发，这段代码是相当简单的。然而，我们需要从缓存的角度思考这个问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <thread>
using namespace std;

void C1(int *A) {
  *A = 43;
}

void C2(int *A) {
  while (*A == 42) {
    ;
  }
}

int main(int argc, char *argv[]) {
  int A = 42;
  thread thread1{C1, &A};
  thread thread2{C2, &A};

  thread2.join();
  thread1.join();

  return 0;

}

如下表所示：

• Time 1时刻，对于C1来说，其需要对地址A写入值43，由于缓存未命中，其会将A的值42写入其私有缓存中。对于C2来说，其需要检查地址A的内容，由于缓存未命中，其会将A的值42写入其私有缓存中。(可能读者会想如果采取的write-through策略，C2有可能会读取到43的值，我们在这个例子中忽略这种情况，实际上如果涉及到两个核同时读写，write-through策略也会导致缓存的不一致性)
• Time 2时刻，C2继续进行循环操作，由于其能命中其私有缓存，故其一直会进行死循环，然而实际上A的值应该是43。

从上述的过程可以得出一个重要的结论，多核问题会产生新的缓存不一致问题。由于私有缓存的存在，当某两个私有缓存指向的是同一个物理地址时，需要保持同步，维护一致性。

一致性问题解决通用方法

从上述的例子，我们其实可以很快地可以类比在多线程编程中的读写同步问题。当只读的时候，不存在不一致性问题，问题就在于写入缓存时。在实际的处理器中采用了cache coherence protocol，分为两类：

• Consistency-agnostic coherence：首先需要将写入的这个事件通过缓存中的内部网络传递到其它核，再写入缓存。
• Consistency-directed coherence：先写入缓存，再广播事件，常用于GPGPU。

(Consistency-agnostic)缓存一致性不变量

我们能够确定一个十分明确的不变量，single-writer-multiple-reader(SWMR)，如下图所示，对于任一时刻，对于某一个内存地址来说，其要么有多个核心在执行读操作，要么只有一个核心在进行读写操作。

同时我们还需要确保数据的一致性，内存位置的值与其最后一个读写时期结束时的值相同。因此我们可以明确如下的两个缓存一致性不变量：

1. Single-Writer, Multiple-Read (SWMR) Invariant.
2. Data-Value Invariant.

通用实现方法

我们希望所有CPU的私有缓存以及所有核心共享的末级缓存都能够维持缓存一致性不变量。目前采用的通用方式就是对于每一个私有缓存以及所有核心共享的末级缓存通过添加一个coherence controller状态机来维持这两个不变量。

对于私有缓存的coherence controller，特称为cache controller，其需要处理来自CPU的Load/Store请求，当是Load请求的时候返回相应的数据给CPU。同时其需要发送请求和响应，接收其他controller的请求和响应。对于末级缓存而言，特称为memory controller，其只需要发送请求和响应，接收其他controller的请求和响应。

在后面的所有讨论中，我们都默认cache策略为write-back。

一个简单协议的实现

首先，对于状态机而言，我们必须定义状态以及导致状态变化的事件：

• 对于cache controller的每一个cache block而言，其有三种状态，$\text{I}$(invalid)，$\text{V}$(valid), $\text{IV}^{\text{D}}$。最后一个状态的存在是由于需要从内存里面读取到缓存，我们必须考虑stall的影响。
• 对于memory controller的每一个cache block而言，其只有两种状态，$\text{I}$(invalid)，$\text{V}$(valid)。
  • 当状态为$\text{I}$时，所有的cache controller相对应的cache block状态都为$\text{I}$。
  • 当状态为$\text{V}$时，有且只有一个cache controller对于的cache block状态为$\text{V}$。
• 三类主要事件：
  • Get：请求一个cache block。
  • DateResp：传输cache block里的数据。
  • Put：将cache block里的数据写回内存。

我们可以给出如下图所示的状态转换：

可以发现这个协议的实现效率十分地低，实际上我们完全在多核处理器下实现的串行操作，在使用当某几个核心竞争相同的cache block时，会发生大量的stall，导致性能的降低。

设计缓存一致性协议的通用思路

状态

在多核系统中，缓存的状态定义变得尤为关键，为了提高效率实现共享不能简单地将其状态划分为invalid和valid：

• Validity：一个valid的cache block必须是其包含了最新的数据。
• Dirtiness：Dirtiness一定是暗含了Validity。当cache block的状态发生变化时，其必须把结果写入到内存中。
• Exclusivity：同样Exclusivity一定时暗含了Validity，且其是唯一一个拥有memory block的副本。
• Ownership：是当前memory block的所有者，负责控制其响应和请求。

Stable states

• $\text{M}$(modified)：valid，exclusive，owned and potentially dirty。
• $\text{O}$(owned)：valid，owned，and potentially dirty but not exclusive。对于这种状态而言，cache block仅仅是只读的，其他核心的cache block也可能共享这个数据，但是其并不拥有控制权，所有的请求和响应都需要是$O$的coherence controller来处理。
• $\text{E}$(exclusive)：valid，exclusive，and clean。
• $\text{S}$(shared)：valid but not exclusive，not dirty and not owned。
• $\text{I}$(invalid)：可以理解为Nothing。

Transient states

我们定义如下的规则，对于$\text{XY}^{\text{Z}}$而言，其意味着只有经历完事件$\text{Z}$，才能完成状态$\text{X}$到$\text{Y}$的转换。

Transactions

我们定义如下的transactions:

1. GetShared(GetS)：将block变为$\text{S}$状态。
2. GetModified(GetM)：将block变为$\text{M}$状态。
3. Upgrade(Upg)：将block从$\text{S}$或者$\text{O}$状态变为$\text{M}$状态。
4. PutShared(PutS)：从$\text{S}$状态释放block。
5. PutExclusive(PutE)：从$\text{E}$状态释放block。
6. PutOwned(PutO)：从$\text{O}$状态释放block。
7. PutModified(PutM)：从$\text{M}$状态释放block。

同时我们可以知道CPU会对cache controller发送如下的事件：

1. Load：如果缓存命中了，直接读取，否则执行GetS。
2. Store：如果在$\text{M}$或者$\text{E}$状态下命中了缓存，直接写入缓存，否则执行GetM或者Upg。
3. Atomic read-modify-write：如果在$\text{M}$或者$\text{E}$状态下命中了缓存，直接执行RMW语义，否则执行GetM或者Upg。
4. Instruction fetch：如果缓存命中了，直接读取，否则执行GetS。
5. Replace：执行PutS，PutE，PutO或者PutM。

参考资料

• A Primer on Memory Consistency and Cache Coherence chapter 2 and chapter 6

物理缓存完全采用物理地址作为索引。由于物理地址具有的唯一性，其能够避免歧义和别名问题。如下图所示，首先虚拟地址通过MMU转化为物理地址，然后根据物理地址判断缓存是否命中。

操作系统与物理缓存的交互

由于物理缓存采取物理地址进行索引，无论是共享内存还是独享内存，物理地址的唯一性确保了歧义和别名问题都可以避免。然而，我们还需要关心一下I/O问题。

I/O与总线监听技术

物理缓存基于总线监听技术来保证I/O操作的缓存一致性。如下图所示，总线连接了CPU/MMU/cache，内存以及I/O设备。使得每个设备都能收到其他设备的广播信息。如下图所示，当CPU需要读内存时，其会把物理地址的信息通过总线发送给内存，然后内存会把值发送给CPU。

总线中的数据传递是基于事务的思想实现的，通过一个或者多个总线事务进行传输。每一个总线事务只能够发送一定大小的数据，例如当需要从从磁盘里面读取数据时，会划分为多个总线事务，每个事务都会包含内存地址及数据。所有的设备都可以观察总线上的事务，当物理缓存没有使用总线时，其会监听总线上所有的总线事务(snooping)。

物理缓存会检查每个总线事务的地址，去判断给物理地址是否命中缓存，如果没有命中缓存，我们什么也不需要处理。然而当命中了缓存后，我们就需要思考如何进行处理呢。我们首先考虑write-through策略，当I/O设备需要从这个地址读取内容时，我们不需要采取任何的内容，因为write-through策略保证了缓存和内存的一致性。然而，当I/O设备需要写入内容到该地址时，必须要把对应的物理缓存的cache line的valid位置为0，从而让下次读取时产生cache miss，让CPU从内存中读取数据，保证缓存与内存的一致性。当然，有些实现直接修改cache line的block值。

对于write-back策略，当I/O设备需要从这个地址读取内容时，如果dirty位为0，I/O设备可以直接从内存中读，如果dirty为1，I/O设备直接从cache读取数据，对于I/O设备中这个过程是透明的，I/O设备并不知道它是从内存读还是缓存读的。当I/O设备需要写入内容到该地址时，如果其dirty位为0，缓存可以直接将其valid位置为0。如果正好写入的大小等于cache line，那么我们就可以直接替代cache line的值，然而很有可能写入的大小小于cache line，就需要硬件提供局部写入的机制，因为不能丢失原先已经写入的缓存的信息。

带有键值的虚拟缓存的基本操作

首先是硬件结构的变化，由于需要支持键值，每个cache line的tag都会增加一个进程键值用于区分不同的进程。同时我们需要一个新的寄存器来保存这个进程键值，如下图所示：

带有键值的虚拟缓存除了其加了一个新的键值以外其本质与虚拟缓存的操作没有差别。其仍然通过虚拟地址进行索引，然而由于有额外的键值信息可以判断当前缓存是否属于当前进程。一个美好的愿望是硬件为系统中的每一个进程都生成一个独一无二的标识符，这样我们就不会产生歧义和别名。愿望始终是愿望，硬件能够提供的标识符往往数目很少，有些硬件仅仅支持8个标识符。所以会有某些进程共享同一个标识符，我们仍然会面临虚拟缓存的歧义和别名问题。

操作系统与带有键值的虚拟缓存的交互

上下文切换

当键值充足时，我们可以为每一个在系统中运行的进程分配一个独一无二的键，这样上下文切换的时候，对于write-through而言，我们都不需要刷新缓存，仅仅只需要改变寄存器中的进程键值即可。

当键值不够使用时，操作系统需要重新分配键值。一个常见的思路是换入和换出，我们仍然需要将某个键值换出，然后把所有有关于该键值的缓存进行刷新。对于write-through而言，我们做的操作会比较简单，我们直接可以直接把cache line的valid位置为0。对于write-back而言，我们还需要写入内存。实际上，你会发现，这样也带来了另外的复杂度，操作系统应该换出哪个键呢？

对于采取write-back的写策略，还有一个更加严重的问题。当我们对进程A进行了上下文切换后，其cache line的值可能已经被改变了，然而很有可能另一个进程B会刷新这个cache line，但是对于进程B而言，操作系统并没有进程A的页表信息，操作系统无法知道该写入哪个具体的物理内存。因此，大多数采取带有键值的虚拟缓存会采用write-through策略。

有些硬件提供了额外的机制，既然目前已经有键值信息，就可以把键值信息和页表信息组成一个映射，这样对于上述情况，就能够找到物理地址，从而写入数据。然而，却极大地增加了硬件负担。

共享内存

对于虚拟缓存而言，两个进程之间共享内存会因为上下文切换时自动对缓存进行刷新的机制避免别名问题，然而带有键值的虚拟内存会更加的复杂。

对于直接映射缓存而言，我们假设两个进程的相同的虚拟地址指向相同的物理地址。同时假设操作系统给进程$A$分配的键值为1，给进程$B$分配的键值为2。我们可以明确地知道由于虚拟地址相同，其找到的cache set必然相同，由于每个cache set只有一个cache line。如下图所示，当进程A切换到进程B时，进程B访问该虚拟地址，由于键值不同，会导致cache miss，然后读取相同的物理内存到cache中。然而，物理内存没有发生任何的改变。

然而，大多数情况这两个进程的虚拟地址是不相同的，这样就和虚拟缓存的情况一样了，会产生别名的情况。当我们需要使用共享内存时，cache在一定程度上就失效了。

应用

MMU的一个重要作用就是将虚拟地址转化为物理地址。MMU内部提供了自动将虚拟地址转化为物理地址的机制，操作系统通过构建虚拟地址到物理地址的映射，对于每个进程操作系统都会构建页表的基地址将其放到某个特定的寄存器中。

MMU与操作系统的交互

Sv39 RISC-V只使用虚拟地址的低39位作为索引来翻译物理地址。如下图所示，其使用了三层页表结构来将虚拟地址翻译为物理地址。其转化的过程相当简单，首先通过页表的基地址找到其L2的偏移量，然后读取其值找到二级页表的基地址找到其L1的偏移量，然后这样循环地进行找到物理地址加上虚拟地址中的偏移量即可。

对于操作系统，只需要将页表的基地址放入satp寄存器中即可。硬件会自动完成虚拟地址到物理地址的转换。

TLB

从上述的过程可以得知，既然硬件需要完成虚拟地址到物理地址，我们已经讲述过的虚拟缓存是不是完美符合这个需求的。现有的MMU都有一小块虚拟缓存，即TLB。TLB保存的缓存信息即为虚拟地址对应的物理地址以及页属性。由于不同进程的页表不同，其虚拟地址对应的物理地址也必然不同：

• 对于虚拟缓存来说，每次进行上下文切换都需要将对应的cache line valid位置0。
• 对于带有键值的虚拟缓存来说，由于其键值存在，不需要每次上下文切换刷新TLB，当键值不够分配时，才需要将对应的cache line valid位置0。

TLB是最适合使用虚拟缓存的，这是因为TLB是一个只读缓存且没有共享内存机制。

基于物理标签的虚拟缓存

虚拟缓存最重要的一个问题在于虚拟地址与物理地址的映射问题，虚拟地址是操作系统与硬件结合起来给进程提供的抽象，其映射关系会随着上下文切换发生改变，从而造成了别名和歧义问题。于是就提出了另一种类型的虚拟缓存，我们仍然使用虚拟缓存对cache se定位，同时找寻block offset。但是缓存中的tag使用物理地址。然而，这样我们不得不增加新的负担，也就是我们必须用通过MMU将虚拟地址转化为物理地址。

参考资料

• UNIX Systems for Modern Architectures Chapter 4
• UNIX Systems for Modern Architectures Chapter 5
• Cache 组织方式
• TLB原理

虚拟缓存的基本操作

无论如何，我们也只能有两种基本的操作，要么读要么写。当我们去读一个虚拟地址其内存值的时候，我们仍然按照相同的操作去查询缓存是否命中，如果缓存命中了，直接返回缓存值即可。如果缓存没有命中，我们需要先把虚拟地址通过MMU转化为物理地址，然后从内存中读取数据，并加载到缓存中。

写的问题就更加复杂了，由于写的策略有两种write-through和write-back（我们假设其都支持write-allocate）。我们需要考虑在这两种策略下，虚拟缓存是如何进行写的操作的。对于write-through，无论是命中了cache还是没有命中cache，其都需要把虚拟地址通过MMU转化为物理地址，然后写入内存。对于没有命中cache的情况，其会直接读取内存的值写入cache中。对于write-back而言，对于没有命中cache的情况，其和write-through是相似的，对于命中了cache的情况，我们只需要在cache中写入即可。

你可能会发现，除了我们需要读取内存的时候要把虚拟地址转化为物理地址的情况，虚拟缓存似乎也没有什么本质改变。然而，我们必须得思考一个问题，就是读写权限的问题。

• 缓存读的虚拟地址对应的物理地址实际上已经变得无法读取了，然而缓存并不知道这个信息，如果我们仍然访问这个虚拟地址，缓存会直接给CPU返回其保存的值，显然我们需要判断这个物理地址是否可读。
• 同理，缓存写的虚拟地址对应的物理地址也可能变得无法写入了。对于cache miss的情况，我们能够轻易地进行判断，因为我们会把虚拟地址通过MMU转化为物理地址，可以判断这个物理地址是否可写。对于cache hit的情况，如果其dirty flag已经是1，我们显然可以得知这个虚拟地址对应的物理地址是可写的。麻烦的情况在于dirty flag为0，我们必须知道其到底是否可写，所以我们需要把虚拟地址转化为物理地址去判断这个地址是否可写。

歧义(Ambiguity)与别名(Alias)

歧义

我们首先回忆一下操作系统是如何与硬件结合实现虚拟地址转化到物理地址。对于每一个进程，操作系统需要维持一个页表，这个页表包含了从虚拟地址到物理地址的映射，操作系统分配内存时，会自动从空闲的内存中分配页然后修改页表，然后按照硬件规则完成虚拟地址到物理地址的映射。也就是对于两个不同的进程，其相同的虚拟地址完全可以对应不同的物理地址。当操作系统对进程进行调度后，由于我们是按照虚拟地址进行缓存的映射，虚拟缓存无法意识到这个物理地址已经改变了。因此，操作系统在此时必须做一些事情来刷新缓存。

别名

进程间的通信有一个重要的方法就是共享内存，即不同的虚拟地址能够映射到同一个物理地址。然而，由于两个进程的虚拟地址不同，其对应的cache set也会不同，假设采取的策略为write-back，当某一个进程修改了共享内存，其只会改变与其对应的cache line的值，却不会改变另一个进程的cache line的值，进而导致不一致问题。

操作系统与虚拟缓存的交互

由于歧义和别名问题，在许多场景下，操作系统必须要采取一些策略来保证缓存的一致性。

上下文切换

当发生上下文切换时，一个虚拟地址可能会映射到另一个物理地址，此时虚拟缓存就应该失效了。所以内核会强制刷新所有当前进程的缓存。对于只进行了读操作的cache line，我们只需要让这个cache line的valid位置为0。对于进行了写的操作，如果其策略为write-through，其操作也很简单，将valid位置为0，然而如果写策略为write-back，我们需要把每一个改变了的cache line重新写入内存，会花费大量的时间。

除此之外，如果上下文切换相当地频繁，缓存的命中率会急剧地下降。因此，虚拟缓存最合适的场景是计算型任务以及批处理任务。减少了虚拟地址转化为物理地址的损耗，同时避免上下文切换带来的性能损耗。

共享内存

对于两个进程使用共享内存的情况，是不存在别名问题的，因为上下文切换时会自动解决这个问题。然而，麻烦的在于可能存在同一个进程两个不同的虚拟地址映射到同一块共享内存，这样就导致了别名问题。一个很简单的解决方法就是不使用cache。

I/O

对于buffered IO而言，由于操作系统管理的内核使用统一的虚拟地址，其不会存在歧义和别名问题。然而，最大的问题在于DMA设备，由于DMA设备直接与内存交互，会导致缓存与内存的不一致问题，即unbuffered I/O。

当用户采用系统调用write时，且缓存写策略为write-back时，不会直接把修改的数据写入到内存中，如果此时DMA设备读取相关的数据，就会导致不一致性问题。所以当DMA设备需要读取数据时，操作系统应强制刷新缓存。如果采用阻塞I/O，当执行write或者read系统调用时，操作系统本身就会进行上下文的切换，对缓存进行刷新。

参考资料

• UNIX Systems for Modern Architectures Chapter 3
• Cache 组织方式

缓存的目的在于减少CPU直接从内存中读取数据的次数。缓存是静态存储器，其不需要对电容进行刷新的性质决定了其访问速度必然快于动态存储器（内存）。如何构建内存与缓存之间的映射关系是缓存的一个最重要的基础知识。对于开发者来说，缓存的存在是透明的。然而，当编写高性能计算或者多线程的程序时，我们不能忽视缓存这个在计算机体系结构中起到重要作用的部件。

我们假定某个计算机支持$m$位的内存地址。显然，常见的$m$为32位或者64位。如下图所示，缓存是由多个cache set组成的，每个cache set由多个cache line组成，同时每一个cache line包含一个cache block。我们定义如下的符号含义：

• $S$：cache set的数目。
• $E$: 每一个cache set所包含的cache line的数目。
• $B$: 每一个cache line所包含的cache block的总字节。

我们需要根据当前的内存地址，首先定位到cache set，由于cache set的数目为$S$，故我们需要$s$位数来定位到某个cache set（显然，$2^{s} = S$）。同时，我们需要$b$位数来定位到cache block的偏移量（显然，$2^{b} = B$）。此时，我们还有一个问题没有解决，我们仍然需要判断其位于哪个cache line中。我们在前两个过程中已经使用了$s + b$位，故我们可以使用剩下的$t = m - (s + b)$位来去定位cache line。然而，目前的缓存组织结构中并不存在这个信息，所以我们需要在缓存中添加。同时，我们在cache line中添加一个标志位，判断当前cache line是否有效，如下图所示`

直接映射缓存(Direct-Mapped caches)

当$E = 1$时，就被称为直接映射缓存，其原理就相当简单了。由于每一个cache set只包含一个cache line，所以每一个地址有且只能有一个cache line与之对应。然而，这样在某些情况下会带来很大的性能问题。举个例子，如下面的代码所示，我们循环地依次在地址$A$和地址$B$中写入数据。恰好不好，地址$A$的地址$B$的$s$是一致的。显然，他们会访问到同一个cache set，由于只有一个cache line，每次其对比tag值都不相同，故缓存硬件会从内存中读取相应的数据放到cache line中，导致每次cache line中的数据都会被刷新，也就是一直cache miss。这种现象被称为cache颠簸（cache thrashing）。

1
2
3
4
5
6

int main(int argc, char *argv[]) {
  while (true) {
    *A = computeA();
    *B = computeB();
  }
}

组相连缓存(Set Associative Caches)

为了解决上述问题，每一个cache set可以含有多个cache line，假如$E = 2$，对于上述例子而言，硬件会寻找两个cache line的tag值是否与物理地址的tag相等，这样就在一定程度上可以缓解cache颠簸。然而，这样也带了另一个问题，如果没有一个cache line与之对应，产生了cache miss。那么缓存必须换出一个cache line（如果有空的cache line，当然就直接使用了）。显然，这就回到了常见的换入换出策略了，例如LRU或者LFU。

全相连缓存

当$S = 1$时，即只存在一个cache set时，我们直接舍弃了$s$。然而，我们增大了寻找cache line的成本，意味着需要遍历来找到我们所需的cache line，如果是cache miss的情况，我们甚至需要遍历所有的cache line。当然，硬件可能提供一些并行来加快速度，然而由于极高的硬件成本，采用率极少。

缓存写策略

• write-through: 同时写入缓存和内存。其优势在于能够始终保持内存和缓存的一致性，劣势在于每次写CPU都会调用一次写内存操作，浪费时钟。
• write-back: 先写入缓存，后面再写入内存。每个cache line中会有一个bit位记录数据是否被修改过，称之为dirty bit。优势在于避免了写内存操作，然而劣势在于需要处理不一致性。

write-allocate

当使用write-back时，write-allocate通常一起被使用，CPU将数据写入内存的情况，如果缓存未命中其总是被写入缓存中。

参考资料

• Cache的基本原理
• CSAPP Chapter 6
• UNIX Systems for Modern Architectures Chapter 2

Before we use openMP to parallelize the code. We just first write the serial form. It is easy.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

void pageRank(Graph g, double* solution, double damping, double convergence) {

  int numNodes = num_nodes(g);
  double equal_prob = 1.0 / numNodes;
  for (int i = 0; i < numNodes; ++i) {
    solution[i] = equal_prob;
  }

  double* tempArray = new double[g->num_nodes];

  bool converged = false;
  while (!converged) {
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      tempArray[v] = 0.0;
    }
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      for (const Vertex* iv = incoming_begin(g, v); iv != incoming_end(g, v); ++iv) {
        tempArray[v] += solution[*iv] / static_cast<double>(outgoing_size(g, *iv));
      }
    }
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      tempArray[v] = tempArray[v] * damping + (1.0 - damping) / static_cast<double>(numNodes);
    }

    double t = 0.0;
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      if(outgoing_size(g, v) == 0) {
          t += damping * solution[v] / static_cast<double>(numNodes);
      }
    }

    for (Vertex v = 0; v < g->num_nodes; ++v) {
      tempArray[v] += t;
    }

    double globalDiff = 0.0;
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      globalDiff += abs(tempArray[v] - solution[v]);
    }
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      solution[v] = tempArray[v];
    }
    converged = globalDiff < convergence;
  }

  delete[] tempArray;
}

Now we can use openMP to parallelize the code above.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

void pageRank(Graph g, double* solution, double damping, double convergence) {

  int numNodes = num_nodes(g);
  double equal_prob = 1.0 / numNodes;
  #pragma omp parallel for
  for (int i = 0; i < numNodes; ++i) {
    solution[i] = equal_prob;
  }

  double* tempArray = new double[g->num_nodes];

  bool converged = false;
  while (!converged) {
    #pragma omp parallel for default(none) shared(tempArray, g)
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      tempArray[v] = 0.0;
    }

    #pragma omp parallel for default(none) shared(tempArray, g, solution)
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      for (const Vertex* iv = incoming_begin(g, v); iv != incoming_end(g, v); ++iv) {
        tempArray[v] += solution[*iv] / static_cast<double>(outgoing_size(g, *iv));
      }
    }

    #pragma omp parallel for default(none) shared(tempArray, g, damping, numNodes)
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      tempArray[v] = tempArray[v] * damping + (1.0 - damping) / static_cast<double>(numNodes);
    }

    double t = 0.0;
    #pragma omp parallel for default(none) reduction(+: t) shared(solution, g, numNodes, damping)
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      if(outgoing_size(g, v) == 0) {
        t += damping * solution[v] / static_cast<double>(numNodes);
      }
    }

    #pragma omp parallel for default(none) shared(tempArray, g, t)
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      tempArray[v] += t;
    }

    double globalDiff = 0.0;
    #pragma omp parallel for default(none) reduction(+: globalDiff) shared(tempArray, solution, g)
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      globalDiff += abs(tempArray[v] - solution[v]);
    }

    #pragma omp parallel for default(none) shared(tempArray, solution, g)
    for (Vertex v = 0; v < g->num_nodes; ++v) {
      solution[v] = tempArray[v];
    }
    converged = globalDiff < convergence;
  }

  delete[] tempArray;
}

Part 2

Top Down BFS

The easiest idea for implementing top-down bfs is to use two variables, one is for the current frontier, and another is for the next frontier. And when we add the new node to the next frontier, we should use #pragma omp critical to protect the next frontier. However, this method is too slow.

However, we could let each thread use its local next frontier. Thus we could avoid critical section and make the code faster.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

void top_down_step(
    Graph g,
    vertex_set* frontier,
    vertex_set* localList,
    int* count,
    int* distances)
{
    #pragma omp parallel for
    for (int i=0; i<frontier->count; i++) {

        int node = frontier->vertices[i];

        int start_edge = g->outgoing_starts[node];
        int end_edge = (node == g->num_nodes - 1)
                           ? g->num_edges
                           : g->outgoing_starts[node + 1];

        // attempt to add all neighbors to the new frontier
        for (int neighbor=start_edge; neighbor<end_edge; neighbor++) {
            int outgoing = g->outgoing_edges[neighbor];
            if (distances[outgoing] == NOT_VISITED_MARKER &&
            __sync_bool_compare_and_swap(&distances[outgoing], NOT_VISITED_MARKER, distances[node] + 1)) {
                  int index = localList[omp_get_thread_num()].count++;
                  localList[omp_get_thread_num()].vertices[index] = outgoing;
            }
        }
    }

    int totalCount = 0;
    for (int i = 0; i < omp_get_max_threads(); ++i) {
      count[i] = totalCount;
      totalCount += localList[i].count;
    }
    frontier->count = totalCount;

    // Parallel copy the data from `localList` to `frontier`
    #pragma omp parallel for
    for (int i = 0; i < omp_get_max_threads(); ++i) {
        memcpy(frontier->vertices + count[i], localList[i].vertices,
                localList[i].count * sizeof(int));
    }
}

Bottom Up BFS

The Top Down BFS is an easy job to do actually. Because it is a prior algorithm. However, in the code, we would do many logical operations especially the frontier size is large and its ancestors’ size is small. Look at the following code snippet, which would cause so many logical operations.

1
2
3
4
5

if (distances[outgoing] == NOT_VISITED_MARKER &&
  __sync_bool_compare_and_swap(&distances[outgoing], NOT_VISITED_MARKER, distances[node] + 1)) {
    int index = localList[omp_get_thread_num()].count++;
    localList[omp_get_thread_num()].vertices[index] = outgoing;
}

Well, I cannot understand the principle of Bottom Up BFS. So I decide to read an essay which is called Direction-optimizing breadth-first-search.

I think the paper is enough. So I omit detail here. You should carefully read the paper. And I record some information here.

The majority of the computational work in BFS is checking edges of the frontier to see if the endpoint has been visited. The total number of edge checks in the conventional top-down algorithm is equal to the number of edges in the connected component containing the source vertex, as on each step every edge in the frontier is checked.

Well, at now the bottom-up way is clear. For every step, we just traverse all the vertices. And we have the current frontier information. From Top Down BFS, we need to check for every vertex’s neighbor to add it to the next_frontier. In the Bottom Up BFS, we just find whether the child is the ancestor of the vertices in the frontier. Thus every child would only can be visited once.

Now we can code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

uint bottom_up_step(Graph g, bool* frontier, bool* new_frontier, int* distances) {
    uint count = 0;
    #pragma omp parallel for reduction(+: count)
    for (int i = 0; i < g->num_nodes; ++i) {
        if (distances[i] == NOT_VISITED_MARKER) {
            for (const Vertex* incoming = incoming_begin(g, i); incoming != incoming_end(g, i); ++incoming) {
                if (frontier[*incoming]) {
                    distances[i] = distances[*incoming] + 1;
                    new_frontier[i] = true;
                    count += 1;
                    break;
                }
            }
        }
    }
    return count;
}

void bfs_bottom_up(Graph graph, solution* sol)
{

    bool *frontier = new bool[graph->num_nodes];
    bool *new_frontier = new bool[graph->num_nodes];

    bool *current = frontier;
    bool *next = new_frontier;

    #pragma omp parallel for
    for (int i = 0; i < graph->num_nodes; ++i) {
        current[i] = false;
    }

    // Set for the root node
    current[ROOT_NODE_ID] = true;

    #pragma omp parallel for
    // initialize all nodes to NOT_VISITED
    for (int i=0; i<graph->num_nodes; i++)
        sol->distances[i] = NOT_VISITED_MARKER;
    sol->distances[ROOT_NODE_ID] = 0;

    uint count = 1;

    while (count != 0) {

        #pragma omp parallel for
        for (int i = 0; i < graph->num_nodes; ++i) {
            next[i] = false;
        }

        count = bottom_up_step(graph, current, next, sol->distances);

        // Swap the pointer
        bool * temp = next;
        next = current;
        current = temp;

    }
    delete[] frontier;
    delete[] new_frontier;
}

However, the result is illustrated below.

As you can see, I cannot get the full grades. I am wondering the reason. You could look at this article.

And the article provides some tips:

• Avoid writing to global data that is accessed from multiple threads.
• Align shared global data to cache line boundaries.
• Don’t store temporary, thread specific data in an array indexed by th thread id or rank.
• When parallelizing an algorithm, partition data sets along cache lines, not across cache lines.

The last tip is what we could do. So we could use schedule(dynamic, chunk_size) for openMP to improve efficiency.

Hybrid BFS

The pairing of the top-down approach with the bottom-up approach is complementary, since when the frontier is its largest, the bottom-up approach will be at its best whereas the top-down approach will be at its worst, and vice versa.

So the idea is simple. Uses the Top Down BFS for steps when the frontier is large. We begin each search with the Top Down BFS and continue until the frontier becomes too large, at which point we switch to the Bottom Up BFS.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

void bfs_hybrid(Graph graph, solution* sol)
{
    // A flag
    bool isUpDownBFS = true;
    bool switchFlag = true;

    // Set up for Bottom Up BFS
    int chunk_size = MACHINE_CACHE_LINE_SIZE * 16;
    while (graph->num_nodes < omp_get_max_threads() * chunk_size) {
        chunk_size /= 2;
    }
    bool *frontier_bottom_up_bfs = new bool[graph->num_nodes];
    bool *new_frontier_bottom_up_bfs = new bool[graph->num_nodes];
    bool *current = frontier_bottom_up_bfs;
    bool *next = new_frontier_bottom_up_bfs;
    #pragma omp parallel for
    for (int i = 0; i < graph->num_nodes; ++i) {
        current[i] = false;
    }
    current[ROOT_NODE_ID] = true;

    // Set up for Top Down BFS
    vertex_set list;
    vertex_set_init(&list, graph->num_nodes);
    int maxThreadNum = omp_get_max_threads();
    vertex_set localList[maxThreadNum];
    #pragma omp parallel for
    for(int i = 0; i < maxThreadNum; ++i) {
        vertex_set_init(&localList[i], graph->num_nodes);
    }
    int count[maxThreadNum];
    vertex_set* frontier_top_down_bfs = &list;
    frontier_top_down_bfs->vertices[frontier_top_down_bfs->count++] = ROOT_NODE_ID;

    // Global configuration
    #pragma omp parallel for
    // initialize all nodes to NOT_VISITED
    for (int i=0; i<graph->num_nodes; i++)
        sol->distances[i] = NOT_VISITED_MARKER;
    sol->distances[ROOT_NODE_ID] = 0;

    uint frontier_length = 1;

    while (frontier_length != 0) {
        if (isUpDownBFS) {
            // We come from Bottom Up BFS
            if (!switchFlag) {
                #pragma omp parallel for
                for (int i = 0; i < maxThreadNum; ++i) {
                    vertex_set_clear(&localList[i]);
                }
                // We need to copy the information from `current`
                // to the `frontier_top_down, it is trivial.
                #pragma omp parallel for
                for (int i = 0; i < graph->num_nodes; ++i) {
                    if (current[i]) {
                        int index = localList[omp_get_thread_num()].count++;
                        localList[omp_get_thread_num()].vertices[index] = i;
                    }
                }
                int totalCount = 0;
                for (int i = 0; i < omp_get_max_threads(); ++i) {
                    count[i] = totalCount;
                    totalCount += localList[i].count;
                }
                frontier_top_down_bfs->count = totalCount;
                #pragma omp parallel for
                for (int i = 0; i < omp_get_max_threads(); ++i) {
                    memcpy(frontier_top_down_bfs->vertices + count[i], localList[i].vertices,
                    localList[i].count * sizeof(int));
                }
                switchFlag = true;
            }

            #pragma omp parallel for
            for (int i = 0; i < maxThreadNum; ++i) {
                vertex_set_clear(&localList[i]);
            }
            top_down_step(graph, frontier_top_down_bfs, localList, count, sol->distances);
            frontier_length = frontier_top_down_bfs->count;
            if (frontier_length != 0 && graph->num_nodes / frontier_length< UP_THRESHOLD) {
              isUpDownBFS = false;
            }
        } else {
            // We come from Top Down BFS
            if (switchFlag) {
                // We should first clear the `current` because it has
                // some dirty data.
                #pragma omp parallel for
                for (int i = 0; i < graph->num_nodes; ++i) {
                    current[i] = false;
                }
                // Transfer the information from `frontier_top_down_bfs` to
                // `current`. It is easy for converting from Top Down BFS to
                // Bottom Up BFS
                #pragma omp parallel for
                for (int i = 0; i < frontier_top_down_bfs->count; ++i) {
                    current[frontier_top_down_bfs->vertices[i]] = true;
                }
                switchFlag = false;
            }
            #pragma omp parallel for
            for (int i = 0; i < graph->num_nodes; ++i) {
                next[i] = false;
            }
            frontier_length = bottom_up_step(graph, current, next, sol->distances, chunk_size);
            bool * temp = next;
            next = current;
            current = temp;
            if (frontier_length != 0 && graph->num_nodes / frontier_length > BOTTOM_THRESHOLD ) {
              isUpDownBFS = true;
            }
        }

    }
    delete[] frontier_bottom_up_bfs;
    delete[] new_frontier_bottom_up_bfs;
}

The result is illustrated in the following figure.

Question 1

As you can see, due to the parallelism of the GPU, the bandwidth is huge.

Question 2

From the results, we can get that the bottleneck is the memory and CPU of the host itself. For the execution time of the kernel, the speed is very fast. However, the speed is low for copying the host memory into the device memory and vice versa.

Part 2

First, we need to implement the parallelism form of scan. The algorithm is super wonderful. You should first understand the algorithm.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

void exclusive_scan_iterative(int* start, int* end, int* output) {

    int N = end - start;
    memmove(output, start, N*sizeof(int));

    // upsweep phase
    for (int two_d = 1; two_d <= N/2; two_d*=2) {
        int two_dplus1 = 2*two_d;
        parallel_for (int i = 0; i < N; i += two_dplus1) {
            output[i+two_dplus1-1] += output[i+two_d-1];
        }
    }

    output[N-1] = 0;

    // downsweep phase
    for (int two_d = N/2; two_d >= 1; two_d /= 2) {
        int two_dplus1 = 2*two_d;
        parallel_for (int i = 0; i < N; i += two_dplus1) {
            int t = output[i+two_d-1];
            output[i+two_d-1] = output[i+two_dplus1-1];
            output[i+two_dplus1-1] += t;
        }
    }
}

It may seem that we need N threads for every inner loop, however, this is a stupid idea, we should calculate how many threads we need for each inner loop.

Part 3

Before diving into how to write a render using CUDA. We first think about how to implement a render with cpp. And after that, you need to read the code written with CUDA.

First Implementation

For the first implementation, I focus on how to write the correct code. The hint part exclusive_scan has made me think we could first store the circle render parameters for each pixel. Thus we can scan the circle render parameters for each pixel.

Thus, we can solve the two important questions:

• Atomicity: we have made the memory independent for each pixel. So we can write whatever we want without any synchronization and mutation.
• Order: We have make an explicit array of render parameters. So the order doesn’t matter.

So, We first need to construct an array to hold the render parameters for each pixel.

1

cudaMalloc(&cudaDevicePixelData, image->width * image->height * numCircles * 4 * sizeof(float));

Now, we first write the render information for every pixel. The core code is below:

1
2
3
4
5
6
7
8
9

int pixelPtrStart = 4 * cuConstRendererParams.numCircles * (pixelY * imageWidth + pixelX) + 4 * circleIndex;
float4* pixelPtr = (float4*)(&cuConstRendererParams.pixelData[pixelPtrStart]);
float4 color;
color.x = rgb.x;
color.y = rgb.y;
color.z = rgb.z;
color.w = alpha;

*pixelPtr = color;

Then we can launch a new kernel to calculate for each pixel:

1
2
3
4
5
6
7
8

for (int i = 0; i < numCircles; ++i) {
    float4* pixelPtr = (float4*)(&cuConstRendererParams.pixelData[startIndex + i * 4]);
    color.x = (*pixelPtr).w * (*pixelPtr).x + (1 - (*pixelPtr).w) * color.x;
    color.y = (*pixelPtr).w * (*pixelPtr).y + (1 - (*pixelPtr).w) * color.y;
    color.z = (*pixelPtr).w * (*pixelPtr).z + (1 - (*pixelPtr).w) * color.z;
    color.w += (*pixelPtr).w;
  }
  *imagePtr = color;

However, cudaDevicePixelData is too big, which will consume so much memory, which would exceed the maximum memory 16GB. So we need to reuse the render information. We should not store the information for every pixel. Because the render information of each circle is deterministic. But the things we need to make sure is that whether the circle has contributed to the pixel. So instead of storing the render information for each pixel, we could just use bit mask to indicate whether the circle has contributed to the pixel.

Now, the result is illustrated by below.

As you can see, we have passed some tests and the performance is not good at all. The reason why there are some failed tests is that the bytes exceed $2^{63}$, which would overflow.

Best practice

We should use a clever way to solve this problem. The problem is a two-dimensional problem. So we’d better design the grid and block for two dimensions, as the following figures illustrates:

From the above figures, we could write the following code to initialize the grid and block size:

1
2
3
4
5
6
7

void CudaRenderer::render() {
  int block_x = 16, block_y = 32;
  dim3 blockDim(block_x, block_y);
  int grid_x = (image->width + blockDim.x - 1) / blockDim.x;
  int grid_y = (image->height + blockDim.y - 1) / blockDim.y;
  dim3 gridDim(grid_x, grid_y);
}

And we should render a block each time, we have already split the pixels into the block. For each block, we should handle the each pixel, we could calculate the current pixel’s x coordinate and y coordinate and the current thread id:

1
2
3

int thread_id = threadIdx.y * blockDim.x + threadId.x;
int pixel_index_x = blockId.x * blockDim.x + threadId.x;
int pixel_index_y = blockId.y * blockDim.y + threadId.y;

So what a thread should do? We have already mapped a pixel $(x, y)$ with a specified thread. So the idea should be simple enough.

• We could traverse sequentially all the circles to tell whether the circle has contributed to this pixel, and we calculate to achieve rendering.

However, this way is too slow. For every pixel, we could calculate a lot of useless calculation. For example, if there are total 100,000,000 circles, there would be many useless circles for this pixel. So we should find a way to find the circles in the current block. So we could use a shared memory (a bit map) to know whether the BLOCK size circle has contributed to the block. So for each pixel (each thread) we could calculate ONLY one circle to know whether it has contributed to this block. And for each pixel, we could use the contributed circles to sequentially achieve rendering.

Look at what parallelism we have done:

• Each pixel renders itself using two-dimension task split.
• Each pixel handles 1 circle to tell whether it contributes to the current block for $num_{circles} / size_{block}$ loops.

It’s a really hard question, but it is very useful.

故事的整体背景实际上是非常好理解的，伴随着整个国家牢狱、下层和上层的划分，人物的阶级属性也就十分鲜明了。整个故事的剧情是线性的，与许多感想讨论的最终章的电车理论相比，我个人将这部作品的基调定为对存在、虚无和荒诞的思考。实际上，我个人认为这部作品对于脚本家想表达的核心就是对存在的思考。然而，GalGame终究是GalGame，本作品在一些章节中考虑的东西过于幼稚，这也是没有办法的事情。然而，我认为这部作品成功的原因就是把其思考的问题贯穿到了整部作品中。

菲奥奈

菲奥奈篇可谓是本部作品中剧情和人物塑造最好的一个篇章。本篇章的开始即交代了当前的背景，不蚀金锁成为了目前牢狱的实质管辖人，由于黑羽的出现扰乱了牢狱本身的秩序，导致了防疫局和不蚀金锁进行合作（实际上，这一幕远没有这么简单，这个时候就已经为下一章的内容进行了铺垫）。菲奥奈作为防疫局队长，刚正不阿，为人正直，无不体现其正义性。菲奥奈深知工作不得牢狱人民的人心，但身怀荣耀，坚信自己的意志。然而，她拥有的是抽象的正义。她并不理解牢狱的人往往没有选择。但是，我认为她是明白这个世界的道理的，只是她也在挣扎。

在后续的剧情中，逐渐地揭示了菲奥奈的理念来源：

• 集体荣誉感。
• 恩赐之剑：家族荣耀，父亲清廉的象征。
• 父亲也得了羽化病，然而父亲支持他们的工作，父亲是她公正信念的又一来源。
• 进入防疫局的原因就是因为哥哥，认为防疫局的工作就是命运。

然而，在追捕黑羽的过程中，其依赖的东西接而破碎。首先是团队内部的叛徒破坏了团队内部保护羽化病人的信念，反而借黑羽的名杀戮羽化病人。其次是意识到了黑羽可能是自己的哥哥，对自己和男主之间进行的交易感到痛恨。再而是明白了防疫局的真相，防疫局从来不保护羽化病人，而是对这些羽化病人进行惨无人道的人体实验。在我个人看来，菲奥奈的信念已然崩塌。就如同“大崩落”一样，将菲奥奈奋斗至今的意义全部抹杀。其开始怀疑其自身存在的价值。

在这个篇章中，玩家有一个最重要的选择：

1. 不能让菲奥奈的双手染上亲人的鲜血
2. 应该让菲奥奈来做决定

如果这不是游戏，我们会做什么选择了，如果是以理性的角度来讨论这个问题，我们都应该选择第二个选项。因为这涉及到了菲奥奈自身的存在。值得玩味的是，如果选择了第一个选项，菲奥奈就会依赖男主，得到小小的幸福。我从来不认为小小的幸福就不是一个好的选择。而是，菲奥奈应该去寻找自己的意义。她已然虚无，自己的信念全部被打碎了。最后，菲奥奈哥哥给了他的忠告，告诉其应该关注具体的正义：

剑的正义会随着挥剑之人而改变

你要役剑

绝对不要为剑所役

你不要被家族之名束缚地活下去

用自己的双眼看透何为正义

在最后的剧情中，男主选择通过另一种方式告诉了菲奥奈要去寻找自身的意义。实际上我认为这部分能够写的更有深度的。但是，在我看来这个篇章描述了一个很重要的问题，菲奥奈的抽象正义从何而来，当其破碎了，她又该怎么走向存在呢？还是走向荒诞呢？

艾莉丝

个人认为这个篇章极其地鬼畜，主要在于在菲奥奈篇中艾莉丝的形象简直发生了翻天覆地的变化。我并不打算分析艾莉丝这个角色，其角色的塑造是显而易见的。然而，我认为在这个篇章中塑造的核心角色反而是男主。这个篇章中揭示了男主在“大崩落”发生的具体情况。实际上，这个篇章中男主的复杂性是第一次体现出来的。

男主为了摆脱男妓，成为了一名职业杀手。然而，男主内心实际上是痛苦和迷茫的。剧情中有许多他的心理暗示。

我不想卖身，而先代给我指出了男妓之外的道路。这就已经足够了。

想要活下去，就必须要忍受、放弃很多的事情。

生活在这里，就只能考虑现在的自己能做些什么。

不管理想和不满反差有多么强烈，也不会产生任何改变。

可以看出，男主是并认为牢狱有什么资格谈理想以及未来的，然而男主真的没有这个资格么？男主在牢狱这个环境里面，也是上层阶级。显然，男主扼杀了自己对生存的意义的追问。然而，男主却对艾莉丝说出了，“我希望你能成为一个自由的人”。实际上，在后面剧情中也证实了这是男主对自己的期望。正是因为自己没有去追问生存的意义，所以希望艾莉丝成为这样的人。

每个人都必定会有其生存的意义。

人生中最重要的事情，就是努力地经营自己的人生，然后去找到生存的意义。

当然，当男主回想起了上述的话，其本质也是在逃避的。男主认为这些话在牢狱里面都是不现实的想法，在牢狱里面优先考虑的就是食物。抱有这种想法，在牢狱是活不下去的。这一章中，男主的复杂性就展现出来了。实际上，男主一直在追问生存的意义。面对在牢狱里的虚无，男主通过荒诞的形式去反抗。

圣女伊莲

我认为这条线可谓是本游戏中最为精彩的一条线。这条线是对荒诞最大深层次的思考。这个世间所有的人们都认为这个悬浮在空中的世界都是依靠圣女的天使的祈祷的。所以上一次“大崩落”的发生归咎于第一代圣女没有认真的履行自己的指责。然而，事实的真相却是圣女的祈祷是没有任何作用的，这个悬浮在空中的世界并不是依靠圣女的力量。人们只需要在发生“大崩落”的时候，把圣女送上刑场，平息百姓的愤怒。

当代圣女使用自己的方式来对抗这种荒诞，正因为她自己意识到了这种荒诞，她必须坚信自己的信仰来维持她自身，以维持自身的存在。为一个虚无的事物坚持是毫无意义的。正也是为什么其面对许多外界压力时，仍然坚持其信仰的根本原因。她的存在必须让她这么做。所以面对拉菲的质疑时，圣女伤心的真正原因就在此。其自身的存在容不得被消灭。为什么圣女的双眼看不清呢？难道不就是为了对抗这种荒诞吗？

这也是我对这条线最欣赏的原因。这条线的圣女展现出了完全与现阶段剧情中人们不一样的观念，面对这个世界的虚无，通过自己的方式尽力地走向存在。其次，圣女和男主下国际象棋博弈的过程，更为精彩，与其说是下棋，不如说是思想的斗争。圣女必须坚持自己的信仰，这是她存在这个世上最重要的意义，否则她就无法面对祈祷这件事情的虚无。而男主却认为手段无所谓，目的达成即可。

当男主得知了事情的真相后，如同菲奥奈的信念被破碎了一样。男主也产生了迷茫，其在牢狱的一切生存理由都被打破了。任谁都会觉得荒诞，本来认为的真相竟然全部都是虚伪的谎言：

如果让都市浮起的不是圣女的话

为什么，大崩落会发生呢？

为什么，我的家人会不得不死呢？

为什么，我会被迫在那名为牢狱的地狱中生活呢？

本剧情中，最精彩的可能就是圣女给男主传达的话语了：

你一直停滞不前，该考虑一下自己的生存方式了。

当然，我也很喜欢这段话。如果只有自己得到利益，才会肯定自己的生存方式，是得不到自由的。

因为被拯救了而去相信，因为没有被拯救而不去相信

这种想法，是绝对得不到拯救的

咱们都很弱小，因为一点事就会飘摇不定

所以，才要相信

并不是在被拯救之后才去相信……而是要去相信而得到救赎

在这一条线中，男主这个人物已然具体了。实际上男主的复杂性已经完全体现。由于生活在牢狱中，必须给自己的生存方式加以理由。然而，意义真的存在吗？其实到目前的剧情中，每个人都是伤痕累累的。信念也受到了崩塌，我无意探讨其细节之处。其真的走向存在了吗？实际上这个问题我回答不了，我们又有谁能说自己能够走向存在呢？

莉西娅

莉西娅线纯粹就是为了爽。同样，我认为莉西娅线塑造的角色并不是莉西娅。当然，莉西娅也面临着意义的问题，走向为王路上的迷茫等。然而，我认为这个线最有趣的角色就是戈尔。戈尔就是男主。戈尔认为她和男主属于同一类人，都是在牢狱通过杀戮来生存的人。显然戈尔为了对抗这种虚无感，直接走向了荒诞。杀人与不杀人已然无所谓了。因为这就是她的生存方式。她为什么想杀死男主？难道不是因为她想把自己也杀死吗，她可能也嫉妒着男主吧。所以我认为她是本章中最为复杂的人。

在我看来，这就是写脚本的人的映射。男主实际上一直都是迷茫的，但是男主并没有直接选择荒诞来对抗这种虚无感。我认为这才是这一章最核心的东西。实际上男主的独白很值得玩味：

不知为何，感觉死去的她就好像自己的某个亲人。

事实上，戈尔和我的人生轨迹几乎完全相同。

作为他人的所有物，而一直毫无道理地夺取他人的性命。

在这种生活之中，迷失了自己与他人的生存意义。

戈尔所面对的结局，应该就是像我们这样的人所经常会抵达的重点之一吧。

但是，我与戈尔不同。

我并没有输给自己所抱持的空虚，而将自己无谓地舍弃。

戈尔的死，让我再次加深了这个想法。

尤斯蒂娅

这一章节被许多人诟病。实际上我对这一章的看法完全没有从电车问题出发。当然，男主的哥哥持有的理念是牺牲牢狱的人而保护下层的人和上层的人，通过最小的代价来保证大多数的权益。而菲奥奈为了保护下层而战，吉克为牢狱而战。圣女为了坚持自己的信仰，为了自己的信仰而战。艾莉丝成为了一名称职的医生。

而男主呢？最后男主表示了自己确定了自己的生存信念：拯救尤斯蒂娅。我并不认可这种想法，实际上这是相当肤浅的。然而，没办法，受到商业的影响（毕竟需要恋爱故事）肯定有所妥协的。尤斯蒂娅为了拯救男主，选择净化了这个世界的污秽。

到这里，我不仅思考生存的意义对于男主而言到底是什么，实际上我认为终章并没有把这个问题阐述清楚。当然，我并不觉得只有男主在迷茫。难道其他角色没有迷茫过吗？哪怕他们的信念是坚定的，也只是他们必须要在这个虚无的世界中坚信信念才能走向存在。我并不认为存在才是解决问题的方式。可能这才是我对这一部分不满意的地方。

总结

在我的心里，我觉得这部作品最精彩的就是第一章，其紧凑的剧情以及优秀的人物塑造和背景让我一下就喜欢上了这部作品。然后后面的部分剧情是相对比较俗套的，但是圣女线这部分我认为是很多GalGame写不出的剧本，其探讨了很有价值的东西，反而是这部作品中很有深度的一章。然而，这部作品优秀的地方在于其对生存的意义的探讨。我们面对这个世界的虚无，应该做出怎么样的选择，我并不觉得里面的角色都能走向存在。然而，这部作品也温柔地探讨了这个问题。

这部作品有一个十分关键的词语：秽翼。浅薄的理解就是尤斯蒂娅能够净化这个世界的污秽，哪怕自己的翅膀染上污秽。然而在剧情中，天使的翅膀永远是纯净的。可能这就是这个世间。因为本身就是污秽，无论在牢狱、下层还是上层，我们都无可避免地去发问什么是生存的意义。

Context

在教程四中，我们已经实现了状态机，接下来我们定义一个Context类，其仅仅简单地封装一下，维持一个current变量指向当前的状态即可。我们需要在miniSMTPServer/context目录下创建context.hpp和context.cpp文件并修改CMakeLists.txt。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// miniSMTPServer/context/context.hpp
#pragma once

#include "state.hpp"

#include <memory>

class Context {
private:
  std::unique_ptr<State> *current;

public:
  Context();
  std::string transitive(std::vector<std::string> &parameters);
  ~Context() = default;
};

1
2
3
4
5
6
7
8
9

// miniSMTPServer/context/context.cpp
#include "context.hpp"

#include "state.hpp"

Context::Context() { current = &States::idleState; }
std::string Context::transitive(std::vector<std::string> &parameters) {
  return (*current)->transitive(parameters, current);
}

1
2
3

# miniSMTPServer/context/CMakeLists.txt
add_library(context STATIC state.cpp context.cpp)
...

可以看出Context类十分的简单，这是因为大部分工作都已经实现了。

SMTP Server

现在，我们终于可以开始写我们的Server了，我们只需要完成一个简单得不能再简单的工作：按照空格分割字符串。然而你可能会想到最直接的方法就是定义一个istringstream。然而这是不正确的，因为可能会存在如下的情况：

1
2

MAIL shejialuo@gmail.com OK
MAIL  shejialuo@gmail.com NOT OK

ABNF中严格地定义了只允许拥有一个空格。而所有命令的参数最多不超过1个。我们采取的策略就可以非常简单了，直接以一个空格分割字符串即可。但是值得注意的是，我们必须删除接收到的字符串的最后两个，根据协议其最后两个字符为CRLF，即\r\n。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// miniSMTPServer/miniSMTPServer.cpp
std::vector<std::string> getParameters(std::string &request) {
  request.pop_back();
  request.pop_back();
  int split = 0;
  for (; split < request.size(); split++) {
    if (request[split] == ' ') {
      break;
    }
  }

  std::string command = request.substr(0, split);
  if (split != request.size()) {
    std::string parameter = request.substr(split + 1, request.size() - split - 1);
    return {command, parameter};
  }

  return {command};
}

最后我们只需要修改主函数就可以了，其逻辑十分的简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

// miniSMTPServer/miniSMTPServer.cpp
int main() {
  std::cout << "Hello, This is a simple SMTP server\n";

  TCPSocket socket{};
  socket.set_reuseaddr();
  socket.bind();
  socket.listen();

  std::string request{};
  Context context{};

  while (true) {
    auto s = socket.accept();

    bool isDone = false;
    while (!isDone) {
      s.read(request);
      if (request.empty()) {
        std::cout << "S: Connection lost\n";
        s.close();
        break;
      }
      std::cout << "C: " << request;
      std::string parameter{};
      std::vector<std::string> parameters = getParameters(request);

      std::string result = context.transitive(parameters);

      s.write(result + "\r\n");
      std::cout << "S: " << result << std::endl;
      if (result.substr(0, 3) == "221") {
        s.close();
        isDone = true;
      }
    }
  }

  return 0;
}