C++ 퍼포먼스와Java/C#

C++ 퍼포먼스와Java/C#

잠겼습니다. 이 질문과 답변은이 질문은 부적절하지만 역사적 의미가 있기 때문에 잠겨 있습니다.현재 새로운 답변이나 상호작용을 받아들이지 않고 있습니다.

C/C++는 특정 기계 아키텍처에서 실행할 네이티브 코드를 생성하는 것으로 알고 있습니다.반대로 Java 및 C#과 같은 언어는 네이티브 아키텍처를 추상화하는 가상 머신 위에서 실행됩니다.논리적으로는 이 중간 단계이기 때문에 Java 또는 C#이 C++의 속도를 맞추는 것은 불가능하다고 생각되지만, 최신 컴파일러("핫스팟")는 이 속도를 달성하거나 초과할 수 있다고 들었습니다.

언어 질문이라기보다는 컴파일러 질문일 수도 있지만, 이러한 가상 머신 언어 중 하나가 네이티브 언어보다 더 나은 성능을 발휘하는 방법을 쉬운 영어로 설명할 수 있는 사람은 누구라도 있습니까?

JIT vs. 스태틱 컴파일러

앞서 말한 바와 같이 JIT는 실행 시 IL/바이트 코드를 네이티브 코드로 컴파일할 수 있습니다.이에 대한 비용은 언급되었지만 결론에 이르지는 않았습니다.

JIT에는 모든 것을 컴파일할 수 없다는 큰 문제가 있습니다.JIT 컴파일은 시간이 걸리기 때문에 JIT는 코드의 일부만 컴파일하지만 정적 컴파일러는 완전한 네이티브 바이너리를 생성합니다.어떤 종류의 프로그램에서는 스태틱 컴파일러가 JIT를 쉽게 능가합니다.

물론 C#(또는 Java, 또는 VB)은 보통 C++보다 실행 가능하고 견고한 솔루션을 생성하는 데 더 빠릅니다(C++가 복잡한 의미를 가지며 C++ 표준 라이브러리는 흥미롭고 강력하지만 에서 표준 라이브러리의 전체 범위에 비해 매우 약합니다).NET 또는 Java)는, 통상은 C++ 와의 차이입니다.NET 또는 Java JIT는 대부분의 사용자에게는 표시되지 않습니다.또한 중요한 바이너리의 경우 C# 또는 Java에서 C++ 처리를 호출할 수 있습니다(이러한 네이티브 콜 자체는 비용이 많이 들 수 있습니다).

C++ 메타프로그래밍

보통 C++ 런타임코드와 C# 또는 Java의 동등한 코드를 비교합니다.단, C++에는 Java/C#을 즉시 능가할 수 있는 기능이 1개 있습니다.그것은 템플릿 메타프로그래밍입니다.코드 처리는 컴파일 시(따라서 컴파일 시간이 크게 증가)에 실행되므로 실행 시간이 0(또는 거의 0)이 됩니다.

아직 실제 효과를 본 적이 없습니다(개념만으로 플레이했지만 그때까지 차이는 JIT의 경우 실행 초수, C++의 경우 0초였습니다). 그러나 템플릿 메타프로그래밍이 사소한 것이 아니라는 사실과 함께 언급할 필요가 있습니다.

Edit 2011-06-10: C++에서는 타입을 사용한 재생이 컴파일 시에 이루어집니다.즉, 범용 코드를 생성하는 것은 매우 쉽고 효율적입니다(예를 들어 문자열에서 타입 T로의 범용 파서, 타입 T의 표준 라이브러리 API를 호출하여 사용자가 인식한 파서를 쉽게 확장할 수 있도록 하는 등). C#은 기껏해야 쓰기가 힘들고 컴파일 시에 타입을 알고 있어도 실행 시 항상 느리고 해결됩니다.즉, 유일한 희망은 JIT가 모든 것을 인라인화하는 것입니다.

...

2011-09-20 편집: Blitz++(홈페이지, Wikipedia)의 배후에 있는 팀은 그 방법을 취했고, 그들의 목표는 C++ 템플릿 메타프로그래밍을 통해 런타임 실행에서 컴파일 시간으로 최대한 이동함으로써 FORTRAN의 과학적 계산 성능에 도달하는 것이다. 그래서 내가 위에서 쓴 "이것에 대한 실제 삶의 효과를 아직 본 적이 없다"는 부분은 실생활에 존재하는 것 같다.

네이티브 C++ 메모리 사용량

C++는 Java/C#과 메모리 사용량이 다르기 때문에 장점/플라우가 다릅니다.

JIT의 최적화에 관계없이 메모리에 대한 직접 포인터 액세스만큼 빠른 것은 없습니다(프로세서 캐시 등은 잠시 무시합시다).따라서 메모리에 연속된 데이터가 있는 경우 C++ 포인터(즉, C 포인터)를 통해 액세스합니다.Caesar 게 caesar 、 Java / C # caesar caesar caesar 。 C++에는 RAII 가 되어 있기 C# 나할 수 .는 C++는 필요 .using을 사용법C++ 에는 「C++」가 없습니다.finally절을 클릭합니다.이것은 에러가 아닙니다.

:-)

또한 C#의 프리미티브와 같은 구조에도 불구하고 "스택 위의" C++ 오브젝트는 할당 및 파괴 시 비용이 들지 않으며, 클리닝을 수행하기 위해 독립된 스레드에서 동작하기 위해 GC가 필요하지 않습니다.

메모리 플래그멘테이션의 경우, 2008년의 메모리 할당자는 1980년의 오래된 메모리 할당자가 아닙니다.일반적으로 GC와 비교됩니다.C++ 할당은 메모리 내에서 이동할 수 없습니다.그러나 Linux 파일 시스템과 마찬가지로 다음과 같습니다.플래그멘테이션이 발생하지 않을 때 하드디스크 조각 모음이 필요한 사용자적절한 태스크에 적절한 할당기를 사용하는 것은 C++ 개발자 툴킷의 일부여야 합니다.현재 할당자를 쓰는 것은 쉽지 않습니다.그리고 대부분의 경우 RAII 또는 GC로 충분합니다.

