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

[분석정보] 슈퍼 스칼라에 의한 고속화와 x86의 문제점은

tware 2010. 9. 20. 20:00

 

슈퍼 스칼라 기본은

 슈퍼 스칼라라는 어원은 원래는 스칼라와 벡터라 불리는 두 가지 명령의 처리 방식에 기인한다. 스칼라 라고 하는 것은, 한마디로 "보통" CPU 데이터 방식으로 x86 명령의 대부분이 이에 해당한다. 굳이 분류하면 'SISD "(Single Instruction Single Data)에 해당하는 것으로, 원칙적으로 하나의 명령으로 하나의 데이터를 조작하는 것이다 (2 개 라든지 세개 등의 경우도 가끔 있지만) .

 이에 맞서는 개념이 벡터 형식으로 가까운 예로 말하면, MMX에서 이어지는 "SIMD"(Single Instruction Multi Data)로 분류되는 것이 그것에 해당한다. 이것은 하나의 명령으로 복수의 데이터를 취급 하는 것을 가리킨다 (MMX조차 최대 동시에 8 개의 데이터끼리의 연산에서 16 개의 데이터를 처리한다.).

 그러면 슈퍼 스칼라는? 이냐고 하면, 스칼라의 흐름을 계승하면서, 동시에 여러 명령을 수행 할 수 있게 함으로써 결과적으로 복수의 데이터도 동시에 취급 할 수 있게 된다는 것이다.


 전형적인 수퍼 스칼라를 갖는 CPU 파이프 라인은 [그림 1] 에 나타낸 바와 같은 것이된다. 여기에 3 명령 동시 실행의 케이스이다 (번잡하게되기 때문에 래치 등은 생략했다.) 기본적으로 실행 유닛만 여럿 되는데 (이 경우라면 3 명령어 분), 다른 유닛은 하나이다. 하지만 예를 들어 Fetch와 Decode는 당연히 3 명령어 분을 한번에 처리하는 형태가 되고, Data Fetch도 필요하다면 여러 데이터 가져오기를 함께 할 필요가 있다. Writeback도 3 명령 분의 결과를 다시 쓰게 하므로 상당히 복잡하게 되지만, 그래도 같은 것을 3개 준비하는 것보다 적은 회로 규모에 맞다.

 

[그림 1] 전형적인 슈퍼 스칼라 파이프 라인

 


 이러한 수퍼 스칼라가 이상적으로 움직이는 경우 그림 1 아래처럼 1 사이클 당 3 명령어의 처리가 가능하게 된다. 이것은 파이프 라인 단수를 겹쳐 (파이프 라인을 길게해서, 예를들면 노스우드가 20단계, 클럭을 더욱 올릴 수 있게 만든 프레스컷은 31단계. 파이프 라인 수가 많다고 하면 동시 명령 실행을 늘렸다는 것이고, 파이프 라인을 길게 또는 깊게라는 표현은 클럭을 올린다는 뜻 입니다. 여기서는 단수를 늘렸다고 했는데, 주파수가 나오면 길게(여러 단계를 거치는) 만들었다는 얘기죠. 아래와 같은 문제를 극복하기 위해서 프레스컷은 프리페치 & 분기예측 개선, 캐시량 증가를 동시에 진행했습니다. 그래야 동클럭에서도 노스우드에 비해서 기존 소프트의 성능이 떨어지지 않으니까요. 파이프 라인이 길어졌다고 해도, 이상적인 실행이라면 첫번째 명령이 들어가서 처리가 끝나기 까지만 몇클럭 더 느릴뿐, 뒤에 줄줄이 명령 처리가 계속 되기 때문에 성능상 차이는 사실상 없는데 (클럭을 올린 것의 효과가 더욱 큼), 문제는 실제로는 이렇게 안된다는 것이죠. 분기예측에 실해하면, 20단계 노스우드와 31단계 프레스컷의 페널티가 다르죠. 그러니까 프레스컷에서 분기예측,프리페치 개선 캐시량 증가를 시킨 겁니다.) 동작 주파수를 올리는 것보다 훨씬 효율적으로 처리 할 수​​ 있게 된다. 파이프 라인 단수가 적어 작동하면 파이프 라인 해저드의 영향도 적다. 또한 동작 주파수를 낮추게 되면, 상대적으로 파이프 라인 스톨의 영향도 줄어든다. 메모리 및 캐시 별 액세스 시간은 일정하지만, 동작 주파수가 내려 가면 상대적으로 대기 사이클 수를 감소할 수 있기 때문이다. 이러한 이점은 크다.


슈퍼 스칼라 앞을 가로막는 명령어 종속성 벽

 물론 실제로는 이런 식으로 잘되지 않는다. 슈퍼 스칼라에는 "명령의 종속성 '이라는 벽이 가로막고 있기 때문이다. 예를 들어, 다음과 같은 3 개의 명령어가 있다고 하자.

