다양한 프로그래밍 언어의 빠르기를 측정해 비교하려면 어떻게 해야 할까 - C# / C++ / Java / Go를 같은 조건으로 비교하는 실천 가이드

「C++는 빠르다고 한다」「Go는 실운용에서 가볍다」「Java는 장시간 돌리면 꽤 빠르다」「C#도 .NET의 JIT이 있어서 의외로 강하다」

이런 이야기는 자주 나옵니다. 다만, 여기서 가장 해서는 안 되는 것은 다른 사람이 다른 환경에서 측정한 숫자를 나열해 그대로 언어의 우열이라고 결정하는 것입니다.

C#과 Java는 JIT이나 warm-up의 영향을 받기 쉽고, C++와 Go는 통상 사전 컴파일이 완료되어 있습니다. GC의 유무나 특성도 다릅니다. 표준 라이브러리나 주변 라이브러리의 구현 차도 꽤 효과적입니다. 게다가 같은 머신에서도 전원 설정, 열, 백그라운드 처리, 입력 데이터의 편향으로 결과는 간단히 흔들립니다. 꽤 진흙투성이의 세계입니다.

이 글에서는 C# / C++ / Java / Go를 가능한 한 공평하게 비교하기 위한 측정 방법을 정리합니다. 결론만 먼저 말하면 「어느 언어가 최속인가」를 1개의 숫자로 결정하려고 하지 않는 것이 가장 중요합니다.

이 글은 어디까지나 비교 방법의 정리가 주제입니다. 환경 의존의 숫자를 그럴듯하게 나열해도 점괘 같아지므로, 여기서는 실측 랭킹은 쓰지 않습니다. 그 대신 어떻게 설계하면 비교에 가치가 나올지에 좁혀 정리합니다.

먼저 결론

먼저 결론만 말하면 C# / C++ / Java / Go의 속도 비교에서 정말로 효과적인 것은 다음 7가지입니다.

무엇의 빠르기를 비교하고 싶은지를 먼저 정한다 기동 시간인지 정상 상태의 throughput인지 p95 지연인지 메모리 효율인지에 따라 측정 방법이 바뀝니다.
1개의 벤치만으로 결론을 내지 않는다 CPU 계산, 메모리 할당, 병렬 처리, 기동 시간에서는 강한 언어나 런타임의 보이는 방식이 바뀝니다.
C#과 Java는 cold와 warm을 나눈다 초회 실행을 포함하는 비교와 warm-up 후의 정상 상태 비교를 섞으면 이야기가 비틀어집니다.
같은 알고리즘, 같은 입력, 같은 정확성 확인으로 측정한다 빠른 구현이 아니라 다른 문제를 풀고 있을 뿐, 은 벤치 흔한 일입니다.
언어 내의 microbenchmark와 언어 횡단의 end-to-end 벤치를 나눈다 각 언어의 전용 하네스는 편리하지만, 언어를 걸치는 비교는 외측의 공통 러너로 돌리는 편이 이치에 맞습니다.
평균뿐만 아니라 중앙값과 분포를 본다 1회만 GC나 백그라운드 처리가 끼는 것만으로 평균은 망가집니다.
숫자뿐만 아니라 조건을 남긴다 벤치 결과는 빠르기의 기록임과 동시에 실험 조건의 기록입니다. 조건이 쓰여 있지 않은 결과는 나중에 꽤 힘듭니다.

처음에 정해야 할 것

「빠르다」를 1개의 말로 해결하면 대개 사고납니다. 우선은 무엇을 빠르다고 부를지를 정합니다.

예를 들어 같은 프로그램이라도 보고 싶은 것은 꽤 다릅니다.

1. 기동 시간을 보고 싶은가

CLI 도구, 짧은 수명의 배치, 1회 기동해 즉시 끝나는 보조 도구라면 cold start나 process startup이 효과적입니다. 이 축에서는 JIT이나 클래스 로드의 초기화 비용을 포함할지 여부로 결과가 크게 바뀝니다.

