C #이 C ++보다 정말 느린가요?

C #이 C ++보다 정말 느린가요?

---

나는이 문제에 대해 한동안 궁금해하고 있습니다.

물론 C #에는 속도에 최적화되지 않은 것이 있으므로 이러한 개체 또는 언어 조정 (예 : LinQ)을 사용하면 코드가 느려질 수 있습니다.

그러나 이러한 조정을 사용하지 않고 C # 및 C ++에서 동일한 코드 조각을 비교하면됩니다 (서로 변환하기 쉽습니다). 정말 그렇게 느려질까요?

이론적으로 JIT 컴파일러가 코드를 실시간으로 최적화하고 더 나은 결과를 얻어야하기 때문에 C #이 어떤 경우에는 더 빠를 수 있음을 보여주는 비교를 보았습니다.

관리 또는 비 관리?

JIT 컴파일러가 실시간으로 코드를 컴파일하지만 이는 1 회 오버 헤드이며 동일한 코드 (한 번 도달하고 컴파일 된 후)가 런타임에 다시 컴파일 될 필요가 없다는 것을 기억해야합니다.

GC는 수천 개의 객체를 만들고 파괴하지 않는 한 많은 오버 헤드를 추가하지 않습니다 (예 : StringBuilder 대신 String 사용). 그리고 C ++에서 그렇게하는 것도 비용이 많이 듭니다.

제가 언급하고 싶은 또 다른 요점은 .Net에 도입 된 DLL 간의 더 나은 통신입니다. .Net 플랫폼은 Managed COM 기반 DLL보다 훨씬 잘 통신합니다.

언어가 더 느려 야하는 내재 된 이유를 알지 못하며 C #이 C ++보다 느리다고 생각하지 않습니다 (경험과 좋은 설명 부족 모두) ..

그렇다면 C #으로 작성된 동일한 코드 조각이 C ++의 동일한 코드보다 느릴까요?
그렇다면 왜?

다른 참고 자료 (이에 대해 조금 이야기하지만 WHY에 대한 설명은 없음) :

C ++보다 느린 경우 왜 C #을 사용하고 싶습니까?

---

경고 : 당신이 물어 본 질문은 정말 꽤 복잡합니다. 결과적으로 이것은 정말 긴 대답입니다.

순전히 이론적 인 관점에서 보면 아마도 이것에 대한 간단한 대답이있을 것입니다. C ++만큼 빠르지 못하게하는 C #에 대해서는 (아마도) 아무것도 없습니다. 그러나 이론에도 불구하고 어떤 상황에서는 어떤 상황에서는 속도 가 느린 몇 가지 실제적인 이유가 있습니다.

언어 기능, 가상 머신 실행 및 가비지 수집이라는 세 가지 기본 차이점을 고려할 것입니다. 후자의 두 개는 종종 함께 이동하지만 독립적 일 수 있으므로 별도로 살펴 보겠습니다.

언어 특징

C ++는 템플릿과 템플릿 시스템의 기능에 많은 중점을 둡니다. 템플릿 시스템의 기능은 주로 컴파일 타임에 최대한 많은 작업을 수행 할 수 있도록 의도되어 있으므로 프로그램의 관점에서 보면 "정적"입니다. 템플릿 메타 프로그래밍을 사용하면 컴파일 시간에 완전히 임의의 계산을 수행 할 수 있습니다 (즉, 템플릿 시스템은 튜링 완료). 따라서 본질적으로 사용자의 입력에 의존하지 않는 모든 것은 컴파일 타임에 계산 될 수 있으므로 런타임에는 단순히 상수입니다. 그러나 여기에 대한 입력에는 유형 정보와 같은 것이 포함될 수 있으므로 C #에서 런타임에 리플렉션을 통해 수행하는 작업은 일반적으로 C ++의 템플릿 메타 프로그래밍을 통해 컴파일 타임에 수행됩니다. 하지만 런타임 속도와 다양성 사이에는 확실히 절충안이 있습니다. 템플릿이 무엇을 할 수 있는지,

