기타 칼럼

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

[CPU] 현대 CPU의 구조 : 프론트엔드 편

IYD | 조회 215 | 추천 0 | 2011.01.22. 14:10 http://drmola.com/etc_column/29628

Author : Daeguen Lee

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


얼마 전 백엔드 구조를 중심으로 현대의 CPU에 대해 알아 보았습니다.
(현대 CPU의 구조 강좌 <백엔드 편> ☞ 여기)

이번 강좌에서는 그때 설명하지 않고 남겨둔 프론트엔드에 대해 간략히 알아보도록 하겠습니다.
우선 저번 강좌에서 처음 등장했던 그림을 다시 한번 보시겠습니다.


오늘날의 컴퓨터는 그 외형과는 별개로, 공통적으로 위와 같은 구조를 가집니다.
저장 장치에서 명령어와 데이터를 인출(Fetch)해서 내부적으로 처리 가능한 포맷으로 변환(Decode)한 뒤
제어 유닛이 명령어를 정렬해 수행 유닛에 전달해 주고 수행 유닛이 이를 처리하는 것.
이것이 현대의 컴퓨터가 작업을 처리하는 방식입니다.

저번 강좌에선 연두색(수행 유닛)에 해당하는 백엔드의 구조만을 살펴보았는데
이번 강좌에서 다룰 부분은 바로 연보라색 상자 안에 해당하는 '명령어 인출-디코드-제어 유닛' 부분입니다.


실질적으로 계산이 일어나는 수행 유닛(백엔드)은 CPU 성능에 절대적으로 중요하지만
백엔드가 아무리 빨라도 프론트엔드가 명령어를 제때 공급해주지 못하면 소용이 없습니다.
1999년 AMD 애슬론의 등장과 함께 현대 CPU의 백엔드는 충분한 대역폭을 갖게 되었고
이에 따라 오늘날의 CPU의 성능 차는 대개 프론트엔드에 의해 갈리게 됩니다.
또한 그 중에서도 파이프라인의 가장 많은 스테이지를 점유하는 디코딩 과정은 특히 중요합니다.

따라서 오늘은 디코더 구조를 중심으로, 프론트엔드의 구조에 대해 알아보겠습니다.


1. Intel P5 Microarchitecture


인텔 펜티엄은 데스크탑용으로 처음 수퍼스칼라 구조를 채택해서 유명한 CPU입니다.
펜티엄의 프론트엔드와 백엔드 사이에는 순차 제어 유닛이 놓여 있습니다.
이름이 말해 주듯 이 제어 유닛은 프론트엔드에서 디코드한 명령어를 "순차적으로" 백엔드에 전달하는데,
최대 2개까지의 명령어를 동시에 처리 가능한 펜티엄의 수퍼스칼라 백엔드의 장점을 살리기 위해서는
명령어들을 최대한 동시에 많이 처리할 수 있도록 조합해서 전달해 주는 것이 중요합니다.
하지만 순차 제어 유닛은 이러한 조합을 만들어내는 데 제한적일 수밖에 없습니다.
(예: 수행-수행-메모리 읽기... 이런 식이면 2개의 수행 명령어를 동시에 처리할 수 있지만
수행-메모리 읽기-수행-메모리 쓰기-수행 이런식이면 수행 명령어의 병렬 처리가 불가능합니다)

즉 정확한 용어로 프론트엔드와 백엔드의 동작이 독립적이지 않다는 것이 문제인데요,
이러한 문제점은 1996년 출시된 AMD의 K5에서 '비순차적 수행' 구조로 해결되었습니다.
그 얼마 뒤 출시된 펜티엄 프로 CPU도 비슷한 비순차적 수행 구조를 채택하고 있습니다.
비순차적 수행에 관해서는 잠시 후 이들 CPU를 설명하면서 함께 언급하겠습니다.

펜티엄의 프론트엔드는 메모리로부터 최대 16바이트에 해당하는 길이의 명령어 스트림을 인출해 옵니다.
이 스트림에서 매 사이클당 1개의 x86 명령어가 디코더로 전송되고,
디코더는 이를 1~2개의 내부 명령어 포맷(마이크로옵: uop이라 쓰겠습니다)으로 변환합니다.
(진한 빨간색 화살표는 x86 명령어의 흐름을, 분홍색 화살표는 마이크로옵의 흐름을 나타냅니다.
또한 마이크로옵 중 진한 분홍색은 항상 생성되는 마이크로옵의 수를 의미하고
연한 분홍색은 이론적으로 생성 가능한 최대 마이크로옵 수를 의미합니다. 이하 동일)

디코드된 마이크로옵은 순차 제어 유닛으로 이동하고 제어 유닛은 마이크로옵을 백엔드에 전달하게 됩니다.
프론트엔드의 구조가 단순한 만큼, 펜티엄의 총 파이프라인 스테이지 수는 5개로 비교적 짧은 편입니다.
페치가 1스테이지, 디코드가 2~3스테이지, 제어가 4스테이지에 위치하고 마지막 단계에서 수행이 일어납니다.


2. AMD K5 Microarchitecture

AMD의 K5는 SUN으로부터 라이선스를 받은 SPARC 29000의 구조를 바탕으로 만들어졌습니다.
RISC CPU인 SPARC 29000과 달리 x86 명령어를 지원해야 하는 K5에는 디코더가 추가되어 있습니다.


K5의 디코더는 페치 버퍼로부터 사이클당 2개의 x86 명령어를 전송받아 4개의 마이크로옵으로 변환합니다.
변환된 마이크로옵은 재정렬 버퍼(ROB)에 16개까지 축적되는데, 이 ROB가 매우 중요한 역할을 수행합니다.
바로 펜티엄의 약점이었던 '순차 수행 구조'를 비순차적으로 바꿔 주는 역할이죠.

이로 인해 K5는 프론트엔드에서 일어나는 작업(인출, 디코드)과 완전히 별개로 백엔드가 작동할 수 있습니다.
명령어가 어떤 순서로 디코드되든 상관없이 백엔드는 최적의 수행 순서로 재정렬된 마이크로옵을 받는 것이죠.
백엔드의 성능 자체는 당시 이미 검증되었던 RISC 프로세서인 SPARC 29000과 동일합니다.

전반적으로 펜티엄보다 진보된 구조(밑에 설명할 펜티엄 프로에 더 가깝습니다), 높은 클럭당 성능에 불구하고
당시 AMD의 생산기술의 한계로 칩의 수율이 좋지 않아 시장에서 인기가 없었습니다.


3. Intel P6 (Pentium Pro/II/III) Microarchitecture

앞에서 살펴본 펜티엄의 문제는 프론트엔드와 백엔드의 작동이 완벽히 독립적이지 않다는 점이었습니다.
수퍼스칼라 구조로 넓어진 백엔드 대역폭을 제대로 활용하려면
마이크로옵을 재정렬해서 동시에 수행 가능한 대역폭만큼의 마이크로옵을 백엔드에 전달해줘야 하는데
펜티엄과 같은 순차 수행 구조 하에선 마이크로옵의 재정렬이 거의 불가능합니다.
AMD의 K5 및 인텔의 펜티엄 프로 CPU는 프론트엔드 말미에 재정렬 버퍼(ROB)를 넣어 이를 해결했습니다.


펜티엄 프로는 디코더 뒤에 40개의 마이크로옵을 축적할 수 있는 ROB를 가지고 있습니다.

또한 펜티엄 프로는 디코더 자체의 구조도 펜티엄에 비해 매우 향상되었습니다.
구체적으로, 명령어 인출 단계에서 페치 버퍼에 저장되는 명령어 스트림의 용량이 32바이트로 두 배 늘었고
페치 버퍼로부터 디코더로 전송되는 x86 명령어 개수가 종전의 사이클당 1개에서 사이클당 3개로 늘었습니다.

펜티엄 프로는 총 3개의 디코더를 가지는데, 단순 디코더 두 개와 복합 디코더 한 개로 구성됩니다.
단순 디코더(Simple Decoder)는 클럭당 1개의 x86 명령어를 1개의 마이크로옵으로 변환하고
복합 디코더(Complex Decoder)는 클럭당 1개의 x86 명령어를 1~4개의 마이크로옵으로 변환해 줍니다.
즉 종합하면 펜티엄 프로는 클럭당 3개의 x86 명령어를 3~6개의 마이크로옵으로 변환할 수 있습니다.
얼핏 보기엔 사이클당 6개의 마이크로옵이 생성되는데 백엔드에는 사이클당 최대 5개씩만을 전달하므로
백엔드가 CPU 성능에 발목을 잡는 것이 아닌가 의아해하실 수 있을 텐데요,
사실 P6의 디코더에는 한 가지 함정이 있습니다.