2. 장시간 운전의 throughput을 보고 싶은가

서버, 상주 프로세스, 워커, 길게 동작하는 변환 처리라면 steady-state의 throughput이 중요합니다. 이 경우 초회만 느린 것 자체는 본질이 아니고, warm-up 후에 어디까지 안정되게 늘어나는가가 주제가 됩니다.

3. tail latency를 보고 싶은가

API, UI, 리얼타임 쪽 처리에서는 평균보다 p95 / p99 쪽이 중요한 경우가 있습니다. 평균이 빠르더라도 가끔 크게 멈춘다면 사용자 체험이나 SLA적으로는 힘듭니다.

4. 메모리 효율도 포함해 보고 싶은가

CPU 시간뿐만 아니라 최대 RSS, 할당량, GC 횟수, GC pause도 보지 않으면 실운용의 무거움은 잘못 읽습니다. 「빠르지만 메모리를 꽤 먹는다」와 「약간 느리지만 안정되게 가볍다」는 용도에 따라 평가가 역전합니다.

요컨대 처음에 정해야 할 질문은

이 비교에서 알고 싶은 것은 어느 언어가 빠른가가 아니라, 어느 workload를 어느 조건으로 어느 지표에서 빠르게 처리할 수 있는가

입니다.

여기를 애매하게 한 채 숫자를 모으면 마지막에 정리되지 않습니다.

왜 언어 비교는 어려운가

JIT과 AOT를 섞으면 다른 실험이 된다

C#과 Java는 통상 JIT의 영향을 받습니다. 한편, C++와 Go는 통상 사전 컴파일이 완료되어 있습니다.

즉, 초회 실행을 측정하면 프로그램 본체의 빠르기뿐만 아니라 런타임의 기동・클래스 로드・JIT 준비도 함께 측정하게 됩니다. 반대로, 충분히 warm-up한 후만 본다면 이번에는 정상 상태의 최적화가 어디까지 효과적인가의 비교가 됩니다.

둘 다 의미는 있습니다. 다만 같은 의미는 아닙니다.

언어 차보다 구현 차 쪽이 큰 경우가 평범하게 있다

같은 「소트」라도,

한쪽은 표준 라이브러리를 사용하고 있다
한쪽은 자체 구현
한쪽은 여분의 복사를 하고 있다
한쪽은 입력을 매번 재생성하고 있다

이것만으로 결과는 꽤 바뀝니다.

게다가 JSON, 압축, 암호, 정규 표현과 같은 처리가 되면 언어 자체보다 라이브러리 구현의 차가 꽤 효과적입니다. 그래서 무엇을 측정하고 있는지를 명시하지 않으면, 「언어 비교」인 줄 알았는데 「라이브러리 비교」가 됩니다.

C++는 최적화로 처리가 사라지는 함정이 있다

특히 microbenchmark에서는 컴파일러가 「이 계산 결과, 아무도 사용하지 않는구나」라고 판단하면 처리를 지워버리는 경우가 있습니다. 그러면 빠른 것이 아니라 원래 아무것도 하고 있지 않다는 약간의 괴담이 됩니다.

C++에서는 이 문제가 특히 노골적으로 나오기 쉬우므로, 결과의 사용이나 checksum의 출력, 또는 benchmark 프레임워크의 최적화 억제 기능이 꽤 중요합니다.

GC의 존재는 「불리」도 「유리」도 아닌 특성

C#, Java, Go에는 GC가 있습니다. 이것을 단순히 「GC가 있으니 느리다」로 하면 너무 거칩니다.

실제로는,

대량 단명 오브젝트를 어떻게 처리하는가
힙 사이즈 설정
GC의 빈도와 pause
오브젝트 레이아웃
라이브러리의 할당 버릇

쪽이 효과적입니다.

반대로 C++는 수동 관리나 RAII로 세세하게 제어할 수 있지만, 그만큼 설계나 구현의 차가 나오기 쉽습니다. 즉 관리 방식의 차이가 그대로 선악이나 우열이 아닙니다.

