06 May 2026 6 min read

Order of Scale

핵심 scale

At 3 GHz 기준

1 ns   ≈ 3 cycles10 ns  ≈ 30 cycles100 ns ≈ 300 cycles1 µs   ≈ 3,000 cycles1 ms   ≈ 3,000,000 cycles

그래서 30 ns/op이면 약 90 cycles/op이고, 1 µs/op이면 약 3,000 cycles/op이야. Microbenchmark 결과가 이 감각에서 벗어나면, compiler가 optimize-away했거나, cache-hot 조건만 재고 있거나, benchmark harness가 이상한 걸 재고 있을 가능성을 먼저 봐야 해.

Latency order 요약

Operation / event	Rough order	판단 포인트
Simple ALU op / register work	sub-ns ~ 1 ns	Tight dependency chain이 아니면 보통 bottleneck 아님
L1 cache reference	~0.5–1 ns	Hot data path의 기본 단위
L2 cache reference	~3–5 ns	여전히 cheap하지만 L1보다 한 order 가까이 느림
Branch mispredict	~3–20 ns	Tight loop에서 unpredictable branch가 많으면 바로 문제
Uncontended mutex lock/unlock	~15–25 ns	Per-element hot path에는 부담
DRAM reference	~50–100 ns	Pointer chasing, random access가 왜 비싼지 보여주는 기준
Real syscall	~0.1–0.6 µs	vDSO fast path는 훨씬 싸지만 real syscall은 mode switch cost 존재
Direct context switch	~1–2 µs	Direct cost만 이 정도이고 cache/TLB disruption은 별도
Fast NVMe 4 KiB random read	~20–100 µs	Storage read를 critical path에 두고 10 µs tail을 기대하면 안 됨
Same datacenter / same-zone RTT	~50 µs–1 ms	Placement, virtualization, congestion에 따라 크게 흔들림
Cloud block storage	~0.25–1 ms	AWS `io2 Block Express`는 16 KiB I/O 평균 latency under 500 µs로 설계됨
Cross-AZ RTT	~1–10 ms	여러 번 넘으면 app code 100 µs 최적화보다 routing이 더 중요
Cross-continent RTT	~100–200 ms	Round trip 제거가 local optimization보다 훨씬 큼

Abseil의 updated table은 L1 cache reference 0.5 ns, L2 3 ns, branch mispredict 5 ns, uncontended mutex 15 ns, main memory reference 50 ns, 4 KiB SSD read 20 µs, same datacenter RTT 50 µs, 1 MiB over 100 Gbps network 100 µs 같은 rough cost를 제시해. Abseil #62도 RAM access를 약 100 ns scale로 설명하고, cache line이 보통 64-byte granularity라고 강조해.

OS 쪽에서는 real syscall의 minimal cost가 machine/kernel/configuration에 따라 대략 수백 ns scale로 측정될 수 있고, clock_gettime 같은 일부 path는 vDSO 때문에 훨씬 싸게 보일 수 있어. Context switch는 single-core pinned synthetic benchmark에서 direct cost가 대략 1.2–1.5 µs, pinning이 없으면 더 올라가는 것으로 측정된 사례가 있어.

Storage는 device와 stack을 구분해야 해. 예를 들어 Micron 9400 NVMe SSD spec은 128 KiB sequential read/write 7,000 MB/s, 4 KiB random read latency median 69 µs, 99th percentile 85 µs를 제시한다. 반면 AWS EBS io2 Block Express는 16 KiB I/O 평균 latency under 500 µs로 설계되었다고 문서화돼 있어. 즉 local NVMe device, kernel block layer, cloud networked block storage는 같은 “SSD”라도 order가 다를 수 있어.

Network는 topology가 전부야. AWS는 same-AZ enhanced networking RTT가 보통 sub-millisecond이고, 같은 region의 AZ 간 RTT는 single-digit millisecond라고 설명한다. Google Cloud 문서도 user last mile latency가 modern network에서는 ISP까지 1–10 ms, DSL/cable은 10–60 ms, 3G cellular은 100–500 ms scale이라고 설명해.

Bandwidth order 요약

