수동 메모리 관리보다 가비지 수집 시연

가비지 수집 이 (이론적으로) 수동 메모리 관리보다 빠를 수 있는 많은 곳에서 읽었습니다 (허리, 심지어 직접 작성했습니다 ).

그러나, 보여주는 것보다 말하는 것이 쉽지 않습니다.
실제로이 효과가 실제로 나타나는 코드는 본 적이 없습니다.

이 성능 이점을 보여주는 코드를 가진 사람이 있습니까?

http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx를 참조 하고 모든 링크를 따라 Rico Mariani와 Raymond Chen (Microsoft의 유능한 프로그래머 모두)의 결의를 확인하십시오. . Raymond는 관리되지 않는 것을 개선하고 Rico는 관리되는 것과 동일한 것을 최적화하여 대응합니다.

본질적으로 최적화 노력이 필요하지 않기 때문에 관리되는 버전은 수동보다 몇 배나 빨리 시작되었습니다. 결국 매뉴얼은 관리 대상을 능가하지만 대부분의 프로그래머가 가고 싶지 않은 수준으로 최적화해야합니다. 모든 버전에서 매뉴얼의 메모리 사용량은 관리되는 것보다 훨씬 낫습니다.

경험상 무료 점심이 없다는 것입니다.

GC는 수동 메모리 관리의 어려움을 없애고 실수 할 가능성을 줄입니다. 특정 GC 전략이 문제에 대한 최적의 솔루션 인 상황이 있으며,이 경우 해당 전략을 사용하면 벌금이 부과되지 않습니다. 그러나 다른 솔루션이 더 빠른 다른 곳도 있습니다. 항상 낮은 수준에서 더 높은 추상화를 시뮬레이션 할 수 있지만 다른 방법으로는 불가능합니다. 일반적으로 높은 추상화가 낮은 것보다 빠를 수있는 방법이 없다는 것을 효과적으로 증명할 수 있습니다.

GC 는 수동 메모리 관리의 특별한 경우입니다

수동으로 더 나은 성능을 얻으려면 많은 작업이나 오류가 발생하기 쉽지만 다른 이야기입니다.

GC가 수동 방법보다 훨씬 효율적으로 인위적인 상황을 구성하는 것은 쉽습니다. 가비지 수집기에는 하나의 "루트"만 있고 모든 것이 가비지이므로 GC 단계가 즉시 완료됩니다.

당신이 그것에 대해 생각하면, 그것은 프로세스에 할당 된 메모리를 가비지 수집 할 때 사용되는 모델입니다. 프로세스는 죽고, 모든 메모리는 가비지입니다. 실질적인 관점에서도 추적을 남기지 않고 시작, 실행 및 죽는 프로세스는 영원히 시작하고 실행하는 프로세스보다 더 효율적일 수 있습니다.

가비지 수집을 사용하여 언어로 작성된 실제 프로그램의 경우 가비지 수집의 이점은 속도가 아니라 정확성과 단순성입니다.

GC는 단순한 메모리 관리 전략이 아니라는 점을 고려해야합니다. 또한 언어 및 런타임 환경의 전체 디자인을 요구하여 비용 (및 이점)을 부과합니다. 예를 들어 GC를 지원하는 언어는 가비지 수집기에서 포인터를 숨길 수없고 일반적으로 신중하게 관리되는 시스템 기본 형식을 제외하고는 구성 할 수없는 형식으로 컴파일해야합니다. 또 다른 고려 사항은 GC가 완료까지 실행되어야하는 일부 단계를 부과하므로 응답 시간 보장을 유지하기가 어렵다는 것입니다.

결과적으로 가비지 수집 된 언어가 있고 동일한 시스템에서 수동으로 관리되는 메모리와 속도를 비교하는 경우 가비지 수집을 사용하지 않더라도 오버 헤드를 지불해야합니다.

빠를수록 모호합니다. 그러나 하드웨어가 지원되는 경우 초고속, 인식 할 수 없거나 더 빠를 수 있습니다. 오래 전에 LISP 기계에 대한 설계가있었습니다. 한 사람은 GC를 하드웨어의 메모리 하위 시스템에 내장하여 주 CPU가 그 CPU를 알지 못했습니다. 많은 다른 디자인과 마찬가지로 GC는 일시 중지가 거의 필요없이 메인 프로세서와 동시에 실행되었습니다. 보다 현대적인 디자인은 Azul Systems Vega 3 머신으로, JVM은 전용 프로세서와 일시 정지없는 GC를 사용하여 JVM보다 훨씬 빠르게 Java 코드를 실행합니다. GC (또는 Java)가 얼마나 빠른지 알고 싶다면 Google에 문의하십시오.

나는 이것에 대해 꽤 많은 작업을 수행했으며 여기 에 그 중 일부를 설명했습니다 . 나는 C ++에서 Boehm GC를 벤치마킹하여 목록 기반의 n- 퀸 솔버를 실행하는 OCaml의 주식 GC와 C ++로 작성된 사용자 지정 표시 영역 GC를 사용 malloc하지만 해제하지는 않지만 할당 및 해제를 사용하여 할당했습니다 free. OCaml의 GC는 모든 경우에 더 빠릅니다. C ++ 및 OCaml 프로그램은 의도적으로 동일한 할당을 동일한 순서로 수행하도록 작성되었습니다.

물론 64 비트 정수만 사용하고 할당은 사용하지 않고 문제를 해결하기 위해 프로그램을 다시 작성할 수 있습니다. 더 빠르기는하지만 연습의 요점을 잃을 것입니다 (새로운 GC 알고리즘의 성능을 예측하는 것이 C ++에 내장 된 프로토 타입을 사용하여 작업했습니다).

나는 실제 C ++ 코드를 관리되는 언어로 포팅하는 업계에서 수년을 보냈다. 거의 모든 단일 사례에서 나는 상당한 성능 향상을 관찰했으며, 그 중 많은 부분이 GC보다 수동 메모리 관리 때문일 것입니다. 실질적인 한계는 마이크로 벤치 마크에서 달성 할 수있는 것이 아니라 마감일 및 GC 기반 언어가 내가 결코 되돌아 보지 않은 생산성 향상을 제공하기 전에 달성 할 수있는 것입니다. 임베디드 장치 (마이크로 컨트롤러)에서 여전히 C 및 C ++을 사용하지만 지금도 바뀌고 있습니다.

이러한 예에는 반드시 수동 메모리 할당 체계가 잘못되어 있습니다.

최고의 가비지 수집기를 가정하십시오 GC. 내부적으로 메모리를 할당하고 해제 할 수있는 메모리를 결정하는 방법과 최종적으로 해제 할 수있는 방법이 있습니다. 이들 모두는 모두보다 시간이 덜 걸립니다 GC. 시간이 다른 방법에 사용 GC됩니다.

이제 동일한 할당과 같은기구를 사용하는 수동 할당을 고려 GC하고, free()통화 바로 옆 메모리를 설정하는 방법과 동일한 방법에 의해 해제되는이 GC. 스캔 단계가 없으며 다른 방법도 없습니다. 시간이 덜 걸립니다.