비교에서 해서는 안 되는 것

1. Debug와 Release를 섞는다

이것은 논외입니다. 비교 대상은 반드시 본번 상당의 최적화 빌드로 맞춥니다.

2. 같은 문제를 풀고 있지 않다

입력 형식이 다르다, 출력이 다르다, 에러 처리가 한쪽만 없다, 메모리 재이용의 방침이 다르다. 이 부근을 방치하면 빠르기가 아니라 요건 차를 측정해 버립니다.

3. 1회만 실행해 결론을 낸다

1회만의 실행은 대개 노이즈입니다.

JIT
페이지 캐시
CPU의 부스트
열
백그라운드 태스크
GC
초회의 파일 읽기

이 부근이 1회에 전부 섞입니다.

4. warm-up을 섞는다

C#과 Java를 측정할 때 초회를 포함할지 warm-up 후만 볼지를 애매하게 하면 의론이 무너집니다. cold와 warm은 별개로서 다룹니다.

5. 정확성 확인을 하지 않는다

벤치는 「빠르다」보다 먼저 「같은 결과를 반환한다」가 필요합니다. 비교 대상의 전 구현에서 같은 입력으로부터 같은 checksum이나 같은 출력이 얻어지는 것을 반드시 확인합니다.

6. 1개의 microbenchmark만으로 세계관을 결정한다

tight loop만으로 이기더라도 실서비스 전체에서 이긴다고는 한정되지 않습니다. 반대로 기동 시간에서 져도 장시간 운전에서는 충분히 강한 경우도 있습니다.

C# / C++ / Java / Go를 비교할 때의 기본 방침

여기는 꽤 중요합니다. 추천은 2층 구성입니다.

1. 언어 내의 측정은 그 언어에 맞는 하네스를 사용한다

각 언어에는 그 언어의 사정을 흡수해 주는 benchmark 도구가 있습니다.

C#: BenchmarkDotNet
Java: JMH
Go: go test -bench과 benchstat
C++: Google Benchmark

이들은 각각의 런타임 사정이나 통계 처리, 측정의 함정을 어느 정도 돌봐줍니다. 언어 내에서의 비교나 구현의 파헤치기에는 꽤 유효합니다.

2. 언어 횡단의 비교는 외측에 공통 러너를 둔다

한편, C#의 BenchmarkDotNet의 결과와 Java의 JMH의 결과를 그대로 옆에 나열하는 것은 조금 위험합니다. 하네스 자체의 작법이 다르기 때문입니다.

그래서 언어 횡단에서는 각 구현을 같은 CLI 계약으로 부를 수 있는 실행 파일로 하고, 외측에서 같은 조건으로 돌리는 것이 추천입니다.

예를 들어 각 언어에서 다음과 같은 형태의 실행 파일을 준비합니다.

bench --scenario sort_int32 --dataset data/sort_10m.bin --mode warm
bench --scenario group_words --dataset data/words_100mb.txt --mode cold
bench --scenario parallel_hash --dataset data/blob_1gb.bin --threads 8

그리고 공통 러너 측에서,

실행 순서를 랜덤화한다
cold / warm을 나눈다
같은 데이터셋을 넘긴다
checksum을 검증한다
wall-clock과 메모리를 채취한다
CSV / JSON에 raw data를 남긴다

라는 흐름으로 합니다.

이것을 하면 각 언어 속의 베스트 프랙티스와 언어 횡단의 공평성을 나누어 다루기 쉬워집니다.

구체 예: 어떤 벤치 항목을 준비해야 할까

「C# / C++ / Java / Go를 비교하고 싶다」라고 말했을 때, 1개만이라면 오해되기 어려운 단순한 CPU계를, 복수 개를 한다면 성격이 다른 workload를 3~4개 준비하는 것이 추천입니다.

JSON이나 HTTP 벤치는 어떻게 할까

