Intel CPU 마이크로 아키텍쳐의 미래.

Source : http://www.parkoz.com/zboard/view.php?id=int_news&no=13181

 

clip_image001
Image size : 320 x 291, Friday May 23, 2008 02:27:47 am, Uploaded by 이동렬

Nehalem 마이크로 아키텍쳐에는, Intel의 향후 CPU의 발전 방향성을 볼수가 있다.

그것은, 프로그램안의 핫 코드, 즉, 자주 실행되는 부분의 병목 현상을 피하고, 보다 깊이 캐쉬, 실행을 고속화할 방향이다. 실제, Nehalem 마이크로 아키텍쳐를 보면, 실질적인 캐쉬인 루프 스트림의 버퍼등이, CPU의 실행 엔진에 의해 가까운 곳에 배치되어 더욱 계층화 된 캐쉬 구조가 되어 있는 것을 알 수 있다.

x86 CPU에 있어서 최대의 걸림돌은 명령 디코더(Instruction Decoder)다.

가변장으로 명령 포맷이 복잡한 x86 명령의 페치로부터 디코드에 있어서, 처리가 어렵고 논리가 복잡하게 된다.그 때문에, 명령 디코더의 transistor 수가 높다.

Intel의 Justin R. Rattner씨 (Senior Fellow, Corporate Technology Group겸CTO, Intel)는 다음과 같이 말하고 있었다.

「(CISC인 x86 명령 세트의) 가변장 명령의 디코더는, 고정장 명령의 RISC 디코더 보다 전력을 많이 소비한다.

Intel이나 AMD의 프로세서 서멀 맵(온도 분포도)을 보면, 칩상의 가장 온도가 높은 부분이 디코더 부분인 것을 알 수 있다. 디코더의 전력 효율에 관해서는, 고정된 길이의 명령 세트 아키텍쳐가 아무래도 유리하게 된다.

여기서 중요한 것은, 프로세서의 퍼포먼스는 평균 소비 전력으로 제약되는 것이 아니라, 피크 온도로 제약되는 것이다. 그 때문에, 뜨거운 디코더가, CPU의 동작 주파수에 사실상의 제약이 된다.

왜냐하면, 그 부분의 교차점 온도가 기정치를 넘지 않게, 줄이지 않으면 안 되기 때문이다」

Intel은, Nehalem에서도, 높은 온도의 원인이 되고 있는 명령 프리디코더&디코더를 더 이상 복잡화 하는 것을 피했다. 전력 효율에 중점을 두기 위해, 효과가 있어도 비용이 비싼 개량은 단념 했다.

1%의 트랜지스터를 더하는 것은 1%이상의 퍼포먼스 향상을 바랄수 있는 경우에 한정하는 것이, Nehalem의 설계 사상.

Core MA에서는, 명령 프리디코더 부분에서도 여러가지 제약을 위해서, 코드 최적화에 몇개의 제약이 있다.

LCP를 피하는, 불필요한 명령장을 길게 하지 않는다는, 제약.  

Intel은, 일본에서 2006년 6월에 행한 「HPC Developer Conference」에서는, 코드 최적화에 대해서, 다음과 같이 설명하고 있었다.

 「Core MA에 맞추어 코드를 최적화 한다면, 그 최적화의 전부는 아니지만, 그 대부분은, 앞으로 2세대의 CPU에 걸쳐 유효하게 된다. 최적화에 대한 투자는, 향후 6년간에 걸쳐 할 것이다」

2세대라고 하는 단어가, 마이크로 아키텍쳐의 교체를 나타 낸다면, Nehalem의 다음인 「Sandy Bridge」까지, 같은 최적화가 필요한 구조를 유지하게 된다. 즉, 프론트엔드의 구조는 2010년 세대의 CPU에서도 인계 되게 된다.

중간 세대의 개량판 마이크로 아키텍쳐도 넣는다면, 최적화는 Nehalem까지의 계승이 된다.

6년간이라는 표현을 생각하면, 전자일 가능성은 높다.

2010년에 등장하는 Sandy Bridge가 인계되는 것은 2년 후인 2012년으로, 컨퍼런스가 열린 2006년의 6년 후가 되기 때문이다.   Core MA의 토대는, Nehalem 뿐만이 아니라 Sandy Bridge에도 계승되게 된다.

clip_image002

Nehalem의 개요

clip_image004
Nehalem 「Bloomfield」의 블럭도

Nehalem에서는, 보틀 넥이 생기는 명령 프리디코드나 디코드를 어떻게 해결 하는 것인가.

Intel은 페치/프리디코드/디코드 에 관련되는 문제에 대한 최선의 해결법의 하나는, 명령어 인출로부터 디코드 까지를 실행하지 않고 끝나도록 하는 것이라고 생각하고 있는 것으로 보인다.

그것은, Nehalem의, uOPs 베이스의 「Loop Stream Detector」.

Core MA로부터 채용된 루프스트림디코더는, 루프를 탐지하면, 루프내의 명령을 최대 18 명령 까지 캐쉬한다. 실제로, 루프의 경우, 프리디코더 아래 명령 큐에 보내진 명령을 플래시 하지 않고 보관 유지하여, 반복 실행한다.

그 때문에, Core MA에서는, 루프내의 명령은 다시 페치&프리디코드 할 필요가 없다.

그에 대하여, Nehalem의 루프스트림디코더는, 명령 디코더의 뒤에 루프스트림디코더가 있어, 루프내의 uOPs를 최대 28 uOPs까지 캐쉬한다. 그 때문에, 명령 디코더까지 바로 보낼수 있다.

