C와 C는 정말 그렇게 빠른가요?

그동안 프로그래밍을 하다가 C와 C가 속도의 기준이라는 말을 들었습니다. 가장 빠른 것 중 가장 빠른 것, 어셈블리 코드로 직접 컴파일된 것, 그 어떤 것도 C나 C와 속도 면에서 경쟁할 수 없습니다. 그리고 누구도 그 공통된 믿음에 도전하지 않는 것 같습니다.

컴퓨팅 성능

물론 숫자를 사용한 산술 연산은 다른 언어보다 C에서 훨씬 빠르게 작동해야 합니다. 그런데 그럴까요?
얼마 전 저는 속도 차이가 실제로 얼마나 큰지 확인하기 위해 다양한 언어에 대한 간단한 벤치마크 세트를 작성하기로 결정했습니다.
아이디어는 간단했습니다. 간단한 계산을 사용하여 0부터 시작하여 10억 개의 정수의 합을 구하는 것입니다. 일부 컴파일러(예: rustc)는 이러한 간단한 순환을 수식 표현식으로 대체합니다. 물론 이는 상수 시간에 평가됩니다. 그러한 컴파일러를 사용하면 이를 방지할 수 있습니다. 비트별 또는과 같은 숫자를 사용한 비용 연산에서도 이와 유사한 방식을 사용했습니다.
결과를 받고 나서 정말 놀랐습니다. 내 세계관은 뒤집어졌고, 프로그래밍 언어의 속도에 대해 내가 알고 있던 모든 것을 재고해야 했습니다.
아래 표에서 내 결과를 볼 수 있습니다.

Linux 64비트, 1.1GHz ​​CPU, 4GB RAM

언어 컴파일러/버전/인수 시간 Rust(

Language	compiler/version/args	time
Rust (bitwise or instead of )	rustc 1.75.0 with -O3	167 ms
C	gcc 11.4.0 with -O3	335 ms
NASM	2.15.05	339 ms
Go	1.18.1	340 ms
Java	17.0.13	345 ms
Common Lisp	SBCL 2.1.11	1 sec
Python 3	pypy 3.8.13	1.6 sec
Clojure	1.10.2	9 sec
Python 3	cpython 3.10.12	26 sec
Ruby	3.0.2p107	38 sec

대신 비트 또는) -O3이 포함된 Rustc 1.75.0 167ms 씨 -O3을 사용한 gcc 11.4.0 335ms 나스엠 2.15.05 339ms 가기 1.18.1 340ms 자바 17.0.13 345ms 커먼 리스프 SBCL 2.1.11 1초 파이썬 3 pypy 3.8.13 1.6초 클로저 1.10.2 9초 파이썬 3 cpython 3.10.12 26초 루비 3.0.2p107 38초

여기에서 모든 테스트 소스를 찾을 수 있습니다.
https://github.com/Taqmuraz/speed-table

그래서 보시다시피 C는 Java보다 그리 빠르지 않습니다. 차이는 약 3%입니다. 또한 우리는 다른 컴파일된 언어가 산술 연산 성능에서 C와 매우 유사하다는 것을 알 수 있습니다(Rust가 훨씬 더 빠릅니다). JIT 컴파일러로 컴파일된 동적 언어는 더 나쁜 결과를 보여줍니다. 주로 산술 연산이 동적으로 전달되는 함수로 래핑되기 때문입니다.
해석된 동적 언어는 JIT 컴파일러 없이 최악의 성능을 보여줍니다.

메모리 할당 성능

그 참패 이후 C 팬들은 GC를 묻지 않고 시스템에서 직접 할당하기 때문에 C의 메모리 할당이 훨씬 더 빠르다고 말할 것입니다.
이제부터는 상황에 따라 GC 용어를 가비지 수집기와 관리되는 힙으로 모두 사용하겠습니다.
그렇다면 사람들은 왜 GC가 그렇게 느리다고 생각할까요? 실제로 GC에는 미리 할당된 메모리가 있고 할당은 단순히 포인터를 오른쪽으로 이동하는 것입니다. 대부분 GC는 C의 memset과 유사하게 시스템 호출을 사용하여 할당된 메모리를 0으로 채우므로 일정한 시간이 걸립니다. C의 메모리 할당은 시스템과 이미 할당된 메모리에 따라 다르기 때문에 정의되지 않은 시간이 걸립니다.
그러나 이러한 지식을 고려하더라도 Java에서는 다음 표에서 볼 수 있듯이 그렇게 좋은 결과를 기대할 수 없습니다.

일>

1.1 GHz 2 cores, 4 GB RAM

Running tests on single thread.

Result format : "Xms-Yms ~Z ms" means tests took from X to Y milliseconds, and Z milliseconds in average

1.1GHz ​​2코어, 4GB RAM 단일 스레드에서 테스트를 실행합니다. 결과 형식: "Xms-Yms ~Z ms"는 테스트에 X에서 Y 밀리초, 평균 Z 밀리초가 소요되었음을 의미합니다.

정수 배열 할당

