AMD ZEN 마이크로아키텍처

2016년 8월 17일에[1] 정식으로 발표된 엑스카베이터의 후속 마이크로아키텍처. (발표 내용) GlobalFoundries의 (글로벌파운드리의 14nm FinFET공정이 삼성에서 돈내고가져온것이니 삼성의 14nm 공정이라고 하는것도 맞다) 14nm FinFET 공정에서 생산된다. 데스크톱 프로세서의 소켓이 모두 AM4[2]로 통합되었으며, DDR4 SDRAM, USB 3.1 10Gbps, NVMe 등의 최신 규격 지원과 노스/사우스 브리지가 프로세서에 통합되고 인텔 PCH(Platform Controller Hub)와 비슷한 프로몬토리(Promontory) 칩셋이 사용된다. #

2. 상세

2.1. ZEN 마이크로아키텍처

[image]
위의 이미지는 2016년 8월 23일 Hot Chips 28 두 번째 날에 발표된 ZEN 마이크로아키텍처 관련 슬라이드로, 자세한 내용은 HOT CHIPS 공식 홈페이지에서 열람할 수 있다.
WIKICHIP의 ZEN 마이크로아키텍처 상세 정보 (영문)

2.1.1. 설계

과거 AMD의 전성기를 이끈 K7과 K8 마이크로아키텍처의 설계에 참여하였던 짐 켈러가 설계를 맡았다.
참고로 짐 켈러는 계약 기간이 끝난 후 2015년 9월에 AMD에서 퇴사했었다. 짐 켈러의 이런 행동에 대해서 논란이 약간 있었는데, 짐 켈러의 경력 자체가 기반을 구축하거나 전반적인 문제를 해결해주고 바로 다른 데로 떠나는 스타일이라는 주장이 있다. 그리고 미국쪽에서는 이런 고용계약이 매우 보편화가 되어서 문제가 전혀 되지 않는다. AMD CPU의 역사상 전성기였던 K7, K8 개발에 참여했던 시절에도 정작 K8이 사용된 애슬론 64 시리즈가 출시될 때에는 AMD에 없었다. 짐 켈러는 애슬론 64 시리즈 출시 시기에 저전력 모바일 프로세서 개발하는 업체로 이직했는데, 이 회사는 애플에 인수되어 A4/A5 칩 설계를 맡으며 애플 자체설계 AP의 초석을 닦았다.[3]
여튼, 짐 켈러가 AMD로 복귀하여 만든것이 바로 이 ZEN 마이크로아키텍쳐이다.
불도저부터 엑스카베이터 마이크로아키텍처까지 사용되었던 모듈(클러스터) 기반 멀티스레드(CMT) 방식을 '''완전히 버렸다.''' 원점에서 전체 아키텍처를 다시 설계했으며, 과거 K7부터 K10 마이크로아키텍처까지의 전통적인 구조로 회귀하는 방향으로 설계했다. 각 부분의 구성 요소들은 기존에 최대한 검증된 방식을 사용하여 리스크를 억제하려고 했는데, 대표적인 부분으로 경쟁사 인텔이 성공적으로 도입하여 적용중인 코어당 2-way SMT와 uOP 캐시, 저전력용인 자사의 밥캣 마이크로아키텍처 등에 이미 도입하였던 신경망 기반 분기 예측 기능을 들 수 있다. 또한 설계 당시부터 성능/전력소모/크기의 3요소간의 균형을 맞추면서 각 요소를 극대화 하는 방향으로 설계 방향을 잡았다.

2.1.2. 성능

[image]
AMD에서 공식 발표한 바에 따르면 엑스카베이터 대비 IPC(Instructions Per Cycle)를 '''40%''' 향상을 목표로 했으며 결과적으로 '''52%'''의 향상을 이루어 냈다.
초기에 기존 CPU 대비 40% 향상이 목표라고 알려졌을 때에는 파일드라이버에 단순히 1.4배를 곱하여 대략 경쟁사의 3세대 아이비브릿지 수준의 성능일 것으로 전망하였으나, 이후 파일드라이버 기준이 아닌 엑스카베이터[4] 기준 40% 향상인 것으로 밝혀지면서 브로드웰 급으로 기대치가 상승하였으며 이후 엠바고가 풀리고 공식 발표에서는 목표인 40%를 뛰어넘어 52%의 IPC 향상을 달성했다고 발표되었다.
2017년 3월에 성능향상폭에 대해서 보다 구체적인 사항이 발표 되었는데 전체적으로는 엑스카베이터 대비 52% 올라간 것이 공식적으로 발표 되었다. 보다 세부적인 향상률은 다음과 같다.

SPECInt_base2006기준 정수연산 향상률 : 파일드라이버 대비 52%, 엑스카베이터 대비 64%[5]
오타가 아니다. 실제 자료에 그렇게 명기되어 있다.
상승.
Cinebench15 단일스레드 실행 기준 벡터연산[6]
Cinebench15는 벡터명령어인 SSE명령에 크게 의존적이다.
향상률 : 파일드라이버 대비 76%, 엑스카베이터 대비 64% 상승.

즉 어느 숫자를 보더라도 52%는 여러 케이스 중에서 가장 낮은 수치인 것이다.
재미있는 건 인텔이 발표한 제온 스케일러블 시리즈의 최대 코어는 28코어이고, AMD가 발표한 EPYC 시리즈의 최대 코어는 32코어인데, 둘을 같은 면적이라고 가정하면 코어당 14% 정도의 차이가 나온다. 그리고 스카이레이크에서 10-15% 가량을 줄이면 브로드웰이다.[7]
데스크톱 라인업인 서밋 릿지인 경우, 불도저에서 이어져 온 4모듈-8코어-8스레드 구성에서 8코어-16스레드 구성으로 바뀌면서 스레드 기준 2배가 증가하게 된다. 이런 구성이면 양쪽 클럭이 동일하다고 가정할 경우 스카이레이크 기반 4코어-8스레드 코어 i7 시리즈에 대해서 싱글스레드 성능은 불과 10% 정도 떨어지지만 멀티스레드 성능은 2배에 달하는 코어 숫자를 이용해 1.7~1.8배 정도 우위를 점하면서 제품경쟁력을 높일 수 있다.
AMD의 공식 발표에 의하면 Blender에서 Intel Core i7-6900K와 AMD RYZEN 7 1800X (추정)의 같은 코어 개수, 같은 스레드 개수, 같은 3GHz 클럭 환경에서 근소하게 앞서는 클럭당 성능을 보여주고 있어, 추후 QS이후의 리테일 제품의 클럭이 성능을 결정 지을 것으로 보인다. 하지만 해당 테스트에 관해서 인텔 엔지니어인 François Piednoël은 'FMA3 명령어로 실행하는 것으로 보이며, L1, L2, L3 캐시의 사이즈가 다르므로 IPC 비교는 무의미하다'는 글을 올렸다. 하지만 '''브로드웰은 FMA3명령어를 256bit데이터폭으로 동시에 두 개, 2배의 스루풋으로 처리할 수 있는데 비해 ZEN은 FMA 명령어를 128bit 데이터폭으로 동시에 처리할 수 있어서''' 단순 스루풋 기준으로는 '''브로드웰이 두 배로 빨라야 정상이다.''' 게다가 브로드웰의 캐시 데이터폭은 ZEN의 두 배로 정확히 FMA3 명령어의 입출력값을 뒷받침해 줄 수 있도록 확장되어 있다. 즉 Blender의 코드가 FMA3명령어 의존적이라는 주장이 맞다면 오히려 ZEN의 FMA 연산에서의 아키텍처 효율이 단순 스펙에서 드러나는 것 보다 훨씬 더 좋다는 이야기가 된다. 캐시사이즈가 달라서 IPC측정으로서는 의미 없다는 주장 자체가 큰 의미가 없는데 애초에 성능 위주의 프로그램들은 캐시 미스로 인한 패널티를 피하기 위해 각 단계별 캐시 크기에 맞도록 코드나 데이터 사이즈를 조정해서 로드하는 경우가 많으며 캐시대역폭 역시 브로드웰이 두 배이다.
결국 ZEN이 실제로 공개되고 난 이후 ZEN의 여러 벤치마크 성능이 클럭대 클럭으로도 브로드웰과 동급이라는 것이 밝혀진 후로는 저러한 장황한 설명이 무의미해지고 말았지만...

2.1.3. 프론트엔드

2.1.3.1. 신경망 예측기 (Neural Net Prediction)

