Microsoft MVP성태의 닷넷 이야기
개발 환경 구성: 383. BenchmarkDotNet 사용 시 주의 사항 [링크 복사], [링크+제목 복사]
조회: 12550
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

BenchmarkDotNet 사용 시 주의 사항

BenchmarkDotNet으로,

BenchmarkDotNet 라이브러리 소개
; https://www.sysnet.pe.kr/2/0/11547

struct 타입을 좀 더 테스트해봤습니다.

C# 7.2의 특징 - GC 및 메모리 복사 방지를 위한 struct 타입 개선
; https://www.sysnet.pe.kr/2/0/11546

성능 비교를 위해 다음의 타입들을 생성하고,

ClassVector                 : class로 구현
StructVector                : struct로 구현
InStructVector              : StructVector이고, op_Addition 메서드의 인자를 in 처리
ReadonlyInStructVector      : InStructVector이고, readonly struct로 정의
ReadonlyInlineStructVector  : ReadonlyInStructVector이고, op_Addition에 AggressiveInlining 특성 부여

각각의 타입에 대해 op_Addition을 테스트하는 코드만을 Benchmark에 추가했습니다.

public class VectorBenchmark
{
    [Benchmark]
    public void ClassVectorTest()
    {
        var player = new ClassVector(10.0, 20.0, 30.0);
        var speed = new ClassVector(10.0, 20.0, 30.0);
        var result = player + speed;
    }

    [Benchmark]
    public void StructVectorTest()
    {
        var player = new StructVector(10.0, 20.0, 30.0);
        var speed = new StructVector(10.0, 20.0, 30.0);
        var result = player + speed;
    }

    [Benchmark]
    public void InStructVectorTest()
    {
        var player = new InStructVector(10.0, 20.0, 30.0);
        var speed = new InStructVector(10.0, 20.0, 30.0);
        var result = player + speed;
    }

    [Benchmark]
    public void ReadonlyInStructVectorTest()
    {
        var player = new ReadonlyInStructVector(10.0, 20.0, 30.0);
        var speed = new ReadonlyInStructVector(10.0, 20.0, 30.0);
        var result = player + speed;
    }

    [Benchmark]
    public void ReadonlyInlineStructVectorTest()
    {
        var player = new ReadonlyInlineStructVector(10.0, 20.0, 30.0);
        var speed = new ReadonlyInlineStructVector(10.0, 20.0, 30.0);
        var result = player + speed;
    }
}

결과는 이렇습니다.

// * Summary *

BenchmarkDotNet=v0.10.14, OS=Windows 10.0.17134
Intel Core i5-4670 CPU 3.40GHz (Haswell), 1 CPU, 4 logical and 4 physical cores
  [Host]     : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3101.0
  DefaultJob : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3101.0


                             Method |       Mean |     Error |    StdDev |
----------------------------------- |-----------:|----------:|----------:|
                    ClassVectorTest | 13.7698 ns | 0.1722 ns | 0.1611 ns |
                   StructVectorTest |  2.5874 ns | 0.0320 ns | 0.0299 ns |
                 InStructVectorTest | 10.5442 ns | 0.0892 ns | 0.0834 ns |
         ReadonlyInStructVectorTest | 10.2489 ns | 0.0843 ns | 0.0788 ns |
     ReadonlyInlineStructVectorTest |  0.5599 ns | 0.0106 ns | 0.0099 ns |

메서드가 inline 처리된 StructVectorTest, ReadonlyInlineStructVectorTest의 성능이 우세한 것은 당연해 보이고, 또한 그 둘 중에서도 복사가 발생하지 않는 ReadonlyInlineStructVectorTest의 성능이 좀 더 높게 나옵니다.

이 상태에서 테스트 코드마다 GetHashCode 호출을 추가했더니,

public void ...VectorTest()
{
    var player = new ...Vector(10.0, 20.0, 30.0);
    var speed = new ...Vector(10.0, 20.0, 30.0);
    var result = player + speed;

    result.GetHashCode();
}

단지 하나의 코드를 추가했을 뿐인데 이제 결과가 완전히 달라집니다.

                             Method |       Mean |     Error |    StdDev |
----------------------------------- |-----------:|----------:|----------:|
                    ClassVectorTest | 34.8412 ns | 0.2300 ns | 0.2151 ns |
                   StructVectorTest | 47.8031 ns | 0.3171 ns | 0.2966 ns |
                 InStructVectorTest | 53.4127 ns | 1.2505 ns | 1.4401 ns |
         ReadonlyInStructVectorTest | 52.1917 ns | 0.3648 ns | 0.3412 ns |
     ReadonlyInlineStructVectorTest | 39.5150 ns | 0.2622 ns | 0.2452 ns |

확인은 해보지 않았지만, GetHashCode 시 값 형식에서 object.GetHashCode 호출로 인한 내부 박싱이 발생해 힙을 사용하도록 변경된 것이 아닌가 예상됩니다. 일단 그건 그렇다 치고, 문제는 모든 Vector 코드에 GetHashCode를 다음과 같이 직접 구현했을 때 발생합니다.

public override int GetHashCode()
{
    return (int)(_x + _y + _z);
}

그럼, 각각의 결과물들이 다음과 같이 바뀝니다.

// GetHashCode() 추가
                             Method |       Mean |     Error |    StdDev |
----------------------------------- |-----------:|----------:|----------:|
                    ClassVectorTest | 15.7360 ns | 0.1863 ns | 0.1651 ns |
                   StructVectorTest | 10.0317 ns | 0.0746 ns | 0.0623 ns |
                 InStructVectorTest | 12.0021 ns | 0.0687 ns | 0.0643 ns |
         ReadonlyInStructVectorTest | 11.8757 ns | 0.1092 ns | 0.1022 ns |
     ReadonlyInlineStructVectorTest |  0.0000 ns | 0.0000 ns | 0.0000 ns |

