在 2024 年 12 月 6 日 Unity 技術開放日廈門站，Unity 中國 DOTS 技術主管李中元帶來分享《團結引擎高性能 ECS 架構》，深入解讀團結引擎 ECS 架構高性能的真相。本文為演講實錄。演講視頻可通過下方鏈接地址觀看。

https://www.bilibili.com/video/BV1F4k1Y3E8q/?spm_id_from=333.1387.collection.video_card.click&vd_source=6ad5666ecbc7fe0e80d963da7e237d92

李中元：大家好！很高興有機會和大家聊一下 ECS，以及關于性能方面的一些進展。

今天給大家帶來的兩個大的話題，一個是 ECS 架構的簡介，給大家帶來一些認知層面上的感受，ECS 為什么快？第二會告訴大家，ECS 快的真相是什么？是用了 ECS 就一定快嗎？第三，能不能更快？

ECS 架構簡介

接下來進入 ECS 架構的主題，分了三部分，首先介紹一下什么是 ECS 架構；第二，和面向對象作對比；第三，我們為什么要使用 ECS 架構？

什么是 ECS 架構？Entity Component System，這個名字起得非常簡單直接，就是三個 ECS 系統核心名詞的組合。Entity 就是指向數據的 Handle，大家可以認為，我拿了這個 Entity，就可以訪問這個 Entity 對應的這些數據。Component 才是真正存儲數據的東西，但是這些數據是按照這些類型去統一歸類放在一起的。System 就是指我們的業務邏輯，通過讀取數據，處理數據，再把數據寫回去。就像我們去訪問數據庫一樣，把數據 select 出來，處理掉，再寫回數據庫，這個和數據庫的操作是非常像的。

ECS 架構面向的是什么？面向的是數據；思考的是什么？思考的是數據如何存儲和處理。

大家可以看到右邊這張圖，數據是分類存在一起的，所有同樣顏色的數據都會分類放在一起。比如左上角這一大塊的數據，我們縱向看，橙色、黃色、綠色、藍色，這些數據放在一起。但是橫向看，所有橙色的數據放在一個大數組里面，黃色的數據放在一個大數組里面等等，相當于幾個大數組羅列在一起，就是數據的排布了。先通過業務去設計我們的數據，再看我們業務會導致數據怎么樣進行流轉，這是在 ECS 架構里面去思考的非常重要的一個部分。

設計一個好的數據流轉，自然就能帶來非常好的性能。

對比一下面向對象，面向對象的特點是什么？封裝、繼承和多態，主要是注重可擴展性和可維護性。讓大家利用抽象，再加上很多好的設計模式，來降低人類對于軟件設計和維護上面的負擔。看上去面向對象是對于人類進行優化的一個方法。

對比一下，面向數據更多是面向機器執行進行思考，對于機器來講是一個非常舒服的狀態，自然就會很快。面向對象，對我們人來講會幫我們降低整個項目開發的難度，但實際上對機器來講是并不舒服的。

面向對象既然是對我們人類做出優化，必然要付出一些代價。ECS 面向機器進行一些優化，就會獲得一些好處，好處是什么？就是性能。當面向有性能要求的應用場景的時候，ECS 往往會獲得一些比較好的結果。

這里介紹一下 CPU 如何讀取數據。CPU 不能直接從內存里面讀數據，只能從Cache里面去讀數據。大家知道 CPU 有一、二、三級的 Cache，只能從一級的 Cache 里面去讀取數據。CPU 從一級的 Cache 里面讀取數據也是非常快的，但是內存相對于 CPU 來講是非常慢的。如果 CPU 要讀取的數據不在它的緩存里面，就需要等待非常漫長的過程，讓數據從內存加載到 Cache，再從 Cache 里面去讀這個數據。

理解了這個，來看一下通常情況下我們使用面向對象的模式去寫代碼，會導致這樣一個非常典型的面向對象的內存里面的數據分布。這時候問你一個問題，把所有的黃色的數據挑出來，對我們人類來講也是很難的事情。