JSON이나 HTTP는 실무에 가까우므로 물론 의미는 있습니다. 다만, 그 경우는 언어 비교가 아니라 라이브러리・프레임워크・에코시스템 포함의 비교가 됩니다.

그 자체는 나쁘지 않습니다. 오히려 실무에서는 그쪽이 중요한 경우도 많습니다. 다만, 기사나 리포트에서는

이것은 언어의 비교가 아니라 표준적인 구현과 주요 라이브러리 포함의 비교입니다

라고 명기하는 편이 오해가 적습니다.

언어별로 맞춰야 할 조건

C++

최적화 빌드로 맞춘다
컴파일러를 고정한다
표준 라이브러리 구현을 고정한다
-O3 / /O2, LTO, PGO 등의 조건을 명기한다
결과가 최적화로 사라지지 않도록 주의한다
미정의 동작으로 빨라 보이고 있지 않은지 의심한다

C++는 자유도가 높은 만큼 조건 차가 그대로 크게 나옵니다. 그래서 어느 컴파일러로, 어느 플래그로, 어느 STL로 측정했는지는 꽤 중요합니다.

C#

Release 빌드로 맞춘다
.NET의 버전을 고정한다
Server GC / Workstation GC 등의 조건을 기록한다
Tiered Compilation, ReadyToRun, Native AOT의 유무를 명기한다
cold와 warm을 나눈다

C#은 .NET의 설정 차가 보이는 방식을 바꿉니다. 특히 JIT의 C#과 Native AOT의 C#은 같은 「C#」이라도 다른 축입니다. 여기를 섞으면 비교 대상이 언어가 아니라 배포 형태가 됩니다.

Java

JDK의 벤더와 버전을 고정한다
GC를 명기한다
warm-up / measurement / fork를 고정한다
힙 사이즈나 JVM 옵션을 기록한다
cold start와 steady-state를 나눈다

Java는 JIT의 은혜를 받기 쉬운 반면, 초회의 보이는 방식은 꽤 바뀝니다. 그래서 단명 프로세스의 비교와 장시간 운전의 비교를 나누는 것이 필수입니다.

Go

Go의 버전을 고정한다
GOMAXPROCS를 고정한다
CGO_ENABLED를 명기한다
GOGC를 만진다면 반드시 기록한다
가능하면 benchmark 형식의 출력을 남긴다

Go는 비교적 다루기 쉽지만 병렬 벤치에서는 GOMAXPROCS의 영향이 큽니다. 또한 cgo를 사용할지 여부로 세계가 바뀌므로 거기는 반드시 조건에 남깁니다.

실행 환경의 맞추는 방법

어느 언어에서도 환경을 맞추지 않은 비교는 대개 환경을 비교하고 있습니다.

맞춰야 할 것

같은 CPU / 메모리 / 스토리지
같은 OS 버전
같은 전원 조건
같은 실온에 가까운 조건
같은 입력 데이터
같은 프로세스 우선도
같은 코어 수 조건
같은 컨테이너 or 베어메탈 조건

특히 효과적인 것

전원 설정과 CPU 주파수

노트 PC라면 AC 접속인지 배터리인지만으로도 별세계가 됩니다. CPU governor나 power mode가 맞춰져 있지 않으면 비교 결과가 꽤 흔들립니다.

Windows에서의 전원 조건, 알림, 백그라운드 노이즈, 열, 실행 순서의 맞추는 방법에 대해서는 별도 기사의 Windows에서 다른 버전의 프로그램의 실행 속도를 어떻게 비교할까 에서 자세히 정리하고 있습니다. Windows에서 측정한다면 여기는 꽤 효과적입니다.

열

처음의 몇 회만 빠르고 후반에서 떨어진다면 열이나 스로틀링을 의심합니다. A를 전부 돌리고 나서 B를 전부 돌리기보다 A / B / A / B처럼 교대로 돌리는 편이 편향을 줄일 수 있습니다.

백그라운드 처리

