요즘 MPSoC쪽 버스 문제 때문에 GALS(Globally asynchronous Locally synchronous)를 다시 들여다보고 있는데, circuit design을 배제하고 verilog netlist 수준에서 기존의 합성 툴을 이용할 수 있도록 생각하다 보니 자꾸만 생각이 제한됩니다. 조막만한 아이디어가 있긴 한데, 이게 구현 가능한 것인지 생각해 보는 것 자체가 고역인걸 보니 그간 머리를 안 돌리긴 안 돌렸나봐요.
GALS중에 Pausible clock control에서 아이디어를 가지고 오되, 귀찮은 부분은 던져 버려서 latency를 줄이는 것에 주안점을 두고 있는데.. 흠 쉽지 않네요..

요즘 회사에서 superscalar microprocessor/SMT 쪽 강좌(?) 세미나(?) 뭐 이런걸 진행하고 있습니다. 컴퓨터 아키텍쳐란 과목에만 한정되는 이야기는 아닙니다만, 이런 종류의 과목이 비교적 편한 과목이지요. (동의하지 않을 분들도 많을 것이지만. ^^;)
물론, 이런 저런 복잡한 배경과 논리들이 얽혀 들어가지만, 신이 만든 것을 연구하는 생물학이나 화학, 물리학에 비하면 컴퓨터 아키텍쳐 같은 것은 예전 사람들이 만들어놓은 걸 논리적으로 풀어가서 발전시키는 형태의 학문이기 때문에 일종의 퀴즈와 같다는 느낌을 많이 받습니다. (안사람이 분자 생물학쪽을 전공하고 있는데, 이야기 듣다보면 정신이 멍~ 해지지요..) 감탄. 또 감탄! 세상엔 똑똑한 사람이 끝도 없이 있단 말이죠. 젠장..

Android의 Dalvik VM[참고자료]이 공개되었습니다. (원래 되어 있던 건가요? 소스공개는 오늘 되었다네요.. 여하튼). 특징적인건 이 VM에서 사용하는 bytecode가 java와는 동떨어진 형태네요. register 기반의 bytecode니까 말이죠. 아주 좋아요. ^^; 단, 호환성 문제는 어쩔라고 그러는지(살펴보니 .class는 .dex로 바꿔야 한다네요.).. JavaME에서의 Sun license를 피하기 위한 방법이라는데, register 기반이기 때문에 전반적인 성능은 java보다 좋을 확률이 좀 있군요.

SIMD/Vector machine에 관심이 없던 건 아닌데, 좀 의외에 상황에서 건드려야 하는 상황이 발생했습니다. 인력의 문제로 사실 할까 말까를 한 2달 동안 고민했는데, 그냥 고민하고 앉아있는 시간이면 요상한 형태의 SIMD machine은 벌써 하나 만들었겠다라는 생각이 들었어요. 이것 저것 처한 상황 때문에 빠르게 진행될 가능성은 없지만, 간단하게 하나 만들어 봐야겠습니다. 대충 틀만 잡고 누구한테 떠넘겨 버릴지도. ㅋㅋ

회사차원에서 open source진영에 대한 지원을 고려하여, EISC 프로세서 관련 사이트 하나를 개설할까 개인적으로 생각중입니다. EISC processor/system시뮬레이터는 그냥 open source로 공개할 생각이고요. 예전에 작업된 이런 저런 시뮬레이터나 환경, 벤치마크 등도 같이 open해 버릴까.. 하는 생각입니다. 감추어두고 죽느니, 열어두고 살리는 것이 좋겠지요. IDEC과 공동으로 작업하는 MPW 지원 프로그램도 거의 정식 release 직전이고.. 이런 저런 "잡일"로 바쁘네요.

ARM에서 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에 따라 바뀌는 것이므로, 아주 강력한 프로세서를 개발해야 할 필요성도 있는 것이지요)

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

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이 (현재로서는) 통신과 미디어 처리 부분이라는 것입니다. 이 문제의 극복은 쉽지 않아보이긴 합니다 ^^;

프로세서 하는 사람으로 할 소리는 아닌듯 하지만, 사용자 입장에선 dual core 2개를 MCP하던, true quad core나 밥 적게 먹고, 일 잘하는 프로세서가 좋은 프로세서입니다.

