기타 칼럼

리뷰(게임, 하드웨어, 칼럼, 영상리뷰) 게시판은
닥터몰라 운영진이 작성한 게시글을 보는 게시판으로 회원들의 작성은 금지되어 있습니다.
(단, 좋은 글이 있으면 글 작성자의 허락과 운영자의 회의를 통하여 리뷰게시판으로 이동 됩니다.)

[CPU] AMD Zen 미리보기 : 현대 CPU의 구조 2015

IYD | 조회 268 | 추천 0 | 2015.05.08. 00:27 http://drmola.com/etc_column/41804

Author : Daeguen Lee

(Any action violating either copyright laws or CCL policy of the original source is strictly prohibited)




안녕하세요 독자 여러분. 오랜만에 글다운 새 글을 들고 여러분을 찾아뵙게 되어 기쁜 글쓴이입니다. 이 글은 며칠 전 있었던 AMD의 주주총회와 거기에 뒤따라 개최된 Financial Analyst Day 행사에 영감을 받아 쓰여지게 되었는데, 혹시 이 날 어떤 일들이 있었는지 아시는지요. 바로 AMD의 새 아키텍처 -모듈 구조와 클러스터 멀티스레딩을 도입한 이후 만 5년만에 새로 선보일!- "Zen" 의 정보가 일부 공개된 것입니다. 현재까지 상세한 정보가 알려지지 않아 많은 부분을 추측에 의존해야 함에 불구하고, 보일듯 말듯한 정보를 바탕으로 모래성을 지어보는 것 역시 쏠쏠한 재미일 것이란 생각에 이렇게 만 다섯살 된 글을 리뉴얼할 결심을 하게 됐습니다. 아마 다음 분기쯤 인텔 6세대 코어 프로세서 (코드네임 스카이레이크) 가 출시되면 다시 한번 업데이트를 해야겠지만...^^;


각설하고, Zen에 관해 AMD가 공식적으로 언급한 내용을 요약하면 아래 이미지와 같습니다.



물론 AMD 자신의 자료이니만큼 다소 허풍이 섞여 있다고 가정하고, 적당히 색안경을 쓰고 바라봐줘야 할 필요가 있겠습니다만 역시 자사의 전/현세대 아키텍처인 불도저와 엑스카베이터를 함께 비교선상에 둔 것으로 보아, 어쨌든 불도저로부터 엑스카베이터까지의 성능향상폭을 모두 합친 것보다 더 큰 성능향상이 있는 것만은 확실해 보입니다. 과연 Zen은 구조적으로 어떤 특징을 가진 아키텍처인지 우선 알아보고, '알아낼 수 있던 것' 에 한해서라도 이에 근거한 몇몇 시나리오에서의 추정 성능을 알아보고자 하는 것이 이 글의 목표입니다.


자, 아래 그림은 참 오랫동안 우려먹고 있죠. 다들 익숙하신가요?



일반적인 CPU(와그 주변)의 구조는 위 그림과 같습니다.

더 자세한 설명에 들어가기 전에, 일반적인 CPU 구조와 AMD의 모듈 구조가 어떻게 다른지 간단히 짚어 보도록 하겠습니다.



1세대 및 2세대 불도저인 불도저 / 파일드라이버는 프론트엔드의 대부분을 한 모듈 내에서 공유합니다. 그 말인즉, '2코어' 불도저(파일드라이버)라 하더라도 프론트엔드 부분까지는 일반적인 1코어 CPU와 크게 다르지 않다는 뜻이기도 합니다. 다만 백엔드 직전, 비순차 실행유닛(=백엔드, Out-of-Order Execution Unit)에 명령어를 공급해주는 장치인 비순차 큐(Out-of-Order Queue)가 모듈 내에서 두 개로 복제되어 있음을 보실 수 있을 겁니다. 그리고 프론트엔드와 달리 백엔드는 본격적으로 '두 개의 코어' 처럼 부풀려져 있는데, 자세히 보면 그 중에서도 정수연산 유닛은 2코어 분량이 탑재되어 있지만 부동소수점 유닛은 여전히 모듈 내에서 공유되고 있는 구조입니다. L1 데이터 캐시 역시 개별 '코어'에 맞춰 두 개로 나뉘어 있습니다.


한편, 3세대 및 4세대 불도저인 스팀롤러 / 엑스카베이터는 위에 더해 '디코드' 단계 역시 두 개로 복제된 것이 특징입니다. 결과적으로 1/2세대가 2코어라기보다는 정수 유닛을 확장한 1코어에 가까웠다면, 3/4세대는 반대로 페치 단계와 부동소수점 유닛을 공유하는 2코어에 보다 가까워진 모양이 되었습니다. 외견상으로는, 그리고 이론적으로는 성능 역시 그만큼의 향상이 있었어야겠지만 실제로는 그렇지 않았는데, 이 글에서는 얕게나마 그 이유 역시 짚어 보도록 하겠습니다.


그럼 이제부터 본론으로 들어갑니다. AMD의 (현재로써는) 마지막 황금기를 누렸던 주인공, K8 아키텍처에서부터 시작합시다.

(K8과 K10(바르셀로나), K10.5(상하이/이스탄불)의 아키텍처는 큰 차이가 없어 이 글에서는 하나로 뭉뚱그려 설명합니다.)



이 구조는 사실 AMD K7부터 큰 변화가 없다고 봐도 무방한데, 그만큼 K7이 우수한 설계를 가지고 있었다고 보면 되겠습니다. 마침 비슷한 시기에 나왔던 인텔의 P6 역시 일부분만 개량되어 코어, 네할렘, 샌디브릿지, 하스웰에 이르기까지 적용되고 있으니, 그때 그 시기에 CPU 제조사들이 신내림이라도 받았던 게 아닌가 하는 생각도 듭니다.


K8/K10은 64KB의 L1 데이터/명령어 캐시를 탑재하고 있으며 (=도합 128KB) L1 명령어 캐시로부터 읽어드린 명령 스트림은 최대 32바이트까지 프론트엔드의 페치 버퍼에 저장됩니다. 제각기 다른 길이와 복잡도를 갖는 CISC 세트에 속하는 x86 명령어는 매 클럭 사이클당 3개씩 디코더로 보내지며, AMD의 디코더는 받아들인 명령어를 3종류로 분류해 CPU 내부에서 처리 가능한 RISC 형태로 변환합니다(=디코드). 3종류란 (1) 2개 이상의 매크로옵으로 변환되는 부류 / (2) 1개의 매크로옵으로 변환되는 부류 / (3) 1개의 마이크로옵으로 변환되는 부류인데, AMD의 '매크로옵'이라는 용어는 인텔의 그것과는 지칭하는 의미가 다른 점에 유의하셔야 합니다. (인텔의 매크로옵은 x86 명령어 자체를 의미하나, AMD의 매크로옵은 마이크로옵(내부 RISC 명령어) 중 일정한 규칙에 따라 '묶음' 취급이 가능한 것을 의미합니다.) AMD 디코더가 생성하는 일반적인 매크로옵은 산술 연산 명령어 마이크로옵과 메모리 접근 명령어 마이크로옵을 묶은 것입니다. 대체로 모든 연산은 수행된 후 결과값을 특정한 메모리 주소에 기록하는 것이 목적이기 때문에 이러한 묶음은 효율적으로 작동합니다.


3개의 디코더가 각각 사이클당 1개의 매크로옵(당연히, '묶을' 쌍이 없으면 1개의 마이크로옵 - 이하 본 글에서 내부 RISC 명령어는 모두 '마이크로옵'으로 지칭합니다)을 생성하면 생성된 마이크로옵들은 모두 AMD가 Instruction Control Unit이라 이름붙인 '재정렬 버퍼'에 들어갑니다. 재정렬 버퍼는 최대 72개의 마이크로옵을 저장할 수 있으며, 적절한 시점에 최대한의 병렬성을 확보해 명령어가 처리되게끔 백엔드에 보내 주는 역할을 하는 '작업 화면' 에 해당합니다. 고전게임인 테트리스를 해 보신 분은 아시겠지만 앞으로 등장할 블럭이 무엇인지 보여주는 창이 넓으면 넓을수록 더 좋은 전략을 세울 수 있을 것이고, 창이 없거나 매우 적을 수의 블럭만 보여준다면 플레이하기가 어려울 것입니다. 재정렬 버퍼의 크기가 바로 그 '창'의 크기를 의미한다고 생각하면 되겠습니다.