ZEN의 분기 예측 기법에는 이전의 Bobcat 아키텍처에도 적용된 적이 있던 신경망 기반의 분기 예측기가 적용되었다.[8] 분기된 예측 주소를 유지하는 BTB(Branch Target Buffer), 간접 분기에 관련된 512엔트리의 ITA(Indirect Target Array), 32엔트리의 반환 스택(Return Stack), 해시 퍼셉트론 테이블(Hash Perceptron Table)의 조합으로 구현되었으며, 신경망 기법 중 가장 기본적인 퍼셉트론 기법이 적용되어 신경망의 특징 답게 코드 상의 분기 패턴을 반복 학습하면서 분기 예측 적중률이 높아진다고 한다.
특징적인 부분으로는 타 분기 예측 기법 역시 분기 예측 적중률은 신경망과 대동소이하나 목표로 하는 적중률이 어느 정도 이상 높아지면 분기 예측 회로 구현에 필요한 로직이 신경망에 비해 복잡해지면서 상대적으로 회로 구현에 필요한 투입 비용과 전력 소모가 커지고 실장 면적 역시 늘어나게 된다. 즉, 신경망 분기 예측기는 저전력 분기 예측기를 만들 때 적합하다.
AMD에서 발표한 SenseMI의 5가지 기능 중 3가지가 전력 및 클럭제어, 2가지가 코드 및 데이터 예측기법에 관련된 내용이다. 2018년 인텔 CPU 보안 버그 유출 사태에서 드러난 인텔 P6 마이크로아키텍처 계보의 모든 아키텍처(코어, 네할렘, 샌디브릿지, 하스웰, 스카이레이크)에서 캐시메모리 분기 예측 멜트다운 버그로 인해 반대급부로 주목받고 있다. 하술할 내용과 같이 젠은 인텔 코어나 애플 실리콘(A 시리즈)과는 달리 짧은 분기 예측을 반복 수행하여 효율성을 올린다. 이건 원래 하이엔드, 모바일, 서버를 동시에 노려야 하는 돈 없는 AMD의 사정이 반영된 선택이었지만, 이게 오히려 한참 앞서간 분기 예측 내용을 빼내는 멜트다운의 악용을 막는 방향으로 얻어 걸린 것이다.[9]
AMD에서는 해당 기능을 ZEN 아키텍처의 IPC를 향상시키는 중요한 기능 중 하나로 소개하고 있으며, IPC가 크게 향상된 ZEN 2 아키텍처에서도 매우 중요한 기능 중 하나로 소개하고 있다.

2.1.3.2. 스마트 프리페치 (Smart Prefetch)

스마트 프리페치는 AMD에서 구현한 데이터 프리페치 기법을 지칭하는 단어로 쉽게 말해 실행코드가 필요한 크리티컬 데이터를 실행코드에서 요청하기 이전에 미리 데이터캐시에 적재하는 기법을 칭한다.
데이터 프리페치 기능은 제대로 동작했을 경우 L1 데이터캐시의 레이턴시 4클럭 이후 크리티컬 데이터의 이용이 가능하지만 프리페치에 실패했을 경우 DRAM에 있는 크리티컬 데이터를 불러오기 위해 L1레이턴시 + L2레이턴시 + L3레이턴시 + DRAM 액세스 레이턴시 까지 합쳐 수십클럭을 소모하며 그 동안 CPU는 아무런 동작도 안하는 상황이 된다. 따라서 데이터 프리페치 기능은 현대 CPU 설계에 중요한 부분을 차지한다.
AMD는 스마트 프리페치의 기능을 크게 두 가지로 설명하는데 첫번째는 코드 선행 분석을 통한 미래 데이터 액세스 위치를 예측한다고 하고, 두 번째는 학습 알고리즘을 사용하여 데이터 액세스 패턴을 파악한다고 한다. 해당 학습 알고리즘에도 분기예측과 같은 신경망 기법이 적용되었는지는 확인되지 않은 상황.

2.1.3.3. 명령어 디코드

[image]
ZEN의 명령어를 해독해줄 디코더는 그림과 같이 클럭당 최대 4개의 x86명령어를 디코딩 할 수 있으며 이는 불도저 아키텍처의 초기 버전과 동일하고 인텔 하스웰/브로드웰의4명령어/clock과는 동급, 스카이레이크의 6명령어/clock에 비해서는 떨어진다.[10]
디코딩 유닛의 큰 특징 중 하나는 x86명령어를 이른 시기에 세부 uOP로 쪼개는 기존 아키텍처와는 달리 대부분의 x86명령어를 단일한 32bit 고정길이의 고밀도uOP[11]로 변환한다는 점이며 이러한 특징은 전력소모 억제를 우선하는 아키텍처에서 많이 찾아볼 수 있다.
ZEN에서의 uOP의 흐름은 정수 유닛과 벡터/실수 유닛으로의 uOP 전달 포트가 통합되어 있는 인텔과는 다르게 uOP 디스패치 단에서 일찌감치 정수 uOP와 벡터/실수 uOP가 각각의 파이프라인으로 분리되어 처리된다. 이러한 분리형 파이프라인은 K7로부터 내려온 전통적인 AMD의 설계 방식으로, 정수부/벡터부 각각의 명령어 스케줄러의 오버헤드를 줄일 수 있다는 장점이 있는 반면 정수부의 파이프라인에 할당된 명령어와 벡터부에 할당된 명령어간의 연관성이 발생할 경우 그 값들을 수평전달하기 위해서 1사이클 정도의 레이턴시를 감수해야 한다.

2.1.3.4. 디스패치

uOP 디스패치(보내기) 능력은 정수uOP의 경우 6 uOP/clock, 벡터/실수uOP의 경우 4 uOP/clock이다. 즉 uOP 동시 처리능력만 놓고 보면 경쟁사의 하스웰/브로드웰 아키텍처의 4uOP/clock 넘어 6uOP/clock인 스카이레이크 아키텍처와 유사한 수준. 거기에 ZEN의 uOP는 상기한 바와 같이 명령어의 밀도가 높기 때문에 실질적인 스루풋은 그보다도 더 높을 가능성조차 있다. 더군다나 ZEN은 정수uOP와 벡터/실수uOP를 동시에 각 스케줄러로 디스패치 할 수 있으므로[12] 동시 디스패치 능력은 스카이레이크를 넘어선다. 다만 보통은 정수명령과 벡터/실수명령이 동시에 섞여서 들어오는 경우는 적기 때문에 현실적인 디스패치 속도는 정수부 6uOP/clock 벡터부 2+4uOP/clock[13]정도이다. [14]

2.1.4. 백엔드

2.1.4.1. 리타이어

연산이 완료된 uOP는 퇴출(Retire)부에서의 최대 8 uOP/Clock의 속도로 퇴출된다. 6 uOP/clock 정도인 동시 디스패치 수에 비해 동시 퇴출수가 더 많은 이유는 처리가 완료된 uOP들을 최대한 빨리 퇴출시켜야 디스패치단에서 들어오는 새로운 uOP를 위한 빈 자리를 만들면서 병목현상을 막을 수 있기 때문이다.
인텔에서는 리오더 버퍼(Reorder Buffer)의 리타이어먼트(Retirement) 기능에 대응된다.

2.1.4.2. 정수부

정수 및 메모리 입출력 uOP가 디스패치 유닛으로부터 클럭당 최대 6개까지 디스패치(파견)되면 레지스터 리네이밍[15] 단계를 거쳐 각 4개의 정수연산유닛과 2개의 로드-스토어 유닛에 각각 1개씩 할당된 uOP 스케줄링-큐 에 uOP가 할당된다. 각 정수uOP 스케줄링-큐 는 uOP를 14개 엔트리에 각각 적재할 수 있으며 스케줄러는 각 큐의 엔트리에 적재된 uOP를 검사하여 비순차 실행이 가능한 순서로 정렬하여 각 정수유닛으로 보내게 된다. 즉 개개의 uOP를 어떤 정수/로드스토어 유닛에서 실행할 것인지 여부는 레지스터 리네이밍 단계에서 우선 결정되어 각 큐에 들어가고, 그 이후 스케줄러가 각 큐 내의 uOP의 실행 순서만 조정한다는 단계적 방식을 통해 비순차 uOP 동시실행을 구현하게 된다.
정수 실행부의 경우 불도저의 코어당 2개 대비[16] 4개로 늘어난 정수 유닛(ALU)과 2개의 로드&스토어 유닛(AGU)으로 구성되어 4+2 구조이다. 즉 정수 실행유닛 4개는 연산능력에 있어 역시 정수유닛이 4개 있는 하스웰 이후의 인텔 정수 실행부의 규모와 유사하다.

4개의 정수 유닛은 연산기능이 거의 동일하여 대부분의 정수명령어들을 처리할 수 있으나 예외적으로 MUL(곱셈)연산기능 1개, DIV(나눗셈)연산기능 1개, BR(분기명령어)기능 2개, CRC32연산기능 1개가 각 유닛에 분산 배치된다. 즉 대부분의 정수명령은 1클럭당 4개씩 처리가 가능하지만 위에서 열거한 명령어들은 한 번에 1개씩 밖에 처리할 수 없으며 명령 실행 결과가 나오기 까지 수 클럭이 소모되는데 대부분의 간단한 정수명령어는 처리에 1클럭이 필요하지만 곱셈이나 나눗셈 등은 로직상의 처리가 매우 복잡하여 정수 유닛의 설계 역시 복잡해진다. 때문에 대부분의 현대적인 슈퍼스칼라 정수 실행부 설계에서는 복잡한 명령어에 대한 실행 유닛은 1개 정도로 억제하는 경우가 많으며 이는 다른 마이크로아키텍처에서도 일반적으로 볼 수 있는 현상이다.

