Microsoft MVP성태의 닷넷 이야기
닷넷: 2163. .NET 8 - Dynamic PGO를 결합한 성능 향상 [링크 복사], [링크+제목 복사],
조회: 2869
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)
(시리즈 글이 5개 있습니다.)
닷넷: 2161. .NET Conf 2023 - Day 1 Blazor 개요 정리
; https://www.sysnet.pe.kr/2/0/13446

닷넷: 2163. .NET 8 - Dynamic PGO를 결합한 성능 향상
; https://www.sysnet.pe.kr/2/0/13448

닷넷: 2178. C# - .NET 8부터 COM Interop에 대한 자동 소스 코드 생성 도입
; https://www.sysnet.pe.kr/2/0/13470

닷넷: 2180. .NET 8 - 함수 포인터에 대한 Reflection 정보 조회
; https://www.sysnet.pe.kr/2/0/13475

닷넷: 2181. C# - .NET 8 JsonStringEnumConverter의 AOT를 위한 개선
; https://www.sysnet.pe.kr/2/0/13476




.NET 8 - Dynamic PGO를 결합한 성능 향상

이번 .NET Conf 2023의 내용을 보면,

Dynamic PGO (개요)
; https://youtu.be/xEFO1sQ2bUc?t=14689

Dynamic PGO (상세)
; https://www.youtube.com/watch?v=WrpYcGic9b8

Dynamic PGO(Profile Guided Optimization)를 결합한 성능 향상을 소개하고 있습니다. 사실 이 글에서 소개하는 모든 옵션은 .NET 7에서도 쓸 수 있으니,

Performance Improvements in .NET 7
; https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/

단지 성능을 더 높인 정도라고 봐야 합니다. 정말 그런지 한번 실습해 볼까요? ^^




성능 비교를 위해 아래의 예제 코드로 각각 .NET 7, .NET 8 프로젝트를 만들고,

// .NET Conf 2023 예제 코드 - Dynamic PGO
// https://youtu.be/xEFO1sQ2bUc?t=14689

using System.Diagnostics;
using System.Runtime.CompilerServices;

namespace ConsoleApp1
{
    internal class Program
    {
        static void Main(string[] args)
        {
            var list = new List<int>();
            Stopwatch sw = Stopwatch.StartNew();
            for (int loop = 0; loop < 3; loop++)  
            {
                sw.Restart();
                for (int i = 0; i < 1_000_000_000; i++)
                {
                    IsEmpty(list);
                }
                Console.WriteLine(sw.Elapsed.TotalSeconds);
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        static bool IsEmpty(List<int> list) => list.Count != 0;
    }
}

Dynamic PGO 옵션을 활성화한 다음, (혹은 csproj에 <TieredPGO>true</TieredPGO> 설정)

c:\temp\ConsoleApp1> set DOTNET_TieredPGO=1

실행해 보면 이런 결과가 나옵니다.

// [.NET 7 + PGO]
c:\temp\ConsoleApp1> dotnet .\ConsoleApp7\bin\Release\net7.0\ConsoleApp7.dll
1.5479958
1.4894338
1.5124722
1.5047404
1.5001046

// [.NET 8 + PGO]
c:\temp\ConsoleApp1> dotnet .\ConsoleApp8\bin\Release\net8.0\ConsoleApp8.dll
1.0941596
1.0035034
1.0044089
1.0028159
1.0046821

".NET Conf 세미나" 화면에서도 .NET 7의 경우 3.4 정도, .NET 8의 경우에는 1.6 정도로 절반 가까이 성능 차이가 났는데, 제 컴퓨터(Intel i9-12900K)에서는 1.5에서 1.0으로 약 33% 정도 향상되었습니다.

JIT 컴파일링이 어떻게 달라졌는지 DOTNET_JitDisasmSummary 환경 변수로 확인할 수 있다고 하는데요,

c:\temp\ConsoleApp1> set DOTNET_JitDisasmSummary=1

각각의 런타임에서 실행해 보면,

// [.NET 7 + PGO + DOTNET_JitDisasmSummary]

