mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-03-06 00:17:12

AMD 불도저 마이크로아키텍처

AMD 파일드라이버 마이크로아키텍처에서 넘어옴

||<table bordercolor=black><table width=100%><bgcolor=white> 파일:AMD 로고.svg x86 CPU 마이크로아키텍처 ||
{{{#!wiki style="margin:0 -10px -5px; min-height:calc(1.5em + 5px); color: #fff;"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-5px -1px -11px; color: #000;"dark-style="color: #fff;" 		<rowcolor=white> 등장 시기 패밀리 넘버
(10진법/16진법) 		설계 기반 이름 공정 노드
고성능 지향 마이크로아키텍처 목록
1996년 3월 - K5 K5 AMD 0.5 ~ 0.35 μm
1997년 4월 05 / 05h K6 K6 AMD 0.35 ~ 0.18 μm
1999년 6월 06 / 06h K7 K7-Athlon AMD 0.25 ~ 0.13 μm
2003년 4월 15 / 0Fh K8-Hammer AMD 0.13 μm ~ 65 nm
2007년 9월 16 / 10h K10 AMD 65 ~ 45 nm
2008년 6월 17 / 11h K8 + K10 Hybrid AMD 65 nm
2011년 6월 18 / 12h K10 Llano Common Platform Alliance SOI 32 nm
2011년 10월 21 / 15h Bulldozer Bulldozer Common Platform Alliance SOI 32 nm
2012년 8월 21 / 15h Piledriver Common Platform Alliance SOI 32 nm
2014년 1월 21 / 15h Steamroller Common Platform Alliance 28 nm
2015년 6월 21 / 15h Excavator Common Platform Alliance 28 nm
2017년 3월 23 / 17h Zen Zen GlobalFoundries 14 nm
2018년 4월 23 / 17h Zen+ GlobalFoundries 12 nm
2018년 6월 24 / 18h Hygon Dhyana GlobalFoundries 14 nm
2019년 7월 23 / 17h Zen 2 TSMC 7 nm
2020년 11월 25 / 19h Zen 3 TSMC 7 nm
2022년 2월 25 / 19h Zen 3+ TSMC 6 nm
2022년 9월 25 / 19h Zen 4 TSMC 5 ~ 4 nm
2024년 7월 26 / 1Ah Zen 5 TSMC 4 ~ 3 nm
미정 불명 Zen 6 미정
고효율 지향 마이크로아키텍처 목록
2011년 1월 20 / 14h Bobcat Bobcat TSMC 40 nm
2013년 5월 22 / 16h Jaguar Jaguar TSMC 28 nm
2014년 6월 22 / 16h Puma Common Platform Alliance 28 nm
}}}}}}}}} ||


1. 개요2. 상세
2.1. 모듈 구조
3. 문제점
3.1. CMT (Clustered Multi-Threading) 구조3.2. 깊은 파이프라인3.3. 부동소수점 연산 유닛(FPU) 문제3.4. 빈약한 디코더3.5. 느린 캐시 메모리3.6. 뒤처진 반도체 공정3.7. 결과
4. 사용 모델 일람5. 파일드라이버 마이크로아키텍처
5.1. 변경점5.2. 사용 모델 일람

1. 개요

AMD의 마이크로아키텍처로서 최초로 출시된 모듈 구조의 아키텍처[1]이다. 인텔의 명령어 세트(SSE4.1, SSE4.2, AES, CLMUL, AVX)과 AMD의 명령어 세트(ABM, XOP, FMA4, F16C) 등의 명령어 세트가 추가되었다. 글로벌파운드리 32nm SOI 공정에서 생산한다.

이 아키텍처는 AMD에 위기를 몰고 오기도 했다. 오죽했으면 인텔이 마음만 먹으면 AMD를 당장 파산시켜 버릴 수도 있었지만 반독점법때문에 어쩔 수 없이 AMD를 살려놓고 있었다는 말까지 나올 정도였다.(...)

여담이지만 불도저 이후 파일드라이버, 스팀롤러, 엑스카베이터까지 Zen 이전의 아키텍처들 이름은 모두 건설기계에서 따온 것이다.

2. 상세

