Java가 C ++보다 빠른 이유는 무엇입니까?

때로는 Java가 벤치 마크에서 C ++보다 성능이 뛰어납니다. 물론 C ++보다 성능이 뛰어납니다.

다음 링크를 참조하십시오.

• http://keithlea.com/javabench/
• http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
• http://blog.cfelde.com/2010/06/c-vs-java-performance/

그러나 이것이 어떻게 가능합니까? 해석 된 바이트 코드가 컴파일 된 언어보다 빠를 수 있다고 생각합니다.

누군가 설명해 주시겠습니까? 감사!

첫째, 대부분의 JVM에는 컴파일러가 포함되어 있으므로 "해석 된 바이트 코드"는 실제로는 거의 드물다 (적어도 벤치 마크 코드에서는 실제로는 드물지 않다). ).

둘째, 관련 벤치 마크의 상당수가 상당히 편향되어있는 것으로 보입니다 (의도 나 무능함에 따라 실제로 말할 수는 없습니다). 예를 들어, 몇 년 전에 게시 한 링크 중 하나에서 링크 된 소스 코드 중 일부를 살펴 보았습니다. 다음과 같은 코드가 있습니다.

  init0 = (int*)calloc(max_x,sizeof(int));
  init1 = (int*)calloc(max_x,sizeof(int));
  init2 = (int*)calloc(max_x,sizeof(int));
  for (x=0; x<max_x; x++) {
    init2[x] = 0;
    init1[x] = 0;
    init0[x] = 0;
  }

calloc이미 제로화 된 메모리를 제공 하므로 for루프를 다시 제로화하는 것은 쓸모가 없습니다. 어쨌든 다른 데이터로 메모리를 채우고 (제로화되는 것에 의존하지 않음) 메모리가 제공되면 모든 제로화는 완전히 불필요합니다. 위의 코드를 간단한 것으로 교체하면 malloc(다른 사람이 처음 사용했던 것처럼) C ++ 버전의 속도가 향상되어 Java 버전을 능가 할만큼 (메모리가 제공되는 경우 상당히 넓은 마진으로) 향상되었습니다.

methcall마지막 링크의 블로그 항목에 사용 된 벤치 마크 를 고려하십시오 (다른 예) . 이름 (및 상황이 어떻게 보일지)에도 불구하고 C ++ 버전은 실제로 메소드 호출 오버 헤드에 대해별로 측정 하지 않습니다 . 중요한 것으로 밝혀진 코드 부분은 Toggle 클래스에 있습니다.

class Toggle {
public:
    Toggle(bool start_state) : state(start_state) { }
    virtual ~Toggle() {  }
    bool value() {
        return(state);
    }
    virtual Toggle& activate() {
        state = !state;
        return(*this);
    }
    bool state;
};

중요한 부분은로 밝혀졌습니다 state = !state;. 우리가 같은 상태를 인코딩하기 위해 코드를 변경할 때 발생하는 고려 int대신의 bool:

class Toggle {
    enum names{ bfalse = -1, btrue = 1};
    const static names values[2];
    int state;

public:
    Toggle(bool start_state) : state(values[start_state]) 
    { }
    virtual ~Toggle() {  }
    bool value() {  return state==btrue;    }

    virtual Toggle& activate() {
        state = -state;
        return(*this);
    }
};

이 작은 변화는 전체 속도를 약 5 : 1 마진 향상시킵니다 . 벤치 마크가되었다 비록 의도 한 현실에서,이 측정 된 것을 대부분의 메소드 호출 시간을 측정 사이의 변환을 할 수있는 시간이었다 int및 bool. 나는 원래의 비 효율성이 불행하다는 것에 분명히 동의하지만, 실제 코드에서 거의 발생하지 않는 것처럼 보이며 그것이 발생할 때 / 고정 될 때 쉽게 고칠 수 있다고 생각하면 어려운 시간을 보내고 있습니다. 그것의 많은 의미로.