업데이트, 인덱스, 동기, 바이러스 스캔, 브라우저, 채팅 도구. 이 부근은 수수하지만 평범하게 끼어듭니다.

무엇을 측정해야 할까

언어 비교에서는 최저한 다음 4가지를 나누어 보는 것이 추천입니다.

1. wall-clock time

사용자가 기다리는 실시간입니다. 우선 처음에 봐야 할 지표는 이것입니다.

2. CPU time

「실제로 CPU를 얼마나 사용했는지」입니다. wall-clock만 빠르고 CPU time이 바뀌지 않는다면 대기 시간이나 I/O의 영향일지도 모릅니다.

3. memory / allocations

최대 RSS
총 할당량
alloc 횟수
GC 횟수
GC pause

이 부근을 보면 빠르기의 뒤에 있는 비용이 보입니다.

4. 분포

중앙값
p95 / p99
min / max
표준 편차나 편차

평균만으로 말하면 가끔 튀는 처리의 정체가 보이지 않습니다.

실행 순서의 추천

실운용하기 쉬운 흐름을 정리하면 대략 다음 순서입니다.

1. workload를 정한다

우선 무엇을 비교하고 싶은지를 명확히 합니다.

기동 시간
정상 throughput
tail latency
메모리 효율
병렬 스케일

2. 공통 데이터셋을 고정한다

입력 데이터는 고정 seed나 고정 파일로 맞춥니다. 데이터 생성까지 포함해 버린다면 그것도 각 언어에서 같은 조건으로 할 필요가 있습니다.

3. 정확성 확인을 먼저 통과시킨다

작은 데이터와 큰 데이터에서 전 구현이 같은 결과를 반환하는 것을 확인합니다. checksum이나 해시를 내게 하면 다루기 쉽습니다.

4. build 조건을 고정한다

각 언어에서 Release / 최적화 완료의 실행 형식을 만들고 버전과 플래그를 기록합니다.

5. cold와 warm을 나눈다

특히 C#과 Java는 여기가 중요합니다.

cold: 프로세스 기동 직후를 포함
warm: 수 회 실행 후의 안정 상태

이 2가지는 같은 표에 섞지 않는 편이 깔끔합니다.

6. 실행 순서를 교대 또는 랜덤화한다

예:

cpp -> csharp -> java -> go
go -> java -> cpp -> csharp
csharp -> go -> java -> cpp
...

이렇게 하면 열이나 노이즈의 편향이 줄어듭니다.

7. 횟수를 확보한다

가벼운 microbenchmark라면 꽤 많이, end-to-end라면 적어도 10회 이상은 원합니다. 차가 작은데 횟수가 적으면 해석이 꽤 위태로워집니다.

8. raw data를 보존한다

집계 결과뿐만 아니라 각 run의 생 데이터를 남깁니다. 나중에 보면 외부 값이나 warm-up의 버릇을 읽을 수 있습니다.

9. 차가 나면 profile을 취한다

차가 나왔을 때는 거기서 처음으로 원인을 파냅니다.

CPU profile
allocation profile
GC 로그
flame graph
OS 측의 트레이스

여기까지 가면 「빠르다 / 느리다」가 아니라 왜 그런가를 말할 수 있게 됩니다.

결과의 읽는 법

숫자가 나온 후도 읽는 방식을 틀리면 역시 위험합니다.

초회만 C# / Java가 느리다

JIT, 클래스 로드, 초기화의 영향을 의심합니다. 이 경우,

기동 시간이 중요하면 의미 있는 차
장시간 운전이 주제라면 별표에 나누어야 할 차

입니다.

C++가 tight loop에서 강하다

저레벨 최적화, 오브젝트 배치, 최소한의 런타임 오버헤드가 효과적일 가능성이 있습니다. 다만, 거기만을 보고 「그러니 실서비스에서도 최속」이라고 하는 것은 비약입니다.

Go가 기동 시간이나 배포하기 쉬움으로 유리해 보인다

