被UnityDOTS坑了，UnityS到底是不是骗局?

被Unity DOTS坑了，问题不应该是问Unity DOTS是不是骗局么，为什么要把ECS这个概念单独拿出来锤，关于ECS的问题没什么可说的了，说一下DOTS。DOTS是由Job System，High Performance C#, Burst Compiler等引擎层实现组成的技术栈，ECS是上面的软组织。先说Burst，很多人反映Burst不如IL2CPP快，我就好奇Unity在吹之前有没有自己测过。就说我自己Windows平台的测试结果，同样用MSVC后端的LLVM编译工具链（从编译到link都是LLVM系，如clang.exe, clang++.exe, llvm-ar.exe, llvm-strip.exe等），开最高的-Ofast优化，对比原生MSVC工具链或把前端编译器从cl.exe代替成LLVM里的clang-cl.exe的Clang-CL工具链开/O2优化，单一项lua 5.4.4解释器的性能测试上，LLVM工具链就慢了10 - 15%，即使是Eigen，glm等纯计算数学库，LLVM工具链也没有丝毫的优势。这是非常夸张的性能差距，用在对性能要求高的应用场景基本算是生产灾难了，可以说LLVM工具链在Windows平台就没有做好准备。Burst作为一个直出LLVM IR的编译器前端，怎么想都觉得跑不快是很合理的事情。再说High Performance C#，这个名字起的是真的好听，直接叫Embeded C language都不怕C语言嫌弃。这玩意对语言特性的支持和C99一样，只能裸指针，只能trivial type，我用C语言还能出DLL呢你能吗？对高性能编程语言来说，接什么后端，用什么工具链都是其次，因为这些随时都能换。表达能力永远是首位，RAII，函数虚表，广义的元编程能力（无论是DSL codegen，还是自省AST，还是用模板，一律都算）。现代高性能编程的不是人力硬拼机器码，而是怎样在维持性能的基础上尽可能多的降低开发门槛。项目都做不出来跑得快有什么用？最后，Job System一整个就是残疾的，除了Job Thread完全无法访问Unity API这种古老的问题以外，最大的问题还是Job里没法开新的Job，这对于许多树状或网状的多线程逻辑而言是毁灭性，比如我要写个加速场景里的AI检测逻辑的空间查找加速结构，我选择了BVH或者k-d tree，那么这个切分过程是万万不可能做成多线程的操作了。但在C++中，只要开发者能力足够，都不需要多新的特性，只用C++11的std::thread，std::mutex，std::atomic，std::condition_variable就能轻松写出一个几百行的Job System，能在任意线程随意开启新的线程，还能顺便标记依赖，关键是性能还不比Job System差。毕竟VS标准库就是微软写的，微软不比Unity懂Windows？说完硬件，在鞭尸一下Unity的组件部分。物理和渲染，这两个多线程需求上最大头的部分，不支持多线程。物理官方是写了新的ECS案例表示自己“支持”了多线程，那以前的组件呢？渲染，做了一个SRP，表示主线程分配上层任务下面会自己多线程，那我想自己绘制场景的部分呢？最后就发展成，有需求必须自己接PhysX库，自己写Vulkan，DX12 Plugin，Unity自己的东西依然完全没得用。实现都没做好，就别说那些花里胡哨的概念了。

#分享编程心得# #分享编程技巧# #好用的开源软件# #wcoop# #编程杂谈# #编程经验# #编程误区# #如何自学IT# #软件如何开发# #怎样学习编程#