x64 용으로 컴파일 할 때 추가 고려해야 할 사항은 int와 같은 일부 데이터 유형이 더 큰 값을 가질 수 있다는 것입니다. 걱정이 있습니까?x64 용 컴파일시 추가 우려 사항
VS2010은 VS2008과 마찬가지로 x64 및 x32 용 컴파일을 지원할 수 있습니다. 응용 프로그램은 x32/86 전용입니다. 나는 그 응용 프로그램이 64 비트 일 필요가 있다고 계속 생각하고있다. 내가 뭘 놓치고 있니? 분명히 이것은 사실이 아닙니다.
감사
x86-64에 대한 구축, 나는 두 가지 이유가있다 생각 - 응용 프로그램이 다음 포인터와 int 치의 두 배 더 많은 메모리를 소비하는 것, 64 비트 인 경우
가있는 대부분의 사람들에게 더 나을 것입니다.
Visual Studio의 일부는 이미 .NET에 이식되어 있습니다. 나머지 C/C++ 코드를 x64로 포팅하는 대신 .NET으로 나머지 포팅을 끝내는 것이 더 간단 할 것입니다.
http://blogs.msdn.com/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx
이유 :
앱이 필요합니다> 4기가바이트 주소 공간
앱이 성능에 중요하며 ~ 30 %의 혜택을 누릴 수 있습니다 증가 된 크기 및 레지스터 수로 인한 성능 향상
위의 어느 쪽도 적용되지 않으면 64 비트 앱을 만들 이유가 없습니다. VS2010 (IDE & 플러그인) 64 비트 응용 프로그램을되지 않는 관련하여
는@PhiS : x86 및 x86-64에서 테스트 한 연산 중심의 코드 (주로 이미지 처리 유형의 것들)를 기반으로 한 경험적 증거 (Intel에만 해당 - AMD에는 적용되지 않을 수도 있음). –
그리고 일부 응용 프로그램은 x64에서 느려질 것입니다. 내 엉덩이에서 번호를 가져 오도록하겠습니다. 약 30 % 느리게 말하십시오. 이것은 주로 캐시가 상대적으로 더 작기 때문입니다 (포인터가 이제 메모리와 캐시 공간을 두 배로 요구하기 때문에). 64 비트 숫자가 크거나 주소 공간이 필요하지 않으면 일반적으로 그럴 가치가 없습니다. – Eloff
@ 엘프 : 저는 제가 개발 한 다양한 코드에 대해 수집 한 벤치 마크 데이터에 대한 30 %의 주장을 근거로 삼고 있습니다. 사실, 대부분 연산 집약적 인 "수치 처리"루틴이지만 x86-64의 30 % 성능 향상은 현저하게 동일합니다. –
어떤 언어? –
ints는 C# 또는 C++에서 더 큰 값을 보유하지 않습니다. C++과 int에서 long은 여전히 32 비트입니다. 포인터가 64 비트이기 때문에 size_t, ptrdiff_t는 64 비트입니다. C#에서는 포인터의 크기가 변하지 않았으므로 (따라서 IntPtr/UIntPtr 형식도 마찬가지입니다.) – Eloff