언어 기능의 차이는 단순히 일부 C #을 C ++로 (또는 그 반대로) 음역하여 두 언어를 비교하려는 거의 모든 시도가 무의미한 것과 오해의 소지가있는 결과를 생성 할 가능성이 있다는 것을 의미합니다 (그리고 대부분의 다른 언어 쌍에서도 마찬가지입니다. 게다가). 간단한 사실은 두 줄 정도의 코드보다 큰 어떤 경우에도 거의 아무도 언어를 같은 방식으로 (또는 같은 방식에 가깝게) 사용할 가능성이 거의 없다는 것입니다. 실생활에서 일하십시오.

가상 기기

거의 모든 합리적으로 현대적인 VM과 마찬가지로 .NET 용 Microsoft는 JIT (일명 "동적") 컴파일을 수행 할 수 있습니다. 이것은 많은 절충안을 나타냅니다.

주로 다른 최적화 문제와 마찬가지로 코드 최적화는 대체로 NP- 완전 문제입니다. 진정으로 사소한 / 장난감 프로그램을 제외하고는 결과를 진정으로 "최적화"하지 않을 것이라고 거의 보장됩니다 (즉, 진정한 최적을 찾지 못할 것입니다). 최적화 프로그램은 단순히 코드를 그것보다 더 좋게 만들 것입니다. 이전에. 그러나 잘 알려진 몇 가지 최적화는 실행하는 데 상당한 시간 (그리고 종종 메모리)이 걸립니다. JIT 컴파일러를 사용하면 컴파일러가 실행되는 동안 사용자가 대기합니다. 더 비싼 최적화 기술의 대부분은 배제됩니다. 정적 컴파일에는 두 가지 장점이 있습니다. 우선 느린 경우 (예 : 대규모 시스템 구축) 일반적으로 서버에서 수행되고 아무도 수행 하지 않습니다.그것을 기다리는 시간을 보냅니다. 둘째, 실행 파일은 한 번 생성 될 수 있으며 여러 사람이 여러 번 사용할 수 있습니다 . 첫 번째는 최적화 비용을 최소화합니다. 두 번째는 훨씬 많은 수의 실행에 비해 훨씬 적은 비용을 상각합니다.

원래의 질문 (및 다른 많은 웹 사이트)에서 언급했듯이 JIT 컴파일은 대상 환경에 대한 더 큰 인식 가능성을 가지고 있으며, 이는 (적어도 이론적으로)이 이점을 상쇄해야합니다. 이 요소가 정적 컴파일의 단점 중 적어도 일부를 상쇄 할 수 있다는 것은 의심의 여지가 없습니다. 코드 및 대상 환경의 일부가 아니라 특정 유형의 경우, 수정적 컴파일의 장점을 능가하는 경우도 있습니다. 그러나 적어도 내 테스트와 경험에서 이것은 상당히 드문 일입니다. 타겟에 따른 최적화는 대부분 상당히 작은 차이를 만들거나 상당히 특정한 유형의 문제에만 적용 할 수 있습니다 (어쨌든 자동으로). 이것은 현대 컴퓨터에서 비교적 오래된 프로그램을 실행하는 경우에 발생할 수 있습니다. C ++로 작성된 오래된 프로그램은 아마도 32 비트 코드로 컴파일되었을 것이며 최신 64 비트 프로세서에서도 32 비트 코드를 계속 사용합니다. C #으로 작성된 프로그램은 바이트 코드로 컴파일되고 VM은 64 비트 기계어 코드로 컴파일됩니다. 이 프로그램이 64 비트 코드로 실행하여 상당한 이점을 얻는다면 상당한 이점을 얻을 수 있습니다. 64 비트 프로세서가 상당히 새롭 던 짧은 시간 동안 이것은 상당한 양의 일이었습니다. 64 비트 프로세서의 이점을 얻을 수있는 최신 코드는 일반적으로 64 비트 코드로 정적으로 컴파일되어 제공됩니다.