2011-10-04 편집:효율적인 할당자에 대한 예: Windows 플랫폼에서는 Vista 이후 Low Fragmentation Heap이 기본적으로 활성화되어 있습니다.이전 버전에서는 WinAPI 함수 HeapSetInformation)을 호출하여 LFH를 활성화할 수 있습니다.다른 OS에서는 대체 할당기가 제공됩니다(리스트에 대해서는 https://secure.wikimedia.org/wikipedia/en/wiki/Malloc 참조).

현재 메모리 모델은 멀티코어와 멀티스레딩 기술의 등장으로 다소 복잡해지고 있습니다.이 분야에서는요.NET이 유리하고 Java가 우위를 점하고 있다고 들었습니다.'베어메탈' 해커라면 자신의 '머신 근처' 코드를 칭찬하기 쉽습니다.하지만 이제는 컴파일러를 그 일에 투입하는 것보다 손으로 더 나은 조립품을 만드는 것이 훨씬 더 어렵습니다.C++의 경우 컴파일러는 보통 해커보다 10년 이상 우수했습니다.C# 및 Java의 경우 이 작업은 더욱 쉬워집니다.

새로운 표준 C++0x는 C++ 컴파일러에 심플한 메모리 모델을 도입하여 C++의 효과적인 멀티프로세서/패럴렐/스레딩 코드를 표준화(및 심플화)하여 컴파일러의 최적화를 보다 쉽고 안전하게 합니다.하지만, 그렇다면, 우리는 몇 년 후에 그 약속이 사실인지 알게 될 것이다.

C++/CLI와C#/VB.NET

주의: 이 섹션에서는 C++/CLI, 즉가 호스트하는 C++에 대해 설명합니다.NET, 네이티브 C++가 아닙니다.

지난주에는 에 대한 교육을 받았습니다.어쨌든 스태틱 컴파일러가 매우 중요하다는 것을 알게 되었습니다.JIT만큼 중요하죠.

C++/CLI로 컴파일된 동일한 코드(또는 그 상위 코드인 Managed C++)는 C#(또는 VB)에서 생성된 동일한 코드보다 속도가 2배 더 빠를 수 있습니다.컴파일러가 C#과 같은 IL을 생성하는 NET).

C++ 스태틱 컴파일러는 C#보다 이미 최적화된 코드를 생성하는 것이 훨씬 더 좋았기 때문입니다.

예를 들어 의 함수 inlining을 입력합니다.NET은 바이트 코드의 길이가 32바이트 이하인 함수로 제한됩니다.따라서 C#의 일부 코드에서는 40바이트의 접근기가 생성되며, 이 접근기는 JIT에 의해 삽입되지 않습니다.C++/CLI 의 같은 코드에 의해서 20 바이트의 액세스처가 생성되어 JIT 에 의해서 인스톨 됩니다.

또 다른 예로는 C++ 컴파일러에 의해 컴파일되고 C# 컴파일러에 의해 생성된 IL에 기재되어 있는 일시적인 변수가 있습니다.C++ 정적 컴파일을 최적화하면 코드가 줄어들기 때문에 보다 적극적인 JIT 최적화가 허용됩니다.

그 이유는 C++/CLI 컴파일러가 C++ 네이티브 컴파일러의 방대한 최적화 기술로부터 이익을 얻었기 때문이라고 추측되고 있습니다.

결론

C++ 좋아해요.

하지만 내가 보기엔 C#이나 Java가 더 나은 것 같아.C++보다 속도가 빠르기 때문이 아니라 C++보다 품질이 향상되고 훈련도 덜 필요하며 표준 라이브러리가 더 완전하기 때문입니다.그리고 대부분의 프로그램에서 속도 차이는 무시할 수 있을 것입니다.

편집(2011-06-06)

C#/에서의 나의 경험.그물

5개월 동안 거의 독점적인 프로페셔널한 C# 코딩(C++와 Java, 그리고 C++/CLI 터치 포함)을 받았습니다.

WinForms (Ahem...)와 WCF (cool!!)와 WPF (cool!!)를 가지고 놀았습니다.XAML과 raw C#을 모두 통과합니다.WPF는 너무 쉬워서 Swing은 비교가 안 될 것 같아)와 C#4.0.

결론은 C++보다 C#/Java에서 작동하는 코드를 만드는 것이 더 쉽고 더 빠르지만, C#(Java에서는 더 어렵고, C++에서는 더 강력하고 안전하며 강력한 코드를 만드는 것이 훨씬 더 어렵다는 것입니다.이유는 다양하지만 다음과 같이 요약할 수 있습니다.

1. 제네릭은 템플릿만큼 강력하지 않습니다(문제를 이해하기 위해 효율적인 범용 해석 메서드(문자열에서T까지) 또는 부스트와 동등한 효율적인 해석 메서드를 C#에 기술하려고 합니다.
2. RAII는 일치하지 않습니다(GC는 아직 리크할 수 있습니다(네, 그 문제에 대처해야 했습니다).메모리만 처리합니다. 올바른 Dispose 구현을 기술하는 것은 어렵기 때문에 C#도 쉽고 강력하지 않습니다.)
3. C# 및 Java는 C++의 빌트인 기능이지만 C#의 복잡한 데이터(노드 트리 등)를 큰 작업 없이 표시할 수 있는 방법은 없습니다. 불변의 데이터는 흥미로운 솔루션이지만 모든 것을 불변의 것으로 만들 수 있는 것은 아니기 때문에 아직 충분하지 않습니다).

그래서 C#은 당신이 효과가 있는 것을 원하는 한 즐거운 언어로 남지만, 당신이 항상 안전하게 효과가 있는 것을 원하는 순간에는 좌절감을 주는 언어로 남습니다.

는 C과 같은 있기 의 C#에 하는 문제가 때문입니다.using키워드는 매우 숙련된 동료인데, C++에서는 (파괴자와 스마트 포인터를 사용하여) 리소스가 올바르게 해방되는 것을 확인하는 데 너무 많은 시간을 할애했습니다.

C#/Java의 생산성 향상은 대부분의 코드에서 볼 수 있습니다.가능한 한 완벽한 코드를 필요로 하는 날까지요그날, 당신은 고통을 알게 될 것입니다.(서버와 GUI 어플리케이션의 요구를 믿을 수 없을 것입니다).

서버측 Java 및 C++에 대해서

건물 반대편에 있는 서버팀(GUI팀으로 돌아가기 전 2년간 함께 근무)과 연락을 취하면서 흥미로운 사실을 알게 되었습니다.

자바에는 많은 프레임워크/툴이 있고 유지 보수, 도입 등이 용이하기 때문에 자바 서버 앱이 오래된 C++ 서버 앱을 대체하는 경향이 있었습니다.

...지난 몇 달 동안 대기 시간이 짧다는 문제가 불거지기 전까지.그 후, Java 서버 앱은 숙련된 Java 팀이 어떤 방법으로 최적화를 시도하든, 실제로는 최적화되지 않은 오래된 C++ 서버와의 경쟁에서 단순하고 깔끔하게 패배했습니다.

현시점에서는 Java 서버를 퍼포먼스는 중요하지만 레이텐시가 짧은 타깃에 관계없이 공통적으로 사용할 수 있도록 유지하고 이미 고속화된 C++ 서버 애플리케이션을 레이텐시가 짧은 초레이텐시의 요구에 따라 적극적으로 최적화하기로 결정했습니다.

결론

기대만큼 간단한 것은 없다.

Java 및 더 많은 C#는 광범위한 표준 라이브러리와 프레임워크를 갖춘 멋진 언어입니다. 이 라이브러리는 빠르게 코드화할 수 있으며 빠른 시일 내에 결과를 얻을 수 있습니다.

단, 강력한 파워, 강력하고 체계적인 최적화, 강력한 컴파일러 지원, 강력한 언어 기능 및 절대적인 안전성을 필요로 하는 경우 Java 및 C#는 경쟁사보다 높은 품질을 유지하기 위해 필요한 마지막 부족하지만 중요한 %의 품질을 획득하기가 어렵습니다.

C++보다 C#/Java에서 평균적인 품질 코드를 생성하는 데 시간과 경험이 적은 개발자가 필요한 것처럼 보이지만, 다른 한편으로, 뛰어난 품질 코드와 완벽한 품질 코드가 필요한 순간, C++에서 올바른 결과를 얻는 것이 갑자기 쉽고 빨라졌습니다.

물론 이것은 저 자신의 인식이며, 아마도 우리의 특정 요구에 한정되어 있을 것입니다.

그러나 오늘날 GUI 팀과 서버 측 팀 모두 이와 같은 일이 일어나고 있습니다.

물론 새로운 일이 생기면 이 게시물을 업데이트하겠습니다.

편집(2011-06-22)

「퍼포먼스에 관해서는, C++가 큰폭으로 우위에 있는 것을 알 수 있습니다.그러나 가장 광범위한 튜닝 작업도 필요했는데, 그 중 대부분은 일반 프로그래머가 이용할 수 없는 정교함 수준에서 수행되었습니다.

[...] Java 버전이 구현하기 가장 간단했지만 성능을 분석하기가 가장 어려웠습니다.특히 쓰레기 수거에 대한 영향은 복잡하고 조정하기가 매우 어렵습니다."

출처:

• https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
• http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests

편집(2011-09-20)

"Facebook에서는 '합리적으로 작성된 C++ 코드는 빠르게 실행된다'는 말이 유행하고 있습니다. 이는 PHP와 Java 코드를 최적화하기 위해 들인 엄청난 노력을 보여줍니다.역설적으로 C++ 코드는 다른 언어보다 쓰기 어렵지만 효율적인 코드는 [다른 언어보다 C++로 쓰기] 훨씬 쉽습니다.

– Herb Sutter at //build/, Andrei Alexandrescu 인용

출처:

• http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T
• http://video.ch9.ms/build/2011/slides/TOOL-835T_Sutter.pptx

일반적으로 C#과 Java는 같은 속도 또는 속도를 낼 수 있습니다.이는 JIT 컴파일러(IL을 처음 실행할 때 컴파일하는 컴파일러)가 C++ 컴파일된 프로그램을 쿼리할 수 있기 때문에 할 수 없는 최적화를 할 수 있기 때문입니다.머신이 Intel인지 AMD인지, Pentium 4, Core Solo 또는 Core Duo인지, SSE4를 지원하는지 등을 판별할 수 있습니다.

C++ 프로그램은 모든 머신에서 정상적으로 실행되도록 보통 혼합 최적화를 사용하여 사전에 컴파일해야 하지만 단일 구성(프로세서, 명령 세트, 기타 하드웨어)에 비해 최적화되지 않습니다.

또한 특정 언어 기능을 통해 C# 및 Java의 컴파일러는 C/C++ 컴파일러에 안전하지 않은 특정 부분을 최적화할 수 있는 코드를 가정할 수 있습니다.포인터에 액세스 할 수 있는 경우, 많은 최적화가 안전하지 않습니다.

또한 Java와 C#은 가비지 콜렉터와 코드 간의 추상화 레이어를 통해 모든 힙 압축을 한 번에 실행할 수 있기 때문에 C++보다 효율적으로 힙 할당을 수행할 수 있습니다(고가의 작업).

다음 점에서는 Java를 대변할 수 없지만 예를 들어 C#은 메서드의 본문이 비어 있는 것을 알고 있을 때 메서드와 메서드 호출을 실제로 삭제합니다.코드 전체에 이런 논리를 사용합니다.

보시다시피 특정 C# 또는 Java의 구현이 빨라지는 데는 여러 가지 이유가 있습니다.

C++에서는 특정 최적화를 할 수 있기 때문에 특히 그래픽 영역이나 하드웨어에 가까운 장소에서는 C#에서 할 수 있는 모든 작업이 무효가 됩니다.여기서 포인터는 놀라운 일을 한다.

그래서 네가 뭘 쓰느냐에 따라 나는 둘 중 하나를 택할 거야.그러나 하드웨어에 의존하지 않는 것(드라이버, 비디오 게임 등)을 쓰고 있다면 C#의 퍼포먼스에 대해서는 걱정하지 않습니다(Java에 대해서는 다시 말할 수 없습니다).잘 될 거야.

자바 쪽에서는 @Swati가 좋은 기사를 지적하고 있습니다.

https://www.ibm.com/developerworks/library/j-jtp09275

매니지드 퍼포먼스와 매니지드 퍼포먼스를 이야기할 때마다 Rico(및 Raymond)가 중국어/영어 사전의 C++ 버전과 C# 버전을 비교한 시리즈를 지적합니다.이 구글 검색은 당신이 직접 읽을 수 있게 해줄 것이지만, 나는 리코의 요약이 마음에 든다.

그래서 내가 참패한 게 부끄럽다는 거야?전혀.관리된 코드는 거의 노력하지 않고 매우 좋은 결과를 얻었습니다.관리 대상인 레이먼드를 물리치려면 다음과 같이 해야 했습니다.

• 파일 I/O 관련 내용을 직접 작성하다
• 자신의 문자열 클래스를 작성합니다.
• 자신의 할당자를 쓰다
• 자신의 국제 지도를 작성하다

물론 그는 이것을 하기 위해 이용 가능한 하위 수준의 라이브러리를 사용했지만, 그것은 여전히 많은 작업입니다.남아 있는 STL 프로그램을 호출할 수 있습니까?저는 그렇게 생각하지 않습니다.결국 문제가 되지 않는 std::vector 클래스를 유지하고 find 기능을 유지했다고 생각합니다.다른 건 거의 다 사라졌어요

그래, 넌 분명히 CLR을 이길 수 있어.레이먼드가 프로그램을 더 빨리 진행할 수 있을 것 같아요

흥미롭게도 두 프로그램의 내부 타이머가 보고하는 파일을 해석하는 시간은 각각 30ms로 거의 비슷합니다.오버헤드에 차이가 있습니다.

결론은 관리 대상 버전이 원래 관리 대상 코드의 단순한 포트였던 관리 대상 버전을 이기려면 6개의 리비전이 필요했다는 것입니다.모든 퍼포먼스를 필요로 하는 경우(및 그것을 얻기 위한 시간과 전문지식이 있는 경우)에는 관리되지 않는 상태로 전환해야 합니다.그러나 저는 6번 시도했을 때 얻을 수 있는 33%보다 첫 번째 버전이 훨씬 유리합니다.

특정 CPU 최적화를 위한 컴파일은 일반적으로 과대평가됩니다.C++의 프로그램을 펜티엄 PRO에 최적화하여 컴파일하고 펜티엄4에서 실행하기만 하면 됩니다.그런 다음 펜티엄 4용으로 최적화하여 다시 컴파일합니다.나는 여러 프로그램으로 그것을 하면서 긴 오후를 보냈다.일반적인 결과?보통 2~3% 미만의 성능 향상따라서 이론적으로 JIT의 이점은 거의 없습니다.성능의 차이는 대부분 스칼라 데이터 처리 기능을 사용할 때만 확인할 수 있습니다.이 기능을 사용하려면 최종적으로 수동 미세 조정이 필요합니다.이러한 종류의 최적화는 실행 속도가 느리고 비용이 많이 들기 때문에 JIT에 적합하지 않을 수 있습니다.

실제 및 실제 애플리케이션에서는 C++가 Java보다 더 빠릅니다. 이는 주로 메모리 설치 공간이 적기 때문에 캐시 성능이 향상되기 때문입니다.

하지만 C++ 기능을 모두 사용하려면 개발자가 열심히 일해야 합니다.우수한 결과를 얻을 수 있지만, 그러기 위해서는 머리를 써야 합니다.C++는 당신에게 더 많은 도구를 제공하기로 결정한 언어이며, 당신이 언어를 잘 사용하기 위해 그들이 배워야 하는 대가를 지불한다.

JIT(Just In Time Compiling)는 타겟 플랫폼에 최적화되어 있어 매우 고속입니다.

즉, 개발자가 코드를 작성한 CPU에 관계없이 CPU가 지원할 수 있는 컴파일러 트릭을 이용할 수 있습니다.

의 기본 개념입니다.NET JIT는 다음과 같이 동작합니다(매우 심플화).

메서드를 처음 호출하는 경우:

• 프로그램 코드가 메서드 Foo()를 호출합니다.
• CLR은 Foo()를 구현하는 유형을 확인하여 관련된 메타데이터를 가져옵니다.
• CLR은 메타데이터를 통해 IL(Intermediate 바이트 코드)이 저장되어 있는 메모리주소를 알 수 있습니다.
• CLR은 메모리 블록을 할당하고 JIT를 호출합니다.
• JIT는 IL을 네이티브코드로 컴파일하여 할당된 메모리에 배치한 후 Foo()의 유형 메타데이터에서 이 네이티브코드를 가리키도록 함수 포인터를 변경합니다.
• 네이티브 코드가 실행됩니다.

두 번째 메서드 호출:

• 프로그램 코드가 메서드 Foo()를 호출합니다.
• CLR은 Foo()를 구현하는 유형을 살펴보고 메타데이터에서 함수 포인터를 찾습니다.
• 이 메모리 위치의 네이티브 코드가 실행됩니다.

보시는 바와 같이 두 번째는 실시간 최적화의 이점을 제외하고는 C++와 거의 동일한 프로세스입니다.

관리 언어를 느리게 하는 다른 오버헤드 문제도 있지만 JIT가 많은 도움이 됩니다.

나는 오리온 에이드리언의 대답을 좋아하지만, 그것에는 다른 측면이 있다.

어셈블리 언어 vs. 수십 년 전에 동일한 질문이 제기되었습니다.FORTRAN과 같은 "인간" 언어. 그리고 그 대답의 일부는 비슷합니다.

네, C++ 프로그램은 어떤 알고리즘에서도 C#보다 빠를 수 있지만, C#의 프로그램은 C++의 "순진한" 구현보다 빠를 수 있습니다.또한 C++의 최적화된 버전은 개발하는데 시간이 오래 걸리고 C# 버전보다 매우 작은 차이로 이길 수도 있습니다.그래서, 정말 그럴 가치가 있을까요?

당신은 그 질문에 하나하나 대답해야 합니다.

하지만 저는 C++의 오랜 팬입니다.그리고 C++는 놀라울 정도로 표현력이 풍부하고 강력한 언어라고 생각합니다.때로는 인정받지 못할 때도 있습니다.그러나, 많은 「실생활」문제(개인적으로는 「돈을 받고 해결할 수 있는 문제」를 의미)에서, C#는 보다 빠르고 안전하게 일을 완수할 수 있습니다.

가장 큰 벌금은?많은 .NET 및 Java 프로그램은 메모리호그입니다나는 본 적이 있다.NET 및 Java 앱은 유사한 복잡성의 C++ 프로그램이 MB의 "10"을 거의 긁지 못할 때 "수백 메가바이트"의 메모리를 사용합니다.

Hotspot을 사용하더라도 Java 코드가 C++보다 더 빨리 실행될지 모르겠지만, 어떻게 실행되는지 설명하겠습니다.

컴파일된 Java 코드를 JVM의 해석된 기계어로 간주합니다.Hotspot 프로세서는 컴파일된 코드의 특정 부분이 여러 번 사용되는 것을 감지하면 기계 코드에 대한 최적화를 수행합니다.수동 조정 어셈블리는 거의 항상 C++ 컴파일된 코드보다 빠르기 때문에 프로그래밍 방식으로 조정된 기계 코드가 그리 나쁘지 않을 것으로 생각됩니다.

따라서, 매우 반복적인 코드의 경우, Hotspot JVM이 C++보다 더 빨리 Java를 실행할 수 있는 곳을 알 수 있었습니다.쓰레기 수거 작업이 시작될 때까지요:)

일반적으로 프로그램 알고리즘은 언어보다 응용 프로그램의 속도에 훨씬 더 중요합니다.C++ 를 포함한, 모든 언어로 서투른 알고리즘을 실장할 수 있습니다.이 점에 유의하면 일반적으로 보다 효율적인 알고리즘을 구현하는 데 도움이 되는 언어로 실행 코드를 보다 빠르게 작성할 수 있습니다.

높은 수준의 언어는 효율적인 사전 구축 데이터 구조에 쉽게 접근할 수 있도록 하고 비효율적인 코드를 방지하는 데 도움이 되는 방법을 장려함으로써 이 문제를 매우 효과적으로 해결할 수 있습니다.물론 느린 코드도 쉽게 작성할 수 있기 때문에 플랫폼을 알아야 합니다.

또한 C++는 STL 컨테이너, 자동 포인터 등의 "새로운" 기능(따옴표 참조)을 따라잡고 있습니다.그리고 어떤 작업을 가장 빨리 완료하는 방법에는 포인터 산술과 같은 기술이 필요할 수 있습니다.이것은 고도의 언어에서는 금지되어 있습니다.다만, 이러한 기술을 사용하면, 필요에 따라서 실행할 수 있는 언어로 작성된 라이브러리를 호출할 수 있습니다.

중요한 것은 사용하고 있는 언어, 관련 API, 기능 및 제한 사항을 파악하는 것입니다.

모르겠어요. Java 프로그램은 항상 느려요. :-) 근데 C# 프로그램이 그렇게 느리다는 건 본 적이 없어요.

여기 또 다른 흥미로운 벤치마크가 있습니다. 자신의 컴퓨터에서 직접 사용해 볼 수 있습니다.

ASM, VC++, C#, Silverlight, Java 애플릿, Javascript, Flash(AS3)를 비교합니다.

Rozz 플러그인 속도 데모

javascript의 속도는 실행하는 브라우저에 따라 크게 달라지므로 주의하시기 바랍니다.이러한 플러그인은 호스팅 브라우저와 동일한 프로세스로 실행되므로 Flash 및 Silverlight도 마찬가지입니다.그러나 Rozz 플러그인은 자체 프로세스로 실행되는 표준 .exe 파일을 실행하므로 속도는 호스팅 브라우저의 영향을 받지 않습니다.

perform better than...을 정의해야 합니다.음, 속도에 대해 물어봤지만 중요한 건 그게 다가 아니야

• 가상 시스템이 더 많은 런타임 오버헤드를 수행합니까?네!
• 그들은 더 많은 작업 기억을 먹나요?네!
• 스타트업 비용이 더 높습니까(런타임 초기화 및 JIT 컴파일러)? 네!
• 큰 도서관을 설치해야 하나요?네!

그래서 편견이 있습니다.그렇습니다.

C# 및 Java를 사용하면 제공되는 제품(더 빠른 코딩, 자동 메모리 관리, 대용량 라이브러리 등)에 대한 대가를 치를 수 있습니다.하지만 당신은 세부 사항에 대해 흥정할 여지가 많지 않다: 완전한 패키지를 가져가든지 아니면 아무것도 없다.

이러한 언어가 컴파일된 코드보다 더 빨리 실행되도록 일부 코드를 최적화할 수 있더라도 전체 접근 방식은 비효율적입니다(IMHO).매일 직장까지 5마일씩 트럭으로 운전한다고 상상해 보세요!쾌적하고, 기분 좋고, 안전하며(극도의 구김살 영역), 잠시 동안 가속하면 일반 자동차와 같은 속도입니다!우리 모두 트럭을 운전해서 출근하는 게 어때?;)