메모리 접근 관련 x86 명령어(로드/스토어)는 두 개의 마이크로옵(Address/Data)으로 디코드됩니다.
따라서 로드/스토어 명령어는 단순 디코더에서 처리할 수 없고 복합 디코더로 전송되어 처리되어야 하는데
메모리 접근이 잦은 서버/오피스 프로그램의 경우 이러한 메모리 명령어가 디코더의 대역폭을 잠식합니다.

위의 그림에서 보이는 바와 같이 메모리 명령어만 연속적으로 주어질 경우엔
3개의 디코더 중 나머지 두개는 개점휴업 상태가 됩니다. (∵메모리 명령어는 단순 디코더가 처리할수 없음)
즉 클럭당 3개의 x86 명령어 -> 6개의 마이크로옵이었던 디코드 성능이
클럭당 1개의 x86 명령어 -> 2개의 마이크로옵이 되어 거의 1/3 수준으로 급감하는 것이죠.

또한 코어 마이크로아키텍처 이전까지의 인텔 CPU의 백엔드는 FPU가 80bit 명령어만을 처리할 수 있었는데
128bit 부동소수점 벡터 명령어의 경우 80bit 대역폭을 넘지 않기 위해
64bit 명령어 두개로 쪼개야 하는 문제가 있었습니다. (즉 128bit 벡터 명령어도 복합 디코더만을 점유함)

결과적으로, P6의 디코더는 P5보다 크게 향상된 구조이기는 하나
- 메모리 접근 명령어
- 128bit 부동소수점 벡터 명령어
의 경우 디코드 성능이 크게 떨어지는 문제점이 있었습니다.
이 문제점은 Pentium III때까지 존속되다가, P6 아키텍처가 재등장한 Pentium M에서 해결됩니다.


4. AMD Chomper (K6) Microarchitecture

AMD는 펜티엄 II의 경쟁상대로 K5를 개량한 K6을 개발합니다.


K6은 K5의 구조에서 크게 달라진 점은 없으나 ICU (ROB를 부르는 다른 이름입니다.) 의 용량이
종전 16 엔트리 (16개의 마이크로옵 저장) 에서 24 엔트리로 50% 증가했습니다.
또한 백엔드 구조의 개선이 있어 클럭당 최대 6개의 마이크로옵을 병렬 수행할 수 있는 구조입니다.

하지만 같은 세대 인텔 CPU와 비교하여, K6은 FPU 파이프라인 스테이지가 분화되지 않은 약점으로 인해
당시 서서히 용도가 부각되던 FPU 성능 (멀티미디어) 이 크게 떨어져 역시 펜티엄 II와 경쟁하진 못했습니다.
하지만 뛰어난 정수 성능 (동클럭 펜티엄 II보다 빠름) 과 저렴한 가격을 바탕으로 시장의 호응을 얻었습니다.


5. AMD K7 Microarchitecture

K6의 상업적인 성공에 고무된 AMD는 NexGen을 인수하고 모토롤라와 손을 잡아 새 프로세서를 개발합니다.
(모토롤라는 Apple, IBM과 더불어 RISC CPU 개발 카르텔인 AIM Alliances 을 이끌던 회사입니다.
AMD는 인텔과 x86 CPU로 경쟁함에도 불구하고 그간 RISC CPU 제조업체와 밀접한 관계를 맺어 왔습니다.)


K7의 디코더 구조를 알아보기 전에 우선 AMD가 새로 도입한 개념들을 짚고 넘어가야 합니다.
인텔의 용어에서 '매크로옵'이란 디코드되지 않은 x86 명령어를 지칭하는 말로 마이크로옵의 반대 개념이지만
여기서 소개할 AMD의 '매크로옵'이란, 디코드된 마이크로옵 두 개를 융합한 것을 지칭합니다.
(첨언하자면, 이후 펜티엄 M에서 설명할 '퓨전 마이크로옵'의 유사 개념이기도 합니다)

K7은 세 개의 디코더를 갖고 있는데, 각각의 디코더는 두 가지 작동 모드를 가집니다.
- DirectPath (= FastPath) : 1개의 매크로옵으로 변환되는 x86 명령어를 처리
- VectorPath : 2개의 매크로옵으로 변환되는 x86 명령어를 처리
(※ 드물게 3개 이상의 매크로옵으로 변환되는 x86 명령어도 있기 때문에 이 때를 대비해 '마이크로코드 엔진'이란 장치가 있는데 이러한 명령어의 비중은 대개 코드 전체에서 차지하는 비중이 극히 미미하므로 마이크로코드 엔진에 대한 설명은 생략하도록 하겠습니다)

x86 명령어는 최소 1개의 매크로옵으로 변환되는데, 매크로옵은 사실 마이크로옵 2개의 융합체이기 때문에
애초 1개의 마이크로옵으로 변환될 수 있었을 x86 명령어 2개를 1개의 매크로옵으로 합치는 것이 가능합니다.
구체적으로, K7의 디코더는 산술 명령어 1개와 메모리 접근 명령어 1개를 매크로옵으로 묶을 수 있습니다.
다만 인접한 산술+메모리 접근 명령어 조합이 없을 때에는 마이크로옵 1개만으로 매크로옵을 생성합니다.
즉 이 경우에는 산술 명령어+NoOp, 또는 NoOp+메모리 접근 명령어 조합이 되는 것이죠.
매크로옵 구조의 좋은 점은 여러 x86 명령어를 디코드한 뒤 추적하는 데 드는 자원이 절감된다는 점입니다.

즉 종합하면 K7의 디코더는 클럭당 3개의 x86 명령어를 전송받아 3~6개의 매크로옵을 생성합니다.
이는 인텔 P6의 디코더의 약점 가운데 하나였던 메모리 관련 명령어의 대역폭 잠식이 해결된 구조입니다.
또한 명령어 제어 유닛 (ICU) 의 용량이 종전 K6의 세 배인 72 엔트리로 크게 늘었습니다.
당시 경쟁 제품이었던 인텔 펜티엄 III(40 엔트리)보다도 80%나 더 넓은 ROB를 가진 셈입니다.


6. Intel Netburst Microarchitecture

펜티엄 III 시기에 인텔은 가장 큰 라이벌로 부상한 AMD의 애슬론에 고전하게 됩니다.
펜티엄 III보다 뛰어난 성능과 더 높은 클럭까지 도달 가능했던 애슬론의 마케팅적 요소를 본받아
인텔은 클럭을 높이는 데 올인하여 펜티엄 4의 근간이 되는 넷버스트 아키텍처를 설계합니다.

넷버스트 아키텍처는 클럭을 높이기 위해 깊은 파이프라인 설계에 올인하여 다른 많은 요소를 희생했습니다.
파이프라인 스테이지는 프로세서가 1클럭당 수행하는 작업의 묶음인데,
파이프라인 스테이지를 잘개 쪼갤수록 1클럭당 수행하는 작업이 줄어들기 때문에 클럭을 높이기는 쉽지만
그만큼 하나의 연산을 완료하기 위해 걸리는 클럭 사이클이 많아지므로 IPC는 크게 떨어지는 설계입니다.


넷버스트 아키텍처는 집적할 수 있는 트랜지스터의 많은 양을 깊은 파이프라인 구현에 투입하였고
결과적으로 당대의 어떤 CPU보다도 간소한 백엔드와 프론트엔드 구조를 가질 수밖에 없었습니다.
당장 전세대의 P6 아키텍처만 해도 백엔드가 동시에 처리할 수 있는 마이크로옵 갯수가 5개였는데 비해
넷버스트 아키텍처는 최대 4개의 마이크로옵밖에 처리할 수 없는 구조입니다.

또한, 프론트엔드 디코더의 설계도 크게 퇴보하여 오리지널 펜티엄과 동급의 디코딩 성능을 갖게 되었습니다.
넷버스트의 디코더는 클럭당 1개의 x86 명령어를 전송받아 1~4개의 마이크로옵으로 변환합니다.
산술적으로, 펜티엄 III에 비해 매 클럭당 디코드 가능한 x86 명령어 갯수가 1/3로 줄어든 것입니다.
이런 열악한 디코드 성능을 만회하기 위해 넷버스트 아키텍처에서는 디코더 뒤에 캐시가 위치합니다.
보통의 L1-Instruction 캐시에 해당하는 트레이스 캐시가 바로 그것입니다.

일반적으로 캐시는 프론트엔드 이전 단계에 위치해서,
CPU가 메모리로부터 명령어를 인출하는 시간을 줄이는 역할을 수행하지만 트레이스 캐시는 조금 다릅니다.
디코더 뒤에 위치하여 디코드 된 마이크로옵을 저장함으로써 디코딩 과정을 생략하게끔 도와주는 것이죠.

즉 트레이스 캐시에 저장된 명령어를 가져 오는 경우
기존 CPU들은 L1캐시 -> 페치 -> 디코드 -> ROB -> 백엔드의 5단계를 거쳐야 했지만
넷버스트는 트레이스 캐시 -> ROB -> 백엔드의 3단계만 거치면 됩니다.

