나는 다음과 같이 진술함으로써이 질문에 대해 받아 들여지고 잘 찬성 된 답변의 일부에 동의하지 않는 것으로 시작할 것입니다.
실제로 JITted 코드가 올바르게 최적화 된 C ++ (또는 런타임 오버 헤드가없는 다른 언어) 프로그램보다 느리게 실행되는 이유는 다음과 같습니다.
런타임에 JITting 코드에 소비 된 계산주기는 정의상 프로그램 실행에 사용할 수 없습니다.
JITter의 모든 핫 경로는 CPU의 명령 및 데이터 캐시 코드와 경쟁합니다. 우리는 캐시가 성능면에서 지배적이며 C ++와 같은 모국어에는 정의에 따라 이러한 유형의 경합이 없습니다.
런타임 최적화 프로그램의 시간 예산은 컴파일 타임 최적화 프로그램의 예산 보다 훨씬 더 제한적입니다 (다른 의견자가 지적했듯이)
결론은 : 궁극적으로, 당신은 할 것이다 거의 확실하게 당신이 C #의 수보다 C ++로 빠른 구현을 만들 수 있습니다 .
이제 말했듯이, 작업, 문제 영역, 하드웨어, 구현 품질 및 기타 많은 요인과 같은 변수가 너무 많기 때문에 실제로 얼마나 빨리 정량화 할 수 없습니까? 시나리오에서 테스트를 실행하여 성능의 차이를 판별 한 후 추가 노력과 복잡성에 대한 가치가 있는지 여부를 결정합니다.
이것은 매우 길고 복잡한 주제이지만 C #의 런타임 최적화 프로그램이 우수하다는 완전성을 위해 언급 할 가치가 있으며 런타임에 C ++에서는 컴파일 타임으로 사용할 수없는 특정 동적 최적화를 수행 할 수 있습니다 ( static) 옵티 마이저. 그럼에도 불구하고, 장점은 여전히 기본 응용 프로그램의 법원에 깊이 있지만, 동적 최적화 프로그램은 위에서 언급 한 " 거의 확실하게"한정자 의 이유입니다 .
-
상대적인 성과 측면에서, 나는 다른 답변에서 본 인물과 토론에 혼란을 겪었습니다. 따라서 동시에 차임 할 것이라고 생각했으며 위에서 언급 한 진술에 대한 약간의 지원을 제공했습니다.
이러한 벤치 마크 문제의 큰 부분은 C #을 작성하는 것처럼 C ++ 코드를 작성할 수 없으며 대표 결과를 얻을 수 있다는 것입니다 (예 : C ++에서 수천 개의 메모리 할당을 수행하면 끔찍한 숫자가 나타납니다).
대신 약간 더 관용적 인 C ++ 코드를 작성하고 제공된 @Wiory C # 코드와 비교했습니다. C ++ 코드에서 변경된 두 가지 주요 사항은 다음과 같습니다.
1) 사용 된 vector :: reserve ()
2) 더 나은 캐시 위치를 달성하기 위해 2d 배열을 1d로 평면화했습니다 (연속 블록)
C # (. NET 4.6.1)
private static void TestArray()
{
const int rows = 5000;
const int columns = 9000;
DateTime t1 = System.DateTime.Now;
double[][] arr = new double[rows][];
for (int i = 0; i < rows; i++)
arr[i] = new double[columns];
DateTime t2 = System.DateTime.Now;
Console.WriteLine(t2 - t1);
t1 = System.DateTime.Now;
for (int i = 0; i < rows; i++)
for (int j = 0; j < columns; j++)
arr[i][j] = i;
t2 = System.DateTime.Now;
Console.WriteLine(t2 - t1);
}
런타임 (릴리스) : 초기화 : 124ms, 채우기 : 165ms
C ++ 14 (클랑 v3.8 / C2)
#include <iostream>
#include <vector>
auto TestSuite::ColMajorArray()
{
constexpr size_t ROWS = 5000;
constexpr size_t COLS = 9000;
auto initStart = std::chrono::steady_clock::now();
auto arr = std::vector<double>();
arr.reserve(ROWS * COLS);
auto initFinish = std::chrono::steady_clock::now();
auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);
auto fillStart = std::chrono::steady_clock::now();
for(auto i = 0, r = 0; r < ROWS; ++r)
{
for (auto c = 0; c < COLS; ++c)
{
arr[i++] = static_cast<double>(r * c);
}
}
auto fillFinish = std::chrono::steady_clock::now();
auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);
return std::make_pair(initTime, fillTime);
}
런타임 (릴리스) : 초기화 : 398µs (예, 마이크로 초), 채우기 : 152ms
총 실행 시간 : C # : 289ms, C ++ 152ms (약 90 % 더 빠름)
관찰
C # 구현을 동일한 1d 배열 구현으로 변경하면 Init : 40ms, Fill : 171ms, Total : 211ms가 발생했습니다 ( C ++은 여전히 거의 40 % 빠릅니다 ).
C ++에서 "빠른"코드를 디자인하고 작성하는 것이 어느 언어로든 "일반"코드를 작성하는 것보다 훨씬 어렵습니다.
C ++에서 성능이 저하되는 것은 놀랍도록 쉽습니다. 우리는 예약되지 않은 벡터 성능으로 그것을 보았습니다. 그리고 이런 함정이 많이 있습니다.
C #의 성능은 런타임에 진행되는 모든 것을 고려할 때 다소 놀랍습니다. 그리고 그 성능은 비교적 접근하기 쉽습니다.
C ++과 C #의 성능을 비교 한 일화적인 데이터 : https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore
결론적으로 C ++은 성능을 훨씬 더 잘 제어 할 수 있다는 것입니다. 포인터를 사용 하시겠습니까? 참조? 스택 메모리? 더미? 동적 다형성 또는 정적 다형성 (템플릿 / CRTP를 통해)으로 vtable의 런타임 오버 헤드를 제거합니까? 당신이 ... 어이 C ++에서 얻을 이상적으로 너무 솔루션 최선 주소 문제가 당신에게있는 거 태클이 (더) 자신이 모든 선택을 할 수 있도록.
위의 사소한 예에서도 성능이 크게 개선되었지만 액세스에 더 많은 투자가 필요하다는 것을 알 수 있기 때문에 실제로 해당 제어를 원하거나 필요로하는지 자문 해보십시오.