C++에서는, 그 이상도 이하도 아닌, 지불한 것을 얻을 수 있습니다.

Bjarne Strostrup을 인용: "C++는 가비지를 거의 생성하지 않기 때문에 내가 가장 좋아하는 가비지 수집 언어입니다" 링크 텍스트

Java 또는 C# 컴파일러에서 생성된 실행 가능 코드는 해석되지 않고 네이티브 코드 "JIT"(Just in Time)로 컴파일됩니다.따라서 Java/C# 프로그램의 첫 번째 코드가 실행 중에 발견되면 "런타임 컴파일러"(일명 JIT 컴파일러)가 바이트 코드(Java) 또는 IL 코드(C#)를 네이티브 머신 명령으로 변환하기 때문에 약간의 오버헤드가 발생합니다.그러나 응용 프로그램 실행 중에 다음 번에 해당 코드가 발견되면 네이티브 코드가 즉시 실행됩니다.일부 Java/C# 프로그램이 처음에는 느린 것처럼 보이지만 실행 시간이 길어질수록 성능이 향상되는 이유를 설명합니다.좋은 예로는 ASP가 있습니다.인터넷 웹 사이트웹사이트에 처음 접속했을 때 C#코드가 JIT 컴파일러에 의해 네이티브코드로 컴파일되기 때문에 조금 느려질 수 있습니다.이후 액세스로 인해 웹 사이트가 훨씬 더 빨라집니다. 즉, 서버 및 클라이언트 측 캐싱은 따로 보관됩니다.

