Microsoft MVP성태의 닷넷 이야기
닷넷: 2163. .NET 8 - Dynamic PGO를 결합한 성능 향상 [링크 복사], [링크+제목 복사],
조회: 2950
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13241정성태2/3/20234003디버깅 기술: 188. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.IO.FileNotFoundException
13240정성태2/1/20234166디버깅 기술: 187. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.Web.HttpException
13239정성태2/1/20233849디버깅 기술: 186. C# - CacheDependency의 숨겨진 예외 - System.Web.HttpException
13238정성태1/31/20235972.NET Framework: 2092. IIS 웹 사이트를 TLS 1.2 또는 TLS 1.3 프로토콜로만 운영하는 방법
13237정성태1/30/20235648.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
13236정성태1/29/20235171개발 환경 구성: 663. openssl을 이용해 인트라넷 IIS 사이트의 SSL 인증서 생성
13235정성태1/29/20234774개발 환경 구성: 662. openssl - 윈도우 환경의 명령행에서 SAN 적용하는 방법
13234정성태1/28/20235884개발 환경 구성: 661. dnSpy를 이용해 소스 코드가 없는 .NET 어셈블리의 코드를 변경하는 방법 [1]
13233정성태1/28/20237272오류 유형: 840. C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생
13232정성태1/27/20234947스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233958오류 유형: 839. python - TypeError: '...' object is not callable
13230정성태1/26/20234329개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
13229정성태1/25/20235338.NET Framework: 2090. C# - UDP Datagram의 최대 크기
13228정성태1/24/20235458.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20235131개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20234810.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20234012개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20234444Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20234609오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20234303개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20234470Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20234574오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20234190Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
13218정성태1/17/20234087VS.NET IDE: 178. Visual Studio 17.5 (Preview 2) - 포트 터널링을 이용한 웹 응용 프로그램의 외부 접근 허용
13217정성태1/13/20234704디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
13216정성태1/12/20234958디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...