AMD, Zen 4의 루프 버퍼 비활성화 결정

• ASRock B650 PG Lightning의 새 BIOS에서 Zen 4 루프 버퍼가 더 이상 마이크로-op 공급원으로 관측되지 않았고, 이전 BIOS로 되돌리면 다시 활성화됨
• 이 구조는 작은 루프를 프론트엔드에서 반복 처리해 전력을 줄이려는 기능으로 보이며, 단일 스레드 144 엔트리, SMT 2스레드에서는 스레드당 72 엔트리로 추정됨
• SPEC CPU2017에서는 루프 버퍼 활성/비활성 간 총점 차이가 1% 미만이라, 일반 성능 영향은 매우 작아 보임
• 루프 버퍼가 꺼지면 Zen 4는 더 많은 마이크로-op를 op cache에서 공급하며, op cache 대역폭이 후단 처리량보다 충분해 프론트엔드 병목으로 이어지기 어려움
• 비활성화 이유와 실제 전력 영향은 불확실하지만, AMD가 거의 문서화하거나 홍보하지 않은 제한적 기능이라 대부분의 사용자와 개발자는 변화를 체감하기 어려움

---

Zen 4 루프 버퍼의 역할과 한계

• 루프 버퍼는 CPU 프론트엔드에서 이미 가져온 소수의 명령을 보관해, 작은 루프를 반복 실행할 때 일부 프론트엔드 단계를 끌 수 있게 하는 구조임
  • 전력 절감에 도움이 될 수 있음
  • 앞단 프론트엔드 제한을 우회해 성능을 개선할 여지도 있음
  • Intel, Arm, AMD 코어에서 오래전부터 쓰인 기법임
• Zen 4는 고성능 AMD 코어 중 루프 버퍼가 있는 유일한 사례로 파악됨
• Zen 4의 Processor Programming Reference는 루프 버퍼를 op cache, 디코더와 함께 마이크로-op dispatch 소스로 언급함
• 성능 카운터 실험상 용량은 다음과 같이 추정됨
  • 단일 스레드 실행 시 144 엔트리
  • SMT 2스레드 활성 시 스레드당 72 엔트리로 정적 분할
• 루프 안에 CALL/RET가 있으면 Zen 4 루프 버퍼가 해당 루프를 캡처하지 못함
• AMD의 Zen 4 최적화 가이드는 루프 버퍼를 다루지 않고, hot code region을 op cache 용량 안에 유지하라는 조언만 제공함

BIOS 업데이트 뒤 사라진 루프 버퍼

• ASRock B650 PG Lightning을 BIOS 3.10으로 업데이트한 뒤, 하드웨어 성능 모니터링에서 루프 버퍼가 마이크로-op를 dispatch하지 않는 것으로 나타남
• BIOS 1.21로 되돌리면 루프 버퍼가 다시 활성화됨
• 비활성화는 BIOS 1.21의 AGESA 1.0.0.6과 BIOS 3.10의 AGESA 1.2.0.2a 사이에서 발생한 것으로 보임
• AMD는 이 변경을 별도 발표나 홍보 없이 적용함
• Hot Chips 2024에서 AMD 직원들과 나눈 부가 논의상, 루프 버퍼는 주로 전력 최적화 목적의 기능이었음

SPEC CPU2017에서 드러난 작은 성능 차이

• SPEC CPU2017 정수·부동소수점 suite의 총점은 루프 버퍼 활성/비활성 간 1% 미만 차이에 그침
• SMT 성능 향상도 루프 버퍼 비활성화로 영향을 받지 않음
• 성능 영향이 작은 이유는 Zen 4의 op cache가 이미 후단 rename/allocate 단계가 소비할 수 있는 것보다 많은 대역폭을 제공하기 때문임
• 루프 버퍼가 켜져 있어도 성능 카운터상 마이크로-op의 소수만 루프 버퍼에서 공급됨
• 개별 benchmark에서도 큰 손실은 확인되지 않음
  • 523.xalanbmk는 instruction stream 중 의미 있는 소수 비중을 루프 버퍼가 담당했지만, 점수는 새 BIOS 9.48, 이전 BIOS 9.44로 오차 범위 안에 있음
  • 544.nab는 마이크로-op의 거의 4분의 1을 루프 버퍼에서 공급받았지만, 루프 버퍼가 꺼진 새 BIOS에서 점수가 11.7로 이전 11.5보다 1.7% 증가함
  • 이 증가는 run-to-run variance일 수 있음