질문하신 내용에 대한 좋은 답변이 여기 있습니다.뒤로 물러서서 더 큰 그림을 보고 싶습니다.

작성한 소프트웨어의 속도에 대한 사용자의 인식은 코드젠의 최적화 정도뿐만 아니라 다른 많은 요인에 의해 영향을 받는다는 점에 유의하십시오.다음은 몇 가지 예입니다.

• 수동 메모리 관리는 올바르게 실시하기 어렵고(누설이 없고), 효율적으로 실시하기 어렵습니다(완료 후 바로 빈 메모리).일반적으로 GC를 사용하면 메모리를 잘 관리하는 프로그램이 생성될 가능성이 높아집니다.GC를 능가하기 위해 열심히 일하고 소프트웨어 제공을 연기할 의향이 있습니까?

• C#은 C++보다 읽기 쉽고 이해하기 쉽습니다.또, C#코드가 올바르게 동작하고 있는 것을 스스로 납득할 수 있는 방법도 많이 있습니다.즉, 버그가 발생할 위험을 줄이면서 알고리즘을 최적화할 수 있습니다(또한 사용자는 소프트웨어 크래시가 빠르게 발생하더라도 소프트웨어를 좋아하지 않습니다).

• C++보다 C#에서 소프트웨어를 빠르게 작성할 수 있습니다.그 때문에, 퍼포먼스에 관한 작업에 시간을 할애할 수 있게 되어, 소프트웨어를 제시간에 납품할 수 있게 됩니다.