2.1.4.3. 실수/벡터부

ZEN의 실수/벡터부는 2개의 128비트 FADD 유닛과 2개의 128비트 FMUL/FMAC 유닛으로 구성되어 초기 불도저와 유사한 2+2의 구조로 회귀하였으며 불도저 아키텍처에서는 초기 불도저 이후 스팀롤러에서 부터는 2+1 구조로 축소되었다. 초기 불도저 아키텍처는 2개의 128bit FMUL/FMAC 유닛과 2개의 128bit 벡터 정수연산유닛(Vector ALU)으로 구성된 구조라서 뒤의 2개 유닛은 실수연산 능력이 없었던 반면 ZEN에서는 네 유닛 모두 실수/벡터 연산이 가능하도록 기능이 확장되었다.
다만 공식 발표된 블록다이어그램상의 표기 상으로는 벡터유닛의 파이프라인 구조가 2+2의 대칭구조를 가지고 있는 것으로 되어 있지만 실제 유닛들이 담당하는 기능은 대칭적이지 않다. 예를 들어 벡터정수덧셈의 경우 FPU0, FPU1, FPU3 세 유닛이 동시에 처리 가능하고 벡터실수덧셈은 FPU2, FPU3이 동시 처리 가능, 벡터실수곱셈은 FPU0과 FPU1이 실행하게 되어있는 등 사실상 비대칭이며 이는 차라리 기존 K7/K8/K10에서의 실수유닛의 구조였던 FADD/FMUL/FMISC의 비대칭 구조의 확장에 가깝다.
다만 ZEN의 실수/벡터부가 이렇게 비대칭적 구조를 가지고 있어도 연산에 필요한 레이턴시나 실제 코드에서의 명령어 혼입을 고려하면 최대 동시에 128bit 데이터폭으로 명령어 4개를 수행하는 것이 가능하며 이는 하스웰 이후의 인텔 아키텍처의 실수/벡터부의 2+1 구조의 256bit 벡터유닛의 연산능력과 비교해도 연산 대상과 그 시나리오에 따라 앞서거니 뒷서거니 할 수 있는 수준으로 예상된다[17].
6개로 분할된 정수부의 명령어 스케줄링 큐와는 달리 실수/벡터부의 명령어 스케줄링 큐는 단일구조로 스케줄러로 이루어져 있으며 해당 스케줄링 단계에서 네 개의 벡터유닛이 선택되어 uOP가 uOP포트를 통해 공급되는 구조이다. 스케줄링 큐 내의 총 엔트리 수는 96개이다.
독특하게도 실수/벡터부의 명령어 큐는 스케줄링 큐와 논-스케줄링 큐의 2단계로 분리되어 있는데 굳이 단계만 차지하는 듯 보이는 논-스케줄링 큐는 uOP의 전달을 일률적으로 지연시켜서 정수부의 로드/스토어 유닛에서 로드되는 메모리 값들이 실수/벡터부 레지스터로 전달되는는 시간간의 타이밍을 맞추기 위해서라고 한다.

2.1.4.4. 로드/스토어 유닛

정수부에 포함된 메모리 액세스를 위한 메모리 어드레스를 계산하는 2개의 AGU(Adress Generation Unit)와 그에 연계된 2개의 로드/스토어 유닛을 통해 메모리 로드/스토어 명령을 처리하며 클럭당 2개의 로드 명령어를 동시에 실행, 혹은 스토어 명령어를 동시에 실행할 수 있다. 해당 유닛은 정수부에 소속되지만 실수/벡터 유닛에 필요한 메모리 내용을 읽기/쓰기 하는 역할도 하므로 2개의 유닛이 클럭당 2개의 128bit 값을 메모리로부터 읽을 수 있으며 쓸 때에는 1개의 유닛이 1개의 128bit값을 쓸 수 있다.
로드/스토어 유닛의 데이터폭 크기가 굳이 128bit인 이유는 4개의 실수/벡터 유닛의 처리 폭 자체가 SSE계열 명령어가 사용하는 XMM레지스터의 데이터폭 128bit로 제약되기 때문이다.
해당 부분을 하스웰 이후의 인텔 마이크로아키텍처와 비교하면 인텔의 경우 ZEN과 유사하게 2개의 로드+스토어 유닛을 가지고 있으나 그에 더하여 상황에 따라 제한적으로 사용할 수 있는 스토어 유닛 2개가 더 추가되어 ZEN의 2 구조에 비해 2+1+1 구조를 가진다. 즉 메모리 로드/스토어 명령어 처리에 있어서는 ZEN 대비 상당한 우위가 예상된다.
그에 더해 하스웰 이후부터의 인텔의 벡터 유닛은 AVX/AVX2 명령어 레지스터폭에 맞게 유닛당 256bit까지 증가하기 때문에 2개의 로드&스토어 유닛이 각각 256bit의 메모리 데이터를 로드하여 클럭당 총 512bit를 레지스터로 로드할 수 있다. 이는 ZEN 대비 2배의 입출력 대역폭이다. 다만 메모리 입출력 대역폭이 2배라고 해서 전체 연산속도가 2배는 아닌 것이 기본 레지스터폭이 256bit인 AVX계열 명령어 처리에서 조차도 메모리-메모리간 연산에 비해 레지스터-레지스터간 연산이 비율이 높아질 경우 실제 메모리 입출력 빈도는 그만큼 낮아지게 된다.

2.1.5. 캐시 및 메모리 계층 구조

불도저 대비 전반적인 캐시 레이턴시와 대역폭이 개선되었다. L1/L2캐시의 레이턴시가 개선되어 FPU명령에 필요한 데이터 로드 레이턴시는 9사이클에서 7사이클로 2사이클 개선, L1/L2의 대역폭은 거의 32Byte/clock로 거의 2배로 증가하고 L3의 대역폭 역시 32Byte/clock인데 이는 거의 5배로 개선된 수치이다.
캐시 용량과 특성을 보면 L1-명령어 캐시가 64KByte/4way이고 L1-데이터 캐시가 32KByte/8-way로 확대 되었다. L2 캐시는 총 512KByte로 8-way구조이다.
캐시 방식은 인텔과 유사하게 uOP 캐시 + exclusive L1캐시 + inclusive L2 캐시를 채택하였다.[18] 또한 모듈 설계의 영향으로 두 개의 정수부 코어가 공유하던 L2 캐시 역시 코어마다 독립적으로 할당되며, 전작인 불도저의 비효율적인 write-through방식에서 벗어나 write-back 방식을 채택하였다.
L3 캐시는 8MByte 16-way로 CCX(Core Complex) 내의 4개 코어가 공유한다. L3 캐시의 방식은 inclusive한 L2 캐시와는 달리 victim 방식으로 거의 exclusive 방식에 가깝다. 즉 L2 캐시 영역의 내용이 갱신되면서 퇴출된 데이터들이 L3 캐시 영역으로 밀려나며 자연스럽게 L2의 내용과 L3의 내용이 중복되지 않는다. 때문에 ZEN의 개발사인 AMD는 CCX 내의 캐시 용량을 코어 당 1개씩 할당된 512KByte L2 캐시와 8MByte의 L3을 합쳐 10MByte의 L2 + L3 캐시 용량으로 소개하고 있다. 사실 victim 방식은 전세대인 불도저 아키텍처에서도 사용했던 방식이지만 상술한 바와 같이 대역폭은 5배로 증가하면서 기존의 대역폭 약점은 사라진 상황.
특히 4코어로 이루어진 CCX 내에서 공유 캐시메모리 역할을 하는 L3 캐시는 8MByte의 L3 캐시를 1MByte로 각각 분할하여 하위 메모리 어드레스 기준으로 interleaving기법을 사용하여 각 코어에서부터 L3 캐시로의 평균 접근 레이턴시를 거의 동일하게 만들었다.
이 캐시 구조에서 젠1/+ 특유의 구조가 나오는데, L3가 코어를 둘러싸는 기존의 코어들과는 달리 젠은 각 CCX에서 코어가 L3를 둘러싸는, 반대로 생각해 보면 L3를 중심으로 코어를 양쪽에 붙여둔 구조가 나온다. 요컨대 L2에서 넘쳐나 흘러들어온 데이터를 다른 코어에서도 최대한 끌어쓸 수 있도록 조치를 해둔 것인데, 전통적으로 코어 양 옆에 L3를 배치하는 방식을 사용하면 한 코어가 다른 코어의 L3에 접근하기까지 시간이 너무 오래 걸리기 때문에 이를 해결하기 위한 대안이라 할 수 있다. 대신 그만큼 코어 간의 간격이 벌어지고 서로 다른 CCX에 있는 데이터는 인피니티 패브릭을 통해서 주고받아야 하기 때문에, 게임 등 레이턴시가 중요한 작업에서 젠의 발목을 잡는 부분이라고도 할 수 있다. 하지만 어쨌든 불도저의 끔찍한 캐시 구조와는 비교할 수 없을 정도로 장족의 발전을 이루었으며, 젠2 및 향후 리비전에서 가장 큰 발전을 기대할 수 있는 부분이기도 하다.

