原文传送门：https://forum.paradoxplaza.com/forum/threads/stellaris-dev-diary-181-threading-and-loading-times.1413671/

       欸嘿，大家好，这是法国悖论。

       谨代表整个群星团队，我们衷心祝愿你们能享受一段美好的暑假，即便是在目前的糟糕情况之下。

       我们现已全部回到工作中去，然而不是回到办公室。接下来的秋冬两季将会因为一大堆的好消息而变得激动人心！我们迫不及待地想让你们了解到接下来的几周，甚至是几个月里将要发生的事！

       今天，我们要来看看让我们的部分技术人员忙了一整个夏天的事情，它将被包含在即将到来的2.8版本中。团队中的其余成员会在后续的日志中公布新版本的内容。

       好了，闲话少说，我们来说一说多线程。

多线程？啥是多线程啊？

       有一个流传很广的笑话：我们的粉丝总是在好奇，究竟是会先出维多利亚3，还是一个使用多线程的P社游戏？

       现在，我要驱散迷雾了：所有的P社游戏都在使用多线程，从欧陆风云4到十字军之王3，甚至是群星！为了更好的解释这个梗，以及它的来源，我们得要回顾一下历史。我听说你们很喜欢历史。

       很长时间以来，软件产业依赖于摩尔定律，也就是“每过两年，CPU的性能会翻一倍”。这在90年代是十分准确的，当时CPU的频率在十年里跨越了从50MHz到1GHz的距离。这个趋势一直持续到2005年，我们把CPU的频率弄到了3.8GHz。在这之后，CPU的时钟频率便不再增长。这之后的15年里，CPU的频率也基本上没有改变。

       正如表现出的那样，物理定律让提高频率到4GHz以上的过程变得十分缓慢。所以制造业开始转向另一个思路：让CPU“裂”成复数个核心和物理线程。这就是你们现在会更多关注核心数而不十分在意频率的原因。摩尔定律还在生效，不过在战略层面，CPU制造商为了避免频率上的瓶颈，转而开始专攻线程数。

多线程并不会变得更快

       这个话题让我们回到了我们的游戏上，以及一个我们常常在论坛上看到的问题：“这个游戏有没有启用多线程？”答案当然是“没错”！事实上，在几个版本以前，我们正面临着游戏因为对线程数的依赖而不能在只有两个核心（或更少）的电脑上运行的严重问题。

       不过，我怀疑真正的问题是：“你们是否有效地利用了多线程？”它的答案是“看情况”。就像我之前提到的，高效地利用更多核心是一个比高效地利用更多时钟周期更复杂的问题。对我们来说，给不同的线程分配任务主要面临两个问题：序列和顺序。

       序列问题会在两个计算过程同时调用同一个数据时发生。举个例子，我们需要计算一个佩奇奇提和一个布洛葛的产出。这两个计算过程都需要调用目前的能源储量，把他们的产出加上，然后再写入数据。根据计算序列，他们会同时读取初始值（假设是100），加上他们的产出（假设是12和3，我们的布洛葛今天不太高兴），然后再写入。理想情况下，我们希望得到115（100+12+3）。但很有可能两边在读取100以后，会分别写入112和103。

       一个简单的解决方案是锁定：在结算佩奇奇提的产出时，锁定当前的能源储量直到结果返回，接下来结算布洛葛的产出。用这种方法解决问题时，它带来了另一个大问题：计算过程再次变成了单线的，多线程计算的优势不复存在。更坏的是，由于锁定、解锁和同步的耗时，整个过程会比原先单线程计算时更浪费时间。

       第二个问题是顺序，或者叫“顺序依赖”，专指顺序改变会导致结果不同的情况。继续拿佩奇奇提和布洛葛举例，他们俩想要解决以核平方式解决一个争端。我们知道战斗系统会同时处理战斗双方，但鉴于一场战斗可能有上百个动作，我们并不知道动作的顺序。非常有可能的是，两台机器上的顺序会有所差异。或许在服务器上，佩奇奇提先动手，而在终端这边，布洛葛更快。

       在服务器这边，佩奇奇提的动作先结算，杀死了布洛葛，而布洛葛可能的后续动作（一般来讲，在另一个线程上结算）也不复存在，毕竟死人不能开枪（非常科学）。但在终端这边，计算的分配与服务器不一致（没准是因为更多的核心），在它的世界里，布洛葛先手解决了佩奇奇提，让他闭上了嘴。然后，在现实分裂的那一刻，两个玩家都收到了令人胆寒的“失去同步”弹窗。

       当然，解决方案是存在的，不过那通常要求在以上两个限制下重做整个设计。在我们的第一个例子中，可以让每个线程结算一个产出，最后合并。两位决斗者带来的问题，可以通过先记录伤害，下一个阶段时再实际生效的方式来解决，以此来避免对确定顺序的依赖。

       正如你所想的那样，想象出一个多线程系统比将一个现成的系统改成多线程的要容易得多。如果你不信的话，看看你改一次舰队要花多久，我可以等你。

好消息

       这都挺好的，但是，下一次更新能为你带来什么好处呢？你会感到开心的，当你知道我们要把这些用到我们引擎中最老的部分：文件和资源加载系统。

       在非常长的一段时间里，我们一直在用第三方软件来解决这个问题。它给我们留下了一堆问题，同时也在多线程方面表现出了重大的缺陷。到目前为止，游戏有时会在多核时变得更慢，尤其是我之前提到的锁定问题。

       和其他优化结合起来，我们已经可以大幅地缩短游戏的启动时间。

       我可以再用千把个词来说明为什么，但我想一个视频会更有说服力。

       这个比较是在我自己的电脑上进行的，用的是i7 2600K和一个固态硬盘。两个都是热启动（在启动过一次以后再启动），不过在我的实验中，似乎冷启动也有所改善。

       为了达到最大的优化，你会需要新的测试版DX11渲染引擎。没错，你读的是对的：下一次更新会提供一个DX11引擎的开放测试版本，用以替代之前的DX9引擎，这个新引擎是由我们在Tantalus的朋友首先为主机版群星制作的。在视效相同的情况下，DX11引擎渲染允许全方面的多线程优化，这是DX9所难以达到的。继续以DX9引擎游戏依然会给你带来一定的加载加速，闪屏会变得更加快速，但是在加载模型和材质时，你将不会看见进度条像飞一样前进。

       这些优化中的一部分会被应用到新的Clausewitz上，成为CK3的一部分。英白拉多也会通过它得以改善。或许它也会被应用到EU4和 HoI4上，但我用EU4做实验得出的提速效果不如群星和CK3那样巨大。

       如果你想了解有关提速群星的更多技术性内容，你可以看看我在博客上贴的文章：https://mropert.github.io/2020/07/26/threading_with_physfs/ 。

       就说这么多。这或许是我的最后一篇群星开发日志，下个月我就要去领导HoI4的程序开发。你可以把这些优化看作是临别礼。

       我在群星制作组的时间可能很短，但不要担心，即便我走了，Jeff也会陪着大家。