• C++보다 C#에 좋은 UI를 쓰는 것이 쉽기 때문에 UI가 반응하는 동안 작업을 백그라운드로 푸시하거나 프로그램이 잠시 차단해야 할 때 진행 또는 하트비트 UI를 제공할 수 있습니다.이것은 아무것도 더 빨리 하는 것은 아니지만, 사용자가 기다리는 것을 더 행복하게 만듭니다.

제가 C#에 대해 말한 모든 것이 Java에 해당될 수 있습니다.확실히 말할 수 있는 경험은 없습니다.

만약 당신이 C++를 배우는 Java/C# 프로그래머라면, 당신은 Java/C#의 관점에서 계속 생각하고 말 그대로 C++ 구문으로 번역하고 싶을 것이다.이 경우 앞서 언급한 네이티브 코드와 해석 코드/J의 이점만 얻을 수 있습니다.IT. C++와 C++의 비교에서 가장 큰 퍼포먼스 향상을 실현하기 위해Java/C#, C++의 장점을 활용하기 위해서는 C++로 사고하는 방법과 특별히 코드를 설계하는 방법을 배워야 합니다.

Edsger Dijkstra를 바꿔 말하면, [당신의 모국어]는 회복할 수 없을 정도로 정신을 손상시킨다.
Jeff Atwood를 바꿔 말하면, 당신은 어떤 새로운 언어로도 [당신의 모국어]를 쓸 수 있다.

가장 중요한 JIT 최적화 중 하나는 메서드 인라인입니다.Java는 실행 시 정확성을 보장할 수 있는 경우 가상 메서드를 인라인화할 수도 있습니다.이러한 종류의 최적화는 일반적으로 표준 정적 컴파일러에서는 실행할 수 없습니다.이는 개별 컴파일로 인해 어렵기 때문입니다(반면 JIT는 모든 프로그램을 이용할 수 있습니다).메서드 인라인은 다른 최적화를 개선하여 더 큰 코드 블록을 최적화합니다.

Java/C#의 표준 메모리 할당도 고속이며, 할당 해제(GC)는 그다지 느리지 않을 뿐더러 결정성도 낮습니다.

