CPU 效能分析與改善 (一) 觀念篇

主旨

筆者過去被指派多次改善CPU效能的項目，累積了一些心得可以分享
因此本系列將以UE4為範例，預計提供一些觀念，標準流程，技巧給大家參考
讓大家都可以更快的入門，避免走一些曾經走過的冤枉路。

本篇不會提到太多UE4相關的技巧，會以效能分析與改善的觀念為主。

隨時審視自己的行為

在作效能改善的過程中，一定要隨時知道自己在改善什麼，
做了這個項目在最佳情況可以改善多少。
不要一股腦兒的投入某個細項，結果其實改善微乎其微。

CPU bound? GPU bound?

本系列要提的是CPU效能的改進，不會提GPU 改進的相關部份。
不過先了解自己的遊戲到底是CPU bound還是GPU bound
絕對是首先最重要的事情。

如何知道遊戲是不是CPU Bound?

在UE4要知道這件事很容易，將你的遊戲放到目標平台上
使用console command stat unit 並觀察CPU與GPU佔用的時間
CPU過高就是CPU bound，GPU過高就是GPU bound。
都很高的話，就挑嚴重的先處理吧。

謹記80/20原則

80/20原則是個概念，可以套用在很多的事情上(可以無限上綱的意思)
在這邊提的意思是，大多數程式執行的總時間只在執行少部分的程式碼。
所以我們在做效能改善的時候，只處理少部分的程式碼就可以改善最多的效能。

不要用猜的來改善效能

改善效能的流程請務必從量測效能開始，
偷懶跳過這個步驟，用"直覺"來改善效能的話
下場就是很容易成為80/20原則的反向教材，
花了80%的時間只改善效能的20%。

 這是經驗談，就算是有經驗的老手也會中招。
畢竟一個遊戲系統很大，每個人都會知道自己經手的系統哪裡效能不佳。
如果直接分配一段時間(例如一週)，讓每個人改善自己的系統效能。
這種作法是最浪費，最沒有效率的，因為效率瓶頸可能根本就不在某人上。

 又例如說某個系統有一段寫法很暴力或是用了很多層迴圈，
花了大把時間去改善，結果這段程式碼只執行一次，也不會影響畫面卡頓。
那麼這個時間應該要省下來去作別的項目。

藉由量測效能估算極限

先從量測效能開始的另一個好處是可以很快知道極限在哪裏。
拿到效能數據，有經驗的話很快就可以預測出要讓fps達標，
總共需要改善多少系統。
就算沒有經驗也可以推估一個大概的方向。

 舉例來說，根據量測的結果，現在距離fps達標還有3ms要改進。
佔用前幾名的A系統佔用3ms，B系統佔用1.5ms，C系統佔用0.5ms
尋找各系統的開發者，詢問他們
系統改進方案，是屬於可移除/可改善？
改進難度，是屬於極難/中等/極簡單？

 假設評估結果
A是極難/可改善，B系統是中等/可改善，C系統是可移除/極簡單
那麼就可以稍為訂出目標為改善B與C
估算ABC三個系統大概可以改進(0.5+0.5)，代表還有2ms需要找其他系統改進。
亦或是要花時間投資在A項目上。

時間寶貴 更要斤斤計較

很多時候我們沒有太多的時間可以作效能改善
遊戲說不定只有一個禮拜或兩個禮拜就要發了才跟你說現在要調效能
(這不是經驗談，只是假設)

注意量測的目標平台

特別注意你現在的目標是哪個平台，請針對平台處理。
完全不建議在編輯器量測平台，除非你明確知道編輯器與打包後的差異。

 如果是server/client架構的話通常效能瓶頸也會差很多，
例如UE4的架構AI幾乎只能在server執行，client不會有AI。
如果現在在意的是client端的FPS，那就直接忘了AI很貴的存在吧

 至於有沒有要每次都在目標平台做分析，這個我反而持保留的態度。
因為很多平台的出版本很耗費時間，不利於頻繁地來回測試與驗證。

 這時候我會建議一開始用同一個版本出各個目標平台。
例如(PC, iOS, Android)
然後以相似的測試條件錄製效能報告。
比對不同平台的測試報告，確認系統的瓶頸是不是大同小異

 例如說各系統所佔的CPU比例在所有平台都差不多，只是絕對值的差別。
(PC 0.1ms，iOS 1ms之類的)
如果差不多，那可以先專注在PC改善就好。
如果有平台特別異常的項目，就要紀錄下來，納入改善的考量。

標準作業流程

首先大家要清楚知道在調整效能的時候是大家都需要幫忙的
但是瓶頸分析可以一個人做就好。
其他人依照分析的方向作改進會比較有效率。

 所以這邊分享一下之前試過一次，
覺得不錯的一個作業流程 經過幾次的調整就可以有效率的達到目標)
  1. 錄製多平台，每平台多個效能檔
  2. 使用分析工具確認效能瓶頸沒有受到不同測試環境而有極大的差異
  3. 列出應該調整的瓶頸項目
  4. 詢問項目開發人員改進方案與難易度
  5. 制訂改進目標
  6. 分發工作項目
  7. 著手進行改善
  8. 回到步驟1驗收

項目1與2目的是避免只錄一次會有偏差，
我曾經遇過只對某一次測試結果分析，結果某個很貴的角色在該次測試沒出現
最後多花了時間處理這個角色。

項目3就比較偏向如何使用工具來找瓶頸，比較偏一些心得與技巧，會在之後的文章介紹。

項目4,5,6,7 就是前面提到的項目，重點就是挑風險低，改善多的項目先下手。

結論