• 새 BIOS의 성능 카운터에서는 op cache가 루프 버퍼의 몫을 가져가며 instruction stream의 더 큰 비중을 처리함
• 507.cactuBSSN에서는 op cache coverage가 일부 낮아지고 디코더가 전체 마이크로-op의 약 4분의 1을 공급하는 패턴이 보임
  • 성능 카운터는 100% 정확한 측정보다는 전반적 경향을 보여주는 도구임
  • 프론트엔드 dispatch는 speculative event라 잘못 예측된 분기 뒤의 잘못 가져온 명령에도 영향을 받을 수 있음

전력 절감 가능성과 프론트엔드 활동

• 루프 버퍼의 주된 목적은 성능 향상이 아니라 op cache를 포함한 프론트엔드 상당 부분을 기회적으로 끄는 데 있음
• Zen 4의 성능 모니터링 기능에는 count mask가 있어 이벤트 카운트가 임계값을 넘는 사이클을 셀 수 있음
  • 임계값을 1로 두면 각 마이크로-op 공급원이 실제로 마이크로-op를 공급한 사이클 수를 추정할 수 있음
  • 이를 통해 루프 버퍼 활성 시 프론트엔드를 얼마나 자주 끌 수 있는지 가늠함
• SPEC CPU2017에서 각 공급원이 활성인 빈도는 해당 공급원이 전달한 마이크로-op 비율과 대체로 잘 맞음
• 일부 workload에서는 프론트엔드가 아무것도 공급하지 않는 사이클도 상당함
  • 502.gcc, 520.omnetpp는 backend memory latency에 크게 묶임
  • out-of-order 실행 엔진이 latency를 숨길 만큼 충분한 명령을 flight 상태로 유지하지 못하면 프론트엔드가 backend로 더 보낼 수 없어 idle 상태가 됨
• 부동소수점 suite에서는 544.nab, 508.namd가 꽤 많은 core cycle 동안 루프 버퍼를 사용함
  • 508.namd는 평균 3.64 IPC의 high IPC workload라 프론트엔드 throughput 요구가 큼
  • 루프 버퍼 친화적이어서 op cache를 끄고 전력을 아낄 기회가 있음
• 루프 버퍼가 꺼지면 op cache가 더 많은 cycle 동안 코어를 공급함
  • 523.xalanbmk에서는 루프 버퍼 없이 op cache가 추가로 core cycle의 12% 동안 활성화되어야 함
  • 548.exchange2는 평균 4.31 IPC의 high IPC workload지만 루프 버퍼가 켜져도 거의 쓰이지 않고, op cache가 core cycle의 85% 이상 활성화됨
  • 508.namd에서는 op cache 활성 비율이 루프 버퍼 활성 시 56.67%에서 비활성 시 75.1%로 증가함
• 144 엔트리 루프 버퍼는 instruction stream의 많은 부분을 담기에는 작음
  • 프로그램이 실행 시간의 상당 부분을 작은 루프에서 보내고, backend throughput이나 latency에 묶이지 않을 때만 뚜렷한 효과를 낼 가능성이 있음

Cyberpunk 2077에서의 관측

• Cyberpunk 2077의 내장 benchmark로 루프 버퍼 비활성화가 게임 성능에 미치는 영향을 확인함
• 일관성을 높이기 위해 Ryzen 9 7950X3D에서 Core Performance Boost를 비활성화하고 모든 코어를 4.2GHz로 제한함
  • Hardware Configuration register MSR 0xC0010015의 bit 25를 설정함
  • RX 6900 XT는 2GHz로 제한함
  • benchmark 설정은 1080p, medium preset, upscaling 없음
• VCache die에 게임을 고정했을 때 루프 버퍼 비활성화는 성능에 거의 영향을 주지 않음
• non-VCache die에 고정했을 때는 루프 버퍼 비활성화 시 5% 성능 손실이 관측됐지만, 원인은 확인되지 않음
  • benchmark는 여섯 번가량 재실행됨
