Category Archives: Microprocessor

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을 사용한 것을 알 수 있습니다. 따라서, 일반적인 개념상 더 빨라야 정상이겠습니다.

ARM의 Cortex-A9 프로세서.

[wp]ARM[/wp]에서 Cortex-A9을 발표하였다고 합니다 [ZDNet 기사]. 일단 저에게 있어서는 한숨 쉬어지는 일이고(ARM의 행보가 점차 빨라지니, 저희같은 업체가 따라잡을 수 있는 여지가 줄어들고 있는 것이 사실이니 말입니다.), 업계에 있어서는 환영할 만한 일이겠습니다. Cortex-A9의 경우 4개 까지 MP로 구성이 가능하다고 하니(MP 구성을 따지는 것으로 보아, cache snooping이 고려된 SMP겠지요..), 대단한 성능을 기대할 수 있겠습니다.


여기서 재미있는 것이 Intel의 대응인데요. 기존에 ARM 기반의 프로세서를 만들다가 해당 부분을 과감히 정리하였지요. 근데, EETimes에 의하면 Intel이 ARC의 프로세서를 라이센스했다고 합니다[EETimes 기사]. ARM 기반을 정리할 때는 x86기반의 embedded processor쪽으로 무게를 둔다고 생각했는데, 범용쪽은 x86기반, 저전력이 요구되는 application specific한 부분은 configurable processor인 ARC쪽에 무게를 두는 느낌입니다. 그래도, x86기반에서도 충분히 configurable하게 만드는데 어려움이 없을 것인데.. 저전력을 위해서 이런 결정을 내린 것이 아닌가 하는 생각입니다.


이러한 행보에 맞추어 저희 회사에서는 Heterogeneous MPSoC쪽에 무게를 두고, 여기에 적합한 lightweight/low power processor와 interconnection에 무게를 두고 있습니다[네이버]. 몇 가지 재미있는 아키텍처적인 시도를 구상하고 있는데, 보도 자료에는 좀 이상하게 나간 느낌이 있습니다. 물론, 마케팅적인 측면을 위해서 빠른 프로세서를 만들어야 겠다는 생각은 변함이 없습니다만.. 실제로 MPSoC에서 중요한 것은 적절한 성능의 작은 footprint를 지닌  low power 프로세서들이니까요. (적절한 성능이란 것이 task에 따라 바뀌는 것이므로, 아주 강력한 프로세서를 개발해야 할 필요성도 있는 것이지요)


뭔가 흥미 진진해질 것 같아요.

Tilera Processor.. 병렬성을 통한 성능 향상

ISSCC’07에서 Intel에서 80개의  core를 집적한 Tera-FLOPS급 프로세서를 발표했었지요. 이번 HOT Chips 19에서는 Tilera라는 회사에서 TILE64 프로세서를 발표한 것이 화제가 되었습니다. 약간 비스므리한 과제를 기획하고 있어서 관심있게 몇 가지 프로젝트를 지켜보고 있었는데, TILE64는 사실 제가 알고 있던 프로세서는 아니었지요.


이는 NoC(Network-on-a-Chip)에 기반을 두고, 다수의 프로세서를 묶은 형태로 볼 수도 있겠는데요 (이런 프로세서가 처음은 아니지요. 기존의 intel의 network processor들이 이런 형태를 가져간 적이 있습니다). 사용하려는 application의 task parallelism이 상당한 경우에 유용한 형태라 볼 수 있습니다.



 


[TILE64의 구조; 일본 MYCOM에서 Tilera의 것을 인용한 것을 재인용합니다.]



이렇게 다수의 프로세서를 집적하는 경우, processor 개개의 속도보다는 area와 전력 소모가 중요한 요소가 됩니다. 프로세서의 속도를 올리는 것 보다 프로세서의 수를 증가시켜 성능 향상을 도모하는 것이니까요.


사실, 성능 향상에는 clock frequency를 증가시키는 것이 더 유용할 수 있습니다.(예전에 speed-demon approach를 말씀드린 것 처럼) 어짜피 전력 소모는 동작 주파수에 비례하니, 전력소모가 급증하지도 않을 테구요. 클럭 주파수를 2배 올려서 얻는 전력의 불이익보다, 코어 2개를 써서 얻는 전력의 불이익이 클 수도 있겠지요? 클럭 주파수를 2배로 올리면 performance가 2배가 되는데, 코어 2개를 쓰더라도 parallelism이 없으면 소용 없으니 말입니다.


그럼에도 왜 클럭 주파수를 높이지 않고 multicore를 사용할까요?


우선, 클럭 주파수를 높이는 것이 그렇게 녹녹하지 않다는 것이지요. 클럭 주파수를 높이기 위하여 합성을 심각하게 하면 area는 exponetial로 증가하며, 클럭 주파수를 높이기 위해서 미세 공정을 적용하면서 leakage current가 심각한 문제로 나타나고, 클럭 주파수를 높이기 위해서 dynamic gate를 쓰다보니 clock frequency 조절에 문제가 생기고, 클럭 주파수를 높이기 위해서 pipeline을 깊게 만들다보니 명령어 처리 효율(insturction per cycle:IPC)이 떨어지고, 이를 회복하려다보니 복잡한 dynamic branch prediction을 적용시켜야 하고.. 등등등..


클럭 주파수를 높이기 위해서 얻는 이득보다, 잃는 것이 많아지고 있는 것이지요. 즉, (parallelis이 어느 정도 존재한다면) 느린 코어를 여러개 쓰는 것이 유리한 시점까지 와버린 거라고 볼 수 있습니다. 문제는.. task 수준의 parallelism을 얻을 수 있는 application이 (현재로서는) 통신과 미디어 처리 부분이라는 것입니다. 이 문제의 극복은 쉽지 않아보이긴 합니다 ^^;