다음은 1/2세대 불도저의 프론트엔드 구조입니다.



앞서 간단히 설명했지만 다시 한번 자세히 살펴보도록 하죠. 우선 모듈 단위의 멀티스레딩 (클러스터 멀티스레딩) 을 수행하기 위해 L1 데이터 캐시가 두 개로 복제되어 있는데 각 캐시의 용량은 K10 대비 4분의 1수준으로 줄었습니다. 따라서 모듈=2코어 기준으로 합산하더라도 32KB로, 종전의 1코어보다 오히려 절반 수준으로 줄어든 캐시를 갖게 된 것이 특징입니다. 마찬가지로 페치 버퍼 역시 16바이트로 줄어들었으며 대신 디코더가 한개 더 늘어 사이클당 4개의 x86 명령어를 최대 4개까지의 내부 RISC 명령어 포맷 (마이크로옵) 으로 변환할 수 있게 되었습니다. 하지만 여전히 명심해야 할 것은 위 그림은 불도저 "모듈"을 설명하고 있다는 점입니다. 2코어당 4개의 디코더를 산술적으로 생각하면 1코어당 2개인 꼴이고, 종전 K10까지는 1코어당 3개의 디코더가 있었으니 아주 러프하게 보면 프론트엔드 성능이 3분의 2 수준으로 떨어졌다고도 생각할 수 있겠습니다.

 

또한, 재정렬 버퍼라는 이름 대신 디스패치 큐라는 이름이 등장했는데 이에 관해 짚고 넘어가도록 하겠습니다. (※ 2010년에 작성된 원 글에는 없던 내용입니다!)

 

인텔이 1995년 P5 마이크로아키텍처에 기반한 '펜티엄' CPU를 출시했을 때까지만 하더라도 프론트엔드에서 공급한 명령어를 백엔드에서 수행하는 방법은 단 하나, '들어온 순서대로' 연산하는것 뿐이었습니다. 이러한 방식을 In-Order라고 하며 가장 직관적인 순서에 의해 명령어가 처리되는 만큼 가장 단순한 하드웨어로도 구현이 가능하고, 그에 따라 소비전력 역시 이점이 있어 오늘날에도 저성능 모바일 CPU 아키텍처에는 간간히 재등장하곤 하는 개념이기도 합니다. (가까이는 베이트레일 이전의 아톰이나 밥캣 코어에 사용된 바 있습니다.) 하지만 여러 차원에서 '병렬성' 이라는 개념이 대두되고 CPU의 백엔드를 넓히는 방향으로 가게 되면서 순차 수행 방식의 한계가 드러나고, 이에 인텔은 P6 마이크로아키텍처부터 / AMD는 K5 아키텍처부터 비순차 수행(Out-of-Order Execution)을 구현하게 됩니다. 비순차 수행은 오늘날 CPU의 핵심이라고 해도 과언이 아닙니다.

 

이러한 비순차 수행을 가능하게 하는 것이 앞서 설명했던 재정렬 버퍼 등의 하드웨어입니다. 명령어가 '최대한의 병렬성'을 확보하여 '동시에 많이' 처리되게끔 '재정렬' 해 주는 것이 이 장치의 목적인 만큼 순차 수행 CPU에는 없는 장치이기도 하며, 또한 프로세서 설계 철학에 따라 얼마든지 다른 방법으로 이러한 역할이 구현되기도 합니다. 여기에서 지금 설명할 주제가 드러나게 됩니다. 바로 비순차 수행 CPU라고 해서 모두 같은 방식의 'OoOE 하드웨어'를 탑재하는 것은 아니기 때문입니다. 이는 크게 (1) 재정렬 버퍼 기반 디자인과 / (2) 물리 레지스터 파일 (Physical Register File, PRF) 기반 디자인으로 구분됩니다.

 

재정렬 버퍼 기반 디자인에 속하는 대표적인 것으로 인텔의 P6, 코어, 네할렘, 샌디브릿지, 하스웰을 들 수 있으며 K7부터 K10까지의 AMD CPU도 이 방식을 사용합니다. (AMD는 재정렬 버퍼를 자신만의 이름 (ICU : Instruction Control Unit) 으로 부르긴 합니다만 본질은 같습니다.) 반면 PRF 기반 디자인을 사용한 대표적인 아키텍처는 인텔의 넷버스트이고, 지금 설명하고 있는 불도저 (1/2/3/4세대 모두) 역시 같은 방식을 사용합니다. 일단 각 디자인을 대표하는 아키텍처들의 면면으로 보아 대강 감(전자에 비해 후자가 훨씬 긴 파이프라인 스테이지를 가지며, 따라서 '상대적으로' 재정렬 버퍼식보다 PRF식 설계에 더 적은 트랜지스터가 투입될 것이라는 느낌적 느낌)이 오셨으리라 생각합니다. 이 설명은 엄밀히 말하면 정확하지 않지만, 아주 러프하게 보아 OoOE를 구현하는 방식이 몇 세대 전으로(=펜티엄 4 수준으로) 후퇴되었다고 보면 틀리지 않을 것 같습니다.

 

정리하자면 모듈 구조의 도입, 그럼에도 불구하고 작아진/퇴화된 L1 데이터 캐시 / 페치 버퍼 / 디코더 / OoOE 하드웨어로 불도저 프론트엔드의 특성을 요약할 수 있겠습니다. 특히 디코더가 수행하는 '디코드' 스테이지는 성능에 상당한 영향을 주기 때문에 아무리 백엔드가 좋아진다고 하더라도 태생적으로 성능상 한계를 안고 있는 설계라 할 수 있겠습니다. 비슷한 사례로 과거 넷버스트 아키텍처가 이와 비슷한 설계를 취한 적이 있었고, 당시 인텔이 목표한 바는 (다른 모든 부문을 축소해서라도) 파이프라인을 짧은 단위로 분절해 (=깊게 파서) 개별 파이프라인에의 체류시간을 짧게 하는 것, 다시 말해 클럭을 올리는 것이었고 이는 실제 불도저가 추구하던 것과도 유사한 측면이 있습니다. 차이점이라면 인텔은 테하스가 100W TDP를 돌파할 것으로 예측되자 과감히 넷버스트를 폐기했다는 점과 AMD는 기어이 220W TDP에 달하는 5GHz CPU를 출시했다는 점 정도랄까요.

 

다음은 3/4세대 불도저, 스팀롤러와 엑스카베이터의 프론트엔드 구조입니다.


 

그림이 갑자기 커진 것 같지만 긴장하지 맙시다. 사실 앞서 살펴본 1/2세대 불도저와 비교해 구조적으로 달라진 부분은 디코더 뿐입니다. 모듈 내 2개의 코어가 공유해 사용하던 4개의 디코더는 3/4세대에 접어들면서 각 코어당 4개로 정확히 두 배가 되었습니다. 또한 L1 명령어 캐시 역시 50%가량 증가해 96KB가 되었으며 이로 인해 캐시 미스가 30% 정도 감소했다고 (AMD의 자료에 따르면) 합니다. 과거 넷버스트나 지금의 불도저나 깊은 파이프라인이라는 공통점이 있고 이러한 설계에서 캐시 미스는 파이프라인 버블을 유발해 성능에 치명적인 악영향을 줍니다. 전체적으로 앞서 1/2세대의 프론트엔드를 살펴보며 지적했던 구조적인 약점을 보완하는 방향으로 노선을 잡은 것 같고 바람직한 개선이 이뤄졌다고 평가할 수 있겠습니다만, (1) 여전히 L1 데이터 캐시와 페치 버퍼 용량은 작고 / (2) 보다 근원적으로, 물리적으로 2코어분을 설계하는 자원을 아껴 '모듈' 구조를 도입한 것이 불도저의 탄생 이유인데 거기에 다시 자원을 투입해 2코어분에 가까운 하드웨어를 장착하게 된 것이 무슨 의미가 있는 걸까요. 그리고 백엔드의 약점은 아직 짚어 보지도 않았습니다.

 