가상 머신 언어는 컴파일된 언어를 능가할 가능성은 낮지만 적어도 다음과 같은 이유로 충분히 가까워질 수 있습니다(C#을 실행한 적이 없기 때문에 Java를 말합니다).

1/ Java Runtime Environment는 일반적으로 자주 실행되는 코드 조각을 검출하고 이러한 섹션의 JIT(Just-In-Time) 컴파일을 수행하여 향후 완전한 컴파일 속도로 실행할 수 있도록 합니다.

2/ Java 라이브러리의 많은 부분이 컴파일되어 있기 때문에 라이브러리 함수를 호출하면 해석되지 않고 컴파일된 코드를 실행할 수 있습니다.OpenJDK를 다운로드하면 (C의) 코드를 볼 수 있습니다.

3/ 대규모 계산을 하지 않는 한 프로그램이 실행되는 대부분의 시간에는 매우 느린(상대적으로 말하면) 사람의 입력을 기다립니다.

4/ Java 바이트 코드의 검증은 클래스 로드 시에 많이 이루어지기 때문에 런타임 체크의 일반적인 오버헤드가 대폭 감소합니다.

5/ 최악의 경우 성능 집약적인 코드를 컴파일된 모듈로 추출하여 Java(JNI 참조)에서 호출하여 최대 속도로 실행할 수 있습니다.

요약하면 Java 바이트코드는 네이티브 머신 언어를 절대 능가하지 않지만 이를 완화할 수 있는 방법이 있습니다.Java의 가장 큰 장점은 거대 표준 라이브러리와 크로스 플랫폼 특성입니다.

오리온 에이드리언 씨, 당신의 발언이 얼마나 근거가 없는지를 보기 위해 당신의 글을 뒤집겠습니다. 왜냐하면 C++에 대해서도 많은 말이 나올 수 있기 때문입니다.또한 Java/C# 컴파일러가 빈 함수를 최적화한다고 하면 최적화에 대한 내 전문가가 아닌 것처럼 들릴 수 있습니다.a) 실제 프로그램에 빈 함수가 포함되어 있어야 하는 이유는 a) 정말 나쁜 레거시 코드, b) 실제로는 검지 않고 엣지 최적화를 하지 않기 때문입니다.

그 문구를 제외하고, 당신은 포인터에 대해 노골적으로 외쳤지만, Java와 C#의 오브젝트는 기본적으로 C++ 포인터처럼 기능하지 않나요?겹치지 않을까요?그들은 무효가 아닐까요?C(및 대부분의 C++ 실장)에는 restrict 키워드가 있으며, 둘 다 값 타입이 있으며, C++에는 null이 아닌 보증의 reference-to-value가 있습니다.Java와 C#은 무엇을 제공합니까?

>>>>>>>>

일반적으로 C와 C++는 같은 속도 또는 속도를 낼 수 있습니다.AOT 컴파일러는 전개 전에 코드를 컴파일하는 컴파일러로 대량의 코어 빌드 서버 상에서 마지막으로 컴파일하기 때문에 C# 컴파일 프로그램에서는 할 수 없는 최적화를 할 수 있기 때문입니다.컴파일러는 머신이 Intel인지 AMD인지, Pentium 4, Core Solo 또는 Core Duo인지, SSE4 등을 지원하는지 여부를 판별할 수 있습니다.또, 사용의 컴파일러가 런타임 디스패치를 서포트하고 있지 않은 경우는, 몇개의 전용 바이너리를 전개하는 것으로 해결할 수 있습니다.

C# 프로그램은 일반적으로 실행 시 컴파일되어 모든 머신에서 정상적으로 실행되지만 단일 구성(프로세서, 명령어 세트, 기타 하드웨어 등)에 대해서는 최적화되지 않습니다.이 프로그램에는 시간이 걸립니다.루프 핵분열, 루프 반전, 자동 벡터화, 전체 프로그램 최적화, 템플릿 확장, IPO 등과 같은 기능은 최종 사용자를 성가시게 하지 않는 방법으로 모두 완전히 해결하기가 매우 어렵습니다.

또한 C++ 또는 C의 컴파일러는 Java/C# 컴파일러에 안전하지 않은 특정 부분을 최적화할 수 있는 코드를 가정할 수 있습니다.제네릭스의 풀타입 ID 또는 보장된 프로그램 흐름에 액세스할 수 없는 경우 많은 최적화가 안전하지 않습니다.

또한 C++와 C는 하나의 레지스터 증분만으로 많은 스택 할당을 동시에 수행합니다.이는 가비지 컬렉터와 코드 간의 추상화 레이어에 관해서는 Javas 및 C# 할당보다 확실히 효율적입니다.

다음 점에서는 Java를 대변할 수 없지만 예를 들어 C++ 컴파일러는 메서드 본문이 비어 있는 것을 알고 있을 때 메서드와 메서드 호출을 실제로 삭제하고 일반적인 서브 표현식을 제거하며 최적의 레지스터 사용 방법을 찾으려고 시도할 수 있습니다.경계 체크를 강제하지 않고 루프와 내부 구조를 자동 추출합니다.루프를 내부로부터 외부로 반전시켜, 루프로부터 조건부 이동시켜, 분할해, 루프를 언플릿 합니다.C와 마찬가지로 std::vector를 네이티브 제로 오버헤드 어레이로 확장합니다.절차 간 최적화를 수행합니다.발신자 사이트에서 직접 반환값을 구성합니다.그것은 표현을 접고 전파합니다.데이터를 캐시 친화적인 방식으로 재정렬합니다.그것은 점프 스레딩을 할 것이다.런타임 오버헤드가 없는 컴파일 타임레이서를 쓸 수 있습니다.매우 고가의 그래프 기반 최적화를 실현합니다.특정 코드를 구문적으로는 완전히 동일하지 않지만 의미적으로는 동등한 코드로 대체하면 강도가 감소합니다(구 "xor foo, foo"는 가장 단순하지만 구식 최적화입니다).IEEE 부동소수점 표준을 생략하고 부동소수점 연산자 재순서화 등의 최적화를 활성화할 수 있습니다.코드를 마사지하고 대량 학살한 후 전체 프로세스를 반복할 수 있습니다. 왜냐하면 대부분의 경우 특정 최적화는 보다 확실한 최적화를 위한 기반을 마련하기 때문입니다.또한 다른 변종이 내부 순위에서 어떻게 점수를 매기는지 다른 변종 매개 변수를 사용하여 재시도할 수도 있습니다.코드 전체에 이런 논리를 사용합니다.

보시다시피 특정 C++ 또는 C의 구현 속도가 빨라지는 데는 여러 가지 이유가 있습니다.

C++에서는 많은 최적화를 할 수 있기 때문에 특히 수치 계산, 실시간 및 금속에 가까운 영역에서는 C#에서 할 수 있는 모든 작업이 중단됩니다.단, C++에서만 가능한 것은 아닙니다.먼 길을 가기 위해 포인터 하나 만질 필요조차 없습니다.

그래서 네가 뭘 쓰느냐에 따라 나는 둘 중 하나를 택할 거야.그러나 하드웨어에 의존하지 않는 것(드라이버, 비디오 게임 등)을 쓰고 있다면 C#의 퍼포먼스에 대해서는 걱정하지 않습니다(Java에 대해서는 다시 말할 수 없습니다).잘 될 거야.

<<<<<<<<<<

일반적으로, 특정 일반화된 주장은 특정 게시물에서는 쿨하게 들릴 수 있지만, 일반적으로 확실히 신뢰할 수 있는 것처럼 들리지는 않습니다.

어쨌든 평화를 위해: AOT도 좋고 JIT도 좋아요.정답은 다음과 같습니다.사정에 따라 다르겠지.그리고 진정한 똑똑한 사람들은 당신이 두 세계의 장점을 모두 사용할 수 있다는 것을 알고 있습니다.

이것은 Java 인터프리터가 실제로 컴파일러가 작성 중인 C++ 코드에 대해 생성하는 머신 코드보다 더 잘 최적화된 머신 코드를 생성하고 있는 경우에만 발생합니다.C++ 코드는 Java 및 해석 비용보다 느립니다.

그러나 Java가 매우 잘 작성된 라이브러리를 가지고 있고, C++ 라이브러리가 제대로 작성되지 않았다면 실제로 발생할 가능성은 매우 낮습니다.

실제로 C#은 Java처럼 가상 머신에서 실행되지 않습니다.IL은 어셈블리 언어로 컴파일됩니다.이것은 완전히 네이티브코드이며 네이티브코드와 같은 속도로 실행됩니다.프리 J를 사용할 수 있습니다.IT는 JIT 비용을 완전히 제거하고 완전히 네이티브 코드를 실행하는 .NET 애플리케이션입니다.

에서의 속도 저하NET은 이유가 아닙니다.NET 코드는 속도가 느리지만 가비지 수집, 참조 확인, 전체 스택 프레임 저장 등의 작업을 백그라운드에서 훨씬 더 많이 수행하기 때문입니다.이는 애플리케이션 구축 시 매우 강력하고 도움이 될 수 있지만 비용이 많이 듭니다.C++ 프로그램에서도 이러한 모든 작업을 수행할 수 있습니다(코어의 대부분).NET 기능은 실제로 입니다.ROTOR에서 볼 수 있는 NET 코드).다만, 같은 기능을 수동으로 기입했을 경우, 그 이후로는 훨씬 느린 프로그램이 될 가능성이 있습니다.NET 런타임은 최적화 및 미세 조정되었습니다.