누구든지 관련된 벤치 마크를 다시 실행하기로 결정한 경우 Java 버전에 거의 똑같이 수정 된 내용이 있거나 추가로 테스트를 다시 실행하지 않은 Java 버전이 추가되어야한다고 덧붙여 야합니다 최근 JVM은 여전히 ​​확인합니다.) Java 버전도 상당히 향상되었습니다. Java 버전에는 다음과 같은 NthToggle :: activate ()가 있습니다.

public Toggle activate() {
this.counter += 1;
if (this.counter >= this.count_max) {
    this.state = !this.state;
    this.counter = 0;
}
return(this);
}

this.state직접 조작하는 대신 기본 함수를 호출하도록 이것을 변경하면 속도가 상당히 향상됩니다 (수정 된 C ++ 버전을 따라갈 수는 없지만).

그래서 우리가 끝내는 것은 해석 된 바이트 코드와 내가 본 최악의 벤치 마크 중 일부에 대한 잘못된 가정입니다. 의미있는 결과를 제공하지도 않습니다.

저 자신의 경험은 동일하게 숙련 된 프로그래머가 최적화에 동일한 관심을 기울이면 C ++이 Java보다 더 자주 이길 수 있지만 (적어도이 둘 사이에서) 언어는 프로그래머와 디자인만큼 큰 차이를 만들지 않습니다. 인용 된 벤치 마크는 벤치마킹하려는 언어에 대한 것보다 저자의 유능함 / 부정직함에 대해 더 많이 알려줍니다.

[편집 : 위의 한 곳에서 암시되었지만 필자가해야 할 것으로 직접 언급하지는 않았지만 인용 한 결과는 ~ 5 년 전에 테스트했을 때 얻은 결과입니다. 현재 당시의 C ++ 및 Java 구현을 사용하여 . 현재 구현으로 테스트를 다시 실행하지 않았습니다. 그러나 한 눈에 코드가 수정되지 않았으므로 코드의 문제를 해결할 수있는 컴파일러의 기능 만 변경 될 것입니다.]

우리는 자바 예제를 무시하면 그러나, 이다 해석 코드 (어렵고 다소 특이한하지만) 컴파일 된 코드보다 빠르게 실행하는 데 실제로 가능합니다.

일반적으로 해석되는 코드는 머신 코드보다 훨씬 간결하거나 코드 캐시보다 데이터 캐시가 더 큰 CPU에서 실행되고 있습니다.

이러한 경우 작은 해석기 (예 : Forth 구현의 내부 해석기)는 코드 캐시에 완전히 들어갈 수 있으며 해석하는 프로그램은 데이터 캐시에 완전히 들어갈 수 있습니다. 캐시는 일반적으로 주 메모리보다 10 배 이상 빠르며 종종 훨씬 더 많습니다 (100 배는 더 이상 드물지 않습니다).

따라서 캐시가 기본 메모리보다 N의 인자만큼 빠르고 각 바이트 코드를 구현하는 데 N 머신 코드 명령보다 적은 시간이 걸리면 바이트 코드가 승리해야합니다 (단순하지만 일반적인 아이디어는 여전히 분명하다).

무제한 시간을 가진 전문가가 수행 한 수동 롤링 C / C ++ 는 적어도 Java보다 빠르거나 빠릅니다. 궁극적으로 Java 자체는 C / C ++로 작성되므로 충분한 엔지니어링 노력을 기울이고 싶다면 Java가하는 모든 작업을 수행 할 수 있습니다.

그러나 실제로 Java는 종종 다음과 같은 이유로 매우 빠르게 실행됩니다.