아참, 깜박하고 넘어갈 뻔 해는데 디스패치 큐가 25%가량 증가해 각 코어당 40개의 마이크로옵을 저장할 수 있게 되었습니다.

 

다음은 -드디어- 오늘의 주인공, Zen의 차례입니다. 설명을 보기 전에 유출된 슬라이드를 먼저 보시죠.

 

 

위 슬라이드는 Zen이 엑스카베이터와 비교했을 때 어떻게 달라지는지 간단히 보여주고 있습니다. 다이어그램으로 드러난 것 외의 여백을 글쓴이의 상상력을 동원해 채워야 하는 시점인데, 아래 그림을 보시며 얼마나 그럴듯한 가정을 세웠나 한번 따져 보시기 바랍니다. Zen의 프론트엔드 추정 구조입니다.

 

 

AMD가 밝힌 (정확히는 내부자로부터 유출된) 슬라이드에 따르면 Zen은 지난 4년간의 흑역사 모듈구조를 버리고 다시 전통적인 설계로 회귀한 것이 특징입니다. 여기서부터의 추정은, 구조적인 복고(復古)가 동반된 부분에서는 과거 K10의 전례를 참조했으며 그렇지 않은 부분에 대해서는 직전 아키텍처인 엑스카베이터의 예를 참조해 이뤄졌음을 밝혀 둡니다.

 

우선 프론트엔드 쪽에서 명확히 밝혀진 것은 'Zen은 코어당 4개의 디코더를 탑재하고 있다' 단 하나뿐입니다. 모듈 구조를 폐기했으니 (모듈 구조 도입에 따라 변화했던) OoOE 하드웨어의 크기, L1 데이터 캐시 등이 필연적으로 바뀌어야 하며 '불도저 철학'의 설계에서 벗어난 만큼 페치 버퍼나 OoOE 하드웨어의 종류 등도 (보수적으로 생각하자면 과거 K10과 비슷한 모습으로) 바뀌었으리란 추측이 가능합니다. 일단 페치 버퍼는 K10과 동일한 크기인 32바이트로 복원시키고, PRF식 OoOE 설계에서 도입되었던 코어당 40 엔트리 디스패치 큐를 재정렬 버퍼로 변경하며 그 용량은 종전 72 엔트리보다 상향된 96~128 엔트리 정도가 될 것으로 보았습니다.

 

한편, L1 캐시 용량을 결정함에 있어 가장 간편한 가정은 '원래대로', 즉 K10처럼 L1 명령어 캐시 64KB + L1 데이터 캐시 64KB가 되는 것이었는데, 두 가지 가능성이 더 있어 보였습니다.

 

(1) L1 명령어 캐시 용량을 현행(엑스카베이터)대로 유지하는 것 : 모듈 구조의 단점을 만회하기 위해 어쩔 수 없이 늘린 것이라 해도 그로부터 얻은 이득이 뚜렷했던 것을, 차기 아키텍처에서 과감히 잘라낼 수 있을까 하는 의문이 들었습니다. 이 경우 L1 명령어 캐시를 96KB로 유지하고, L1 데이터 캐시를 (현 엑스카베이터 1모듈=2코어의 L1 데이터 캐시 용량 합인) 32KB로 두거나 48KB 정도로 상향할 가능성에 대해 고려해 보았습니다. 불도저를 설계할 당시, 전통적인 L1 명령어 : L1 데이터 비율인 1:1을 벗어나 명령어 캐시에 큰 비중을 둔 데에도 나름의 이유가 있었으리라 (예컨대 미래의 워크로드는 갈수록 명령어스트림의 비중이 커진다고 여겼으리라) 믿는다면, 이 믿음을 곧장 뒤집는 것도 그리 쉬운 결정은 아닐 것입니다.

 

(2) Zen의 캐시 계층 구조는 AMD의 전통적인 "Strictly Exclusive" 정책에서 벗어나 인텔과 같은 "Strictly Inclusive" 방식으로 전환되었습니다. 이 방식의 특성상 상위 계층의 캐시 용량이 하위 계층에 비해 거대할 필요가 없으며, 그간 AMD의 상대적으로 큰 L1 캐시 용량은 상당부분 그들의 exclusive 정책에 의한 것임을 고려할 때 Zen에서는 과거처럼 큰 L1 캐시를 달 필요가 없다는 생각도 해볼 수 있습니다. 이 경우 현재의 하스웰처럼 L1 명령어 / L1 데이터 캐시 모두 32KB 정도로 줄이는 것도 가능한 일이라 보았습니다.

 

따라서 이 모든 가정을 고려하여, L1 명령어 캐시는 32~96KB의 범위 내에서, L1 데이터 캐시는 32~64KB 가운데에서 결정될 것이라 가정했습니다.

 

일단 확실한 것만 논하자면, 클럭이 같을 경우 비슷한 구조를 가진 K10보다 같은 시간 동안 33% 더 많은 x86 명령어를 디코드할 수 있다는 점입니다. 앞서 과거의 K7과 P6이 매우 비슷한 IPC를 가졌었단 얘기를 했는데 (애슬론과 카트마이, 카퍼마인의 엎치락뒤치락하는 관계를 생각해 보면...) 공교롭게도 인텔이 넷버스트 이후 P6을 재도입하며 '코어' 마이크로아키텍처에서 수정한 부분이 바로 디코더를 하나 더 늘린 것이며, 그 이래로 AMD가 인텔과 약 30% 가량의 IPC 격차를 따라잡은 적이 없다는 사실은 매우 의미심장합니다. 프론트엔드의 역할은 백엔드에 끊임없이 연산할 마이크로옵을 공급해 주는 것이며, 백엔드가 충분히 빠르다는 가정 하에 프론트엔드의 개선이 큰 폭의 IPC 향상으로 이어지는 것은 CPU사(史)에서 흔한 일이었습니다.

 

불도저의 경우 모듈 내의 연산유닛들을 2코어 명목으로 공유해 사용했기 때문에 '백엔드가 충분히 빠르다'는 전제를 충족하지 못할 가능성이 있었지만, 모듈 구조를 폐기한 Zen에서 프론트엔드의 강화는 어떤 결과를 가져올까요. 상당히 흥미있는 대목이 아닐 수 없습니다. (이런 흥미로운 대목을 이렇게밖에 이야기하지 못하는 제 역량을 탓해 주세요 ㅠㅠ)

 

이제부터는 백엔드 구조를 살펴보도록 하겠습니다. 글의 절반이 끝난 셈이니 잠시 읽던 걸 멈추고 쉬셔도 좋습니다.ㅎㅎ

 

.

.

.

 

...자, 화장실 가셨던 분들 다 돌아오셨나요? 쉬는 시간 끝났습니다~

아래는 K8/K10의 백엔드 구조입니다.

 

 

K8/K10의 프론트엔드를 거친 마이크로옵은 최대 72개까지 재정렬 버퍼에 저장되어 있다가 적당한 시점에 각 스케줄러로 배분됩니다. K10은 3개의 정수/메모리 스케줄러와 3개의 부동소수점 스케줄러를 갖고 있으며 각각의 정수/메모리 스케줄러에는 정수연산유닛 한개, 주소생성유닛 한개가 쌍으로 묶여 있습니다. 즉 프론트엔드로부터 끊김 없이 마이크로옵이 공급된다는 가정 하에 K10의 백엔드는 사이클당 최대 3개의 정수 스칼라 연산 명령어 (IOPS), 3개의 부동소수점 정수/스칼라 연산 명령어 (FLOPS) 또는 정수 벡터 연산 명령어, 3개의 메모리 접근 명령어를 처리할 수 있으며 부동소수점 정수/스칼라 연산과 정수 벡터 연산은 서로 경합하는 관계에 있습니다.

 

