AMD Zen 6, 분기 예측 실패 비용을 분기당 3~3.5ns로 줄이고 단일 스레드가 디코드 클러스터 2개를 모두 사용함
- Zen 6은 분기 예측 실패 복구 비용을 분기당 3~3.5ns로 낮춰 Zen 5의 3.5~4ns보다 줄였고, 예측 정확도는 Zen 5 수준을 유지함
- Zen 5에서는 스레드 하나가 디코드 클러스터 하나만 쓸 수 있었지만 Zen 6은 단일 스레드가 두 클러스터를 모두 사용함
- BTB는 용량을 키우는 대신 속도에 투자했고, L1i 안에서는 사이클당 분기 2개를 처리하다가 L1i를 넘으면 다시 1개로 떨어짐
- 정수 곱셈 유닛을 3개에서 2개로 줄이고 PDEP/PEXT 처리량도 사이클당 3개에서 2개로 낮춘 대신, 256b 이하 벡터 로드를 사이클당 4개 처리함
- Zen 6c는 CCD당 32코어로 Zen 6의 12코어를 크게 넘지만 L3 레이턴시가 10.7ns에서 16.4ns로 늘어남
Hacker News 의견들
코어가 메모리 컨트롤러보다 훨씬 빨라진 판에 왜 코어마다 컨트롤러를 안 붙이나 싶음. 대역폭이 아니라 레이턴시 때문에 그런 건가.
컨트롤러 늘리면 PHY도 늘고 패키지 핀도 늘고 보드 트레이스도 늘어남. 어느 지점부터는 물리적으로 못 만듦.
AMD는 이미 채널 수로 등급을 나눠 팔고 있잖아. 소비자 2채널, 스레드리퍼 4, 8005가 6, EPYC 12채널이고 Zen 6 EPYC은 16채널임. 대역폭이 급하면 칩렛 적게 넣은 8코어 EPYC을 사면 됨.
대부분 워크로드는 대역폭이 병목이 아님. 진짜 필요한 건 레이턴시인데 그건 대역폭만큼 안 좋아졌어.
128코어에 DIMM당 288핀을 곱해보면 소켓에 3만 6천 핀이 필요함. 그 배선은 누가 깔지 생각해보면 답 나옴.
AM5 소켓이 1718핀인데 그중 메모리 레인은 4x32bit뿐임. PCIe 28레인, USB, 디스플레이까지 다 합친 숫자임.
Zen 6c가 따로 노는 게 아쉬웠는데 OoO 구조를 오히려 키웠더라. 메모리가 무거워지니까 레이턴시 흡수하려는 거고 그건 인정함.
L3 조정하고 노드 줄여서 12코어가 32코어가 되는 게 신기함. 다만 6c L3 레이턴시가 16.4ns까지 오르는 건 CCD가 커지는 대가 같음.
그건 메모리 서브시스템 차이라기보다 클럭 목표가 낮아서 생긴 여유 아닐까. 구조 키우는 건 면적은 거의 안 먹는데 타이밍은 빡빡해짐.
CCD를 다시 쪼개면 게임이 죽어서 못 쪼갤 거임. AMD 게임 드라이버가 2-CCD CPU에서 두 번째 CCD를 파킹하는 판국인데.
2-ahead 분기 예측의 ILP가 신기함. 메모리가 이렇게 느리니까 이런 복잡도가 이득이 되는 거겠지.
CPU에서 계산하는 부분은 거의 무시할 수준이고 대부분 SRAM과 재정렬, 분기 예측임.
SPEC2026 그래프에 애플 P코어가 빠진 게 웃김. Graviton은 넣으면서. 정수 9.8, FP 13이면 차트 전체를 지워버리는데.
서버 부품 리뷰니까 애플이 빠진 건 당연하지. M칩을 하이퍼스케일러에 파는 것도 아니고.
싱글스레드는 애플 코어가 훌륭하지만 소켓 단위 멀티스레드는 Zen 6이 압살함. 서버 CPU랑 비교할 물건이 아님.
코어 자체는 작고 균형 잡힌 개선처럼 보임. 256b 이하 벡터 로드를 사이클당 4개 한다니 gather 성능은 이제 괜찮아졌나 싶고.
정수 곱셈기를 3개에서 2개로 줄인 게 의외인데 VNNI 파이프 자리 만드려고 그런 건가.
곱셈기랑 회로를 공유하는 건 아닐 테고, 레이아웃 단순화하려고 곱셈기 있는 실행 유닛 2개를 동일하게 맞추면서 PDEP/PEXT도 거기 붙인 거임.
32코어 CCD면 CCD와 코어 사이에 중간 단위가 있냐, 최하위 NUMA 레벨에서 32코어를 다뤄야 하냐.
중간 단위는 없는 걸로 보임. L3를 넘나들지 않는 큰 VM을 만들 수 있어서 오히려 좋음. 32코어는 6c CCD 얘기고 일반 Zen 6 CCD는 12코어임.