2024全国大学生计算机系统能力大赛-OS功能挑战赛道全国总决赛答辩心得、教训
2024全国大学生计算机系统能力大赛全国总决赛-OS功能挑战赛道答辩心得、教训
虽然标题中写的是"心得、教训"，但因为本次比赛表现较差，主要还是记录一下教训。
场外因素的影响
因为平时比较喜欢熬夜，在去杭州的前一天晚上睡得很晚，当天又因为初到杭州十分亢奋，在旅途上全程没有补觉。导致第二天白天（答辩前一天）非常困，几乎整个白天的时间都呆在酒店里睡觉。到了夜里因为：
- 白天已经睡够了
- 内心十分紧张
在双重因素的作用下，整晚都没有睡好觉，总睡眠时长只有两个小时，导致第二天白天答辩前晕头转向、头昏脑涨，严重影响了临场发挥和随机应变的能力。
因此，和社会普遍公认和接受的作息保持一致是非常有必要且有用的，可以很有效地减少这种情况的发生。
答辩现场
性能测试相关问题
虽然比赛前老师叮嘱我们要对评委各种可能的提问方式做预案，但我们还是因为缺少相关经验和麻痹大意，只着重准备了这两类问题：
- 相比往届作品有何优势？
- 系统架构/设计思路
然而这些最后都没能成为评委老师重点关注的问题。
在我们展示完毕之后，对我们的项目比较了解的评委老师都对性能测试方面的内容穷追猛打，但这恰好是我们最大的弱点：
- 负责测试的同学没有来参加答辩
- 我们的测试环节做的非常粗糙
老师们提出的问题大概如下：
-
为什么你们的malloc随着分配规模的变化，性能变化会呈现出这样的趋势？
- 这个问题比较简单，因为内存分配器的架构是我们自己设计的。
-
你们的作图不规范，time连单位都没有（我们直接沿用了往届的测试脚本，没有自己进行编写）
- 这个是前期的态度问题导致的。
-
比较了解的评委老师认为我们和memmalloc进行比较，是在挑软柿子捏，认为我们不真实。
现场错误表现：因为被老师戳到痛点（我们确实不敢和比较高效的性能分配器作比较），所以只能支支吾吾地回答我们也和GNU的malloc进行了比较，而GNU的malloc是比较强的。但是可能老师对GNU这个名词不是很熟悉，也可能因为我当时说话没说清楚，老师对我的回答没什么反应。
正解：我们的技术文档里，是有着我们的项目和其他相比memmalloc更优秀的往届作品的比较结果的，我应该拿这些图片来反驳评委老师；即使不拿出我们的技术文档里的图片，PPT里的图片起码也有三条曲线，可以结合图片告诉老师，这是我们和GNU的ptmalloc对比的结果，我们的性能是相近的。
当时一个非常大的错误就是怯场：评委老师不翻PPT，就不敢动，实际上，应该积极地挑对我们有利的内容进行展示。
至于负责测试的同学没有到场这个问题，实际上也是有解决之道的：
- 测试工作很简单，干脆两个人做完得了；
- 既然他不来，那么他就有义务给出详实的测试报告，包括测试的详细内容和具体执行步骤，这样我们可以以此为依据来回答老师们提出的问题。
回答老师提问的技巧
- 对项目比较了解的评委老师指出我们的性能测试数据过少之后：
现场错误表现：不敢正面回答问题，小声划拉我们的文档页面。
正解：既然我们被老师质疑缺少测试，那么这个时候，哪怕测试是不规范的，也要大胆地摆出来！毕竟我们的测试样本已经被老师指出不规范了，这时候老师的问题已经转移到"为什么你们的测试这么少"上面，这个时候大胆展示我们丰富的测试用例，可以挽回局面。
- 对项目不太了解的老师提问为什么我们的page大小是4k：
现场错误表现：因为操作系统当中设置的是4k，保持一致
老师反驳：内核实现当中，可能大小和我们的4k是不一致的
出现错误的原因：老师问的page和我们所回答的page并不是一个东西，老师心里带着的概念是：操作系统底层实现中的page，而我此时脑袋里想的却是我们的基本单位page，事实上，我们的这个page只是我们针对malloc设计的一个内存管理单位而已，叫slot、span、arena什么的都无所谓，应该首先向老师解释清楚这两个容易被混淆的概念，然后再进行进一步的解释。
老师追问：为什么要设置为4k呢？
组长回答：因为这一块区域里不仅要存放实际用户分配的内存，还要记录malloc的信息，这二者受到不等式关系的约束，故选择4k。
当时老师接受了这个解释，但实际上这个并没有答到点子上。
- 你们为什么不和微软的mimalloc做性能对比？（我之前提到参考了mimalloc）
现场回答：因为他们的项目不好部署
老师追问：但是他们官方提供了数据呀
之后我就只能点头同意
但这里正确的回答应该是：他们的官方数据使用的平台都是高性能服务器设备，我们无法复刻，自然也就无法比较。
正解：
-
首先，如果一个单位过大，会导致内部碎片异常巨大，极大降低我们malloc的效率；
-
如果按照老师的这种思想，把它发展到极端，也就是把整块内存当成一个单位，一次就直接把它分配出去了，这显然是不合理的。
综上，我们需要给每个层级设置一个合适的大小。 -
对项目不太了解的老师针对三模冗余功能提出疑问，并且问道"如果发生了超过一位翻转，那是不是就不行了？"：
现场错误表现：在解释了纠错功能之后，我针对老师的质疑，回答道：赛题只要求一个bit
正解：所谓"赛题只要求一个bit"这种发言，是回答这个问题最低级的形式；我应该在说明三模冗余功能的基本原理之后，告诉老师：实际上纠错任务本身，是能够实现对无限bit的纠错的，只要我们备份的够多，或者遍历的时候，用的时间复杂度越高，越接近O(n)，那理论上可以实现任意位的纠错；但是我们赛题的前提是特种设备、航空设备，内存和CPU资源都十分紧张，我们必须平衡好纠错的收益和代价；加之单粒子翻转本身就是小概率事件，所以我们没有必要考虑多位翻转的情况，如果真的有那么倒霉的话，估计航天器早就坠毁了；在回答这个问题之后，足以见得这位评委老师没有认真听我们的报告，因此，有必要再次强调，我们不仅有三模冗余功能，还实现了奇偶校验，他们一个是时间换空间，一个是空间换时间。
- 有比较了解的评委老师指出，虽然我们给存入实际地址的内存做了纠错功能，但是本身的信息位却没有做防纠错。
我在看到hcmalloc的这个设计时，还认为是多次一举。这位评委老师一语道破天机，这确实是我们在设计系统时一个非常可笑的疏漏了。
- 有评委老师问我们：你们是如何利用核心亲密度机制来实现加速内存分配的？
现场错误回答：我在回答的时候举了NUMA的例子，我说我们的目的是保证在内存都被绑定在同一个节点的同时，保证进程长期运行在同一个核心，减少切换次数，从而提高性能。
老师回话：NUMA不是什么节点之类的（具体表述我忘了）而是CPU访问不同内存的延迟天然不同，有差异。
灾难性回答（实际上勉强及格）：我的回答是：哦，那这样的话，我们的目的就是在保证"内存都被绑定在同一个节点的同时，保证进程长期运行在同一个核心，减少切换次数，从而提高性能。"
正解：当时我的脑子没有转过来，实际上我和老师已经在问题的基础上达成共识了，那就是NUMA架构下CPU访问不同内存的延迟不同，但是我和老师在"节点"的概念上理解存在偏差，我应该先指出，节点就是那些内存访问速度不一样的点，所以我们需要让内存绑定在一个恒定的节点上，同时用Linux的taskset命令来绑核，这样就能实现访存延迟最小化。
其他问题
组长在展示时忘记提到我们的小内存分配有预分配功能，后来我在回答问题阶段向老师补充说明了这一点，这属于是不可控、不可预测事件了，教训就是一定要尽可能地表述清楚，不要放过具有我们技术特色的细节实现。
总结
-
描述项目实现时不要太微观，但是在宏观层面要做到面面俱到，重点展现我们花了心思的地方。在一开始就描述全面、充分，防止在提问阶段被评委老师抓住漏洞输出。
-
不要怯场、不能慌。很多问题我在事后回顾时都能回答得很好，当时却乱了阵脚答不上来，要注意锻炼心态，要自信大方！就像我们的前一组那名同学一样，一个人也能舌战群儒，并且达到非常优秀的水准（被拉去抽查项目实现）
-
要积极应战，别犯拖延症。在开发阶段，从初赛到最后的决赛，我们都是最后一段时间踩点完成的，这一点非常的不应该！正是时间上的紧张，导致我们的测试部分做的一塌糊涂；也正是因为时间紧张，我们没能充分预见评委老师可能提出的各种***钻问题，导致到提问环节表现差劲
-
面试和答辩，不要怕"把别人当傻子"，尽量详细、清楚地说明，尽可能减少歧义和模糊的地方；在每一次表达时，一定要抓住一切机会，表明我们项目是有多么困难（即使它实际上并没有，但可能别人并没有那么了解这个领域），我们为了克服这个困难，费了多大力气、用了多少巧思。
