32코어, 128스레드의 인텔 Larrabee GPU

예전에 들은 내용이긴 한데 그 동안 여전히 공개되지 않다가 오늘 파코즈에 올라온 글을 보니 이 정보가 유출이 된 듯 하다. 인텔이 개발 중인 래러비 GPU는 x86 기반의 프로세서 32개로 출발한다. Out-of-Order 프로세서는 아니고 in-order 형식이다 (사실 이런 구조에서 in-order인 것이 당연). 그래서 파코즈의 글 처럼 P5 (펜티엄 클래식의 마이크로아키텍처)에 기반했다고 표현되어있다. 이 작은 프로세서들은 4개의 스레드를 동시에 돌릴 수 있는 구조여서 총 128개의 스레드가 동시에 돌아가는 구조. 하이퍼스레딩과 같은 SMT는 아닌 것 같지만 어쨌든 하드웨어 수준에서 4개의 스레드가 처리가 되도록 한다. 내 생각엔 hard-partitioned multi-threading 정도가 아닐까 싶은데, 좀 더 알아봐야할 듯.

그리고 중요한 것은 512비트의 SIMD (Single Instruction Multiple Data) 명령이 처리 가능하다는 점. 즉, 16개의 float이나 int를 한방에 처리 가능한 명령어셋을 지원한다. 예를 들어, 주어진 두 float [16] 배열을 가지고 전체 벡터 합을 구한다거나, 각 원소에 대해 덧셈과 뺄셈을 지그재그로 한다거나, 아니면 saturated arithmetic을 한다거나 이러한 연산이 한방에, 즉 한 사이클에 된다는 것이다. 현재 Core 2 Duo는 128 비트의 SIMD(=SSE3)를 지원한다. 아마 올해 나오는 네할렘은 (SSE 4.1) 128비트 SIMD이고, 그 다음 인텔의 마이크로아키텍처인 Sandy Bridge는 256비트로 확장된 AVX 명령어 셋이 지원된다.

 

사실 이런 구조는 새삼스러운 것은 아니다. 코드네임 Niagara인 Sun의 UltraSPARC T1 프로세서는 이미 8개의 코어와 4-way SMT (즉, 하이퍼스레딩 인텔 CPU가 코어 당 2개의 가상 CPU를 만들었다면 이 녀석은 4개를 만든다)을 구현해서 32개의 스레드가 동시에 실행되는 CPU가 이미 2005년 11월에 나왔었다. Niagara 2인 UltraSPARC T2는 이 보다 더 나가 8코어에 코어 당 8스레드가 실행되어 64개의 스레드가 동시에 실행되는 CPU이다. 아래 그림은 나이아가라 2의 대략적인 다이어그램.

L2 캐쉬는 4MB 공유이며 8개의 뱅크로 나뉘어 있는 구조. 즉 8개의 독립된 입출력은 동시에 가능하다는 소리. 뱅크 하나만 해서 Read/Write 포트를 늘리는 것은 일반적으로 매우 어렵기 때문에 대용량 캐쉬에서 더구나 이런 많은 코어에서는 멀티 뱅크 구조가 합리적이다. 만약에 한 뱅크에 여러 입출력 요구가 몰리면 이른바 bank conflict가 생기고 성능 저하로 연결된다. 이런 bank conflict는 캐쉬 뿐만 아니라 DRAM에서도 일어날 수 있으며 DRAM 레이턴시를 갉아먹는 주요한 원인이다. 이쪽은 자세히 잘 모르므로 더 이상 언급은 생략.

따라서 AMD가 인텔보고 네이티브 쿼드코어 디자인은 우리를 베꼈어! 이런 건 좀 넌센스. 또, 메모리 컨트롤 내장도 AMD 뿐만 아니라 다른 아키텍처에서도 흔히 볼 수 있는데, 이런 걸로 기술의 우위를 논한다는 건 좀 웃기다. 현재 AMD 쿼드코어가 2년 전 나온 인텔 Q6600 에게도 밀리는 것이 사실인데 좀 얼굴이 화끈 거린다. 그래도 AMD가 좀 분발해줘서 요지 부동인 인텔 CPU 가격이 떨어지도록 좀 해주기를. 이번에 ATi의 4850이 엄청난 가격 대 성능비로 데뷔하자 nVidia의 8000 시리즈는 가격을 대폭 하락할 수 밖에 없었다. 요즘 ATi 때문에 난리~

 