• JIT 컴파일-Java 클래스는 바이트 코드로 저장되지만 프로그램이 시작될 때 JIT 컴파일러에서 기본 코드로 컴파일됩니다 (보통). 일단 컴파일되면 순수한 원시 코드입니다. 따라서 이론적으로 프로그램이 오랫동안 실행 된 후에 (즉, 모든 JIT 컴파일이 완료된 후) 컴파일 된 C / C ++와 마찬가지로 수행 할 수 있습니다.
• Java의 가비지 콜렉션 은 매우 빠르고 효율적입니다. Hotspot GC는 아마도 세계 최고의 GC 구현 일 것입니다. 썬과 다른 회사들이 수년간의 전문적인 노력을 기울인 결과입니다. C / C ++로 롤백하는 복잡한 메모리 관리 시스템은 거의 나빠질 것입니다. 물론 C / C ++로 매우 빠르고 가벼운 기본 메모리 관리 체계를 작성할 수 있지만 완전한 GC 시스템만큼 다재다능하지는 않습니다. 대부분의 최신 시스템에는 복잡한 메모리 관리가 필요하므로 Java는 실제 상황에 큰 이점이 있습니다.
• 더 나은 플랫폼 타게팅 -애플리케이션 시작 (JIT 컴파일 등)으로 컴파일을 지연시킴으로써 Java 컴파일러 는 실행중인 정확한 프로세서를 알고 있다는 사실을 이용할 수 있습니다 . 이를 통해 "가장 낮은 공통 분모"프로세서 명령어 세트를 대상으로해야하는 사전 컴파일 된 C / C ++ 코드에서 수행 할 수없는 매우 유용한 최적화를 수행 할 수 있습니다.
• 런타임 통계 -JIT 컴파일은 런타임에 수행되므로 프로그램이 실행되는 동안 통계를 수집하여 더 나은 최적화를 가능하게합니다 (예 : 특정 분기가 수행 될 확률을 알 수 있음). 이를 통해 Java JIT 컴파일러는 C / C ++ 컴파일러보다 더 나은 코드를 생성 할 수 있습니다 (가장 가능성이 높은 분기를 미리 "추측"해야 함).
• 매우 우수한 라이브러리 -Java 런타임에는 성능이 우수한 (특히 서버 측 응용 프로그램 용) 매우 잘 작성된 라이브러리가 포함되어 있습니다. 종종 스스로 작성하거나 C / C ++에서 쉽게 얻을 수있는 것보다 낫습니다.

동시에 C / C ++에는 몇 가지 장점이 있습니다.

• 고급 최적화를 수행하는 데 더 많은 시간 -C / C ++ 컴파일은 한 번 수행되므로 고급 최적화를 수행하도록 구성하면 상당한 시간을 할애 할 수 있습니다. Java가 그렇게 할 수없는 이론적 인 이유는 없지만 실제로는 Java가 코드를 비교적 빠르게 JIT 컴파일하기를 원하므로 JIT 컴파일러는 "더 간단한"최적화에 집중하는 경향이 있습니다.
• 바이트 코드로 표현할 수없는 명령어 -Java 바이트 코드는 완전한 범용이지만, 바이트 코드로는 할 수없는 낮은 수준에서 수행 할 수있는 작업이 여전히 있습니다 (체크되지 않은 포인터 산술이 좋은 예입니다!). 이러한 종류의 트릭을 사용하면 성능 이점을 얻을 수 있습니다.
• "안전성"제약 완화-Java 는 프로그램이 안전하고 신뢰할 수 있도록하기 위해 추가 작업을 수행합니다. 배열에 대한 경계 검사, 특정 동시성 보장, 널 포인터 검사, 캐스트에 대한 유형 안전 등이 있습니다. C / C ++에서는이를 피함으로써 약간의 성능 향상을 얻을 수 있습니다.

사무용 겉옷:

• Java 및 C / C ++는 비슷한 속도를 달성 할 수 있습니다
• C / C ++는 극한 상황에서 약간 우위에있을 것입니다 (예 : AAA 게임 개발자가 여전히 선호하는 것은 놀라운 일이 아닙니다)
• 실제로 그것은 위에 나열된 여러 가지 요소가 특정 응용 프로그램에 어떻게 균형을 맞추는 지에 달려 있습니다.