integers array size	times	Java 17.0.13 new[]	C gcc 11.4.0 malloc	Common Lisp SBCL 2.1.11 make-array
16	10000	0-1ms, ~0.9ms	1-2ms, ~1.2ms	0-4ms, ~0.73ms
32	10000	1-3ms, ~1.7ms	1-3ms, ~1.7ms	0-8ms, ~2.ms
1024	10000	6-26ms, ~12ms	21-46ms, ~26ms	12-40ms, ~7ms
2048	10000	9-53ms, ~22ms	24-52ms, ~28ms	12-40ms, ~19ms
16	100000	0-9ms, ~2ms	6-23ms, ~9ms	4-24ms, ~7ms
32	100000	0-14ms, ~3ms	10-15ms, ~11ms	3-8ms, ~7ms
1024	100000	0-113ms, ~16ms	234-1156ms, ~654ms	147-183ms, ~155ms
2048	100000	0-223ms, ~26ms	216-1376ms, ~568ms	299-339ms, ~307ms

하나의 정수 필드를 사용하여 Person 클래스의 인스턴스를 할당합니다.

how many instances	Java 17.0.3 new Person(n)	C g 11.4.0 new Person(n)
100000	0-6ms, ~1.3ms	4-8ms, ~5ms
1 million	0-11ms, ~2ms	43-69ms, ~47ms
1 billion	22-50ms, ~28ms	process terminated

여기에서 모든 테스트 소스를 찾을 수 있습니다.
https://github.com/Taqmuraz/alloc-table

저는 C, C, Java, Lisp 등 총 4가지 언어를 테스트했습니다. 그리고 GC가 있는 언어는 항상 더 나은 결과를 보여주지만 C와 C보다 훨씬 더 엄격하게 테스트했습니다. 예를 들어 Java에서는 가상 함수 호출을 통해 메모리를 할당하므로 정적으로 최적화되지 않을 수 있으며 Lisp에서는 할당된 배열의 첫 번째 요소를 확인하므로 컴파일러는 할당 호출을 건너뛰지 않습니다.

메모리 해제

C 팬들은 여전히 ​​자신의 신념을 지키려는 의욕이 있기 때문에 "그래, 메모리를 더 빨리 할당하지만 나중에 풀어야 해!"라고 말합니다.
진실. 그리고 갑자기 GC가 C보다 더 빨리 메모리를 해제합니다. 그런데 어떻게요? GC에서 100만 개의 할당을 했는데 나중에 프로그램에서 참조되는 객체가 1000개밖에 없다고 상상해 보세요. 그리고 이러한 개체는 긴 메모리 전체에 분산되어 있다고 가정해 보겠습니다. GC는 스택 추적을 수행하여 1000개의 "살아 있는" 개체를 찾아 이전 세대 힙 피크로 이동하고 마지막 개체 뒤에 힙 피크 포인터를 배치합니다. 그게 다입니다.
그래서 객체를 몇 개 할당하든 GC의 작업 시간은 이후에 얼마나 보관하느냐에 따라 결정됩니다.
그리고 그와 반대로 C에서는 할당된 메모리를 모두 수동으로 해제해야 하므로 메모리를 100만 번 할당했다면 해제 호출도 100만 번을 해야 합니다(그렇지 않으면 메모리 누수가 발생하게 됩니다). 즉, GC의 O(1)-O(n)과 C의 O(n) 또는 더 나쁜을 비교합니다. 여기서 n 이전에 할당된 횟수입니다.

요약

그래서 저는 C와 C에 대한 가비지 수집 언어의 승리를 공고히 하고 싶습니다. 요약표는 다음과 같습니다.

요구 GC가 있는 언어 C/C 산술

demands	languages with GC	C/C
arithmetic	fast with JIT	fast
allocating memory	fast O(1)	slow
releasing memory	fast O(1) best case, O(n) worst case	O(n) or slower
memory safe	yes	no

JIT로 빠르게 빠르게 메모리 할당 빠르게 O(1) 천천히 메모리 해제 빠른 O(1) 최상의 경우, O(n) 최악의 경우 O(n) 이하 메모리 안전 그렇습니다 아니요

이제 알 수 있듯이 가비지 수집은 필요악이 아니라 우리가 원할 수 있는 최고의 것입니다. 이는 안전과성능모두을 제공합니다.

C에 대한 찬사

C는 내 테스트에서 더 나쁜 결과를 보였지만 여전히 중요한 언어이며 고유한 응용 분야가 있습니다. 내 글은 C 거부나 말살을 목표로 하지 않습니다. C는 나쁘지 않습니다. 사람들이 생각하는 것만큼 우수하지도 않습니다. 많은 좋은 프로젝트는 일부 사람들이 Java 대신 C를 사용하기로 결정했기 때문에 무너졌습니다. 예를 들어 C는 훨씬 빠르고 Java는 가비지 수집으로 인해 엄청나게 느리다는 말을 들었기 때문입니다. 아주 작고 간단한 프로그램을 작성할 때는 C가 좋습니다. 하지만 C로 복잡한 프로그램이나 게임을 작성하는 것은 결코 권장하지 않습니다.

C는 다르다

C는 단순하지 않고, 유연하지 않으며, 구문이 과부하되고 사양이 너무 복잡합니다. C로 프로그래밍하면 자신의 아이디어를 구현하지 않고 90%의 시간 동안 컴파일러 및 메모리 오류와 싸울 것입니다.
이 기사는 C를 거부하는 것을 목표합니다. 왜냐하면 속도와 성능은 사람들이 소프트웨어 개발에서 이 언어를 사용하는 데 대한 변명일 뿐이기 때문입니다. C를 사용하면 시간, 프로그램 성과 및 정신 건강에 대한 비용을 지불하게 됩니다. 그러니 C와 다른 언어 중 하나를 선택해야 한다면 마지막 언어를 선택하시기 바랍니다.

위 내용은 C와 C는 정말 그렇게 빠른가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!