파일:external/upload.wikimedia.org/AMD_Bulldozer_block_diagram_%28CPU_core_bloack%29.png

2.1. 모듈 구조

전통적인 마이크로아키텍처는 1개의 코어가 1개의 부동소수점 연산 장치(FPU)와 1개의 정수 연산 장치(Integer Cluster), 그것들을 모두 포함한 1개의 프론트엔드와 1개의 백엔드로 구성되어 있다. 거기에 적절한 수의 코어를 적절한 수로 배치해 싱글 코어와 멀티 코어에서 극대화한 성능을 낸 것이 현재 CPU의 구조이다. 하지만 불도저에서는 더 나아가 각 코어 사이에서 공유해도 성능 저하가 적은 부분들을 공유해 크기는 줄이면서 소비 전력과 트랜지스터를 상대적으로 적게 늘리면서도 성능을 끌어올리는 설계라는 것이다. 이 마이크로아키텍처에선 2개의 정수 연산 장치와 공유된 1개의 부동소수점 연산 장치를 가져 2개의 코어를 포함한 1개의 모듈 구조를 형성한다. IBM이 제시한 SMT에서 클러스터 멀티 스레드(CMT)라는 구조를 가지게 된 것이다.

1모듈이 2개의 코어인지에 대해서도 논란이 있었는데 전통적인 구조에서는 1개의 백엔드와 1개의 프론트엔드를 1개의 코어라고 지칭했지만 불도저의 모듈 구조에서는 분리된 것이 정수 연산 장치밖에 없다 보니 코어 개수에 대해 말이 많다. 자원을 공유하기도 하고, 그 공유가 완전치 않아 1개의 모듈에 1개의 코어씩 2 모듈을 동작시키는 것이 1개의 모듈에 2개의 코어를 동작시키는 것보다 성능이 떨어진다. # 각자 독립된 자원을 가지고 운용된다는 부분을 감안하면 2개의 코어로 볼 수도 있다. 이런 방식으로 계산하는 대표적인 예가 썬마이크로시스템즈 UltraSparc T 시리즈이다.

산업이나 임베디드, 서버에서 매출을 많이 남기는 AMD 특성 상 정수 지향의 아키텍처를 설계하기 위해, 불도저는 기존 K10의 3개 정수 유닛(3IU-3AGU) 구성의 정수 연산부 1개 대신, 다발적인 정수 연산에 최적화 된 2개 정수 유닛(2IU-2AGU) 구성의 코어를 2개 넣고, 당시 네할렘(이후 샌디브릿지와도 비슷하다)과 같은 크기에 FMAC를 지원하는 대형 부동소수점 연산부 유닛을 하나 넣었다. 1개의 부동소수점 연산 장치를 가진 이유는, 첫째, 평소에 잘 쓰이지 않는 부동소수점 연산 장치의 개수를 줄이고 남는 자리에 정수 연산 장치를 넣음으로써, 보다 많은 정수 연산 장치가 가져오는 총 성능 향상을 노린 점. 둘째, 한 개의 부동소수점 연산 장치를 넣으면 면적을 아낄 수 있고 고급 부동소수점 연산 명령어를 넣을 수 있게 된다는 것이다.

한편 인텔에선 하이퍼스레딩이라는 SMT 구조로 스레드를 늘려 멀티 스레드 성능을 향상시켰다. 사실 이미 인텔은 이 CMT 구조를 한번 만들어 본 경험이 있다. 프레스캇의 후속으로 계획되었던 테자스(Tejas)로, 프레스캇을 뛰어넘는 무자비한 소비전력과 발열로 인해 취소되었다. 게다가 불도저 같은 모듈 위에 하이퍼스레드를 또 얹는(...) 구조.

샌디브릿지까지는 인텔도 3개 파이프라인을 가졌고, 하스웰부터는 AVX가 크게 보강되고 정수 파이프라인도 4개로 늘어나 불도저 아키텍처는 사실 샌디브릿지와 하스웰 사이에 끼여 있다고 보아도 된다. 이는 목적대로 제대로 만들었을 경우 그 수준까지의 성능을 보았을 수도 있다는 의미다. 사실상 AMD의 모듈 아키텍처는 인텔의 하이퍼스레딩에 완전히 대응한다고 보아도 무방하다. 간혹 작은 매니코어 설계가 미래 지향적이라는 의견이 있는데, 이는 잘못된 것이다. 원래 계획대로라면 단일 스레드 성능은 좋아야 했다. 자세한 내용은 문제점에서 후술