Java 런타임 이 바이트 코드를 해석하지 않습니다. 오히려 Just In Time Compilation을 사용 합니다. 기본적으로 프로그램이 실행되면 바이트 코드를 사용하여 특정 CPU에 최적화 된 기본 코드로 변환합니다.

모든 것이 동등하다는 것은 말할 수 있습니다. 아니요, Java는 결코 빠를 수 없습니다 . 항상 C ++에서 Java를 처음부터 처음부터 구현할 수 있으므로 최소한 좋은 성능을 얻을 수 있습니다. 그러나 실제로 :

• JIT 는 최종 사용자 컴퓨터에서 코드를 컴파일 하여 실행중인 정확한 CPU에 맞게 최적화합니다. 컴파일에는 오버 헤드가 있지만 집중적 인 앱의 경우 비용이 많이 듭니다. 실제 프로그램은 종종 사용중인 CPU 용으로 컴파일되지 않습니다.
• Java 컴파일러는 C ++ 컴파일러보다 자동으로 최적화하는 것이 좋습니다. 또는 현실 세계에서는 상황이 항상 완벽하지는 않습니다.
• 가비지 수집과 같은 다른 요소로 인해 성능 동작이 달라질 수 있습니다. C ++에서는 일반적으로 객체 작업이 완료되면 즉시 소멸자를 호출합니다. Java에서는 단순히 참조를 해제하여 실제 소멸을 지연시킵니다. 이것은 성능 측면에서 차이가없는 또 다른 예입니다. 물론, 당신은 C ++로 GC를 구현하고 그것을 할 수 있다고 주장 할 수 있지만, 실제로는 거의 / 할 수있는 사람 / 할 수있는 사람이 거의 없다는 것이 현실입니다.

따로, 이것은 80 년대 / 90 년대 C에 관한 토론을 떠올리게합니다. 모든 사람들은 "C가 어셈블리만큼 빠를 수 있을까?" 기본적으로 대답은 종이에 없었지만 실제로 C 컴파일러는 어셈블리 프로그래머의 90 %보다 더 효율적인 코드를 만들었습니다 (약간 성숙 해지면).

그러나 할당은 메모리 관리의 절반에 불과합니다. 할당 해제는 나머지 절반입니다. 대부분의 객체에서 직접 가비지 수집 비용은 0입니다. 복사 수집기는 죽은 개체를 방문하거나 복사 할 필요가없고 살아있는 개체 만 복사 할 수 있기 때문입니다. 따라서 할당 직후 가비지가되는 개체는 수집주기에 워크로드를 제공하지 않습니다.

...

JVM은 놀랍게도 개발자 만 알 수 있다고 생각했던 것을 알아내는 데 능숙합니다. JVM이 사례별로 스택 할당과 힙 할당을 선택할 수 있도록함으로써 프로그래머가 스택에 할당할지 힙에 할당할지 고민하지 않고도 스택 할당의 성능 이점을 얻을 수 있습니다.

http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html

완전히 최적화 된 Java 프로그램은 완전히 최적화 된 C ++ 프로그램을 거의 능가하지 않지만, 메모리 관리와 같은 차이점은 C ++에서 관용적으로 구현 된 동일한 알고리즘보다 많은 알고리즘을 Java로 관용적으로 구현할 수 있습니다.

@Jerry Coffin이 지적했듯이 간단한 변경으로 코드를 훨씬 빠르게 만들 수있는 경우가 많이 있지만 성능 향상을 위해 한 언어 또는 다른 언어로 부정확 한 조정이 필요한 경우가 종종 있습니다. 아마도 C ++보다 Java가 더 잘 작동한다는 것을 보여주는 훌륭한 벤치 마크 에서 볼 수 있습니다 .

또한 일반적으로 그다지 중요하지는 않지만 Java와 같은 JIT 언어로 C ++에서 할 수없는 성능 최적화가 있습니다. Java 런타임에는 코드가 컴파일 된 후 개선 된 기능이 포함될 수 있습니다 . 이는 JIT가 잠재적으로 새로운 (또는 최소한 다른) CPU 기능을 활용하기 위해 최적화 된 코드를 생성 할 수 있음을 의미합니다. 이러한 이유로 10 년 된 Java 바이너리는 10 년 된 C ++ 바이너리보다 성능이 우수 할 수 있습니다.