如果換一張圖，按照 ECS 的方式，我讓你把所有的綠色數據都挑出來，對我們人類來講是很方便的，對于機器來講，對于 CPU 來講也是的。當我們去讀取第一個綠色數據的時候，我們現在的硬件 CPU 就會去猜第一個綠色數據附近的數據，會順帶把后面那些數據都加載進來。而在我們 ECS 里面，就會按照 CPU 的工作模式去使用這些數據，也就是我們訪問完第一個綠色，就會訪問第二個、第三個，這樣就充分利用現在硬件的架構。

當我們去處理數據的時候，在 ECS 里面大家應該怎么想呢？這個數據和剛才的圖一模一樣，只不過把它們按照顏色進行了對齊。這時候如果我告訴你說，我們去處理黃色和綠色的數據，你就可以把它理解成我是在遍歷黃色和綠色這兩個大數組，對我們程序員來講非常好理解，就是變成兩個大循環，去把它們進行處理。

這就是我們 ECS 架構的第一個優勢，對于硬件的緩存非常友好，可以幫助硬件發揮它的硬件性能。

再來看一下這張圖。這里面的 Entity 可以直接訪問豎向的資源。橫向是一個大數組。能看到這些黃色的、綠色的數據，天然是分塊的。既然分了塊，我們是不是可以用分置的方式去處理它們？也就是我們非常方便把這些一塊的數據都放在一個個單獨的線程里面分別處理，這樣能夠利用現在多核的 CPU 架構。所以 ECS 對于并行來講，也是一個非常好的方式。

看點兒不一樣的，這是我們引擎里面存儲 Transform 數據，如果大家做游戲的話，天天會和這些位置、旋轉、縮放打交道。最左邊的圖，是引擎里面現在去存儲位置、旋轉、縮放的信息，把它們放在一起。中間這個是 Unity Entities 現在的做法，把位置、旋轉、縮放拆成了 3 個，所有的位置信息放在一起，所有的旋轉信息放在一起，所有的縮放信息放在一起。最右邊的這一個，是在我們團結引擎的粒子系統里面采用的方式，甚至把位置的 X、Y、Z 三個分量也拆了出去，所有位置的 X 信息放在一起，Y 信息放在一起，Z 信息放在一起。

大家可以想一下，如果沒有 ECS 架構，把這些數據拆得如此稀碎，你在寫代碼的時候是一個很痛苦的過程，滿屏幕都是大數組，在添加刪除這些數據的時候都是會非常痛苦的。但是如果有了我們 ECS 架構，可以非常方便把數據拆成像中間或者右邊這樣的，看你業務的需要。正常情況下應該不會用到最右邊這樣非常極端的方式，因為我們粒子系統要求是不太一樣的。

這是 ECS 架構的第三個優勢，數據可以非常方便地以 SOA 的方式進行存儲。SOA 可以方便轉換成 SIMD 的指令，方便 CPU 使用 SIMD 去對數據的處理進行加速。

這里簡單對比一下 Unity 的 Entities，也就是大家能夠用到的 ECS 的包，和團結引擎的 ECS。左邊是 Unity 的 Entities，存儲是以16K的 chunk 為單位進行存儲，你可以認為它是固定大小的一個存儲。可以看下面幾個數據，正好不是 16K 的倍數，就會產生一些空間的浪費。像團結這邊，我們是以128個數據為一組一個單位，我們是定數據長度的，而不是定大小的，把它們整齊排列在一起。可以認為右邊很像一個 excel，只是根據數據的大小，把一列的寬度調整一下，它們仍然是能夠非常滿地存在這個表格里面。