2.1.6. 2-way SMT (양방향 동시 멀티스레딩)

ZEN에는 AMD 최초로 인텔의 Hyper-Threading 기술과 같은 방식인 코어당 양방향(2-way) SMT 기능이 구현되었다.[19] 양방향 SMT 자체는 불도저 마이크로아키텍처부터 부분적으로나마 도입된 적이 있었지만 인텔의 하이퍼스레딩처럼 완전한 양방향 SMT라고 보기 어려운 CMT였기 때문에, 제대로된 양방향 SMT로써는 ZEN부터라고 볼 수 있다.
ZEN 내부의 모든 구조들은 단일스레드 모드에서 빠짐없이 사용 가능하며 프론트-엔드 큐 는 라운드-로빈 방식으로 각 구조들의 사용 순서를 결정하며 필요할 경우 순서를 오버라이드 할 수도 있다.
ZEN의 코어당 양방향 SMT 효율은 Cinebench R15 멀티스레드 모드에서 측정한 결과 실행 속도가 약 40.6% 향상되어 2002년 Prestonia 계열 제온 시리즈, 펜티엄 4 HT 3.06 이래로 15년 동안 지속적으로 개발해 온 인텔 하이퍼쓰레딩의 15~30%보다도 오히려 효율이 앞서게 되었다. 그 결과 처음으로 코어당 양방향 SMT를 개발 했음에도 불구하고 굉장히 잘 만들었다는 평가가 주류를 이루고 있다.

2.1.7. 인피니티 패브릭 인터커넥트

ZEN의 칩내 인터커넥트는 기존의 Hyper-Transport를 기반으로 재창조하다시피 갈아엎은 Infinity-Fabric(이하 IF)을 사용하게 된다. IF의 경우 AMD가 심혈을 기울여 만든 칩내 혹은 칩간 인터커넥트 규격으로 여러 종류의 연결 토폴로지를 망라하여 지원하며, 입출력 대역폭 역시 메인 메모리 입출력 조차도 무리없이 수용할 수 있도록 IF 클럭이 메인 메모리 클럭에 동기화 되어있다.
달리 말하면 '''램 성능빨을 많이 탄다'''는 의미이기도 하다. 그래서 라이젠의 성능을 제대로 뽑아내려면 램 오버클럭을 할 수밖에 없다. 캐시 메모리 클럭에 동기화된 인텔의 링 인터커넥트와 대조적인 부분. 이러한 특성 때문에 인터커넥트 대역폭도 성능에 영향을 줄 수밖에 없는데 그래픽 카드를 많이 활용하지 않고 CPU에 의존하는 렌더링 또는 인코딩 작업에서는 순전히 CPU의 클럭과 IPC가 조합된 성능만큼만 보여주지만, 그래픽 카드를 적극적으로 이용하는 게임에서는 그래픽 카드가 지니는 PCIe 대역폭만큼 인터커넥트 대역폭을 할당하기 때문에 안 그래도 느린 대역폭인 AMD의 IF 인터커넥트의 여유 대역폭이 더욱 부족해져 게임 성능이 렌더링 또는 인코딩 성능보다 더 떨어질 수 있다. 이렇다 보니, 인텔과 같은 CPU 코어 클럭으로 맞춰도 게임 성능이 떨어지는 원인 중에 하나로 꼽히고 있다.
다만, 메인 메모리 클럭에 동기화하는 방식이 반드시 단점만 있는 것만은 아니다. 오히려 메인 메모리 클럭에 동기화되기 때문에 꾸준히 클럭이 상향되는 DDR 계열 SDRAM의 JEDEC 표준 규격에 따라 IF 클럭도 상승되고, DDR4에서 DDR5로 크게 바뀌면 IF 클럭도 그만큼 큰 폭으로 향상되는 장점이 있다. 거기에 CPU의 PCI-Express 버전에 따라 향상될 수 있음을 고려하면 엄청난 잠재력인 셈이다!
2017년 시점에서 인텔의 링 인터커넥트가 AMD의 IF 인터커넥트보다 훨씬 더 빠른 대역폭을 보여주는 것은 부정할 수 없는 사실이다. 하지만 캐시 메모리 클럭도 결국엔 CPU 코어 클럭에 영향을 받는데다 코어 클럭이 너무 높으면 소비 전력이 너무 높아져 이를 완화하기 위해 캐시 메모리 클럭을 낮추는 꼼수로 지속될 수 있으므로 정작 인터커넥트 대역폭을 결정하는 캐시 메모리 클럭이 정체되어 CPU의 PCIe 버전이 업그레이드되기 전까지는 링 인터커넥트 대역폭도 정체될 수 있는 한계가 드러날 것이다.
특징적인 것은 Control-Fabric과 Data-Fabric이 분리되어 저레이턴시-저대역폭 제어 통신은 Control-Fabric이 담당하고 대량의 데이터의 고대역폭은 Data-Fabric이 담당한다는 점이다. 이러한 IF는 칩 내부 뿐만 아니라 소켓내 칩간 연결, 그리고 소켓간 연결에도 일관적으로 사용되어 ZEN아키텍처의 특징적인 MCM구조를 확립하는데 큰 역할을 하고 있다.

2.1.8. SenseMI

ZEN의 클럭 및 전력 제어 구조는 아래의 3개 기능을 이용한다. 해당 기능을 위해 ZEN의 내부에는 수백개의 관련 센서가 내장되어 있으며 해당 센서는 Infinity Fabric 중에서 Control Fabric를 통해 제어된다.
젠 코어를 특징짓는 굉장히 특이한 기능 중 하나로, 겉보기에는 세 기능이 연동되어 인텔의 터보부스트와 비슷한 작업을 하고 있으나 실제로는 정책상의 중요한 차이가 있다. 터보부스트가 작업이 많아지면 이에 따라 순차적으로 작업량과 발열량을 고려하여 클럭을 올리는 방식인 데에 반해, 젠 코어의 클럭 조정은 프로세스가 들어왔을 때 프로세스의 규모와 각 클럭의 상태를 확인한 후 가능한 코어를 선택해 클럭을 즉시 높이 올려 프로세스를 최대한 빨리 처리한 후 저클럭으로 즉시 돌아오는 것을 원칙으로 한다.
상당히 희한한 방식이고 클럭이 오르내리는 간격도 대단히 짧기 때문에 윈도우 작업관리자 등의 시스템 확인 프로그램에서도 올라간 클럭만 찍혀서 나오고 기본 클럭이 나오지 않는 버그가 있다. 때문에 실제로 확인하는 가장 좋은 방법은 온도를 확인하는 것으로, 굉장히 간단한 작업에도 온도가 잠깐 8~10도 정도로 큰 폭으로 올랐다가 바로 다시 내려오는 현상을 확인할 수 있다.
서밋 릿지 런칭 전후로 이 기능이 사실상 CPU를 자동으로 오버클럭 해준다는 이야기가 돌았으나, 당시에는 프리시전 부스트 기능이 미흡하여 이런 기능을 제대로 수행하지 못했다. 그러나 피나클 릿지에서는 프리시전 부스트의 클럭 곡선이 완만하게 변경되고 XFR 기능이 더 높아진 클럭 상한선과 맞물리며 실제로 괄목할 만한 수준의 자동 오버클럭을 가능하게 해 라이젠 CPU의 경쟁력에 기여하고 있다.

2.1.8.1. Pure Power

동일 클럭에서 낮은 전력소모를 목표로 한 전력제어 기능이다. 각 부분의 온도/클럭/전압을 모니터링 하여 최적 전압을 설정하여 전력소모를 낮춘다. Precision Boost기능과 연계하여 동작한다.

2.1.8.2. Precision Boost(PB)

동일 전압에서 보다 높은 클럭을 목표로 한 전력제어 기능이다. 역시 각 부분의 온도/클럭/전압을 모니터링 하여 해당 전압에서 뽑아낼 수 있는 최대 클럭을 설정한다. 단 해당 단계에서는 스펙상의 부스트 클럭이 클럭 한계이다. 터보부스트와는 달리 25Mhz 단위로 작동하며, 상술한 이유로 터보부스트에 비해서 클럭을 공격적으로 잡는 특성을 지닌다.
2세대에 들어와 고급형 X370/470 보드에 프리시전 부스트 오버드라이브(PBO)라는 기능이 생겼는데 이 PB 기능의 기본 정책을 변경하는 기능이다. 젠 코어가 PB를 운용할 때 원래는 모든 메인보드에서 안전하게 사용할 수 있도록 온도만 감안하는 것이 아니라 일정한 수준의 전력 및 전류를 넘어가지 않게 설정되어 있는데, 이 제약을 사실상 풀어버리고 온도 지표만을 가지고 클럭을 조정하게 만드는 것이다. 충분하고 안정적인 전류를 공급할 수 있도록 전력 공급 구성을 잘 해둔 보드와 함께 사용하면 상당한 수준의 올코어 오버클럭과 함께 XFR까지 함께 사용할 수 있어 돈 값을 톡톡히 해 준다.

