10.18

2026-10-18

周日

星辰杯决赛

意料之中，国庆节期间放出来的赛题就是正式赛题，最后只是换了 15 个 Case，这为我节约了非常多时间。

我早已发现主办方是草台班子，并以此预测到了这一点。因为国庆放假，主办方肯定搞不出一个全新的题目，大概率就是沿用这道题。至于有人国庆就开始做了，是否会不公平的问题，主办方大概率也不会在意。

星辰杯决赛将在 10.31 23:59 结束，还剩 14 天，目前 排行榜 上第一的是自从超过我后一直遥遥领先的南工工南，而我自从 10.11 开始就没在排行榜上动过了，这里的技巧是我称为潜行模式的东西，只需要为每个 Case 都加上 1ms，就能既让排行榜上的时间很慢，又能解算出自己的真实时间，还不会刷新 TBest。

现在南工工南是明面上的第一。我应该暂时是实际的第一，而实际的第二或许另有其人，这是因为可以注意到部分 Case 的 TBest 比当前榜上所有人的都快，例如此时此刻 Case 1 的 TBest 是 305.18 微秒，但南工工南的 Case1 是 321.30 微秒。这说明至少有个高手也藏了起来，但手法比较拙劣，居然刷新了 TBest。我猜测他的方法是目标 Case 直接测试，其他 Case 输出 wrong answer，这样压低自己的总分，但这就让时间暴露在 TBest 里了。

下图记录了此时此刻的 TBest，南工工南，以及我的线上情况。

大致情况是，我在所有 Case 上都最快，但只有 Case 4 和 Case 5 遥遥领先，Case 1 显著领先，其他 Case 则大致在同一水平。

今天尝试了一下指导 Astra 优化，发现真的有用，我看了一下 Case 1 的流水线图，发现 AIV 的启动时间非常不均衡，启动慢的核直接拖累了后续工作，成为瓶颈，所以我有两种猜测，一种是对启动的控制不够底层，有多余动作；另一种是启动不够轻量，应该可以通过删数据来减少启动时的负担。

事实上两个朴素的猜测都不对，但这也确实可以改进，总之我们通过改变启动过程，确实减少了最晚核的启动时间，从 9.46 微秒变成了 5.32 微秒，并让端到端时间也相应减少了大约 4 微秒。

那么，我在其中起到了什么作用呢？很简单，就是看到一片刺眼的空白，并且发现它确实是瓶颈，然后让 Astra 来尝试解决。为什么 Astra 自己没关注这个问题？可能是根据经验，kernel launch 到 process 的过程就是被通常优化所忽视的。