   1: JIT compiled System.Runtime.CompilerServices.CastHelpers:StelemRef(System.Array,long,System.Object) [Tier1, IL size=88, code size=93]
   2: JIT compiled System.Runtime.CompilerServices.CastHelpers:LdelemaRef(System.Array,long,ulong) [Tier1, IL size=44, code size=44]
   3: JIT compiled System.SpanHelpers:IndexOfNullCharacter(byref) [Tier1, IL size=792, code size=388]
   4: JIT compiled ConsoleApp1.Program:Main() [Instrumented Tier0, IL size=74, code size=320]
   5: JIT compiled ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]) [Instrumented Tier0, IL size=10, code size=40]
   6: JIT compiled ConsoleApp1.Program:Main() [Instrumented Tier1-OSR @0x25 with Dynamic PGO, IL size=74, code size=253]
   7: JIT compiled ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]) [Tier1, IL size=10, code size=10]
   8: JIT compiled System.Collections.Generic.List`1[int]:get_Count() [Tier1, IL size=7, code size=4]
   9: JIT compiled System.Text.ASCIIUtility:NarrowUtf16ToAscii(ulong,ulong,ulong) [Instrumented Tier0, IL size=490, code size=1373]
  10: JIT compiled System.SpanHelpers:SequenceCompareTo(byref,int,byref,int) [Tier1, IL size=632, code size=329]
1.5190925
1.4906073
1.4788726
1.4834886
1.4853625
  11: JIT compiled System.Buffer:Memmove(byref,byref,ulong) [Tier1 with Static PGO, IL size=480, code size=270]

.NET 7에서는 저렇게 2번의 "Instrumented Tier0", "Tier 1" 컴파일이 발생하지만, .NET 8에서는,

// [.NET 8 + PGO + DOTNET_JitDisasmSummary]

   1: JIT compiled System.Runtime.CompilerServices.CastHelpers:StelemRef(System.Array,long,System.Object) [Tier1, IL size=88, code size=93]
   2: JIT compiled System.Runtime.CompilerServices.CastHelpers:LdelemaRef(System.Array,long,ulong) [Tier1, IL size=44, code size=44]
   3: JIT compiled ConsoleApp1.Program:Main(System.String[]) [Instrumented Tier0, IL size=74, code size=324]
   4: JIT compiled ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]) [Tier0, IL size=10, code size=40]
   5: JIT compiled ConsoleApp1.Program:Main(System.String[]) [Tier1-OSR @0x25 with Dynamic PGO, IL size=74, code size=220]
   6: JIT compiled ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]) [Instrumented Tier0, IL size=10, code size=40]
   7: JIT compiled System.Collections.Generic.List`1[int]:get_Count() [Instrumented Tier1, IL size=7, code size=4]
   8: JIT compiled ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]) [Tier1, IL size=10, code size=10]
   9: JIT compiled System.Collections.Generic.List`1[int]:get_Count() [Tier1, IL size=7, code size=4]
1.0763641
1.0003451
0.9969336
0.9980177
  10: JIT compiled System.Buffer:Memmove(byref,byref,ulong) [Instrumented Tier1 with Static PGO, IL size=480, code size=581]
0.9961069

"Tier 0", "Instrumented Tier 0", "Tier 1" 총 3번의 JIT 컴파일 최적화가 이뤄집니다. 그런데, 위의 출력 결과를 다시 보면 2개 모두 다음과 같이,

// .NET 7 + PGO + DOTNET_JitDisasmSummary
...[생략]...
6: JIT compiled ConsoleApp1.Program:Main(<unnamed>) [Instrumented Tier1-OSR @0x25 with Dynamic PGO, IL size=74, code size=253]
...[생략]...

// .NET 8 + PGO + DOTNET_JitDisasmSummary
...[생략]...
5: JIT compiled ConsoleApp1.Program:Main(System.String[]) [Tier1-OSR @0x25 with Dynamic PGO, IL size=74, code size=220]
...[생략]...

(동영상과는 달리 Main 메서드에만) "Dynamic PGO" 문구가 있습니다. 그런데, 재미있는 것은, ^^; "DOTNET_TieredPGO" 옵션을 제거하고 다시 실행해 보면,

// .NET 7 + DOTNET_JitDisasmSummary
6: JIT compiled ConsoleApp1.Program:Main(<unnamed>) [Tier1-OSR @0x25, IL size=74, code size=445]

// .NET 8 + DOTNET_JitDisasmSummary
5: JIT compiled ConsoleApp1.Program:Main(System.String[]) [Tier1-OSR @0x25 with Dynamic PGO, IL size=74, code size=220]

저렇게 .NET 7의 경우 "Dynamic PGO"가 빠지지만, .NET 8은 여전히 남아 있습니다. 즉, 저 결과로만 본다면 PGO 옵션이 .NET 8에서는 기본적으로 활성화된 것입니다. 실제로 "set DOTNET_TieredPGO=0"이라고 명시적인 비활성화 옵션을 주고 실행해야만 .NET 8에서 다음과 같은 결과가 나옵니다.

// .NET 8 + PGO 비활성 + DOTNET_JitDisasmSummary
5: JIT compiled ConsoleApp1.Program:Main(System.String[]) [Tier1-OSR @0x25, IL size=74, code size=475]




개인적으로 흥미 있는 건 DOTNET_JitDisasm 옵션입니다. 이 옵션이 있는 줄 몰랐을 때는, 기계어로 번역된 코드를 얻으려면 windbg + sos 확장을 이용한 번거로운 절차를 거쳐야 했기 때문입니다. 어쨌든, 이것으로 원하는 메서드에 대해 JIT 컴파일 결과를 출력한다고 하는데요,

// 동영상에서는 콤마로 감싸는데,
set DOTNET_JitDisasm="IsEmpty"

// 제가 테스트한 바로는 콤마를 빼고 지정해야 합니다.
set DOTNET_JitDisasm=IsEmpty

.NET 7에서는 다음과 같이 2번의 JIT 컴파일 결과가 나오고,

// [.NET 7 + PGO + DOTNET_JitDisasm]

; Assembly listing for method ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]):bool
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; Tier-0 compilation
; MinOpts code
; instrumented for collecting profile data
; rbp based frame
; partially interruptible

G_M000_IG01:                ;; offset=0000H
       55                   push     rbp
       4883EC20             sub      rsp, 32
       488D6C2420           lea      rbp, [rsp+20H]
       48894D10             mov      gword ptr [rbp+10H], rcx

G_M000_IG02:                ;; offset=000EH
       488B4D10             mov      rcx, gword ptr [rbp+10H]
       3909                 cmp      dword ptr [rcx], ecx
       FF15369F0F00         call     [System.Collections.Generic.List`1[int]:get_Count():int:this]
       85C0                 test     eax, eax
       0F95C0               setne    al
       0FB6C0               movzx    rax, al