다시 GPU 이야기로 돌아가서, nVidia GPU 역시 100여개 이상의 스레드가 동시에 돌아가는 구조라서 큰 그림은 결국 비슷하나 인텔은 조금 더 많은 일을 할 수 있는, 즉 좀 더 CPU 스러운 녀석을 중심으로 구현한 것이 차이인 것 같다. nVidia GPU 구조는 워낙 계층이 많고 용어가 모호해서 이해하기가 참 힘들었는데, 최근 나온 GTX 280에 대한 구조를 읽어보니 이제 조금 감이 잡힌다. 그래도 그래픽 쪽에 대한 지식히 부족해서 그런지 좀 긴가민가한 점이 여전히 있다.

일단 아래 그림 중 SP라고 불리는 아주 간단한 구조의 Streaming Processor로 출발을 한다. 보다시피 레지스터 파일이 있고 계산 유닛이 있는 파이프라인화 되어있는 간단한 CPU이다. 이것과 SFU라고 하는 Special Function Unit을 묶어서 Streaming Multiprocessor, SM을 하나의 빌딩블럭으로 만든다. 여기에는 보다시피 캐쉬도 있고 공유 메모리도 있고 그렇다.

그런 뒤에 다시 얘들을 묶어서 Texture Processor Cluster라는 TPC를 만든다. 8800시리즈는 SM이 두개 있었다면 GT200은 3개가 묶어져있다.

그리고 이걸 또 모은다. nVidia 최신 GT 280은 이걸 10개를 모아서 총 240개의 스트리밍 프로세서를 가지고 있고 이 숫자는 과거 G80 구조가 가졌던 128개에 비해 대폭적인 증가이다.

이제 마지막으로 메모리랑 연결하고 그래서 GPU가 완성된다.

뭐가 참 복잡하다. 그래도 그 동안 GPU가 어떻게 생겨먹었나 궁금하셨던 분들에겐 조금이나가 그림이 그려졌기를 기대해본다. Larrabee는 좀 더 나이아가라스러운 구조가 아닐까 한데 나도 아는 바가 없어서... 그래도 본질적으로 100여개 이상의 스레드를 동시에 처리할 수 있다는 점에서 동일하다고 볼 수 있다.

by object | 2008/07/06 13:06 | 컴퓨터 | 트랙백 | 핑백(1) | 덧글(7)
트랙백 주소 : http://minjang.egloos.com/tb/1965403
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Linked at 오서비네 이글루 : [펌] U.. at 2008/10/20 09:55

... ☆</a> <a href="http://minjang.egloos.com/1965403" class="permalink" title="32코어, 128스레드의 인텔 Larrabee GPU" rel="bookmark">#</a> by object | <a href="http://minjang.egloos.com/1965403" class="time" title="32코어, 128스레드의 인텔 Larrabee GPU" rel="bookmark">2008/ ... more

Commented by tan at 2008/07/07 18:47
어머, 무플방지.
Commented by object at 2008/07/08 15:12
무플방지에 나서도 알바비는 없다.
Commented by ez at 2008/07/11 02:06
재미있게 잘 보고 갑니다. ^^
( 항상 RSS로만 보다보니, 직접 와서 보는 것은 또 다른 느낌이네요. )
Commented by nineye at 2008/07/16 14:39
흠... 컴파일러 만드는 사람들이 바빠지겠군요... 제가 CPU에 대한 지식이 좀 딸려서 그런데... 여기서 말하는 thread는 소프트웨어적인 thread와는 달리 context switching같은 게 필요없이 독립적으로 수행할 수 있는 것을 말하나요? 그럼 그것에 대한 제어는 어떻게 하는지 궁금합니다. 각 thread마다 따로 register를 가지고 있다면 가능하겠지만... 요즘 듀얼 코어에 대해 실망한 것도, 하나의 process마다 하나의 코어를 할당해서 결국 process 하나만 실행하면 하나의 CPU만 사용하고, 두 개 이상 실행해야 두 CPU를 사용한다는 단순한 방식이 좀 그렇더라구요...
Commented by object at 2008/07/16 15:32
1. GPU에서 이야기하는 thread는 그게 개념이 조금 짜증나게 혼동스러운데 우리가 흔히 운영체제에서 다루는 그 스레드가 아니라 하드웨어 레벨에서 자기 자신의 레지스터 벡터를 가지는 스레드라고 보면 됩니다. 스케쥴링이 하드웨어 차원에서 이루어집니다. 자세한 건 잘 모릅니다. 별로 문서화되지 않아서..