[명령 1] R3 = R1 + R2
[명령 2] R6 = R4 + R5
[명령 3] R7 = R3 + R6


 명령 1과 명령 2는 동시에 실행할 수 있다. 라는 것은 [명령 1]은 레지스터 1 ~ 3 (R1 ~ R3) [명령 2]는 레지스터 4-6 (R4 ~ R6)를 사용하고 있기 때문에 동시에 실행해도 문제가 없기 때문이다. 그런데 [명령 3]이 명령 1과 명령 2의 결과를 이용하여 계산된다. 따라서 [명령 3]은 [명령 1]과 [명령 2]가 완료 될 때까지 실행할 수 없다.

 [명령 3]이 수행 할 첫 번째 두 명령의 Writeback를 완료하고 그 결과를 Data Fetch 할 수 있게 이후이고 따라서 3주기 지연후 파이프 라인에 투입 할 필요가 있다. 즉, 다음 [그림 2] 와 같이 이 경우라면 7 명령 분의 파이프 라인이 꼬박 비어 버리는 것으로,이 상태로는 전혀 성능 향상으로 연결되지 않는걸 알게 된다.(슈퍼 스칼라를 사용하지 않는 단순한 파이프 라인과 같은 성능이 되어 버리는).

 

 

[그림2] 명령어 3의 대기에 의해 파이프 라인 공백

 

 

x86의 문제를 해소하는 명령의 정렬 및 레지스터 리네이밍

 이 문제는 원래 x86 명령이 슈퍼 스칼라을 전제로 한 같은 명령어 세트가 아닌것에 따른 것이다. 슈퍼 스칼라의 경우 자주 명령어를 정렬하여 가능한 동시에 여러 개의 명령을 실행할 수 있도록 하는 것이 필요하게 되기 때문이다. 따라서 본격적인 슈퍼 스칼라의 경우 실행에 들어가기 전에 스케줄러가 설치되고, 여기서 명령의 정렬을 행한다.

 

 

[그림 3] Decode 다음에 스케줄러를 구현한 CPU의 스테이지 구성


 명령어의 정렬이란 무엇인가? 라고 하면, 예를 들어 다음과 같은 명령이 줄선다고 하자. 이것을 기존의 파이프 라인에서 실행하면 [그림 4] 와 같이된다.

명령 1 R1 = Data1
명령 2 R2 = Data2
명령 3 R3 = R1 + R2
명령 4 R4 = Data3
명령 5 R5 = Data4
명령 6 R6 = R4 + R5

 

 

[그림 4] 정렬을  않고 실행할때 명령 처리 흐름


 그런데 명령을 다음과 같이 순서를 바꾸면 명령 1 ~ 4 까지 한번에 실행할 수 있기 때문에 [명령 5]의 시작 타이밍은 함께 하지만 [명령 6]의 시작을 1 사이클 빨리 된다. ( 그림 5 ).

명령 1 R1 = Data1
명령 2 R2 = Data2
명령 3 R4 = Data3
명령 4 R5 = Data4
명령 5 R3 = R1 + R2
명령 6 R6 = R4 + R5

 

 

[그림 5] 정렬 된 명령 처리 흐름


 이 "명령어 정렬"을 행하는 것이, [그림 3] 에서 추가 된 스케줄러의 처리이다. 가능한 동시에 여러 개의 명령을 실행할 수 있도록 잘 정렬하여 명령어 실행 효율을 높이려는 수법이다. 이에 관련되는 기술이 "레지스터 리 네이밍"이다. 예를 들어, 명령이 다음과 같은 경우 정렬 할 수 없다.

명령 1 R1 = Data1
명령 2 R2 = Data2
명령 3 R3 = R1 + R2
명령 4 R1 = Data3
명령 5 R2 = Data4
명령 6 R4 = R1 + R2


 이유는 R1, R2는 레지스터를 재사용하는 것에 기인하는 것이지만, 사실 x86의 경우 이러한 문제가 발생하는 일이 많다. x86에서는 8 개의 범용 레지스터가 유효한 것으로되어 있지만 실제로는 매우 제약이 많기 때문에 실제로 사용할 수 있는 것은 3개 정도가 되고, 이것으로 어떻게든 변통하는 경우가 많다 ※ 1 .

※ 1 이것을 충당하기 위해 스택이라는 데이터의 임시 저장소 구조를 많이 사용하고, 그것은 또한 성능 저하의 요인이되지만 또 다른 기회에 설명한다.

 그래서 내부에 많은 범용 레지스터를 프로그램에서 보이지 않는 형태로 준비해 두고이를 적시 다시 사용한다는 것이 레지스터 리 네이밍이다. 위 예의 경우, 다음과 같이 내부에서 살짝 고쳐 써 버린다. 이제 또 레지스터의 사용 돌리기에 제약을받지 않을 것이다. (현대의 CPU에는 레지스터 리 네이밍을 위해 물리 레지스터가 준비되어 있습니다.)