• Cyberpunk 2077은 평균적으로 instruction stream의 약 22% 를 루프 버퍼가 담당해 예상보다 루프 버퍼 친화적임
  • 루프 버퍼 비활성화 후 op cache의 마이크로-op 공급 비율은 62%에서 82% 로 증가함
• 이 게임은 루프 버퍼 비활성 시 평균 0.89 IPC, 활성 시 1.02 IPC로 high IPC workload가 아님
  • 프론트엔드 대역폭은 큰 고려 사항이 아님
  • backend bound이거나 branch predictor delay에 묶였을 가능성이 있음
• VCache die에서 실행할 때 성능 카운터는 루프 버퍼 활성 시 평균 1.25 IPC, 비활성 시 1.07 IPC를 보임
  • 새 BIOS에서 작은 성능 하락도 관측됨
  • 155 FPS 수준에서 GPU 측 병목에 더 가까워졌을 가능성이 있음

코어 전력 카운터 결과의 불확실성

• 루프 버퍼 실행이 전력 효율을 개선하는지 확인하기 위해 Zen 4의 core power counter도 살펴봄
• instruction bandwidth benchmark는 테스트 구간에서 CALL/RET를 쓰지 않도록 수정됨
  • CALL/RET가 있으면 Zen 4가 루프 버퍼를 사용하지 않기 때문임
• 테스트는 한 코어에 고정하고, 테스트 배열로 점프하기 전후의 Core Energy Status MSR을 읽어 평균 전력을 계산함
• Core Performance Boost는 전력 읽기가 크게 흔들려 비활성화함
• 이전 BIOS에서 Core Energy Status MSR은 op cache에서 NOP를 가져올 때 평균 6W, 루프 버퍼에서 가져올 때 훨씬 낮은 전력을 표시함
• 테스트 배열 크기를 L2 용량에 들어가는 128KB까지 늘려 op cache coverage를 1% 미만으로 낮췄을 때도 평균 core power가 1.5W로 표시됨
  • 디코더와 L2 fetch path 사용이 늘어야 하는 상황과 맞지 않는 결과임
• 새 BIOS에서는 op cache 테스트가 평균 1.68W, L2에서 디코더를 주로 공급하는 테스트도 거의 같은 전력으로 표시됨
• AMD의 전력 모니터링 기능은 실제 측정이 아니라 전력 모델링일 수 있음
  • BIOS 버전 사이에 모델링 방법이 바뀌었거나 전력 모델이 맞지 않을 가능성이 있음
  • 12V EPS 커넥터 등에서 직접 측정할 하드웨어가 없어 추가 검증은 이뤄지지 않음

비활성화 이유와 개발자 관점

• AMD가 Zen 4 루프 버퍼를 비활성화한 이유는 알려져 있지 않음
• CPU 기능은 하드웨어 버그 때문에 비활성화되는 경우가 있음
  • Intel Skylake의 루프 버퍼인 LSD는 SMT 두 스레드가 활성화된 짧은 루프에서 partial register access와 관련된 버그 때문에 비활성화된 사례가 있음
• Zen 4는 AMD가 고성능 CPU에 루프 버퍼를 넣은 첫 시도로, 첫 구현 기능의 검증은 어려움
• AMD가 내부적으로 외부에 드러나지 않은 버그를 발견해 예방 차원에서 루프 버퍼를 껐을 가능성이 있음
• 성능 영향은 op cache 대역폭이 충분하기 때문에 거의 없거나 매우 작을 것으로 보임
• 전력 영향은 알 수 없지만, 작고 측정도 어려울 수 있음
• AMD는 루프 버퍼를 Processor Programming Reference의 한 줄 외에는 거의 문서화하거나 광고하지 않음
  • Intel이 자사 loop buffer를 자주 문서화하고 개발자가 이를 활용하도록 최적화 가이드에서 권장하는 방식과 대비됨
• Zen 4 루프 버퍼는 낮은 용량과 CALL/RET 제한 때문에 op cache만큼 유용하지 않은 제한적 기능임
• 오래된 BIOS에서 Zen 4 루프 버퍼를 의식해 최적화한다면 다음 조건을 고려할 수 있음
  • 루프를 144 micro-ops 미만으로 유지함
  • 물리 코어를 두 스레드가 공유하면 그 절반 수준을 고려함
  • 작은 루프 안에서 호출되는 함수는 CALL/RET를 피하기 위해 inline을 검토함