하지만 필연적으로 언젠가는 캐시 미스 (Cache miss) 가 발생하기 마련이고
이런 경우엔 넷버스트의 느린 디코더가 명령어를 디코드하기를 기다려야 하므로 큰 성능 저하가 발생합니다.
(특히 다른 아키텍처보다도 넷버스트는 깊은 파이프라인 때문에 '기다림' 이 성능에 치명적인 구조입니다)

넷버스트 아키텍처의 트레이스 캐시는 12,000개의 마이크로옵을 저장해둘 수 있습니다.
기존의 L1 캐시로 환산하면 대략 16~18KB에 해당하는 용량이 됩니다.

그 밖에, 넷버스트 아키텍처에서는 ROB가 P6에 비해 크게 늘어 최대 126개의 명령어를 축적해 둘 수 있어
보다 효율적인 재정렬 및 병렬 전송이 가능합니다. 좁아진 백엔드 대역폭을 최대한 활용하기 위한 방편입니다.


7. AMD K8 / K10 / K10.5 Microarchitecture

K7로 경쟁사의 기를 꺾는 데 성공한 AMD는 K8 아키텍처를 설계하며 보다 근본적인 변화를 도모합니다.
바로 8086 시절부터 20년 넘게 사용해 온 x86 ISA (명령어 세트 아키텍처) 를 자사 주도로 바꿔 낸 것이죠.
사실 오래된 x86 ISA를 바꾸려는 시도는 이 ISA의 창시자 격인 인텔에서 먼저 있었습니다.
하지만 IA-64라 이름붙여진 새 ISA를 적용한 'Itanium' CPU가 시장에서 별 반응을 얻지 못하고 표류하던 찰나
AMD는 2003년 경 자사 주도의 새로운 ISA인 'x86-64' ISA를 제안하고, 이를 적용한 CPU인 K8을 발표합니다.
K8은 기존 x86 ISA에 대한 호환성과, 무엇보다 뛰어난 성능을 바탕으로 시장에서 즉시 채택되게 됩니다.

K8은 하드웨어적인 측면만 보자면 K7을 소폭 개량한 버전입니다.


페치 버퍼의 용량이 두 배로 커진 것이 유일한 가시적인 변화입니다.
(사실 디코더 뒤에 팩/디코드라는 단계가 추가되었지만 여기에서는 언급하지 않겠습니다)

K8의 디코더에서 개선된 부분은 매크로옵으로 융합할 수 있는 마이크로옵의 종류가 늘어났다는 것으로
기존의 산술+메모리 조합 외에도 64bit 마이크로옵 두개로 변환되는 128bit 벡터 명령어가 추가되었습니다.
종전에는 128bit SSE 명령어가 들어오면 두 사이클에 걸쳐 64bit 마이크로옵으로 디코드해야 했지만
K8에서는 한 사이클만에 하나의 128bit SSE 명령어를 한 개의 매크로옵으로 변환할 수 있게 된 것입니다.
(이는 인텔 코어 듀오/솔로가 펜티엄 M으로부터 개선된 점과 동일합니다.)

한편, K10 아키텍처는 하드웨어 구조적으로는 K8과 완전히 동일하고,
백엔드 FPU의 대역폭이 80bit에서 128bit로 향상되어 128bit 벡터 연산을 한 사이클만에 완료할 수 있습니다.


8. Intel P6 (Pentium M) Microarchitecture

넷버스트 아키텍처는 낮은 클럭당 성능으로 인한 혹평에도 불구하고
설계 당시 의도한 바와 같이 높아진 클럭으로 인해 마케팅상 유리한 고지에 설 수 있었습니다.
하지만 엉뚱한 곳에서 문제가 발생했는데, 불완전한 90nm 공정으로의 이전이 문제였습니다.
90nm 공정으로 제조된 첫 CPU인 프레스캇은 무려 31단계로 깊어진 파이프라인 스테이지을 갖고 있었는데
높은 소비전력과 발열로 인해, 깊은 파이프라인으로 희생된 IPC를 상쇄할 만큼 클럭이 올라가지 못했습니다.
따라서 인텔은 넷버스트 아키텍처를 폐기하고 기존의 P6 아키텍처를 되살려 새로운 CPU를 설계합니다.
모바일로 처음 데뷔한 펜티엄 M이 바로 그것입니다.


펜티엄 M은 기존 P6과 거의 똑같은 백엔드 구조를 가졌고 프론트엔드 구조가 약간 변화되었습니다.
페치 버퍼와 ROB의 용량이 각각 P6보다 두배 늘었고, 디코더에 '마이크로옵 퓨전'이란 기능이 추가되었는데
바로 이것이 기존 P6 아키텍처에서 문제가 되었던 로드/스토어 명령어의 성능저하를 해결해주는 방편입니다.

기존에는 복합 디코더에서만 처리 가능한 메모리 접근 명령어가 연속적으로 전달될 경우
다른 두 개의 단순 디코더가 유휴상태가 되어 디코더 대역폭이 1/3 수준으로 줄어드는 문제가 있었는데
펜티엄 M에서는 이들 또한 단순 디코더로 전달되어 한 개의 '퓨전 마이크로옵'으로 변환됩니다.
퓨전 마이크로옵의 개념은 AMD의 '매크로옵'과 매우 비슷합니다.


기본적으로 퓨전 마이크로옵은 기존의 마이크로옵을 두개 합친 것과 같습니다.
메모리 접근 명령어의 경우 재정렬의 효율이 크지 않고, 하나처럼 붙어 다녀도 성능상 큰 영향이 없으므로
디코더 -> ROB -> 백엔드에 이르기까지 따로 분해하지 않고 묶어 두는 것이죠.

이러한 설계로 인해 펜티엄 M은
- 디코딩 성능의 향상
- 디코더 유휴상태의 방지. 즉 하는 일 없이 전기를 소모하는 경우를 없앰
라는 두가지 토끼를 잡을 수 있었습니다.

이후 등장한 코어 듀오/솔로 프로세서에서는 128bit 벡터 명령어의 마이크로옵 퓨전도 지원되기 시작했습니다.
즉 애초 P6 아키텍처의 디코더의 약점으로 지적되었던 부분들을 모두 개선한 것이죠.


9. Intel Core Microarchitecture

인텔은 펜티엄 M의 개량된 P6 아키텍처를 더욱 발전시켜 '코어' 아키텍처를 쓴 코어2 CPU를 발표합니다.
코어2의 백엔드는 역대 최고속이었던 AMD 애슬론의 백엔드와 같은 대역폭(6-uop 병렬 처리)을 지원하며
이에 걸맞게 코어 아키텍처에서는 프론트엔드에도 큰 변화가 있었습니다.


일단 페치 버퍼와 디코더 사이에 '루프 탐지기'라는 하드웨어가 추가되었습니다.
코어2의 루프 탐지기는 18개의 x86 명령어를 저장할 수 있는 일종의 버퍼인데,
프로그램에서 루프가 탐지될 경우 (즉 몇 개의 명령어를 반복적으로 수행할 경우)
분기 예측 및 페치 과정을 생략하고, 자신이 저장한 명령어를 곧바로 디코더에 전달해 줍니다.

루프 탐지기의 등장으로 상대적으로 페치 버퍼의 중요성이 줄어
코어의 페치 버퍼 용량은 펜티엄 M의 절반 수준으로 줄어들었습니다.

한편 코어2의 디코더는 종전 P6의 3개에서 4개로 증가된 형태입니다. (단순 디코더가 1개 증가)
거기다가 디코드 전 단계에 '매크로옵 퓨전'이란 기능이 추가되었는데, x86 명령어 두 개를 하나로 묶은
'퓨전 매크로옵'을 사이클당 한 개씩 생성해 네 개의 디코더 중 하나로 전송할 수 있습니다.
즉 사이클당 디코더로 전송 가능한 x86 명령어의 갯수는 총 4+1 = 5개가 되는 셈이죠.
기존 P6 프론트엔드의 사이클당 3개 x86 명령어에서 67%나 증가한 수치입니다.
(※ AMD의 매크로옵이란 용어와 혼동을 방지하기 위해 그림에는 x86-op Fusion으로 표시했습니다.
AMD의 매크로옵과 코어2의 매크로옵이란 용어는 개념이 약간 다른데,
AMD의 매크로옵은 이미 디코드된 마이크로옵 두개를 융합한 것이고
코어2의 매크로옵은 디코드되지 않은 x86 명령어 두개를 융합한 것입니다)

매크로옵 퓨전이 가능한 명령어의 종류는 한정적인데, 코어2는 다음의 두 가지를 묶을 수 있습니다.
- Compare-and-test 명령어
- 분기 명령어