문제점 파트에서 후술하겠지만, 불도저 이후 세대까지도 자원 공유의 핵심이 되는 부동소수점 유닛이 완전히 공유가 안되고 절반으로 갈라져 작동하는 문제점이 있었기 때문에 사실 기술적으로도 모듈은 온전한 (작은) 2코어라고 부를 수 있을 것이다.

아래 그림은 4모듈 8코어의 개념도이다.

파일:external/upload.wikimedia.org/AMD_Bulldozer_block_diagram_%288_core_CPU%29.png

이런 불도저가 출시되기 전에 대략적인 성능을 계산한 결과 출처 라고 하지만 현실은...

3. 문제점

3.1. CMT (Clustered Multi-Threading) 구조

한 스레드에서 사용할 수 있는 정수 유닛이 이전 세대의 3분의 2로 줄어들었다. 이전 세대인 K8, K10세대에서는 ALU(Arithmetic Logic Unit)와 AGU(Address Generation Unit)를 한 쌍으로 한 정수 유닛을 코어당 세 쌍을 갖추고 있었으나 불도저 세대에서는 한 코어당 두 쌍으로 한 모듈 당 두 코어였는데, 그러다 보니 한 쓰레드에는 두 쌍만 사용할 수 있다. 이로 인해 병렬화 정도가 낮은 애플리케이션에서는 암달의 법칙에 따라서 성능이 급격하게 떨어진다. 이는 정수 멀티 스레드 작업에 극도로 최적화 되어 있다고 볼 수도 있으며 이는 서버 시장에 잘 부합한다.

하지만 그 당시 애플리케이션의 명령어 수준 병렬화(Instruction-Level Parallelism)는 2개 유닛 이상을 점유하는 경우가 몹시 드물었다. 실제로 멀티 스레드에 한정하여 불도저의 정수 성능은 상당히 높은 편이다.

다만 불도저가 정수 멀티 스레드에 최적화 되어 있다는 주장에도 심각한 함정이 하나 숨어 있는데 4코어-8스레드 구성의 i7을 가정할 경우 4스레드 동시 실행 환경까지는 각 코어당 1스레드만 할당되면서 단일 코어의 모든 연산 리소스를 1스레드에 몰아줄 수 있게 된다. 즉 불도저가 i7에 대항할 만한 상황은 8스레드를 동시에 할당할 수 있는 멀티 스레드 환경을 제외하고는 없다는 것이 가장 큰 문제. 실제로 해당 환경에 가까운 배틀필드 1에서 불도저의 성능은 생각보다 좋게 나온다.

이 문단에서 설명한 내용은 1세대 FX 시리즈인 잠베지가 처음 나온 2011년 기준에서는 더욱 치명적이었다. 결정적으로 당시 최신 운영 체제였던 Windows 7의 스케줄러는 불도저의 CMT 구조를 제대로 활용하지 못했기 때문이다. 이 때문에 8스레드를 전부 사용하는 일이 없는 상태에서는 1모듈의 절반인 4스레드만 활용했고, 4스레드를 활용하는 작업도 드물던 그 당시 환경에 전작인 페넘 2보다 IPC도 떨어지고 클럭은 비슷했던 초기 잠베지들은 정말 아무 장점도 없는 CPU였다.

결국 마이크로소프트는 석 달의 시간이 지난 2012년 1월 KB2645594와 KB2646060 핫픽스를 내놓아서야 해결했다. 핫픽스 내용은 모듈을 마치 코어처럼, 코어를 마치 스레드처럼 처리하며, 코어들이 Deep Power Down 상태(C6 state)로 가는 것을 막은 것이다. 이후 마이크로소프트는 새로운 운영 체제들, Windows 8, 8.1, 10을 내놓았고 같은 방식으로 처리했으나[2] 유의미한 성능 개선은 없었다. 이후 마이크로소프트는 Windows 10 1903 2019년 상반기 업데이트에서 코어와 논리 프로세서를 잘못 표기하고 있는 문제를 해결했다. 그 이후 크라이시스 3와 배틀필드 4를 필두로 8스레드를 전부 활용하는 작업이 하나둘씩 쓰이기 시작한 이후로도 2세대 코어 i5에게 여전히 뒤떨어진다.