2.1.8.3. Extended Frequency Range(XFR)

최대 클럭에서도 온도가 낮다면 오버클럭을 통해 추가로 클럭을 증대시키는 기술. non-X 모델과 X 모델 모두 지원하나 non-X 모델의 경우 X모델에 비해 제한적이다. 그 이상의 클럭을 원한다면 사용자가 수동으로 오버클럭을 해야한다.

2.1.9. 명령어셋 지원

CLZERO 등 일부 명령어셋이 추가된 반면 FMA4 확장 명령어셋 XOP 명령어셋 등 AMD가 독자적으로 만들던 SSE5의 일부 명령어셋은 지원이 중단 되었다[20].
지원이 중단된 명령어셋은 AMD가 인텔의 SSE4에 대응해 추가하기는 했지만 인텔의 시장지배력에 밀려 사실상 사장된 명령어들이기 때문에 비록 지원이 중단 되어도 기존 바이너리와의 명령어 호환성 문제는 없을 전망이다.[21]
또한 지원은 중단되었지만 아무래도 AMD CPU다 보니 기본적으로 디코더에 포함된 것으로 보인다. 강제로 FMA4 명령어를 사용한 연산을 명령하면 잘 수행된다# 단 지원 중단을 선언했으니 후속 아키텍쳐에서는 제거될 것으로 추정된다.
대신 인텔의 SSE 후속 명령어셋인 AVX를 인텔처럼 AVX-2까지 확장하였다.
가상화 기술의 이름이 AMD-V에서 SVM으로 변경되었다. 기본값이 '''꺼짐'''이어서 VMware나 VirtualBox 등이 제대로 작동되지 않아 혼돈의 카오스를 겪기 일쑤이므로 가상머신을 쓸 일이 있다면 UEFI로 들어가서 무조건 켜 놓자.

2.1.10. 사용 모델

AMD Threadripper 시리즈 - Whiteheaven
AMD RYZEN 시리즈 - Summit Ridge, Raven Ridge
AMD EPYC 시리즈 - Naples

2.1.11. 기대와 우려

2.1.11.1. 출시 이전

출사 이전 정보들을 종합하면 ZEN에서 기대할 수 있는 부분과 우려할 만한 부분은 다음과 같다.
기대

2005년 5월부터 2007년 11월까지 주력 제품군이었던 K8 아키텍처 기반의 애슬론 64 X2 시리즈 이후 10년만에 인텔과 제대로 경쟁할 수 있는 제품의 출시.
AMD CPU를 괴롭혔던 미세 공정 경쟁의 열세에서 벗어나면서 동급의 14nm 공정 달성.
일반 PC시장 최초로 인텔의 개인 사용자용 4코어-8스레드 제품 대비 차별화된 8코어-16스레드 제품의 도입.
라이젠 7이 인텔의 익스트림 모델과 비견 될 성능을 보여주면서도 최대 $499 이하 가격의 라인업을 갖춘, 하이엔드급에서의 뛰어난 가성비.
파운드리 협력 업체로 14nm FinFET공정을 빠르고 안정적으로 개발한 삼성 S.LSI와 GlobalFoundries를 선택하여, 안정적이며 저렴하고, 앞전 Polaris 14nm FinFET 생산으로, GF/S.LSI가 두번째로 내놓는 PC에 탑재되는 14nm FinFET 제품의 성능 저하의 우려가 사라짐.[22]
인텔의 스카이레이크의 다이 면적은 약 122 평방mm에 불과하여 일반적인 모바일 AP의 다이 면적과도 큰 차이가 없으며 제품의 성격 역시 로직IC라는 점에서 유사하다. 하지만 가격은 대략 10배의 차이가 나는데 그럼에도 불구하고 파운드리 업체는 모바일AP 생산을 통해 막대한 수익을 내고 있다. 파운드리 업체들의 원가경쟁력이 얼마나 강력한지 실감할 수 있는 부분.

우려

8코어-16스레드 제품은 인텔 역시 이미 제온 및 HEDT 제품군을, 2018년 4분기부터는 컨슈머용 제품군까지 공급하고 있으므로 경쟁하면서 만약 인텔이 가격을 저렴하게 인하할 경우 차별성 있는 포인트가 사라질 우려.

2.1.11.2. 출시 이후

평가

전반적인 성능은 출시 이전의 기대 수준 혹은 그 이상으로 나왔다는 평가가 대부분이다. 비록 스카이레이크나 그 이후의 인텔 경쟁제품 대비 클럭이나 IPC는 근소하게 뒤지지만 전성비 면에서 명확한 우위, 특히 레거시 실수연산이나 SSE명령어 연산 성능은 오히려 앞서는 편.
14nm 공정의 우열은 클럭성능에서는 인텔 대비 열세로 4GHz가 한계이다. 높은 오버클럭 잠재력을 지닌 인텔CPU 대비 단점임이 분명하나, 3GHz대 영역에서의 전성비는 매우 뛰어나 라이젠 7 1700의 경우 8코어 제품인데도 TDP는 65W에 불과하다.
일반용인 8코어-16스레드, HEDT용인 16코어-32스레드, 서버용인 32코어-64스레드 제품은 상대적으로 저렴한 가격과 차별화된 상품성에 힘입어 소비자들의 높은 관심을 받으며 시장에 안착했다. 이로 인해 인텔은 기존의 HEDT 제품 라인업에서 대대적인 수정을 거쳐 18코어-36스레드까지 지원하는 코어-X 시리즈의 i9 라인업을, 서버 제품은 28코어-56스레드까지 지원하는 제온 시리즈의 스케일러블 프로세서를 도입해야만 하는 처지가 되었다.
파운드리의 서밋릿지 다이의 수율은 80%에 달한다는 루머가 공개되었다. 최소한 공급망 이슈가 없는 것으로 봐서 양산이 순조로운 상황이라는 예상은 가능하며 파운드리의 생산능력도 입증되었다고 볼 수 있다.
서밋릿지 다이 수율이 80%라는 이야기와 함께 다이 활용률은 99%에 달한다는 주장도 같이 공개되었다. 수율이 너무 좋아서 코어 절반을 죽여서 판매하는 R3라인업의 출시가 늦어지게 된 것이 아니냐는 추측이 나돌 정도.
인텔의 공급가 인하 카드는 간접적으로나마 일부는 구체화된 상황이다. 대표적인 예가 데스크탑용 8세대 코어 i7과 i5 라인업에 6코어를 전면에 내세운 커피레이크.
멜트다운 취약점이 없다. 그나마 남아 있는 보안 취약점 중에 한 종류인 스펙터의 경우 Zen과 Zen+에는 마이크로코드 패치가 되었다고 하며, Zen2에서 근본적으로 해결된다고 한다.

기대

ZEN아키텍처는 AMD에서 백지 상태에서 개발하여 갓 출시된 아키텍처라서 오랜 기간 동안 개선을 거듭해 온 인텔 아키텍처에 비해 상대적으로 추후 성능향상의 여지가 크다.
ZEN을 개발한 개발진이 14nm LPP 공정과는 처음 협업하는 것임에도 불구하고 큰 무리 없이 4.0GHz까지의 클럭을 달성하는 데 성공했고, 더욱 고성능인 12nm에서는 4.4GHz까지 달성했으며, 7nm 공정에서는 공정 자체의 성능 향상과 업무숙련도 향상이 시너지 효과를 내면서 더 좋은 결과를 내 줄 가능성이 있다.
현존하는 소프트웨어 코드들은 당연하게도 새로 출시된 ZEN의 마이크로아키텍처 구조에 최적화되지 않은 반면 샌디브릿지 이후로 점진적인 확대전략을 써 온 인텔 마이크로아키텍처에 적합하게 만들어졌다. 즉 차후 SW수준의 최적화가 진행되면서 기대할 수 있는 성능 향상폭은 인텔 아키텍처보다는 ZEN아키텍처에서 더 높아질 것으로 기대할 수 있다. 물론 ZEN의 시장 점유율이 신통치 않다면 SW최적화의 수혜를 받기 어렵겠지만 현재 ZEN 기반의 RYZEN 제품이 특히 강세를 보이는 부분이 다름아닌 바로 그 고성능이 필요한 하이엔드 시장이므로 SW최적화에 대한 전망은 전반적으로 긍정적이다.
마이크로아키텍처의 개선 역시 충분히 기대해 볼 만 하다. ZEN의 아키텍처가 최고는 아니지만 전반적으로 균형이 잘 잡혀 나왔기 때문에 동시 명령어 디코딩 숫자 증대나 레지스터파일 증가 등 전형적으로 사용되는 성능향상책을 적용하더라도 안정적인 성능 향상이 가능할 것으로 전망된다.
4way 실수/벡터 유닛 구조는 레거시 x87에서부터 최신의 AVX2까지의 명령어들을 무리없이 실행할 수 있는 범용성이 높은 아키텍처이지만 AVX2와 같이 고도로 데이터가 병렬화된 명령어셋에 대해서 스루풋이 절반으로 떨어진다는 문제점을 가지고 있다. 이러한 문제점을 해결하기 위해 현재의 비대칭적인 유닛 기능을 점차 대칭적으로 확장하여 벡터연산 명령어의 스루풋을 높이면서도 레거시 명령어의 실행능력도 유지하는 방향 역시 기대할 수 있을 것이다.[23]
다만 각 유닛의 처리 데이터폭을 현용 128-bit에서 256-bit로 확장하는 것은 신중해야 하는 것이 바로 인텔이 섣불리 데이터 폭을 512-bit까지 확대하는 시도를 했다가 발열 문제를 해결하지 못하고 결국 AVX2, AVX-512 명령 사용시 클럭을 저하시켜야만 했던 사례가 있기 때문이며 심지어 이 문제는 현재진행형으로 계속 남아있는 상태이다.