또한 기존의 CPU들은 백엔드의 FPU가 받을 수 있는 명령어 대역폭이 80bit로 한정되어 있었는데
코어2는 FPU 대역폭을 128bit로 확장해서, 128bit 벡터 명령어를 한 사이클만에 처리할 수 있습니다.
이 덕분에 코어2는 부동소수점 벡터 성능이 거의 두 배에 가깝게 향상될 수 있었습니다.

종합하면, 코어2는 사이클당 최대 5개의 x86 명령어를 7개의 (퓨전)마이크로옵으로 변환할 수 있는데
기존의 x86 명령어:마이크로옵 비율과 비교하면 상대적으로 더 1:1에 가까워진 것을 알 수 있습니다.
- P5: 1개의 x86 -> 2개의 마이크로옵 (1:2 = 200%)
- P6: 최대 3개의 x86 -> 6개의 마이크로옵 (1:2 = 200%)
- 넷버스트: 1개의 x86 -> 4개의 마이크로옵 (1:4 = 400%)
- 코어: 5개의 x86 -> 7개의 마이크로옵 (5:7 = 140%)
이것이 의미하는 것은 x86 명령어당 마이크로옵 비율이 줄어듦에 따라,
쓸데없이 많이 생성된 마이크로옵을 추적하는 데 드는 자원(= 소비전력)을 줄일 수 있다는 점입니다.


10. Intel Nehalem Microarchitecture

코어2 시리즈의 인상적인 성능을 발판으로 인텔은 이를 소폭 개량한 네할렘 아키텍처를 발표했습니다.


네할렘의 백엔드는 코어의 백엔드와 똑같고, 프론트엔드 구조도 아래의 4가지를 제외하면 거의 비슷합니다.
- 페치 버퍼의 크기
- 루프 탐지기의 위치
- 루프 탐지기의 용량
- ROB의 용량

일단, 네할렘에서는 루프 탐지기를 종전의 페치 버퍼~디코더 사이에서 디코더~ROB 사이로 옮겼습니다.
따라서 루프가 감지될 경우 기존의 분기예측/인출 뿐만 아니라 디코딩 과정까지 생략할 수 있게 되었는데
보기에 따라서 넷버스트 아키텍처의 트레이스 캐시와 유사한 구조라고 생각할 수 있습니다.

또한 기존에는 루프 탐지기가 18개의 x86 명령어를 저장할 수 있었는데
네할렘 아키텍처에서는 28개의 마이크로옵을 저장하도록 바뀌었습니다.
x86 명령어와 마이크로옵을 일대일로 비교할 수는 없지만 대략 1.5배 가량 늘어난 용량입니다.
향상된 루프 탐지기로 인해 상대적으로 페치 버퍼의 역할이 줄어들었기 때문에
페치 버퍼의 용량은 크게 줄어들었습니다. 코어/넷버스트/P6보다 작은 것은 물론 P5와 비슷한 수준입니다.

또한 네할렘 아키텍처에서는 매크로옵 퓨전 될 수 있는 x86 명령어의 종류가 몇가지 더 추가되었습니다.

한편 ROB의 용량도 종전 코어의 96 엔트리에서 128 엔트리로 33.3% 증가했는데,
덕분에 더 효율적인 재정렬 및 백엔드로의 명령어 동시 공급이 가능해졌습니다.
대체로 스루풋은 ROB 용량에 비례하므로 네할렘은 코어보다 최대 33.3% 향상된 IPC를 갖게 되었습니다.


11. Intel Sandy Bridge Microarchitecture


샌디 브릿지의 디코더 구조는 네할렘 아키텍처와 거의 같습니다.
샌디 브릿지의 주된 변화점은 과거 넷버스트에서 쓰였던 '트레이스 캐시' 를 공식적으로 재도입했다는 것과
ROB의 용량이 네할렘의 128 엔트리에서 168 엔트리로 31% 가량 향상되었단 것입니다.

과거 넷버스트 아키텍처에서 트레이스 캐시가 L1-Instruction 캐시를 대체한 것과 달리
샌디 브릿지는 그대로 L1-Instruction 캐시를 가지면서 프론트엔드에 트레이스 캐시가 추가된 형태입니다.

그 밖에도 샌디 브릿지는 백엔드 부동소수점 포트의 대역폭을 256bit로 확장해
256bit AVX 명령어를 한 사이클에 처리할 수 있게 되어 향후 성능향상이 기대되고 있습니다.
(다만 기존의 128bit 명령어를 두배 빨리 처리한다든지 하는 식의 응용은 불가능해
대역폭 확장으로 인한 기존 어플리케이션에서의 성능 향상은 거의 없다는 한계를 가집니다)


12. AMD Bulldozer Microarchitecture

불도저는 전통적인 AMD의 디코더 구조를 바탕으로 인텔이 도입한 여러 기법들을 채용했습니다.
프론트엔드 구조를 설명하기에 앞서, 우선 불도저의 '모듈'구조를 짚고 넘어가도록 하겠습니다.

아시다시피 1 불도저 모듈은 명목상 2코어로 작동하지만 실제 2코어로 보기엔 불완전한 부분이 많습니다.
백엔드 레벨에서 '두 코어'가 부동소수점 유닛을 공유한다는 점 외에도 근본적으로 2코어가 아닌 이유는
프론트엔드 레벨에서 대부분의 단계를 '두 코어'가 공유하고 있기 때문입니다.
즉 CPU 성능을 핵심적으로 좌우하는 디코더 및 ROB는 1모듈당 한 세트밖에 탑재되어 있지 않습니다.
즉 불도저가 '2코어'에 걸맞게 보유하고 있는 하드웨어는 사실 백엔드의 정수/메모리 유닛밖에 없어
단지 이것만을 근거 삼아 1 불도저 모듈을 2코어로 정의하기엔 어려움이 있습니다.

그럼 이제 불도저의 프론트엔드 구조를 보도록 하겠습니다.


큰 틀에서 디코더 구조는 기존의 AMD 방식을 따르고 있습니다.
하나의 디코더가 내부적으로 Direct Path / Vector Path 두 가지의 작동 모드를 가지며,
1개의 매크로옵으로 변환될 x86 명령어는 Direct Path에 배정돼 사이클당 1개의 매크로옵을 생성하고
2개의 매크로옵으로 변환될 x86 명령어는 Vector Path에 배정돼 사이클당 1개의 매크로옵이 됩니다.

'매크로옵'으로 묶일 조건은 1개의 산술 명령어와 1개의 메모리 접근 명령어가 쌍을 이루는 것인데
서로 인접한 산술/메모리 접근 명령어가 없을 때에는 각자 NoOp을 포함한 1개의 매크로옵이 됩니다.
즉 정수 연산/Load Address 명령어가 인접해 있을 때는 이 둘이 하나의 매크로옵으로 융합되지만
산술 명령어만 연속적으로 들어오는 경우라면 각 산술 명령어는 "산술-NoOp" 형태의 매크로옵이 됩니다.
즉 디코더의 대역폭을 최대한 활용하기 위해서는 들어오는 명령어의 조합이 대단히 중요합니다.

불도저는 이러한 디코더를 4개 내장해 사이클당 4개씩의 x86 명령어를 매크로옵으로 변환하며,
생성되는 매크로옵 갯수는 사이클당 4개~8개가 됩니다. (마이크로옵 단위로는 최저 4개~최대 16개)
이렇게 생성된 매크로옵은 ICU(ROB에 해당)에 저장되는데, ICU의 용량이 종전 K10의 72-Entry에 비해
128-Entry로 거의 78%가량 늘어 불도저의 스루풋 역시 그만큼 향상되었을 것으로 짐작됩니다.
ICU는 백엔드와 연결되어 각 정수 코어 및 공유 부동소수점 유닛에 각각 4개씩의 매크로옵을 전송합니다.
즉 총 명령어 포트가 12개인 셈으로 불도저는 지금까지 발표된 어떤 CPU보다도 넓은 백엔드를 가집니다.

주목할 점은 인텔 CPU에 도입되었던 루프 탐지기(Loop Stream Detector)와 트레이스 캐시의 등장입니다.
루프 탐지기는 앞서 인텔 코어 아키텍처에 대해 설명하면서 언급한 바 있는데,
명령어의 루프가 감지될 경우 해당 루프 전체를 탐지기 내부에 저장해서
루프가 종료될 때까지 별도의 인출 절차를 생략하고 바로 탐지기로부터 명령어를 공급받도록 합니다.
이 장치는 코어 아키텍처가 전세대에 비해 압도적인 성능 향상을 이룰 수 있던 비결 중 하나입니다.

또한 트레이스 캐시는 인텔 넷버스트 아키텍처 및 최근의 샌디 브릿지에서 도입된 장치로
디코드되기 전 단계의 x86 명령어를 저장해두는 기존의 L1-Instruction 캐시와 달리 이미 디코드된 마이크로옵을 저장해 둠으로써 캐시를 억세스할 때 인출-디코드 절차를 생략할 수 있습니다.
트레이스 캐시가 완전히 L1-Instruction 캐시를 대체했던 넷버스트와는 달리 불도저는 샌디 브릿지처럼 L1-Instruction 캐시와 트레이스 캐시가 CPU 내부에 공존하는 형태인데 이 덕분에 트레이스 캐시는 일종의 "L0 캐시" 처럼 기능하게 됩니다.