마지막으로 큰 그림에서 완전한 유형 안전은 매우 드물지만 성능을 크게 향상시킬 수 있습니다. 거의 전적으로 C # 기반 언어로 작성된 실험용 OS 인 Singularity 는 하드웨어 프로세스 경계 나 값 비싼 컨텍스트 스위치가 필요하지 않기 때문에 프로세스 간 통신 및 멀티 태스킹이 훨씬 빠릅니다.

JavaRanch에 Tim Holloway가 게시 :

기본 예는 다음과 같습니다. 기계가 수학적으로 결정된 주기로 작동 할 때 분기 명령은 일반적으로 두 가지 다른 타이밍을가집니다. 하나는 가지를 찍었을 때, 다른 하나는 가지를 찍지 않을 때를 위해. 일반적으로 분기가없는 경우가 더 빠릅니다. 분명히 이것은 어떤 경우가 더 흔했는지에 대한 지식을 바탕으로 논리를 최적화 할 수 있음을 의미했습니다 (우리가 "알고있는"것이 항상 실제로는 아니라는 제약 조건에 따라).

JIT 재 컴파일은이 단계를 한 단계 더 발전시킵니다. 실제 실시간 사용량을 모니터링하고 실제로 가장 일반적인 경우에 따라 논리를 뒤집습니다. 작업량이 바뀌면 다시 뒤집으십시오. 정적으로 컴파일 된 코드는이 작업을 수행 할 수 없습니다. 이것이 자바가 때때로 수동 튜닝 어셈블리 / C / C ++ 코드를 능가하는 방법입니다.

출처 : http://www.coderanch.com/t/547458/Performance/java/Ahead-Time-vs-Just-time

이는 C ++ 프로그램을 빌드 할 때 명시 적이 지 않고 Java 프로그램을 실행할 때 머신 코드를 생성하는 최종 단계 가 JVM 내부 에서 투명하게 발생하기 때문입니다 .

현대 JVM은 바이트 코드를 가능한 빨리 원시 머신 코드로 컴파일하는 데 많은 시간을 소비한다는 사실을 고려해야합니다. 이를 통해 JVM은 실행중인 프로그램의 프로파일 링 데이터를 알면 더 나은 모든 종류의 컴파일러 트릭을 수행 할 수 있습니다.

게터를 자동으로 인라인하는 것만으로 값을 얻는 데 JUMP-RETURN이 필요하지 않으며 속도가 빨라집니다.

그러나 실제로 빠른 프로그램을 허용 한 것은 나중에 정리하는 것이 좋습니다. Java의 가비지 수집 메커니즘은 C에서 수동 malloc-free보다 빠릅니다 . 많은 현대 malloc-free 구현은 아래에 가비지 수집기를 사용합니다.

짧은 대답-그렇지 않습니다. 잊어 버려요, 주제는 불이나 바퀴만큼 오래되었습니다. Java 또는 .NET은 C / C ++보다 빠르지 않습니다. 최적화에 대해 전혀 생각할 필요가없는 대부분의 작업에는 충분히 빠릅니다. 양식 및 SQL 처리와 유사하지만 그것이 끝나는 곳입니다.

예를 들어, 무능한 개발자가 작성한 벤치 마크 또는 작은 앱의 경우 최종 결과는 Java / .NET이 가깝고 더 빠를 것입니다.

실제로 스택에 메모리를 할당하거나 단순히 memzone을 사용하는 것과 같은 간단한 작업은 Java / .NET을 즉시 중단시킵니다.

쓰레기 수거 세계는 모든 회계와 함께 일종의 막을 사용하고 있습니다. C에 막을 추가하면 C가 그 자리에서 더 빨라집니다. 특히 Java 대 C "고성능 코드"벤치 마크의 경우 다음과 같습니다.

