Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

C#에서 return할 때 명시적으로 casting한 것과 안한 것의 차이

아래와 같은 질문이 있군요. ^^

c#에서 return할 때 명시적으로 casting한것과 안한것의 차이
; http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_QnA_etc&no=4117&z=

문제를 정리하면 다음의 2가지 메서드 구현중에서,

static float GetLengthSqaure(float a, float b)
{
    return (float)((a * a) + (b * b));
}

static float GetLengthSqaure2(float a, float b)
{
    return (a * a) + (b * b);
}

Release 모드로 빌드했을 때 "(float)((a * a) + (b * b))"의 형변환을 한 경우가 더 빠르다는 것입니다.

사실 이 문제는 다음의 답변에서 했던 것과 같은 방식으로 살펴볼 수 있습니다.

C# - 부동소수 계산 왜 이렇게 나오죠? (1)
; https://www.sysnet.pe.kr/2/0/10872

즉, 비주얼 스튜디오의 디스어셈블리 창을 이용하면 된다는 것입니다. ^^

그래도 간단하게 살펴볼까요?

일단, For 루프 안에 생성된 기계어를 보면 Debug 모드에서는 동일합니다. 하지만 Release 모드에서는 (float) 형변환을 한 경우 다음과 같은 코드가 생성됩니다.

// ====== GetLengthSqaure

            for (int k = 0; k < cnt; k++)
01092E71 33 D2                xor         edx,edx  
01092E73 85 DB                test        ebx,ebx  
01092E75 7E 1C                jle         01092E93  
            {
                for (int j = 0; j < nested; j++)
01092E77 33 C0                xor         eax,eax  
                for (int j = 0; j < nested; j++)
01092E79 85 F6                test        esi,esi  
01092E7B 7E 11                jle         01092E8E  
01092E7D DD D8                fstp        st(0)  
01092E7F D9 05 64 2F 09 01    fld         dword ptr ds:[1092F64h]  
01092E85 40                   inc         eax  
01092E86 3B C6                cmp         eax,esi  
01092E88 7D 04                jge         01092E8E  
01092E8A DD D8                fstp        st(0)  
01092E8C EB F1                jmp         01092E7F  
            for (int k = 0; k < cnt; k++)
01092E8E 42                   inc         edx  
01092E8F 3B D3                cmp         edx,ebx  
01092E91 7C E4                jl          01092E77  
                }
            }

잘 보시면, for 루프 안에 call이 없습니다. 즉, GetLengthSqaure 메서드가 인라인 최적화가 된 것입니다.

반면, 형변환을 하지 않은 경우 다음과 같은 코드가 생성됩니다.

            for (int k = 0; k < cnt; k++)
00FE0B2A 33 D2                xor         edx,edx  
00FE0B2C 89 55 EC             mov         dword ptr [ebp-14h],edx  
00FE0B2F 83 7D F0 00          cmp         dword ptr [ebp-10h],0  
00FE0B33 7E 2C                jle         00FE0B61  
            {
                for (int j = 0; j < nested; j++)
00FE0B35 33 F6                xor         esi,esi  
                for (int j = 0; j < nested; j++)
00FE0B37 85 FF                test        edi,edi  
00FE0B39 7E 1B                jle         00FE0B56  
00FE0B3B DD D8                fstp        st(0)  
00FE0B3D 68 BC 74 13 3E       push        3E1374BCh  // 0.144f
00FE0B42 68 89 41 A0 3E       push        3EA04189h  // 0.313f
00FE0B47 FF 15 1C 4D E9 00    call        dword ptr ds:[0E94D1Ch]  
00FE0B4D 46                   inc         esi  
00FE0B4E 3B F7                cmp         esi,edi  
00FE0B50 7D 04                jge         00FE0B56  
00FE0B52 DD D8                fstp        st(0)  
00FE0B54 EB E7                jmp         00FE0B3D  
            for (int k = 0; k < cnt; k++)
00FE0B56 FF 45 EC             inc         dword ptr [ebp-14h]  
00FE0B59 8B 45 EC             mov         eax,dword ptr [ebp-14h]  
00FE0B5C 3B 45 F0             cmp         eax,dword ptr [ebp-10h]  
00FE0B5F 7C D4                jl          00FE0B35  
                }
            }