G_M000_IG03:                ;; offset=0022H
       4883C420             add      rsp, 32
       5D                   pop      rbp
       C3                   ret

; Total bytes of code 40

; Assembly listing for method ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]):bool
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; Tier-1 compilation
; optimized code
; rsp based frame
; partially interruptible
; No PGO data
; 0 inlinees with PGO data; 1 single block inlinees; 0 inlinees without PGO data

G_M000_IG01:                ;; offset=0000H

G_M000_IG02:                ;; offset=0000H
       33C0                 xor      eax, eax
       83791000             cmp      dword ptr [rcx+10H], 0
       0F95C0               setne    al

G_M000_IG03:                ;; offset=0009H
       C3                   ret

; Total bytes of code 10

.NET 8에서는 3번의 JIT 컴파일 결과가 나옵니다.

// [.NET 8 + PGO + DOTNET_JitDisasm]

; Assembly listing for method ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]):bool (Tier0)
; Emitting BLENDED_CODE for X64 with AVX - Windows
; Tier0 code
; rbp based frame
; partially interruptible

G_M000_IG01:                ;; offset=0x0000
       push     rbp
       sub      rsp, 32
       lea      rbp, [rsp+0x20]
       mov      gword ptr [rbp+0x10], rcx

G_M000_IG02:                ;; offset=0x000E
       mov      rcx, gword ptr [rbp+0x10]
       cmp      dword ptr [rcx], ecx
       call     [System.Collections.Generic.List`1[int]:get_Count():int:this]
       test     eax, eax
       setne    al
       movzx    rax, al

G_M000_IG03:                ;; offset=0x0022
       add      rsp, 32
       pop      rbp
       ret

; Total bytes of code 40

; Assembly listing for method ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]):bool (Instrumented Tier0)
; Emitting BLENDED_CODE for X64 with AVX - Windows
; Instrumented Tier0 code
; rbp based frame
; partially interruptible

G_M000_IG01:                ;; offset=0x0000
       push     rbp
       sub      rsp, 32
       lea      rbp, [rsp+0x20]
       mov      gword ptr [rbp+0x10], rcx

G_M000_IG02:                ;; offset=0x000E
       mov      rcx, gword ptr [rbp+0x10]
       cmp      dword ptr [rcx], ecx
       call     [System.Collections.Generic.List`1[int]:get_Count():int:this]
       test     eax, eax
       setne    al
       movzx    rax, al