VM을 사용하면 캐시 사용량도 향상 될 수 있습니다. VM에 대한 지침은 종종 기본 컴퓨터 지침보다 더 간결합니다. 그들 중 더 많은 것은 주어진 양의 캐시 메모리에 맞을 수 있으므로 필요한 경우 주어진 코드가 캐시에있을 가능성이 더 높습니다. 이는 대부분의 사람들이 처음에 예상했던 것보다 더 경쟁력있는 (속도 측면에서) VM 코드의 해석 된 실행을 유지하는 데 도움이 될 수 있습니다 . 한 번의 캐시 미스에 걸리는 시간에 최신 CPU에서 많은 명령을 실행할 수 있습니다 .

이 요소가 반드시 둘 사이에 반드시 다르지 는 않다는 점도 언급 할 가치가 있습니다. 예를 들어 C ++ 컴파일러가 가상 머신 (JIT 포함 또는 제외)에서 실행되도록 의도 된 출력을 생성하는 것을 막는 것은 없습니다. 사실, 마이크로 소프트의 C ++ / CLI는 거의 가상 머신에서 실행하도록 출력을 생성하는 (거의) 준수 C ++ 컴파일러 (확장 많은,이기는하지만) - 있음.

그 반대도 마찬가지입니다. Microsoft는 이제 C # (또는 VB.NET) 코드를 네이티브 실행 파일로 컴파일하는 .NET 네이티브를 보유하고 있습니다. 이는 일반적으로 C ++와 훨씬 유사한 성능을 제공하지만 C # / VB의 기능을 유지합니다 (예 : 네이티브 코드로 컴파일 된 C #은 여전히 ​​리플렉션을 지원함). 성능 집약적 인 C # 코드가있는 경우 유용 할 수 있습니다.

가비지 컬렉션

내가 본 것에서 나는 가비지 콜렉션이이 세 가지 요소 중 가장 잘 이해되지 않는 것이라고 말하고 싶습니다. 명백한 예를 들어, 여기에있는 질문은 다음과 같습니다. "GC는 수천 개의 객체를 생성하고 파괴하지 않는 한 [...]"이라는 오버 헤드도 많이 추가하지 않습니다. " 당신이 만드는 경우 실제로, 그리고 수천 개의 오브젝트를 파괴, 가비지 콜렉션의 오버 헤드는 일반적으로 상당히 낮을 것이다. .NET은 다양한 복사 수집기 인 세대 별 청소 도구를 사용합니다. 가비지 수집기는 포인터 / 참조가 알려진 "장소"(예 : 레지스터 및 실행 스택)에서 시작하여 작동합니다.액세스 할 수 있습니다. 그런 다음 힙에 할당 된 개체에 대한 포인터를 "추적"합니다. 체인의 끝까지 모든 개체를 따라갈 때까지 추가 포인터 / 참조에 대해 해당 개체를 검사하고 (적어도 잠재적으로) 액세스 할 수있는 모든 개체를 찾습니다. 다음 단계에서는 사용중인 (또는 적어도 있을 수있는 ) 모든 개체를 가져 와서 힙에서 관리되는 메모리의 한쪽 끝에있는 연속 청크로 모든 개체를 복사하여 힙을 압축합니다. 나머지 메모리는 무료입니다 (모듈로 파이널 라이저를 실행해야하지만 적어도 잘 작성된 코드에서는 드물기 때문에 잠시 무시할 것입니다).

이것이 의미하는 바는 많은 개체 를 만들고 파괴 하는 경우 가비지 수집이 오버 헤드를 거의 추가하지 않는다는 것입니다 . 가비지 수집주기에 걸리는 시간은 거의 전적으로 생성되었지만 파괴 되지 않은 개체 수에 따라 다릅니다 . 서둘러 개체를 만들고 파괴하는 주요 결과는 단순히 GC를 더 자주 실행해야하지만 각주기는 여전히 빠르다는 것입니다. 당신이 개체를 만들고 있다면 하지 않는 그들을 파괴, GC가 더 자주 실행 하고 잠재적 라이브 객체에 더 많은 시간을 쫓는 포인터를 보낸다 각주기가 느린 실질적 될 것입니다, 그리고 그것은 아직 사용 개체를 복사하는 더 많은 시간을 보낸다.

