새로운 EISC processor

저희 팀에서 이번에 새로 만든 EISC processor인 Empress에 대한 기사가 많이 나오고 있습니다. 단신을 제외하고도 꽤 많이 나왔군요.

 

 

일단 정말 승질 머리 디러운 팀장의 강력한 태클과 갈굼을 이겨내고 좋은 결과를 거둔 팀원들에게 최고의 찬사를 보내고 싶습니다. 짝짝짝~! (제가 그 팀을 알아서 하는 이야긴데, 제가 그 팀장 밑에 있었으면 아마 회사 때려쳤을 겁니다. ㅋㅋㅋ)

여하튼, 새로운 프로세서에 많은 관심이 보여지고 있다는 점에서 상당히 기쁘긴 하지만, 대부분의 기사가 속도에 방점을 찍는 관점에서 많이 기술되어 있다는 점은 약간 아쉬운 점이지요. 사실 속도를 높이는데 여러 가지 요인이 있겠지만, 마이크로 아키텍쳐적인 접근을 제외한다면, 가장 중요한 것이 좋은 공정 + 좋은 cell library + 좋은 macro block을 사용하는 것이 중요합니다. 근데, 저희는 그다지 큰 회사가 아닌 관계로 좋은 공정은 물론이요 좋은 cell library(고속 cell library는 따로 비용 청구가 되지요)나 좋은 macro(특히 cache tag에 사용되는 CAM이 아닌 일반 High density single port SRAM을 사용하게 되면 속도차이가 심하죠..)를 사용하는 것이 비용의 문제로 쉽지 않다고 인식하고 있습니다. 따라서, 속도는 마이크로 아키텍쳐에서 할 수 있는 수준까지만 잡아놓자는 것이 저의 일관된 접근 방법입니다.

이번 Empress 프로세서는 단순한 MHz 단위의 클럭 속도보다는 면적이나 전력 소모를 줄이고, 클럭당 명령어 수를 높일 수 있는 방법, 그리고 자바 언어 가속 기술에 무게를 두고 만든 버전입니다. 그래서, 적은 면적(대략 동급 ARM의 절반 크기)에서 좀더 정교한 분기 예측기와 loop 처리 기법, out-of-order completion 방법, non-blocking cache등의 주요 기술을 저희 프로세서를 위하여 개발하는데 공을 많이 들였습니다. 물론 부족한 부분이 아직 많아서 좀 더 노력해야 할 부분이 많지요.

보도 자료 상에서도 위의 이야기가 많이 있었는데, 실제적으로는 거의 다루어지지 않아서 좀 아쉽습니다. (기자 분들께서 비 전문가를 위해서 가장 이해하기 쉬운 부분을 발췌하신다는 것은 알고 있습니다만..)

앞으로도 저희 프로세서는 특별한 일이 없는 이상(예를 들어, 가끔 정말 모르시는 분께서 ‘어찌되어도 좋으니 xxxMHz를 맞추어야 한다’라고 외압을 넣으신다던지..) 단순히 클럭 끌어올리기는 없으며, 1) 명령어 수준의 병렬성과 쓰레드 수준의 병렬성을 찾아가는 방향과 2) 자바와 같이 intermediate language를 이용하는 환경을 가속하는 방향으로 발전할 예정입니다.

특히 2009년, 자바 언어와 2D 벡터 그래픽은 embedded 분야에서 매우 중요한 명제가 될 것으로 예측하고 있습니다. 그래서, 저희 팀에서는 프로세서의 자바 가속뿐 아니라 2D 벡터 그래픽 분야도 같이 병행하고 있지요. 2009년 요맘때쯤 또 한번 재미있는 소식을 전해 드릴 수 있기를 바라고 있습니다. ^^;

내년 상반기 중에는 사내에서 사용하고 있는 linux수준의 OS 구동이 가능한 시스템 수준의 시뮬레이터인 ESCAsim(EISC System Cycle Accurate Simulator)의 소스 코드를 좀 정리해서 Open Source로 배포하는 것도 계획 중이며, IDEC과의 작업도 성공적으로 진행 중에 있고, EISC 개발 지원을 위한 Community site도 준비 중에 있습니다.

사람도 없는데, 참.. 벌이는 일은 많고 해서 걱정이긴 합니다. 어려울 때 한발자국 더 뛰는 사람이 내일을 기약할 수 있을 것이라 믿고, 힘들지만 몸땡이를 더 굴려보렵니다.

Intel의 새로운 GPU

