벤치리뷰·뉴스·정보/아키텍처·정보분석

[분석정보] IDF 2010 왜 Sandy Bridge는 성능이 높은가?

tware 2010. 9. 17. 21:00

 

모듈화가 매우 높은 Sandy Bridge의 내부 구조

Intel의 차세대 CPU 아키텍처 "Sandy Bridge (샌디 브릿지)"는 기존의 디자인 개념의 연장 성능을 끌어 올린 CPU이다. Intel은 Sandy Bridge의 성능에 매우 자신감을 가지고 있으며, 내년 (2011 년)에는 단번에 PC 시장에 침투시킬 전망이다.

Sandy Bridge의 클라이언트 PC 용 제품은 4 코어와 2 코어 2 버전에서 모두 GPU 코어를 온 칩에 내장한다. Sandy Bridge 4 코어의 경우는 4 개의 CPU 코어와 공유의 LL 캐시 (Last Level Cache), 1 블록의 GPU 코어, DDR3 메모리 컨트롤러, PCI Express, DMI, 디스플레이 인터페이스, 그리고 각 블록을 제어하는​​ 시스템 에이전트를 탑재한다. 공유 LL 캐시는 4 개의 "슬라이스 (Slice)"으로 분류되며, 각 CPU 코어와 함께하고있다. 1 개의 CPU 코어와 1 슬라이스 LL 캐시에서 하나의 CPU와 캐시 블록을 구성하고 있다.

 Sandy Bridge 제품군은 모두 온칩 인터커넥트 링 버스를 채용하고있다. Sandy Bridge 4 코어의 경우는 4 개의 CPU 및 캐시 블록, GPU 코어, 시스템 에이전트 링 버스에 연결되어있다. 링은 합계 6 스톱 것으로 보이며, 4 번 링이 되고있다.

 Sandy Bridge 2 코어의 경우 CPU 코어 및 캐시 블록이 2 개로 줄어들지 만, 링 버스를 사용하는 구조는 같다. 링으로 연결성이 높은 디자인으로 인해, Intel은 CPU 코어 수를 어느 정도 자유롭게 늘릴 수있다. 4 코어와 2 코어 2 버전 외에, 8 코어 버전의 제품군 (Sandy Bridge-EN/EP/EX)도 준비되어있다. 상위 8 코어 제품군은 GPU 코어를 비치하지 않고, 링 버스로 8 개의 CPU 코어와 캐시 블록을 연결하고 있다고 추측된다.

 

 

 

Sandy Bridge 다이

 

 

 

 

정말 멋진 형상이 더해진 Sandy Bridge

Sandy Bridge의 CPU 코어의 기본 아키텍처는 Nehalem (네할렘) 계와 같은 Core

Microarchitecture (Core MA)의 발전계다. 프롬 스크래치(신품)에서 개발 된 아키텍처가 아니다. 그러나, 새로운 명령어 세트 확장 "AVX (Advanced Vector Extensions)"의 구현 등 많은 확장이 이루어지고 있으며, 상당한 성능 향상이 도모되고 있다. 특히 눈에 띄는 것은, AVX의 벡터 연산 성능의 향상뿐만 아니라, 단일 스레드 성능 향상에 주력하고 있다는 점이다.

CPU 코어로 확장 된 포인트는 크게 나누어 4. (1) 프론트 엔드 클러스터에서 uOP 캐시 추가, (2) 실행 엔진 클러스터에서 AVX 장치의 구현 및 재구성 (3) 물리 레지스터 파일 마이그레이션 및 예약 자원의 강화, (4) 메모리 클러스터 에서로드 / 스토어 기능 강화. 특히, 프론트 엔드에 신설 된 uOP 캐시는 단일 스레드 성능 향상에 크게 기여할 것으로 보인다. 실행 클러스터 메모리 클러스터의 강화는 주로 AVX의 벡터 연산의 성능에 효과가있는 것으로 보인다.

 

 

 

 

 

Intel은 이러한 마이크로 아키텍쳐 확장을 2 개로 나누고있다. "멋진"과 "정말 멋진"의 2 단계이다. 멋진 마이크로 아키텍처 확장은 확장에 따라 증가하는 전력 이상의 퍼포먼스 향상을 얻을 수있는 것. 즉, 소비 전력이 10 % 늘어도 10 % 이상 성능이 오르는 형상이다. Intel은 Nehalem 설계시에 이 원칙을 만들고 나쁜 전력 비율의 구조 개혁은 하지 않았다. 결과적으로 Nehalem에서는 전체 전력 당 성능이 1.3 배 이상 증가했다.

반면 정말 멋진 마이크로 아키텍처 확장은 소비 전력을 줄이면서 성능을 높이는 기능이 된다. 전력을 줄이고 성능이 증가하므로 성능 / 전력을 크게 끌어 올린다. Sandy Bridge는 정말 멋진 형상이 더해진 것이 중요하다고 한다.