불도저의 트레이스 캐시 및 (그림에는 표시되지 않았지만) L1-Instruction 캐시는 각 코어별로 분화되어 각각 별개의 스레드를 전담하는 역할을 합니다. (이와 달리 L1-Data 캐시는 두 코어가 공유합니다)

아시다시피 불도저는 기본적으로 1모듈-2스레드 구조인데, 불도저의 싱글스레드 성능도 궁금하실 겁니다.
싱글스레드만을 지원하는 어플리케이션 하에서 가동되는 불도저의 프론트엔드 유닛은 아래와 같습니다.


이로써, 크리티컬 패스의 위치에 따라 다르겠지만, '싱글코어' 불도저의 성능은 대략 아래와 같을 것입니다.
- 디코더가 병목현상을 유발할 경우: K10 대비 33% 향상
- 병목현상이 없을 경우: (ROB의 In-flight 명령어 갯수에 비례해) K10 대비 78% 향상
- 백엔드가 병목현상을 유발할 경우: K10 대비 33% 향상

즉 불도저의 싱글스레드 성능은 전세대에 비해 매우 큰 폭으로 향상될 것이 확실시됩니다.
오히려 상당수의 유닛을 공유하기 때문에 멀티스레드 성능이 기존만큼 크게 증가하지 않을 가능성이 있는데
기존의 '느린 코어를 많이 집어넣는' K10까지의 전략과는 분명히 다른 방향이라고 할 수 있습니다.

 

//

 

아래 위젯은 일종의 크라우드펀딩 플랫폼인 티스토리 '밀어주기' 서비스 위젯입니다. 100원부터 3000원까지의 범위 내에서 소액기부가 가능하며, 이런 형태의 펀딩이 성공적일 경우 '이해관계자로부터 독립된 벤치마크' 의 지속 가능한 원동력이 되리라 생각합니다. 물론 후원 없이 제 글을 읽어 주시는 것만으로도 저는 독자 여러분께 감사합니다 :)

 

 

 

IYD's Signature

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

DR.MOLA

레벨 Lv. 1 (35%)
포인트 186 p
출석 11 일 (개근 0 일)

IYD'님의

  1. 08_amd_k7.jpg (File Size:55.4KB/Download:0)
  2. 03_intel_p5_revised.jpg (File Size:40.5KB/Download:0)
  3. 04_amd_k5.jpg (File Size:43.0KB/Download:0)
  4. 02_frontend_overview.jpg (File Size:81.0KB/Download:0)
  5. 11_intel_pentium_m_revised.jpg (File Size:47.6KB/Download:0)
  6. 06_intel_p6_limits.jpg (File Size:50.4KB/Download:0)
  7. 16_amd_bulldozer_2t_revised.jpg (File Size:108.3KB/Download:0)
  8. 17_amd_bulldozer_1t_revised.jpg (File Size:0Byte/Download:0)
  9. 07_amd_k6.jpg (File Size:43.9KB/Download:0)
  10. 12_intel_pentium_m_cont_revised.jpg (File Size:69.0KB/Download:0)
  11. 13_intel_core_revised.jpg (File Size:61.4KB/Download:0)
  12. 01_general_architecture.jpg (File Size:78.2KB/Download:0)
  13. 14_intel_nehalem_revised.jpg (File Size:60.6KB/Download:0)
  14. 15_intel_sandy_bridge_revised.jpg (File Size:67.9KB/Download:0)
  15. 09_intel_netburst_revised.jpg (File Size:48.9KB/Download:0)
  16. 10_amd_k8_k10_k10h.jpg (File Size:54.7KB/Download:0)
facebook twitter google plus pinterest kakao story band
Profile image vico 2011.01.27 16:33
멀티스레딩 포스트부터 쭈욱 정주행하며 재미있게 잘 읽었습니다.
프론트엔드, 백엔드의 역할 정도만 알고 있었는데 이런 친절한 설명이라니..
특히 INTEL과 AMD의 기술력 대결이 드라마처럼 흥미진진하게 느껴지네요.
북마크해두고 가끔 놀러 오겠습니다. :)
수정 삭제
Profile image ㄷㄱ ver.2 2011.01.27 18:04
오 이런 반가운 소식을^^
감사합니다. 자주 놀러오세요~
수정 삭제
Profile image K.S.J 2011.01.27 18:15
안녕하세요, 늘 포스트 잘 보고 있습니다...
알기 쉽게 설명해주셔서 읽으면서 그동안 많은 지식들을 쌓을수 있었습니다ㅎㅎ
그런데.. 이 글에서 코어아키텍처부분에 페치버퍼가 64Byte로 늘었다는데
그림에서는 32Byte로 표시가 되어있네요. 수정해야할 부분이 아닐까 싶네요..
어쨌든 앞으로도 많은 컴퓨터 지식들 기대하겠습니다~ㅎㅎ
수정 삭제
Profile image ㄷㄱ ver.2 2011.01.28 01:18
앗 그렇군요! 수정하겠습니다ㅋㅋ

//

내용을 다시 점검해보니 본문이 틀렸군요^^;
펜티엄 M의 페치 버퍼는 64-Byte였는데 코어는 32-Byte로 오히려 줄었습니다.
수정 삭제
Profile image K.S.J 2011.01.30 21:40
안녕하세요~^^ 이번에는 질문이 댓글을 있어서 올리게 됬습니다.
P6아키텍처를 보면 메모리 명령어가 연속적으로 주어질 경우 디코더의 성능이
1/3으로 떨어진다고 되어있는데요, 단순 디코더2개가 일을 안하는건 이해가 되는데
복합 디코더의 절반이 일을 안하는게 이해가 잘 안되서요;;
혹시 위에 나와있는 '메모리 접근이 잦은 서버/오피스 프로그램의 경우 이러한 메모리 명령어가 디코더의 대역폭을 잠식합니다.'가 그에 대한 해답인가요?
수정 삭제
Profile image ㄷㄱ ver.2 2011.01.30 23:51
복합 디코더는 1개의 x86 명령어를 최대 4개의 마이크로옵으로 분해하는데, 어떤 x86 명령어가 몇개의 마이크로옵으로 분해되는지는 그 명령어의 종류에 달린 것이지 디코더가 신경쓸 부분이 아닙니다.

로드/스토어 명령어의 경우 2개의 마이크로옵으로 분해되는 종류에 해당하고, 이 경우 복합 디코더는 일을 안 하는게 아니라 복합 디코더가 정상적으로 작동해서 생성하는 마이크로옵 수가 2개일 뿐인 것이죠.
수정 삭제
Profile image K.S.J 2011.01.31 09:59
아, 그런거군요ㅎㅎ 감사합니다~
수정 삭제
Profile image Bible 2011.02.03 09:54
잘 읽었습니다.
정말 깊은 지식에 감탄하고 갑니다.

ㄷㄱ님께서 예측하신 불도저의 싱글코어 성능향상은 최소 33% 정도이군요. 그렇다면 이게 네할렘이랑 비교시 우위를 점할 수 있는 수치이겠네요
수정 삭제
Profile image K.S.J 2011.02.19 23:47
음... 안녕하세요~ㅎㅎ 역시 질문이 있어서 댓글올려봅니다...
위에 Intel의 복합디코더는 Instruction fetch로부터 한주기에 1개씩 명령어를 받는데 여기서 처리된 마이크로옵 개수가 한 주기에 최대 3개, 매크로옵이 1개면... 4개를 한번에 다 전달할 수 있는건가요? x86명령어가 3개 이상의 마이크로옵으로 처리되는 경우는 미미하다고 하셨으니...
수정 삭제
Profile image ㄷㄱ ver.2 2011.02.20 00:28
인텔/AMD 양사의 CPU는 외형적으로는 똑같이 x86 명령어를 받아 처리하는 CISC CPU이지만 내부적으로는 각자의 내부 RISC 포맷으로 변환해 처리하는 구조입니다. 즉 같은 x86 명령어라도 인텔과 AMD의 내부 명령어 변환은 다르기 때문에 1:1 비교는 어렵습니다.

디코드 단계는 마이크로옵을 '처리'하는 게 아니라, x86 명령어를 마이크로옵으로 '변환'하는 과정입니다. 즉 마이크로옵을 '생성'하는 단계라고 보면 되죠.