2.1.12. 공개 전 루머

AMD ZEN 마이크로아키텍처/공개 전 루머 항목 참조

2.2. ZEN+ 마이크로아키텍처

WIKICHIP의 ZEN+ 마이크로아키텍처 상세 정보 (영문)

2.2.1. 변경점

14nm → 12nm (공정 개선) [24]
공정만바꾸고 AMD 14nm표준 라이브러리를 사용했기에 면적은 그대로다.
레이턴시 감소
- L1 캐시 레이턴시 최대 13% 감소
- L2 캐시 레이턴시 최대 34% 감소 (17사이클 → 12사이클)[25]
  1세대 EPYC 시리즈에 사용된 Naples와 1세대 라이젠 APU에 사용된 Raven Ridge는 Summit Ridge와 같은 14nm 공정에 ZEN 마이크로아키텍처 기반으로 제조되었지만 Summit Ridge와는 다르게 캐시 사이클 감소가 선행 적용되었다.
- L3 캐시 레이턴시 최대 16% 감소
- 메모리 레이턴시 최대 11% 감소
캐시 대역폭 상승
캐시 및 메모리 레이턴시 감소 덕분에 IPC 3% 향상
클럭 2~10% (평균 6%) 증가
실 성능 10% 증가
XFR2, PB2, PBO 지원
지원 메모리 비트레이트 증가 (DDR4 2666 → 2933)[26]
데스크탑용 Raven Ridge 한정으로 이미 2933까지 지원한다.
[27]
레이븐 릿지는 애초부터 14nm 젠+라는 시각이 많았다. 왜냐하면 14nm인거 빼면 레이턴시 특성이 피나클을 따라갔기에... 괜히 2000번대 넘버링이 아니다.
버그 수정
전력소모 감소
StoreMI 기술 추가
OEM 관련 문제 해결

2.2.2. 사용 모델

AMD Threadripper 시리즈 - Colfax
AMD RYZEN 시리즈 - Pinnacle Ridge, Picasso

2.3. ZEN 2 마이크로아키텍처

[image]
[image]
WIKICHIP의 ZEN 2 마이크로아키텍처 상세 정보 (영문)

2.3.1. 변경점

GF 12 nm → TSMC 7 nm (공정 미세화)
일반 소비자용 라인업 증설
코어와 I/O가 별도의 다이로 분리, 서버용(sIOD)은 GF 14nm 공정, 일반 소비자용(cIOD)은 GF 12nm 공정으로 제조
- 단, APU인 Renoir는 코어와 I/O가 분리되지 않은 모놀리식 다이
IPC 15% 향상
클럭 9% 증가
실 성능 10~20% 증가
PCIe 4.0 지원, 단, APU인 Renoir는 여전히 PCIe 3.0 지원
TLB
- L2 DTLB가 1536 엔트리 → 2048 엔트리로 확장
캐시 메모리
- 마이크로옵 캐시가 2K μops → 4K μops로 확장
- L1 명령어 캐시 메모리가 64 KB → 32 KB로 줄어든 대신 set associativity가 4-way → 8-way로 확장
- CCX당 L3 캐시 메모리 용량이 8 MB → 16 MB로 2배 증가된 대신, 레이턴시가 35사이클 → 39사이클로 지연됨
  - 단, APU인 Renoir는 CCX당 4 MB 그대로 유지
기타 메모리 서브 시스템
- 스토어 버퍼(큐)가 44 엔트리 → 48 엔트리로 확장
프론트 엔드 개선 및 확장
- 프리페처 개선
- 리오더 버퍼(ROB)가 192 μops → 224 μops로 확장
- 디스패치 대역폭 확장
백 엔드 확장
- 정수 연산 스케쥴러가 14 μops → 16 μops로 확장
- 정수 연산 메모리 스케쥴러가 2개의 14 μops → 하나의 28 μops로 통합
- 주소 생성 유닛(AGU)이 2개 → 3개로 확장 (단, 스토어 전용 유닛만 확장)
- 부동소수점 스케쥴러가 32 μops → 36 μops로 확장
- AVX 스루풋이 128-bit → 256-bit로 2배 증가
새로운 명령어 추가 (WBNOINVD, CLWB, RDPID)
기존의 분기 예측기에 TAGE(TAgged GEometric history length branch prediction)의 추가 탑재로 분기 예측 능력이 향상
인피니티 패브릭 2
- PCIe 4.0 도입으로 링크의 폭이 32 바이트/사이클 → 64 바이트/사이클로 향상
- 링크당 전송 속도가 10.6 GT/s → 25 GT/s로 2.3배 향상
실리콘 단계에서 멜트다운/스펙터 차단
지원 메모리 비트레이트 증가 (DDR4 2933 → 3200)

2.3.2. 사용 모델

2.3.2.1. 9세대 콘솔 게임기

2019년부터 루머를 통해 차세대 플레이스테이션과 엑스박스 기종에 ZEN2 아키텍처 CPU가 들어간다는 소식이 흘러나왔고 각각 4월과 6월 공식적으로 확인되었다. 2020년 3월 소니와 MS 양사에 의해 구체적인 사양이 발표되었다. 플레이스테이션 5와 엑스박스 시리즈 X 모두 ZEN 2 아키텍처 기반의 8코어 16스레드 CPU가 사용되며, 차이점은 부스트 클럭 정도로[28] 거의 동일한 구성이다. 다만 L3 캐시 메모리가 4MB x2 구성으로, 이전 버전에서 서술되었던 3700X보다는 르누아르 R7 4750G의 콘솔 게임기 버전이라 생각하면 되겠다. 다만 대신 PCIe 4.0을 지원하므로 PCIe 3.0인 라이젠 7 프로 4750G보다는 낫다. RDNA2 기반인 이들과는 달리 르누아르의 iGPU는 여전히 GCN 기반의 Vega 코어이기 때문.[29]
전작들의 CPU는 ZEN이 발표되기 전의 재규어 아키텍처를 사용했고, 이들은 인텔의 아톰처럼 저전력 저성능의 제품군이라서[30] 굳이 현 시점과 비교하지 않더라도 2021년 현재는 물론 그 당시(2013~2014년 무렵) CPU 중에서도 그리 높은 성능을 보이지 않았다. 그 탓에 CPU 성능이 4배 향상이라는 말도 안되는 성능 도약이 있을 예정이다.

2.4. ZEN 3 마이크로아키텍처

[image]
WIKICHIP의 ZEN 3 마이크로아키텍처 상세 정보 (영문)

2.4.1. 변경점