3.2. 깊은 파이프라인

이로 인한 문제점을 클럭을 상승시켜서 벌충하기 위해 파이프라인 스테이지당 게이트 수를 줄이고 파이프라인의 스테이지를 늘렸는데[3], 깊은 파이프라인은 통상적으로 분기 예측[4]의 적중률을 떨어뜨리면서 IPC 저하를 유발하여 결국 성능 증가에 발목을 잡게 된다. 또한 분기 예측에 실패했을 경우 해당 파이프라인을 비우고 처음부터 다시 계산해야 하는데, 투반에서는 실패할 경우 14단계를 밟아서 다시 계산하는 반면에, 불도저는 18단계를 밟아서 다시 계산하게 된다. 이것을 파이프라인 버블이라고 한다.

이 같은 문제점은 인텔도 펜티엄 4에서 경험했는데 그나마 불도저는 윌라멧(20)이나 프레스캇(31)정도는 아니니 그보다는 조금 나은 상황(...)이다. 게다가 네할렘이나 샌디브릿지와 비슷한 수준(16~19)이다. 하지만 안타깝게도 인텔에는 넷버스트 시절에 큰 도움은 되지 않았어도 ALU가 한 사이클에 두 번의 연산을 수행하여 부족한 정수 유닛의 숫자를 제한적으로나마 벌충하는 2배속 ALU가 있었으나 AMD는 그 조차도 없으며, 역시 인텔에선 넷버스트 시절에 도입되어 샌디브릿지 세대부터 다시 등장한 µop 캐시[5]라는 것이 있는데, AMD에는 이것이 없어서 분기 예측에 실패할 경우 더 많은 페널티를 가지게 된다는 것이다. ANANDTECH에서는 분기 예측에 실패할 경우 K10은 12사이클, 불도저는 20사이클, 넷버스트는 20사이클, 샌디브릿지는 14~17사이클로, 대부분 불도저보다 페널티가 더 적다.

여기서 AMD의 비애가 드러난다. AMD의 경우 K7부터 K10까지 K7시절부터 이어져 온 퀀티스피드 아키텍처의 큰 틀을 유지하면서 개량을 거듭하여 사용해 왔는데, 이 아키텍처가 너무나도 잘 만든 아키텍처라 무려 12년 넘는 세월까지 개량을 하는 것 만으로도 충분히 사용할 수 있었고, 코어 아키텍처가 나오기 전까지만 해도 인텔에 비해 구조적으로 우위에 있었다. 그러나 AMD를 영광으로 이끌었던 당시 엔지니어들은 대부분이 퇴사한 상태였으며 설상가상으로 자금이 부족해 자동화 설계와 저급 엔지니어들로 설계를 했어야 하는 상황이었다. 게다가 CMT의 개념을 잡아 준 것이 그 퇴사한 엔지니어들이었으며, 설계 경험이 거의 없는 그들이 만든 것이 재앙급의 불도저라는 것이다.