네할렘을 기준으로, 인텔 CPU는 총 4개의 디코더를 가지고 있으며 각각의 디코더는 사이클당 1개씩의 x86 명령어를 내부 포맷으로 변환할 수 있습니다.
이 중 3개의 '단순 디코더'는 1개의 내부 명령어로 변환되는 x86 명령어만을 처리할 수 있는 반면, 1개의 복합 디코더는 2개 이상의 내부 명령어로 변환되는 x86 명령어를 처리할 수 있습니다.
또한 인텔의 변환 방식은 하나의 x86 명령어를 4개 이상의 내부 명령어로 쪼개지 않기 때문에(대부분의 경우에) 복합 디코더가 최대 4개까지의 내부 명령어만을 생성하도록 만들어진 거죠.

마찬가지로, AMD는 1개의 x86 명령어를 1개~2개의 '매크로옵'이란 단위로 변환하는데 여기서 매크로옵이란 '마이크로옵'을 두 개 묶은 단위를 말합니다. 마이크로옵은 CPU의 내부 명령어 포맷을 의미하죠.
AMD의 변환 방식으로는 (대부분의) x86 명령어는 2개 이하의 매크로옵으로 변환됩니다. (2개의 매크로옵 = 4개의 마이크로옵... 즉 어차피 인텔과 비슷한 거죠)

물론 디코더만으로 모든 x86 명령어를 해독할 수 있는 건 아니어서, 예컨대 인텔의 경우 x86 명령어 중에서 5개 이상의 마이크로옵으로 분해되는 것도 존재하고 AMD의 경우는 3개 이상의 매크로옵을 생성하는 x86 명령어도 존재하기는 합니다.
다만 그 빈도가 매우 낮기 때문에 이런 소수의 명령어를 전담하는 디코더를 설치하기보다는, 미리 해당 명령어에 대응하는 내부 명령어를 입력시켜 둔 일종의 '롬(rom)'을 CPU 내부에 두어 복잡한 x86 명령어의 처리를 도맡게 하고 있습니다.
수정 삭제
Profile image K.S.J 2011.02.20 00:20
어익후... 제가 기존에 이해했다고 생각했던게 대부분 틀린것이었네요;; 어찌됬든 뒤늦게라도 이해했으니 다행이네요ㅎㅎ 감사합니다~
수정 삭제
Profile image 몰라서.. 2011.03.23 16:26
ROB 용량과 IPC가 비례하는 군요...

근데 왜 AMD는 불도저의 ROB를 샌디브릿지보다

적게 한거죠..?

그리고 프론트엔드만 보았을때

ROB의 용량이 같은 불도저와 네할렘의

프론트 엔트 효율은 어느것이 더 뛰어난지도 좀..
수정 삭제
Profile image ㄷㄱ ver.2 2011.03.24 01:03
프론트엔드엔 인출/디코드/제어까지가 포함되는데, 현재까지 비교할 수 있는 건 디코더 부분뿐이라 나머지 부분이 어떻게 될지 몰라 네할렘과 불도저의 프론트엔드 효율을 평가할 수는 없습니다. 다만 불도저의 "알려지지 않은" 나머지 부분이, 최악의 경우엔 K10과 동일하리라는 가정 하에 K10 대비 어느 정도 향상일 것이란 추정이 가능하죠. (최악의 상황이 아니라면 "알려지지 않은" 나머지 부분도 K10보단 좋을 것이고요. 사실 불도저는 K10의 개량이라기보다는 완전히 새로운 설계라 K10과 비슷하다는 것을 전제로 분석한 성능 예측은 정확하지 않게 될 가능성이 많습니다. 아마 "알려지지 않은" 나머지 부분에서도 K10과 비교해서 모종의 개정이 있었으리라 추측해 보겠습니다)

ROB는 in-flight operations 갯수를 나타내게 되는데, 위와 마찬가지 이유로 완전히 다른 아키텍처끼리 ROB 갯수만으로 1:1 비교를 할 수는 없고, 기존의 유사한 아키텍처와의 비교를 통해 간접적으로 유추해 봐야 합니다. 예를 들어 펜티엄 III과 애슬론을 비교할 땐 ROB 용량 차이가 40 entry vs 72 entry로 애슬론이 1.8배 가량 더 높은데 IPC 차이가 80%나 벌어지지는 않았으니까요. (비슷한 아키텍처간의 비교에선 린필드(네할렘)와 요크필드(코어)를 생각해 보시면 이해가 쉬울 겁니다. 반면 ROB 용량이 매우 컸던 넷버스트는 그 전/후의 아키텍처 (P6, 코어) 들과 ROB 용량으로 직접 비교가 불가능한데, 그 이유는 P6/코어 vs 넷버스트가 설계 철학이 전혀 다른 -비슷하지 않은- 아키텍처였기 때문입니다)
수정 삭제
Profile image 몰라서.. 2011.03.23 16:32
http://gigglehd.com/zbxe/5398252

그리고 이 글 밑부분 질답에 대해서도 대충이라도 설명을 해주셨으면

좋겠어요 ^^;; 염치없이 많이 바라는것 같아서 죄송합니다
수정 삭제
Profile image ㄷㄱ ver.2 2011.03.24 01:12
질의응답엔 터보부스터 2.0의 설명에 상당히 많은 분량을 할애한것 같은데...
죄송하지만 그건 저도 잘 몰라서 뭐라 덧붙일 말이 없습니다^^;;
수정 삭제
Profile image ㅎ;; 2011.03.24 16:18
평상시 컴퓨터 관련 커뮤니티에서 논쟁이 될까봐 언급을 피하시는

모습이 역력하시던데 개인적인 불도저 성능 예측 좀 해주세요 ^^;;
수정 삭제
Profile image ㄷㄱ ver.2 2011.03.25 19:41
이 글이랑 이 전 글(백엔드 편)에서 다룬 내용이 제 능력 선에서 이야기할 수 있는 전부입니다^^;

싱글스레드 성능이 뒤지더라도 각 스레드 성능의 총 합을 늘리는게 목적이었던 투반과 달리 불도저의 싱글스레드 성능은 상당히 높을것 같은데 오히려 각 스레드 성능의 총 합이 (마케팅적인 수사로) "8코어" 어치가 될는지가 의문입니다. 아시다시피 각 스레드를 담당하는 자원끼리 공유하는 부분이 있으니까요.

싱글스레드 성능이 (1/2모듈 대 코어로) 샌디브릿지와 비슷하다면, 4모듈(8스레드) 불도저는 6코어 샌디브릿지와 비교할만하지 않을까 생각됩니다. 즉 싱글 대 싱글보다 멀티 대 멀티가 오히려 불리해질 꺼란 예측이죠. (거꾸로 말해 싱글스레드 성능은 최소한 그 만큼까지는 향상될 것으로 예상하고 있습니다)
수정 삭제
Profile image ㅎ;; 2011.03.29 20:45
오.. 제발 그 정도로만 나와줘도 좋겠네요..

바로 지를텐데.. 2분의 1모듈이 샌디수준의 성능이라면...

1모듈의 자원을 싱글스레드 처리에 몰아준다면.. 게임성능이나

실 체감 성능도 엄청나겠군요.. 지금 투반에서 업글할 메리트가 확실히

생길듯..
수정 삭제
Profile image presvi 2011.04.06 22:27
제가 문외한이라 초보적인 질문이지만, 궁금한 것이 있습니다. 전편 백엔드 설명하실때 파이프라인 깊이, 스테이지 수 (스테이지 수가 깊이라고 하셨던가요), 연산 처리속도, 클럭속도에 대해서 언급하셨는데 그들의 대략적 관계가 어떻게 되는것인지요? 스테이지가 단순하면 클럭이 높아지는 대신 명령 수행속도가 느려진다...고 하셨던가..(아까 읽은것도 가물가물;;) 사실 일반인은 클럭이 높으면 무조건 속도가 빠르다 고 생각하는데 저 셋, -스테이지수(=파이프 깊이?), 클럭속도, 연산속도의 관계가 어떻게 되는지 간단히라도 설명해 주시면 감사하겠습니다. 그리고 비슷해 보이는 모델명을 가진 CPU들이 스펙에 L1.L2,L3같은 사양도 같이 기재하는데, 그 캐시들 중에 L2 캐시가 높은것이 더 좋은 것인가요? 코어 정격 클럭이 차이가 나도 캐시때문에 실제 체감 성능이 비슷해질수도 있는것인가요..?
수정 삭제
Profile image ㄷㄱ ver.2 2011.04.06 22:48
파이프라인에 대해서는 이 글을 참조하세요: http://udteam.tistory.com/266
궁금해하시는 모든 꼭지가 다뤄지진 않았지만 대충 감을 잡는 덴 도움이 될 거라 생각합니다.

그리고 캐시는... 일단 서로 다른 아키텍처 사이에선 캐시를 일대일로 비교하는게 무의미하고, 같은 아키텍처의 경우엔 L3 캐시보단 L2 캐시가, L2 캐시보단 L1 캐시가 더 중요합니다. 즉 이론상 가장 이상적인 건 대용량의 L1 캐시를 탑재하는 것이죠. (그게 아니면 하다못해 대용량의 L2 캐시라도... 물론 L2 캐시가 조금 적더라도 거대한 L3 캐시가 있는 경우엔 얘기가 또 달라집니다만)