이를 방지하기 위해, 세대 청소 객체는 가정에서 작동 한 아주 잠시 동안 "살아"남아 가능성이 더 오래 꽤 살아 남아 계속한다. 이를 기반으로, 가비지 수집주기에서 살아남은 개체가 "보존"되는 시스템이 있으며 가비지 수집기는 단순히 사용 중이라고 가정하기 시작하므로 매주기마다 복사하는 대신 그들 혼자. 이것은 세대 별 청소가 일반적으로 대부분의 다른 형태의 GC보다 상당히 낮은 오버 헤드를 가질 정도로 충분히 유효한 가정입니다.

"수동"메모리 관리는 종종 잘 이해되지 않습니다. 예를 들어, 많은 비교 시도는 모든 수동 메모리 관리가 하나의 특정 모델 (예 : 최적 할당)을 따른다고 가정합니다. 이것은 가비지 수집에 대한 많은 사람들의 믿음 (예 : 일반적으로 참조 계산을 사용하여 수행된다는 광범위한 가정)보다 현실에 거의 (존재하는 경우) 가깝습니다.

가비지 수집 및 수동 메모리 관리에 대한 다양한 전략을 고려할 때 전체 속도 측면에서 두 가지를 비교하는 것은 매우 어렵습니다. 메모리 할당 및 / 또는 해제 속도 (그 자체로)를 비교하려고 시도하는 것은 기껏해야 무의미하고 최악의 경우 오해의 소지가있는 결과를 생성하는 것이 거의 보장됩니다.

보너스 주제 : 벤치 마크

많은 블로그, 웹 사이트, 잡지 기사 등이 한 방향 또는 다른 방향으로 "객관적인"증거를 제공한다고 주장하기 때문에이 주제에 대해서도 2 센트 가치를 부여하겠습니다.

이러한 벤치 마크의 대부분은 자동차 경주를 결정하는 십대와 비슷하며,이기는 사람은 두 자동차를 모두 유지하게됩니다. 하지만 웹 사이트는 한 가지 중요한면에서 다릅니다. 벤치 마크를 게시하는 사람은 두 차를 모두 운전하게됩니다. 이상한 우연으로 그의 차는 항상 이기고 다른 사람들은 "나를 믿어, 나는 정말로 당신의 차를 가능한 한 빨리 운전하고 있었다"고 안주해야합니다 .

아무것도 의미하지 않는 결과를 생성하는 열악한 벤치 마크를 작성하는 것은 쉽습니다. 의미있는 모든 것을 생산하는 벤치 마크를 설계하는 데 필요한 기술에 가까운 거의 모든 사람은 자신이 원하는 결과를 얻을 수있는 벤치 마크를 생산할 수있는 기술을 가지고 있습니다. 실제로 의미있는 결과를 생성하는 코드보다 특정 결과를 생성하는 코드를 작성하는 것이 더 쉽습니다 .

제 친구 James Kanze가 말했듯이 "당신이 자신을 위조하지 않은 벤치 마크를 절대 믿지 마십시오."

결론

간단한 대답은 없습니다. 나는 동전을 뒤집어 승자를 선택한 다음 1에서 20 사이의 숫자를 선택하여 승자 비율을 정하고 합리적이고 공정한 벤치 마크처럼 보이는 코드를 작성할 수 있다고 확신합니다. (적어도 일부 대상 프로세서에서는 다른 프로세서가 백분율을 약간 변경할 수 있음)

다른 사람들이 지적했듯이 대부분의 코드에서 속도는 거의 관련이 없습니다. (훨씬 더 자주 무시) 그에 대한 추론은 속도가 중요합니까 작은 코드에서, 그것은 보통 중요한 것입니다 많은 . 적어도 내 경험상 실제로 중요한 코드에서는 C ++가 거의 항상 승자입니다. 확실히 C #을 선호하는 요소가 있지만 실제로는 C ++를 선호하는 요소보다 더 큰 것 같습니다. 선택한 결과를 나타내는 벤치 마크를 확실히 찾을 수 있지만 실제 코드를 작성할 때 거의 항상 C #보다 C ++에서 더 빠르게 만들 수 있습니다. 글을 쓰는 데 더 많은 기술 및 / 또는 노력이 필요할 수도 있고 그렇지 않을 수도 있지만 거의 항상 가능합니다.

