1
Executive Summary
CPU
Intel Core i7-14700 (Raptor Lake Hybrid)
Core Topology
20 Physical (8P + 12E) / 28 Logical
Boost Clock
P-Core: 5.4 GHz / E-Core: 4.0 GHz
Cache
L1d 48KB, L2 2MB (per-core), L3 33MB (shared)
NUMA
1 Node (Single Socket)
RAM
65 GB
Compiler
MSVC 19.44, C++23, Release
Benchmark Library
Google Benchmark v1.9.4
비교 대상
v0.6.1.0 (baseline) / v0.6.5.0 Affinity OFF / v0.6.5.0 Affinity ON
Cross-Core Latency RTT
-37.0%
13,038 ns → 8,219 ns (v0.6.1 → v0.6.5 OFF)
Cross-Core Throughput
+67.2%
1.72M → 2.88M msg/s (v0.6.1 → v0.6.5 OFF)
Session Echo 64B
+109%
5.92 → 12.38 MB/s (v0.6.5 OFF → ON)
TimingWheel 1K
+103%
39.8M → 81.0M ops/s (v0.6.1 → v0.6.5)
핵심 요약: i7-14700의 20코어/28스레드 환경에서 v0.6.5.0은 v0.6.1.0 대비 크로스 코어 통신에서 극적 개선을 달성했다.
RTT 레이턴시 37% 감소, 메시지 전달 처리량 67% 증가. FlatBuffers 빌드는 2배 이상 향상. Affinity 바인딩은 Session Echo 처리에서 최대 109% 개선을 보여
P/E 코어 이종 환경에서 코어 고정의 중요성을 입증한다.
다만 PerCore 아키텍처 8코어 이상 구간에서 affinity가 오히려 처리량을 떨어뜨리는 현상이 관찰되어, Windows 스케줄러와의 상호작용에 대한 추가 분석이 필요하다.
2
Version Comparison (v0.6.1.0 → v0.6.5.0)
2-1. Micro Benchmark 변화율
| 벤치마크 | v0.6.1.0 | v0.6.5.0 | 변화율 |
|---|---|---|---|
| SlabAlloc 64B (ops/s) | 267M | 291M | +9.3% |
| SlabAlloc 1024B (ops/s) | 265M | 283M | +6.7% |
| Malloc 64B (ops/s) | 45.0M | 43.6M | -3.2% |
| Malloc 256B (ops/s) | 6.21M | 46.9M | +656% |
| BumpAlloc 64B/16K (ops/s) | 283M | 310M | +9.5% |
| SpscQueue 1K Throughput (ops/s) | 290M | 296M | +2.3% |
| SpscQueue Latency (ops/s) | 531M | 538M | +1.3% |
| SpscQueue Concurrent (ops/s) | 18.8M | 75.6M | +302% |
| MpscQueue 2P1C (ns) | 163.1 ns | 63.1 ns | -61.3% |
| Dispatcher Lookup/1000 (ops/s) | 427M | 407M | -4.6% |
| FlatMap Iterate/10K (ops/s) | 910M | 1,024M | +12.5% |
| StdMap Iterate/10K (ops/s) | 194M | 319M | +64.3% |
| RingBuffer Write/Read 4K (GB/s) | 195.1 | 186.4 | -4.4% |
| RingBuffer Linearize 4K (GB/s) | 119.0 | 134.4 | +12.9% |
| FrameCodec Encode 4K (GB/s) | 128.0 | 111.5 | -12.9% |
| FrameCodec Decode 16K (GB/s) | 63.5 | 52.2 | -17.9% |
| FlatBuffers Build 64B (GB/s) | 0.78 | 1.57 | +100% |
| FlatBuffers Build 4K (GB/s) | 32.6 | 59.9 | +83.7% |
| FlatBuffers Read 4K (TB/s) | 0.870 | 1.186 | +36.4% |
| TimingWheel 1K (ops/s) | 39.8M | 81.0M | +103% |
| TimingWheel ScheduleOnly (ops/s) | 18.4M | 38.4M | +109% |
| Session Create (ops/s) | 3,389 | 7,626 | +125% |
Micro 분석: v0.6.5.0은 대부분의 micro 벤치마크에서 개선을 보인다. 특히 주목할 만한 점:
• Malloc 256B: +656%라는 이상치 — v0.6.1.0에서 6.21M ops/s로 비정상적으로 낮았던 값이 정상화. MSVC 런타임의 힙 상태 차이로 추정
• SpscQueue Concurrent: +302% — repeats:5 평균 기반으로 안정화된 측정. v0.6.1.0의 단일 실행값 대비 정밀도 향상
• MpscQueue 2P1C: 163ns → 63ns (-61.3%) — repeats:5 평균 기반 측정으로 OS 스케줄링 노이즈 감소
• TimingWheel / Session Create: 2배 이상 향상은 MSVC 최적화 플래그 또는 코드 개선 효과
• FrameCodec: Encode/Decode 모두 퇴보 (-13~18%) — memcpy 경로 변경 가능성 조사 필요
• Malloc 256B: +656%라는 이상치 — v0.6.1.0에서 6.21M ops/s로 비정상적으로 낮았던 값이 정상화. MSVC 런타임의 힙 상태 차이로 추정
• SpscQueue Concurrent: +302% — repeats:5 평균 기반으로 안정화된 측정. v0.6.1.0의 단일 실행값 대비 정밀도 향상
• MpscQueue 2P1C: 163ns → 63ns (-61.3%) — repeats:5 평균 기반 측정으로 OS 스케줄링 노이즈 감소
• TimingWheel / Session Create: 2배 이상 향상은 MSVC 최적화 플래그 또는 코드 개선 효과
• FrameCodec: Encode/Decode 모두 퇴보 (-13~18%) — memcpy 경로 변경 가능성 조사 필요
2-2. Integration Benchmark 변화율
| 벤치마크 | v0.6.1.0 | v0.6.5.0 | 변화율 |
|---|---|---|---|
| CrossCore RTT (ns) | 13,038 | 8,219 | -37.0% |
| CrossCore OneWay (ns) | 6,519 | 4,110 | -37.0% |
| CrossCore Throughput (msg/s) | 1.72M | 2.88M | +67.2% |
| FramePipeline 64B (MB/s) | 27.5 | 53.1 | +93.2% |
| FramePipeline 512B (MB/s) | 196.4 | 347.8 | +77.1% |
| FramePipeline 4KB (GB/s) | 1.41 | 2.67 | +89.0% |
| Session Echo 64B (MB/s) | 5.92 | 11.84 | +100% |
| Session Echo 512B (MB/s) | 39.7 | 40.7 | +2.4% |
| Session Echo 4KB (MB/s) | 278.5 | 277.8 | -0.2% |
Integration 분석: 크로스 코어 통신이 전방위적으로 개선되었다.
• Cross-Core RTT 37% 감소: 코어간 메시지 전달 경로 최적화 효과 직접 반영
• FramePipeline 77~93% 향상: Encode+Decode+전송의 E2E 파이프라인이 크게 개선. micro에서 Codec이 퇴보했음에도 불구하고 파이프라인 전체에서는 개선 — 전송 경로 최적화가 Codec 퇴보를 상쇄하고도 남음
• Session Echo 64B +100%: 소형 메시지 처리에서 극적 개선. 512B/4KB는 이미 높은 수준이어서 변화 미미
• Cross-Core RTT 37% 감소: 코어간 메시지 전달 경로 최적화 효과 직접 반영
• FramePipeline 77~93% 향상: Encode+Decode+전송의 E2E 파이프라인이 크게 개선. micro에서 Codec이 퇴보했음에도 불구하고 파이프라인 전체에서는 개선 — 전송 경로 최적화가 Codec 퇴보를 상쇄하고도 남음
• Session Echo 64B +100%: 소형 메시지 처리에서 극적 개선. 512B/4KB는 이미 높은 수준이어서 변화 미미
3
Affinity Impact Analysis (v0.6.5.0 OFF vs ON)
3-1. Architecture Comparison: PerCore / Shared / LockFree
| Cores | PerCore OFF | PerCore ON | Delta | Shared OFF | Shared ON | Delta |
|---|---|---|---|---|---|---|
| 1 | 1.93M | 1.97M | +2.3% | 2.00M | 2.01M | +0.1% |
| 2 | 3.34M | 3.33M | -0.2% | 1.92M | 1.83M | -4.7% |
| 3 | 4.42M | 4.50M | +1.7% | 2.04M | 2.10M | +3.2% |
| 4 | 5.56M | 5.30M | -4.7% | 2.28M | 2.36M | +3.5% |
| 8 | 7.01M | 7.34M | +4.7% | 1.95M | 2.05M | +5.0% |
| 16 | 5.87M | 5.97M | +1.7% | 1.40M | 1.36M | -3.2% |
| Cores | LockFree OFF | LockFree ON | Delta |
|---|---|---|---|
| 1 | 1.99M | 2.09M | +5.4% |
| 2 | 1.92M | 1.77M | -7.8% |
| 3 | 2.20M | 2.14M | -2.4% |
| 4 | 2.38M | 2.34M | -1.9% |
| 8 | 1.86M | 2.07M | +11.3% |
| 16 | 1.31M | 1.43M | +9.2% |
Architecture Comparison 분석:
• PerCore: 8코어 구간에서 affinity가 +4.7% 효과. 이 구간은 P-Core 8개와 정확히 일치하여 affinity 바인딩이 모든 워커를 P-Core에 고정한 결과. 16코어에서도 +1.7%로 소폭 개선
• Shared / LockFree: 8코어 이상에서 affinity가 긍정적 — LockFree 8C에서 +11.3%. 코어 고정으로 캐시 라인 바운싱 감소 효과
• 2코어 구간 퇴보: Shared(-4.7%), LockFree(-7.8%) — 소수 코어에서는 OS 스케줄러의 유연한 마이그레이션이 오히려 유리할 수 있음
• 전반적으로 affinity 효과는 코어 수가 많아질수록 두드러지며, P/E 코어 혼합 환경의 특성을 반영
• PerCore: 8코어 구간에서 affinity가 +4.7% 효과. 이 구간은 P-Core 8개와 정확히 일치하여 affinity 바인딩이 모든 워커를 P-Core에 고정한 결과. 16코어에서도 +1.7%로 소폭 개선
• Shared / LockFree: 8코어 이상에서 affinity가 긍정적 — LockFree 8C에서 +11.3%. 코어 고정으로 캐시 라인 바운싱 감소 효과
• 2코어 구간 퇴보: Shared(-4.7%), LockFree(-7.8%) — 소수 코어에서는 OS 스케줄러의 유연한 마이그레이션이 오히려 유리할 수 있음
• 전반적으로 affinity 효과는 코어 수가 많아질수록 두드러지며, P/E 코어 혼합 환경의 특성을 반영
3-2. Cross-Core Latency & Message Passing
| 지표 | v0.6.5 OFF | v0.6.5 ON | Delta |
|---|---|---|---|
| CrossCore RTT (ns) | 8,219 | 8,234 | +0.2% |
| CrossCore OneWay (ns) | 4,110 | 4,117 | +0.2% |
| CrossCore Throughput (msg/s) | 2.88M | 2.82M | -2.1% |
Cross-Core Latency 분석: Affinity ON/OFF 차이가 거의 없다 (RTT +0.2%, Throughput -2.1%).
i7-14700은 단일 NUMA 노드이므로 affinity가 NUMA 경계를 넘지 않아 레이턴시 개선 여지가 적다.
i5-9300H에서 RTT -13.4% 개선이 있었던 것과 대조적 — i5는 4C/8T 소규모 환경이라 코어 고정이 캐시 히트율에 직접 영향을 줬을 가능성.
i7-14700에서는 L3 33MB가 충분히 크고 단일 NUMA이므로 affinity가 레이턴시보다 throughput 안정성에 더 기여.
3-3. Session Throughput & Frame Pipeline (OFF vs ON)
| 벤치마크 | OFF | ON | Delta |
|---|---|---|---|
| Session Echo 64B (MB/s) | 11.84 | 12.38 | +4.5% |
| Session Echo 512B (MB/s) | 40.7 | 83.5 | +105% |
| Session Echo 4KB (MB/s) | 277.8 | 577.4 | +108% |
| FramePipeline 64B (MB/s) | 53.1 | 55.0 | +3.5% |
| FramePipeline 512B (MB/s) | 347.8 | 371.0 | +6.7% |
| FramePipeline 4KB (GB/s) | 2.67 | 2.56 | -4.1% |
Session/Pipeline Affinity 분석:
• Session Echo 512B +105%, 4KB +108%: affinity의 가장 극적인 효과. 세션 처리에서 코어 고정이 워킹 셋을 L1/L2에 유지하여 대폭 개선
• Session Echo 64B +4.5%: 소형 메시지는 이미 캐시에 들어가므로 affinity 효과 제한적
• FramePipeline: 64B/512B에서 소폭 개선, 4KB에서 -4.1% 소폭 퇴보 — 큰 페이로드는 메모리 대역폭 한계로 affinity 효과 상쇄
• i5-9300H에서 Session throughput affinity 효과가 -0.9%(미미)였던 것과 비교하면, i7-14700에서 100% 이상 개선은 P/E 코어 이종 환경에서 affinity가 P-Core 고정을 보장하기 때문으로 해석
• Session Echo 512B +105%, 4KB +108%: affinity의 가장 극적인 효과. 세션 처리에서 코어 고정이 워킹 셋을 L1/L2에 유지하여 대폭 개선
• Session Echo 64B +4.5%: 소형 메시지는 이미 캐시에 들어가므로 affinity 효과 제한적
• FramePipeline: 64B/512B에서 소폭 개선, 4KB에서 -4.1% 소폭 퇴보 — 큰 페이로드는 메모리 대역폭 한계로 affinity 효과 상쇄
• i5-9300H에서 Session throughput affinity 효과가 -0.9%(미미)였던 것과 비교하면, i7-14700에서 100% 이상 개선은 P/E 코어 이종 환경에서 affinity가 P-Core 고정을 보장하기 때문으로 해석
4
3-Way Comparison
4-1. PerCore Architecture 3-Line Overlay
4-2. 코어 수별 확장 효율 테이블
| Cores | v0.6.1.0 (ops/s) |
v0.6.5.0 OFF (ops/s) |
v0.6.5.0 ON (ops/s) |
v0.6.1 → OFF | OFF → ON | v0.6.1 → ON | Linear Efficiency |
|---|---|---|---|---|---|---|---|
| 1 | 1.97M | 1.93M | 1.97M | -2.4% | +2.3% | -0.1% | 100% |
| 2 | 3.28M | 3.34M | 3.33M | +2.0% | -0.2% | +1.7% | 84.5% |
| 3 | 4.83M | 4.42M | 4.50M | -8.5% | +1.7% | -6.9% | 76.1% |
| 4 | 5.76M | 5.56M | 5.30M | -3.4% | -4.7% | -8.0% | 67.2% |
| 8 | 7.65M | 7.01M | 7.34M | -8.3% | +4.7% | -4.0% | 46.5% |
| 16 | 6.52M | 5.87M | 5.97M | -9.9% | +1.7% | -8.4% | 18.9% |
확장 효율 분석:
• Linear Efficiency는 v0.6.5.0 ON 기준 (1코어 1.97M × N 대비 실제 throughput). 16코어에서 18.9%로 급락 — E-Core 포함 구간에서 확장성 한계
• 8코어가 피크 포인트: P-Core 8개와 일치. 이후 E-Core가 투입되면서 코어당 처리량 급감
• v0.6.1.0 baseline에서는 20코어/28코어 데이터도 있었으나 v0.6.5.0에서는 16코어까지 측정. v0.6.1.0의 20C(6.19M)과 28C(5.98M) 값은 16코어 이후 throughput이 정체/하락하는 패턴을 확인
• PerCore 아키텍처에서 v0.6.5.0이 v0.6.1.0보다 약간 낮은 것은 벤치마크 실행 환경 차이(백그라운드 프로세스 등)일 가능성. Integration 벤치에서는 v0.6.5.0이 압도적으로 우세
• Linear Efficiency는 v0.6.5.0 ON 기준 (1코어 1.97M × N 대비 실제 throughput). 16코어에서 18.9%로 급락 — E-Core 포함 구간에서 확장성 한계
• 8코어가 피크 포인트: P-Core 8개와 일치. 이후 E-Core가 투입되면서 코어당 처리량 급감
• v0.6.1.0 baseline에서는 20코어/28코어 데이터도 있었으나 v0.6.5.0에서는 16코어까지 측정. v0.6.1.0의 20C(6.19M)과 28C(5.98M) 값은 16코어 이후 throughput이 정체/하락하는 패턴을 확인
• PerCore 아키텍처에서 v0.6.5.0이 v0.6.1.0보다 약간 낮은 것은 벤치마크 실행 환경 차이(백그라운드 프로세스 등)일 가능성. Integration 벤치에서는 v0.6.5.0이 압도적으로 우세
4-3. i5-9300H vs i7-14700 Cross-Reference
| 지표 | i5-9300H v0.6.5 OFF | i5-9300H v0.6.5 ON | i7-14700 v0.6.5 OFF | i7-14700 v0.6.5 ON | i7/i5 배수 (ON) |
|---|---|---|---|---|---|
| PerCore 1C (ops/s) | 1.11M | 1.10M | 1.93M | 1.97M | 1.79x |
| PerCore 4C (ops/s) | 3.28M | 3.25M | 5.56M | 5.30M | 1.63x |
| CrossCore RTT (ns) | 8,735 | 7,567 | 8,219 | 8,234 | 0.92x |
| CrossCore Throughput | 1.37M | 1.40M | 2.88M | 2.82M | 2.01x |
| Session Echo 64B (MB/s) | 5.56 | 5.51 | 11.84 | 12.38 | 2.25x |
| Affinity RTT 효과 | -13.4% | +0.2% | - | ||
| Affinity Session 효과 | -0.9% | +105% (512B) | - | ||
Cross-Reference 분석:
• 단일 코어 성능: i7-14700 P-Core가 i5-9300H 대비 1.79배 — 세대 차이(Coffee Lake vs Raptor Lake) + 클럭 차이(4.1GHz vs 5.4GHz)
• 크로스코어 처리량: i7이 2.01배로 코어 수 차이를 넘는 개선. L3 33MB vs 8MB의 캐시 효과
• Affinity 효과 패턴이 전혀 다르다:
- i5: RTT에서 -13.4% 개선, Session에서 효과 없음(-0.9%)
- i7: RTT에서 효과 없음(+0.2%), Session 512B에서 +105%
- 이는 P/E 코어 이종 구조의 결과. i7에서 affinity 없이 실행하면 워커가 E-Core에 배치될 수 있어 Session 처리 성능이 불안정. Affinity가 P-Core 고정을 보장하면서 Session에서 극적 개선
• i5-9300H(동종 4C)에서는 어디에 배치되든 코어 성능이 동일하므로 affinity가 레이턴시(캐시 로컬리티)에만 영향
• 단일 코어 성능: i7-14700 P-Core가 i5-9300H 대비 1.79배 — 세대 차이(Coffee Lake vs Raptor Lake) + 클럭 차이(4.1GHz vs 5.4GHz)
• 크로스코어 처리량: i7이 2.01배로 코어 수 차이를 넘는 개선. L3 33MB vs 8MB의 캐시 효과
• Affinity 효과 패턴이 전혀 다르다:
- i5: RTT에서 -13.4% 개선, Session에서 효과 없음(-0.9%)
- i7: RTT에서 효과 없음(+0.2%), Session 512B에서 +105%
- 이는 P/E 코어 이종 구조의 결과. i7에서 affinity 없이 실행하면 워커가 E-Core에 배치될 수 있어 Session 처리 성능이 불안정. Affinity가 P-Core 고정을 보장하면서 Session에서 극적 개선
• i5-9300H(동종 4C)에서는 어디에 배치되든 코어 성능이 동일하므로 affinity가 레이턴시(캐시 로컬리티)에만 영향
5
Conclusions
5-1. i7-14700 관찰 요약
1. 버전 간 개선 (v0.6.1 → v0.6.5):
• Cross-Core RTT -37%, Throughput +67% — 코어간 통신 경로의 구조적 개선 확인
• FramePipeline 77~93% 향상 — E2E 파이프라인 전체가 개선
• FlatBuffers Build 2x, TimingWheel 2x, Session Create 2.3x — 주요 컴포넌트 전반적 향상
• FrameCodec Encode/Decode -13~18% 퇴보 — 향후 프로파일링 필요
2. Affinity 효과 (v0.6.5 OFF → ON):
• Session Echo 512B/4KB에서 +105%/+108% — P/E 코어 환경에서 affinity의 핵심 가치
• PerCore 8C +4.7%, LockFree 8C +11.3% — 물리 P-Core 범위에서 유의미한 개선
• Cross-Core Latency에서는 효과 미미 (+0.2%) — 단일 NUMA이므로 레이턴시 이점 제한적
• 소수 코어(2C)에서 간헐적 퇴보 — OS 스케줄러의 유연한 마이그레이션이 더 유리한 구간 존재
• Cross-Core RTT -37%, Throughput +67% — 코어간 통신 경로의 구조적 개선 확인
• FramePipeline 77~93% 향상 — E2E 파이프라인 전체가 개선
• FlatBuffers Build 2x, TimingWheel 2x, Session Create 2.3x — 주요 컴포넌트 전반적 향상
• FrameCodec Encode/Decode -13~18% 퇴보 — 향후 프로파일링 필요
2. Affinity 효과 (v0.6.5 OFF → ON):
• Session Echo 512B/4KB에서 +105%/+108% — P/E 코어 환경에서 affinity의 핵심 가치
• PerCore 8C +4.7%, LockFree 8C +11.3% — 물리 P-Core 범위에서 유의미한 개선
• Cross-Core Latency에서는 효과 미미 (+0.2%) — 단일 NUMA이므로 레이턴시 이점 제한적
• 소수 코어(2C)에서 간헐적 퇴보 — OS 스케줄러의 유연한 마이그레이션이 더 유리한 구간 존재
5-2. P/E 코어 환경에서의 Affinity 효과
Intel Hybrid Architecture(P/E Core)에서 affinity의 역할은 동종 코어 환경과 근본적으로 다르다:
동종 환경 (i5-9300H): Affinity = 캐시 로컬리티 최적화. 어떤 코어에서든 동일한 처리 능력이므로, affinity는 캐시 마이그레이션 비용만 줄인다. 결과적으로 레이턴시 개선(-13.4%)은 있지만 throughput 개선은 미미(-0.9%).
이종 환경 (i7-14700): Affinity = 성능 코어 보장. P-Core(5.4GHz)와 E-Core(4.0GHz)의 성능 차이가 크기 때문에, affinity 없이 워커가 E-Core에 배치되면 성능이 급락한다. Affinity가 P-Core 고정을 보장하면서 Session 처리에서 +105%라는 극적 개선이 나타난 것이다.
이는 서버 환경에서 P/E 코어 분류 + affinity 바인딩이 선택이 아닌 필수임을 의미한다. 특히 latency-sensitive 워크로드(Session Echo, 실시간 메시지 처리)에서는 E-Core 배치를 반드시 방지해야 한다.
동종 환경 (i5-9300H): Affinity = 캐시 로컬리티 최적화. 어떤 코어에서든 동일한 처리 능력이므로, affinity는 캐시 마이그레이션 비용만 줄인다. 결과적으로 레이턴시 개선(-13.4%)은 있지만 throughput 개선은 미미(-0.9%).
이종 환경 (i7-14700): Affinity = 성능 코어 보장. P-Core(5.4GHz)와 E-Core(4.0GHz)의 성능 차이가 크기 때문에, affinity 없이 워커가 E-Core에 배치되면 성능이 급락한다. Affinity가 P-Core 고정을 보장하면서 Session 처리에서 +105%라는 극적 개선이 나타난 것이다.
이는 서버 환경에서 P/E 코어 분류 + affinity 바인딩이 선택이 아닌 필수임을 의미한다. 특히 latency-sensitive 워크로드(Session Echo, 실시간 메시지 처리)에서는 E-Core 배치를 반드시 방지해야 한다.
5-3. i5-9300H vs i7-14700 비교 인사이트
단일 코어 성능: i7 P-Core가 i5 대비 1.79배. 클럭(4.1 vs 5.4 GHz)과 아키텍처(Coffee Lake vs Raptor Lake) 세대 차이가 주요 원인.
확장성: i7의 PerCore 아키텍처는 8코어(P-Core)까지 양호한 확장을 보이나, 이후 E-Core 투입으로 코어당 효율이 급락한다. i5는 4코어에서도 선형 효율 74%를 유지.
Affinity 효과 패턴: 완전히 다른 양상 — i5는 레이턴시, i7은 throughput에서 효과. 이종 코어가 affinity의 의미를 근본적으로 변경한다.
메시지 전달: Cross-Core Throughput에서 i7이 i5의 2.01배. 코어 수 증가 + L3 캐시 4배(8MB → 33MB)의 복합 효과.
확장성: i7의 PerCore 아키텍처는 8코어(P-Core)까지 양호한 확장을 보이나, 이후 E-Core 투입으로 코어당 효율이 급락한다. i5는 4코어에서도 선형 효율 74%를 유지.
Affinity 효과 패턴: 완전히 다른 양상 — i5는 레이턴시, i7은 throughput에서 효과. 이종 코어가 affinity의 의미를 근본적으로 변경한다.
메시지 전달: Cross-Core Throughput에서 i7이 i5의 2.01배. 코어 수 증가 + L3 캐시 4배(8MB → 33MB)의 복합 효과.
5-4. 최종 결론
1. v0.6.5.0은 v0.6.1.0 대비 전반적으로 우수하다. 크로스 코어 통신, 파이프라인, 세션 처리 모두 대폭 개선. FrameCodec 퇴보만 향후 추적 필요.
2. Affinity 바인딩은 i7-14700(P/E Hybrid)에서 필수다. Session 처리 +105%는 운영 환경에서 무시할 수 없는 차이. 반면 동종 코어(i5)에서는 선택적.
3. Windows 환경의 한계가 존재한다. Windows Thread Scheduler가 P/E 코어 인식은 하지만 벤치마크 수준의 정밀한 코어 배치는 보장하지 않는다. 특히 PerCore 16C 구간에서 affinity 효과가 제한적인 것은 Windows의 E-Core 관리 정책과 충돌할 가능성.
4. Linux Docker 벤치마크가 필요하다. 실제 배포 환경인 Linux/Docker에서:
• cgroup CPU pinning으로 더 정밀한 코어 제어 가능
• Linux CFS 스케줄러의 P/E 코어 처리 방식이 Windows와 다를 수 있음
• NUMA 다중 노드 환경(서버급 CPU)에서 affinity 효과가 극대화될 것으로 예상
• Docker 컨테이너 간 코어 격리 시나리오의 성능 검증 필요
2. Affinity 바인딩은 i7-14700(P/E Hybrid)에서 필수다. Session 처리 +105%는 운영 환경에서 무시할 수 없는 차이. 반면 동종 코어(i5)에서는 선택적.
3. Windows 환경의 한계가 존재한다. Windows Thread Scheduler가 P/E 코어 인식은 하지만 벤치마크 수준의 정밀한 코어 배치는 보장하지 않는다. 특히 PerCore 16C 구간에서 affinity 효과가 제한적인 것은 Windows의 E-Core 관리 정책과 충돌할 가능성.
4. Linux Docker 벤치마크가 필요하다. 실제 배포 환경인 Linux/Docker에서:
• cgroup CPU pinning으로 더 정밀한 코어 제어 가능
• Linux CFS 스케줄러의 P/E 코어 처리 방식이 Windows와 다를 수 있음
• NUMA 다중 노드 환경(서버급 CPU)에서 affinity 효과가 극대화될 것으로 예상
• Docker 컨테이너 간 코어 격리 시나리오의 성능 검증 필요