아래가 현재 알고있는 범위에서 Sandy Bridge의 블록 다이어그램과 Nehalem의 블록 다이어그램이다.

 

 

Nehalem 아키텍처

 

 

 

Sandy Bridge 아키텍처

 

 

파이프 라인 전체에 걸친 아키텍처 확장

 Sandy Bridge CPU 코어의 확장 속에서 정말 멋진 기능은 프런트 엔드 "uOP (마이크로 오퍼레이션) 캐시 (uOP Cache)"이다. 이유는 간단하다. uOP 캐시가 x86 명령을 디코딩하는 전력 및 성능 모두에서 병목 현상을 피할 수 있기 때문이다. 캐시 후단의 실행 엔진이 실행하는 uOPs가 uOP 캐시에 적중하면 uOPs는 캐쉬로부터 읽어진다. 큰 x86 명령어 디코더는 아무것도 할 필요가없고 절전된다 (또는 다른 스레드의 명령을 디코딩 할 수있다).

 

 

 

실행 클러스터는 기존의 128-bit 폭의 SIMD (Single Instruction, Multiple Data) 연산 유닛 인 SSE 유닛 외에 256-bit 폭의 AVX 유닛이 장착됐다. Intel은 명령어 세트를 256-bit 폭으로 확장해도 실행 유닛은 128-bit 폭의 2 사이클 처리량으로 AVX 명령어를 실행할 수 있었다. 사실, SSE에서는 처음에 그러한 구현을 하고 있었다 (128bit 폭의 SSE 시리즈의 경우 최초 하드웨어 구현은 64비트로 두번에 걸쳐서 처리, 이후에 콘로에서 128비트 한번에 처리로 바뀜 (프로그램 상, 레지스터 이용등 소프트웨어측에서 보면 동일하지만, 실제 하드웨어는 2번에 처리냐, 한번에 처리냐의 차이가 발생. 물론 성능에도 차이가 발생). 마찬가지로 256bit의 AVX의 경우도 최초 하드웨어 구현은 128bit를 두번처리로 해결할 수도 있었으나 256bit 한번에 처리로 구현 했다는 얘기. 간혹 명령어만 만들면 된다고 생각하는 분도 계신데, 명령어만 만들면, 하드웨어 처리가 안되죠. 당연히 하드웨어가 있어야 합니다. 이걸 다르게 말하면, DirectX 10,11을 DirectX 9 하드웨어로 돌린다는 얘기랑 같은거죠. DirectX 10,11을 돌리려면 하드웨어가 DirectX 10,11,을 돌릴 수 있어야 돌리죠. 또 이런 확장 명령은 왜 만들까? 당연히 기존 명령보다 빠르게 처리 가능한 명령 형식이니까 만드는거죠. DirctX 10 이상부터 9보다 같은 그래픽이면 더 빠르고, 더 오버헤드가 적다 라고 만들어지는 것과 같은 겁니다. 또 간혹 새로운 명령어와 유닛이 들어오면, 그걸 빼고 성능 체크를 해야 한다는 분도 계신데 (물론 단기적으로 그럴 수 있죠. 지원 소프트가 나와야 하니까), 그 말은 DirectX 10,11,12 하드웨어가 나왔는데, DirectX 9로 테스트 해야만 그게 진짜 성능이다 라고 말하는 것과 동일합니다. 그래픽도 단기적으로는 DirectX 10.11.12 게임이 없으니까 9성능이 한동안의 성능이긴 하죠. 똑같습니다. CPU로만 다르게 비교해서 말하면, i7 CPU가 나왔으면, 2코어나 4코어만 테스트 해야 진짜 성능이다 라고 하는 것과 동일한 것 이구요. 한동안 8스레드(8코어) 지원 소프트가 없죠. 이것도 시간이 조금 지나야 지원 소프트가 보편화 될테니까요. 기존의 X86,X87 명령으로 동일한 연산을 32비트 명령 4번 처리해아 할 것을 SSE 시리즈는 1명령으로 (콘로 이전은 명령은 1명령인데, 하드웨어는 2번에  걸쳐서 처리), AVX는 8개를 1명령으로 처리 가능 합니다. 그러니까 엄청나게 빠르겠죠. 인코딩 디코딩, 각종 게임기 에뮬레이터, 그래픽 소프트웨어, 게임 등에서 사용.). 그러나, AVX는 처음부터 256-bit 폭의 풀 스피드를 낼 실행 유닛을 구현했다. 이를 위해 Intel은 교묘하게 기존의 실행 유닛과 데이터 패스를 이용하고 있다.

 

 

 