명령 1 R101 = Data1
명령 2 R102 = Data2
명령 3 R3 = R101 + R102
명령 4 R103 = Data3
명령 5 R104 = Data4
명령 6 R4 = R103 + R104

 

 그러나 여기까지해도 첫 번째 문제인 "종속성 해소"그렇게 쉽게 이루어 지지 않는다는 것이 슈퍼 스칼라의 가장 큰 문제이다. 이런 것도 스케줄러에 의한 명령의 정렬도 만능은 아니라 특히 동시 처리 명령 수가 많을수록 이 정렬의 난이도가 증가하기 때문이다.

 실제로 수퍼 스칼라을 먼저 구현한 x86은 인텔의 Pentium와 Cyrix의 M1 ※2  하지만 모두 2 명령어의 수퍼 스칼라 정도였다. 이상 동시 발행 명령어 수를 늘리려면 회로 규모으로 너무 복잡해서 당시의 공정 기술에서는 불가능했던 것도 있지만, 단순히 슈퍼 스칼라로 3 명령어 처리를 행해도 (종속성 해소가 어렵기 때문에) 성능이 오르지 않는다는 문제가 있었던 것도 사실이다.

※ 2 원래 계획은 Cyrix의 M1 쪽이 먼저 구현하고 등장의 예정 이었지만, 개발 지연으로 Pentium가 선행 출시 ( 관련 기사)

(그런데 여기서는 M1이 먼저 슈퍼스칼라를 계획했다고 나오고, 관련기사가 있다고 하는데, 관련기사를 직접 읽어봐도, 그렇게 보이지 않습니다. 왜냐하면 펜티엄은 1993년에 출시가 됩니다. i80486이 89년에 출시가 되구요. 486까지는 인텔도 x86 개발팀은 1개였고 (RISC CPU 개발팀은 별도. iAPX 432, i860/i960 RISC CPU 개발. i960은 초기 F-22에 사용. RISC CPU는 슈퍼컴퓨터용으로 개발) 486 개발이 끝나고 펜티엄 개발에 들어간 이후에 2개가 됩니다.

 

(486 -> 펜티엄  산타클라라 개발팀. RISC CPU 개발팀 = 펜티엄 프로를 개발한 오리건 개발팀. 후에 펜티엄4와 네할렘 등을 개발. 문제는 산타클라라 개발팀이 펜티엄 개발후에 P7을 개발을 시작하는데, 시작 초기에 P7 개발이 취소되고, HP CPU 개발팀과 공동으로 개발하는 슈퍼컴퓨터및 최상위 서버용 CPU 머시드(IA-64) 개발팀으로 변경. 한동안 x86의 새로운 CPU는 오리건 팀 혼자서 개발. 기타 이미 개발된 CPU의 파생형 제품들은 이스라엘의 하이파 개발팀이 개발. 하이파 팀은 나중에 콘로, 샌디브릿지/아이비브릿지 개발로 다시 2개의 x86 개발팀 체재.).

 

486 출시부터 펜티엄 출시까지는 4년이지만, 펜티엄이 93년에 출시된 2년 후인 1995년에 펜티엄 프로가 출시가 되죠. M1은 97년에 출시가 됩니다. 또 해당 기사에서 펜티엄으로 이동한 인텔을 추격하기 위해서 M1 개발에 착수를 했다고 나옵니다.

 

97년에 출시된 슈퍼슈칼라 CPU인 M1이 발표가 되는데, 이게 개발중 난항을 겪어서 절반 스펙인 M1SC Cx5x86을 먼저 출시했다고 하는데,  이 제품도 95년에 나옵니다. M1의 절반 스펙이면 인텔 486을 그대로 따라만든 제품은 아니지만, 스펙상 486에 가깝다는 얘기구요.

 

최초의 Cyrix 이름의 486이 붙는 제품은 92년 출시된 Cx486DLC 인데, 이 386보드에 사용하기 위해 나온 제품이고, 캐시다 1kB 밖에 없어서 486보다 느립니다. 진짜 486은 1993년 출시한 Cx486DX 이구요. 이런 제품은 그대로 따라한 제품이구요. 해당 기사에 그렇게 나와 있습니다. 뭔가 앞뒤가 맞지 않는 내용 입니다.)

 

싸이릭스 5x86과 인텔 펜티엄의 성능 비교는 아래 링크를 클릭해서 아래로 이동해서 보세요.

https://tware.tistory.com/961

 

 

