上一篇寫服務端的文章《MQTTnet4入門(一)實現服務端》已經是去年年底,現在MQTTnet的版本是4.2.1.781,總的來說改動不大。下麵以新版為例實現一個客戶端。 var mqttClientOptions = new MqttClientOptionsBuilder() .WithTcpS ...
作者: zyl910
目錄一、引言
前面的幾篇文章里,介紹了 C# 編寫向量演算法的各種辦法。
雖然也做了一些基準測試,初步驗證了向量演算法的效率高。但是由於 CPU睿頻、其他進程搶占CPU資源 等原因,基準測試的結果不太穩定,有時難以評價哪種向量演算法的效率更高。
這時便需要檢查一下程式運行時的彙編代碼,從而能進行更精準的分析。
例如彙編代碼里的這些情況, 會影響程式的性能:
- 以函數調用的方式來使用內在函數。內在函數的運行時間,一般僅是個位數的時鐘周期;而函數調用因存在參數壓棧、在棧中保存寄存器 等操作,會花費數十個時鐘周期或更長的時間。而以Release方式運行程式時,正常情況下會以內聯(inline)的方式使用內在函數,即直接使用CPU指令,而不是函數調用。
- 對於變數訪問存在多餘的讀寫記憶體操作,未充分利用寄存器(Register)。當以內聯的方式使用內在函數時,是使用CPU內部的寄存器來傳遞參數的。寄存器與CPU同頻工作,速度比記憶體快好幾個數量級。正常情況下,僅當寄存器數量不夠用時,才需要使用棧記憶體來暫存中間變數,這會拖慢速度。有時向量版代碼編寫的不夠好,就容易遇到“超過了寄存器數量”問題。檢查彙編代碼,可以發現這種問題。
- 存在多餘的越界檢查等安全檢查。
……
C# 程式編譯時,只是編譯為IL(Intermediate Language,中間語言)的代碼。
隨後在真機上運行時,通過JIT(just in time,即時編譯)技術,將IL再編譯為本機代碼(Native Code),從而使程式運行。
使用 ildasm、ILSpy 等工具進行反編譯時,只能看到IL代碼,而不是運行時的本機彙編代碼。
若想查看運行時的本機彙編代碼,得用其他辦法。
二、辦法說明
2.1 基本辦法
若想查看運行時彙編代碼,最簡單的辦法是使用Visual Studio的“Disassembly”功能。
具體辦法是:在Visual Studio里打開程式的解決方案,並設置斷點。按“F5”運行程式直至遇到斷點,然後點擊菜單欄里的“DEBUG”(調試)->“Windows”(視窗)->“Disassembly”(反彙編)。
在“Disassembly”菜單項的旁邊,還有一個“Registers”(寄存器)菜單項,可以用來查看CPU的各個寄存器。這對調試彙編代碼很有用。
對於 C# 程式,目前Visual Studio還不支持“查看AVX寄存器信息”,會發現它的數據為灰色字體。僅在運行 C/C++
程式時,可以用該視窗查看AVX的寄存器。
C# 僅是看不了AVX寄存器而已,“Registers”視窗仍然能查看 SSE寄存器、通用寄存器 等內容。
2.2 Release程式如何設置斷點
在Visual Studio里,可通過“在某行代碼的左側點擊滑鼠左鍵”的辦法,設置斷點。
在Debug模式下運行時,該辦法一般是有效的。而在Release模式下運行時,大多數時候會發現斷點沒生效。
這可能是因為Release模式下進行了很多編譯優化,導致斷點失效了。
初步發現僅Visual Studio 2022在調試 .NET 7.0
程式時,斷點在Release模式運行時有效。而低版本的,一般沒成功。
所以對於Release模式下運行的程式,我們需要用另一種辦法來設置斷點。
辦法就是使用 Debugger.Break
來主動觸發斷點. 它的名稱空間是 System.Diagnostics
.
using System.Diagnostics;
Debugger.Break();
// ...
2.3 如何避免“分層編譯”的誤導
設置好斷點後,按“F5”運行Release模式的程式。隨後會發現一個情況——怎麼內在函數全部是函數調用方式運行的?這種方式的效率很低啊。
別慌,這是 .NET
的“分層編譯”技術所導致的。
為了提高程式的啟動速度,.NET
推出了“分層編譯”技術。即在程式啟動時,幾乎不進行編譯優化,而是以最簡單、最快的辦法進行即時編譯(JIT),使程式能在很短的時間內啟動。隨後JIT會監控程式的熱點代碼, 對熱點代碼進行 慢速的、複雜的二次編譯,此時才會使用多種編譯優化手段。例如改為內聯使用內在函數,而不是函數調用。
為了查看編譯優化後的彙編代碼,需要在熱點代碼運行後才觸發斷點。
此時有一個技巧——先按原來的辦法對函數進行基準測試,隨後在基準測試代碼的後面,插入“Debugger.Break”,並再調用一次測試函數。
因為在對函數進行基準測試時,會使該函數變為熱點代碼,觸發編譯優化。基準測試完畢遇到“Debugger.Break”時會暫停執行,便能打開“Disassembly”視窗。然後單步運行,從而查看彙編代碼。
為了不影響程式發佈, 可以建立useBreakPoint變數。隨後根據該變數寫分支語句,寫好斷點時相關代碼。
修改後的代碼如下。
bool useBreakPoint = true;
// SumVectorAvxRef.
tickBegin = Environment.TickCount;
rt = SumVectorAvxRef(src, count, loops);
msUsed = Environment.TickCount - tickBegin;
mFlops = countMFlops * 1000 / msUsed;
scale = mFlops / mFlopsBase;
tw.WriteLine(indent + string.Format("SumVectorAvxRef:\t{0}\t# msUsed={1}, MFLOPS/s={2}, scale={3}", rt, msUsed, mFlops, scale));
if (useBreakPoint) {
Debugger.Break();
rt = SumVectorAvxRef(src, count, 1);
}
2.4 實際演練(彙編調試)
2.4.1 進入斷點
按照上面辦法修改好程式,並將程式切換為Release方式,然後按“F5”(或工具欄的運行按鈕)運行程式。
程式運行一段時間後,斷點觸發了,Visual Studio的C#源碼
視窗,會停在“Debugger.Break”的下一行 C# 代碼上。如下圖。
此時點擊點擊菜單欄里的“DEBUG”(調試)->“Windows”(視窗)->“Disassembly”(反彙編)。
隨即便打開了“Disassembly”視窗,能查看本機的彙編代碼。例如這臺電腦是X86架構,於是彙編代碼是X86的。如下圖。
“Disassembly”視窗里不僅展示了彙編代碼,且還將對應的 C# 代碼也一起展示。註意有些時候因為編譯優化等原因,對應的 C# 代碼沒能一起展示。此次閱讀彙編代碼會稍微吃力一些,需人工翻閱 C# 代碼, 思考對照關係.
格式說明——
- C# 代碼。格式為
前導空格 + C#行號 + 冒號(:) + 多個空格 + C#代碼
. - 彙編代碼。格式為
十六進位地址 + 多個空格 + 彙編指令
.
173: rt = SumVectorAvxRef(src, count, 1);
00007FF95A68985B mov rcx,rdi
00007FF95A68985E mov edx,1000h
00007FF95A689863 mov r8d,1
00007FF95A689869 call Method stub for: BenchmarkVector.BenchmarkVectorDemo.SumVectorAvxRef(Single[], Int32, Int32) (07FF95A680FB0h)
這裡的3個“mov”指令,是使用寄存器傳遞參數。最後用“call”指令,調用測試函數(SumVectorAvxRef).
可參考C#代碼中函數的參數列表, 弄清楚這3個“mov”指令所對應的參數。
mov rcx,rdi
。它對應函數的float[] src
參數。即float[] src = new float[count];
。mov edx,1000h
。它對應函數的int count
參數。即const int count = 1024*4;
。1024*4
的結果是4096
, 用十六進位表示就是1000h
.mov r8d,1
。它對應函數的int loops
參數。即1
。
2.4.2 單步調試
“Disassembly”視窗也支持“F11”單步調試等快捷鍵。註意此時不再以 “一條C#語句” 為單位, 而是以“一條彙編指令” 為單位。
按3次“F11”,跳過了3個“mov”指令,當前語句是“call”指令。此時再按一次“F11”,便能進入該函數。如下圖。
上面的截圖裡,展示了“Disassembly”視窗的快捷菜單,其中有如下的查看選項。
- Show Address:顯示彙編代碼的地址。
- Show Source Code:顯示 C# 源碼。
- Show Code Bytes:顯示代碼的位元組。即顯示機器碼。
- Show Symbol Names:顯示符號名。
- Show Line Numbers:顯示 C# 源碼的行號。
- Show Toolbar:顯示工具欄。即此視窗頂部的“Viewing Options”工具欄。
上述截圖裡,還展示了“cntBlock”欄位是如何計算的,結果會保存到“eax”寄存器。彙編代碼摘錄如下。
734: int cntBlock = count / nBlockWidth; // Block count.
00007FF95A68CBDC mov eax,edx ; eax = edx; 註意edx是函數的輸入參數 `int count`。
00007FF95A68CBDE sar eax,1Fh ; eax >>= 1Fh; “1Fh”是十進位的“31”,這個帶符號移位是為了獲得edx的符號. 0或正數會得到“0”,負數會得到“-1”(FFFFFFFFh).
00007FF95A68CBE1 and eax,7 ; eax &= 7
00007FF95A68CBE4 add eax,edx ; eax += edx
00007FF95A68CBE6 sar eax,3 ; eax >>= 3; 因為此時 nBlockWidth 為8,可優化為右移3位.
為了便於讀者閱讀,我在上述彙編代碼的後面加了註釋,用 ;
(分號)隔開。
這一段代碼使用了一種常見的編譯優化手段——“將除法優化為移位”。且由於是帶符號數,有可能為負數,於是在右移前對數據進行了一些轉換。
上述截圖裡,還展示了“vrt”欄位是如何清零的,它使用了“ymm1”寄存器。彙編代碼摘錄如下。
736: Vector256<float> vrt = Vector256<float>.Zero; // Vector result.
00007FF95A68CBFE vxorps ymm1,ymm1,ymm1 ; ymm1 = ymm1^ymm1 = 0; 將同一個數進行“xor”運算, 結果為0, 這便完成了“賦值為0”的工作.
2.4.3 觀察主迴圈的彙編代碼
由於程式已經運行到該函數內,於是可以不用進行單步調試了。可直接拖動滾動條,查看主迴圈的彙編代碼。如下圖。
由於有 C# 語句做對照,所以能很快定位關鍵代碼。例如下麵這幾條彙編語句,是計算“p0”的初始值(數組中首個元素的引用)
00007FF95A68CC18 add rcx,10h ; rcx += 10h
740: ref Vector256<float> p0 = ref Unsafe.As<float, Vector256<float>> (ref src[0]); // Pointer for src data.
00007FF95A68CC1C mov r10,rcx ; r10 = rcx
註意rcx是函數的輸入參數 float[] src
。加上 10h
後,使rcx改為指向“數組中首個元素的地址”。10h
與 .NET
內部的數組記憶體佈局有關, 不同的處理器架構, 該值不同。
雖然 Unsafe.As
寫起來比較冗長, 但這些冗長內容,只是為了滿足 C# 的語法檢查,它的本質是“賦值”。於是並不需要調用Unsafe.As
等函數, 僅用1條“mov”指令就行。
接下來可以觀察向量處理的關鍵迴圈(Vector processs)。彙編代碼摘錄如下。
741: // Vector processs.
742: for (i = 0; i < cntBlock; ++i) {
00007FF95A68CC1F xor r11d,r11d ; r11d = r11d^r11d = 0; 這是for的“i = 0”部分.
742: for (i = 0; i < cntBlock; ++i) {
00007FF95A68CC22 test eax,eax ; 檢查eax(cntBlock)是否小於等於(le)零。若為真,會用下一條語句跳轉到“00007FF95A68CC37h”,即迴圈外.
00007FF95A68CC24 jle BenchmarkVector.BenchmarkVectorDemo.SumVectorAvxRef(Single[], Int32, Int32)+067h (07FF95A68CC37h) ; 若為假, 則往下執行.
743: vrt = Avx.Add(vrt, p0); // Add. vrt += vsrc[i];
00007FF95A68CC26 vaddps ymm1,ymm1,ymmword ptr [r10] ; ymm1 = ymm1 + [r10]; 該指令的最後一個參數可以是記憶體地址,便從 r10(p0)載入了數據。註意ymm1是累加結果變數“vrt”.
00007FF95A68CC2B add r10,20h ; r10 + 20h; 對應 `p0 = ref Unsafe.Add(ref p0, 1);`. 使r10寄存器指向下一筆數據. 向量類型的長度是256位,為32位元組,既十六進位的“20h”.
742: for (i = 0; i < cntBlock; ++i) {
00007FF95A68CC2F inc r11d ; ++r11d; 這是for的“++i”部分.
00007FF95A68CC32 cmp r11d,eax ; 這是for的“i < cntBlock”部分. 若為真,會用下一條語句跳轉到“07FF95A68CC26h”,即迴圈內的第一條語句.
00007FF95A68CC35 jl BenchmarkVector.BenchmarkVectorDemo.SumVectorAvxRef(Single[], Int32, Int32)+056h (07FF95A68CC26h) ; 若為假, 則往下執行, 離開迴圈.
748: for (i = 0; i < cntRem; ++i) {
00007FF95A68CC37 xor r11d,r11d
可以看出,上面的彙編代碼的質量很高——
- 不僅對內在函數做了內聯優化, 且將引用的相關操作(
Unsafe.As
、Unsafe.Add
)也做了內聯, 轉成了高效率的地址計算指令。 - 充分利用了寄存器,避免了慢速的棧記憶體。
三、結語
還可以對照一下SumVectorAvxPtr運行時的彙編代碼, 會發現它與SumVectorAvxRef的幾乎是一樣的。這就是“引用版函數與指針版函數的性能幾乎一致”的原因,現在有彙編代碼為證。
這也是 第2篇文章 發現“C# 向量演算法與C++版向量演算法的性能幾乎一致”的原因。因為它們都已經被編譯為高效率的彙編代碼。
除了“Disassembly”視窗外,還可以使用 WinDbg、BenchmarkDotNet、CoreCLR命令行 等辦法來查看彙編代碼。有興趣的讀者,可以查看 Nemanja Mijailovic 的文章.
參考文獻
- Microsoft《Debugger.Break 方法》. https://learn.microsoft.com/zh-cn/dotnet/api/system.diagnostics.debugger.break?view=net-7.0
- Leon_Chaunce《.NET Core 2.1中的分層編譯(預覽)》. https://www.cnblogs.com/xiaoliangge/p/9441988.html
- Nemanja Mijailovic《Exploring .NET Core platform intrinsics: Part 3 - Viewing the code generated by the JIT》. https://mijailovic.net/2018/07/05/generated-code/
- zyl910《
C# 使用SIMD向量類型加速浮點數組求和運算(1):使用Vector4、Vector<T>
》. https://www.cnblogs.com/zyl910/p/dotnet_simd_BenchmarkVector1.html - zyl910《
C# 使用SIMD向量類型加速浮點數組求和運算(2): C# 通過Intrinsic直接使用AVX指令集操作 Vector256<T>,及C++程式對比
》. https://www.cnblogs.com/zyl910/p/dotnet_simd_BenchmarkVector2.html - zyl910《
C# 使用SIMD向量類型加速浮點數組求和運算(3):迴圈展開
》. https://www.cnblogs.com/zyl910/p/dotnet_simd_BenchmarkVector3.html - zyl910《
C# 使用SIMD向量類型加速浮點數組求和運算(4):用引用代替指針, 擺脫unsafe關鍵字,兼談Unsafe類的使用
》. https://www.cnblogs.com/zyl910/p/dotnet_simd_BenchmarkVector4.html