AVX의 구현은 2 개의 유닛을 확장하고 결합
Sandy Bridge의 CPU 코어는 새로운 AVX (Advanced Vector Extensions)의 실행 엔진이 구현 되었다. AVX는 256-bit 폭 (32-bit 단 정밀도라면 8way)의 SIMD (Single Instruction, Multiple Data) 명령어를 포함한다. 종전의 SSE의 128-bit 폭의 SIMD 엔진의 2 배의 벡터장이 된다. Intel에서Sandy Bridge의 아키텍트를 맡은 Bob Valentine 씨 (Senior Principal Engineer)는 "같은 양의 명령 흐름과 캐시 대역폭에서 2 배의 연산이 있다.보다 효율적인 명령 스타일"이라고 벡터 길이를 2배로의 이점을 강조한다.
또한 AVX는 마스크로드 / 스토어 등의 구현에 벡터를 더 취급하기 쉬워 졌다고 지적한다. SIMD 데이터 슬롯 단위로 바꾸기위한 컨트롤 흐름 제어를 가능하게 한다.
그러나 256-bit SIMD 하드웨어 구현하는 것은 쉽지 않다. 실행 엔진을 기존의 SSE의 128-bit 폭의 SIMD 엔진의 2 배 넓이의 실행 장치 및 데이터 경로를 구현해야 하기 때문이다. Valentine 씨에 의하면, Sandy Bridge의 개발팀은 그대로 구현하면 배의 유닛과 배의 데이터 경로가 필요한 확장을 더욱 간편하게 지니는 트릭을 발견했다. 그것은 기존의 실행 유닛과 데이터 경로를 확장 AVX에 대응시켜 버리는 것이었다.
현재 Nehalem (네할렘)은 SIMD 실행 엔진이 2스택 존재한다. 부동 소수점 (FP) 연산 스택과 정수 연산 스택이다. "벡터 부동 소수점 벡터 정수 병렬 하드웨어 스택이 있었다. 이러한 하드웨어는 동일한 자원을 사용하지 않는 분리된 실행 하드웨어였다. 그래서 이 두 128-bit 하드웨어를 동시에 사용하면 256-bit 하드웨어가 된다고 생각해낸 영리한 엔지니어가 있었다 "(Valentine 씨).
아래의 그림에 이 Nehalem의 SIMD 엔진 군, 아래가 Sandy Bridge의 SIMD 엔진 군이다. 각각 3개의 명령 발행 포트 uOPs (마이크로 오퍼레이션 : 내부 명령어)가 발행된다. 데이터 캡처 스케줄러가 피연산자의 이해와 목적지 레지스터에 기록 관리한다. Nehalem에서는 부동 소수점 (FP) 스택과 정수 스택 명령 발행 포트는 공유하지만, 실행 엔진 자체는 독립적.
AVX의 구현
따라서 Intel은 Sandy Bridge에서는 스택을 그림의 아래처럼 재구성했다. AVX의 256-bit SIMD를 높고 낮은 2 개의 128-bit SIMD로 나누었다. "AVX 256-bit 하이 측의 절반은 기존의 부동 소수점 (FP) 스택을, AVX 256-bit 로우 측의 반은 레거시 정수 스택을 사용한다. 이에 따라 AVX 256-bit의 가산과 곱셈의 두 를 각각 실행한다 "(Valentine 씨).
기존의 128-bit SIMD 하드웨어를 확장하여 256-bit SIMD를 실현했기 때문에 완전히 새로운 엔진은 AVX 256-bit의 셔플과 파뮤트 엔진만으로 끝난다고 한다.
실제 레지스터 기반으로 마이그레이션 효율을 올리는 AVX 구현의 또 하나의 문제는 SIMD 레지스터가 128-bit 폭에서 256-bit 폭에 넓어졌기 때문에, 데이터 이동의 낭비가 눈에 띄게 된 것이라고 한다. AVX의 YMM 레지스터는 기존의 SSE XMM 레지스터의 2 배 크기가 된다.
일반 Out-of-Order 실행 엔진은 명령 실행의 결과를 리오더버퍼 (ROB)에 버퍼링된다. 결과를 피연산자 사용 명령이 있는 경우는 리오더버퍼 (ROB)를 읽는 스케줄러에 복사한다. 마지막으로, 명령이 커밋(완료)하면 결과는 리타이어먼트를 위한 레지스터에 기록된다. 이 구조에서는 결과 데이터를 여러번 이동시킬 필요가 있었다.
그러나, AVX에서 레지스터 폭이 넓어 데이터 양이 증가하면 데이터 이동에 의해 소모되는 전력이 만만치 않다. 그 낭비를 피할 수 Sandy Bridge에서는 물리 레지스터 파일 (Physical Register File: PRF)를 구현 했다고 한다. 데이터는 물리적 레지스터 파일에 저장된 개별 IA의 레지스터는 물리 레지스터로 이름이된다. 결과를 피연산자에 사용하려면 매핑 된 물리적 레지스터에서 직접 데이터를 가져 오기. Intel의 Valentine 씨는이 구조를 다음과 같이 비유했다.
"현재 스케줄러는 피연산자를 실행 장치에 보내 연산 등의 결과를 캡처한다. 캡처 된 데이터는 (리오더 버퍼에) 저장 한 후, 센트럴 플레이스에 되 돌린다. 예를 들어, 명령의 실행 결과 기다리는 덩어리 사람 (명령)이 있다고하자. 당신 (리 오더 버퍼)는 결과를 캡처하고 그 결과를 기다리고 있는 사람 (명령)도 사용할 수 있도록 한다. 그 경우, 당신 (리 오더 버퍼)는 각각 (명령)에 개별적으로 결과를 쓴 종이 (데이터)를 일일이 통과해야한다. 종이 (결과)를 전달하면 그들 (명령)은 그것을 가지고 (리자 베이션 스테이션로) 이는 그다지 효율적인 방법은 아니다.
Sandy Bridge는 대신 결과를 1 개소 (물리 레지스터 파일)에두기로 했다. 명령을 실행하면 데이터 스케줄러 물리 레지스터 파일에 기록된다. 또 다시 리타이어먼트를 위해 쓰이지 아니한다. 1 복사 데이터가 1 개소에 1 회 저장소 될 뿐이다.
비유하면, 결과가 나오면 누구 (명령)라도 일정한 장소 (물리적 레지스터)에 결과가 있으면 알게된다. 그들 (명령)은 필요하다면 언제든지 그 결과를 참조 할 수있다. 이것이 우리가 실제로 달성 한 것이다. "
Intel에 따르면, 실제 레지스터 파일의 마이그레이션에 의해, AVX 구현을 용이하게 한다. 2 배 넓은 벡터 데이터를 처리하기 위해서는 전력소비를 줄일 물리 레지스터와 같은 구조가 필요했다고 한다. Out-of-Order 실행중인 임시 결과는 기존은 리 오더 버퍼 (ROB)의 버퍼에 저장되어 있던 것이 실제 레지스터에 저장되게되었다. 그 결과, 리 오더 버퍼 (ROB)에 데이터를 저장하는 버퍼가 없으며 실질적으로 명령의 커밋 (명령 종료) 관리만을 지휘하게 된 것으로 보인다.
Nehalem의 그림은 리 오더 버퍼 (ROB)에 큰 버퍼가 있고, 스케줄러와 리 오더 버퍼 사이를 데이터가 이동한다. 그러나, Sandy Bridge는 리 오더 버퍼 (ROB) 측에 버퍼가 없으므로 데이터의 이동도 없어졌다. Nehalem의 데이터 캡처 스케줄러는 Sandy Bridge에서는 물리 레지스터 파일 (Physical Register File)로 대체하고있다.
Sandy Bridge의 블록 다이어그램
Out-of-Order 실행 창을 크게 확대
Sandy Bridge는 Out-of-Order 실행 엔진의 리소스도 크게 넓히고있다. Sandy Bridge의 리 오더 버퍼 (ROB) 항목은 168으로 이것은 Nehalem 128 항목에 비해 30 % 이상 많다. Nehalem은 Core MA (Merom : 메롬)의 96 항목보다 ROB이 33 % 컸기 때문에 아키텍처 세대마다 30 % 씩 증가하고 있는 셈이다. 리져베이션 스테이션 (RS)의 항목도 Sandy Bridge는 54에서, Nehalem의 36 ~ 50%, Merom의 32에서 68% 나 늘었다.
명령 발행은 ROB과 리져베이션 스테이션 (RS)의 항목에 여유가 있었을 때에 이루어 지므로, ROB 및 RS 항목이 늘어 나면, 스케줄링 할 명령 수가 증가하게된다. 더 많은 명령을 예약 할 수 있으면, 병렬 실행 할 수있는 기회가 더 늘어난다. 이 밖에 Sandy Bridge는 로드 / 스토어 버퍼도 깊어지고 있다.
"더 버퍼를 가지면 더(일정)창을 넓게 할 수있다.하지만 더 많은 스토리지에 더 많은 데이터 이동은 전력의 증대를 의미한다. 도전, 어떻게 전력을 억제하면서, 모든 버퍼를 늘리거나하는 점에있다 "(Valentine 씨).
여기에서도 해결 방법은 물리 레지스터 파일 기반 전환이었다고한다. 물리 레지스터 파일로 대체함 으로써, 데이터 이동을 줄이고 낭비를 생략 한 것으로, 전체 버퍼의 증가가 가능하게 되었다고 한다.
덧붙여서 이뿐만 아니라 물리 레지스터 파일을 채용 한 AMD의 차세대 아키텍처 "Bulldozer (불도저)"도, 각 코어 당 128 항목 (모듈 전체 256 항목)과 리 오더 버퍼 (ROB)를 확장하고있다. 물리 레지스터는 AMD의 저가형 & 저전력의 "Bobcat (밥캣)"에서도 채용하고, 최신 CPU의 소비 전력 감소의 트랜드가 되고 있는 것 같다.
로드 / 스토어 유닛을 128-bit x2로드로 확장
AVX에서 Intel은 벡터 데이터 연산 폭을 128-bit에서 256-bit로 확장했다. 따라서 Intel은 2 배의 데이터를 실행 엔진에 피드 하지 않으면 안되었다. Nehalem 세대까지는 메모리 작업 파이프 라인은 3 개로 1 개가 로드, 2 개가 스토어 이중 하나는 스토어 어드레스 다른 하나는 스토어 데이터가 있었다. L1 데이터 캐시 액세스 대역폭은 32bytes / 사이클 이었다.
Intel은 Sandy Bridge는 로드가 더 중요한 것으로,로드 대역폭을 2 배로하기로했다. 로드가 충분히 공급하지 못하면 명령 실행을 중지하기 때문이다. Valentine 씨는 기존 byte / Flop 비율을 유지 하려면,로드를 2 배로 해야 한다고 설명한다.
로드 대역폭을 2 배로하기 위해 Intel은 실행 유닛에서 사용한 것과 어느 정도 유사한 접근을 채택했다. 기존의 로드 장치 및 스토어 어드레스를 각각 로드/스토어 모두 지원 파이프로 전환했다. 또한 스토어포트와 로드포트를 각각 양방향 포트로 전환했다.
그 결과, Sandy Bridge는 기존의 1 개의 128-bit로드에서 2 개의 128-bit를 로드해 로드 대역폭은 2 배가되었다. 총 L1 데이터 캐시 대역폭은 로드가 128-bit (16-byte)x2 ,스토어가 128-bit(16-byte) x1에서 48-byte (384-bit)가 되었다.
덧붙여서, AMD의 Bulldozer도 각 정수 코어 2 개씩 로드 / 스토어 모두 지원 주소 생성기를 갖춘다. 또한 각 정수 코어마다 1 사이클에 2 개의 128-bit (16-byte)로드 및 1 개의 128-bit 저장소가 가능 해지고 있다. AMD의 Bulldozer는 2 코어를 융합시킨 CPU 모듈의 FAM 유닛의 최대 처리량은 단정 16 운영 / 사이클. Sandy Bridge는 AVX의 연산 처리 속도는 1 코어 당 단정 16 운영 / 사이클. 따라서 단순 계산으로 Bulldozer가, bytes / Flop 비율은 높아진다.
프론트 엔드에서는 분기 예측의 효율화를 도모
실행 엔진 메모리 클러스터의 확장뿐만 아니라, Intel은 프런트 엔드, 즉 명령을 캡처 디코딩하는 부분도 강화하고 있다. 이전 기사 프런트 엔드 부분에 실수가 있었다. 내부 명령 uOPs 캐시 uOP 캐시 구조는 추적 단위가 아닌 일반 명령 캐시 형이다. 버퍼링하여 분기 경로의 결합을 가능하게 한다고 한다.
그러나 uOP 한 단계에서 명령 수와 명령 길이는 바뀌어 버리기 때문에, 캐시를 어떻게 관리하고 있는지 모르겠다. 단순히 캐시 라인 단위로 관리 할 수 없기 때문이다. 어쨌든, 분기를 어떻게 교묘하게 처리 하는가가 캐시의 관건이 될 것은 확실하다. Intel의 Justin R. Rattner (저스틴 · R · 래트너) 씨 (Intel Senior Fellow, Vice President, Director (Corporate Technology Group)는 다음과 같이 설명한다.
"Pentium 4의 추적 캐시는 실망을 불렀다. 그러나 분기를 잘 연결하는 것 자체는 나쁜 생각이 아니다. 성능 향상을 위해 (Sandy Bridge 개발 팀은) 어느정도 비슷한 접근을 채택하고 있다. "
또한 프런트 엔드의 분기 예측에 Sandy Bridge는 예측 압축 기법을 사용한다. 더 긴 기록, 더 긴 메모리의 기록을 하기 위하여 부분적으로 압축 방법을 사용하는 것 같다. 예를 들어, 분기의 대부분은 단순하기 때문에 2-1 bit 경우에 따라서는 1-bit 태그로 끝나고 마는 경우가 있다고 한다. 또한 분기 대상은 GB 급 메모리 공간을 건너 이동할가 나는 경우도 적지 않다. 대부분의 분기는 더 작은 범위에서 발생하기 때문에, 거기서도 압축이 가능하다고 한다.
Intel의 Valentine 씨는 이러한 CPU 마이크로 아키텍처의 확장 결과, Sandy Bridge는 새로운 애플리케이션뿐만 아니라 기존의 응용 프로그램도 빨라질 것을 강조했다. 기존의 레거시 응용 프로그램의 성능을 향상 유지해야 할 것은 소프트웨어 유산에 의존된(엄청난 수의 x86 소트트웨어들이 장점이자) Intel을 덮치는 속박이다. 다른 CPU 업체들은 이 속박이, Intel CPU의 진도를 감속 요인이되고 있다고 지적한다. 그러나, Intel의 Sandy Bridge는 그 속박에서 벡터와 스칼라 스레드 성능의 균형을 잡고, 어떤 요소도 향상 시킨다는 방향으로 향하고 있는 것 같다.
[아키텍처] 왜 Sandy Bridge는 성능이 높은가?
[아키텍처] 정수 연산 성능을 희생해서 효율성을 거둔 AMD의 "Bulldozer"
[벤치리뷰] 인텔 샌디브릿지 공개 코어 i7 2600k, i5 2500k, i5 2400, i3 2100 CPUs
[분석정보] 왜 인텔은 샌디브릿지에 AVX를 구현하는가?
[분석정보] 2012년 vPro는 클라이언트 관리의 결정적 수단이 되는가? 1/2부
[분석정보] 2012년 vPro는 클라이언트 관리의 결정적 수단이 되는가? 2/2부
'벤치리뷰·뉴스·정보 > 아키텍처·정보분석' 카테고리의 다른 글
[분석정보] CPU와 메모리의 속도 차이를 해소하는 캐시의 기초지식 (0) | 2010.10.25 |
---|---|
[분석정보] AMD가 확장판 K10 코어 기반의 APU Llano 를 첫 공개 (0) | 2010.10.21 |
[분석정보] x86을 고속화하는 조커기술 명령변환 구조 (0) | 2010.10.04 |
[분석정보] 명령의 실행 순서를 바꿔 고속화 하는 아웃 오브 오더 (0) | 2010.09.27 |
[분석정보] 슈퍼 스칼라에 의한 고속화와 x86의 문제점은 (0) | 2010.09.20 |
[분석정보] IDF 2010 왜 Sandy Bridge는 성능이 높은가? (0) | 2010.09.17 |
[분석정보] Intel 래트너 CTO에게 듣는 Atom 탄생 비화 (0) | 2010.09.16 |
[분석정보] CPU 고속화의 기본 수단 파이프라인 처리의 기본 2/2 (0) | 2010.09.13 |