단, 관리코드의 장점 중 하나는 완전히 검증할 수 있다는 것입니다.즉, 코드를 실행하기 전에 다른 프로세스의 메모리에 액세스하거나 경과시간을 단축하지 않는 것을 확인할 수 있습니다.Microsoft는 완전 관리형 운영체제의 연구용 프로토타입을 제공하고 있습니다.이것에 의해, 이 검증에 의해, 관리 대상 프로그램에 불필요하게 된 시큐러티 기능을 무효로 하는 것으로, 실제로 100%의 관리 대상 환경이, 최신의 operating system보다 큰폭으로 고속으로 동작할 수 있는 것이 밝혀지고 있습니다(이것에 대해서는, 10배).(경우에 따라서는)SE라디오는 이 프로젝트에 대한 에피소드가 아주 좋습니다.

경우에 따라서는 관리 대상 코드가 네이티브 코드보다 더 빠를 수 있습니다.예를 들어 "마크 앤 스위프" 가비지 컬렉션 알고리즘을 사용하면 JRE 또는 CLR과 같은 환경에서 단수명(통상은) 개체를 한 번에 대량 해방할 수 있습니다.이 경우 대부분의 C/C++ 힙 개체는 한 번에 해방됩니다.

Wikipedia에서:

실제로 가비지 수집 언어로 구현된 할당/할당 취소 알고리즘은 수동 힙 할당을 사용하면 실제로 동등한 알고리즘보다 더 빠를 수 있습니다.그 주된 이유는 가비지 컬렉터가 런타임시스템이 잠재적으로 유리한 방법으로 할당 및 할당 해제 작업을 상각할 수 있도록 하기 때문입니다.

즉, 저는 많은 C#과 C++를 썼고 많은 벤치마크를 실행했습니다.제 경험상 C++는 C#보다 훨씬 빠릅니다.C#에서 작성한 코드를 C++로 포팅하면 네이티브 코드가 더 빠릅니다.얼마나 빨라?매우 다양하지만 속도가 100% 향상되는 것은 드문 일이 아닙니다.(2) 가비지 수집으로 인해 관리되는 애플리케이션의 속도가 크게 저하될 수 있습니다..NET CLR은 큰 힙(예를 들어 2GB 이상)에 대해 끔찍한 작업을 수행하며, 중간 수명의 오브젝트가 거의 없거나 아예 없는 애플리케이션에서도 GC에서 많은 시간을 소비하게 됩니다.

물론 지금까지의 대부분의 경우, 관리 언어는 충분히 고속이며, C++의 퍼포먼스 향상을 위한 유지 보수와 코딩의 균형은 그다지 좋지 않습니다.

여기 흥미로운 벤치마크가 있습니다.http://zi.fi/shootout/

실제로 Sun의 HotSpot JVM은 "혼합 모드" 실행을 사용합니다.특정 코드 블록(메서드, 루프, 트라이캐치 블록 등)이 많이 실행될 것이라고 판단할 때까지 메서드의 바이트 코드를 해석한 후 JIT가 컴파일합니다.메서드가 거의 실행되지 않는 메서드일 경우 메서드를 해석하는 경우보다 JIT 컴파일에 필요한 시간이 더 오래 걸리는 경우가 많습니다.JVM이 시간을 낭비하지 않기 때문에 일반적으로 "혼합 모드"의 경우 성능이 향상됩니다.거의 실행되지 않는 ITing 코드.C# 및.NET에서는, 이 조작은 행해지지 않습니다.NET JIT는 대부분의 경우 시간을 낭비합니다.

HP Labs의 Dynamo에 대해 읽어보세요.PA-8000의 인터프리터이며, PA-8000에서 실행되며, 대부분의 경우 네이티브보다 빠르게 프로그램을 실행합니다.그러면 전혀 놀랍지 않을 거야!

'중간 단계'라고 생각하지 마세요.프로그램의 실행에는 이미 어느 언어로든 많은 다른 단계가 포함되어 있습니다.

그 요점은 다음과 같습니다.

• 프로그램에는 핫스팟이 있기 때문에 실행해야 하는 코드의 95%가 느리게 실행되더라도 핫스팟 5%로 고속화하면 퍼포먼스 경쟁력을 유지할 수 있습니다.

• HLL은 C/C++와 같은 LLL보다 고객의 의도를 더 잘 알고 있기 때문에 더 많은 최적화된 코드를 생성할 수 있습니다(OCaml은 더 많은 것을 가지고 있으며, 실제로는 더 빠릅니다).

• JIT 컴파일러에는 스태틱 컴파일러에서는 얻을 수 없는 많은 정보가 있습니다(이번에 얻은 실제 데이터 등).

• JIT 컴파일러는 기존 링커가 할 수 없었던 최적화를 런타임에 실행할 수 있습니다(일반적인 케이스가 평평하도록 브랜치를 재정렬하거나 라이브러리 호출을 인라인화하는 등).

대체로 C/C++는 퍼포먼스에 있어서 매우 서투른 언어입니다.데이터 타입에 대한 정보가 비교적 적고, 데이터에 대한 정보도 없으며, 런타임 최적화에 도움이 되는 동적 런타임도 없습니다.

Java 또는 CLR이 C++보다 빠르면 짧은 버스트가 발생할 수 있지만 애플리케이션 수명 동안 전반적으로 성능이 저하됩니다.그 결과에 대해서는, www.codeproject.com/KB/dotnet/RuntimePerformance.aspx 를 참조해 주세요.

다음은 Cliff Click의 답변입니다.http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

C/C++는 특정 기계 아키텍처에서 실행할 네이티브 코드를 생성하는 것으로 알고 있습니다.반대로 Java 및 C#과 같은 언어는 네이티브 아키텍처를 추상화하는 가상 머신 위에서 실행됩니다.논리적으로는 이 중간 단계이기 때문에 Java 또는 C#이 C++의 속도를 맞추는 것은 불가능하다고 생각되지만, 최신 컴파일러("핫스팟")는 이 속도를 달성하거나 초과할 수 있다고 들었습니다.