오히려 불도저는 샌디브릿지에 비해 정수 연산 성능이 뛰어나므로, 파이프라인 증대가 성능 하락을 유발했다고 보기 힘들다. 극단적으로 깊은 파이프라인의 대명사인 프레스캇이 워낙 정신 나간 수준의 31단계 파이프라인을 채택하면서 파이프라인의 단수가 주목을 받은 것이고 결국 노트북 전용이었지만 펜티엄M의 클럭당 성능, 전성비를 가졌던 P6 개량판을 토대로 65nm 공정으로 미세화 · 네이티브 듀얼코어화 · SSE3 추가가 적용된 코어 듀오를 거치고, 여기에 아키텍처도 대대적으로 개량하고 후기형 펜티엄 4에서 선보였던 64비트까지 대응된 코어 아키텍처 기반의 코어2 듀오로 넘어가자 인텔 역사상 펜티엄 4, 펜티엄 D 대비 역변급의 성능 향상이 이뤄지면서 깊은 파이프라인에 대해 부정적인 이미지가 쌓였던 것이었을 뿐. 대표적인 사례가 워낙 심하게 망해서 그렇지 사실 파이프라인 페널티를 충분히 상쇄할 수 있는 구조를 추가한다는 전제 하에 파이프라인을 늘리는 것은 그렇게 큰 문제가 되지 않는다. 가령 스카이레이크의 경우에도 14nm에 진입하면서 부분별 절전 계획이 힘들어지자 파이프라인을 하스웰보다 늘렸다. 하지만 소비 전력은 굉장히 적다. 사실 프레스캇의 경우 공정의 누설 전류를 고려하지 않고 무리하게 파이프라이닝한 것이 문제였다. 오히려 Zen 아키텍처 기반 코어에 마이크로옵 캐시가 도입된 걸 보면 파이프라인은 불도저에서 거의 줄어들지 않거나 하스웰 정도에 머무를 가능성이 높다. 분기 예측 성능에 영향을 많이 받는 정수 연산과는 달리 부동소수점 연산 성능은 대체로 높은 클럭이 성능을 결정한다. 처참한 FPU 성능을 고클럭으로 상쇄하기 위해 파이프라인 단계를 늘렸다고 해석할 수도 있다.

3.3. 부동소수점 연산 유닛(FPU) 문제

의외로 단일 스레드 실행 환경에서 FPU의 성능이 떨어지는 문제가 있는데 그 이유는 엄격하게 스케줄 된 FgMT(Fine-Grained Multithreading) 때문. FgMT란 슈퍼스칼라 파이프라인에 사이클마다 각각의 스레드가 돌아가면서 명령을 하나하나 인출하는 방식인데, 여기까지는 괜찮은데 문제는 이 순서가 필요에 따라서 유연하게 돌아가는게 아니라 고정되어 엄격하게 지켜지는 것이다. 이 때문에 하나의 스레드가 FPU 자원 전체를 사용하지 못하고, 그에 따라 단일 스레드 애플리케이션의 경우 그냥 나머지 절반의 시간은 놀게 되며 이는 마치 단일 스레드에서 정수 연산 유닛의 절반이 노는 문제와 유사한 상황을 유발한다. 이는 유연한 FgMT가 생각보다 만들기 까다롭고, 개발비도 부족하고, 출시일도 수차례 미루어서 더 이상 연기할 수 없다고 판단해 엄격한 FgMT로 땜질해 출시했다고 추측된다. 이 문제점은 결국 불도저의 핵심적인 문제 중 하나로 자리잡았고, 2012년 이후 불도저 코어 고성능 CPU 개발을 포기하면서 개선된 FgMT가 구현된 아키텍처는 영영 볼 일이 없어지게 되었다. 만약 유연한 FgMT가 구현된 모듈 아키텍처가 있었다면 모듈당 실수 및 정수 스트리밍의 단일 스레드 성능은 동클럭에서 샌디브릿지의 90% 까지 나왔을 것이다. 사실상 불도저가 참패한 주요 원인 중 하나. FgMT가 제대로 구현되었다면 모듈은 여전히 1코어인지 2코어인지 구분하기 애매했을 것이다. 하지만 엄격한 FgMT로 내부적으로 분리되어 동작하는 경우 모듈 기술은 사실상 작게 분리된 2코어라고 부를 수도 있다.

사실 FPU의 성능이 떨어지는 것이 단순히 실수 연산 성능의 저하만을 불러오는 것으로 오해하기 쉬운데 현대적인 SSE나 AVX 명령어들은 실수 뿐만 아니라 패킹된 정수값들도 동시에 처리하도록 되어 있다.[6] 즉 FPU의 성능 저하는 스트리밍 혹은 패킹된 정수 처리나 메모리 로드-스토어 기능에도 직접적인 악영향을 주게 된다.

3.4. 빈약한 디코더