캐시라는 중간계층 메모리가 없는 경우에 CPU는 주기억장치인 램으로부터 명령어/데이터를 읽어 오는데, 분기 예측에 실패해 엉뚱한 명령어를 읽어 온 경우 이를 취소하고 다시 새 명령어를 읽어 오는 시간은 CPU의 입장에서는 매우 긴 시간입니다. (∵ 램이 CPU보다 한참 느리므로) 이러한 '느린 램을 기다리는 시간'을 줄이기 위해 쓰일 가능성이 높은 명령어/데이터를 미리 CPU 근처에 담아 두는 공간이 캐시인데, CPU와 가장 가까운 곳에 최고속의 캐시를 장착하지만 CPU의 제조비용이 상승하는 관계로 고속의 캐시 용량을 늘리는 데는 한계가 있습니다.

캐시의 저용량은 곧 '필요한 명령어를 미리 담아두지 못하는' 상황과 직결되므로, 이러한 저용량을 보완하기 위해 다시 고속 캐시와 램의 중간 단계에 '약간 느리지만 그래도 램보다는 빠른, 용량이 좀 더 큰 캐시'를 두고, 다시 그 밑에 '조금 더 느리지만 여전히 램보다는 빠르고 용량이 많이 큰 캐시'를 두기도 합니다. 이것들이 L1 / L2 / L3 캐시로 일컬어지죠.

http://udteam.tistory.com/202 이 글을 읽어보시면 궁금한 부분이 해결되실것 같기도...^^
수정 삭제
Profile image presvi 2011.04.06 23:01
오.... 친절한 답변 감사드립니다. ^^ 링크해주신 글 읽어보면 더욱 도움이 되겠군요. 어서 봐야겠네요..ㅎㅎ
수정 삭제
Profile image Mayfly 2011.08.25 02:36
먼소린진 하나도 모르겠지만 백엔드 부터 머리 쥐어짜며 보고 있습니다..
제 머리는 파이프라이닝 되어있지 않나보군요 ㅠㅠ
지금 눈이 터질거 같아요.. 오늘은 여기까지만 보고 내일 봐야겠습니다
정말 멋진글이네요
수정 삭제
Profile image ㄷㄱ 2011.08.25 16:56
엇 이 댓글을 못보고 지나칠뻔 했네요^^;;
읽어 주셔서 감사합니다. 오늘도 다녀갔단 흔적 남겨주세요~^^
수정 삭제
Profile image kym 2011.08.27 22:40
대근님의 포스팅을 보니 불도저의 구조가 단일 스레드혹은 모듈로만 놓고 봤을때는 상당히 효율적인 구조인것은 확실한 것 같습니다.
다만, 구조적으로 타 아키텍쳐보다 세분화 되어있고, 무엇보다도 모듈개념을 도입하면서 정수연산부가 싱글코어대비 거의 배로 증가한점을 미루어 볼 때, 다이사이즈가 상당히 커질수밖에 없는 구조로 보입니다.(실제로 4모듈버전인 잠베지는 투반보다 다이사이즈가 큰걸로 알고 있습니다.)
또한, 불도저가 상대적으로 낮은ipc를 고클럭으로 만회하는 아키텍쳐로 알고 있는데, 고클럭을 지향하는 깊은 파이프라인 스테이지&모듈화&복잡한 프론트엔드구조로 인한 다이사이즈증가 및 소비전력상승문제가 발생하는것이라고 생각하고있습니다.
소비전력이 늘어나다보니 불도저의 클럭을 원하는만큼 끌어올리지 못하고 있고 현재까지 알려진 바와 같이 성능이 제대로 안나오는 것이고요.(캐시성능이 상당히 안좋은것도 성능이 떨어지는 이유중 하나라고 알고 있습니다.)
제 생각이 맞는것인가요?
수정 삭제
Profile image ㄷㄱ 2011.08.28 01:23
불도저의 싱글스레드 성능이 여전히 좋을 것이라 예측하는 한 사람으로써, IPC가 낮아 클럭으로 메꿔야 한다는 전제를 어느 정도까지 받아들여야 할지 잘 모르겠습니다.ㅠㅠ
물론 kym님이 말씀해주신 부분들이 실제 출시된 불도저의 성능이 기대에 못 미칠 때 충분히 근거가 될 만한 내용이긴 합니다. 즉 kym님의 생각도 타당하다고 할 수 있습니다.
수정 삭제
Profile image 항상행복하시길바라요 [비밀댓글] 2011.08.30 14:02
Profile image ㄷㄱ 2011.08.30 17:59
알려주셔서 감사합니다^^ 담당자분께 연락 드렸으니 어떤 식으로든 해결될 겁니다.
그나저나 이렇게라도 들러 주셔서 반갑네요~ 앞으로도 종종 놀러와 주세요..^^ㅋ
수정 삭제
Profile image RuBisCO 2011.10.22 18:30
그런데 궁금한게 있는데, 불도저 아키텍쳐가 낮은 IPC를 갖게 되는 이유가 자세히 나오지 않아서 그런데 상세히 알 수 있을까요? 생각 이상으로 비참한 수준으로 떨어져서 클럭상승으로 커버할 수가 있는 수준이 아니던데, 그런 부분들에 대해서는 정보가 나와있는곳이 없더군요.
수정 삭제
Profile image ㄷㄱ 2011.10.22 20:32
그 부분에 대해 확실한 심증이 있는데 아직까지 확인해보질 못해 확언을 못 하는 상황입니다.
제 추측은 아마 파이프라인 스테이지가 늘어났기 때문이란 것인데, 현재까지 나돌아다니는 어떤 기술문서를 보아도 파이프라인 스테이지에 대한 묘사를 찾을 수 없었습니다.ㅠㅠ
유일한 관련된 언급은 스테이지당 게이트 수가 줄었다는 것인데, 이것이 파이프라인의 깊이가 깊어졌다는 것을 확실히 얘기해 주고 있기는 하지만, 구체적으로 얼마나 (예: 10단계 -> 20단계가 되었다는 등) 깊어졌는지를 알려 주고 있지는 않습니다.

파이프라인 이외의 요소로는 L2캐시 성능이 엄청나게 떨어진 것도 원인인 듯 합니다. 거기에 대해선 이 글을 참조하세요.
http://udteam.tistory.com/447
수정 삭제
Profile image 우다리 2012.04.26 03:52
아이고 골이야 백엔드부터 일단 다 읽기는 했습니다

그동안 하드웨어 사이트에서 봐왔던 기사보다 훨씬 이해하기 쉽네요

mmx니 네이티브 듀얼이니 하이퍼쓰레딩이니 하는걸 피상적으로 이름만 알고 있다가 이제 좀 가닥이 잡히는 기분이 듭니다

늦었지만 수고에 감사드려요

그건 그렇고 역시 맨 마지막의 불도저가 참 뭐랄까 짠하네요