제가 자주 그렇게 하고 있습니다만, 이 글은 MPR의 기사와 몇몇 논문을 기반으로 하고 있습니다. 읽고 제 맘대로 쓰는 글이라 항상 그렇듯 모두 맞는 내용을 쓰고 있다는 보장은 없어요.



Intel이 새로운 UFO를 주워서 새로운 장난감을 만들었습니다 ^^; 사실 인텔에게 GPU는 생소한 분야가 아닙니다. 이미 GPU 분야에서 상당한 – 실제적으로는 모든 마켓을 고려했을 때는 가장 큰- 마켓 쉐어를 가지고 있으니까요.. (근데, 아직도 이런가요? 몇년전엔 맞는 이야기인데, 아직도 이런지는 확신이 없네요. )



돌아가는 상황


Intel이 x86 기반으로 데스크 탑과 서버 시장을 장악하고 있다는 것이야 다들 아는 사실이고, 예전에 예상했듯이 strongARM과 XScale 사업을 버린 이유가, x86기반으로 embedded 시장에 도전하려는 것이라는 것도 실제로 나타났지요. 오히려 예상보다 느린 행보라 약간 의아할 뿐입니다. 실제적으로 ARM과 불꽃 튀게 붙게 될 시점은 2010년 정도로 보고 있습니다. ARM에서 저전력을 가지고 이러니 저러니 해도 Intel은 아직 SoC를 만든 것이 아니라, mobile processor를 embedded 시장에 맞도록 한번 바꾼 정도라고 보시는 것이 맞을 것입니다. 즉, ARM에서 내세우는 저전력의 우세는 ARM에서 그러하듯이 intel이 대부분의 peripheral을 on-chip화 시켜 SoC를 만들어내는 2010년 정도에 따져볼 일입니다. 게다가 이전에 썼듯이 ARM의 Cortex-A9의 경우 기존의 A8과 비교하여 여전히 energy-efficient할 것인지 의문입니다. (물론, 2-way까지는 Instruction Level Parallelism 가 충분하므로 어느 정도 까지는 문제가 없겠지요 ^^;)




Intel의 새로운 GPU; Larrabee


이러한 상황에서 Intel이 새로 내놓은 GPU는 기존의 3D accelerator와 차이가 많습니다. 각core당 16-lane SIMD 와 4개의 thread를 지원하고, NoC를 기반으로 하여 필요에 따라 다수의 코어를 연결할 수 있는 형태의 범용성 높은 프로세서를 만든거죠. Larabee는 일종의 NoC 기반의 array/vector processor 형태를 취하고 있는 것으로 보시면 되겠습니다. GPU가 GPGPU를 내세우니, 그동안 잘 알려진 general processor형태로 GPU를 공략했다고 할까요 ^^;


이런 형태나 시도가 없었던 건 아니죠. 약간 모양이나 형태가 다르긴 합니다만, media processor도 이런 형태의 접근이죠. dedicated engine을 사용하지 않고, 범용성 높은 vector processing unit으로 시장을 공략했었던 것이지요. 단지, 그 당시에는 여러가지 이유로 이러한 시도가 실패했는데, 뭐 다들 짐작하시듯 전용 엔진이 범용 엔진보다 전력 소모, 효율 면에서 앞서기 때문이죠(게다가, 당시 3D accelerator는 rasterizer 부분에 포커싱 되어 있어서 범용성이 매우 떨어졌습니다). 그런데, 이번에 이런 시도는 어찌보면, GPU 가 이런 저런 기능을 GPU에 넣다보니, 파이프라인과 연산의 형태가 GPGPU를 시도할 만큼 범용성을 갖춘 시점이기 때문에 가능한 한번 싸워 볼만한 시점이 된 것이기 때문이라 보입니다. GPGPU를 하느니 첨부터 vector-array processing을 해서 programmability를 높이는 접근이 좋지 않냐..라는 거겠죠.


게다가, 명령어 셋을 x86 기반으로 가져가니, 어렵게 GPGPU를 위한 언어를 따로 쓸 필요도 없지요. (병렬 프로그래밍이나 컴파일 문제는 따로 이야기하더라도..). 이 부분은 기존에 이미 multiprocessor를 위하여 작성된 대부분의 x86 기반의 프로그램이 아주 잘 동작할 것이라는 것이고, multiprocessor를 위한 것이 아니라도 recompile이 필요하진 않을 거라는 거죠. 즉, 이미 잘 구성되어 있는 x86의 컴파일러들과 multicore를 위한 지원등을 그대로 이용할 수 있다는 아주 큰 장점을 지닙니다. (GPGPU의 가장 큰 진입 장벽이 새로운 renderer 명령을 배워서 써야 한다는 점을 생각하면 이해하기 쉽습니다.)



