본문으로 건너뛰기
0
r/jeffnews HN 약 4분

칩셋 레이턴시를 측정해봤더니 — 쓸모는 없지만 재밌는 실험

backend

요약

Vulkan GPU 벤치마크로 여러 세대 마더보드 칩셋의 PCIe 레이턴시를 측정한 실험. CPU 직결 대비 칩셋 경유 시 수백 ns 레이턴시가 추가되며, 의외로 2012년 Skylake Z170이 가장 낮은 추가 레이턴시를 보임.

기사 전체 정리

칩셋 레이턴시를 측정해봤더니 — 쓸모는 없지만 재밌는 실험

왜 칩셋을 벤치마킹하나

  • 마더보드 칩셋은 시간이 지나면서 성능 핵심 역할을 거의 다 잃었음. Athlon 64 시절에 메모리 컨트롤러가 CPU로 들어갔고, Sandy Bridge 때 PCIe 레인도 CPU로 올라옴. 지금 칩셋은 IO 기능을 호스팅하지만 성능 방정식에서는 각주 수준임

  • 유용하진 않지만 재미는 있으니까 해보자는 취지. Vulkan 기반 GPU 벤치마크를 수정해서 호스트 메모리에서 GPU 메모리 접근 레이턴시를 측정함. CPU PCIe 슬롯 vs 사우스브리지 PCIe 슬롯 차이를 보는 거임. 테스트 GPU는 1슬롯짜리 Nvidia T1000

플랫폼별 결과

  • AMD AM5 (Zen 5):

    • CPU PCIe 레인: 약 650ns 기본 레이턴시
    • B650 칩셋(PROM21 1개) 경유: 1,221ns (+570ns)
    • X670E 칩셋(PROM21 2개) 경유: +921ns — 칩셋 하나 더 거치면 레이턴시가 더 늘어남
    • 칩셋 경유 시 GPU 캐시 히트 대역폭이 25 GB/s 수준으로 떨어짐
  • Intel Arrow Lake (Z890):

    • CPU PCIe 레인: 785ns (Zen 5보다 높음)
    • PCH 경유: +약 550ns (B650의 PROM21 1개와 비슷)
  • Intel Skylake (Z170):

    • CPU PCIe 레인: 535.59ns — 의외로 가장 낮은 기본 레이턴시
    • Z170 PCH 경유: +338ns — 현세대보다 오히려 나음
    • PCH 경유 시 캐시 히트 대역폭 51 GB/s 이상
  • AMD AM3+ (990X, Piledriver):

    • 모든 PCIe가 외부 노스브리지를 거치는 옛날 구조인데도 기본 레이턴시가 769.67ns로 선방
    • SB950 사우스브리지 경유: +602ns
    • 990X 노스브리지의 프로브 처리량이 IO 대역폭(10.5 GB/s)을 포화시키는 데 필요한 것의 10배나 됨

미스터리와 결론

  • VK_MEMORY_PROPERTY_HOST_COHERENT_BIT 설정 시 GPU 캐시 히트에도 대량의 프로브 트래픽이 발생하는데, 프로브가 64바이트 캐시라인이 아니라 512바이트마다 1개씩 발생하는 이상한 현상이 있음. 아직 설명 못 함

  • 칩셋 PCIe 레인은 수백 ns의 레이턴시 패널티와 대역폭 제한을 부과함. 하지만 SSD나 네트워크 어댑터는 μs~ms 단위 레이턴시이므로 수백 ns는 의미 없음. 멀티 GPU가 사라진 지금, 칩셋은 저렴한 비용과 더 나은 연결성에 최적화될 거지 레이턴시 최적화는 기대하기 어려움

핵심 포인트

  • AMD AM5 CPU 직결 650ns, 칩셋 1개 경유 +570ns, 2개 경유 +921ns
  • Intel Arrow Lake CPU 직결 785ns, PCH 경유 +550ns
  • Skylake Z170이 +338ns로 현세대보다 오히려 양호
  • 칩셋 경유 시 GPU 캐시 히트 대역폭도 크게 제한됨

인사이트

쓸모 없는 벤치마크라고 스스로 인정하면서도 재미로 밀고 가는 게 오히려 매력적. 하드웨어 덕후라면 플랫폼별 수치 비교만으로도 흥미로울 듯.

댓글

댓글

댓글을 불러오는 중...

backend

Redis 8.0 출시 — I/O 스레딩 갈아엎고 처리량 3배, 2.1M ops/sec 달성

Redis 8.0이 I/O 스레딩 모델을 완전히 재설계해서 16코어 기준 2.1M ops/sec를 달성함 (7.4 대비 3배). Hash field expiration, Vector search HNSW, Client-side caching v2, Redis Functions 2.0 async 실행 등 굵직한 기능이 추가되고, jemalloc 통합으로 메모리 fragmentation도 25% 줄어듦.

backend

Go 1.26의 타입 생성(Type Construction)과 순환 감지(Cycle Detection) 개선

Go 1.26에서 타입 체커의 타입 생성 알고리즘을 개선해 재귀 타입과 배열 크기 계산 시 발생하던 순환 감지 문제를 체계적으로 해결했다. 불완전한 값이 다운스트림으로 퍼지기 전에 업스트림에서 차단하는 새로운 접근법으로 여러 컴파일러 패닉을 수정.

backend

Cloudflare Gen 13 서버: 캐시를 코어로 바꿔 성능 2배 달성한 이야기

Cloudflare가 AMD Turin 9965(192코어) 기반 Gen 13 서버를 배포함. 코어당 L3 캐시가 6배 줄어 레거시 NGINX 스택(FL1)으로는 레이턴시 50% 악화가 불가피했으나, Rust로 전면 재작성한 FL2로 전환해 Gen 12 대비 처리량 2배, 성능/와트 50% 개선을 달성함.

backend

ForgeKV — Rust로 만든 멀티코어 Redis 대체제

Rust로 만든 Redis 드롭인 대체제. 64-샤드 잠금 아키텍처로 멀티코어 스케일링 지원. 2코어 환경에서 Redis 7 대비 41% 빠른 SET 처리량(158K ops/s). 고동시성에서는 약점 있음. Source-available 라이선스.

backend

AI 바이브 코딩에 Go를 쓰는 이유 — Rust도 Python도 아닌

AI가 코드의 90%를 쓰는 바이브 코딩 시대에 Go가 최적의 언어라는 주장. Python은 안전장치가 없고, Rust는 언어 자체의 문제까지 인간에게 떠넘기지만, Go는 중요한 것만 잡고 비켜준다는 논리. 실제로 한 세션에 3도메인 풀스택 블로그를 7커밋으로 완성한 사례 제시.