2. 하나의 thread는 물리적인 코어가 여러개 있어도 단 하나만 사용하지요. 그런데 한 process라고해도 여러 스레드가 존재하면 스레드별로 돌아가는 코어/CPU를 당연히 조절할 수 있습니다. 운영체제가 알아서 대부분 해주고 affinity를 직접 조절할 수도 있습니다. 설마 한 스레드를 동시에 두 개 이상의 코어에 돌리기를 바라신 건 아니겠죠? :) 그렇게 해서 싱글스레드 성능을 올려보자는 아이디어도 많지만 쉽지 않겠죠.
Commented by nineye at 2008/07/16 16:02
사실 제가 바랬던게 그거 였는데... ㅋ 듀얼 코어 환경에서 하나의 process에 하나의 소프트웨어 thread가 돌아갈 때, 그 thread는 하나의 코어 밖에 사용하지 못하는게 맘에 안들어서요.. 비싼 돈 들여서 코어 두개가 들어있는 CPU를 샀는데 그 반밖에 사용하지 못한다면 차라리 코어 하나에 hz높은 걸 사는게 효율적일 거라는 생각이 드네요... 만약 하드웨어 수준에서 여러 개의 코어가 있을 때, 안정적인 병렬처리만 제공해 준다면 그것을 이용하는 소프트웨어는 CPU의 구성방식을 몰라도 모든 코어를 이용해서 빠르게 동작할 수 있을거라는 이상적인 생각이...ㅋ 물론 어렵겠죠... 그냥 제 생각입니다.. ㅋㅋ
Commented by object at 2008/07/16 16:22
그게 되면 병렬 프로그래밍이 필요가 없죠. 싱글스레드의 성능, 즉 클럭스피드를 올리는 건 넷버스트 아키텍처로 처절히 힘들다는 것이 판명이 나서 지금은 다 머릿수를 늘리죠. 그래서 성능을 비약적으로 올리기 위해 과거와 같이 클럭 높은 CPU만 사는걸로 해결이 되지 않죠. 직접 병렬화를 해야하고 그래서 요즘 심각한 프로그래밍 패러다임의 변환기에 있는 겁니다. 이미 CPU 싱글코어에서도 명령어 수준 병렬성을 이미 10년 이상 잘 뽑아내고 있습니다만 이게 한계가 와서... 그런겁니다. 한 스레드를 여러 코어가 협력(?)해서 잘 실행시켜 줘서 성능이 곱절로 늘면 얼마나 좋겠습니다만 한 스레드 내에는 이미 병렬화가 불가능한 직렬로만 수행해야하는 코드가 많이 있어서 매우 힘듭니다. 그래서 뭐 thread level speculation이라고 그런게 있습니다만.. 논문으로만 있고 구현되기도 힘들고 뭐 그렇군요.

:         :

:

비공개 덧글

<< 이전 페이지 다음 페이지 >>





by 김민장 2008 이글루스 TOP 100
최근 등록된 덧글
개발자 입장에서의 수많은 ..
by Jiyoon at 02/04
저도 아들 돌잔치때 돌잡이 ..
by 박상욱 at 01/18
미국 대학원 원서 작성중에 p..
by 태클사이야 at 01/13
TO: 박PD 로그인 하지 않아..
by 박응용 at 01/10
http://gigglehd.com/zbx..
by dhunter at 12/28
우와.. 좋네요. 태반이 ..
by 윤광배 at 12/17
항상 좋은 글 잘 보고 있습니..
by y2k at 11/23
글이 좋아서 제 블로그에 담..
by 쏭섭 at 11/23
최근 등록된 트랙백
조엘 스폴스키의 강연 (Sta..
by 인덕원칸타타
[Redis] sds.c를 분..
by 조급하지말고 천천히
메뉴릿
이글루 파인더

website counter

Add to Google

rss

skin by 이글루스