---

항상 "가장 빠른"언어를 사용할 필요가 없기 때문입니까? 더 빠르기 때문에 나는 페라리에서 일하기 위해 운전하지 않습니다 ...

---

C ++는 항상 성능에 유리합니다. C #을 사용하면 메모리를 처리 할 수 ​​없으며 문자 그대로 작업을 수행하는 데 사용할 수있는 리소스가 엄청나게 많습니다.

자신에게 질문해야 할 것은 어느 것이 시간을 절약하는지에 대한 것입니다. 기계는 이제 믿을 수 없을 정도로 강력하며 대부분의 코드는 최소한의 시간에 최대의 가치를 얻을 수있는 언어로 작성되어야합니다.

C #에서 너무 오래 걸리는 핵심 처리가있는 경우 C ++를 빌드하고 C #과 상호 운용 할 수 있습니다.

코드 성능에 대해 생각하지 마십시오. 가치 구축을 시작하십시오.

---

2005 년경 네이티브 / 관리 형 펜스의 양쪽에서 두 명의 MS 성능 전문가가 동일한 질문에 답하려고했습니다. 그들의 방법과 과정은 여전히 ​​매력적이며 결론은 오늘날에도 여전히 유효하며 정보에 입각 한 답변을 제공하려는 더 나은 시도는 알지 못합니다. 그들은 성능 차이에 대한 잠재적 인 이유에 대한 논의 가 가설적이고 무익하며, 진정한 논의는 그러한 차이가 실제 세계에 미치는 영향에 대한 경험적 근거 를 가져야한다고 지적했습니다 .

그래서 Old New Raymond Chen 과 Rico Mariani 는 친선 경기의 규칙을 세웠습니다. 장난감 애플리케이션 컨텍스트로 중국어 / 영어 사전이 선택되었습니다. 취미 부수 프로젝트로 코딩 할 수있을만큼 간단하면서도 사소한 데이터 사용 패턴을 보여줄 수있을만큼 복잡합니다. 규칙은 간단하게 시작되었습니다. Raymond는 간단한 C ++ 구현을 코딩했고 Rico 는 정교함없이 한 줄씩 C #으로 마이그레이션 했으며 두 구현 모두 벤치 마크를 실행했습니다. 그 후 여러 번의 최적화 작업이 이어졌습니다.

전체 세부 정보는 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 입니다.

이 거인의 대화는 매우 교육적이며 저는 잠수 할 것을 진심으로 권장합니다.하지만 시간이나 인내심이 부족하다면 Jeff Atwood 가 결론을 아름답게 정리했습니다 .

결국 C ++는 2 배 더 빨랐지만 처음에는 13 배 더 느 렸습니다.

Rico 는 다음 과 같이 요약합니다 .

그래서 나는 내 압도적 인 패배에 부끄럽습니까? 거의. 관리 코드는 거의 모든 노력으로 매우 좋은 결과를 얻었습니다. 관리되는 버전을 없애기 위해 Raymond는 다음을 수행해야했습니다.

• 자신의 파일 / io 항목 작성

• 자신의 문자열 클래스 작성

• 자신의 할당 자 작성

• 자신의 국제 매핑 작성

물론 그는이 작업을 위해 사용 가능한 하위 수준 라이브러리를 사용했지만 여전히 많은 작업입니다. 남은 STL 프로그램을 부를 수 있습니까? 나는 그렇게 생각하지 않는다.

그것은 11 년 동안의 제 경험이며 나중에 몇 개의 C # / C ++ 버전을 아는 사람입니다.