3개의 연산 유닛이 하나의 디코더를 공유하고 있다는 점이 문제점으로 자주 지적되었다. 앞에서 서술한 엄격한 FgMT와 더불어 불도저 연산 유닛에 부하를 걸 수 없는 원인이다. 하지만 정작 스팀롤러B 아키텍처에서 채용한 2개의 디코더는 결국 큰 성능 향상을 갖지 못했다. CPU가 극한까지 치닫았을 때 10% 정도의 향상을 보여주었다. 전세대 대비 디코더가 확장된 아키텍처는 스팀롤러B 말고도 스카이레이크가 있다. CPU에서 소비 전력이 가장 많은 부분은 디코더인데, 인텔 엔지니어가 아이비브릿지 코어의 소비 전력의 40%는 디코더에서 나온다고 언급했다. 단일 스레드 성능이 중요한 부동소수점 연산부와 함께 디코더를 공유한 것은 크게 나쁘지 않으며 오히려 괜찮다고도 할 수 있는 시도이다. 하여튼 결국 극도의 전성비를 추구한 엑스카베이터에서는 도로 디코더가 하나로 줄어들었다.

3.5. 느린 캐시 메모리

비대해진 L2 캐시 메모리 용량도 한몫한 것으로 보인다. AMD는 인텔과 다르게 Exclusive Cache 방식의 캐시 메모리 정책을 사용한다. 이 Exclusive Cache 방식은 상위 캐시 메모리와 하위 캐시 메모리의 내용이 겹치지 않도록 하는 방식이다. 따라서 FX-8150의 경우는 384KB의 L1캐시, 8MB의 L2캐시와 8MB의 L3캐시로 더하면 16MB도 넘어가는 캐시 용량을 가진다.

하지만 이렇게 무작정 용량이 커지면 캐시 메모리 접근 대기 시간(레이턴시, latency)이 늘어난다. 샌디브릿지의 경우 L3 캐시 메모리의 접근 대기 시간은 22사이클, 아이비브릿지는 24사이클임에 비해 불도저는 L2 캐시 메모리의 접근 대기 시간이 18사이클이다. L3 캐시 메모리의 접근 대기 시간은 무려 65사이클. 이는 L2 캐시와 L3 캐시 메모리의 접근 대기 시간이 각각 12~14사이클, 40사이클인 K10보다도 훨씬 느리다. 이는 공유 메모리인 이유도 있고, 크기가 커서 그렇기도 한다고 하지만... K10보다 대역폭은 절반이나 낮으면서 대기 시간이 엄청 길다는 것은 큰 문제가 있다. 메모리 접근 속도가 대용량의 스트리밍 연산을 제외하고 작은 용량의 정수 연산, 실수 연산에 지대한 영향을 미친다는 것을 고려하면 캐시 메모리 접근 대기 시간 문제는 심각한 약점이 아닐 수 없다.

3.6. 뒤처진 반도체 공정

IBM과 공동 개발한 글로벌파운드리 32nm HKMG 공정은 인텔 32nm 공정에 비해 소비 전력이 그닥 좋지 않았다. 누설 전류가 심했고 3.6GHz를 넘기면 소비 전력이 꽤 많아지기 시작해, 4.2GHz를 넘기면 폭증하는 수준이 되었다. 제품 SKU를 세세하게 살펴보면 3.6GHz/4.2GHz 선에서 작동하는 제품이 굉장히 많다. FX-8150의 클럭이 3.6/4.2GHz, FX-6100의 6코어 터보 클럭도 3.6GHz, FX-4100의 베이스 클럭도 3.6GHz다. 2세대 파일드라이버에서도 역시 비슷하게 알 수 있는데, FX-6330이 3.6/4.2GHz, FX-6350의 터보 클럭이 4.2GHz, FX-8300의 8코어 터보 클럭은 3.6GHz에 4코어만 터보 클럭은 4.2GHz, FX-8350의 터보 클럭도 4.2GHz 등. 기타 개선판 제품들도 여기에서 0.1GHz단위로 더 올라가는 모습이다. 사실 AMD FX의 심한 소비 전력의 주 원인이 되었으며, 설상가상으로 불도저는 떨어지는 IPC를 클럭속도로 상쇄하기 위해 파이프라인을 어느정도 깊게 만든 구조고 이러면 꽤나 높은 클럭에서 작동을 해야 제 성능이 나오게 되는데, 마침 엄격한 FgMT 때문에 단일 스레드 성능이 너무 떨어져 클럭을 올리자니 소비 전력이 너무 높고, 클럭을 내리자니 성능이 너무 낮은 딜레마에 빠지게 되었다.