ReadonlyInlineStructVectorTest의 결과가 놀라운데요, 어떻게 저럴 수 있을까요? 저 때의 JIT 코드를 windbg로 살펴보면 다음과 같이 나옵니다.

0:000> !DumpMD /d 00007ffa11f47790
Method Name:  ConsoleApp1.VectorBenchmark.ReadonlyInlineStructVectorTest()
Class:        00007ffa11f54858
MethodTable:  00007ffa11f477a8
mdToken:      0000000006000007
Module:       00007ffa11f470d0
IsJitted:     yes
CodeAddr:     00007ffa11ea6450
Transparency: Critical

0:000> !U /d 00007ffa11ea6450
Normal JIT generated code
ConsoleApp1.VectorBenchmark.ReadonlyInlineStructVectorTest()
Begin 00007ffa11ea6450, size 1
>>> 00007ffa`11ea6450 c3              ret

보는 바와 같이 정상적인 테스트 코드를 생성하지 못하고 ret만 포함하는 메서드로 테스트하고 있는 것입니다. 따라서 BenchmarkDotNet으로 성능 측정을 할 때는 그 자체의 버그나 Release 모드에서의 최적화에 따른 의도치 않은 코드 삭제를 주의해야 합니다.

게다가 전통적인 Stopwatch를 이용할 때는 Visual Studio 내에서 disassembly 코드를 보며 곧바로 확인할 수 있는 여지가 있는데, BenchmarkDotNet으로 하게 되면 ConsoleApp1.exe의 자식 프로세스로 임시 exe 프로세스를 생성시켜 성능 측정을 하기 때문에 그런 부분을 파헤치기가 불편한 점도 있습니다.




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







[최초 등록일: ]
[최종 수정일: 6/14/2018]

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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  57  [58]  59  60  ...
NoWriterDateCnt.TitleFile(s)
12175정성태3/8/202010570개발 환경 구성: 477. "Docker Desktop for Windows"의 "Linux Container" 모드를 위한 tcp 바인딩 추가
12174정성태3/7/202010123개발 환경 구성: 476. DockerDesktopVM의 파일 시스템 접근 [3]
12173정성태3/7/202011104개발 환경 구성: 475. docker - SQL Server 2019 컨테이너 실행 [1]
12172정성태3/7/202015997개발 환경 구성: 474. docker - container에서 root 권한 명령어 실행(sudo)
12171정성태3/6/202010923VS.NET IDE: 143. Visual Studio - ASP.NET Core Web Application의 "Enable Docker Support" 옵션으로 달라지는 점 [1]
12170정성태3/6/20209574오류 유형: 599. "Docker Desktop is switching..." 메시지와 DockerDesktopVM CPU 소비 현상
12169정성태3/5/202011597개발 환경 구성: 473. Windows nanoserver에 대한 docker pull의 태그 사용 [1]
12168정성태3/5/202012286개발 환경 구성: 472. 윈도우 환경에서의 dockerd.exe("Docker Engine" 서비스)가 Linux의 것과 다른 점
12167정성태3/5/202011519개발 환경 구성: 471. C# - 닷넷 응용 프로그램에서 DB2 Express-C 데이터베이스 사용 (3) - ibmcom/db2express-c 컨테이너 사용
12166정성태3/4/202011171개발 환경 구성: 470. Windows Server 컨테이너 - DockerMsftProvider 모듈을 이용한 docker 설치
12165정성태3/2/202010853.NET Framework: 900. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 네 번째 이야기(Monitor.Enter 후킹)파일 다운로드1
12164정성태2/29/202011721오류 유형: 598. Surface Pro 6 - Windows Hello Face Software Device가 인식이 안 되는 문제
12163정성태2/27/202010151.NET Framework: 899. 익명 함수를 가리키는 delegate 필드에 대한 직렬화 문제
12162정성태2/26/202012913디버깅 기술: 166. C#에서 만든 COM 객체를 C/C++로 P/Invoke Interop 시 메모리 누수(Memory Leak) 발생 [6]파일 다운로드2
12161정성태2/26/20209580오류 유형: 597. manifest - The value "x64" of attribute "processorArchitecture" in element "assemblyIdentity" is invalid.
12160정성태2/26/202010272개발 환경 구성: 469. Reg-free COM 개체 사용을 위한 manifest 파일 생성 도구 - COMRegFreeManifest
12159정성태2/26/20208472오류 유형: 596. Visual Studio - The project needs to include ATL support
12158정성태2/25/202010267디버깅 기술: 165. C# - Marshal.GetIUnknownForObject/GetIDispatchForObject 사용 시 메모리 누수(Memory Leak) 발생파일 다운로드1
12157정성태2/25/202010152디버깅 기술: 164. C# - Marshal.GetNativeVariantForObject 사용 시 메모리 누수(Memory Leak) 발생 및 해결 방법파일 다운로드1
12156정성태2/25/20209470오류 유형: 595. LINK : warning LNK4098: defaultlib 'nafxcw.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
12155정성태2/25/20208805오류 유형: 594. Warning NU1701 - This package may not be fully compatible with your project
12154정성태2/25/20208651오류 유형: 593. warning LNK4070: /OUT:... directive in .EXP differs from output filename
12153정성태2/23/202011322.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202011043.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/22/202011569.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202011426.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
... 46  47  48  49  50  51  52  53  54  55  56  57  [58]  59  60  ...