이 문제를 해결한 것은 다음 설명하는 아웃 오브 오더와 그 다음에 설명하는 RISC 형 명령으로 변환하는 등의 기술이 결합해 크게 성능을 끌어 올리는 것이 가능하게 되었다.

 


 참고로, 지금까지 여러 균일한 실행 단위가 줄 지어있는 것처럼 설명했지만, 당연히 이 부분의 구현은 제품에 따라 다르다. "Cyrix MII" 의 경우는 거의 같은 명령을 처리 할 수​ ​있는 실행 유닛 × 2의 구성이었다. 한편 Pentium의 경우 "U Pipe" 와 "V Pipe"라고 하는 2 개의 유닛이 포함되어 모든 명령을 처리 가능은​​ U Pipe 만. V Pipe는 일반적으로 사용되는 간단한 명령어만을 처리 할 수​ ​있는 구성으로 되어 있었다. 이러한 구성은, 예를 들면 VIA의 "Isaiah"인(로 불린, 아키텍처인) "VIA Nano"프로세서에서도 이용되고 있다.

 x86 이외에 눈을 돌리면, 예를 들면 "MIPS32 74K '라는 프로세서는 2개의 연산 파이프 라인을 탑재한 슈퍼 스칼라 (아웃 오브 오더는 탑재하지 않는) 구성이지만, 다른 한쪽은 ALU (정수 연산) 만, 다른 한쪽은 AGEN (주소 생성)만 하는 극단적으로 결론 지은 구성으로 되어있다. 반드시 수퍼 스칼라는 아웃 오브 오더는 필요 없다는 예라고도 말할 수 있지만, x86 명령어의 복잡성 역시 아웃 오브 오더나 명령 변환을 필요로 할 수 밖에 없다는 측면은 있을 것이다 (사실 x86 문제라기 보다 CISC의 문제라고 하는게 더 정확하겠죠. CISC CPU도 많은데, 아무래도 x86이 대표적인 CISC CPU이다 보니 그냥 x86의 문제라고 쓴거 같구요. 그래서 펜티엄 프로에서 아웃 오브 오더, 명령 변환을 들여오고 더욱더 RISC화 시킨게 펜티엄4죠. 그런데 그걸 다시 되돌려서 RISC화를 최소화 시킨게 펜티엄M 베니어스,도선,코어솔로,코어듀오죠. 이후에 더욱 발전시켜 더욱 RISC화를 최소환 시킨 CPU가 데스크탑/서버/노트북 통합 아키텍처로 출시된 제품이 코어2 듀오 콘로(메롬)죠. RISC화가 좋다고 더더욱 진헹시킨 펜티엄4는 상업적으로야 인텔의 생산량(반대로 AMD의 공장 생산량이 x86 시장의 20% 남짓 밖에 되지 않음. 인텔은 FAB이 엄청 많고, AMD는 2개 밖에 없죠.) 덕분에 유지가 되었지만, 좋은 CPU인가? 로는 좋은 평가를 못들었죠. 그리고는 반대로 RISC화를 줄이고 다시 CISC에 가까운 형태로 돌아갔습니다. 왜 돌어간지는 아래의 글을 읽어 보세요.).

 

[아키텍처] Core Microarchitecture 속도의 비밀은 CISC의 아름다움

 


 다음은 슈퍼 스칼라와 짝으로 거론되는 아웃 오브 오더에 대해 설명 하고자 한다.

 

2010년 9월 20일 기사 입니다.

 

 

[분석정보] CPU 고속화의 기본 수단 파이프라인 처리의 기본 1/2

 

 

[분석정보] CPU 고속화의 기본 수단 파이프라인 처리의 기본 2/2

 

 

 

[분석정보] 명령의 실행 순서를 바꿔 고속화 하는 아웃 오브 오

 

 

[분석정보] x86을 고속화하는 조커기술 명령변환 구조

 

 

[분석정보] CPU와 메모리의 속도 차이를 해소하는 캐시의 기초지식

 

 

[분석정보] 캐쉬 구현 방식으로 보는 AMD와 인텔이 처한 상황

 

 

[분석정보] 5W 이하의 저전력 프로세서의 개발로 향하는 Intel

 

 

[고전 2005.11.30] 마이크로 아키텍처의 변화를 반영하는 "Core"브랜딩

 

 

[분석정보] 20년 후인 지금도 곳곳에서 살아남은 펜티엄 아키텍처

 

 

[분석정보] intel의 듀얼 코어 CPU 1번타자 Montecito

 

 

[분석정보] 멀티 코어 + 멀티 스레드 + 동적 스케줄링으로 향하는 IA-64

 

 

[정보분석] Penryn의 1.5 배 CPU 코어를 가지는 차세대 CPU "Nehalem"

 

 

[고전 2002.09.12] Hyper-Threading Technology를 지원하는 HTT Pentium 4 3.06GHz