그건 말도 안 돼요.중간 표현을 사용한다고 해서 성능이 본질적으로 저하되는 것은 아닙니다.예를 들어 llvm-gcc는 LLVM IR(가상 무한 레지스터 머신)을 통해 C와 C++를 네이티브 코드로 컴파일하여 뛰어난 퍼포먼스(종종 GCC를 능가)를 실현합니다.

언어 질문이라기보다는 컴파일러 질문일 수도 있지만, 이러한 가상 머신 언어 중 하나가 네이티브 언어보다 더 나은 성능을 발휘하는 방법을 쉬운 영어로 설명할 수 있는 사람은 누구라도 있습니까?

다음은 몇 가지 예입니다.

• JIT 기능을 가상 JIT 컴파일 기능:System.Reflection.Emit.를 C#및할 수 를 C C로.NET)를 사용하면 생성된 코드를 C# 및 F#과 같은 언어로 즉시 컴파일할 수 있지만 비교적 느린 인터프리터를 C 또는 C++로 작성할 필요가 있습니다.이치

• 가상 머신의 일부(예: 쓰기 장벽 및 할당기)는 C와 C++가 충분히 빠른 코드를 생성하지 못하기 때문에 손으로 코딩된 어셈블러로 작성되는 경우가 많습니다.프로그램이 시스템의 이러한 부분을 강조하면 C 또는 C++로 쓸 수 있는 어떤 것도 능가할 수 있습니다.

• 네이티브 코드의 동적 링크에는 퍼포먼스를 저해하고 프로그램 전체의 최적화를 회피하는 ABI 준수가 필요하지만 링크는 통상 VM 상에서 지연되어 프로그램 전체의 최적화의 이점을 얻을 수 있습니다(등).NET의 검증된 범용 기기).

또, Paercebal의 매우 높은 응답에 대해서도 몇개의 문제에 대해 이야기하고 싶습니다(누군가가 자신의 답변에 대한 제 코멘트를 계속 삭제하고 있기 때문에).이러한 문제는, 생산적으로 양극화된 견해를 나타내고 있습니다.

코드 처리는 컴파일 시에 완료됩니다.

따라서 템플릿 메타프로그래밍은 프로그램이 컴파일 시에 이용 가능한 경우에만 동작합니다.예를 들어 런타임 코드 생성(메타프로그래밍의 중요한 측면)이 불가능하기 때문에 바닐라 C++에서는 경쟁적으로 성능이 뛰어난 정규 표현 라이브러리를 작성할 수 없습니다.

...타입으로 재생은 컴파일 시에 완료됩니다...Java 또는 C#의 등가물은 기껏해야 쓰기가 힘들고 컴파일 시 유형이 알려져 있어도 실행 시 항상 느리고 해결됩니다.

C#에서는 참조 유형에만 해당되며 값 유형에는 해당되지 않습니다.

JIT 최적화에 관계없이 메모리에 대한 직접 포인터 액세스만큼 빠른 것은 없습니다.메모리에 연속된 데이터가 있는 경우, C++ 포인터를 통해 액세스합니다(예: C 포인터...Caesar에게 당연한 것을 전하자)는 Java/C#보다 몇 배나 더 빨리 진행됩니다.

사람들은 포인터가 에일리어싱 관련 최적화를 방해하기 때문에 정확히 SciMark2 벤치마크에서 SOR 테스트에서 Java가 C++를 이기는 것을 관찰해 왔다.

그것도 주의할 필요가 있습니다.NET은 링크 후에 동적으로 링크된 라이브러리 간에 제네릭스의 전문화를 입력하는 반면, C++는 링크 전에 템플릿을 해결해야 하기 때문에 그렇지 않습니다.템플릿에 비해 제네릭이 갖는 가장 큰 장점은 이해 가능한 오류 메시지입니다.

내가 알기로는 다른 사람들이 말한 것 외에.메모리 할당은 NET 및 Java가 더 우수합니다.예를 들어 C++는 메모리를 압축할 수 없는 반면 C++는 압축할 수 없습니다(네이티브로, 현명한 가비지 콜렉터를 사용하고 있는 경우는 압축할 수 있습니다).

고속화가 필요한 경우 JVM은 C++ 구현을 호출합니다.따라서 JVM이 대부분의 OS 관련 작업에 얼마나 적합한지보다 Lib가 얼마나 좋은지에 대한 질문이 더 많습니다.가비지 컬렉션을 사용하면 메모리가 반으로 줄어들지만, 일부 고급 STL 및 Boost 기능을 사용하면 동일한 효과를 얻을 수 있지만 버그의 가능성은 몇 배나 됩니다.

클래스가 많은 대규모 프로젝트에서 C++ 라이브러리와 많은 고급 기능을 사용하는 경우 JVM을 사용하는 것보다 속도가 느려질 수 있습니다.에러가 발생하기 쉬운 경우는 제외합니다.

단, C++의 장점은 자신을 최적화할 수 있다는 것입니다.그렇지 않으면 컴파일러/jvm의 조작에 얽매이게 됩니다.독자적으로 컨테이너를 만들고 정렬된 메모리 관리를 작성하여 SIMD를 사용하여 여기저기 조립하는 경우 대부분의 C++ 컴파일러가 수행하는 작업보다 최소 2배에서 4배 더 고속화할 수 있습니다.일부 동작의 경우 16x-32x입니다.같은 알고리즘을 사용하면 더 나은 알고리즘을 사용하여 병렬화하면 증가 속도가 극적으로 향상될 수 있습니다.때로는 일반적으로 사용되는 방법보다 수천 배나 빠를 수 있습니다.

나는 몇 가지 다른 관점에서 그것을 바라본다.

1. 시간과 리소스가 무한할 경우 관리 코드 또는 관리되지 않는 코드가 더 빠릅니까?대답은 관리대상 외 코드가 적어도 이 측면에서는 관리대상 코드를 항상 연결할 수 있다는 것입니다.최악의 경우 관리대상 코드 솔루션을 하드 코드화하기만 하면 됩니다.
2. 한 언어로 된 프로그램을 다른 언어로 직접 번역하면 성능이 얼마나 나빠질까요?아마 두 가지 언어라면 많을 거예요.대부분의 언어는 다른 최적화를 필요로 하며 다른 gotcha를 가지고 있습니다.마이크로 퍼포먼스는 이러한 세부 사항을 파악하는 데 많은 도움이 됩니다.
3. 한정된 시간과 자원이 주어진다면 두 언어 중 어떤 언어가 더 나은 결과를 낳을까요?이것은 가장 흥미로운 질문입니다.관리 대상 언어에서는 약간 느린 코드가 생성될 수 있지만(해당 언어에 대해 합리적으로 기술된 프로그램이 있으면), 그 버전은 더 빨리 완료되기 때문에 최적화에 더 많은 시간을 할애할 수 있기 때문입니다.

간단한 답변: 예산이 정해져 있으면 C++ 어플리케이션보다 성능이 뛰어난 Java 어플리케이션을 실현할 수 있습니다(ROI 고려사항).또한 Java 플랫폼에는 보다 뛰어난 프로파일러가 탑재되어 있어 핫스팟을 보다 신속하게 특정할 수 있습니다.

언급URL : https://stackoverflow.com/questions/145110/c-performance-vs-java-c