또한 AVX의 구현에 따라, Intel은 실행 엔진 클러스터 명령 스케줄링 자원도 대폭 확장했다. Sandy Bridge도 아웃 오브 오더 형의 실행 엔진에서 많은 명령어를 병렬로 정렬 실행할 수있다. Sandy Bridge는 더 많은 명령을 정렬하고 더 많은 스토어와 로드 버퍼가있다. 즉, 엔진 성능을 더 낼 수 있게 되었다. 또한 레지스터 파일을 물리 레지스터 파일에 리네이밍하는 방식으로 전환하는 것으로, 데이터의 이동을 최소화하여 전력 감소와 성능 향상을 도모했다.

 AVX에서 SIMD 유닛의 연산 능력이 2 배가되면 2 배의 데이터가 필요하다. 따라서 Intel은 메모리 클러스터에서 메모리를 처리하는 기능을 높였다. 기존의 Nehalem은 로드와 스토어의 파이프 라인이 분리되어 있었다. 그러나, Sandy Bridge는로드 / 스토어 모두 지원 장치로, L1 데이터 캐시 포트를 확장하여 최대 2 개의 16bytes로드와 1 개의 16bytes 스토어를 병렬로 행할 수있게 했다. 부하가 많은 실행 엔진의 실제 사용 부하가 훨씬 많기 때문이다.

 이러한 개혁의 결과, Sandy Bridge는 정수 연산,SIMD 부동 소수점 연산에서 모두 성능이 높은 CPU가 되었다고 한다.

 

 

 

 

uOPs 캐시의 효율 업

 Sandy Bridge CPU 코어의 프론트 엔드 클러스터, 즉, 명령을 메모리에서 가지고 와서 실행할 수 있도록 하는 데 걸리는 부분은 매우 복잡하고 강력하다. 이것은 명령어 세트가 복잡한 x86 CPU에서는, 명령의 실행 자체보다 명령 페치 (캡처) 및 디코딩이 병목 현상이 쉽기 때문이다. Intel은 Core MA에서 이 부분을 매우 강화했지만, Nehalem과 Sandy Bridge도 계속 강화되고 있습니다. 이미 언급했듯이, 그 중에서도 uOP 캐시 (uOP Cache)에서 전력 소비를 줄이면서 성능을 업그레이드 할 수 있었다고 한다.

 대부분의 x86 계 CPU는 x86 명령을 CPU 내부 명령 "uOP"로 디코딩하고 실행한다. x86 CPU는 x86 명령에서 uOP 로의 디코딩이 매우 부담이며, CPU 중에서도 다이 면적을 가지고 전력을 소비하는 근원이 되고있다. 따라서 x86 명령어 디코딩 부분을 건너 뛸 수 있다면 성능이 향상되고, 전력 소비도 줄어든다. Intel은 이 원칙에 따라, Sandy Bridge의 프론트 엔드를 크게 향상시켰다. 즉, 디코딩 된 uOPs을 캐시하여 올림으로써 디코딩 하지 않으려 했다.

 

 

 

 

 

 

 

Sandy Bridge는 1.5K 분의 uOPs를 유지할 수 있도록 uOP 캐시를 디코더 후단에 비치하고 있다. 이것은 1.5KB 분 명령이 아니라, 약 1,500 개의 분 uOPs를 저장한다. Intel은 이 1.5K 분의 uOPs 만 유지해도 uOP 캐시에서 80 %의 캐시 적중률을 달성 할 수 있다고 설명하고 있다. 명령 디코더는 20 % 밖에 사용하지 않는다. 여기서 포인트, 80 %의 확률로 디코더를 생략 가능하면 CPU 성능이 크게 오를 것이다. 특히 성능 향상이 어려운 정수 연산 향상을 기대할 수있는 점이 크다. 그러나 Intel은 아직 uOP 캐시에서 80 %의 근거가되는 상세한 자료는 밝히고 있지 않다. 이정도라면, 크기에 비해 효율이 좋은 캐쉬가된다.

또한 이 uOP 캐시는 단순한 캐시가 아닌,명령 흐름 속에서 분기를 넘어 명령 흐름을 연결시킬 수있다. 즉, 실제 실행되는 명령 (분기 명령 포함) 추적 (경로)에 따라 캐시에 uOP를 저장할 수있는 트레이스 캐시적인 구조로 되어 있다. (uOP 캐쉬 부분이 추적 캐쉬라고 되어 있으나, 트레이스 캐쉬가 아닙니다. 이 부분은 다음 기사에 정정 됩니다.) 캐시 라인을 읽을 때 분기를 걸터 앉아 실행 추적 uOP가 페치되게, 원리 적으로는 효율이 오를 것이다 (조건 분기의 결과가 다르면 효율이 떨어진다). 원래, uOP 캐시되면 일반 명령어 캐시와 같이 캐시 라인마다 메모리에 정적 명령 시퀀스를 캐시하는 것은 아니다. 추정되는 Sandy Bridge의 프론트 엔드의 구조는 다음과 같이 되어있다.

 

 

 

 

 

