AMD 불도저 마이크로아키텍처
1. 개요
AMD의 마이크로아키텍처로서 최초로 출시된 모듈 구조의 아키텍처[1]이다.[2]
2. 불도저 마이크로아키텍처
2.1. 특징
GlobalFoundries의 32nm SOI 공정에서 제작된다.
인텔의 명령어 세트(SSE4.1, SSE4.2, AES, CLMUL, AVX)과 AMD의 명령어 세트(ABM, XOP, FMA4, F16C) 등의 명령어 세트가 추가되었다.
2.1.1. 모듈 구조
[image]
전통적인 마이크로아키텍처는 1개의 코어가 1개의 부동 소수점 연산 장치(FPU)와 1개의 정수 연산 장치(Integer Cluster), 그것들을 모두 포함한 1개의 프론트엔드와 1개의 백엔드로 구성되어 있다. 거기에 적절한 수의 코어를 적절한 수로 배치해 싱글 코어와 멀티 코어에서 극대화한 성능을 낸 것이 현재 CPU의 구조이다. 하지만 불도저에서는 더 나아가 각 코어 사이에서 공유해도 성능 저하가 적은 부분들을 공유해 크기는 줄이면서 소비 전력과 트랜지스터를 상대적으로 적게 늘리면서도 성능을 끌어올리는 설계라는 것이다. 이 마이크로아키텍처에선 2개의 정수 연산 장치와 공유된 1개의 부동 소수점 연산 장치를 가져 2개의 코어를 포함한 1개의 모듈 구조를 형성한다. IBM이 제시한 SMT에서 클러스터 멀티스레드(CMT)라는 구조를 가지게 된 것이다.
1모듈이 몇 개의 코어인지에 대해서도 논란이 있었는데 전통적인 구조에서는 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의 모듈 아키텍처는 인텔의 하이퍼스레딩에 완전히 대응한다고 보아도 무방하다. 간혹 작은 매니코어 설계가 미래지향적 아키텍처라는 의견이 있는데, 이는 잘못된 것이다. 원래 계획대로라면 싱글스레드 성능은 좋아야 했다. 자세한 내용은 문제점에서 후술
[image]
위는 불도저 아키텍처, 아래는 샌디브릿지와 크기가 거의 동일한 웨스트미어 코어다. 보면 불도저의 2코어와 샌디브릿지의 1코어가 양적인 면에서 차이를 보기 힘들다는 점을 알 수 있다.
문제점 파트에서 후술하겠지만, 불도저 이후 세대까지도 자원 공유의 핵심이 되는 부동소수점 유닛이 완전히 공유가 안되고 절반으로 갈라져 작동하는 문제점이 있었기 때문에 사실 기술적으로도 모듈은 온전한 (작은) 2코어라고 부를 수 있을 것이다.
아래 그림은 4모듈 8코어의 개념도이다.
[image]
이런 불도저가 출시되기 전에 대략적인 성능을 계산한 결과 출처
- 디코더가 병목현상을 유발할 경우: K10 대비 33% 향상
- 병목현상이 없을 경우: (ROB의 In-flight 명령어 개수에 비례해) K10 대비 78% 향상
- 백엔드가 병목현상을 유발할 경우: K10 대비 33% 향상
2.2. 문제점
한 마디로 표현하자면, '''총체적 난국.'''
2.2.1. CMT (Clustered Multi-Threading) 구조
한 스레드에서 사용할 수 있는 정수 유닛이 이전 세대의 3분의 2로 줄어들었다. 이전 세대인 K8, K10세대에서는 ALU와 AGU를 한 쌍으로 한 정수유닛을 코어당 세 쌍을 갖추고 있었으나 불도저 세대에서는 한 모듈당 네 쌍으로 불도저는 인텔과 반대로 정수 유닛이 분리되어있으므로 한 쓰레드에는 이 절반인 두 쌍만을 사용할 수 있다. 이로 인해 병렬화 정도가 낮은 애플리케이션에서는 암달의 법칙에 따라서 성능이 급격하게 떨어진다.
하지만 현재 대부분의 애플리케이션의 명령어 수준 병렬화는 2개 유닛 이상을 점유하는 경우가 몹시 드물기 때문에 벤치마크에서는 싱글스레드 성능이 낮게 나올 수 있으나, 현실적으로는 다발적인 정수 멀티스레딩에 극도로 최적화 되어 있다고 볼 수도 있으며 이는 불도저의 목적인 서버시장 공략에 잘 부합한다. 실제로 샌디브릿지에서 하스웰로 넘어오면서 정수 유닛이 4개로 늘어났지만, 여전히 펜티엄의 멀티스레딩 성능은 몹시 낮고, i3의 멀티스레딩 성능은 몹시 크게 증가한 점에서 아직 정수유닛 점유 최적화는 그닥 좋아지지 않았다고 판단 가능하다. 실제로 멀티스레딩에 한정하여 불도저의 정수성능은 상당히 높은 편이며, 하스웰에서 정수유닛이 4개로 보강된 것도 불도저를 의식해서 확장했다고 추측할 수 있다.
다만 불도저가 정수 멀티스레딩에 최적화 되어 있다는 주장에도 심각한 함정이 하나 숨어 있는데 4코어-8스레드 구성의 i7을 가정할 경우 4스레드 동시 실행환경까지는 각 코어당 1스레드만 할당되면서 단일 코어의 모든 연산 리소스를 1스레드에 몰아줄 수 있게 된다. 즉 불도저가 i7에 대항할 만한 상황은 불도저의 8코어당 스레드가 1개씩 할당 가능한 그야말로 극단적인 멀티스레딩 환경을 제외하고는 없다는 것이 가장 큰 문제. 실제로 해당 환경에 가까운 배틀필드 1에서 불도저의 성능은 생각보다 좋게 나온다.
이 문단에서 설명한 내용은 1세대 FX 시리즈인 잠베지가 처음 나온 2011년 기준에서는 더욱 치명적이었다. 결정적으로 당시 최신 OS였던 Windows 7은 아직 불도저의 CMT 구조를 제대로 활용하지 못했기 때문이다. Windows 7은 모듈 방식의 CPU를 잘 활용하지 못하기 때문에 8스레드를 전부 사용하는 일이 없는 상태에서는 1모듈의 절반(4코어)만을 활용했고, 전작인 데네브보다 떨어지는 IPC에 실질적인 클럭 상승폭은 높지 않았던(데네브-투반 세대 상위 제품과 잠베지의 기본 클럭은 엎치락뒤치락이다.) 초기 잠베지들은 4스레드를 활용하는 작업도 드물던 그 당시 환경에서는 정말 아무 장점도 없는 물건이었다. 크라이시스 3와 배틀필드 4를 필두로 8스레드를 전부 활용하는, 혹은 그 이상의 많은 스레드를 활용하는 작업이 하나둘씩 쓰이기 시작한 2013년 이후로도 별로 높은 취급을 받지 못하는데 당시에는... 그리고 Windows 10의 등장으로 그럭저럭 재평가를 받는 2015년 이후에도 2세대 i5에게 여전히 한없이 발리는 점이 불도저의 안습포인트.
또한 하스웰의 정수유닛 보강 역시 굳이 불도저를 의식했다는 추측에도 반론이 가능한데 어차피 불도저가 있거나 말거나 하스웰을 개발한 인텔의 입장에서 차세대 제품의 IPC를 전세대 보다 향상시키기 위해 실행유닛을 추가하는 등의 설계 개선 작업을 수행하는 것은 당연한 수순인 것이다. 즉 불도저가 뭘 하건 간에 하스웰의 실행유닛을 증가시킬 충분한 동기가 인텔에게 있었다는 것.
2.2.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 성능을 고클럭으로 상쇄하기 위해 파이프라인 단계를 늘렸다고 해석할 수도 있다.
2.2.3. 백엔드의 부동소수점 실수 연산 유닛(FPU) 문제
의외로 싱글스레드 실행 환경에서 FPU의 성능이 떨어지는 문제가 있는데 그 이유는 엄격하게 스케줄 된 FgMT(Fine-Grained Multithreading) 때문. FgMT란 슈퍼스칼라 파이프라인에 사이클 마다 각각의 스레드가 돌아가면서 명령을 하나하나 인출하는 방식인데, 여기까지는 괜찮은데 문제는 이 순서가 필요에 따라서 유연하게 돌아가는게 아니라 고정되어 엄격하게 지켜지는 것. 이 때문에 하나의 스레드가 FPU 자원 전체를 사용하지 못하고, 그에 따라 싱글스레드 애플리케이션의 경우 그냥 나머지 절반의 시간은 놀게 되며 이는 마치 단일 스레드에서 정수연산 유닛의 절반이 노는 문제와 유사한 상황을 유발한다. 이는 유연한 FgMT가 생각보다 만들기 까다롭고, 개발비도 부족하고, 출시일도 수 차례 미루어서 더 이상 연기할 수 없다고 판단해 엄격한 FgMT로 땜질해 출시했다고 추측된다. 이 문제점은 결국 불도저의 핵심적인 문제 중 하나로 자리잡았고, 2012년 이후 고성능 CPU 시장을 타겟으로 한 불도저 코어 개발을 포기하면서 개선된 FgMT가 구현된 완전체 모듈 아키텍처는 영영 볼 일이 없어지게 되었다.만약 유연한 FgMT가 구현된 모듈 아키텍처가 있었다면 모듈당 실수 및 정수 스트리밍의 싱글스레드 성능은 동클럭에서 샌디브릿지의 90% 까지 나왔을 것이다. 사실상 불도저가 참패한 주요 원인중 하나. FgMT가 제대로 구현되었다면 모듈은 여전히 1코어인지 2코어인지 구분하기 애매했을 것이다. 하지만 엄격한 FgMT로 내부적으로 분리되어 동작하는 경우 모듈 기술은 사실상 작게 분리된 2코어라고 부를 수도 있다.
사실 FPU의 성능이 떨어지는 것이 단순히 실수 연산 성능의 저하만을 불러오는 것으로 오해하기 쉬운데 현대적인 SSE나 AVX 명령어들은 실수 뿐만 아니라 패킹된 정수값들도 동시에 처리하도록 되어 있다. 즉 FPU의 성능 저하는 스트리밍 혹은 패킹된 정수 처리나 메모리 로드-스토어 기능에도 직접적인 악영향을 주게 된다.
2.2.4. 프론트엔드의 빈약한 디코더 단
3개의 연산 유닛이 하나의 디코더를 공유하고 있다는 점이 문제점으로 자주 지적되었다. 앞에서 서술한 엄격한 FgMT와 더불어 불도저의 연산 유닛에 풀로드가 걸릴 수 없는 원인이다. 하지만 정작 스팀롤러B 아키텍처에서 채용한 2개의 디코더는 결국 큰 성능향상을 갖지 못했다. CPU가 극한까지 치닫았을 때 10% 정도의 향상을 보여주었다. 전세대 대비 디코더가 확장된 아키텍처는 스팀롤러B 말고도 스카이레이크가 있다. CPU에서 전력 소모가 가장 많은 부분은 디코더인데, 인텔 엔지니어가 아이비브릿지 코어의 전력소모의 40%는 디코더에서 나온다고 언급했다. 싱글스레드 성능이 중요한 부동소수점 연산부와 함께 디코더를 공유하여 압축해버린 점은 크게 나쁘지 않으며 오히려 괜찮다고도 할 수 있는 시도이다. 하여튼 결국 극도의 전성비를 추구한 엑스카베이터에서는 도로 디코더가 하나로 줄어들어 버렸다.
2.2.5. 비대하면서도 느린 캐시 메모리 접근 레이턴시
비대해진 L2 캐시 메모리 용량도 한몫 한 것으로 보인다. AMD는 인텔과 다르게 모든 캐시에 Exclusive Cache 방식을 사용한다. 이 Exclusive Cache 방식은 상위 캐시와 하위 캐시의 내용이 겹치지 않도록 하는 캐시 방식이다. 따라서 FX-8150의 경우는 384KB의 L1캐시, 8MB의 L2캐시와 8MB의 L3캐시로 더하면 16MB도 넘어가는 캐시 용량을 가진다.
하지만 이렇게 무작정 용량이 커지면 캐시 접근 레이턴시를 줄이기 어려워진다. 샌디브릿지의 경우 L'''3'''(L2가 아니다.)캐시의 접근 레이턴시는 22사이클, 아이비브릿지는 24사이클임에 비해 불도저는 '''L2 캐시의 접근 레이턴시가 18사이클'''이다. '''L3 캐시의 접근 레이턴시는 무려 65사이클'''. 이는 L2 캐시와 L3 캐시의 접근 레이턴시가 '''각각 12~14사이클, 40사이클인 K10보다도 훨씬 느린 레이턴시'''이다. 이는 공유 메모리인 이유도 있고, 크기가 커서 그렇기도 한다고 하지만... K10보다 대역폭은 절반이나 낮으면서 레이턴시가 엄청 느리다는 것은 큰 문제가 있다. 메모리 접근 속도가 대용량의 스트리밍 연산을 제외하고 작은 용량의 정수 연산, 실수 연산에 지대한 영향을 미친다는 것을 고려하면 캐시 접근 레이턴시 문제는 심각한 약점이 아닐 수 없다.
2.2.6. 뒤처진 미세공정 수준
IBM과 공동개발한 GF의 32nm HKMG 공정이 인텔에 비해 전력소모가 그닥 좋지 않았다. 누설전력이 심했고 3.6GHz를 넘기면 전력소모가 꽤 많아지기 시작해, 4.2GHz를 넘기면 소모가 폭증하는 수준이 되었다. 제품 SKU를 세세하게 살펴보면 3.6GHz/4.2GHz 선에서 작동하는 제품이 굉장히 많다. FX8150의 클럭이 3.6/4.2GHz, FX6100의 6코어 터보 클럭도 3.6GHz, FX4100의 베이스 클럭도 3.6GHz다! 2세대 파일드라이버에서도 역시 비슷하게 알 수 있는데, FX6330이 3.6/4.2GHz, FX6350의 터보 클럭이 4.2GHz, FX8300의 8코어 터보 클럭은 3.6GHz에 4코어만 터보 클럭은 4.2GHz, FX8350의 터보 클럭도 4.2GHz 등. 기타 개선판 제품들도 여기에서 0.1GHz단위로 더 올라가는 모습이다. 사실 AMD FX의 심한 전력소모의 주 원인이 되었으며, 설상가상으로 불도저는 떨어지는 IPC를 클럭속도로 상쇄하기 위해 파이프라인을 어느정도 깊게 만든 구조고 이러면 꽤나 높은 클럭에서 작동을 해야 제 성능이 나오게 되는데, 마침 엄격한 FgMT 때문에 싱글스레드 성능이 너무 떨어져 클럭을 올리자니 전력소모가 너무 높고, 클럭을 내리자니 성능이 너무 낮은 딜레마에 빠지게 되었다.
스팀롤러 아키텍처는 이 문제점을 해결하고자 GF의 28nm HP 공정(후에 SHP 공정으로 교체)으로 교체하여 누설전력을 회피하도록 설계 되었지만 고성능 CPU 시장으로의 진출을 완전히 포기해 버린 후 빛을 보지 못하게 되었다. 유출된 고성능 스팀롤러의 다이샷 여기서 2배화된 연산유닛이 도로 삭제된 스팀롤러B 아키텍처가 카베리에 들어간다.
2.2.7. 결과
이러한 설계와 제조공정상의 총체적인 난국으로 인하여 불도저 아키텍처는 극단적인 멀티스레드 환경을 제외한 대부분의 상황에서 좋은 성능을 보여 주지 못했고, 그 유일하게 좋은 성능을 보여 준 분야에서 조차도 인텔의 SMT 방식에 비해 고만고만한 성능에 불과했을 뿐 아니라 이후 일부 성능을 개선하는 것에는 성공했지만 여전히 경쟁 제품에 비해 한참 부족한 성능 격차를 메꿀 방법은 존재하지 않았다. 결국은 2012년 이후로 AMD는 불도저로 대표되는 CMT 구조를 포기하고 인텔과 유사한 SMT 아키텍처로 선회하면서 ZEN을 개발하는데 집중하게 된다.
2.3. 사용 모델 일람
- AMD FX 시리즈 - 잠베지
- AMD 옵테론 시리즈 - 취리히, 발렌시아, 인터라고스 MCM
3. 파일드라이버 마이크로아키텍처
3.1. 변경점
- 분기 예측 능력 향상
- 부동 소수점/정수 스케줄링, 프리페칭(Prefetching) 개선
- IMC(통합 메모리 컨트롤러) 성능 향상
- L1 TLB 및 L2 효율 향상
- 고급 벡터 확장(AVX) 1.1, FMA3, FMA4, F16C, BMI1, TBM 지원
- 터보 코어 3.0 적용
- 공진 클럭 매시
- 하드에지 플립플롭 적용으로 전력 소모량 감소
- 8~10%의 클럭 향상과 비슷한 IPC 상승과 약 15%의 성능 향상
- 비디오 코딩 엔진
AMD는 싸이클로스 사의 공진 클럭 메시 기술을 사들여와, GF 32nm의 소비전력을 동클럭에서 40W 가까이 누를 수 있었다. 하지만 여전히 전력 소모는 많았다.
3.2. 사용 모델 일람
- AMD FX 시리즈 - 비쉐라
- AMD 애슬론 II 시리즈 - 애슬론 X4, X2[6]
- AMD/APU - 트리니티, 리치랜드
- AMD 옵테론 시리즈 - 델리, 서울, 아부다비 MCM, 바르샤바
[1] CMT 구조는 인텔의 테자스가 훨씬 먼저 개발되었지만, 제품 출시와 양산으로 이어지지 못했다.[2] 이거 때문에 진짜로 AMD가 파산 직전까지 나가떨어졌다.(...) 오죽했으면 반독점법때문에 인텔이 할 수 없이 AMD를 살려놓고 있다는 말 까지 나올 정도였었다.(...)[3] 투반 코어당 3개, 총 14스테이지. 불도저 코어당 2개, 총 18 스테이지[4] 다음 명령이 무엇인지 예측하여 처리시간을 단축하여, 성능 향상과 전력 감소 효과를 볼 수 있게 해 준다.[5] P4 시절에는 트레이스캐시라고 불리던 것으로, 디코드 단계를 생략할 수 있게 하여 밟아야 하는 파이프라인 단계를 줄여주는 캐시이다. 초창기 펜티엄4 윌라멧이 펜티엄3 보다 느렸던 이유 중 하나는 파이프라인 단계는 늘렸는데 정작 이 문제를 완화시켜 줄 트레이스캐시의 크기는 작아서 적중률이 떨어져 그 기능이 취약했기 때문이었다. 노스우드에서 이걸 무려 8배나 증강시켜 문제를 해결하게 된다. 다만 윌라멧과 노스우드A의 차이는 0.18㎛에서 0.13㎛로 변경되면서 클럭 속도가 33% 정도 증가했고 L2캐시 용량이 2배로 확장되면서 P6 대비 떨어지는 IPC를 캐시빨과 클럭빨로 감춘 것이라서 트레이스 캐시의 개선이 준 효과가 어느 정도인지는 명확하지 않다.[6] APU 내장그래픽 제거 버전이다.