2009-12-07 3 views
1

나는 C로 오래 전에 시작한 다음 C++로 옮겨서 C++/CLI를 마주하고 있습니다. 퍼포먼스 괴물로서 필자는 항상 코드의 모든 라인에 대해 마지막 성능 저하를 쥐어 짜려고 노력하고있다. 나는 현재 VB.Net (단순성, 리소스 가용성 등)에서 주로 수행되는 것이 당연한 프로젝트이지만 성능에 매우 민감하고 C++/CLI로 이러한 부분을 수행 할 계획이었습니다. . 그러나 나머지 부분은 관리해야하는 반면 관리 코드에서는 그 중 일부만 제거 할 수 있습니다. 문제는 C# 또는 VB.Net과 비교하여 C++/CLI 관리 기능을 작성함으로써 기대되는 성능 향상이 있습니까? 내가 읽고있는 문서에서 이해할 수있는 것부터 유일한 이점은 관리/관리되지 않는 썽킹이 더 가벼운 것으로 보입니다. 그럴까요? C++/CLI가 MSIL로 컴파일로C++/CLI 성능 향상

String^mystr = "Oh, my!"; 
Object^myarray[10]; 
myarray[0] = mystr; // Can't event be casted to void*, int, HANDLE... 
// (however, handles do have a sizeof() == 4 in Win32) 
// (I don't expect the handle to behave like a pointer; just stay as handle) 

답변

0

C++/CLI에서 볼 수있는 유일한 성능 향상은 네이티브 코드와 관리 코드를 함께 사용하는 경우입니다. C++/CLI를 사용하면 VB.Net보다 적은 오버 헤드로 코드의 성능이 중요한 부분에 대한 네이티브 메소드를 호출 할 수 있습니다. 여전히 처벌이 있기 때문에 네이티브와 네이티브간에 전환하는 것을 권장하지 않지만 퍼포먼스 관련 코드의 덩어리에 대한 네이티브 코드에 컨트롤을 전달하는 것은 허용됩니다.

  • 일단,

  • +0

    감사합니다. 비록 오버 헤드가 얼마나되는지를 여전히 프로파일 링해야하지만 썽킹 오버 헤드에 대해 알고있었습니다. –

    1

    그냥 C# 및 VB처럼, 어떤 성능 이점이 없습니다 : 심지어 같은 (I 빠르게 조작 할 수있다) 관리되지 않는 배열이나 구조에 핸들을 저장할 수없는 것 때문에 .그물. VB 및 C++/CLI 모두에서 간단한 테스트 기능을 직접 작성하여 직접 볼 수 있습니다.

    +0

    그 시점에서 각 컴파일러의 문제입니다. C++ 팀이 C# 또는 VB.NET 팀보다 성능에 열심히 일하는 경향이있을 수 있습니다. –

    +0

    사실입니다. C++/CLI 팀이 모든 팀 중에서 가장 작은 팀이 될 것으로 기대합니다. 그들은 VS 2010에서 C++/CLI 용 인텔리 센스조차 가지고 있지 않습니다. 따라서 C++ 또는 MS 팀이 C++ 또는 VB 팀보다 MSIL 컴파일 또는 적어도 모토로를 최적화하는 데 많은 노력을 기울일 것으로 기대하지는 않습니다. – Eric

    +0

    장점이 없다고 말하는 것이 맞지 않습니다. 모든 디자인에 적용되는 것은 아니지만 경우에 따라 매우 큰 이점이 있습니다. –

    3

    내가 너무 성능 괴물이야, 나는 질문의

    1. 이런 종류의 내가 성능 문제가 위치를 알 때까지 질문을하기도 것이 아니라고 배웠습니다 나는 그들이 어디 있는지 알기 때문에 묻지 않아도된다. 왜냐하면 나는 모든 컴파일 된 언어가 내가 볼 수있는 어셈블리 언어 나 중간 언어를 생성하기 때문이다. b) 나는 10^6 번 실행할 수있다. 그냥 클럭하세요.

    내 경험에 따르면 다양한 크기의 문제가 있습니다. 먼저 가장 쉽고 가장 큰 것을 수정합니다. 그러면 나머지는 시간의 큰 부분을 차지하므로 다음 패스에서 쉽게 찾을 수 있습니다. **

    I keep doing tuning passes until I run out of performance problems I can fix. 그때까지는 코드가 처음보다 빨리 수행 될 수 있습니다.

    ** 예 : 프로그램이 10 초 걸린다 고 가정합니다. 두 가지 문제가 있다고 가정하면 (당신이 알기 전까지는 당신은 모릅니다), 그들은 각각 50 %와 30 %를 차지합니다. 첫 번째 문제를 해결하고 시간이 5 초로 떨어집니다. 이제 두 번째 문제는 총 시간이 감소 했으므로 60 %를 소비하므로 더 쉽게 발견 할 수 있습니다. 문제를 해결하고 2 초로 시간을 단축합니다. 즉, 5 배의 속도 향상입니다. 문제가 많을수록 가능한 빠른 속도 향상. 하나는 큰 문제가 있다고 의심 할 수 있으며, 그렇다면 샘플링은 그것을 증명하거나 반증 할 것입니다.

    +0

    감사합니다, 마이크. 그러나 이것은 내 질문과 관련이 없습니다. –

    +0

    유효한 포인트를 만들기 위해 Upvoted. –

    3

    C++/CLI는 관리되며 다른 모든 .net 언어와 동일한 MSIL로 컴파일됩니다. 속도가 당신을 위해 왕이라면, 네이티브 dll에 비판적인 비트를 쓰고 vb.net 앱에서 pinvoke하십시오 (썽크 카운트를 낮추면 괜찮을 것입니다).

    그러나 tbh, id는이 코드가 정말로 필요한지 조기에 최적화되었는지보기 위해 코드를 작성합니다. 어쨌든 MSIL은 네이티브 코드로 컴파일 될 수 있습니다. 진짜 질문은 .net JITer가 네이티브 c/C++ 컴파일러만큼 최적화되어 있는지 여부입니다.

    1

    그런데 메모리의 관리되지 않는 부분에 핸들을 저장하려면 GCHandle structure 또는 gcroot을 사용해야했습니다.

    0

    C++/CLI 컴파일러는 코드의 직접 변환에 대해 더 나은 성능을 제공하지는 않지만 관리 코드에서도 큰 성능 이점을 줄 수있는 다양한 C++ 기능이 있습니다.

    큰 것은 템플릿입니다. 이 코드는 템플릿 매개 변수의 각 조합에 대해 재생성되고 독립적으로 최적화됩니다. .NET 제네릭은 흔히 가장 간단한 인라이닝을 금지하지만 C++/CLI 템플릿으로 변환하면 다른 .NET 언어와 동등하지 않은 특수화 및 컴파일 타임 메타 프로그램뿐만 아니라 추가 최적화 기회가 가능합니다.

    0

    관리되지 않는 코드와 관리되는 어셈블리를 혼합하면 성능이 향상됩니다. C++/cli는 이것을 매우 쉽게 만듭니다. C# 또는 vb.net을 통해 pinvoke를 사용하여 C++을 호출 해보십시오. extern c 호출에서 C++을 래핑하거나 C 언어로 호출하면됩니다. 또한 최적화 된 Microsoft C++ 컴파일러의 성능이 상당히 향상되었습니다. 관리되지 않는 코드를 섞어 놓지 않으면 다른 사람처럼 MSIL을 컴파일 할 때 성능 이득이 없습니다.