Java 런타임 퍼포먼스와 네이티브 C/C++ 코드 비교

Java 런타임 퍼포먼스와 네이티브 C/C++ 코드 비교

C++나 C보다 자바에서 프로그래밍하는 것이 더 편해졌습니다.기본적으로 동일한 "프로젝트"를 실행하는 것이 아니라 JVM 인터프리터를 사용하여 발생하는 성능 저하를 파악하고 싶습니다.여기에는 어느 정도의 주관성이 있다는 것을 알고 있습니다.프로그램의 질은 좋은 구현에 크게 좌우됩니다.일반적인 의미에서 다음과 같은 점에 관심이 있습니다.

• 인터프리터를 사용할 때는 오버헤드에 대한 기준선이 있어야 합니다.기억해야 할 일반적인 경험칙이 있나요?10% 15%?(이러한 숫자들을 불쑥 꺼냈다) Java 코드가 네이티브 코드와 거의 같은 속도라는 블로그를 가끔 읽었는데, 그것이 편향된 것일 수도 있다고 생각합니다.

• JVM 가비지 컬렉터가 런타임 성능에 상당한 오버헤드를 추가합니까?코코아 앱이 쓰레기 수거 모델을 사용하기 시작했다는 것을 알고 있으며, 저는 코코아 앱이 프로그래밍을 훨씬 더 단순하게 만든다는 것에 동의합니다. 하지만 비용이 얼마나 들까요?

• Java에서 시스템 콜을 발신하는 데 드는 오버헤드는 얼마입니까?예를 들어 C 소켓 API가 아닌 Socket 객체를 만듭니다.

• 마지막으로 JVM 구현은 싱글 스레드라고 읽은 적이 있습니다.이것이 사실이라면(의심스럽지만), Java 스레드는 정말 진정한 스레드가 아님을 의미합니까?자바 스레드는 일반적으로 커널 제공 스레드에 대응합니까?Java 어플리케이션은 네이티브 어플리케이션과 마찬가지로 여러 코어/여러 CPU에서 이점을 얻을 수 있습니까?

JVM과 Java 프로그램 성능의 복잡성을 이해하는 개발자의 조언은 매우 감사할 것입니다.고마워요.

자바는 통역된 언어가 아니며, 여러 버전에도 해당되지 않았습니다.자바 바이트코드는 JIT에 의해 즉시 처리됩니다.(기술적으로는 일부 코드를 해석하지만 퍼포먼스에 문제가 있는 것은 J를 얻습니다.IT부문)

퍼포먼스에 관해서는, 도대체 무엇이 「오버헤드의 베이스라인이 있다」라고 하는 엉뚱한 생각을 하게 하는 것일까요.없어요.과거에도 없었고 앞으로도 없을 것이다.C++와 Java, Python과 Javascript 사이 또는 다른 두 언어 사이에서는 사용할 수 없습니다.특정 버전의 JVM이 특정 C++ 컴파일러보다 고속으로 처리되는 것, 특정 C++ 컴파일러가 특정 JVM보다 더 잘 처리되는 것이 있습니다.

따라서 언어 선택의 "오버헤드"는 1)코드의 실행 방법 및 2)코드의 작성 방법에 전적으로 의존합니다.

Java 프로그램을 C++로 변환하면 결과가 느려지는 것은 거의 확실합니다.

C++ 프로그램을 Java로 변환하면 동작도 느려집니다.

한 언어가 다른 언어보다 더 빠르기 때문이 아니라 원래 프로그램이 한 언어용으로 작성되어 해당 언어로 잘 작동하도록 조정되었기 때문입니다.그리고 그것을 다른 언어로 번역하려고 하면 이 장점이 없어집니다.결국 JVM에서 효율적으로 실행되지 않는 C++ 스타일의 Java 프로그램이나 마찬가지로 끔찍하게 실행되는 Java 스타일의 C++ 프로그램을 얻게 됩니다.

두 언어 사양 모두 "그리고 결과는 언어 y보다 x% 이상 느릴 것"이라는 절을 포함하지 않습니다.C++ 컴파일러와 JVM은 모두 작업을 신속하게 진행하기 위해 최선을 다하고 있습니다.