for(...)
{
alloc_memory//Allocating heap in a loop is verrry good, in't it?
zero_memory//Extra zeroing, we really need it in our performance code
do_stuff//something like memory[i]++
realloc//This is lovely speedup
strlen//loop through all memory, because storing string length is soo getting old
free//Java will do that outside out timing loop, but oh well, we're comparing apples to oranges here
}//loop 100000 times

C / C ++ (또는 새로운 배치)에서 스택 기반 변수를 사용해보십시오 sub esp, 0xff. 이것은 단일 x86 명령어이며 Java로 이길 수 있습니다.

대부분의 경우 Java와 C ++을 비교하는 벤치가 표시되는 것처럼 보입니다. 잘못된 메모리 할당 전략, 준비금이없는 자체 재배 컨테이너, 여러 가지 새로운 기능. 이것은 성능 지향적 인 C / C ++ 코드에 가깝지 않습니다.

또한 읽어보십시오 : https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

실제로 프로그래머가 지시하는대로 정확하게 수행하는 고급 어셈블러이며, 프로그래머가 지시 한 순서대로 프로그래머가 지시하는 방식을 알 수 있습니다. 성능 차이는 모든 실제적인 목적에 필연적으로 작습니다.

언어는 "느린"것이 아니며, 프로그래머는 느린 프로그램을 썼습니다. 연구의 저자가 자신의 특정 도끼를 갈아 치우지 않는 한, 대체 언어의 최선의 방법을 사용하여 같은 일을하는 프로그램보다 (실제적인 목적으로) 한 언어로 가장 좋은 방법으로 작성된 프로그램은 거의 없습니다.

하드 리얼 타임 임베디드 시스템과 같은 희귀 한 경우를 선택한다면 언어 선택에 차이가 생길 수 있지만 얼마나 자주 발생합니까? 그리고 그러한 경우에, 올바른 선택이 얼마나 자주 눈에 띄지 않습니까?

다음 링크를 참조하십시오 ... 그러나 이것이 어떻게 가능합니까? 해석 된 바이트 코드가 컴파일 된 언어보다 빠를 수 있다고 생각합니다.

1. 해당 블로그 게시물이 신뢰할만한 증거를 제공합니까?
2. 해당 블로그 게시물이 확실한 증거를 제공합니까?
3. 이 블로그 게시물은 "해석 된 바이트 코드"에 대한 증거를 제공합니까?

Keith Lea는 "명백한 결함"이 있다고 말하지만 "명백한 결함"에 대해서는 아무 것도하지 않습니다. 2005 년에이 오래된 작업은 버려져 벤치 마크 게임에 표시된 작업으로 대체되었습니다 .

Keith Lea는 "현재 구식 Great Computer Language Shootout에서 C ++ 및 Java에 대한 벤치 마크 코드를 가져 와서 테스트를 수행했습니다"라고 말하지만 실제로 는 구식 테스트 중 25 개 중 14 개에 대한 측정치 만 표시합니다 .

Keith Lea는 7 년 전 블로그 게시물에서 아무 것도 증명하려하지 않았다고 말했지만, 당시에는 "사람들이 자바가 느리다고 느낀다고 들었습니다. 매우 빠르다 ..." 당시에는 그가 증명하려는 것이있었습니다.

Christian Felde는 "코드를 만들지 않고 테스트를 다시 실행합니다"라고 말합니다. 그와 같이 Keith Lea가 선택한 작업 및 프로그램의 측정을 공개하기로 한 그의 결정에 대한 책임에서 그를 제외시켰다.

25 개의 아주 작은 프로그램의 측정도 확실한 증거를 제공합니까?

이러한 측정은 "혼합 모드"로 실행되는 프로그램에 대한 것입니다. Java가 해석되지 않은 Java- "HotSpot 작동 방식을 기억하십시오." Java가 "해석 된 바이트 코드"를 얼마나 잘 실행하는지 쉽게 알 수 있습니다. Java가 바이트 코드 만 해석 하도록 할 수 있기 때문 입니다. -Xint 옵션을 사용하거나 사용하지 않고 일부 Java 프로그램을 실행하기 만하면됩니다.