• 이런 최적화를 해도 보상은 대부분 없을 가능성이 높음

[GN⁺]

Hacker News 의견들

• 이 기능이 공개되지 않은 하드웨어 취약점을 막으려는 시도로 비활성화된 건 아닐까 하는 추측이 듦

  • 글에서도 대체로 비슷하게 추측함: Zen 4는 AMD가 고성능 CPU에 루프 버퍼를 넣어본 첫 시도이고, 첫 구현의 검증은 항상 어려움
    AMD 내부에서 아무도 마주치지 않은 버그를 발견했고, 지나친 조심 차원에서 루프 버퍼를 껐다고 상상해도 무리는 아님. 코어 수명주기 이 정도 시점에 AMD가 Zen 4 프런트엔드를 건드릴 다른 이유는 잘 떠오르지 않음
  • 실제로는 더 많은 것이 비활성화됐을 수도 있음. 수치가 꽤 의외임: Cyberpunk 2077에서 VCache 다이로 실행할 때 루프 버퍼를 켜면 평균 IPC가 1.25, 끄면 1.07로 성능 카운터가 나타나는데도 새 BIOS에서는 약간의 성능 하락이 있음
    개인적으로는 마이크로코드 완화책 냄새가 나지만, 당연히 CVE를 기다려봐야 함
  • 조용히 비활성화하는 것도 큰 위험임. 문제의 심각성을 알고 있었고, 패치할 만큼 심각하다고 판단했다는 신호가 되기 때문임
    취약점을 공개하지 않으면 영향받는 쪽은 순수한 편집증 말고는 대응을 시작할 방법이 없음. 취약점 공개는 책임을 최종 사용자에게 넘기는 방법이기도 함. 업데이트 안 했으면 불평하지 말라는 식임. 공개가 제품 책임으로 이어지는 경우는 드물고, Meltdown이나 Spectre에서도 그런 책임 문제가 있었던 기억은 없음. 그래서 AMD가 일부러 숨기고 있다고 단정하진 않겠음
  • 정답인 듯한데, 더 말할 수는 없음 :(

• 글은 루프 버퍼가 성능 이득도 전력 이득도 없다고 시사하는 듯함
  그렇다면 “엔지니어 팀이 몇 달 동안 반짝이는 새 기능을 만들었지만 실제 이득은 없었고, 그래도 누군가 체면을 살리려고 출시했다”는 고전적인 경우일 수 있음. 소프트웨어 팀에서도 레거시 비대함을 없애고 성능을 올리겠다며 코드베이스를 다시 쓰자고 했다가, 끝나고 보니 코드 줄 수는 늘고 성능은 나빠지는 일을 봄. 두 경우 모두 출시하지 말았어야 함

  • 그래도 출시한 이유는 펌웨어 업데이트로 끌 수 있고, 설계 중간에 물리적 하드웨어 배치를 크게 바꾸면 더 나쁜 영향이 났을 가능성이 크기 때문임
  • 코어에 이미 들어간 뒤 별 도움이 안 된다는 걸 깨달았다면, 제거하는 것 자체가 분명한 위험임
  • 글에서도 전력 사용량을 전반적으로 측정하기 어려웠다고 했으니, 이 기능이 아무 영향도 없다고 결론내릴 수는 없고 사실 그래선 안 됨
    AMD 엔지니어링 팀이 아무 가치 없는 하드웨어 기능에 면적과 전력을 쓰도록 둘 만큼 원칙 없다고 보기는 어렵고, 여기서는 Chips 'n Cheese가 영향을 측정하지 못했을 가능성에 무게를 두고 싶음
  • 꽤 유명한 하드웨어 회사에서 일하는데, 소프트웨어 쪽은 일부 좁은 사용 사례나 표적 벤치마크 말고는 이득이 충분히 입증되지 않은 일이라도 뭔가를 하는 것에 집착하는 중임
    매우 답답하지만, 아무도 사전 조사를 할 시간을 들이려 하지 않음. 새 프로젝트를 밀고 가는 편이 상층부를 만족시키고 질문을 덜 받기 쉬움
  • 전력 벤치마크가 정확하다는 다른 가능성도 있음. 버퍼가 전력을 아꼈지만, 이후 마이크로코드 수준에서 일반 경로가 더 전력을 아끼게 하는 더 나은 최적화를 찾아내서 버퍼가 오히려 전력 먹는 장치가 됐을 수 있음

• 글에서 가장 흥미로운 문단은 이 부분임: Zen 4의 루프 버퍼를 보는 가장 좋은 관점은 AMD에 엔지니어들이 뭔가 시도해볼 여유 역량이 있다는 신호라는 것
  이번에는 성과가 없었을지도 모르지만, 엔지니어들이 낮은 위험과 낮은 영향의 기능으로 실험하게 하는 건 자신감을 쌓는 좋은 방법임. 앞으로 그런 자신감을 더 많이 보게 되길 기대함

• “이상하게도 non-VCache 다이에 고정하면 루프 버퍼 비활성화 시 게임 성능이 5% 떨어진다. 이유는 모르겠다”는 부분은, 더 세밀한 전력 측정이 있다면 열/전력 예산 관련인지 판단할 수 있지 않을까 싶음
  이 기능은 전력을 아끼려는 의도로 보이기도 함

  • 여기서는 세부 정보가 충분하지 않음. Ryzen 칩의 두 번째 CCD는 non-X3D 칩에서도 첫 번째보다 선별 품질이 낮고, 칩마다 모두 다름
    내 non-X3D 칩의 CCD0 코어 대부분은 5.6~5.75GHz까지 가지만, CCD1 코어는 5.4~5.5GHz에서 끝남. Zen 4의 V-Cache 칩은 클록 페널티가 크지만, 캐시가 그 이상을 보상함. 같은 칩의 CCD1에서 기능을 켠 상태와 끈 상태를 모두 테스트했는지, 보안 수정 같은 다른 변화를 분리하려 했는지 봐야 하는데, 글에서는 스스로 “아니오”라고 인정함. 제대로 하려면 기능이 켜진 BIOS에서 이 기능만 끄는 방법을 찾아 같은 칩에서 양쪽을 테스트해야 하고, 그래도 다른 분기 조건 때문에 결과가 정확하지 않을 수 있음. 전체 성능 프로파일이 있으면 정확도가 올라가겠지만, 아마 AMD 엔지니어만 할 수 있을 듯함
  • 테스트한 두 UEFI 버전 사이 어딘가에서 비활성화됐다고 했음. 다른 변경도 포함됐을 테니, 측정은 엄밀한 A/B 테스트가 아님

• 실제 차이를 만들기에는 너무 작았고, 아주 특정한 상황에서만 의미가 있었던 듯함. 더 크게 만들면 이득에 비해 구현 비용이 너무 컸을 것 같음
  그렇다고 해도 일부 작업부하에서는 약간의 회귀가 있겠지만, AMD는 출시 이후 작은 성능 개선도 해왔음. Zen 4에서는 그냥 BIOS 옵션으로 만들었어야 함. 그렇게 하지 않은 듯하다는 점은 버그나 보안 문제 가능성을 시사함

  • 사용자 대부분이 못 알아차리지만 프런트엔드를 복잡하게 만드는 기능을 조용히 비활성화했다는 건, 하드웨어 버그 공개를 피하거나 늦추면서 완화책은 이미 배포하려고 이 치킨 비트를 당겼다는 느낌임. 빌어먹을 벤더들, 언제쯤 배울까

• 일화적으로 1979년 68000과 1982년 68010의 몇 안 되는 차이 중 하나가 “loop mode”, 즉 6바이트 루프 버퍼 추가였음

  • 훨씬 더 중요한 건 MMU 지원을 고친 점임. 원래 68000은 페이지 폴트에서 복구하는 데 필요한 일부 상태를 잃어버렸고, 우회책은 추하고 비쌌음
    CPU 두 개를 한 사이클 어긋나게 실행하고 두 번째 CPU에 복구 가능한 인터럽트를 주입하는 방식이었음. 그래도 MMU가 있고 32비트 명령어 집합, 24비트 주소 버스를 가진 CPU를 원한다면 당시 대안보다 쌌던 모양임. 정말 거친 시기였을 듯함
  • 흥미로움. 작은 루프 버퍼로는 GreenArrays forth 코어가 꽤 마음에 듦
    18비트 워드 하나에 명령어 4개가 들어가고, 한 연산코드는 루프 카운터를 감소시킨 뒤 워드 시작으로 돌아감. 그럴 때 꽤 더 빠르게 실행될 수 있음
  • 68010의 루프 버퍼는 거의 쓸모없었음. 6바이트뿐 아니라 명령어도 두 개만 담았기 때문임
    그중 하나는 루프 명령어(DBcc)여야 해서 루프 본문은 단일 명령어여야 했음. 실제로 빨라질 수 있는 건 최적화 안 된 memcpy 정도가 거의 전부였음

• Cortex-A15에서는 이게 핵심 설계 기능이라는 점이 흥미로움. 다른 칩에서 효과 수치가 있는지 궁금함
  콘솔처럼 설계 수명이 더 긴 장치에서는 최소한 최적화 대상으로도 쓸 수 있을 것 같음

  • 나도 궁금함. 어떤 RISC 아키텍처든 루프 버퍼에서 얻는 이득은 비교적 작을 거라고 예상함
    RISC의 요지는 명령어 가져오기와 해독이 훨씬 쉽거나 거의 사소하다는 데 있으니까

• 7950X3D를 갖고 있는데, Skylake 6700K에서 업그레이드한 것임. 무의식적으로 하드웨어 루프 버퍼가 소프트웨어로 비활성화된 칩에 끌리는 모양임

  • 언젠가 새 머신을 살 거라면 미리 알려주면 좋겠음. 우리가 피할 수 있게!

• 흥미로운 글인데, 루프 버퍼가 다이에서 얼마나 많은 공간을 차지하는지 모르겠음
  향후 칩에서 제거한다면 그 공간을 더 큰 L2 캐시 같은 더 유용한 데 쓸 수 있는지 궁금함

  • 최신 칩 대부분은 바닥 면적보다 배선 제약이 더 크다고 봄. 기능은 엄청 많이 만들 수 있지만, 거기에 전력과 정규화된 신호를 모두 공급하는 일이 정말 고역임
  • 내 이해로는 프런트엔드의 꽤 작은 최적화임. 애초에 항목이 많지 않고 144개라서 절약되는 공간은 아마 미미할 것임
    이론적으로 루프 버퍼는 타이트한 루프에서 전력을 아끼거나 성능을 올릴 수 있음. 실제로는 둘 다 못 하는 것처럼 보이고, AMD는 Zen 5에서 완전히 제거했음
  • 도표를 보면 루프 버퍼는 어차피 존재하는 마이크로 연산 큐와 같은 저장 공간을 쓰는 듯함
    그게 맞다면 그럴듯하고, 면적 비용은 추가 제어 로직 정도임. 가장 비싼 부분은 애초에 루프를 감지하는 일일 것 같지만, 큐 크기에 비하면 꽤 작을 듯함
  • 코어당 144개 마이크로 연산 항목이라고 되어 있음. 몇 바이트인지는 모르겠지만, 요즘 L2 캐시는 코어당 약 1MB라서 루프 버퍼 다이 공간이 대부분 저장소라고 가정해도 눈에 띄는 차이는 없을 것임

• “전력” 섹션의 분석은 초당 실행 명령어 수로 나누지 않은 것처럼 보임
  이 루프 버퍼의 이점을 보려면 초당 에너지, 즉 전력(와트)이 아니라 명령어당 에너지를 봐야 할 가능성이 거의 확실함

  • 명령어마다 걸리는 클록 사이클 수가 다르고, Zen 4에서 Zen 5 같은 아키텍처 세대 사이에서도 달라짐. 그래서 작업부하가 정확히 같은 사이클당 명령어 수를 만들지 않는 한 실현 가능하지 않은데, 멀티스레딩과 작업 처리 때문에 불가능함
    순서와 RAM 내용조차 모든 걸 바꿀 수 있음. 켠 경우와 끈 경우를 수백 번 실행해 어느 정도 분리할 수는 있지만, 시간이 엄청 들고 그래도 100% 정확하지 않음. 기능을 끄는 것만으로도 코드가 다른 분기를 타서 모든 배치가 달라질 수 있음. 이 문제를 구체적으로 아는 건 아니지만, 기능을 끄자 부하가 정수 유닛에서 FPU나 GPU로 이동하거나, 명령어 5개가 사라지는 대신 2개가 추가되는 사례를 본 적이 있음