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

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

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

今天給大家?guī)淼膬蓚€大的話題，一個是 ECS 架構(gòu)的簡介，給大家?guī)硪恍┱J知層面上的感受，ECS 為什么快？第二會告訴大家，ECS 快的真相是什么？是用了 ECS 就一定快嗎？第三，能不能更快？

ECS 架構(gòu)簡介

接下來進入 ECS 架構(gòu)的主題，分了三部分，首先介紹一下什么是 ECS 架構(gòu)；第二，和面向?qū)ο笞鲗Ρ龋坏谌覀優(yōu)槭裁匆褂?ECS 架構(gòu)？

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

ECS 架構(gòu)面向的是什么？面向的是數(shù)據(jù)；思考的是什么？思考的是數(shù)據(jù)如何存儲和處理。

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

設計一個好的數(shù)據(jù)流轉(zhuǎn)，自然就能帶來非常好的性能。

對比一下面向?qū)ο螅嫦驅(qū)ο蟮奶攸c是什么？封裝、繼承和多態(tài)，主要是注重可擴展性和可維護性。讓大家利用抽象，再加上很多好的設計模式，來降低人類對于軟件設計和維護上面的負擔。看上去面向?qū)ο笫菍τ谌祟愡M行優(yōu)化的一個方法。

對比一下，面向數(shù)據(jù)更多是面向機器執(zhí)行進行思考，對于機器來講是一個非常舒服的狀態(tài)，自然就會很快。面向?qū)ο螅瑢ξ覀內(nèi)藖碇v會幫我們降低整個項目開發(fā)的難度，但實際上對機器來講是并不舒服的。

面向?qū)ο蠹热皇菍ξ覀內(nèi)祟愖龀鰞?yōu)化，必然要付出一些代價。ECS 面向機器進行一些優(yōu)化，就會獲得一些好處，好處是什么？就是性能。當面向有性能要求的應用場景的時候，ECS 往往會獲得一些比較好的結(jié)果。

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

理解了這個，來看一下通常情況下我們使用面向?qū)ο蟮哪Ｊ饺懘a，會導致這樣一個非常典型的面向?qū)ο蟮膬?nèi)存里面的數(shù)據(jù)分布。這時候問你一個問題，把所有的黃色的數(shù)據(jù)挑出來，對我們?nèi)祟悂碇v也是很難的事情。

如果換一張圖，按照 ECS 的方式，我讓你把所有的綠色數(shù)據(jù)都挑出來，對我們?nèi)祟悂碇v是很方便的，對于機器來講，對于 CPU 來講也是的。當我們?nèi)プx取第一個綠色數(shù)據(jù)的時候，我們現(xiàn)在的硬件 CPU 就會去猜第一個綠色數(shù)據(jù)附近的數(shù)據(jù)，會順帶把后面那些數(shù)據(jù)都加載進來。而在我們 ECS 里面，就會按照 CPU 的工作模式去使用這些數(shù)據(jù)，也就是我們訪問完第一個綠色，就會訪問第二個、第三個，這樣就充分利用現(xiàn)在硬件的架構(gòu)。

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

這就是我們 ECS 架構(gòu)的第一個優(yōu)勢，對于硬件的緩存非常友好，可以幫助硬件發(fā)揮它的硬件性能。

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

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

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

這是 ECS 架構(gòu)的第三個優(yōu)勢，數(shù)據(jù)可以非常方便地以 SOA 的方式進行存儲。SOA 可以方便轉(zhuǎn)換成 SIMD 的指令，方便 CPU 使用 SIMD 去對數(shù)據(jù)的處理進行加速。

這里簡單對比一下 Unity 的 Entities，也就是大家能夠用到的 ECS 的包，和團結(jié)引擎的 ECS。左邊是 Unity 的 Entities，存儲是以16K的 chunk 為單位進行存儲，你可以認為它是固定大小的一個存儲。可以看下面幾個數(shù)據(jù)，正好不是 16K 的倍數(shù)，就會產(chǎn)生一些空間的浪費。像團結(jié)這邊，我們是以128個數(shù)據(jù)為一組一個單位，我們是定數(shù)據(jù)長度的，而不是定大小的，把它們整齊排列在一起。可以認為右邊很像一個 excel，只是根據(jù)數(shù)據(jù)的大小，把一列的寬度調(diào)整一下，它們?nèi)匀皇悄軌蚍浅M地存在這個表格里面。

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

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

在 AddComponent 里面我們的優(yōu)勢會相對大一些。在 Unity 的 Entity 中是需要復制和拷貝數(shù)據(jù)的，但對團結(jié)來講，我們只需要拷貝指針。

在 ECS 架構(gòu)中我們經(jīng)常會用到 Shared Component 進行數(shù)據(jù)的分組，我們對于 API 的設計和工作流各方面都進行了一些調(diào)整和優(yōu)化，最終也是拿到了非常不錯的性能優(yōu)勢。

ECS 架構(gòu)高性能真相

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一個想法，把 float4×4*float4，轉(zhuǎn)化成一個 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，但是代碼沒有任何變化，只不過數(shù)據(jù)格式從 4×3 變成了 8×3。

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

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

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

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

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

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

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

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

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

總結(jié)

總結(jié)一下，ECS 是面向 CPU 進行優(yōu)化的程序架構(gòu)，它和面向?qū)ο蟛灰粯樱蠹以谑褂?ECS 的時候可能會感覺到一些不習慣，但是認識到它是對數(shù)據(jù)進行優(yōu)化，按照數(shù)據(jù)進行思考，和人類大腦正常的思考方式不太一樣，只要適應了就都還好。

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

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

這是我今天給大家?guī)淼乃蟹窒恚x謝！

Unity 官方微信

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

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