Ronak Singhal씨(Principal Engineer, Oregon CPU Architecture, Intel)는, 명령 프리디코드&디코드를 개량하는 것보다, 오히려 루프스트림디코더 등, 별도의 해결책을 강구하는 것이 좋다고 판단했다고 말하고 있다.

clip_image005

clip_image007

Nehalem,Core MA의 페치&디코드…

clip_image008
clip_image009

이 발상은, NetBurst(Pentium 4)의 트레이스 캐쉬의 생각과 기본적으로는 비슷하다.

트레이스 캐쉬도, 명령 디코더의 병목 현상을 피하기 위한 구조였기 때문이다.

그러나, Ronak Singhal씨(Principal Engineer, Oregon CPU Architecture, Intel)는, 다음과 같이 설명한다.

「Nehalem의 루프 디텍터는, 트레이스 캐쉬를 베이스로 한 것은 아니다. 루프 디텍터는 Core MA에 이미 존재 하며, 파이프라인중에서의 그 위치를 위해 효율적인 위치로 움직이는 것은 자연스러운 확장이기 때문이다. 결과적으로는 비슷하지만, 기본 토대는 다르다」

NetBurst에서는, 디코더의 뒤에 L1명령 캐쉬에 상응하는 트레이스 캐쉬를 배치 했다.

그 때문에, 트레이스 캐쉬에 사용 하는 한, 명령 디코드의 필요가 없었다. 명령 디코더의 보틀 넥을, L1명령 캐쉬를 디코더의 뒤에 가져오고, 명령 디코드를 파이프라인으로부터 제외하는 것으로 실현 되었다.

그러나, NetBurst의 트레이스 캐쉬는 매우 고비용으로 비효율적 이었다.

우선, x86 명령을 uOPs 로 분해하는 명령수가 많아져, 명령장도 길어짐과, 캐쉬가 비대화 해 버린다. Prescott에서는, 12 K의 uOPs를 보관하기 위해서 128 KB의 트레이스 캐쉬를 실장하고 있었다. x86 CPU 통상의 L1명령 캐쉬보다 훨씬 크며, NetBurst CPU를 보면, 트레이스 캐쉬가, 다이상에서 큰 면적을 차지하고 있는 것을 알 수 있다.

또, NetBurst의 트레이스 캐쉬는, 분기 예측에 근거하는 예측 트레이스를 캐쉬하고 있었다.

NetBurst에서는, 예측 미스등에서, 캐쉬 미스가 발생하면, 명령 디코드로부터 실행한다. 그런데 , 명령 디코더는 1 way이므로, 캐쉬 미스시에는 1 명령/사이클 머신이 되어 버린다.

clip_image010
캐쉬와 버퍼 계층의 변화

효율이 나쁘고, 캐쉬 미스시의 패널티가 큰, NetBurst의 트레이스 캐쉬는, 동마이크로 아키텍쳐의 약점이었다.

그 때문에, Pentium III로부터 확장된 Pentium M(Banias)에서는, 명령 디코더 전에 L1명령 캐쉬가 배치되었다. 트레이스 캐쉬의 시도는 실패 하고, 한번 더, 기존의 x86 CPU의 스타일로 되돌렸다.

Pentium M로부터 발전한 Core MA에서는, 명령 프리디코더와 명령 디코더의 사이에, 루프 스트림 디텍터의 버퍼를 사이에 두는 아키텍쳐가 되었다.  즉, 명령 프리디코드의 보틀 넥을 피할 수 있는 부분에, 루프에 특화한 캐쉬를 배치했다. 빈번히 사용하는 코드 부분에 대해서는, 보다 CPU의 실행 엔진에 가까운 곳에서 캐쉬하는 형태.

그리고, Nehalem에서는, 루프 스트림을 위한 버퍼가, 명령 디코더의 뒤에 설치 되었다.

x86 명령 큐를 루프 스트림 버퍼로서 사용하는 대신에, uOPs 큐를 버퍼로서 사용하게 되었다. 자주 사용되는 코드 부분(핫코드)의 캐쉬가, CPU의 안쪽으로 이동해 가는 것이 잘 알수 있다.

그러나, NetBurst와는 달리, 디코더 밖의 L1명령 캐쉬는 그대로, 디코더의 안쪽의 uOPs 캐쉬는 매우 작은 그대로 이다.

NetBurst의 트레이스 캐쉬에서는, 1번 밖에 실행하지 않는 코드 부분(콜드 코드)도, uOPs의 캐쉬에 격납 되고 있었다.그에 대하여, Nehalem의 어프로치에서는, 콜드 코드는 디코더의 밖의 L1캐쉬에 있으며, 루프 부분의 핫 코드만이 uOPs로 캐쉬된다. 그 때문에, 트레이스 캐쉬와 비교해 보면 매우 효율적이다.

이 흐름으로부터 논리적으로 예상되는, Intel CPU의 진화의 방향성은 다음과 같이 된다.

명령 디코더 아래에 배치 하는 캐쉬를, 더욱 더 크게 하며, 보다 긴 루프나 실행중의 루프 이외의 핫 코드도 검지하여 격납하도록 한다. 실제의 명령 실행을 베이스로 한 실행 트레이스를 캐쉬 한다. 그러면, 보다 많은 코드에 대해서, CPU의 프론트엔드의 병목을 피할 수 있다.

Nehalem로 보이는 것은, Intel이 Core MA로 자신감을 가져, Core MA를 베이스로한 명료한 방향으로 CPU 마이크로 아키텍쳐의 개발을 진행시키고 있는 것이다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: