闲聊 [Lattice核心]我“们”做了一个高性能核心

[老穆棍]

因为不是正式的发布，排版很随意，敬请谅解。

前言​

如果说你在大约一年前刷minebbs，可能会看到过我发布的一个帖子，是“Lattice核心团队招人”，好吧实在是没几个人感兴趣，于是乎只好做个1人团队了。其实有人愿意加入，但是对c++造诣不够深（没污蔑他，他自己说的），本人人脉也不行，没有认识的可以做这个项目的佬，因此项目立项，到最终做到这个状态，相当不容易。

​

性能​

关于性能，因为架构限制，也不能比原版快多少。接下来先介绍Lattice的架构：Java版服务端（基于Purpur）->JNI胶水层->C++

为什么你要整一个这么抽象的架构？​

好问题，如此设计的原因的基本点是基于性能考量，C++具有无与伦比的生态和原生性能，让我们能越过jvm，我们可以将smid优化到极致，只要这个计算量能够和jni开销相抵，我们就可以吃到原生优化的红利，所以说基本都是批量计算，数据“拼车”进入native可以发挥较大的性能，不用额外付出jni的开销。同时社区对Java服务端的优化基本达到顶点，整体方向向“异步化”靠齐，不过异步化bukkitAPI、给某个模块开异步线程是非常高风险的优化。

对于Lattice而言，我们尽可能少做这种高风险的优化，同时提升性能。其实从多线程本身来说，多线程本身就可以碾压单线程，但是问题在于我们怎么做多线程而已。像Foila，放弃SpigotAPI生态，一半以上的插件不能用。并且多线程要求一个数据量和核心数量，换句话来说，就是玩家人数足量才能碾压，否则多线程就没什么用。

说这个对于Lattice的意思是什么？因为我们在追求极致的性能的同时，保留了Purpur原有的味道，做成了“九转核心Lattice”

其实jni并不是什么新技术，但是把它接入到MC核心热点方法中代为jvm计算的，Lattice是第一个这么做的。

​

性能数据​

说完上面一堆意义不明的东西之后终于可以说说我们优化了什么了

世界生成​

这是我们最得意的优化之一，因为它的收效相对来说较大。其实这个模块并不一定影响你的TPS，但是也会导致你的mspt上升。并且维护难度大。

在我的9600XCPU上面，内存堆4GB，chunkgen-worker为6。相对Paper提升35%左右，最大提升50%的世界生成速度

为什么Lattice敢做世界生成优化？因为我们在核心上面集成了一套parity系统，通过双跑native/原版算法比对原版与native的计算结果的差异，反映是否有算法上的错误。最大数值差异最大控制在6E-14这个数值左右，属于极小的差异。并且保证99.9%的地形与原版一致。

​

实体性能​

这里没有多少可以native化的东西。我们原以为加速碰撞模组可以给我们带来启发，但是我们还是大意了，Paper已经在配置文件中限制了实体碰撞（还是Spigot来着），因此这个模组对我来说没什么用。并且本身AABB占比不会特别高，因此优化不会很明显。

在我们的测试基准中，Lattice已经可以和Leaf的速度持平甚至超越Leaf，幅度在5~15%之间。寻路也被压成非热点，spark显示findPath()总耗时仅4ms。

​

开源​

https://github.com/LatticeMC/Lattice 我二十多天没有推送仓库了，会在这几天推送。

​

最后​

这不是正式的发布贴，只是想要提前预告一下。感兴趣的话可以加入QQ群吹水：1050633385​