2009-04-06 4 views
6

32 비트 OS에서 32 비트를 실행하고 64 비트 OS에서 64 비트를 실행하게하는 AnyCPU를 대상으로 .NET 응용 프로그램을 컴파일 할 수 있다는 것을 알고 있습니다.64 비트 OS에서 32 비트 .NET 응용 프로그램을 실행하는 것은 정말 안좋은가요?

그러나 64 비트 OS에서보고 된 버그로 인해 내 앱에서 오류 및 해결책을 제공했지만 x86을 대상으로해야합니다.

내 질문 : 코드를 x64로 실행하려고해도 x86을 대상으로하는 것이 정말 안좋은가요? 우리가 말하는 어떤 종류의 공연입니까? (내 응용 프로그램은 꽤 CPU를 많이 사용하지만 실제로 처리하기가 어렵습니다.)

결국 .NET Framework는 32 ​​비트에서 실행되며 이는 x64 CPU **의 전체 주소 지정 기능을 사용하는 대신 나에게 좋지 않습니다.

*이 버그는 기억이 나지 않지만 해결책은 x86을 특별히 목표로 삼아 문제를 해결했습니다.

** 중요한 점은 확실하지 않지만 응용 프로그램에서 Int64 변수를 사용하지 않습니다.

답변

4

아니요, 나쁘지 않습니다. 실제로, 내가 일하고있는 응용 프로그램의 경우 을 대상으로합니다 (COM 개체를 가져 오는 경우 해당 공급 업체가 x64를 지원하지 않음)

+1

프로세스를 실행한다고 가정 할 때 64 비트 프로세스에서 32 비트 COM을 실행할 수 있습니다. http://stackoverflow.com/questions/611651/64-bit-c-with-a-32-bit-vb6-com-object – Zach

+1

내 경우에는 interop을 처리하는 프레임 워크입니다. WIC. proc 프록시를 작성하는 것을 고려해 봤지만 x86을 타깃으로하는 번거 로움은 적습니다 ... –

2

나는 CPU를 많이 사용하는 응용 프로그램을 많이 가지고 있습니다 (몇 가지 해결책을 강요합니다). 64 비트 .NET Framework (8 초)에서 실행하는 것은 32 비트 (30 초)보다 약 4 배 빠릅니다. 그것은 단 하나의 사례 일뿐입니다.

+0

주로 Int32 대신 Int64를 처리 할 때 눈에.니다. 인자 4의 차이점은 여기에서도 마찬가지입니다. – Joey

+0

임의의 CPU로 컴파일하면 어떻게 될까요? AFAIK는 x64 시스템에서 x64로 컴파일 된 것처럼 작동해야합니다. –

+0

@dr. Any CPU .exe를 x64 시스템에서 직접 실행하면 64 비트 모드로 실행됩니다. 그러나 32 비트 호스트가 프로세스 중에로드되면 32 비트 모드로 실행됩니다. –

0

기억해야 할 것은 64 비트 환경에서 실행되는 32 비트 프로세스는 시스템이 수행하는 모든 작업에 대해 메모리 주소 변환을 수행해야합니다. 나쁜가요? 시나리오에 따라 다릅니다. 그것은 확실히 그것이 될 수있는만큼 효율적이지 않습니다. x-64 서버에서 32 비트 버전의 IIS를 실행하는 것은 어려울 정도로 느립니다. 그것은 모두 응용 프로그램의 요구 사항에 따라 다릅니다.

+0

* 가상 주소 공간 *이있는 최신 운영 체제의 모든 프로세스는 사용시 실제 주소로 변환되어야한다고 생각합니다. –

+0

아니, 더 큰 레지스터와 같은 x64의 몇 가지 장점이 있지만 이중 포인터 크기로 인해 더 큰 응용 프로그램과 같은 단점이있어 캐시와 메모리 대역폭을 덜 효율적으로 만듭니다. 어쨌든 합리적인 컴파일러가 사용된다고 가정하면 속도는 대략 동일해야합니다. –

+0

.Net의 경우 64 비트에서 더 진보 된 Jit 엔진이 차이점입니다 (또는 32 비트 Jit 컴파일러가 덜 진보해야합니다, 특히 64 비트 구조로 작업 할 때, 긴 이중과 같은 문제, 32 비트 C++ 컴파일러는 가지고 있지 않습니다.) –

0