이 "해석 된 바이트 코드"라는 이상한 개념이 얼마나 널리 퍼져 있는지를 즐겁게 해줍니다. JIT 컴파일에 대해 들어 본 적이 있습니까? 귀하의 주장은 Java에 적용 할 수 없습니다.

그러나 JVM을 제외하고 직접 스레드 코드 또는 사소한 바이트 코드 해석으로 최적화 된 네이티브 코드를 쉽게 능가하는 경우가 있습니다. 설명은 매우 간단합니다. 바이트 코드는 매우 작을 수 있으며 동일한 알고리즘의 기본 코드 버전이 단일 반복에 대해 여러 개의 캐시 누락이 발생하는 경우 작은 캐시에 적합합니다.

JIT, GC 등을 제외하면 C ++은 Java보다 훨씬 더 느리게 만들어 질 수 있습니다. 이것은 벤치 마크에는 나타나지 않지만 Java 개발자와 C ++ 개발자가 작성한 동일한 앱은 Java에서 훨씬 빠릅니다.

• 운영자 과부하. "+"또는 "="와 같은 모든 간단한 연산자는 안전 검사, 디스크 작업, 로깅, 추적 및 프로파일 링을 수행하는 수백 줄의 코드를 호출 할 수 있습니다. 또한 사용하기가 너무 쉬워서 일단 운영자에게 과부하가 걸리면 사용법이 어떻게 누적되는지 알지 못하고 자연스럽고 적절하게 사용할 수 있습니다.
• 템플릿. 메모리만큼 속도에 영향을 미치지 않습니다. 템플릿을주의해서 사용하면 사용자가 눈치 채지 않고도 수백만 줄의 코드 (기본 템플릿의 대안)를 생성 할 수 있습니다. 그러나 이진 로딩 시간, 메모리 사용량, 스왑 사용량은 벤치 마크에 대해서도 작용합니다. 그리고 RAM 사용은 지붕을 통과합니다.

고급 상속 패턴에 관해서는 이것들과 거의 비슷합니다. C ++에는 Java와는 다른 것들이 있으며 그 반대도 마찬가지입니다. 따라서 객체가 많은 프로그래밍에서 특별한 C ++ 이점이 없습니다.

한 가지 더 경고 : GC는 수동으로 할당을 관리하는 것보다 빠르거나 느릴 수 있습니다. 작은 개체를 많이 할당하면 GC 환경에서 일반적으로 메모리 청크가 할당되고 새 개체에 필요한만큼 조각이 전달됩니다. 관리 대상-각 개체 = 개별 할당에 상당한 시간이 걸립니다. OTOH, 많은 메모리를 한 번에 malloc () 한 다음 수동으로 객체에 할당하거나 더 큰 객체 인스턴스를 사용하면 훨씬 더 빨리 올 수 있습니다.

어떻게 든 스택 교환은 다른 스택 포인트를 사용하지 않으므로 불행히도 회신이 없습니다 ...

그러나 여기에서 두 번째로 많은 투표를 한 답변은 겸손한 의견으로 잘못된 정보로 가득합니다.

C / C ++의 전문가가 직접 제작 한 앱은 항상 Java 애플리케이션보다 훨씬 빠릅니다. 'Java 또는 Faster만큼 빠르지 않습니다'. 아래 인용 항목으로 인해 더 빠릅니다.

JIT 컴파일 : 자동 최적화 프로그램이 전문가 프로그래머의 지능을 가지고 CPU가 실제로 실행하려는 의도와 코드 사이의 링크를 볼 것으로 기대하십니까? 또한 모든 JIT는 이미 컴파일 된 프로그램과 비교하여 시간이 손실됩니다.

가비지 콜렉션 은 프로그래머가 할당을 잊어 버린 자원을 다소 효율적으로 할당 해제하는 도구입니다.