這樣能夠獲得什么好處？如果使用 ECS，一個非常常用的 API 是 AddComponent，或者是 RemoveComponent。在左邊的 ECS 架構里面會付出一些代價，因為大小容量是固定的，當我們去添加或者刪除 Component 的時候，其他所有數據都會產生一次數據的拷貝。但是在團結定長的大小里面，當你添加或者是刪除一個 Component 的時候，我們只是需要把指針從這個位置移動到另外一個位置就好了，不會牽扯到數據的移動。

這里面有一些簡單的性能對比。在創建或者是刪除 Entity 的時候，因為大家在使用 ECS 的時候會牽涉到頻繁大量的數據創建和刪除。可以看到隨著創建數據量的增多，在團結的設計里面是能夠拿到越來越大的性能優勢的。

在 AddComponent 里面我們的優勢會相對大一些。在 Unity 的 Entity 中是需要復制和拷貝數據的，但對團結來講，我們只需要拷貝指針。

在 ECS 架構中我們經常會用到 Shared Component 進行數據的分組，我們對于 API 的設計和工作流各方面都進行了一些調整和優化，最終也是拿到了非常不錯的性能優勢。

ECS 架構高性能真相

今天的第二部分是 ECS 架構高性能的一些真相，里面包含了 Burst 編譯器和并行，這里面會分享一些也許會讓大家大開眼界的看法。

首先看一下Burst 編譯器。我在最開始使用 Burst 編譯器的時候經常會有三個問題：第一，它真的有那么快嗎？第二，它為什么快？第三，如果我們想做到那么快，真的只是需要添加一個 Burst Compile 這個標簽，奇跡就這么發生了嗎？你不覺得這個事情非常的簡單嗎？簡單我就認為一定會有問題。

這是我選擇的一個圖，在 Burst 剛發布的時候，有人拿 Burst 編譯器和其他的編譯器做了一些 benchmark。

先來看左邊的三列，是 Burst 編譯器，GCC 和 Clang，在同樣的算法情況下，會發現它們是在一個量級的，Burst 甚至要慢 10% 左右。大家能夠得到一個結論，Burst 編譯器和普通的 C/C++ 編譯器沒有什么區別，甚至還慢一點。

后面兩個是 IL2CPP 和 MonoJIT，MonoJIT 對應著我們在 Editor 里面看到的一個函數執行的時間長度。IL2CPP 就是大家打出來的包以后，只要用了 IL2CPP 能看到的性能大概是這樣的。如果用 Burst 和 IL2CPP 和 Mono 對比，它還是很好的。

看這個圖能得出一個結論，Burst 和普通的 C/C++ 編譯器編譯出來的效果是差不多的，甚至還要差一點，但是和 IL2CPP 和 MonoJIT 比是要更好的。如果你得到這個結論，你就掉到我的陷阱里面去了。

我們來看一下，首先 Burst 是 DOTS 一部分，它是HPC#的編譯器。HPC# 并不是 C#，也就意味著它不是一個通用的 C# 的語言。它是針對 ECS 場景做了很多特別的優化。剛才講了，ECS 是方便我們把數據組織成 SOA 的方式，也就是 Burst 對于 SOA 的數據會有一些特別的處理。Burst 還有一個唯一的依賴的 package，就是 Mathmatics。Burst 對于這里面，做了大量的優化。

Burst 編譯器既然是一個 DOTS 的編譯器，肯定有一些它特別的能力。它特別的能力就是向量化的能力，是它跟其他的通用編譯器非常不一樣的地方。也就是說對于像 HPC# 里面那些 NativeContainer，還有所有標注了 NoAlias 屬性的數據，它都會去做一些更激進的自動向量化的工作。如果沒有這個假設，像通用的編譯器很難做這種自動向量化的工作。向量化的數據結構，像 float3 和 float4，都是 Math 里面提供的數據。在 Burst 里面是直接會把 float3、float4 轉化成向量化的這些寄存器存儲起來的，不需要做另外的轉換。你會發現它在處理 float3 和 float4 的時候，生成的匯編代碼非常的精簡。