총 9개의 포트는 각기 전능(plenipotency)하지 않고 명확히 구분된 역할을 갖고 있기에 전체 대역폭을 다 채울 상황은 많지 않아 보입니다만 각종 연산 명령어와 메모리 접근 명령어는 쌍으로 올 때가 많기에 이러한 경우의 병목현상이 최소화되게끔 설계되어 있다는 점에서 대단히 실용적인 백엔드를 가졌다고 볼 수 있겠습니다. 실제로도 AGU를 다른 연산유닛과 쌍을 이루는 것으로 계산하면 실질적으로는 6 이슈 포트 백엔드로 볼 수 있는데, P6부터 샌디브릿지에 이르기까지 인텔의 백엔드 역시 6포트 너비였다는 점이 단순한 우연의 일치는 아닐 것입니다. 한편 3개의 부동소수점 스케줄러에는 각각 한개씩의 부동소수점 연산유닛 (FPU) 이 연결되어 있습니다.

 

다음으로 1/2세대 불도저 모듈의 백엔드 구조를 보겠습니다.

 

 

앞서 살펴본 것과 같은 부분을 꼽아보는 것이 더 빠를 만큼 많은 부분이 변했(=빨간색으로 표시한 것)습니다. 다시 한번 하나의 모듈은 2개의 코어에 해당한다는 점을 상기하고, 위 그림을 찬찬히 뜯어 보도록 합시다.

 

우선 각 코어당 할당된 32 엔트리 디스패치 큐는 저장된 마이크로옵의 종류를 분류해 정수 스칼라 연산 명령어나 메모리 접근 명령어의 경우 자신이 속한 코어의 정수/메모리 스케줄러에 전달합니다. 부동소수점 연산, 정수 벡터 연산 명령어는 모듈 내에서 공유되는 부동소수점 스케줄러의 몫입니다. 이렇게 명령어를 받은 각 스케줄러는 다시 각각 4개의 이슈 포트에 연결된 하위 연산유닛에 마이크로옵을 내려보냅니다.

 

보시는 바와 같이 1개분의 코어가 사용할 수 있는 유닛은 정수 연산 유닛 두 개와 메모리 접근 유닛 두 개, 그리고 다른 코어와 경합해 가며 사용할 수 있는 부동소수점 연산 유닛 두 개, 정수 벡터 연산 유닛 두 개입니다. 이 수치만으로도 K10 대비 1코어당 사용가능한 자원은 거의 3분의 2꼴로 줄어들었음을 알 수 있는데, 설상가상 부동소수점 유닛들은 다른 코어와 공유하는 것입니다. 결국 K10 코어 2개와 불도저 모듈 1개를 비교하자면 정수 연산 대역폭은 3분의 2수준, 부동소수점 연산 대역폭은 3분의 1수준에 그치는 셈입니다. 물론 부동소수점 포트 자체는 4개로 K10의 3개 대비 33% 증가한 수치이며 (과거엔 부동소수점 연산과 정수 벡터 연산이 서로 경합하는 관계여서 어떻게 해도 이들 마이크로옵을 사이클당 3개 이상 처리하는 것이 불가능했지만, 불도저로 넘어오면서 FPU와 정수 벡터 유닛이 서로 다른 포트를 쓰게 되어 최적의 코드 하에서는 사이클당 4 마이크로옵의 처리도 가능해졌습니다.) 정수 벡터 유닛 중 한 개는 부동소수점 메모리 접근 전용으로 사용되기도 하며 실제로 K10의 3분의 1까지 성능이 추락하는 것만은 면했습니다.

 

그러나 불도저의 FPU나 정수 벡터 유닛이, 이러한 포트 배분을 '예견하고' 역할을 분리한 것이라 보긴 어렵습니다. 그보다는 불도저의 설계 철학(파이프라인 분절에 투입되는 것 이외의 모든 것을 간소하게)에 따라 K10의 개별 FPU를 경량화한 결과물이 그것이고, 포트를 분리한 것은 (그렇잖아도 경량화한 FPU를) 2개의 포트에 밀어넣을 경우 너무 처참해질 부동소수점 성능을 염려한 최소한의 조치로 받아들여집니다.

 

이렇듯 1/2세대 불도저는, 프론트엔드 측면에서도 K10 대비 3분의 2수준의 자원을 갖고 출발했으며 (디코더 3개 -> (코어당) 2개) 백엔드 역시 K10 대비 "최대" (최소가 아닙니다) 3분의 2 수준에 머물고 있습니다. 종합적인 성능 역시 같은 클럭에 같은 코어 갯수라면 K10보다 대부분 뒤떨어지는 성능을 보여 출시 당시로부터 현재까지도 많은 유저들에게 질타받고 있는 상황입니다. 이를 타개하기 위해 AMD는 프론트엔드를 개선한 3세대 불도저 스팀롤러를 작년 초 출시한 바 있습니다. 앞서 스팀롤러의 프론트엔드를 살펴보며, '이토록 개선되었는데 성능이 왜 안 올랐을까' 에 대해 고찰해 보자는 숙제를 남겨둔 바 있었고, 지금 그 숙제를 해야 할 것 같습니다. 아래는 3/4세대 불도저의 백엔드 구조입니다.

 

 

스팀롤러는 파일드라이버와 비교해서 프론트엔드가 상대적으로 많이 개량된 반면 백엔드의 변경은 극히 소폭에 그치고 있습니다. 디스패치 큐의 용량이 각각 32 엔트리에서 40 엔트리로 25% 증가했고, 정수/메모리 스케줄러의 용량 역시 40 엔트리에서 48 엔트리로 20% 증가했으며, 그림에는 드러나지 않았지만 FPU들 / 정수 벡터 유닛들 간의 역할 분담을 재조정해 더 높은 효율을 낼 수 있도록 했다고 합니다. (아마 FSTORE 전담유닛제를 폐지하고 모든 FPU가 메모리 계층에 접근할 수 있게 한 것이 아닌가 추측됩니다.) 한편 4개까지 있어봐야 별 필요도 없던 (...) 부동소수점 스케줄러의 네 번째 포트를 폐지하고, 대신 유닛 자체는 4개를 모두 남김으로써 3 포트에 선점적(pre-emtive)으로 4 유닛 중 3개를 배정하는 조치를 취했는데 이는 트랜지스터 수와 면적을 줄이기 위한 조치였다고 합니다. 포트를 줄였음에도 불구하고 각 유닛간의 밸런스 최적화 등으로 인해 (그리고 프론트엔드의 개선에도 힘입어) 스팀롤러의 부동소수점 성능 자체는 동 클럭의 파일드라이버를 10+a% 가량 안정적인 갭으로 상회하게 되었습니다.

 

그러나, 스팀롤러의 성능이 크게 향상되었다고 말하면 십중팔구는 그대로 믿지 않을 것입니다. 그 이유는 크게 두 가지입니다.

 

(1) 1/2세대 불도저의 성능이 너무 낮았다 (...) : 실제로 스팀롤러 자체는 동 클럭의 파일드라이버보다 10~20% 가량 오른 성능을 보여줍니다. 문제는 '동 클럭'을 달성하기 어려워져서 같은 급의 SKU라면 파일드라이버보다 항상 10% 정도 낮은 클럭을 갖게 된 점인데, 이 때문에 결과적으로는 거의 성능향상이 없게 되었단 점과 앞선 세대의 불도저가 너무 성능이 낮았던 탓에 조금 오른 정도로는 성능향상의 '티' 가 나지 않았다는 점이 스팀롤러를 위한 변명이 되지 않을까 합니다.

 

(2) 프론트엔드 보강이 효과를 보기엔 백엔드가 너무 빈약했다 : 앞에서 수차례 언급했듯 프론트엔드는 백엔드에 마이크로옵을 공급해 주는 기능을 수행합니다. 다시 말해 프론트엔드의 성능은 높은 성능 발휘를 위한 필요조건이지 충분조건은 아니란 뜻인데, 어디까지나 연산을 수행하는 것은 백엔드란 점을 잊어서는 안 되겠습니다. 물론 백엔드의 성능이 너무나 좋아 대부분의 마이크로옵 공급량을 빠른 시간 내에 처리해 버리고 대부분의 시간을 놀고 있는 상황이라면 프론트엔드의 확장이 큰 성능향상을 가져다 주겠지만 불도저의 백엔드가 과연 그러한 상황이었는지 냉정히 따져봐야겠죠.

 