Resource / path	Rough order	판단 포인트
Single-core streaming DRAM	~10–50 GB/s	Abseil quicksort estimate는 per-core memory bandwidth를 ~16 GB/s로 가정
Socket DRAM bandwidth	~100 GB/s–several 100 GB/s	Peak보다 NUMA, contention, access pattern이 중요
10 Gbps Ethernet	~1.25 GB/s raw	1 MiB transfer lower bound ~0.8 ms
100 Gbps Ethernet	~12.5 GB/s raw	1 MiB transfer lower bound ~80–100 µs
Enterprise NVMe sequential	~6–7 GB/s per drive	Large I/O와 queue depth가 필요
HDD sequential	~100–250 MB/s	Sequential은 가능하지만 random seek가 ms scale

Bandwidth에서는 “peak bandwidth”보다 useful bandwidth를 봐야 해. 예를 들어 64-byte cache line 중 8-byte만 실제로 쓰면 memory bandwidth efficiency는 12.5% order야. Abseil #62가 말하는 hot/cold benchmark도 이 감각이야. 작은 microbenchmark는 working set이 cache에 다 들어가서 arithmetic cost만 보이고, production에서는 cache miss와 memory bandwidth가 지배할 수 있다.

Hardware Performance Counters에서 볼 값

perf stat, Google Benchmark의 --benchmark_perf_counters, PMU sampling 등을 쓸 때는 아래를 보면 좋아. Abseil #53은 instructions retired, cycles, loads/stores, cache misses, branches, branch mispredicts 같은 Hardware Performance Counters를 time-based benchmark와 함께 보면 regression root cause를 훨씬 빨리 좁힐 수 있다고 설명해. 특히 instructions retired 같은 counter는 time보다 noise가 훨씬 적고, 특정 조건에서는 variation이 0.01% 미만일 수 있다고 말해.

Metric	Rough heuristic	의미
`instructions/op`	version 간 거의 deterministic해야 함	갑자기 늘면 extra work, inlining, codegen 변화 의심
`cycles/op`	`ns/op × GHz`와 일관성 확인	Time regression이 진짜 CPU work인지 noise인지 구분
`IPC` / `CPI`	`IPC < 1`이면 stall 의심	Memory-bound, branch-bound, frontend-bound 가능성
`branch-misses / branches`	hot loop에서 몇 % 이상이면 의심	unpredictable branch 또는 layout issue
`L1-dcache-load-misses`	hot benchmark에서는 낮아야 함	working set이 L1에 안 맞거나 access pattern 문제
`LLC-load-misses` / `MPKI`	`MPKI`가 10+면 memory-bound 가능성 큼	DRAM miss, pointer chasing, poor locality
`dTLB-load-misses`, page walks	large working set에서 중요	huge page, layout, batching 후보
`frontend-bound`, `i-cache misses`	code size 문제	`memcmp bloat` 같은 문제를 잡는 신호
`backend-bound`, `mem-bound`	memory/dependency 문제	instruction 줄이기보다 data layout이 더 중요할 수 있음
`context-switches/sec`	100k/s면 이미 의심	100k/s × 1.5 µs ≈ 150 ms CPU/s direct overhead
allocation count/op	hot path에서 `>0`이면 의심	allocator cost + cache churn + GC/fragmentation

perf는 cycles, instructions, L1 cache misses 같은 PMU event와 context-switches, minor faults 같은 software event를 측정할 수 있고, perf stat -d는 L1/LLC cache, TLB, prefetch 관련 detailed statistics를 단계적으로 보여준다.

판단에 바로 쓰는 예시

첫째, hot request path에서 random DRAM reference를 10개 줄이고 QPS가 1M이면:

10 references × 50 ns × 1,000,000 req/s= 0.5 CPU-second / second≈ 0.5 core

Fleet-wide hot path면 meaningful하고, low-QPS path면 아닐 수 있어.

둘째, context switch가 100k/sec이면:

100,000 × 1.5 µs= 150 ms CPU time / second≈ one core의 15% direct overhead

여기에 cache/TLB disruption은 빠져 있으니 실제 영향은 더 클 수 있어.

셋째, NVMe random read가 median tens of µs order라면, 10 µs tail latency target을 가진 service에서 storage read를 critical path에 두는 설계는 처음부터 불리해. Cache, prefetch, async pipeline, batching, admission control을 먼저 봐야 해.

넷째, cross-AZ boundary를 request 하나가 여러 번 넘으면 app code를 100 µs 줄이는 것보다 request routing, AZ affinity, replication protocol을 바꾸는 게 더 큰 효과를 낼 수 있어. AWS도 cross-AZ traversal이 여러 번 생기면 latency lower bound가 빠르게 커지는 예시를 든다.