最后一個也是 Burst 快的一個非常重要的秘密，Mathmatics 提供了非常多的數學函數，這些數學函數在 Burst 編譯的時候，會直接映射成 Sleef 庫里面的實現。大家可以在 Github 上找，這個庫是開源的，是非常出名的一個 SIMD 的向量化的庫，也就是說很多函數你看到的實現和 Burst 編譯出來的實現是不一樣的，這是 Burst 里面非常大的一個秘密。

看一個代碼，這是我們在做粒子系統的時候有一個curve 采樣，這是采樣里面的核心代碼。這是一個點擊，最重要的是上面的公式，ax＾3+bx＾2+cx+d=[（ax-b）x+c]x+d，里面套一個乘加，外面也是一個乘加，最外面也是一個乘加。Mathmatics 庫里面也提供了 Math 的指令，如果用上面的這個實現的話，其實是等效的，但是我們把它上面的實現換成了下面的實現，經過測試我們的代碼快了3 倍。這是同樣的代碼，但是只是換了一個實現，快了 3 倍。

為什么呢？是因為現代 CPU 里面對于乘加這種計算是有專門的處理的，相當于乘加是一個特別的操作。在 Burst 編譯這段代碼的時候，就會把乘加換成相應的匯編指令，一般現代的 CPU 都有這樣的優化，它的速度是和你普通寫乘法和加法的速度是不一樣的，這是 Burst 里面非常重要的一些細節。

這是給大家一些建議，如果大家想去發揮 Burst 的實力，就不要只是拿 float 或者 int 做這種計算，你應該把你的數據盡量 pack 成一些 float2、float4 這樣的方式做數學計算，這樣你會獲得意想不到的性能提升。還有就是盡量要使用 Mathmatics package 里面提供的很多數據類型，這些 Burst 都會對它們進行一些特別的優化，因為 Burst 認識這些數據格式，會把它直接轉換成更高效的一些實現。所以它和普通編譯器的思路是不一樣的，普通編譯器是會把你的代碼當成一段黑盒，不知道代碼里面有什么東西，但是 Burst 認識 Mathmatics 庫，它認識 HPC#，它和 HPC# 之間是有約定的，所以 Burst 不是一個通用的編譯器。如果大家把它當成一個通用的編譯器去做測試，Burst 不會很快的。

另外，Position 是大家計算里面非常常用的，它是一個 float3，在我們的粒子系統實現里面，它是一個 X，一個 Y，一個 Z，三個分量都是拆開的，我們怎么對它進行優化呢？

看一個例子，這是一個位置的坐標變化，是一個矩陣乘法，就是 float 4×4，再乘一個 float 4，就是一些乘加乘加乘加，這里面有什么可以優化的嗎？

第一個想法，把 float4×4*float4，轉化成一個 float4×4*float4×3。這并不是一個標準的矩陣乘法，這里面 float4×3，是把 4 組 X、Y、Z 打包在一起，就是 4 個 X 放在一起，4 個 Y 放在一起，4 個 Z 放在一起，這樣形成了這么一個矩陣乘法。

能看到 float4 是 128 bit 的寬度，但是在我們 PC 上提供了 AVZ2 指令集，提供了 256 bit 寬度的向量化指令。我們就自然想到了，能不能把 float4 翻一倍變成 float8。

這樣就形成了下面的接口，把 float4×4*float4，變成 float4×4*float8×3，這樣我們可以一次處理 8 個位置，800 個 XYZ，但是代碼沒有任何變化，只不過數據格式從 4×3 變成了 8×3。

測一下，在 M2 的機器上，可以看到 float4×3 比單獨的一個 float4 要快 1.5 倍左右，float8×3 快 1.6 倍左右。差不多，這是因為在 Arm 芯片上，只有 128 bit 向量化的寬度，也就意味著這里面我們沒有拿到任何的好處，但是也沒有壞處，稍微快一點點。

但是如果在 PC 上，結果就不一樣了，因為有 AVX2 指令集的存在，我們的 float8×3 直接比 float4 快了 3.6 倍，如果你有大量數學計算的話，能夠帶來非常好的優勢。