여기 정리하신 그대로가 차질없이 구현됐다면 분명히 동시기 동급공정의 네할렘 & 샌디랑 박빙의 승부가 났었을텐데, 얘기 끝난지 거의 1년이 지났지만 새삼 아쉽네요
수정 삭제
Profile image riddler 2012.05.08 04:18
cpu에 관심이 있어서 1년전 이 글을 처음봤을때, 뭔소린지 이해가 안갔는데 학교에서 컴퓨터구조란 과목을 수강하면서 보니까 이해가 확 가네요 ㅎㅎ 컴구조과목에서는 슈퍼스칼라 구조에 대해 매우 간략하게 나와있는데 이 글 덕분에 슈퍼스칼라구조와 그 이후 등장하는 cpu을 이해하는데 있어서 많은 도움이 됬습니다.
수정 삭제
Profile image 쟁이 2012.09.07 18:56
다나와에 링크된걸 따라 왔습니다.
백엔드와 프론트엔드 모두 알기 쉽게 설명해주셔서 큰 도움이 되었습니다.
더불어 무리가 안된다면 부탁을 드리고 싶은게 있는데, 캐시에 대해서 궁금한게 무지 많은데 이런 방식으로 정리해 주시면 정말 좋겠네요.
특히 인텔이 샌디브릿지(네할렘?) 이후로 L2캐시를 크게 줄이고 L3캐시를 늘린 이유가 무엇인지, 그리고 인텔과 AMD가 캐시의 스펙에 있어서는 과거부터 많이 달랐던 이유 등이 정말 궁금하거든요.
앞으로도 좋은 글 기대하겠습니다.^^
수정 삭제
Profile image Haswell 2013.02.14 06:52
그림 퍼갈게요. 출처는 표기 합니다. ㅎㅎ
수정 삭제
Profile image 회달 2013.03.10 13:48
잘봤습니다. ^^ 쉽게설명해주시고.. 퍼갈게용
수정 삭제
Profile image 카베리 2016.03.21 21:10
좋은 글 잘 봤습니다. 감사합니다. 그리고 요즘 나온 CPU(=이 글이 씌여진 이후 나온 CPU)들도 분석해서 올려주시면 좋겠습니다.
수정 삭제
Profile image IYD_jhlee 2016.03.21 21:45
넵. X86뿐만 아니라 ARM까지도 넓혀서 글 준비중이에요~ 조금만 기다려 주세요
수정 삭제
  • [VGA] VGA calculator : 2014 updates [9] secret

    비밀글입니다.

    • IYD |
    • 14.01.16 |
    • 조회 1 |
  • AMD 본사 직원 인터뷰 : 스팀롤러와 HSA의 의의 [ICT] AMD 본사 직원 인터뷰 : 스팀롤러와 HSA의 의의 [4] file

    Interviewer & Author : Daeguen Lee Interviewee : Adam Kozak, Terry Makedon (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 지난 12일엔 서울 모처에서 AMD의 APU Tech Day 행사가 열렸습니다. 이 글에서 간단히 행사장 전경을 전달해드렸었죠. 당시 AMD ...

    • IYD |
    • 14.01.15 |
    • 조회 34 |
  • [VGA] A speculation on GTX 790 [2] secret

    비밀글입니다.

    • IYD |
    • 14.01.05 |
    • 조회 0 |
  • 맥 프로의 가치 [ICT] 맥 프로의 가치 [7] file

    Author : Daeguen Lee(Any action violating either copyright laws or CCL policy of the original source is strictly prohibited)0. 내색한 적은 한번도 없지만 (그리고 아무도 안 믿을테지만) 내겐 완제품 PC에 대한 로망이 있다. 특히 맥... 새로 나온 맥 프로가 그간 이미지로만 보던것과 달리 매우 아담하단 사실에 ...

    • IYD |
    • 13.12.26 |
    • 조회 39 |
  • 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 |
    • 조회 9 |
  • [VGA] 라데온 R9 290 -> R9 290X 변신?! [14] secret

    비밀글입니다.

    • IYD |
    • 13.11.15 |
    • 조회 2 |
  • [VGA] GeForce GTX 780 GHz에 관한 썰 [4] secret

    비밀글입니다.

    • IYD |
    • 13.10.31 |
    • 조회 0 |
  • NVIDIA GeForce GTX 780 Ti 성능 예측 [VGA] NVIDIA GeForce GTX 780 Ti 성능 예측 [6] file

    글쓴이 : 이대근연락처 : leedaeguen [at] kaist.ac.kr(이 블로그의 CCL정책에 위배되는 무단전재 및 재배포를 금지합니다)두시간 전 해외 포럼인 ChipHell을 통해 GTX 780 Ti의 사양으로 추정되는 스크린샷이 유출되었습니다.▲ GTX 780 Ti의 사양으로 2496SP설, 2688SP설, 2880SP설 등이 분분했는데, 위의 정보가 정확한 것...

    • IYD |
    • 13.10.22 |
    • 조회 51 |
  • An essay on NVIDIA GeForce GTX 780 Ti [VGA] An essay on NVIDIA GeForce GTX 780 Ti [5] file

    글쓴이 : 이대근 (이 블로그의 CCL 정책에 위배되는 무단전재 및 재배포를 금지합니다) 엔비디아에서 방금 지포스 GTX 780 Ti라는 새 제품의 출시를 예고했습니다. 그간의 네이밍 정책에 비춰 볼 때 해당 제품은 GTX 780의 상위 모델일 것은 확실하나 모델 넘버가 없는 GTX TITAN과의 우열관계는 확실치 않은데, 일단 단선적...

    • IYD |
    • 13.10.19 |
    • 조회 5 |
  • FCAT : 프랩스에 종언을 고함 [VGA] FCAT : 프랩스에 종언을 고함 [2] file

    글쓴이 : 이대근 (이 블로그의 CCL정책에 위배되는 무단전재/재배포를 금지합니다) 재미있는 글을 읽었습니다. 일단 글을 소개하자면 원문은 아래 링크와 같습니다. (see this : http://techreport.com/review/24553) 간단히 요약하자면 "Fraps로 측정하는 프레임레이트는 정확하지 않다. 나아가 현존하는 모든 방식의 프레...

    • IYD |
    • 13.09.30 |
    • 조회 17 |
  • GK110, 하와이 가상 대결 : by VGA 계산기 [VGA] GK110, 하와이 가상 대결 : by VGA 계산기 [7] file

    글쓴이: 이대근 (이 블로그의 CCL 정책에 위배되는 무단전재/재배포를 금지합니다) 그동안 '그래픽카드 성능 방정식'을 사용해 몇번의 포스팅을 올리곤 했는데, 혹시 이 방정식의 배경이 궁금하셨던 분은 안 계셨는지요. 오늘은 아직 출시되지 않은 '가까운 미래의' 그래픽카드의 성능을 예측함과 함께 그간 한번도 직접적으...

    • IYD |
    • 13.09.12 |
    • 조회 24 |
  • [VGA] A short essay on GK110 [4]

    글쓴이: 이대근 (이 블로그의 CCL 정책에 위배되는 무단전재/재배포를 금지합니다) 지금으로부터 약 19개월 전, AMD는 코드명 Southern Islands로 명명된 새 GPU를 발표했고 이들 제품군은 전세대 자사/경쟁사 플래그십 제품군 대비 2배~2.5배에 가까운 압도적인 성능 향상을 가져온 반면 소비전력은 전세대와 별 차이가 없...

    • IYD |
    • 13.09.05 |
    • 조회 7 |
  • [ICT] 주파수경매 총평

    글쓴이: 이대근 연락처: leedaeguen [at] kaist.ac.kr (이 블로그의 CCL 정책에 위배되는 무단전재/재배포를 금지합니다) 주파수경매 총평 (매우 주관적임) : 1. KT는 (이미 보유하고 있던) 1.8GHz대역 20MHz폭(업로드 10/다운로드 10)의 바로 옆에 추가로 15MHz폭(업 5/다운 10)을 보유하게 됨으로써 별도의 기술적 변경 없...

    • IYD |
    • 13.08.31 |
    • 조회 18 |
  • [VGA] 지포스 GTX TITAN 성능 예상 : by VGA 계산기 [3]

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) ▶ 참고글1: http://iyd.kr/488 (그래픽카드 성능 방정식을 이용한 7970/680 성능 예측) ▶ 참고글2: http://iyd.kr/200 (그래픽카드 성능 방정식을 이용한 페르미 라인업의 성능 예측) ▶ 참...

    • IYD |
    • 13.02.19 |
    • 조회 32 |
  • It still works! : VGA 계산기로 돌려 본 7970, 680 예상 성능 [VGA] It still works! : VGA 계산기로 돌려 본 7970, 680 예상 성능 [8] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 안녕하세요. 한동안 올릴 글이 없었는데 지인의 요청을 받고 간단히 해 본 실험입니다.ㅎㅎ 다름이 아니라...... 오래 전 만든 'VGA 성능 방정식' 이 최신 VGA에까지 적용이 가능한지 여부...

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

    비밀글입니다.

    • IYD |
    • 11.10.17 |
    • 조회 4 |
  • [VGA] Hybrid PhysX 구성 팁 [12] secret

    비밀글입니다.

    • IYD |
    • 11.08.06 |
    • 조회 1 |
  • Hybrid PhysX : 6990 + GTX260 [VGA] Hybrid PhysX : 6990 + GTX260 [5] file

    글쓴이: 이대근 (ㄷㄱ)※ 무단전재 및 재배포를 금지합니다. 퍼가실 때에는 원제, 작성자, 출처를 반드시 병기해 주시기 바랍니다 ※ 안녕하세요. 오랜만에 벤치를 작성하게 되었습니다ㅋㅋ 이 블로그 개설 초기에 라데온 4870 + 9800GT를 사용한 하이브리드 피직스 구성 팁을 올렸었는데요,드라이버 버전들이 많이 올라가고 (...

    • IYD |
    • 11.08.05 |
    • 조회 6 |
  • AFR의 비밀 : 크로스파이어 미지원 게임 수동 설정법 [VGA] AFR의 비밀 : 크로스파이어 미지원 게임 수동 설정법 [14] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 크파 유저분들은 가끔 이 문제로 속을 썩으셨을 텐데요...비싼 돈 들여 크파를 구성해 놨더니 정작 갖고 있는 게임이 크파를 지원하지 않는다면?!눈물을 머금고 GPU 하나만 갈구며 게임을 ...

    • IYD |
    • 11.07.10 |
    • 조회 101 |
  • [VGA] Some articles on multi-GPU scaling [6] secret

    비밀글입니다.

    • IYD |
    • 11.06.30 |
    • 조회 0 |