단일 바이너리, 비교적 가벼운 시작, 다루기 쉬운 병렬 모델이 효과적일 수 있습니다. 다만, 모든 CPU계 workload에서 유리한 것은 아닙니다.

C# / Java가 steady-state에서 꽤 따라잡거나, 또는 역전한다

JIT의 최적화가 효과적일 가능성이 있습니다. 이것도 드문 이야기가 아닙니다. 그래서 기동 포함의 비교와 정상 상태의 비교를 섞지 않는 것이 중요합니다.

allocation-heavy한 처리에서 차가 크다

이 경우는 언어명보다

메모리 레이아웃
문자열이나 map의 취급
GC의 거동
여분의 복사

쪽이 효과적인 경우가 많습니다.

기록 템플릿

벤치 결과에는 최저한 다음 항목을 남겨 두면 나중에 도움이 됩니다.

timestamp,language,scenario,run_kind,cold_or_warm,elapsed_ms,cpu_ms,max_rss_mb,alloc_bytes,gc_count,checksum
compiler_or_runtime,compiler_version,flags,os,cpu,threads,input_id,notes

예를 들어 run_kind는 이런 느낌으로 나눌 수 있습니다.

micro
macro
startup
parallel

cold_or_warm은 적어도 다음 중 하나를 명시하고 싶습니다.

cold
warm

벤치는 측정하는 것보다 나중에 해석할 수 있는 것 쪽이 중요한 경우가 있습니다.

정리

C# / C++ / Java / Go의 속도 비교에서 정말로 중요한 것은 어느 언어가 최속인가라는 거친 질문을 어느 workload를 어느 조건으로 어느 지표로 비교할지 라는 실험의 형태로 떨어뜨리는 것입니다.

특히 빗나가기 어려운 포인트를 다시 한 번 정리하면 다음과 같습니다.

기동 시간과 정상 상태를 나눈다
같은 알고리즘, 같은 입력, 같은 정확성 확인으로 측정한다
1개의 벤치만으로 결론을 내지 않는다
언어 내의 benchmark와 언어 횡단의 benchmark를 나눈다
평균보다 중앙값과 분포를 본다
조건과 raw data를 남긴다

그리고 마지막으로 가장 중요한 것은 언어명으로 승패를 결정하려고 너무 하지 않는 것입니다. 현실의 성능은 언어, 런타임, 라이브러리, 빌드 조건, 데이터, OS, 하드웨어의 합작기로 결정됩니다.

「C++가 빠르다」「Java가 강하다」「Go가 가볍다」「C#도 충분히 빠르다」라는 이야기는 전부 어떤 의미에서는 옳습니다. 다만 어느 조건에서 그렇게 말하고 있는가가 빠지면 대개 안개 속에서 치고받는 이야기가 됩니다.

조건을 맞추고, 복수의 workload에서, cold / warm을 나누고, 분포까지 본다. 수수하지만 결국 이것이 가장 강합니다.

참고 자료

BenchmarkDotNet Getting Started https://benchmarkdotnet.org/articles/guides/getting-started.html
OpenJDK JMH Project https://openjdk.org/projects/code-tools/jmh/
JMH GitHub Repository / README https://github.com/openjdk/jmh
Go testing package https://pkg.go.dev/testing
Go benchstat https://pkg.go.dev/golang.org/x/perf/cmd/benchstat
Google Benchmark User Guide https://google.github.io/benchmark/user_guide.html
Windows에서 다른 버전의 프로그램의 실행 속도를 어떻게 비교할까 https://comcomponent.com/blog/2026/03/16/002-windows-benchmark-comparing-program-versions/

이 주제의 상담처

성능 비교의 설계, 계측 조건의 맞추는 방법, 결과의 해석, 원인의 파헤치기는 다음 서비스와 상성이 좋은 주제입니다.

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

Windows 앱 개발

상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.

서비스 보기 문의하기

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

프로필 보기 문의하기

공개 링크

GitHub LinkedIn X COM_BLAS COM_BigDecimal