보는 바와 같이, 메서드 호출을 그대로 하고 있기 때문에 그만큼 속도가 느려진 것입니다.




더욱 재미있는 것은, 인라인된 GetLengthSqaure의 for 루프 내 코드입니다.

                for (int j = 0; j < nested; j++)
01092E79 85 F6                test        esi,esi  
01092E7B 7E 11                jle         01092E8E  
01092E7D DD D8                fstp        st(0)  
01092E7F D9 05 64 2F 09 01    fld         dword ptr ds:[1092F64h]  
01092E85 40                   inc         eax  
01092E86 3B C6                cmp         eax,esi  
01092E88 7D 04                jge         01092E8E  
01092E8A DD D8                fstp        st(0)  
01092E8C EB F1                jmp         01092E7F  

저기서 ds:[1092F64h] 주소값을 확인해 보면 0x3df31b9b 값이 들어있었는데, 이는 0.118704997...를 의미합니다. 따라서 GetLengthSqaure 메서드는 인라인된 것도 아니고, 아예 JIT 컴파일러가 값을 이미 계산한 상태였고 런타임시 ds:[1092F64h] 주소에서 곧바로 이용하고 있는 것입니다.

일단, 왜 빠른지 이유는 알 수 있지만 왜 (float)를 명시한 경우에만 저런 최적화가 되는지는 JIT 컴파일러 팀만이 알 수 있습니다.

굳이 예상해 보면, 아마도 이번 역시 "C# - 부동소수 계산 왜 이렇게 나오죠? (1)" 글과 유사한 맥락에서 이해할 수 있지 않을까 싶습니다. 80비트의 ST0 부동 소수점 레지스터의 값을 이용하는데, GetLengthSqaure는 내부 코드 수준에서 이미 (float) 제한을 해버렸기 때문에 인라인을 할 수 있었고, 인라인하고 보니 고정된 오퍼랜드(0.144f, 0.313f)여서 값을 미리 계산한 것이 아닌가 싶습니다. 반면 2번째는 메서드 수준에서는 반환값이 float이긴 하지만 인라인되어야 할 코드 수준에서 결정되지 않았으므로 (안전을 위해.... 또는 반환값까지 체크하는 것이 귀찮아서... 또는 몰라서... 등등의 이유로) 그냥 메서드 호출로 남긴 것이 아닐까 추측만 해봅니다.

참고로, x86 JIT 컴파일러보다 x64 JIT 컴파일러가 더 최적화를 잘 하도록 만들어졌기 때문에 x64로 빌드하면 위의 속도차이는 거의 없습니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




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







[최초 등록일: ]
[최종 수정일: 7/17/2021]

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

비밀번호

댓글 작성자
 



2016-03-17 01시43분
마지막에 말씀하신 "x86 JIT 컴파일러보다 x64 JIT 컴파일러가 더 최적화를 잘 하도록 만들어졌기 때문에 x64로 빌드하면 위의 속도차이는 거의 없습니다" 라는 말씀은 얼마전 제가 겪었던 x64 JIT컴파일러의 공격적 최적화에 의해 MethodImpl(MethodImplOptions.NoInlining) 어트리뷰트가 무시되던 상황이 떠올라서...안구에 습기가...ㅜㅜ
재미있게 읽었습니다^^
Beren Ko
2016-03-17 06시55분
제 생각이지만, 마이크로소프트가 x86 JIT 컴파일러에 대해서는 거의 변경을 하지 않는 쪽으로 자세를 취하는 것 같습니다. RyuJIT도 x64에서만 적용시켰죠. ^^ 아마도 x86이 점점 더 입지가 좁아지기 때문에 x64에 역량을 집중하는 듯합니다.
정성태