That is no coincidence, of course, as these two languages spectacularly achieve their vastly different design goals. C# wants to be used where development cost is the main consideration (still the majority of software), and C++ shines where you'd save no expenses to squeeze every last ounce of performance out of your machine: games, algo-trading, data-centers, etc.

---

C# is faster than C++. Faster to write. For execution times, nothing beats a profiler.

But C# does not have as much libraries as C++ can interface easily.

And C# depends heavily on windows...

---

BTW, time critical applications are not coded in C# or Java, primarily due to uncertainty of when the Garbage Collection will be performed.

In modern times, application or execution speed is not as important as was previously. Development schedules, correctness and robustness are higher priorities. A high speed version of an application is no good if it has lots of bugs, crashes a lot or worse, misses an opportunity to get to market or be deployed.

Since development schedules are a priority, new languages are coming out that speed up development. C# is one of these. C# also assists in correctness and robustness by removing features from C++ that cause common problems: one example is pointers.

The differences in execution speed of an application developed with C# and one developed using C++ is negligible on most platforms. This is due to the fact that the execution bottlenecks are not language dependent but usually depend on the operating system or I/O. For example if C++ performs a function in 5 ms but C# uses 2ms, and waiting for data takes 2 seconds, the time spent in the function is insignificant compared to the time waiting for data.

Choose a language that is best suited for the developers, platform and projects. Work towards the goals of correctness, robustness and deployment. The speed of an application should be treated as a bug: prioritize it, compare to other bugs, and fix as necessary.

---

A better way to look at it everything is slower than C/C++ because it abstracts away rather than following the stick and mud paradigm. It's called systems programming for a reason, you program against the grain or bare metal. Doing so also grants you speed you cannot achieve with other languages like C# or Java. But alas C roots are all about doing things the hard way, so your mostly going to be writing more code and spending more time debugging it.

C is also case sensitive, also objects in C++ also follow strict rule sets. Example a purple ice cream cone may not be the same as a blue ice cream cone, though they might be cones they may not necessarily belong to the cone family and if you forget to define what cone is you bug out. Thus the properties of ice cream may or may not be clones. Now the speed argument, C/C++ uses the stack and heap approach this is where bare metal gets it's metal.

With the boost library you can achieve incredible speeds unfortunately most game studios stick to the standard library. The other reason for this might be because software written in C/C++ tends to be massive in file size, as it's a giant collection of files instead of a single file. Also take note all operating systems are written in C so generally why must we ask the question what could be faster?!

Also caching is not faster than pure memory management, sorry but this just doesn't fan out. Memory is something physical, caching is something software does in order to gain a kick in performance. One could also reason that without physical memory caching would simply not exist. It doesn't void the fact memory must be managed at some level whether its automated or manual.

---

Why would you write a small application that doesn't require much in the way of optimization in C++, if there is a faster route(C#)?

---

Getting an exact answer to your question is not really possible unless you perform benchmarks on specific systems. However, it is still interesting to think about some fundamental differences between programming languages like C# and C++.

Compilation

Executing C# code requires an additional step where the code is JIT'ed. With regard to performance that will be in favor of C++. Also, the JIT compiler is only able to optimize the generated code within the unit of code that is JIT'ed (e.g. a method) while a C++ compiler can optimize across method calls using more aggressive techniques.

However, The JIT compiler is able to optimize the generated machine code to closely match the underlying hardware enabling it to take advantage of additional hardware features if they exist. To my knowledge the .NET JIT compiler doesn't do that but it would conceiveably be able to generate different code for Atom as opposed to Pentium CPU's.

Memory access

The garbage collected architecture can in many cases create more optimal memory access patterns than standard C++ code. If the memory area used for the first generation is small enough in can stay within the CPU cache increasing performance. If you create and destroy a lot of small objects the overhead of maintaing the managed heap may be smaller than what is required by the C++ runtime. Again, this is highly dependent on the application. A study Python of performance demonstrates that a specific managed Python application is able to scale much better than the compiled version as a result of more optimal memory access patterns.

---

Don't let confusing!