분명히 이것은 C 프로그래머가 자신의 메모리를 처리하기 위해 수행하는 전문가 (당신이 용어를 고른 것)보다 느릴 수 있습니다 (정확하게 작성된 앱에는 누수가 없음).

성능 최적화 된 C 응용 프로그램은 실행중인 CPU를 알고 있으며 CPU에 컴파일되어 있습니다. 그렇지 않으면 성능에 대한 모든 단계를 수행하지 않은 것입니까?

런타임 통계 이것은 내 지식을 초월하지만 C 전문가가 자동 최적화를 다시 능가하기에 충분한 분기 예측 지식을 가지고 있다고 생각합니다.

매우 우수한 라이브러리 Java의 라이브러리를 통해 쉽게 최적화 할 수없는 기능이 많이 있으며 모든 언어에서 동일하지만 가장 최적화 된 라이브러리는 특히 계산을 위해 C로 작성됩니다.

JVM 은 추상화 계층으로, 위의 많은 것들이 모두 좋은 것을 의미하며 전체 솔루션이 설계 상 느리다는 것을 의미합니다.

사무용 겉옷:

Java는 보호, 기능 및 도구가 많은 JVM에서 작동하는 방식으로 인해 C / C ++의 속도에 도달 할 수 없습니다.

C ++는 컴퓨팅이나 게임용으로 최적화 된 소프트웨어에서 분명한 우위를 점하고 있으며, C ++ 구현이 두 번째 페이지에서만 볼 수있는 최고의 Java 구현이라는 점에서 코딩 콘테스트에서 승리하는 것이 일반적입니다.

실제로 C ++은 장난감이 아니며 대부분의 현대 언어가 처리 할 수있는 많은 실수를 피할 수는 없지만 간단하고 안전하지 않기 때문에 본질적으로 빠릅니다.

결론적으로, 나는 대부분의 사람들이 이것에 대해 2 센트를주지 않는다고 말하고 싶습니다. 결국 최적화는 소수의 운이 좋은 개발자에게만 제공되는 스포츠이며 성능이 실제로 문제가되는 경우를 제외하고는 (즉, 하드웨어에 10을 곱해도 도움이되지 않거나 최소한 수백만을 대표하지 않는 경우) 대부분의 관리자는 최적화되지 않은 앱과 수많은 하드웨어를 선호합니다.

나는 자바에서 적어도 두 가지 인상적인 mmo가 수행되는 것을 보았습니다. 게임에 충분하지 않은 것은 잘못된 것입니다. 게임 디자이너가 다른 언어보다 C ++을 더 선호하기 때문에 단순히 Java 관련이 아니라고 말하면 프로그래머가 다른 프로그래밍 언어 / 패러다임과 전혀 관련이 없다고 말한 것입니다. C / C ++ 또는 Java와 같은 고급 언어는 속도 인수를 기술적으로 충족 시키거나 이길 수있는 코드를 생성 할 수 있습니다. 잘하고 말한 것은 프로그래머가 아는 것, 팀이 무엇을 가장 많이 사용하는지, 무엇보다 중요한 것은 왜 툴을 사용하는지에 달려 있습니다. 우리는 프로그래밍의 게임 개발 측면을 다루고 있으므로 논쟁의 여지가 더 많을 것입니다. 간단히 말해 QA를 충족하고 실제 환경에서 C ++를 Java 또는 다른 언어보다 C ++을 선택해야하는 이유에 대해서는 비즈니스 데드 세트에 대한 돈과 시간에 관한 모든 것이 중요하지 않습니다. 그것은 단지 대량 생산 결정입니다. 가장 기본적인 수준의 컴퓨팅 알고리즘에서 우리가 가지고 노는 것은 1과 0이며, 속도 인수는 게임에 적용되는 가장 멍청한 인수 중 하나입니다. 속도 향상을 원치 않으면 프로그래밍 언어를 완전히 삭제하고 어셈블리와 함께 사용하면 가장 좋은 이점이 될 수 있습니다.