G_M000_IG03:                ;; offset=0x0022
       add      rsp, 32
       pop      rbp
       ret

; Total bytes of code 40

; Assembly listing for method ConsoleApp1.Program:IsEmpty(System.Collections.Generic.List`1[int]):bool (Tier1)
; Emitting BLENDED_CODE for X64 with AVX - Windows
; Tier1 code
; optimized code
; rsp based frame
; partially interruptible
; No PGO data
; 0 inlinees with PGO data; 1 single block inlinees; 0 inlinees without PGO data

G_M000_IG01:                ;; offset=0x0000

G_M000_IG02:                ;; offset=0x0000
       xor      eax, eax
       cmp      dword ptr [rcx+0x10], 0
       setne    al

G_M000_IG03:                ;; offset=0x0009
       ret

; Total bytes of code 10

그런데, .NET 8의 "Tier 0", "Instrumented Tier 0" 컴파일 결과는 동일한데다가 3번째 "Tier 1"의 컴파일 결과는 .NET 7의 두 번째 "Tier 1" 컴파일 결과와 같습니다. 즉, 저 결과로만 보면 쓸데없는 작업이 .NET 8에 들어간 것인데, 그래도 성능이 저렇게 빠른 거 보면 원래 .NET 8 런타임 자체가 빠른 건지도 모르겠습니다. ^^;

참고로, 아래의 도구들을 사용하면 더 쉽게 JIT 컴파일 결과를 알 수 있습니다.

Disasmo
; https://marketplace.visualstudio.com/items?itemName=EgorBogatov.Disasmo

Sharplab
; https://sharplab.io/




그렇다면, 아예 기본값이 활성 상태인 TieredCompilation 옵션 자체를 끄고 실행하면 어떨까요?

// .NET Core 2 이하의 환경에서 기본값이 비활성
// .NET Core 3 이상의 환경에서 기본값이 활성 상태
SET DOTNET_TieredCompilation=0

그럼, PGO를 사용했던 것보다 더 빠르게 실행이 됩니다.

// .NET 7 + Tiered Compilation 없이 실행 (PGO도 함께 자동으로 비활성)
0.8113732
0.7983001
0.8145982
0.8106876
0.799827

// .NET 8 + Tiered Compilation 없이 실행 (PGO도 함께 자동으로 비활성)
0.7899068
0.7979388
0.7953996
0.7973212
0.7974282

여기서 한 가지 오해하지 말아야 할 것이 있습니다. "Tiered Compilation" 기능은 프로그램의 "성능"을 높이는 목적이 아닌, "초기 JIT 컴파일 속도"를 높이기 위해 만들어졌다는 사실입니다.

즉, 시간이 많이 걸리는 최적화 JIT 빌드를 모든 코드에 대해 수행해 초기 로딩 속도를 늦추기보다는, 몇 번 실행되지도 않는 코드들은 (최적화 단계 없이) 일단 실행만 되게 고속으로 JIT 컴파일 시키고, 이후에 천천히 최적화를 하는 것이 "Tiered Compilation"입니다.

따라서, 저런 결과가 나오는 것이 정상입니다.

그런 관점에서 .NET 8의 PGO를 다시 바라볼 필요가 있습니다. 이것 역시, 오히려 DOTNET_TieredPGO=0으로 옵션을 명시적으로 비활성화시키고 실행하면 .NET 7에서 .NET 8보다 빠른 결과를 보입니다.

// .NET 7 + PGO 없이 실행 (DOTNET_TieredPGO=0, 기본값이므로 설정 유무에 상관없음)
1.1310844
1.016918
1.0223791
1.0211129
1.0194825

// .NET 8 + PGO 없이 실행 (DOTNET_TieredPGO=0, 반드시 설정해야 비활성화됨)
1.4378975
1.3701194
1.3651987
1.3690431
1.3692595

저걸 굳이 해석해 보자면, .NET 7은 Tiered Compilation이 2단계로 단순하게 나누어져 있는 반면, .NET 8은 Tiered Compilation을 좀 더 세분화해서 3단계로 나뉘었다고 보면 될 듯합니다. 아마도 저렇기 때문에 .NET 8은 PGO를 기본 옵션으로 활성화시켰다는 것으로 해석할 수 있습니다.

하지만, 이렇게 3단계로 나뉜 .NET 8의 초기 로딩 속도가 얼마나 효율적인지는 테스트로 확인하는 것이 좀 애매합니다. 왜냐하면, RAM/Disk Cache나 Cold/Warm 실행에 따른 성능 변수가 오히려 더 클 수 있기 때문입니다.

암튼, 그냥 긍정적인 방향으로 정리해 보면, .NET 8은 초기 (JIT 컴파일을 포함하는) 로딩 속도를 보완하기 위해 3단계 Tiered Compilation을 적절한 수준으로 구현했다... 정도로 보면 되겠습니다. ^^

(2023-11-23 업데이트) 위의 예제만으로는 실망스러울 수 있지만, "Dynamic PGO (상세)" 영상에 나오는 GDV, Profile-Guided Inlining 등의 예제를 보면 분명히 성능 향상이 될 수 있는 여지가 많습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/30/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...
NoWriterDateCnt.TitleFile(s)
12561정성태3/12/20218856VS.NET IDE: 159. Visual Studio에서 개행(\n, \r) 등의 제어 문자를 치환하는 방법 - 정규 표현식 사용
12560정성태3/11/202110168개발 환경 구성: 549. ssh-keygen으로 생성한 개인키/공개키 파일을 각각 PKCS8/PEM 형식으로 변환하는 방법
12559정성태3/11/20219611.NET Framework: 1028. 닷넷 5 환경의 Web API에 OpenAPI 적용을 위한 NSwag 또는 Swashbuckle 패키지 사용 [2]파일 다운로드1
12558정성태3/10/20219081Windows: 192. Power Automate Desktop (Preview) 소개 - Bitvise SSH Client 제어 [1]
12557정성태3/10/20217756Windows: 191. 탐색기의 보안 탭에 있는 "Object name" 경로에 LEFT-TO-RIGHT EMBEDDING 제어 문자가 포함되는 문제
12556정성태3/9/20217010오류 유형: 703. PowerShell ISE의 Debug / Toggle Breakpoint 메뉴가 비활성 상태인 경우
12555정성태3/8/20219055Windows: 190. C# - 레지스트리에 등록된 DigitalProductId로부터 라이선스 키(Product Key)를 알아내는 방법파일 다운로드2
12554정성태3/8/20218856.NET Framework: 1027. 닷넷 응용 프로그램을 위한 PDB 옵션 - full, pdbonly, portable, embedded
12553정성태3/5/20219321개발 환경 구성: 548. 기존 .NET Framework 프로젝트를 .NET Core/5+ 용으로 변환해 주는 upgrade-assistant, try-convert 도구 소개 [4]
12552정성태3/5/20218587개발 환경 구성: 547. github workflow/actions에서 Visual Studio Marketplace 패키지 등록하는 방법
12551정성태3/5/20217492오류 유형: 702. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly. (2)
12550정성태3/5/20217154오류 유형: 701. Live Share 1.0.3713.0 버전을 1.0.3884.0으로 업데이트 이후 ContactServiceModelPackage 오류 발생하는 문제
12549정성태3/4/20217678오류 유형: 700. VsixPublisher를 이용한 등록 시 다양한 오류 유형 해결책
12548정성태3/4/20218445개발 환경 구성: 546. github workflow/actions에서 nuget 패키지 등록하는 방법
12547정성태3/3/20218986오류 유형: 699. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly.
12546정성태3/3/20218584개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/2/202111314.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [10]
12544정성태2/26/202111533.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태2/26/20219874VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태2/20/202112220개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법 [1]
12541정성태2/18/20219479개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태2/17/20219796.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/20219704Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/202110115.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202111166.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/202110138개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...