• If a C# application is written in the best case and a C++ application is written in the best case, the C++ is faster.
  Many reason is here about why C++ is faster that C# inherently, such as C# uses virtual machine similar to JVM in Java. Basically higher level language has less performance (if uses in best case).

• If you're an experienced professional C# programmer just like you're an experienced professional C++ programmer, developing an application using C# is much more easy and fast than C++.

Many other situations between these situations is possible. For example, you can write an C# application and C++ application so that C# app runs faster than C++ one.

For choosing a language you should note the circumstances of the project and its subject. For a general business project you should use C#. For a hight performance required project like a Video Converter or Image Processing project you should choose C++.

Update:

OK. Lets compare some practical reason about why most possible speed of C++ is more than C#. Consider a good written C# application and same C++ version:

• C# uses a VM as a middle layer for executing the application. It has overhead.
• AFAIK CLR could not optimises all C# codes in target machine. C++ application could be compiled on target machine with most optimisation.
• In C# the most possible optimisation for runtime means most possible fast VM. VM has overhead anyway.
• C# is a higher level language thus it generates more program code lines for the final process. (consider difference between an Assembly application and Ruby one! same condition is between C++ and a higher level language such as C#/Java)

If you prefer to get some more info in practice as an expert, see this. It is about Java but it also applies to C#.

---

The primary concern would not be speed, but stability across windows versions and upgrades. Win32 is mostly immune across windows versions making it highly stable.

When servers are decommissioned and software migrated, A lot of anxiety happens around anything using .Net and usually a lot of panic about .net versions but a Win32 application built 10 years ago just keeps running like nothing happened.

---

I have been specializing in optimization for about 15 years, and regularly re write C++ code, making heavy use of compiler intrinsics as much as possible because C++ performance is often nowhere near what the CPU is capable of. Cache performance often needs to be considered. Many vector maths instructions are required to replace the standard C++ floating point code. A great deal of STL code is re written and often runs many times faster. Maths and code which makes heavy use of data can be re written with spectacular results, as the CPU approaches its optimum performance.

None of this is possible in C#. To compare their relative #real time# performance is really a staggeringly ignorant question. The fastest piece of code in C++ will be when each single assembler instruction is optimised for the task in hand, with no unnecessary instructions - at all. Where each piece of memory is used when it is required, and not copied n times because that’s what the language design requires. Where each required memory movement works in harmony with the cache. Where the final algorithm cannot be improved, based on the exact real time requirements, considering accuracy and functionality.

Then you will be approaching an optimal solution.

To compare C# with this ideal situation is staggering. C# can’t compete. In fact, I am currently re writing a whole bunch of C# code (when I say re writing I mean removing and replacing it completely) because it is not even in the same city, let alone ball park when it comes to heavy lifting real time performance.

So please, stop fooling yourselves. C# is slow. Dead slow. All software is slowing down, and C# is making this speed decline worse. All software runs using the fetch execute cycle in assembler (you know – on the CPU). You use 10 times as many instructions; it’s going to go 10 times as slow. You cripple the cache; it’s going to go even slower. You add garbage collect to a real time piece of software then you are often fooled into thinking that the code runs ‘ok’ there are just those few moments every now and then when the code goes ‘a bit slow for a while’.

모든 사이클이 중요한 코드에 가비지 컬렉션 시스템을 추가해보세요. 주식 시장 거래 소프트웨어에 가비지 수집 기능이 있는지 궁금합니다 (3 억 달러의 비용이 드는 새로운 해저 케이블에서 실행되는 시스템에서?). 2 초마다 300 밀리 초를 절약 할 수 있습니까? 우주 왕복선의 비행 제어 소프트웨어는 어떻습니까? GC는 괜찮습니까? 고성능 차량의 엔진 관리 소프트웨어는 어떻습니까? (시즌의 승리가 수백만의 가치가있는 곳).

실시간 가비지 수집은 완전한 실패입니다.

따라서 아니요, C ++가 훨씬 빠릅니다. C #은 도약입니다.

참고 URL : https://stackoverflow.com/questions/5326269/is-c-sharp-really-slower-than-say-c