그리고 현재 보고 있는 성능 특성은 내일 바뀔 수 있습니다.언어에는 속도가 없습니다.

그러나 구체적인 질문에 답하려면:

인터프리터를 사용할 때는 오버헤드에 대한 기준선이 있어야 합니다.기억해야 할 일반적인 경험칙이 있나요?10% 15%?자바 코드가 네이티브 코드와 거의 비슷하다는 블로그를 가끔 읽었지만, 편향된 것 같습니다.

위와 같이 상황에 따라 다릅니다.일반적인 태스크의 대부분은 어느 쪽이든 몇 % 이상 차이가 나지 않습니다.일부 사용 사례에서는 (어느 쪽으로든) 더 큰 차이를 볼 수 있습니다.퍼포먼스에 관해서는 두 언어 모두 장점이 있습니다.JVM과 관련된 오버헤드가 일부 있지만 최적화 기회가 매우 크고 가비지 컬렉터도 마찬가지입니다.)

JVM 가비지 컬렉터가 런타임 성능에 상당한 오버헤드를 추가합니까?코코아 앱이 쓰레기 수거 모델을 사용하기 시작했다는 것을 알고 있으며, 저는 코코아 앱이 프로그래밍을 훨씬 더 단순하게 만든다는 것에 동의합니다. 하지만 비용이 얼마나 들까요?

기본적으로는 없습니다.평균적으로 가비지 컬렉터는 여러 가지 이유로 수동 메모리 관리보다 훨씬 빠릅니다.