... 106  107  108  109  110  111  [112]  113  114  115  116  117  118  119  120  ...
NoWriterDateCnt.TitleFile(s)
11125정성태1/7/201724436개발 환경 구성: 310. IIS - appcmd.exe를 이용해 특정 페이지에 클라이언트 측 인증서를 제출하도록 설정하는 방법
11124정성태1/4/201727838개발 환경 구성: 309. 3년짜리 유효 기간을 제공하는 StartSSL [2]
11123정성태1/3/201723350.NET Framework: 629. .NET Core의 dotnet.exe CLI 명령어 확장 방법 [1]
11122정성태1/3/201722814.NET Framework: 628. TransactionScope에 사용자 정의 트랜잭션을 참여시키는 방법 [2]파일 다운로드1
11121정성태1/1/201720708개발 환경 구성: 308. "ASP.NET Core Web Application (.NET Core)"와 "ASP.NET Core Web Application (.NET Framework)" 차이점
11120정성태12/25/201626585개발 환경 구성: 307. ASP.NET Core Web Application을 IIS에서 호스팅하는 방법
11119정성태12/23/201649275개발 환경 구성: 306. Visual Studio Code에서 Python 개발 환경 구성 [2]
11118정성태12/22/201636023오류 유형: 374. Python 64비트 설치 시 0x80070659 오류 발생 [3]
11117정성태12/21/201622326웹: 35. nopCommerce 예제 사이트 구성 방법
11116정성태12/21/201624285디버깅 기술: 84. NopCommerce의 Autofac 부하(CPU, Memory) [2]
11115정성태12/21/201627254Windows: 133. 윈도우 서버 2016에서 플래시가 동작하지 않는 경우 [2]
11114정성태12/19/201637283Windows: 132. 역슬래시(backslash) 문자가 왜 통화 표기 문자(한글인 경우 "\")로 보일까요? [2]
11113정성태12/6/201621137오류 유형: 373. ICOMAdminCatalog::GetCollection에서 CO_E_ISOLEVELMISMATCH(0x8004E02F) 오류 발생파일 다운로드1
11112정성태11/23/201626308오류 유형: 372. MySQL 서비스가 올라오지 않는 경우 - Error 1067
11111정성태11/23/201634793.NET Framework: 627. C++로 만든 DLL을 C#에서 사용하기 [2]
11110정성태11/17/201621500.NET Framework: 626. Commit 메모리가 낮은 상황에서도 메모리 부족(Out-of-memory) 예외 발생 [2]
11109정성태11/17/201621489.NET Framework: 625. ASP.NET에서 System.Web.HttpApplication 인스턴스는 다중으로 생성됩니다.
11108정성태11/13/201621309.NET Framework: 624. WPF - Line 요소를 Canvas에 위치시켰을 때 흐림(blur) 현상파일 다운로드1
11107정성태11/9/201625188오류 유형: 371. Post cache substitution is not compatible with modules in the IIS integrated pipeline that modify the response buffers.파일 다운로드1
11106정성태11/8/201625361.NET Framework: 623. C# - PeerFinder를 이용한 Wi-Fi Direct 데이터 통신 예제 [2]파일 다운로드1
11105정성태11/8/201619743.NET Framework: 622. PeerFinder Wi-Fi Direct 통신 시 Read/Write/Dispose 문제
11104정성태11/8/201619218개발 환경 구성: 305. PeerFinder로 Wi-Fi Direct 연결 시 방화벽 문제
11103정성태11/8/201619176오류 유형: 370. PeerFinder.ConnectAsync의 결과 값인 Task.Result를 호출할 때 System.AggregateException 예외 발생
11102정성태11/8/201619289오류 유형: 369. PeerFinder.FindAllPeersAsync 호출 시 System.UnauthorizedAccessException 예외 발생
11101정성태11/8/201622048.NET Framework: 621. 닷넷 프로파일러의 오류 코드 - 0x80131363
11100정성태11/7/201628869개발 환경 구성: 304. Wi-Fi Direct 지원 여부 확인 방법 [1]
... 106  107  108  109  110  111  [112]  113  114  115  116  117  118  119  120  ...