아니요. 문제없이 실행됩니다. 실제로 우리는 32 비트 응용 프로그램이 새로운 OS 메모리 관리자로 인해 32 비트 Vista보다 64 비트 Vista에서 더 나은 것으로 나타났습니다. x86을 직접 타겟팅하는 것이 좋습니다. 그러나 64 비트에서 네이티브로 실행할 수 있다는 것은 더 많은 메모리에 액세스 할 수있는 기능, CPU에 더 많은 레지스터를 제공하는 기능 등과 같이 다른 장점이 있으므로 가능하면 일어나서 실행할 수있는 가치가 있습니다.

1

아니요, x64 시스템에서 x86을 대상으로해야하는 것은 그리 나쁘지 않습니다. 추가 x64 혜택을 놓치고 32 비트 에뮬레이션 레이어에서 실행됩니다. 하지만 완전히 깨진 것보다 낫다. 그리고 대부분의 애플 리케이션은 여전히 ​​32 비트이다.

.Net을 사용하면이 작업을 수행해야하는 일반적인 이유는 네이티브 32 비트 전용 DLL에 대한 종속성입니다. .Net을 임의의 CPU에서 대상으로두면 64 비트 모드에서 32 비트 dll을로드하려고 시도하고 충돌이 발생합니다. 궁극적으로 64 비트 모드를 사용할 수 있도록 종속성에서 벗어나고 싶습니다. 그러나 한 번의 석방으로 그것은 당신을 죽이지 않을 것입니다.

0

필자는 측정하는 것이 가장 확실한 방법이라고 말하려했지만 분명히 제대로 실행되지 않으면 측정하기가 어려웠습니다.

먼저 성능 문제가 있는지 확인하십시오. 문제가있는 것처럼 보이면 x64와 호환되지 않는 응용 프로그램에서 정확히 무엇을 정확하게 찾을 수 있는지 확인하십시오. 대부분의 .NET 코드는 플랫폼에 독립적이어야하므로 가장 많이 발생하는 범인은 상호 운영 체제 또는 타사 라이브러리입니다.

1

대답은 "다릅니다."그것은 당신의 어플리케이션이 메모리에 많이 액세스하는지 아닌지에 달려 있습니다. 케빈이 옳습니다 : 프로세서는 주소 변환을 많이해야하지만 아마 어플리케이션의 성능을 크게 손상시키지 않을 것입니다. 하드웨어 명령어는 대부분 x86과 amd64에서 동일하며 CLR 작성자가 자신이 무엇을하고 있는지를 알고 있다고 가정 할 때 너무 비효율적이지는 않습니다 (그리고 나는 확신합니다). 그래픽을 수행하면 성능 차이가 크게 나타날 수 있습니다 조작법을 설명하지만 .NET App이기 때문에 Mehrdad가 언급 한 것처럼 약간의 숫자 처리 작업에 대해서는 놀랐지 만

All- 성능에 민감한 응용 프로그램을 사용하지 않으면 성능 문제를 걱정하지 말라는 뜻입니다. 그런 다음 n을 이해하면 성능 문제 만 걱정하면됩니다. 귀하의 신청서를 제출하십시오.

1

구조체를 사용하고 64 비트 계산 (double, long)이 많은 경우 32 비트 Jit 엔진이 64 비트 모델보다 덜 고급이므로 성능이 저하됩니다.

그렇지 않으면 32 비트 및 64 비트 버전의 .Net이 다소 비슷한 성능을 발휘합니다. 호환성 서브 모드 - 당신은 당신이 할 프로세스에 대한 한계는 2GB를 초과 할 필요가없는 경우

는 또한이 기능을 해결하기위한 64 비트를 필요로하지, 운영 체제는 Long Mode라는 특별한 CPU 모드를 사용하기 위해 그 처리합니다. (CPU는 실제로 64 비트 모드에서 실행되지만 주소 지정에는 32 비트를 사용하여 호환성을 제공합니다)

0

.NET 코드가 32 비트 COM 객체를 사용한다는 "버그"가 있었습니까?

이 경우는 AnyCPU 설정으로 컴파일 된 64 비트 아키텍처에서 .NET 프로세스를 실행할 때 실제로 문제가 될 수 있습니다.

프로세스가 64 비트 프로세스로 실행되고 프로세스에서 실행되는 모든 COM 구성 요소도 64 비트 버전이어야합니다. 그렇지 않은 경우 프로세스가 종료됩니다.

가능한 해결 방법은 대상 플랫폼을 x86으로 설정하는 것입니다.

+0

WEbbrowser 컨트롤을 사용하고 있었지만 x64 호환이라고 가정합니다.문제는 MS Access 2007 액세스라고 생각합니다. 그러나 recemember 수 없습니다. –

관련 문제