CCX당 코어 구성: 4코어 → 8코어
CCX당 L3 캐시 메모리 슬라이스 구성: 총 16 MB → 32 MB
전력당 성능비: 이전 세대 대비 20% 향상
IPC: 이전 세대 대비 평균 19% 향상[31]
다만 전통적으로 CPU 벤치마크에서 주로 쓰는 멀티스레딩 중심의 프로그램에서는 10%대 초중반으로, 20%에 가깝다는 평균치에 비하면 꽤 낮은 편이다. AMD가 공식적으로 주장하는 IPC 향상치 또한 마찬가지로, 대부분은 3D 그래픽, 게이밍처럼 20%를 훨씬 초과하는 프로그램들까지 모조리 포함한 평균치가 19%라는 것. 게임같이 IPC보단 언코어/메모리 의존도가 높은 프로그램들을 IPC 비교에 대거 포함시켜서 다소 빛이 바랜 점이 있으나, 어차피 업계 표준에 가까운 SPEC 2006/2017 측정에서도 19~21% 가량의 성능 향상을 보였으므로, AMD가 공언한 수치를 충족하는 데는 문제가 없다.
- 캐시 프리페칭 2.7% 개선
- 실행 엔진 3.3% 개선
- 분기 예측 1.3% 개선
- 마이크로옵 캐시 2.7% 개선
- 프론트 엔드 4.6% 개선
- 로드/스토어 4.6% 개선
프론트 엔드
- No-Bubble을 표방하는 개선된 분기 예측 능력
- 분기 예측 실패시 빨라진 복구 능력
- L1 BTB(분기 타겟 버퍼)가 512엔트리 → 1024엔트리로 확장
- L2 BTB가 7168엔트리 → 6656엔트리로 축소, 그 대신 효율성 향상
- 새로운 L1 명령어 캐시 라인 교체 정책
백 엔드
- 재정렬 버퍼가 224엔트리 → 256엔트리로 확장
- 정수 연산 스케줄러 용량이 92엔트리 → 96엔트리로 확장
- 정수 레지스터 파일 용량이 180엔트리 → 192엔트리로 확장
- 정수 연산 발행 횟수가 최대 7회 → 10회로 증가
- 부동소수점 실수 연산의 디스패치 폭이 4 µOps → 6 µOps로 확장
- FMAC (Fused Multiply Accumulate Operations) 연산 시간이 5사이클 → 4사이클로 단축
- 로드 유닛의 대역폭이 1.5배 확장
- 스토어 유닛의 대역폭이 2배 확장
- 스토어 큐가 48엔트리 → 64엔트리로 확장
메모리 시스템
- CCX당 L3 캐시 메모리 용량이 16 MB → 32 MB로 2배 증가된 대신, 레이턴시가 39사이클 → 46사이클로 지연됨
- CCX당 L3 캐시 메모리 대역폭이 그대로 유지됨에 따라, 코어당 L3 캐시 메모리 대역폭이 절반으로 축소
- 메인 메모리의 평균 레이턴시가 약 8~9% 단축
새로운 명령어 추가 (MPK, VAES/VPCLMULQD)

IPC 향상률이 발표 전 루머들을 통해 언급된 예상보다 잘 나왔다는 반응이 압도적이다. 이전 세대에서는 분기 예측과 마이크로옵 캐시의 IPC 향상 기여도가 가장 컸던 것과는 다르게, 프론트 엔드와 백 엔드 로드/스토어 유닛의 IPC 향상 기여도가 가장 큰 것이 특징.
CCX 및 L3 캐시 메모리의 구성 변경에 직접적인 영향을 받는 캐시 프리페칭의 IPC 향상 기여도가 2.7%라고 언급되어 있는데, 이는 렌더링, 인코딩, 시뮬레이팅 등의 전문 작업을 기준으로 측정된 IPC로 게이밍에서 캐시 프리페칭의 IPC 향상 기여도는 2.7%가 아닐 수 있다. 2020년 5월 초순에 출시된 라이젠 3 3300X와 3100을 통해 같은 클럭으로 변인 통제된 상태에서 CCX 및 L3 캐시 메모리 구성만 다를 경우, 렌더링 및 인코딩 성능 격차가 별로 없는 반면, 게이밍 성능 격차가 FHD 해상도 환경에 NVIDIA 지포스 RTX 2060 기준으로 5~10% 정도였던 점을 상기해보면 3300X가 ZEN 3 아키텍처 맛보기 CPU라는 호평이 과장된 것이 아니었음을 짐작할 수 있다.
게다가 일반적으로 순수하게 IPC만을 판단할 때 게이밍 평균 성능보다는 SPEC같은 전문 벤치마크 프로그램들의 평균 성능을 통해 가늠하는 경향이 더 강하고, 게임 등을 포함해서 봐도 평균 20% 가까이의 성능 향상을 이뤘다는 점에서 ZEN 3 아키텍처의 향상된 IPC는 순전히 CCX 및 L3 캐시 메모리 구성의 변경에 의존한 IPC 향상률이 절대 아니라고 볼 수 있다.[32]
ZEN 2 아키텍처까지는 CCX당 4코어였기 때문에 코어 간 인터커넥트 토폴로지가 크로스 바 구조로 이루어져 있었다. 크로스 바 구조 특성상 코어 개수가 많아질 수록 커넥션 개수가 기하급수적으로 증가되어 복잡도가 급상승해지기 때문에 8코어씩 묶여져 있는 ZEN 3 아키텍처의 CCX는 인텔의 클라이언트용 현행 아키텍처에 채택되고 있는 링 구조라고 주장하는 사람들이 있었으나, 실제로는 링 구조보다 더 균일한 레이턴시 패턴인 구조로 밝혀졌다. 링 구조가 성립되려면 레이턴시가 점진적으로 변하다가 어느 기점에 급변한 후 다시 점진적으로 변하는 패턴이어야 하는데, 그런 레이턴시 패턴으로 보기 어렵기 때문. 사실 크로스 바 구조의 경우 코어가 늘어날수록 제곱에 비례해서 인터커넥터 숫자가 늘어나야 하는데, 그런 문제점을 안고서 기어이 8코어를 크로스 바로 묶었다는 점에서 놀라는 이들이 많다. 링 구조 내지 완전히 새로운 구조일 것이라는 예측이 대세였던 이유 또한 이제까지 8코어를 하나하나 1:1 직결한 사례가 없었기 때문.

2.4.2. 사용 모델

3. 운영체제 활용

3.1. 윈도우

ZEN의 스레드 스케줄러를 대응하는 윈도우 운영체계는 윈도우 10 이상으로 윈도우 7 같은 구형 OS에서는 SMT를 활용하지 못해 성능이 떨어진다.
윈도우 10 계열에서도 AMD RYZEN Threadripper 처럼 스레드가 128개가 넘어가는 제품들은 가능하면 윈도우 엔터프라이즈 계열을 사용해야 한다. 엔터프라이즈 제품군은 제온 같은 서버용 CPU 사용을 대응하기 위해 다수의 스레드, 다수의 CPU 소켓을 지원하기 때문이다. 그래서 윈도우 홈에디션 같은 메모리나 CPU 스레드에 제약이 걸린 제품과 엔터프라이즈 제품군을 벤치마크 하면 엔터프라이즈 계열이 훨씬 잘나온다.#

3.2. 리눅스

ZEN 마이크로아키텍쳐가 이전의 CPU와 많이 다르다보니, 초기 출시 시점에는 리눅스 커널과 호환성 문제가 제기되었다. 커널 버전 기준으로 4.4 버전 이상인 경우 켜지기는 하는 수준이고, 4.8 버전부터 성능 저하는 있지만 큰 문제는 없는 수준이며, 4.11부터 제 성능이 나오는 상황이다. 최근 리눅스 배포판들은 모두 RYZEN을 사용하는데 문제는 없지만, 레거시 문제로 이전 버전의 리눅스를 사용하려는 경우 커널 버전이 4.4 버전 미만이면 구동이 어려우므로 미리 확인하자.
현재 ZEN 마이크로아키텍쳐와 가장 궁합이 맞는 리눅스는 인텔에서 제작한 리눅스인 인텔 클리어 리눅스#이다. 인텔에서 x86 계열 CPU에 최적화 했기 때문에 동일한 x86, AMD64 ISA를 사용하는 ZEN 계열 CPU와 궁합이 잘 맞는 것이다.밴치마크 및 분석

우분투 - 16.04.4부터 설치 후 바로 사용할 수 있다.
CentOS - 7.4.1708 부터 설치 후 바로 사용할 수 있다. 7.3 이전 버전은 설치 불가.
페도라 - Fedora 26 버전부터 설치 후 바로 사용할 수 있다.
아치 리눅스 - pacman -Syu 의 위용.. 이참에 넘어가보자.

4. 관련 문서