1/2세대 불도저는 모듈당 4개의 디코더를 가지고 있었고 3세대 들어 이것을 '코어당' 4개로 두 배 늘렸습니다. (프론트엔드 파트에서 언급했듯 L1 명령어 캐시 용량도 50% 늘렸지만 여기서는 따로 다루지 않겠습니다.) K10과 비교하더라도 33%가 더 많습니다. 반면 코어당 백엔드 유닛 수는 K10 대비 3분의 2수준으로 감소한 상황인데, 아주 러프하게 디코더 하나가 먹여살려야(=feeding) 하는 백엔드 유닛 수를 따져 보면 K10이 9/3=3개, 1/2세대 불도저가 6/2=3개, 3/4세대 불도저가 6/4=1.5개가 됩니다. 디코더가 1개의 x86 명령어를 디코드한 결과물이 2 마이크로옵의 결합체인 '매크로옵' 임을 고려하면 앞의 비율은 2에 근접하게 되는 것이 바람직한데, 스팀롤러는 이미 그보다 낮은 값을 갖고 있습니다. 다시 말해 디코더 증가분이 별로 효과를 얻지 못할 상황인 것입니다.

 

한가지 흥미로운 점은 스팀롤러와 정 반대의 노선을 걸은 것이 바로 인텔의 하스웰이란 점입니다. 상대적으로 약체인 백엔드를 두고 프론트엔드를 강화한 스팀롤러와 달리 하스웰은 수년간 변함없이 사용되어 온 프론트엔드를 유지한 채 백엔드 포트 수를 33% 늘렸습니다(6개 -> 8개). P6 기반 아키텍처의 (그리고 큰 틀에서, K7 기반 아키텍처의) 프론트엔드 : 백엔드 구성이 일종의 황금비처럼 여겨지는 가운데 하스웰 역시 큰 성능향상을 얻지 못하며 이러한 가정을 한층 강화시킨 바 있습니다. 그러나 이는 더 큰 가능성을 시사하는 것이기도 합니다. 현 단계에서는 백엔드를 늘림으로써 '황금비'에서 이탈하게 되었지만, 다음 단계에서 프론트엔드를 늘려 다시 황금비를 달성한다면...? 실제로 스카이레이크는 인텔이 코어 마이크로아키텍처 이래 9년간 고수해 온 4 디코더 프론트엔드를 대폭 확장할 것으로 알려져 있고, 스팀롤러의 경우와 달리 든든한 백엔드가 뒷받침되는 프론트엔드의 개선은 곧 큰 성능향상으로 이어지리란 가정도 가능합니다.

 

애초 AMD가 모듈 구조를 도입하며 의도한 모든 과녁(높은 효율, 높은 멀티스레드 성능, 낮은 소비전력)이 빗나가버린 가운데 '불도저 개량 로드맵' 으로 이미 4년 전부터 제시되었던 파일드라이버 / 스팀롤러 / 엑스카베이터의 투입 모두 결국 인상적인 성능향상을 가져오는 데에는 실패했다고 봐야겠습니다. (사실 성능향상폭 자체는 불도저 -> 파일드라이버에서 10% 가량, 파일드라이버 -> 스팀롤러에서 10+a% 가량으로 꽤 견실한 편이었습니다. 같은 기간 샌디브릿지 -> 하스웰에 이르는 성능 정체를 감안하자면 더더욱 그렇죠.) 4년 연속 / 4개 아키텍처 연속으로 쓴맛을 본 AMD의 마지막 희망이 Zen에 걸린 셈입니다. 바로 오늘의 주인공, Zen의 백엔드 구조를 보겠습니다.

 

 

앞서 Zen의 프론트엔드 파트에서 다루었듯 모든 예측은 '전례'에 기반해 최대한 보수적으로 잡는 것을 원칙으로 했습니다. 유출된 다이어그램 상에는 정수 파이프라인이 6개로 표시되어 있고, 이를 장미빛으로 아전인수하자면 인텔식의 "6포트 정수유닛" 으로 받아들일 수도 있겠으나 최대한 AMD의 전례를 따라 3 정수 연산 유닛 + 3 메모리 접근 유닛으로 가정한 것 역시 그러한 마음가짐의 일환입니다.

 

위에서 스팀롤러의 '오버', 그리고 하스웰의 '준비'를 대비해 이야기를 풀어 보았는데, 여기서 얻을 수 있는 교훈은 (1) 황금비를 준수해야 한다 (괜히 P6 / K7이 장수한 게 아닙니다) / (2) Zen이 K10보다 늘어난 디코더를 갖는 만큼 백엔드의 확장도 동시에 이뤄져야 성능향상을 극대화할 수 있으리라는 점입니다. 다만 아직까지 밝혀진 바에 따르면 AVX 부동소수점 연산을 하는 경우가 아니면 종전 K8/K10, 인텔 코어~샌디브릿지 수준의 백엔드 대역폭 이상을 기대할 수는 없을 것 같습니다.

 

여기서도 "확실히 드러난 것" 위주로 언급하자면 정수 포트가 6개가 되었다는 점, 각 스케줄러가 K10처럼 세분화되지 않고 불도저처럼 'Unified' 형태로 존재한다는 점, 그리고 FMAC 스트림 폭이 128bit에서 256bit로 확장되었다는 점입니다. 과거 불도저가 128bit FMAC 유닛 두 개로 256bit AVX 명령어를 사이클당 한 개 비율로 처리할 수 있었던 점을 고려할 때 (=AMD FlexFP) Zen 역시 512bit AVX2 명령어를 2개의 256bit FMAC를 통해 사이클당 한 개 비율로 처리할 수 있으리라 생각됩니다.

 

다만 부동소수점 연산 유닛에 배정된 포트 자체는 K10보다 33% 줄어든 두 개에 그치고 있어, AVX가 아닌 x87 / 128bit SSE 명령어의 경우 K10 대비 67%에 그치는 스루풋을 보일 것으로 예상됩니다. 이 부분을 보다 실감나게(?) 알아보기 위해 간단한 계산값을 준비했습니다 : 아래의 표들을 보시죠.

 

 

위의 표는 각 CPU별로 클럭, 코어 갯수, (코어당) 백엔드 정수 연산 유닛 갯수를 곱한 것입니다. Zen을 제외한 나머지 셋은 현존하는 SKU로 각각 스팀롤러, 파일드라이버, K10을 대표하는 4코어 제품들이며 Zen의 클럭은 파일드라이버 기반 SKU와 동등한 수준이 될 것이라 가정했습니다. 결과를 간단히 분석하자면 모든 코어를 사용할 때 스팀롤러보다 최대 50% 더 높은 정수 연산 성능을 보일 수 있으리라는 것인데... 너무 뻔하죠? ^^;

 

 

위의 세 개의 표는 각 명령어 세트별 부동소수점 연산 성능을 계산한 것입니다. x87 / 128bit SSE 연산성능은 정확히 FPU 포트 갯수에 비례해 계산되었고, AVX의 경우 불도저 계열의 성능이 최악으로 떨어지는 것을 볼 수 있습니다. FlexFP는 128bit FMAC 두 개로 AVX 명령어를 처리하게 해줄 따름이지 '각 FMAC 유닛마다 AVX를 처리' 한다거나 'AVX를 두 배 빠르게' 처리하는 기술이 아니기 때문입니다. 달리 말하자면 불도저의 FPU에는 AVX 유닛이 단 한 포트 열려 있는 것과 마찬가지이고, 그러한 약점이 위의 수치로 드러난 것이라 볼 수 있습니다. 반면 Zen은 256bit FMAC 포트를 두 개 가지고 있으며 각각의 코어가 독립적으로 온전한 FPU를 보유하고 있어 재차 불도저보다 강점을 가집니다.

 

 

위의 표는 AVX와 FMA (Fused Multiply and Add) 최적화 시나리오를 가정해 본 것입니다. 현실적으로 완벽히 이상적인 위와 같은 결과는 보기 어렵겠지만,

 

 

...위와 같은 '일부 최적화' 결과는 상대적으로 흔히 볼 수 있으리라 생각합니다. (위 두 표 중 위의 표는 AVX와 FMA에 각각 20%씩 최적화된 워크로드, 아래는 50%씩 최적화된 워크로드 가정입니다.)

특히 20% 최적화 시나리오는 현실적으로 비슷한 성능이 나타나리라 기대해봄직한 것이기도 한데, 바로 <하스웰의 모든 것 : 아키텍처편> 에서 아래와 같은 결과를 얻은 적이 있기 때문입니다.

 

 

