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로 빌드하면 위의 속도차이는 거의 없습니다.
(
첨부 파일은 이 글의 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]