以上講了一些過去的心得與自己的觀念，
之後預計會介紹如何在UE4 Profile CPU，如何使用Unreal Frontend。
Blueprint(BP)轉C++的衡量，以及一些曾經遇過常常是瓶頸的項目。
不過我只列出大綱，時間都未訂就是了XD

留言

張貼留言

這個網誌中的熱門文章

UE4 除錯技巧分享 (一)

圖片
俗話說的好 給他魚吃不如教他釣魚 今天要分享幾個我平常在用的技巧 心理建設 如果你是有程式背景，但是正在用blueprint(BP)開發。 那我會建議你要先幫自己做好心裡建設。 你在用的是開發原始碼的引擎， 遇到問題時應該儘量往引擎內部追， 不要馬上就找繞過(workaround)的方法或求救。 那樣作你很快就會想放棄，因為無法進步，遇到問題無法自救。 硬體設備 雖說是技巧心得，理論上要跟硬體無關，但是這個真的要講一下。 想追code一定要準備好2個螢幕以上，至少一個螢幕是UE4 Editor，另一個是Visual Studio。 單螢幕的話光是切換視窗就亂掉了。 技巧分享 這裡面的技巧應該比較零散，所以可以跳著看。 不寫Code就直接顯示變數值在螢幕上 如果問我只能寫一條的話，我一定選這一條。 這個是我第一常用的技巧了，大部分我們想到要得知某一個值，就是跑去Actor或是Component的Tick裡面下PrintString，這樣資訊就會顯示在畫面上。如下圖。 可是有的時候bug是機率出現的，好不容易bug發生了，想看某個值是否異常，但是當下卻沒有埋PrintString，難道只能放棄了嗎？ 其實沒有，引擎提供了強大的console command "DisplayAll"，讓我們可以直接拿到變數值並顯示於螢幕。如圖。 DisplayAll的使用方法是： DisplayAll [ClassName] [PropertyName] 大小寫無分別，所以可以不管大小寫。 ClassName的部份，可分為C++與BP class兩種。 如果你要追查的class是C++ class，那麼直接輸入C++的名稱就好， 但是要去除第一個字。例如 AActor應該輸入Actor 想知道movement移動速度的最大值可下 displayall charactermovementcomponent maxwalkspeed 如果你要追查的class是BP，那麼你要輸入[BP的名稱_C]， 舉例來說 有一個BP名稱為BP_CodeTraceActor 裡面有一個變數是value 那麼要輸入的是 DisplayAll BP_CodeTraceActor_c value PropertyName的部份，只要這個變數有被定義為UPROPERTY，就可以拿到值。BP所有的
閱讀完整內容

UE4 GameplayAbilitySystem - GameplayEffect & GameplayCue 如何設定參數

圖片
[前言]  這篇文章主要是關於UE4 GameplayAbilitySystem中GameplayEffect的細項介紹 在專案內我們大量使用GameplayEffect的各種用法來達成不同的Gameplay 而GameplayEffect有一大堆的參數, 讓我們在使用上遇到不少問題 寫這篇文章就是希望其他開發者不用走一次我們走過的冤枉路 [簡介]  先列出GameplayEffect可設定參數中的分類, 每個分類內在本文會有更詳細的介紹 GameplayEffect Tags - Tag的新增與移除 Modifiers - 修改AttributeSet內的Value Duration Policy - 不同的時間執行規則, 很多功能只有特定duration policy才會生效 Conditional Gameplay Effects - 額外apply的effect, 可以設定apply條件 Application - 這個效果能否套用的條件 Period - 週期執行 Display - 演出 Expiration - 結束後追加效果 Immunity - 這個效果套用時, 對其他效果免疫的設定 Stack - 同樣Effect的堆疊處理 Overflow - 堆疊溢出時追加效果 Grant Ability - "Give" Ability, 不會自動Activate GameplayCue GameplayCue Tag - GameplayEffect跟GameplayCue是透過GameplayTag關聯 [本文] Tags GameplayEffectAssetTag 這個effect的tag, 在做一些remove, immunity之類的檢查欄位 GrantedTag 當Effect apply後, 會同時賦予角色的tags OngoingTag Requirements 這個tag的玩法很像是遙控炸彈的概念, 先把炸彈的effect裝在某個對象上 滿足OngoingTag的時候effect就會active( tag有
閱讀完整內容

UE4 GameplayAbilityTask介紹

圖片
簡介 本篇介紹的是UE4引擎的Gameplay Ability System(GAS)中的AbilityTask系列。 不知道什麼是GAS的話可以參考先前的文章 GameplayAbilities System介紹 (一) https://yekdniwue.blogspot.com/2018/08/gameplayabilities-sytem.html GameplayAbilities System介紹 (二) https://yekdniwue.blogspot.com/2018/09/gameplayabilities-system.html UE4 GameplayAbilitySystem - GameplayEffect & GameplayCue 如何設定參數 https://yekdniwue.blogspot.com/2019/06/GameplayEffectAndCue.html Gameplay AbilityTask介紹 AbilityTask建立了大量的範例，作為示範，很多ASC內部的系統與其他系統的溝通都做在AbilityTask內。 而AbilityTask則是要在Gameplay Ability內串流程的時候使用，AbilityTask節點不會出現在一般的Blueprint(BP)內 所以當了解完如何使用ASC，如何創造一個GameplayAbility，以及GameplayEffect後。 應該先試著了解GameplayTask，可以對ASC能夠做到的事情，如何做事情有更深刻的了解。 以下是引擎提供的Tasks，這些都可以在 Engine\Plugins\Runtime\GameplayAbilities\Source\GameplayAbilities\Private\Abilities\Tasks\ 裡面找到 RootMotion ApplyRootMotion_Base ApplyRootMotionConstantForce ApplyRootMotionJumpForce
閱讀完整內容