상황에 대한 이야기는 대충 된 것 같고, 전체 구조는 아래와 같습니다. (인터넷 찾으니 그림이 많군요 ^^; 원본 그림은 watermarking 된것 처럼 TECHARP.com에서 온 것 같습니다. google image검색에서 따 온거라 ^^;)




각 코어의 scalar/vector processing datapath의 그림은 위와 같구요. 위의 두 그림을 보고 알 수 있는 것은 dedicated L1의 형태를 지닌 vector 프로세서를 NoC(interprocessor ring network) 기반으로 array 형태로 배치한 것을 알 수 있습니다. 첫 그림을 보면 shared 형태의 L2처럼 보이는데, 실은 coherent L2 cache입니다. 코어의 수가 늘어나면 다수의 NoC를 배치한다고 하네요. 그래픽(visual computing)을 타켓으로 하다보니 dedicated accelerator와 몇몇 블록들이 존재 하구요.


형태상으로는 전반적으로 thread level parallelism과 data parallelism을 극대화시키기 위한 형태라고 생각됩니다. 흠.. 근데, snooping에 의한 traffic문제는 어떻게 할지 좀 궁금하긴 해요. NoC 에서 snooping에 의한 traffic이 만만치 않을 것 같은데, 주된 application이 vector processing이라 생각하면 그다지 많지 않을 것 같기도 하구요.



자세한 정보를 얻으실 분은 이 논문 을 읽어 보시는 것이 도움이 되실 것입니다.



요즘 흘러가는 것을 보면, 예전에 한번 실패했던 재미있는 테마들이 새로운 응용 분야, 기술의 발전에 힘입어 재미있게 융합되어 부활하는 것 같아서 흥미진진합니다.

via nano와 Intel atom간의 벤치마크가 화제라는데..

오랫만에 올블을 보다보니, VIA nano와 Intel ATOM간의 벤치 마크 결과 VIA가 앞섰다는 이야기가 있어서 좀 찾아봤습니다.


지난 글에서 간단히 썼듯이 ATOM의 경우 전력 성능을 위하여 speculation을 최대한 자제한 프로세서라 할 수 있지요. 따라서 in-order issue pipeline을 사용하고 있습니다.


MPFJ 2008에서 Belli Kuttanna의 발표를 보면 다음과 같은 내용이 있지요.



이 이야기를 하면서, ‘baseline core에 비하여 성능이 떨어지더라도, 전력 소모를 줄이는 것이 목표이며, 이를 위해서 처음부터 다시 개발했다(developed from scratch)’ 라는 이야기를 같이 했었지요. 그만큼 저전력 마켓에 대한 의지가 강력하다는 의미로 받아들일 수 있겠습니다.


문제는 in-order issue의 경우 out-of-order에 비하여 여러 면에서 성능 차이가 발생하게 되는데, 이를 해결하기 위한 intel의 방법입니다. ATOM에서는 2개의 thread를 지원하는 SMT 구조를 채용하고, 프로세서의 입장에서는 약간 특이한 OF(RF)-AG-DC1-DC2-EX-WB 형태의 backend pipeline을 구성하여 x86 native(macro) instruction에 최적화 시킨듯한 느낌입니다. 이 경우 분기 예측의 중요성이 매우 커지게 되는데, 이를 보완하기 위해서 branch trace buffer, GShare predictor와 Return stack buffer등을 채용해서 분기 쪽은 비교적 aggressive하게 만든 거죠.


좀 재미난 건, 슬라이드 중의 다음 내용인데요..


Reduced number of specialized execution units and queuing structures
– no integer multiplier, divider, store data buffer


처음에는 저렇게 해도 성능(clock freq말고요..)이 나올까.. 라는 부분이 궁금했습니다만, 강력한 SIMD/FP part가 있으니 integer part중 복잡한 연산을 모두 FP 부분에 넘기고, 이 결과를 바로 integer 연산 pipeline쪽으로 넘기는 동작을 수행하더군요. SIMD/FP 연산의 경우는 reg-reg 연산이라서 가능한 거겠지요. 물론 데이터 패스에 보면 메모리에서 FP로 바로 넘어가는 것도 있습니다만, 발생하는 일이 많지 않으니 저렇게 설정했겠습니다.





아.. 제목의 것으로 돌아가서, VIA nano의 경우 약간 접근이 다릅니다. wikipedia의 정보를 보니, VIA의 경우 out-of-order pipeline을 사용한 것을 알 수 있습니다. 따라서, 일반적인 개념상 더 빨라야 정상이겠습니다.