본문으로 건너뛰기
피드

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

backend 약 4분
vote
0
댓글
북마크

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

  • 1

    AMD AM5 CPU 직결 650ns, 칩셋 1개 경유 +570ns, 2개 경유 +921ns

  • 2

    Intel Arrow Lake CPU 직결 785ns, PCH 경유 +550ns

  • 3

    Skylake Z170이 +338ns로 현세대보다 오히려 양호

  • 4

    칩셋 경유 시 GPU 캐시 히트 대역폭도 크게 제한됨

왜 칩셋을 벤치마킹하나

  • 마더보드 칩셋은 시간이 지나면서 성능 핵심 역할을 거의 다 잃었음. 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가 사라진 지금, 칩셋은 저렴한 비용과 더 나은 연결성에 최적화될 거지 레이턴시 최적화는 기대하기 어려움

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

댓글

댓글

댓글을 불러오는 중...

backend

잘못된 추상화보다 중복이 낫다는 샌디 메츠의 고전 조언

샌디 메츠는 중복을 없애려다 잘못된 추상화를 만들면 코드가 조건문과 파라미터로 부풀어 더 위험해진다고 말한다. 이미 틀어진 추상화는 억지로 보존하지 말고, 다시 호출부에 인라인해서 중복을 되살린 뒤 현재 요구사항에 맞는 새 구조를 찾는 편이 빠르다는 주장이다.

backend

리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

backend

덕디비는 왜 빠를까: 서버 없는 분석 엔진의 내부 구조 뜯어보기

DuckDB가 단일 바이너리, 인프로세스 실행, 컬럼형 저장, 최적화 패스, Parquet 푸시다운으로 빠른 분석 쿼리를 처리하는 방식을 깊게 설명한 글이다. 6GB Parquet 파일을 노트북에서 바로 SQL로 읽는 경험 뒤에 어떤 설계가 깔려 있는지 따라간다.

backend

피지독, 포스트그레스를 수평 확장시키겠다고 550만 달러 투자 유치

피지독은 포스트그레스 앞단에 프록시를 두고 샤딩과 라우팅을 처리해 수평 확장을 가능하게 하겠다는 오픈소스 프로젝트다. 이미 프로덕션에서 초당 200만 건이 넘는 쿼리를 처리하고, 확인된 규모만 20테라바이트 이상을 샤딩했다고 밝히며 550만 달러 투자를 공개했다.

backend

펜타시스템, EDB 포스트그레SQL로 국내 엔터프라이즈 DB 전환 시장 공략

펜타시스템테크놀러지가 EDB와 파트너 계약을 맺고 국내에 EDB 포스트그레SQL 기반 데이터 플랫폼을 공급한다. 기존 상용 DBMS 정책 변화로 비용 부담이 커진 기업들을 겨냥해, 오픈소스 기반 엔터프라이즈 데이터 플랫폼 전환 수요를 잡겠다는 전략이다. 금융, 공공, 제조, 유통, 클라우드, AI 데이터 분석 환경까지 적용 범위를 넓히려는 움직임이다.