네할렘 대비 16%가량 높은 샌디브릿지의 성능, 샌디브릿지 대비 5%가량 높은 아이비브릿지의 성능, 아이비브릿지 대비 8%가량 높은 하스웰의 성능...

그럴듯하지 않나요?

 

지금까지 살펴본 시나리오를 바탕으로, 가장 보수적이고 '그럴듯' 하다고 여겨지는 '20%-20% 최적화 시나리오'에 근거해 다른 표를 하나 만들어 보았습니다.

바로 최상위 Zen이 취할 것으로 여겨지는 8코어 SKU에 대한 가정입니다.

 


스팀롤러와 Zen의 8코어 SKU는 각각 FX-8370의 클럭에 준하는 것으로 가정하고 대입해 본 것입니다. Zen은 3코어 로드까지는 페넘 II X6 1100보다 다소 떨어지는 (근소한 차이이지만) 성능을 보이지만 4코어부터는 역전하기 시작하고, 무엇보다 불도저들과 다른 '네이티브 8코어' 라는 점에서 코어 갯수가 늘어날수록 견실한 성능 향상을 보일 것으로 예상되었습니다. 최종적으로는 페넘 II X6 1100보다 36%가량 향상된 멀티코어 성능을 보이리란 추측입니다.

 

예측이 다소 보수적으로 이뤄졌기 때문에 'Zen의 성능이 이것밖에 안 돼?' 하는 생각이 드신 분들도 많으시겠지만, 일단은 이렇게 접근해 보는 어프로치 자체가 재미있는 것 아닐까, 거기에 이 글의 존재가치가 있는 것 아닌가 하는 생각을 해 보았습니다. 개인적으로 만 4~5년만에 글을 다시 쓰려니 머리에 쥐가 나는 것 같기도 했고 한편으로는 무척 재미있었습니다. 읽고 계신 독자 여러분께도 이 글이 재미있게 읽혔길 바랍니다.

 

긴 글 읽어주셔서 감사합니다 :)

 

//

 

아래 '밀어주기'는 티스토리의 크라우드펀딩 시스템입니다. 100원부터 3000원까지의 범위 내에서 글쓴이에게 소액 기부가 가능합니다. 제가 작성한 글이 후원할만한 가치가 있다고 여기신다면 밀어주기를 통한 후원을 부탁드립니다. 물론 글을 '가치있게' 쓰는 것은 저의 몫이며, 설령 제 글이 후원할 만큼 가치있게 여겨지지는 못하더라도 그것이 독자 여러분의 잘못이 아니란 건 너무 당연해 굳이 언급할 필요도 없겠습니다. 저는 후원 여부와 관계없이 제 글을 읽어주시는 모든 독자분께 감사합니다.

 

 

 

IYD's Signature

적용중인 트로피가 없습니다.

DR.MOLA

레벨 Lv. 2 (31%)
포인트 501 p
출석 11 일 (개근 0 일)

IYD'님의

  1. zen_03_k10_front.png (File Size:38.5KB/Download:0)
  2. zen_14_fullopt.png (File Size:7.5KB/Download:0)
  3. zen_99_haswell.png (File Size:15.4KB/Download:1)
  4. zen_04_bulldozer_front.png (File Size:45.2KB/Download:0)
  5. zen_16_sku_assumption.png (File Size:26.7KB/Download:0)
  6. zen_00_intro.jpg (File Size:208.1KB/Download:0)
  7. zen_12_iops.png (File Size:6.9KB/Download:0)
  8. zen_13_flops.png (File Size:30.8KB/Download:1)
  9. zen_06_zen_edit.png (File Size:70.0KB/Download:2)
  10. zen_02.png (File Size:69.8KB/Download:0)
  11. zen_05_steamroller_front.png (File Size:56.9KB/Download:0)
  12. zen_08_bulldozer_edit2.png (File Size:0Byte/Download:0)
  13. zen_15_partiallyopt.png (File Size:14.9KB/Download:0)
  14. zen_01.png (File Size:43.3KB/Download:0)
  15. zen_11_zen_back.png (File Size:60.5KB/Download:0)
  16. zen_07_k10_back.png (File Size:55.7KB/Download:0)
facebook twitter google plus pinterest kakao story band
Profile image widow7 2015.05.10 07:18
암드를 쓰면 암 걸릴 것 같다는 농담도 있는데, 전 개인적으로 암드 cpu에는 아무 불만 없이 써서 만족하는 편입니다. 다만 주변 부품이 인텔쪽 부품보다 못하다는 인상이 있어, 결국 인텔로 돌아오긴 했지만 그래도 암드가 잘 되기를 바랍니다. 암드가 잘 돼야 소비자들이 좀더 저렴한 cpu를 쓸 수 있을 거 같으니까....암드팬이든 인텔팬이든 말입니다.
수정 삭제
Profile image IYD 2015.05.10 15:59
동감입니다. 읽어 주셔서 감사합니다~^^
Profile image JHLee 2015.05.10 15:49
오 안그래도 제가 궁금했던 부분이었는데 이런 글로라도 접할 수 있으니 정말 좋네요. 군에서 열심히 읽었던 현대 CPU의 구조가 다시 떠오르네요
수정 삭제
Profile image IYD 2015.05.10 16:01
인트라넷 상에서도 5년만에 새 버전으로 업데이트가 되어야 할텐데...ㅋㅋㅋㅋㅋ
Profile image MYkim 2015.05.11 11:18
댓글은 안달지만 항상 재밋게 보고있습니다.
수정 삭제
Profile image IYD 2015.05.12 00:30
감사합니다!! (댓글을 남겨 주면 더 감사했을텐데, 이 댓글로 감사받을 요건을 충족하셨으니 드리는 감사입니다 ㅋㅋㅋ) 글이 재미없어서 걱정인데 재미있게 봐 주셨다는 분이 계셔 힘이 나는군요. 앞으로도 자주 새로운 글로 찾아뵐테니 종종 들러 주시길 바랍니다 :D
Profile image 여우비 2015.05.12 09:47
어떻게 보면 이건 최소치로 잡은거니 Zen 아키텍쳐에 대한 기대가 더 커지는 것 같네요.
수고하셨습니다.
수정 삭제
Profile image IYD 2015.05.12 15:06
감사합니다 :)
Profile image 바리엘 2015.05.14 04:05
항상 좋은 글 잘 읽고 있습니다^^
이번 암드만큼 인텔 스카이레이크도 만만찮게 발전을 한 것 같던데요, 경쟁이 될 만큼 서로 잘 나와줬으면 좋겠네요 ㅎㅎ
수정 삭제
Profile image IYD 2015.05.14 13:37
감사합니다! 스카이레이크가 얼마나 성능이 향상됐을지 기대됩니다... :D
Profile image ndd247 2015.06.12 14:35
최신 CPU 아키텍처를 정확하게 이해하는 사람이 별로 없는데, 대단하시네요. 뭐하시는 분인지 살짝 궁금합니다.ㅎㅎ

그건 그렇고 저는 성능최적화 업무를 해서 그런데, 제가 겪어본 최신 CPU 에서는 decode 가 성능 저하를 일으키는 경우는 드뭅니다. MSROM 을 참조해서 에뮬레이션으로 돌아야하는 명령어를 자주 쓰지 않는 한 말이죠. 그럴 수 밖에 없는게, load 에서 L1 hit 이 된다고 해도 3~4 clock latecny 는 발생할 뿐더러 의외로 많은 명령어가 latency/throughput 에서 매클럭마다 꼬박꼬박 실행될 수 있는게 아니다보니, 비대칭 포트가 6개라해도 평균적으로 1 clock 에 실행될 수 있는 명령어수는 훨씬 적습니다. 더구나 포트는 u옵을 실행하는거고, decoder 는 x86옵을 하나 디코드하면 u옵이 2-3개 나올수도 있고 u옵 버퍼까지 있으니, 프론트엔드는 amortized 로 백엔드가 실행되는 속도에 맞추어 u옵을 간신히 공급만 할 정도면 충분하죠. 그래서 심지어 silvermont 같은 임베디드CPU 는 데스크탑CPU 보다 백엔드 성능이 한참 떨어지니 듀얼이슈디코더로 땡입니다. 외계인을 고문해서 백엔드 성능을 왕창 향상시켰더니 decode 가 못따라간다, 그럼 먼저 u옵 버퍼를 증가시켜서 때워보고 그래도 안되면 그때서야 decoder 증설하는 식이죠.

