失败了但没完全失败的编译原理比赛

失败了但没完全失败的编译原理比赛

前言

  • 毕业答辩结束了一直想找点事做,之前听说了编译原理比赛,但没有下定决心参加。接触了组内师兄的研究方向后发现编译的占比挺高,于是想参加一下,既是学习,也是挑战一下自己

0

1

准备

  • 既然决定了参加,第一步就是找队友,这个时间很难找队友,同学们都在旅行/实习/科研,最后只找到了一个在华为实习的室友做队友
  • 虽然是四人一队参加比赛,自己队只有两个人,但考虑到大多数参赛人员都是大二或大三的学生,当时还是信心满满
  • 五月底到六月中旬主要是调研比赛和各种技术方案,期间也去做了一下实验室师兄设计的编译语言实验,本来师兄和自己都觉得可以在这个的基础上改改参赛,后面觉得有两个问题
    • 一,为了满足实验课分阶段处理的要求,编译各阶段解耦得很开,中间都靠 json 传递信息,感觉太笨重了
    • 二,原实验的设计依赖了很多 llvm 的接口,这对于学生来说,能熟悉很多 llvm 接口当然很好,但该比赛不允许使用 llvm ,需要把这些接口都自己设计实现一遍,虽然可以参考 llvm 源码,工作量也不小
    • 更重要的是,初步接触了 ANTLR 后决定立刻放弃 bison+flex 的前端技术方案不用自己建树太香了
  • 和队友谈论时,他也倾向使用 ANTLR,因为他还在实习,于是我来写前中端,他来处理后端,这样他可以稍晚点开始动手写

coding

  • 真正开始写项目是六月下旬,临近毕业,有一些活动,以及偶尔 emo+思考人生,真正用在写代码的时间并不多,离校前仅将前端完成其实就写了两天,中端设计好,搭了个框架
  • 7月初回家到7月20号左右是全力开发的时间,在使用lli做后端验证下通过 70+/100 的功能测例,离前中端全部调通只有几个小块内容,很快就可以进入中端优化
  • 和队友讨论时,询问他关于中端结构的意见,他总是没什么反应,push 他写也被他用华为工作很忙搪塞过去;当时心里虽然有点慌,但想着他怎么也会把后端写个七七八八吧,甚至后端优化也可以我来学着写写;单纯的 zty 还没有预料到接下来会发生什么

剧变与选择

  • 像往常一样 push 队友写后端的早晨,队友突然说自己不写了,当时我的内心是崩溃的
  • 我已经写了5000~6000行代码,而后端是0,距离 ddl 还有15天左右
  • 和张老师沟通了一下,也可以选择到冲大另一队做外援,另一队由两个大二和两个大三组成,他们基于编译原理实验课的项目开发,据说困难很大,因为两个大二学弟没有学过编译原理,实现 llvm 的接口工作量也不小
  • 此时面前的有三条路
    • 一是继续开发,一个人做编译器全栈;考虑到剩余时间不多了,而我完全没接触过 ARM 之前已经接触过MIPS和X86了如果非要我再学一门汇编我可能会学RISC-V,接下来的日子会很艰难,而且基本没有时间做优化
    • 二是把代码给另一队,自己转做外援,还要帮助他们继续中端开发;这样所有奖项荣誉都和自己无关了
    • 三是直接放弃;说实话当时没怎么考虑过
  • 应该说,不管怎么选,奖项大概率都和自己无关了,陷入了所谓“非与非”的选择
  • 思前想去,最后还是选择了“带代码进组”,毕竟这个奖对于我这种已经毕业确定去向的老学长没什么作用了虽然后面队伍进决赛没自己名字还是会emo;另外,参加比赛的初衷也是学习,这样至少可以接触一些中端优化的内容

后续

  • 后续差不多继续写了一个礼拜代码,lli做后端验证下把测例全部调通了,做了一下常量相关的优化,一些中端分析和函数信息收集
  • 再后面就没有写的动力了,只做一些维护性工作
  • 一个大三同学继续做中端优化,一个大三同学做后端,人手和时间不足导致后端同学也写得比较辛苦
  • 最后成功进入了决赛,但是后端只通过了99/100的功能测例,其实我们做了很多优化,按照比赛规则,项目没有进入性能测试,拿不到性能分,只拿了优胜奖

总结

个人

  • 这次经历不能算是什么很好的人生体验,但人生总会有这样的事情,人总是要学着和自己和解
  • 在抱怨队友的不靠谱之余,我也深刻理解了一个道理:“人是项目成败与否最重要的因素”
  • 应该说,从零开始设计实现一个编译器是能学到很多东西的,一开始面对其它项目或者 LLVM 的设计,我总是一头雾水,只能被动接受,知其然不知其所以然,但经过自己的模仿设计实现后回头看,一些设计的细节能想得更明白

未来可能参赛的学弟学妹

  • 对于想学到东西的人,我建议还是从头设计,敏捷开发,不管能不能拿奖一定能受益良多,今年报名的有150+支队伍,但最后提交的只有50不到,进入决赛(大约卡在预赛功能分60以上)的好像只有30+,这个领域很难,走到最后的竞争对手并没有想象中那么多,虽然参赛队伍每年增加得很快,但我估计最后能达到预赛功能分60以上的队伍数增长不会很快;注意不要犯和我一样的错误,一定要找到能一路坚持的靠谱队友,人是软件项目管理最重要的事情
  • 对于想要拿奖的人,我建议不要从头开始,直接看懂一两个项目然后在别人的基础上魔改,如果能直接在师兄师姐的项目上写或者学校实验课项目上写最好,组委会也鼓励这种行为;今年是编译原理比赛第三届,每年会在去年的基础上增加一些需求,可以预见的是,项目需求会越来越复杂,到后面越来越不可能从零开始开发,所以重心不需要放在整个项目的设计上,更重要的各种优化的实现
  • 具体的技术细节官方培训视频都说得很明白了,各种技术路线,经验和坑的讲解都有

库亚西

2


失败了但没完全失败的编译原理比赛
http://example.com/2022/09/08/失败了但没完全失败的编译原理比赛/
作者
zty
发布于
2022年9月8日
许可协议