剛才說完了 Burst，再來說一下并行，這一塊也比較復雜，我只是提一些問題。

第一個問題，在我們 Profiler 里面有一個非常好玩的圖，我們做粒子系統的時候嘗試把所有的東西都并行起來，但是并行的時候發現我們有一個地方實現的不好，異常的突出。這里我想反映一個現實，在一個并行系統里面，能夠決定這個并行系統快還是慢的，其實取決于最慢的那個 Job，因為所有人都會等這個 Job 執行完才會進行下面的操作。這是并行和并發不一樣的地方，并行強調的是同時開始和同時結束。如果說這里面有一個 Job 執行的慢，整個并行系統可能最后還是虧的，可能還不如單線程快。

因為這個事比較復雜，我就打算直接給大家講一些建議。首先大家一定要注意這個 Schedule 本身是有開銷的，包括線程調度、數據競爭，都會給你的整個并行系統帶來一些復雜性，并且如果你的數據設計不好的話，往往一個并行的算法可能還不如單線程來得快。像剛才我們已經把數學計算優化到極致的情況下，做 Profile 一般都是在 10 微秒這個尺度進行。如果一個乘法寫得不好，很可能就增加了 1 微秒，這樣我們很可能就虧掉了。

我可以給大家一個數據，像線程的調度和它的開銷應該是在 100 微秒左右，如果你的算法能夠優化到 10 微秒的級別，線程調度是一個非常可怕的開銷。還有數據競爭，會導致 Job 之間的依賴關系設置得非常不合理，本來能夠都并行在一起，但是因為有一些數據設計得不好，只能讓所有人去等那個最慢的，會出現剛才上面那張圖的情況，所以也要稍微注意。

給大家的建議，所有大于 1 毫秒的任務，大家再考慮放到 worker 里面去做，否則從開銷角度來講，你盡量在主線程里面寫一個 Burst 的靜態函數。從開銷的角度來講，一個 IJobFor.Schedule 的調用，會大于 IJobFor.Run，.Run 是在主線程的調用，也會大于一個 Burst 靜態函數的開銷。

Burst 靜態函數其實很簡單，寫一個 static 函數，它所有的傳入、傳出都是以引用的方式去做，在這里面你加上一個 BurstCompile 標簽，這應該比寫一個 Job 要來得簡單，這是大家應該最先做的事情。做完這個如果發現它還超過 1 毫秒，那你再去嘗試給它Job 化，這是我給大家一個非常重要的建議。

如果大家非得要使用多線程的話，一定要先合理去組織數據，把無關的數據用 SOA 的方式組織起來，把這些無關的數據分離；還有合理設置 Job 的依賴關系，要對你的業務有非常清楚的分析。如果說一個 Job 執行的時間非常短，在微秒級的話，更好的一個策略是把這些小 Job 合成一個大 Job，這樣可能反而執行得更快。

總結

總結一下，ECS 是面向 CPU 進行優化的程序架構，它和面向對象不一樣，大家在使用 ECS 的時候可能會感覺到一些不習慣，但是認識到它是對數據進行優化，按照數據進行思考，和人類大腦正常的思考方式不太一樣，只要適應了就都還好。

第二，盡量使用 SOA 的方式去組織代碼，組織數據，這樣 Burst 編譯器才能夠生成更高效的代碼。盡量使用像 float2、float4 這種高效的數據結構。要使用 Mathmatics 庫里面的函數，這樣至少能夠做到非常快。

第三，根據任務復雜度來確定是否使用多線程。如果說你是一個很快的，就不需要追求任何事情都是多線程的，反而把它變成一個 Burst 優化過的程序可能會是更好的選擇，先 Burst，然后再 Job。

這是我今天給大家帶來的所有分享，謝謝！

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發技能

每一個“點贊”、“在看”，都是我們前進的動力