前几天GCC社群有个不小的新闻：新的 "-fparallel-job=<N>" 选项可以让编译流程 本身平行化 有别於许多近代 build system 早已提供的档案层级平行化(i.e. 把个别档案的编译工作 都到独立的一个thread) 编译器本身的平行化(i.e.把编译器内部的工作平行化)一直以来都没有登上 主流 因此我听到这个消息以後非常的兴奋 事实上这个计画大概在去年底就有个雏形了： https://youtu.be/jd6R3IK__1Q 我也会就这个影片做讲解(P.S.虽然内容很赞但这个演讲本身的品质...有待加强XD) 这个计画最大的动机是大型档案的编译速度太慢 同时也是前述build system档案层级平行化无法解决的问题 如果把GCC各部分(e.g. frontend, backend)的处理时间摊开来看 可以得到以下分布： https://imgur.com/35KzIRj 其中很明显的RTL，也就是backend/code generation的部分花最多时间 第二多的则是target independent、intra-procedural的优化与analyses (也就是GIMPLE) 虽然RTL占的时间最多 但该计画的作者认为 GIMPLE 比较好改 所以就先尝试将每个function丢到独立的thread里面做 GIMPLE 优化 https://imgur.com/bpah6Q4 当然就如影片里面所示 有一堆全域的资料结构因为race condition的缘故要修改 最终实验结果如下： https://imgur.com/Blb6Tye 5~6%的加速...虽然已经很好了 但如果把这项技术也用在RTL上的话... https://imgur.com/wD9422B 30~60%的加速 这个就真的蛮惊人了 虽然我很想吐槽：绕了一大圈你还不是要平行化RTL （笑 ======== 即便得到了一个如此亮眼的数字 我想最大的问题在於： 通常你有一个超超超大的档案 你会想直接把他切小一点 而不是那麽费工地平行化编译器 我认为并不是这想法本身有问题 而是因为用multi-threading本身的overhead还蛮大的 所以你的档案真的要超级超级大 用这个技术才划得来 但如果如此的大 就像上面所说的：直接切小一点会比较快 又或者是说：会产生如此大档案的情况少之又少 这种corner case 真的值得你花那麽多 时间去研究以及维护吗？别忘了GCC是一个持续成长的开源专案 如果这项技术导致以後 一些更重要的功能难以实作 难保不会有人质疑这技术的必要性 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 169.234.228.215 (美国) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/CompilerDev/M.1598206736.A.EF3.html 对吼有道理 差点都忘了template所造成的潜在code size膨胀 ※ 编辑: mshockwave (169.234.228.215 美国), 08/25/2020 11:24:52