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에 역량을 집중하는 듯합니다.
정성태

... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...
NoWriterDateCnt.TitleFile(s)
11790정성태12/11/201810656오류 유형: 507. Could not save daemon configuration to C:\ProgramData\Docker\config\daemon.json: Access to the path 'C:\ProgramData\Docker\config' is denied.
11789정성태12/10/201820522Windows: 153. C# - USB 장치의 연결 및 해제 알림을 위한 WM_DEVICECHANGE 메시지 처리 [2]파일 다운로드2
11788정성태12/4/201810482오류 유형: 506. SqlClient - Value was either too large or too small for an Int32.Couldn't store <2151292191> in ... Column
11787정성태11/29/201814457Graphics: 33. .NET으로 구현하는 OpenGL (9), (10) - OBJ File Format, Loading 3D Models파일 다운로드1
11786정성태11/29/201811139오류 유형: 505. OpenGL.NET 예제 실행 시 "Managed Debugging Assistant 'CallbackOnCollectedDelegate'" 예외 발생
11785정성태11/21/201813540디버깅 기술: 120. windbg 분석 사례 - ODP.NET 사용 시 Finalizer에서 System.AccessViolationException 예외 발생으로 인한 비정상 종료
11784정성태11/18/201813191Graphics: 32. .NET으로 구현하는 OpenGL (7), (8) - Matrices and Uniform Variables, Model, View & Projection Matrices파일 다운로드1
11783정성태11/18/201811319오류 유형: 504. 윈도우 환경에서 docker가 설치된 컴퓨터 간의 ping IP 주소 풀이 오류
11782정성태11/18/201811078Windows: 152. 윈도우 10에서 사라진 "Adapters and Bindings" 네트워크 우선순위 조정 기능 - 두 번째 이야기
11781정성태11/17/201813289개발 환경 구성: 422. SFML.NET 라이브러리 설정 방법 [1]파일 다운로드1
11780정성태11/17/201814761오류 유형: 503. vcpkg install bzip2 빌드 에러 - "Error: Building package bzip2:x86-windows failed with: BUILD_FAILED"
11779정성태11/17/201815146개발 환경 구성: 421. vcpkg 업데이트 [1]
11778정성태11/14/201812916.NET Framework: 803. UWP 앱에서 한 컴퓨터(localhost, 127.0.0.1) 내에서의 소켓 연결
11777정성태11/13/201811963오류 유형: 502. Your project does not reference "..." framework. Add a reference to "..." in the "TargetFrameworks" property of your project file and then re-run NuGet restore.
11776정성태11/13/201811219.NET Framework: 802. Windows에 로그인한 계정이 마이크로소프트의 계정인지, 로컬 계정인지 알아내는 방법
11775정성태11/13/201813763Graphics: 31. .NET으로 구현하는 OpenGL (6) - Texturing파일 다운로드1
11774정성태11/8/201811628Graphics: 30. .NET으로 구현하는 OpenGL (4), (5) - Shader파일 다운로드1
11773정성태11/7/201811371Graphics: 29. .NET으로 구현하는 OpenGL (3) - Index Buffer파일 다운로드1
11772정성태11/6/201813673Graphics: 28. .NET으로 구현하는 OpenGL (2) - VAO, VBO파일 다운로드1
11771정성태11/5/201812832사물인터넷: 56. Audio Jack 커넥터의 IR 적외선 송신기 - 두 번째 이야기 [1]
11770정성태11/5/201819852Graphics: 27. .NET으로 구현하는 OpenGL (1) - OpenGL.Net 라이브러리 [3]파일 다운로드1
11769정성태11/5/201811661오류 유형: 501. 프로젝트 msbuild Publish 후 connectionStrings의 문자열이 $(ReplacableToken_...)로 바뀌는 문제
11768정성태11/2/201811550.NET Framework: 801. SOIL(Simple OpenGL Image Library) - Native DLL 및 .NET DLL 제공
11767정성태11/1/201813085사물인터넷: 55. New NodeMcu v3(ESP8266)의 IR LED (적외선 송신) 제어파일 다운로드1
11766정성태10/31/201814444사물인터넷: 54. 아두이노 환경에서의 JSON 파서(ArduinoJson) 사용법
11765정성태10/26/201812104개발 환경 구성: 420. Visual Studio Code - Arduino Board Manager를 이용한 사용자 정의 보드 선택
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...