• 관리 힙에서는 동적 할당을 훨씬 빠르게 수행할 수 있습니다.
• 공유 소유권은 무시할 수 있는 상각 비용으로 처리할 수 있습니다.원어민 언어에서는 참조 카운트를 사용해야 합니다.이것은 매우 고가입니다.
• 경우에 따라서는 오브젝트 파괴도 대폭 간소화됩니다(대부분의 Java 오브젝트는 GC가 메모리 블록을 조작하는 것만으로 재확보할 수 있습니다.C++에서는 디스트럭터를 항상 실행해야 하며 거의 모든 오브젝트에 디스트럭터가1개씩 있습니다.

GC의 주요 문제는 가비지 컬렉터가 평균적으로 더 나은 성능을 발휘하지만 성능 비용을 부담하는 시기를 제어할 수 없다는 것입니다.수동 메모리 관리를 통해 메모리가 청소되기를 기다리는 동안 스레드가 중단되는 일이 없습니다.가비지 컬렉터는 거의 언제든지 프로세스를 일시 중지하고 메모리를 청소할 수 있습니다.대부분의 경우, 이 속도는 문제가 없을 정도로 빠르지만, 중요한 실시간 정보에는 문제가 있습니다.

(또 다른 문제는 표현력이 떨어진다는 것입니다.C++에서는 RAII는 모든 종류의 자원을 관리하기 위해 사용됩니다.Java에서는 RAII를 사용할 수 없습니다.대신 GC는 메모리를 처리하며 다른 모든 리소스는 망하고 많은 시도/최종 블록을 직접 수행해야 합니다.RAII를 GC 언어로 구현하지 못할 이유는 없지만 Java 또는 C#에서는 사용할 수 없습니다.)

Java에서 시스템 콜을 발신하는 데 드는 오버헤드는 얼마입니까?예를 들어 C 소켓 API가 아닌 Socket 객체를 만듭니다.

비슷비슷하다.왜 다를까요?물론 Java는 관련 OS 서비스와 API를 호출해야 하기 때문에 약간의 오버헤드가 발생하지만, 실제로는 전혀 눈에 띄지 않습니다.

마지막으로 JVM 구현은 싱글 스레드라고 읽은 적이 있습니다.이것이 사실이라면(의심스럽지만), Java 스레드는 정말 진정한 스레드가 아님을 의미합니까?자바 스레드는 일반적으로 커널 제공 스레드에 대응합니까?Java 어플리케이션은 네이티브 어플리케이션과 마찬가지로 여러 코어/여러 CPU에서 이점을 얻을 수 있습니까?

Java는 여러 스레드를 사용할 수 있습니다.JVM 자체는 싱글 스레드일 수 있습니다(모든 JVM 서비스가 같은 스레드에서 실행된다는 의미에서는).그건 잘 모르겠어요.그러나 Java 어플리케이션에서는 원하는 수만큼 스레드를 사용할 수 있으며, 스레드는 OS 스레드에 매핑되어 여러 코어를 사용합니다.

당신의 목표는 매우 겸손하기 때문에, 「퍼포먼스 히트를 느끼고 싶다.「컴퓨터 언어 벤치마크 게임」에 표시되는 프로그램과 측정치를 조사하면, 그 대부분을 실현할 수 있을 것입니다.

Java와 C++ 모두 알고 있듯이

• 당신은 프로그램 소스 코드를 보고 어떤 자바 프로그램이 C와 C++ 프로그램 중 어느 것과 비교하기에 합리적인지 스스로 결정할 수 있다.

• 당신은 12개의 다른 작업을 보고 그들 중 어떤 것이 "각 언어의 가장 기본적인 특징"에 대한 당신의 생각을 실천하는지를 스스로 결정할 수 있다.

• 멀티코어에 대한 다양한 접근법 또는 하나의 코어에 강제된 프로그램을 볼 수 있습니다.

• JVM 부팅이 이러한 측정에 얼마나 영향을 미치는지 확인할 수 있습니다.

그러나 작은 프로그램의 측정이 애플리케이션의 성능을 제대로 나타낼 수 있는지 생각해 보아야 합니다.

java와 c#(및 objective-c) 모두 네이티브 코드만큼 빠르지 않습니다.그러나 이는 엔지니어링 시간이 제한되지 않는 문제가 있는 경우에만 문제가 됩니다.왜냐하면 당신은 고도의 언어로 더 나은 알고리즘을 고안할 시간이 있기 때문입니다.

따라서 기본적으로 연간 100만 개의 기기를 개발하거나 배터리로 구동하는 경우 핵심 기능을 구축하기 위해 Java 또는 c#을 사용하지 않습니다.단, 커스터마이즈를 용이하게 하기 위해 lisp 인터프리터를 추가할 수도 있습니다.Microsoft 에서는 퍼포먼스가 중요한 SQL Server의 핵심에 c#을 사용하지 않습니다.한편 MS가 하이엔드 하드웨어를 탑재할 수 있는 비주얼스튜디오는 느리지만 생산성이 높은 테크놀로지의 쇼케이스로 활용될 수 있다.

참고로 저는 현재 대부분의 프로그래밍을 pharo Smalltalk에서 하고 있습니다.이것은 java, c#, objective-c보다 훨씬 느리고, Smalltalk 중 가장 빠른 것도 아닙니다.생산성이 퍼포먼스를 능가합니다.

주의할 점은

자바 바이트 코드 JIT가 특정 하드웨어에 대해 훨씬 최적화된 코드로 컴파일됨

대

C코드는 특정 하드웨어에서 제공하는 기능을 이용할 수 없도록 일반 하드웨어에 컴파일 및 최적화되어 있습니다.

많은 사람들이 자바의 성능을 과소평가한다.저도 한때 이것에 대해 궁금해서 Java로 간단한 프로그램을 작성했고, 그 후 c로 동등한 프로그램을 작성했습니다(for loop과 대규모 어레이로 작업을 수행하는 것과 다름없습니다).정확한 수치는 기억나지 않지만, c 프로그램이 최적화 플래그(gcc 아래)로 컴파일되지 않았을 때 java가 c를 누른 것은 알고 있습니다.결국 적극적인 최적화로 컴파일 했을 때 예상대로 c가 앞섰습니다.솔직히 말하자면, 그건 과학 실험은 아니었지만, 자바가 어디에 서 있는지 알 수 있는 기준선을 제시해 주었어요.

물론 시스템 호출이 필요한 작업을 시작할 때 Java는 더 뒤처질 수 있습니다.다만, 디스크나 네트워크를 사용하는 경우, 100 MB/s의 읽기 퍼포먼스를 볼 수 있었습니다.그게 정확히 무슨 뜻인지 모르겠지만, 내가 필요로 하는 거의 모든 것에 충분하다는 것을 의미해요.

스레드에 대해서는 Java 프로그램이 2개의 스레드를 작성하면 2개의 실제 스레드가 있습니다.

http://www.w3sys.com/pages.meta/benchmarks.html

http://www.freewebs.com/godaves/javabench_revisited/

http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance

http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/

http://www.irrlicht3d.org/pivot/entry.php?id=446

기타 등등.사실은, 그건 중요하지 않다.병목현상과 느린 소프트웨어는 언어가 아닌 개발자에 의해 발생합니다(최소한 오늘날).

각 포인트에 대처하려면:

• 코드 해석의 오버헤드는 10~15%(약 3배~5배 이상)보다 훨씬 높습니다.10~15%로 줄이려면 기계코드 컴파일 단계(JIT)를 사용해야 합니다.(JIT가 꺼진 상태에서 JVM을 실행해 보면 성능이 엄청나게 저하됩니다.)
• 쓰레기 수거가 성능에 영향을 미치긴 하지만, 저는 모두가 쓰레기 수거가 가치가 있다는 것에 동의한다고 말하고 싶습니다.바이트 코드 컴파일/해석 오버헤드를 감당할 수 있다면 gc 오버헤드도 감당할 수 있습니다.
• Socket programming is much easier in Java than in C/C++, if that's what you're asking. And performancewise, the socket I/O overhead dominates over the Java execution overhead.
• Most modern JVMs have true threads, i.e. each Java thread is executed by a kernel thread, allowing Java threads to utilize modern multi-core CPUs.

Actually, a VM can do a lot of optimizations at runtime, based on information that's only available at runtime, that a C/C++ compiler cannot do. So, in most circumstances, the JVM will be at least as fast as a native program.

Brian Goetz answers most, if not all of your questions in his talk Towards a universal VM.

There isn't an easy answer to this. Writing C style C++ is possible (even a good idea) but once you try to do inheritance in C, things get ugly. So ignore C and go with Java -vs- C++ since they are closer to one another.

To get a real sense of it you would need to write two relatively large applications in similar manner in both languages. If you do that then do you use the STL and the Java collection classes or do you write your own and port them between languages? If you use the native one then it depends on which implementation is faster where as if you use your own you are not testing the real speed of the application.

I'd say you would need to write the application as similar as possible but use the language specific libraries/idioms where it makes sense. C++ and Java code, while being similar, have different ways of doing things - something that is easy in Java may be terribly hard in C++ and vice versa.

A modern GC implementation doesn't add that much overhead, and you can switch to a GC in C++ to do the comparison if you like :-)

There are some things that the Java runtime can do that is not generally done in C++ compilers, such as the ability to inline virtual methods.

For system type things Java typically resorts to making calls into C so there is overhead there (though JNI is faster than it used to be).

Threading depends on the implementation. Sun used to use "green threads; for Solaris, but that is long gone. As far as I know most (all?) modern VMs use native Threads.

한마디로 Java -vs-C++의 오버헤드에 대한 적절한 지표는 존재하지 않으며, 실제로 존재하지 않는 마이크로 벤치마크일 가능성이 높습니다(불행히도).

오늘날 멀티스레드 및 분산 패턴은 네이티브 속도를 필요로 하지 않습니다.자바는 c++ 속도에 도달할 수 있으며 경우에 따라서는 더 빠를 수 있습니다.그러나 일반적으로 c++는 자바보다 약간 빠릅니다.이것은 로드 밸런서 뒤에 다른 서비스를 추가함으로써 무시할 수 있습니다.따라서 4개의 c++ 서비스가 5개의 Java 서비스를 수행할 수 있습니다.3개의 c++ 스레드가 4개의 자바 스레드를 같은 속도로 실행할 수 있습니다.또 다른 중요한 요소는 코드 자체입니다.좋은 자바 코드는 나쁜 c++ 코드보다 빠를 수 있습니다.java는 더 큰 커뮤니티와 더 강력한 지원, 그리고 더 안정적인 라이브러리 및 도구를 가지고 있습니다.따라서 서버 사이드 자바는 더 나은 선택이며 시간을 절약하고 더 안정적이고 성능 좋은 코드를 얻을 수 있습니다.

언급URL : https://stackoverflow.com/questions/1984856/java-runtime-performance-vs-native-c-c-code