예전에 포스팅에서 적은 적도 있지만, Intel의 전략은 일견 영악한 구석이 없잖아 있는 것이 사실이지만 사용자의 입장에서 그런 걸 따질 필요도 없으니, AMD가 굳이 "우린 true quad"라고 이야기할 필요도 없습니다.

단지, true quad의 장점을 보이면 되는 것이겠지요. 여기서는 잠깐 Quad core가 2x2보다 좋을 것 같은 부분을 짚어 보면,

• processor 간의 bandwidth가 아무래도 PAD의 제약을 받고 있는 2x2전략보다는 높을 것이고,
• PAD간에 소모되는 전력도 무시할 수 없을테니, 전력 소모도 적겠습니다. (그리, 크지는 않겠습니다만..)

장점만 있는건 아니니, 단점은

• area가 그만큼 커진다는 말이니 아무래도 수율에 문제가 존재하겠고, 이는 단가 싸움에서 불리하게 작용할 가능성이 있습니다. 물론 2x2전략도 pad의 크기를 고려하면 마냥 행복한 전략은 아닙니다만..

같은 코어를 집적한다면 2x2보다 quad가 좋을 것이라고(가격은 둘째 치고) 말씀드릴 수 있겠습니다만, 현재로서는 뭐라 말할 수 없는 것이 intel과 AMD의 microarchitecture가 다르니 좀 애매한 부분이 있습니다.

물론, 발표된 barcelona자료에서는 몇 가지 장점(특히 대역폭에서)이 보이지만, 이것이 실제 performance로 연결될지는 좀 의문입니다. core당 1MB내지는 2MB의 L2 cache를 내장하고 나면, L2 이후의 traffic은 많이 줄어들지 않을까 생각도 됩니다.

결론은 시장 출시후에 나오겠지요

착찹한 마음에 적은 글에 많은 분들이 격려해 주셔서 진심으로 감사드립니다.  착찹한 마음을 걷어내고 다시 나아기기 시작했습니다. 몇 번 적었듯이 쉽지 않은 길을 가는 것을 지지해 주고, 지원해 주는 회사에도 감사드리고 있습니다. 저희 프로세서에 부족했던 부분을 채울 수 있었던 좋은 기회였으므로, 너무나도 아쉽지만 EISC는 쉬운 길을 갈 운명은 아닌가 봅니다 ^^;

----
프로세서 설계에 있어서 두 가지 중요한 갈래가 있습니다.
바로 속도를 높이는 것이 최고라고 생각하는 접근 방법(소위 speed demon approach -  이후 SDA)와 클럭당 수행되는 명령어의 수를 높이는 방법(소위 brainiac approach  - 이후 BA -라 이야기하는)이 존재하는 것이지요.
두 가지 모두 아주 의미있는 접근이라고 할 수 있습니다. 예를 들어 SDA는 파이프라인 프로세서에서 명령어 수준의 병렬성(Instrcution level parallelism -ILP)를 하드웨어가 동적으로 찾아내는데는 어짜피 한계가 있으므로, 전반적인 클럭 스피드를 높이는 것이 좋다라는 생각입니다.
이 SDA를 기조에 두고 있는 아키텍쳐로 유명한 것이 Alpha였는데, 얼마전까지의 Intel의 Netburst microarchitecture 역시 SDA를 기반에 둔 것입니다. 최대한 파이프를 잘게 쪼개서 높은 클럭 주파수를 얻어냄으로써, 좋은 성능을 얻자는 것입니다.
두 번째 갈래인 BA의 경우 파이프라인을 잘게 나누어 속도를 높이는 것도 중요하지만 ILP를 최대한 찾아내서 IPC(instructions per cycle)를 높이는 것도 중요하다라는 관점입니다. 전통적인 컴퓨터 아키텍트들이 선호하는 관점이기도 하지요. 제가 AMD를 더 선호하는 이유도 IPC의 관점에서 좋은 프로세서를 만든다는 점 때문입니다. (물론, 인텔도 아주 아주 뛰어납니다. 코어2듀오를 보십시오!)
마케팅의 관점에서