[1] 이 날은 인텔이 마지막으로 개최했던 IDF 2016의 두 번째 날이었다.[2] 초기(2015년 초)에는 FM3으로 불린적도 있었다.보드나라 기사 다만 소켓이 통합되는 사실 자체는 변함이 없고 소켓명칭만 가칭 FM3에서 정식으로 AM4로 붙은 것이다.[3] 이전에는 삼성전자 허밍버드(엑시노스 3110으로 개칭)를 그대로 사용하였고, 사실 A4나 A5는 엑시노스와 구조상 차이가 거의 없다. A6와 A6X까지도 삼성전자의 입김이 설계에 많이 들어갔으며, A7부터 줄어들기 시작하였다. 지금은 생산 빼고는 별 관련이 없다. 생산은 TSMC와 공동으로 한다.[4] 실사용에서는 아닐지 몰라도,의외로 일부 벤치에서는 아이비브릿지와 비슷한 벤지마킹 점수를 기록했기 때문에 브로드웰급으로 예상치가 올라가게되었다.[5] 오타가 아니다. 실제 자료에 그렇게 명기되어 있다.[6] Cinebench15는 벡터명령어인 SSE명령에 크게 의존적이다.[7] 물론 IPC라는 게 완벽하게 고정불변한 절대값은 아니므로, 사용하는 프로그램이나 환경에 따라 클럭 당 성능차는 더 벌어지거나 좁혀질 수 있음을 명심하자.[8] bobcat 아키텍처의 신경망 분기예측기를 구현한 엔지니어는 인텔에서 테자스 아키텍처를 구현하다가 AMD로 이적한 후 bobcat의 신경망 분기예측기를 구현하고 다시 삼성전자로 이적해서 삼성 M1 마이크로아키텍처의 신경망 분기예측기를 구현했다고 한다. [9] 그러나 신경망 분기예측과 커널/유저 단순 권한분리로 한계가 있기 때문에 아예 메인보드 칩셋과, 내부 보안칩셋부에서 메모리 암호화도 동시에 시행한다.# 또한 이 구조는 멜트다운은 막지만 스펙터는 완전하게 막지는 못하며, AMD에서도 관련 패치를 개발하고 있다.[10] ZEN 아키텍처가 아키텍처 상으로 하스웰/브로드웰 수준의 IPC를 가질 것이라고 추정되었던 이유 중 하나가 클럭당 디코딩 능력이 스카이레이크가 아닌 하스웰/브로드웰 수준이라는 점이었다.[11] x86/x64 명령어의 길이는 평균적으로 32bit보다 짧다. 사실 x86명령어셋의 긍정적인 특징 중 하나가 짧은 명령어 길이로 인해 코드 바이너리가 상대적으로 고밀도라는 점이었다. [12] http://www.anandtech.com/show/10591/amd-zen-microarchiture-part-2-extracting-instructionlevel-parallelism/3 "AMD that the dispatch unit can simultaneously dispatch to both INT and FP inside the same cycle, which can maximize throughput" [13] 벡터명령 위주의 연산이라고 해도 메모리 입출력은 필요하기에 정수부의 로드/스토어 유닛은 벡터/실수 연산 과정에서도 비교적 바쁘게 움직인다.[14] 다만 SMT에 의해 스레드 2개에서 정수명령어와 벡터명령어가 동시에 디스패치 유닛으로 들어오는 상황이라면 정수부와 벡터부로의 디스패치가 동시에 수행되면서 이론상의 디스패치 속도에 근접하게 될 가능성은 있다. 실제로 ZEN의 SMT효율은 인텔측 보다도 더 좋다는 의견이 대세이기도 하고.[15] CPU 레지스터에는 ISA에 정의된 명시적 레지스터와 CPU내부에서만 보고 사용할 수 있는 백그라운드 레지스터가 존재하는데 두 명령어간 레지스터값 연관성이 없어도 됨에도 불구하고 명시적 레지스터 숫자의 부족으로 인해 의사-연관성이 어쩔 수 없이 발생하여 두 명령어의 동시 실행이 어려워질 경우 CPU 내부에서 자체적으로 해당 레지스터 이름을 백그라운드 레지스터에서 이름을 바꿔서 의사-연관성을 제거하게 되는데 이를 레지스터 리네이밍이라고 한다.[16] 모듈 전체로 보자면 ZEN과 동일한 4개이다.[17] 예를 들어 코드 내 명령어들이 SSE명령어에 치중되었을 경우 ZEN은 최대 4개 명령어를 실행 가능한데 비해 인텔은 3개만 실행 가능하며 실질적인 아웃풋은 오히려 ZEN이 유리하게 된다. 반면 코드가 AVX2에 치중되었다면 ZEN은 AVX2명령어를 SSE로 쪼개어 두 번에 걸쳐 실행해야 하므로 최대 2개 명령을 실행할 수 있는데 비해 인텔 아키텍처는 최대 3개씩 실행할 수 있다. [18] uOP 캐시의 경우 인텔의 uOP와 동일한 역할을 하지만 방식이 약간 다르다. 인텔의 경우 L1 캐시가 uOP캐시를 포함하는 inclusive 방식이지만 ZEN의 L1 캐시는 OP 캐시의 내용을 담고 있지 않는다. [19] 2-way SMT가 일반적으로 학계나 업계에서 사용하는 학문 또는 기술 용어이고, 하이퍼쓰레딩은 해당 기술을 인텔이 상표화한 것이다. 즉, 부르는 이름만 다르고 실제 기능은 동일한 기술.[20] 해당 명령어셋의 지원 추가와 중단은 다음 링크에서 확인해 볼 수 있다. https://reviews.llvm.org/D28018 [21] 예를 들어 FMA4 명령어셋은 AVX 레지스터를 대상으로 한 4-오퍼랜드 실수벡터연산 명령어인데 ZEN의 실수/벡터유닛의 구조상 레지스터파일이 3-오퍼랜드까지만 대응이 가능하다. 결국 4-오퍼랜드 명령어라고 해도 uOP로 변환되는 과정에서 3-오퍼랜드 명령어 1개와 FMOV명령어 1개로 분리되어 순차 처리되면서 결국 기존의 FMA3의 3-오퍼랜드 명령과 처리속도의 차이가 없게 된다. 처리속도 차이는 없는데도 불구하고 디코더 입장에서는 FMA4 명령을 처리하기 위한 기능까지 떠안게 된다. 즉 ZEN에서의 FMA4 명령어는 속도상의 이득은 없으면서 디코더만 더 복잡하게 만드는 요인이 되므로 삭제한 것으로 보인다.[22] 인텔의 스카이레이크의 다이 면적은 약 122 평방mm에 불과하여 일반적인 모바일 AP의 다이 면적과도 큰 차이가 없으며 제품의 성격 역시 로직IC라는 점에서 유사하다. 하지만 가격은 대략 10배의 차이가 나는데 그럼에도 불구하고 파운드리 업체는 모바일AP 생산을 통해 막대한 수익을 내고 있다. 파운드리 업체들의 원가경쟁력이 얼마나 강력한지 실감할 수 있는 부분.[23] 다만 각 유닛의 처리 데이터폭을 현용 128-bit에서 256-bit로 확장하는 것은 신중해야 하는 것이 바로 인텔이 섣불리 데이터 폭을 512-bit까지 확대하는 시도를 했다가 발열 문제를 해결하지 못하고 결국 AVX2, AVX-512 명령 사용시 클럭을 저하시켜야만 했던 사례가 있기 때문이며 심지어 이 문제는 현재진행형으로 계속 남아있는 상태이다.[24] 공정만바꾸고 AMD 14nm표준 라이브러리를 사용했기에 면적은 그대로다.[25] 1세대 EPYC 시리즈에 사용된 Naples와 1세대 라이젠 APU에 사용된 Raven Ridge는 Summit Ridge와 같은 14nm 공정에 ZEN 마이크로아키텍처 기반으로 제조되었지만 Summit Ridge와는 다르게 캐시 사이클 감소가 선행 적용되었다.[26] 데스크탑용 Raven Ridge 한정으로 이미 2933까지 지원한다.[27] 레이븐 릿지는 애초부터 14nm 젠+라는 시각이 많았다. 왜냐하면 14nm인거 빼면 레이턴시 특성이 피나클을 따라갔기에... 괜히 2000번대 넘버링이 아니다.[28] 엑스박스:3.6GHz, 플스:3.5GHz[29] PCIE 3.0 기반이라 당연히 이를 지원하는 i/o 역시 3.0 기반이다.[30] 의외로 많은 사람들이 동세대 아키텍처인 CMT, 즉 불도저 기반이라고 알고 있으나 해당 문서에서도 볼 수 있듯 K10의 간소화판이다.[31] 다만 전통적으로 CPU 벤치마크에서 주로 쓰는 멀티스레딩 중심의 프로그램에서는 10%대 초중반으로, 20%에 가깝다는 평균치에 비하면 꽤 낮은 편이다. AMD가 공식적으로 주장하는 IPC 향상치 또한 마찬가지로, 대부분은 3D 그래픽, 게이밍처럼 20%를 훨씬 초과하는 프로그램들까지 모조리 포함한 평균치가 19%라는 것. 게임같이 IPC보단 언코어/메모리 의존도가 높은 프로그램들을 IPC 비교에 대거 포함시켜서 다소 빛이 바랜 점이 있으나, 어차피 업계 표준에 가까운 SPEC 2006/2017 측정에서도 19~21% 가량의 성능 향상을 보였으므로, AMD가 공언한 수치를 충족하는 데는 문제가 없다.[32] 애초에 IPC는 단어 뜻 그대로 클럭 당 명령어 처리 횟수이지 단순히 동클럭당 성능이 아니다. L3 캐시가 있는 데네브와 없는 프로푸스의 동 클럭 당 성능은 전혀 다르지만, 코어 단에서 동 클럭 당 명령어 처리하는 횟수는 같기 때문.