AMD 는 파일드라이버에서 FP 공유구조로 트랜지스터를 줄였으면 그 트랜지스터를 재투자해서 INT 던 FP 던 백엔드 실행성능을 왕창 끌어올렸어야 했습니다. 처음의 AMD 발표도 그렇게 하겠다는 것 같았고요. 그런데 실제 결과에서는 그게 안되었죠. 그게 패착이라고 봅니다. 그리고 그게 안되었는데, 엉뚱하게 decoder 쪽에 트랜지스터 투자하는건 해결책이 될 수 없음은 자명한거고요. 하여간 저도 젠은 제대로 될 물건으로 나왔으면 좋겠습니다.
수정 삭제
Profile image IYD 2015.06.12 22:44
어우 과찬이십니다. 읽어 주셔서 감사하고...
제 주업은 학생이고, 부업으로 ITCM에서 이런 글을 쓰고 있습니다 :)
Profile image 낄낄맨 2015.06.14 09:07
AMD 팬인데요.. 이번에는 AMD가 꼭 선전을 해주었으면 합니다. 하이퍼 쓰레딩 같은 기술도 넣는다고 하니 기대 만빵입니다. 화이팅~!!! AMD 포스팅 잘 봤습니다.
수정 삭제
Profile image IYD 2015.06.16 14:13
감사합니다!!
Profile image 안강일 2015.10.04 18:23
그럼 zen은 SSE나 정수연산을 간소화하고 FMAC를 불도저의 두배로 넣은 구조인건가요?
그럼 AMD가 언급한 40% 향상은 AVX 성능이고 나머지는 네할렘 정도에 그칠 수도 있겟네요.
AMD는 대체 뭘 만들려는 걸까요 0_0? 그래픽 코어와 함께 엄청난 수준의 FP 연산머신을
만들려는 걸까요?
수정 삭제
Profile image IYD 2015.10.05 01:16
SSE는 부동소수점 벡터 확장입니다. 위 그림에서 FMAC / AVX로 묶어 언급한 사각형 하나가 마찬가지로 SSE 하나에도 대응합니다. (불도저의 경우 2개의 SSE대응 유닛이 묶음으로 AVX에 대응했기에 따로 그렸지만...) 즉 위 그림에서 가정한 바를 따라 Zen 1코어와 불도저 1모듈을 비교하자면 SSE의 사이클당 스루풋은 128bit x 2로 동일합니다. 하지만 AVX는 불도저가 256 x 1인데 비해 Zen은 256 x 2로 두배 늘어납니다.

정수연산의 측면에서는, Zen 1코어와 불도저 1모듈을 비교하면 전자가 사이클당 3 IOPS / 후자가 4 IOPS이니 줄어들었다고 볼 수 있지만 불도저 1코어 (반 모듈) 와 비교하면 이쪽이 2 IOPS이니 50% 증가한 것으로 볼 수 있습니다. 물론 이 계산들은 프론트엔드의 영향이라든지, 백엔드/프론트엔드 이외 (언코어) 부분의 영향이 배제되어 있어 최종적으로 Zen의 성능을 가늠하기엔 부족함이 많습니다. 40%라는 숫자는 어디서 튀어나온 건지 무척 궁금... ㅇ_ㅇ

일단 보수적으로 보자면, 위에서 살펴본 것 중 부동소수점 (특히 AVX) 의 스루풋이 +100% 향상으로 가장 컸으니 그 부분이 기타 여러 요소에 의해 닳고 닳아 +40%가 되지 않았을까 싶습니다. 현재 인텔보다 AMD의 IPC가 30%가량 떨어진다고 여겨지는데 이를 뒤집으면 AMD 입장에서는 40%가 상승해야 인텔과 비슷해지는 것이고 (7 x 1.4 = 10) 마침 사이클당 2 AVX 스루풋은 샌디=하스웰=스카이레이크와 동일한 수준이 되는 것이니 그래야 말이 되지 않을까... 하는 게 제 추측입니다.ㅎㅎ
Profile image 대파 2015.10.05 20:27
안녕하세요. 대근님. 1일 1출석하는 눈팅유저인데..
제 군시절 고참이랑 이름이 같으시군요.. 그분은 02군번이시던데 혹시??

wccftech.com/amd-zen-cpu-core-microarchitecture-detailed/2/

여기에 젠 백엔드구조가 몇시간전에 나온거 같은데
간단이 요약하면 4 ALU, 2 AGU, 4 FP 로 총 10개의 파이프라인을 가진다.. 라는데..
뭔말인지 모르겠다 그냥 가만히 있어야겠다.. 를 시전하다가

도와줘요 스피드웨건!을 사용합니다....

근데 인텔 8코어가 제일 싼게 80만원대에 있는데..
30만원대 기대하는 사람들이 많군요..

AMD는 그냥 i5가격대에 한단계 높은거 팔아도 장사 잘될꺼 같네요 ㅎ;;
수정 삭제
Profile image IYD 2015.10.05 21:38
WCCFTech의 분석은 FPU 부분은 저와 같고 (바로 윗 리플의 댓글에 좀더 상세히 언급되어 있는데, 완전히 똑같습니다) 정수/메모리 접근 유닛 분배에 관해 저는 3:3, WCCFTech는 4:2로 예상한 차이가 있습니다. 아직 정확한 구조가 나오지 않은 만큼 저도 예상이 엇갈리는 부분에 대해서는 잘 모르겠습니다 ^^;

그리고 저는 11군번입니다 ㅋㅋㅋㅋㅋ
Profile image apu만쓸거야 2016.01.07 14:18
근래에 나온 amd apu를 보면 cpu와 다중 그래픽 코어를 이용한 병렬 처리쪽에 더 신경을 쓰고 있는걸로 보이는데, amd가 gpu 드라이버와 소프트웨어를 오픈소스화 한다는 기사도 있더라구요. 이 기술이 모든 부분에 보급이 된다면 AMD apu와 일반 인텔 apu, AMD cpu와의 성능 차이가 많이 나지 않을까요?
수정 삭제
Profile image 암드야 아프지마 2016.05.06 22:49
이렇게 좋은글을 늦게 보게 되었네요 5년째 투반쓰고 있는 암드 유저입니다. 이번엔 제발 좀 나름 선방하면 좋겠습니다
수정 삭제
  • 가격인하로 재조명된 레이븐 릿지 : 기업용 PC, 지금은 맞고 그때는 틀리다 [CPU] 가격인하로 재조명된 레이븐 릿지 : 기업용 PC, 지금은 맞고 그때는 틀리다 [3] file

    Zen 아키텍처가 등장한지 11개월만인 지난 2월, AMD는 드디어 APU 시장에 라이젠 브랜드를 투입하기 시작합니다. Zen과 Vega가 결합된 레이븐 릿지가 바로 그것이었습니다. 뛰어난 CPU / GPU 성능 밸런스와 가성비로 주목받으며 닥터몰라의 리뷰(링크)에서도 '드디어 AMD가 진검승부를 시작했다' 고 총평했었는데요. 그랬던 ...

  • 틱틱, 톡, 틱틱틱, 톡 : 느려지는 인텔 시계, 구원투수로 투입되는 커피레이크 [CPU] 틱틱, 톡, 틱틱틱, 톡 : 느려지는 인텔 시계, 구원투수로 투입되는 커피레이크 [7] file

    빅 뉴스. 인텔의 2016-2018년 모바일 CPU 로드맵이 유출되었다. 그동안 베일에 싸여 있던 10nm 캐논레이크Cannonlake의 존재가 공식화된 한편 캐논레이크의 수율이 안정화될 때까지 임시로 투입할, 케이비레이크Kaby Lake의 2차 최적화 버전격인 커피레이크Coffee Lake의 존재가 새롭게 드러났다. 커피레이크는 케이비레이크...

    • Dr.Lee |
    • 16.09.26 |
    • 조회 수 2349 |
  • i7 6950X의 가격 정책에 관한 소고 [CPU] i7 6950X의 가격 정책에 관한 소고 [4] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 지난주 공개된 인텔의 새 익스트림 에디션, 코어 i7 6950X는 여러 면에서 그동안의 궤를 벗어나 있는 제품이다. 코어 갯수가 늘었다거나 그에 따라 '전례없는' 성능을 가졌단 얘긴 결코 아...

    • IYD |
    • 16.06.07 |
    • 조회 수 337 |
  • 인사이드 메모리 : 램타이밍, 클럭, DDR 규격별 분석 [CPU] 인사이드 메모리 : 램타이밍, 클럭, DDR 규격별 분석 [15] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) (image source : Micron Crucial) 오늘날 컴퓨터 하드웨어의 발전속도가 정체되었음을 시사하는 지표는 한두 가지가 아닙니다. 익숙한 인텔 CPU는 벌써 몇 세대째 한자릿수의 성능향상률을...

    • IYD |
    • 15.10.06 |
    • 조회 수 2335 |
  • 제온의 모든 것 : (1) 이론편 [CPU] 제온의 모든 것 : (1) 이론편 [16] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 1. A Brief History of Xeon 안녕하세요 독자 여러분. 오늘은 벌써 반년 전 약속한 + 예고편을 올린지도 벌써 한달이 되어가는 제온 리뷰를 보여드릴 차례입니다. 오랜 기다림 끝에 내놓은...

    • IYD |
    • 15.06.01 |
    • 조회 수 172 |
  • AMD Zen 미리보기 : 현대 CPU의 구조 2015 [CPU] AMD Zen 미리보기 : 현대 CPU의 구조 2015 [20] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 안녕하세요 독자 여러분. 오랜만에 글다운 새 글을 들고 여러분을 찾아뵙게 되어 기쁜 글쓴이입니다. 이 글은 며칠 전 있었던 AMD의 주주총회와 거기에 뒤따라 개최된 Financial Analyst D...

    • IYD |
    • 15.05.08 |
    • 조회 수 268 |
  • L3 캐시가 게임성능에 미치는 영향 [CPU] L3 캐시가 게임성능에 미치는 영향 [4] file

    Author : Daeguen Lee (Any action violating either CCL policy or copyright laws is strictly prohibited) 그제 BEST CPU FOR GAMERS 12월호를 등록하며 드린 약속을 지키게 되었습니다. 공언했던 새 글을 기한 내에 소개하는 게 참 오랜만입니다. 우선 이 글의 기원에 관해서는 BEST CPU FOR GAMERS 12월호 마지막 문단...

    • IYD |
    • 14.12.07 |
    • 조회 수 403 |
  • 하스웰의 모든 것 : 실전편 [CPU] 하스웰의 모든 것 : 실전편 [8] file

    Author : Daeguen Lee (Any action violating either CCL policy or copyright laws is strictly prohibited) ※ 재미없음 주의 지난 글에서는 아키텍처 레벨에서 하스웰이 어떤 변화를 가져왔는지 간단히 살펴보았습니다. 인텔로서는 코어 마이크로아키텍처 이래 처음으로 백엔드 대역폭을 넓히는 모험을 감행했다는 점과 그...

    • IYD |
    • 14.11.03 |
    • 조회 수 91 |
  • 하스웰의 모든 것 : 아키텍처편 [CPU] 하스웰의 모든 것 : 아키텍처편 [10] file

    Author : Daeguen Lee (Any action violating either CCL policy or copyright laws is strictly prohibited) 오랜만에 새 글을 올립니다. 이 블로그의 시작이 된 글이기도 하고, 엄청난 손가락노동을 기꺼이 감수한 한 독자분 덕분에 국방망(군용 인트라넷) 내에까지 전파되어 여러 군인 독자들과 저를 연결해 준 글이기도 ...

    • IYD |
    • 14.10.31 |
    • 조회 수 190 |
  • [CPU] 마침내 게이머가 이겼다 : 하스웰-E를 생각하며

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 오늘 새벽 공식 출시된 하스웰-E의 각 라인업을 전세대 카운터파트인 아이비브릿지-E와 SKU 대 SKU로 비교했을 때, 인텔 코어 i7 (이하 모델넘버 앞 "인텔 코어 i7" 부분 통째로 생략. 이 ...

    • IYD |
    • 14.08.30 |
    • 조회 수 70 |
  • A short essay on "Kaveri" [CPU] A short essay on "Kaveri" [13] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 사실 "Future is fusion" 이라는 AMD의 슬로건에서부터 예견되었던 것이기도 하지만 CPU+GPU 이종교배의 진정한 힘은 다이사이즈 축소를 통한 원가절감 따위를 훨씬 상회하는 것이리라. Ma...

    • IYD |
    • 13.11.27 |
    • 조회 수 52 |
  • [CPU] 잊혀진 아키텍처들 (예고편) [22] secret

    비밀글입니다.

    • IYD |
    • 11.10.17 |
    • 조회 수 5 |
  • 파이프라이닝의 이해 [CPU] 파이프라이닝의 이해 [22] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) (그림 출처: 위키피디아)명령어가 수행되는 과정을 아래와 같다고 칩시다.인출 - 디코드 - 실행 - 쓰기(완료)이 네가지 과정은 각각 해당 과정의 기능에 맞는 하드웨어에 의해 수행되고이...

    • IYD |
    • 11.03.02 |
    • 조회 수 330 |
  • 멀티스레딩 기술의 이해 [CPU] 멀티스레딩 기술의 이해 [53] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 오늘은 현대 CPU의 성능향상 기법 중 하나인 SMT에 대해 간단히 알아 보겠습니다.SMT는 Simutaneous Multi-threading의 약자로, 동시에 여러 스레드를 처리하는 기법을 통칭합니다.CPU의 ...

    • IYD |
    • 11.02.05 |
    • 조회 수 326 |
  • 현대 CPU의 구조 : 프론트엔드 편 [CPU] 현대 CPU의 구조 : 프론트엔드 편 [36] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) Tweet 얼마 전 백엔드 구조를 중심으로 현대의 CPU에 대해 알아 보았습니다.(현대 CPU의 구조 강좌 <백엔드 편> ☞ 여기)이번 강좌에서는 그때 설명하지 않고 남겨둔 프론트엔드에 대해 간...

    • IYD |
    • 11.01.22 |
    • 조회 수 336 |
  • 현대 CPU의 구조 : 백엔드 편 [CPU] 현대 CPU의 구조 : 백엔드 편 [56] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) Tweet 오늘날 컴퓨터는 다양한 형태와 기능을 갖추고 인간의 생활을 도와주고 있습니다.재미있는 점은 컴퓨터들이 쓰이는 용도나 형태가 천차만별임에도 그 기본 원리는 거의 같다는 점입...

    • IYD |
    • 11.01.22 |
    • 조회 수 489 |
  • 오버클럭의 공학적 배경 [CPU] 오버클럭의 공학적 배경 [26] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) Tweet 흔히, "오버클럭을 하면 소비전력이 늘어나기 때문에 전압을 더 줘야 한다" 고 생각합니다.하지만 과연 이게 맞는 명제일까요?만약 위의 명제가 참이라면 오버클럭시 CPU의 요구전압...

    • IYD |
    • 11.01.14 |
    • 조회 수 159 |
  • 현대 CPU의 구조 : 메모리 계층 구조와 성능 [CPU] 현대 CPU의 구조 : 메모리 계층 구조와 성능 [9] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 1. Introduction앞서 작성했던 두 '현대 CPU의 구조' 강좌의 속편입니다. 무려 7개월 만의^^;- 현대 CPU의 구조 -백엔드 편-: http://iyd.kr/57- 현대 CPU의 구조 -프론트엔드 편-: http:/...

    • IYD |
    • 10.11.24 |
    • 조회 수 353 |
  • [CPU] Tightening tRFC : DRAM Refresh Cycle secret

    비밀글입니다.

    • IYD |
    • 10.10.27 |
    • 조회 수 1 |
  • [CPU] Memory Overclocking via D.O.C.P. [7] secret

    비밀글입니다.

    • IYD |
    • 10.09.09 |
    • 조회 수 3 |