Intel에 있어서 3 번째 uOPs 캐시

 Intel이 uOPs 캐시 시도는 이제 3 번째다. 먼저 NetBurst (Pentium 4) 아키텍처 12K의 uOPs를 저장하는 트레이스 캐쉬를 L1 명령 캐시 대신 채용. 다음 Nehalem에 28 개의 uOPs를 저장하는 작은 루프 스트림 디텍터 버퍼 (Loop Stream Detector Buffer)를 마련했다. 실제로 캐시가 아닌 uOPs 대기열을 잘 이용하는 구조이지만, uOPs를 재사용한다는 점에서 목적은 같다. 덧붙여서,이 칼럼에서는 Nehalem을 설명하며 다음 마이크로 아키텍처는 큰 uOP 캐시를 탑재 할 것으로 예상했지만, 그대로 되었다. 그러나 이러한 기대는, Intel의 설계 개념에서 보면 당연한 결과 다. 덧붙여서, AMD의 Bulldozer (불도저)에서도 비슷한 캐시를 탑재한다는 소문이 있었지만, 실제로 탑재 한 것은 Intel의 것 이었다.  

 

 

캐시 계층의 변화

(이거 좀 그림의 가장 왼쪽 P6/merom 이 오기가 있는거 같네요. P6/Banias 여야 되는거 같은데... Merom은 Core MA와 같은 얘기죠. 저런 오기는 종종 생기죠. 저도 가끔 저러니까...)

 

또한 캐시 향상에 따라, Intel은 Sandy Bridge의 분기 예측도 일신했다고 설명하고있다. 그러나 자세한 내용은 대부분 공개하지 않고, 분기 타겟의 버퍼가 2 배가 된 것이나, 히스토리 버퍼가 보다 효율적으로 된 것 등만 밝혀져있다. 덧붙여서, Intel은 Nehalem에서는 분기 예측 유닛을 2 계층했다. 1 단은 작은 코드 풋 프린트의 예측을 신속하게 수행, 2 단은 풋 프린트 예측을 행하는 구조로 되어 있었다.

 

 

 

 

이렇게 보면, Intel은 여전히​​ 프론트 엔드 부분의 개량에 힘을 쏟고 있는 것으로 안다. Pentium M (Banias : 베니어스)는 Micro-Fusion에서 2 개의 uOPs를 1 개로 통합하면서 내부 파이프 라인이 동작하도록 했다. Core MA에서는 매크로 퓨전(Macro-Fusion)을 도입하여 특정 2 명령어를 1 명령어로 융합시킴 으로써 명령어 인출 대역폭과 uOPs 대역을 실질적으로 늘렸다. Nehalem에서는 uOPs 기반 루프 디텍터에서 루프 때 디코딩 단계를 건너 뛸 수 있도록 했다.

 이 흐름을 보는 한, Intel은 앞으로도 이 부분에 개선을 더해 가게 될 것이다. 명령어 인출과 디코딩이 무겁다는 x86 계열 명령어가 복잡하기 때문이다. Intel의 강함은 x86 명령에 있지만, 그것을 위한 부담이 CPU의 프론트 엔드를 무겁게 짓누르고 있다. Intel은 강함을 유지하기 위해 프런트 엔드 개선에 지속적으로 힘을 쏟고있다. 덧붙여서, Intel은 몇년전에 이 노선의 최종 형태가 될 마이크로 아키텍처 연구 "PARROT (Power AwaReness thRough selective dynamically Optimized Traces)"을 발표 했었다. PARROT의 복잡한 구조로 인해 정착 여부는 모르지만, Intel에서 아직 프론트 엔드 개혁의 꼬리표가 있는 것은 확실하다.

 

 

 

RARROT 파이프 라인 개념

 

 

 

[분석정보] 2012년 vPro는 클라이언트 관리의 결정적 수단이 되는가? 1/2부

 

 

[분석정보] 2012년 vPro는 클라이언트 관리의 결정적 수단이 되는가? 2/2부

 


[분석정보] 왜 인텔은 샌디브릿지에 AVX를 구현하는가?

 

 

[아키텍처] 전력 효율성에 초점을 둔 인텔 연구개발 (PARROT)

 

[아키텍처] 트릭을 거듭한 Sandy Bridge 마이크로 아키텍처

 

[벤치리뷰] 인텔 샌디브릿지 공개 코어 i7 2600k, i5 2500k, i5 2400, i3 2100 CPUs

 

[벤치리뷰] 샌디브릿지 프리뷰