스팀롤러 아키텍처는 이 문제점을 해결하고자 글로벌파운드리 28nm HP 공정(후에 SHP 공정으로 교체)으로 개선했지만, 이 공정은 소비 전력은 절감할 수 있었던 반면 높은 클럭을 쓰기 어려운 공정이었기 때문에 데스크톱 고성능 데스크톱 및 서버 CPU 시장을 포기한 것이나 다름없게 되었다. 유출된 고성능 스팀롤러의 다이샷 여기서 2배화된 연산 유닛이 도로 삭제된 스팀롤러B 아키텍처가 카베리에 들어간다.

3.7. 결과

이러한 설계와 제조 공정 상의 총체적인 난국으로 인하여 불도저 아키텍처는 극단적인 멀티 스레드 환경을 제외한 대부분의 상황에서 좋은 성능을 보여 주지 못했고, 유일하게 좋은 성능을 보인 분야에서 조차도 인텔의 SMT 방식에 비해 고만고만한 성능에 불과했을 뿐이었다. 그뿐만 아니라 이후 일부 성능을 개선하는 것에는 성공했지만 여전히 경쟁 제품에 비해 한참 부족한 성능 격차를 메꿀 방법은 없었다. 결국은 2012년 이후로 AMD는 불도저로 대표되는 CMT 구조를 포기하고 인텔과 유사한 SMT 아키텍처로 선회하면서 ZEN을 개발하는데 집중하게 된다.

4. 사용 모델 일람

5. 파일드라이버 마이크로아키텍처

5.1. 변경점


설계 자체는 불도저와 다르지 않다. 다만 불도저에서 개선한 점이 상당히 많다. 정수 연산 능력도 투반 페넘 II보다(...) 높아졌다. AMD는 싸이클로스(Cyclos)의 공진 클럭 메시 기술을 라이선스 받고 하드에지 플립 플롭을 적용해, 소비 전력을 동클럭에서 40W 가까이 절감할 수 있었다. 하지만 여전히 소비 전력은 많았다.

5.2. 사용 모델 일람

[1] CMT 구조는 인텔의 테자스가 훨씬 먼저 개발되었지만, 제품 출시와 양산으로 이어지지 못했다. [2] 다만 Windows 8 이후의 운영 체제는 전원 관리 수준이 좋아져 KB2646060 핫픽스 같은 AMD FX CPU들의 코어가 Deep Power Down 상태(C6 state)로 가는 것을 막을 필요가 없어졌다. [3] 투반 코어당 3개, 총 14스테이지. 불도저 코어당 2개, 총 18 스테이지 [4] 다음 명령이 무엇인지 예측하여 처리시간을 단축하여, 성능 향상과 전력 감소 효과를 볼 수 있게 해 준다. [5] 펜티엄 4 시절에는 트레이스 캐시라 불리던 것으로, 디코드 단계를 생략할 수 있게 하여 밟아야 하는 파이프라인 단계를 줄여주는 캐시이다. 초창기 펜티엄4 윌라멧이 펜티엄3 보다 느렸던 이유 중 하나는 파이프라인 단계는 늘렸는데 정작 이 문제를 완화시켜 줄 트레이스 캐시의 크기는 작아서 적중률이 떨어져 그 기능이 취약했기 때문이었다. 노스우드에서 이걸 무려 8배나 늘려 문제를 해결한다. 다만 윌라멧의 0.18㎛ 공정이 노스우드A에서 0.13㎛ 공정으로 개선되면서 클럭 속도가 33% 정도 증가했고 L2 캐시 메모리 용량이 2배로 확장되면서 P6 대비 떨어지는 IPC를 캐시 메모리 증가와 높은 클럭으로 벌충한 것이라 트레이스 캐시의 개선이 준 효과가 어느 정도인지는 명확하지 않다. [6] 128비트에서 패킹된 16비트 정수를 반환하는 punpckhwd나 punpcklwd 같은 것들 [7] APU 내장그래픽 제거 버전이다.

분류