Tag Archives: 마이크로 프로세서

참 파란만장합니다.

16 Replies

음.. 원래 잉걸에는 손을 대지 않는 것이 정답이긴 한데.. 답답하긴 답답하네요.

몇번 쓴적이 있습니다만.. 개인적으로 프로세서를 만들어 봐야겠다는 생각에 이 일에 전념해 온지도 상당한 시간이 흘렀고, 어느 정도 가시적인 성과를 거둔 것도 있습니다. 아직은 마케팅력에 문제와 ARM의 거대함을 절감하고 있는 중이라는 것이 정답이겠지만.. 작은 회사에서 프로세서라는 하기 힘든 아이템을 가지고, 이만큼 버텨내면서 여기까지 온것이 자체도 대단하다고 생각하지요. 근데, 오늘 같은 일이 벌어지면, 제가 왜 프로세서를 했는지 참 의아합니다.

대중에게 잘 회자되지 않을 만한 무언가를 했다면 이슈화도 덜 되었을 것이고, 덜 힘들었을 것인데 말입니다.
예전에 회사에 좋지 않을 일이 있었을 때, 가장 먼저 나온 이야기가 “기술이 허깨비다”라는 말이지요. 그럼 제가 만든건 허깨비란 이야기지요 ^^; 뭐랄까요.. 많은 분들이 돈앞에서 이런 저런 이야기를 하는데, 그런 이야기를 보고 당시에 많은 엔지니어들이 회사를 떠났습니다. 자존심하나로 버티는 사람들이니까요.
이번에도 뭐 이런 저런 이야기 많습니다. 역시 또 나오는 이야기들 중의 하나가 “기술이 허깨비다”라는 이야기인데요.. 그 동안의 노력이 많은 분들의 말에 폄하되는 것이 참을 수 없군요. 여러 전문 위원들의 기술 평가 결과는 욕심 앞에서는 그냥 하나의 “글”일 뿐이고, 단지 뭔가 이유를 찾으려 하는 건 알고 있지만…
엔지니어로서 잘못이 있다면, ARM에 비하여 압도적인 performance를 내는 프로세서를 아직까지 만들지 못한 것이 잘못이겠지요. 이런 저런 말이 뭐가 필요하겠습니까.. ^^; 엔지니어는 기술로 자신을 나타내는 것이겠지요. Market 고려하지 않고 회사와 싸워서라도 제대로 하나 만들어야만 직성이 풀리겠습니다. 내년 9월 쯤을 기대해 주세요 

마이크로 프로세서가 나아가야 할 방향…

2 Replies

쓰고보니 상당히 거창한 제목입니다.
요즘 프로세서 로드맵 작성중이라는 말씀을 드렸는데, 회사에 중대한 일이 생겨서 전면적으로 홀드 상태입니다. 가용 자원이나 target이 약간 수정되어야 하니 말입니다.
그래도, 마이크로 프로세서가 나아가야 할 방향성은 크게 달라지지 않겠지요. 단지, 현재 상황에서는 targeting하기 어려울 것이라 생각했던 목표를 추가적으로 설정할 수 있게 되었다는 것이 중요하겠지요.


Energy Efficient

현재 microprocessor 개발에 있어서 ([wp]EISC[/wp]나 [wp]ARM[/wp]같은 embedded microprocessor에 한정하지 않더라도) 가장 중요한 목표가 무엇이겠습니까?
아마도 energy-efficient 가 아닐까 생각합니다.
생각보다 많은 분들이 저전력 (low power)프로세서와 에너지 효율이 높은(energy-efficient) 프로세서를 혼용하여 사용하시는데, 사실은 약간 차이가 있습니다.

아시다시피 전력은 소모되는 에너지를 단위 시간으로 나눈 것이지요.
에너지는 일량. 즉 어떤 일을 끝내는데 필요한 힘이라 보시면 되겠습니다.

Low Power와 energy-efficient가 어떻게 다른지 한번 간단한 예를 들어 봅시다.

A라는 프로세서는 123.exe라는 프로그램을 한번 처리하는데 10초가 걸리며 100mw의 전력을 소모하는 반면,
B라는 프로세서는 123.exe라는 프로그램을 한번 처리하는데 2초가 걸리며 200mw의 전력을 소모한다고 생각해 보죠.

어떤 프로세서가 energy-efficient하겠습니까? 당연히 B 프로세서입니다. 전력소모에 있어서는 A라는 프로세서가 더 저전력이지만 말입니다.
Energy 단위의 중요성은 “동일한 일”을 수행하는데 얼마나 적은 에너지를 소모하는냐를 따지는 척도이기 때문에, 단순히 단위 시간당 얼마나 적은 “전력”을 소모하느냐와는 약간 다르다고 생각하시면 됩니다.

다른 관점에서 전력은 power supply가 얼마나 전력을 공급해 줄 수 있느냐와 발열에 영향을 미칩니다. 그래서 desktop/server에서는 평균적인 전력 소모가 얼마나 되는지가 중요합니다.
이에 반하여 Energy는 동일 용량 battery로 얼마나 버틸 수 있느냐를 결정할 때 매우 중요한 요소입니다.
단, 아무리 energy efficient하더라도 전력 소모가 크다면 (예를 들어 C라는 프로세서가 123.exe를 처리하는데 0.0001초가 걸리고 30W가 소모된다고 예를 듭시다), battery를 사용하는 시장 자체에 진입이 불가능할 수도 있습니다. 그런 관점에서는 low power와 energy-efficient가 밀접한 관계가 있는 것이겠지요.

요즘에 low-power보다 energy-efficient가 중요시되는 중요한 이유중의 하나는 dynamic power management 기법의 적극적인 활용입니다. Dynamic power management 기법은 “사용하지 않을때는 해당 유닛에 공급되는 전력을 최소화 한다”라고 생각하시면 되는데, 저전력을 위하여 느릿 느릿 오랫동안 일을 지속하는 것 보다, 빠른 시간에 작업을 끝내고 전력 소모를 더이상 하지 않는 것이 좋다는 것이겠지요.
여담입니다만, Dynamic power consumption 기법이 활성화되지 않았다면, 사실 energy-efficient와 low power는 동일한 언어로 표현되지 않았을까.. 라는 생각도 해봅니다.

또 다른 관점에서…
Enenry-Efficient는 Hardware만의 문제가 아니라 Software도 같이 노력해야 하는 문제입니다. (물론, 저전력도 그렇습니다만) Energy란 “어떤 일”을 수행하는데 소모되는 시간이기 때문에, “어떤 일”을 빠르게 수행할 수 있도록 더 효율적인 코드를 만드는 책임이 소프트웨어에게 있는 것이지요.

프로그래머의 관점에서

프로세서를 사용하는 프로그래머에게는 약간 다른 관점이 있는데, 프로그래밍이 쉬워야 한다는 측면입니다.
프로세서 아키텍쳐는 벌써 dual core, quad core로 발전하고 있으며, GPU들도 programmable shader를 가지고 있으므로, 아키텍쳐적인 형태로 보았을 때는 heterogeneous multiprocessor의 형태를 이미 취하고 있다고 보셔도 됩니다.
문제는 프로그래머들은 아직 multiprocessor를 사용할 준비가 되어 있지 않다는 것입니다. Multiprocessor를 지원하는 OS와 compiler, library의 등장으로 물론 점점 multiprocessor를 효과적으로 사용해 나가는 상황이 되어가고 있는 것은 맞습니다만, 아직 프로그래머들이 multiprocessor가 제공하는 기능을 충분히 활용하고 있는 상태는 아닙니다.  
점차 나아지겠습니다만, 프로그래머의 역량 강화가 매우 시급한 상황입니다.

가상화 기술.. 왜 각광 받는가?

7 Replies

이 글은 MPR의 “gHOST in the machine”이라는 3주간의 연재 기사를 읽고 이를 토대로 “제 기억 남은 내용과 그 간의 어설픈 지식을 버무려” 쓴 글입니다. 관심 있으신 분은 microprocessor report를 보시는 것이 더 좋은 글을 읽으실 수 있습니다.

요즘 마이크로 프로세서에서는 “가상화(virtualization)”라는 기술이 각광받고 있습니다.
Intel도 AMD도 서로 앞을 다투어 “가상화” 가속 명령어라는 것을 대대적으로 홍보하고 있지요.
그럼.. 가상화 기술이 대관절 무엇이관대 이렇게도 세상을 시끄럽게 하는지 알아보도록 하겠습니다.

우선, 생각해볼 문제가 가상화란 것이 무엇인가 하는 점입니다.
가상화란 “A”라는 머신에 “B”라는 virtual machine을 구동시키는 것을 의미합니다. 근데, embedded 분야에 종사하시는 분은 상당히 익숙하실만한 Intel CPU상에서 ARM이나 MIPS cpu simulator가 구동되는것도 엄연히 virtual machine이 구동되는 것입니다. (사실 마음 같아서는 제가 만든 EISC processor simulator인 ESCAsim도 끼워 넣고 싶지만.. ^^; 사용해 보셨을 분이 극히 제한적이라.. 그래도 나름대로 uCLinux까지도 구동 가능한 simulator랍니다.). 또한, 일반적인 사용자분들께서도 JVM(Java Virtual Machine)에 익숙하실 것입니다.  즉, 가상화란 “특별한 기술”이 아니라는 거죠. 다른 프로세서의 “동작”을 모사하는 것은 범용 마이크로 프로세서에게 있어서는 큰 문제가 아니라는 것이죠.

제가 가상화 가속 기술들이 속속 소개 될때 가장 궁금했던 내용이 “왜 가상화 가속이 필요한가” 였습니다. 일반적으로 모든 프로세서에서 큰 어려움 없이 되는 것에 대한 가속이라.. 근데, 문제는 다른 것이더군요. 그리고, 이 문제가 multithread/multicore processor를 이끄는 힘 중에 하나가 됩니다. 흥미 진진하죠?

시간은 거슬러 소프트웨어 업계의 가장 변태적인(저는 가끔 천재적인 = 변태적인으로 인식하게 되더군요..) 소프트웨중의 하나인 “VMWare”가 나타납니다. VMWare는 Virtual machine인데, 해당 프로세서뿐 아니라 해당 시스템에 있는 모든 시스템을 가상화시킨 하나의 독립적인 “시스템”으로서의 가치가 있습니다.

이 각각의 독립적인 가상 시스템에서 서버를 운용한다면 어떻게 될까요?
하나의 머신에서 A,B,C라는 세 개의 서버가 운용되고, A라는 머신에 문제가 발생해도 B, C라는 머신은 문제 없이 수행되겠지요? 즉, 안정성의 문제가 향상되고.. OS 하나가 만들어 낼 수 있는 thread보다 OS 세 개가 만들어내는 thread가 당연히 많고 parallelism도 높겠지요. 즉, multiprocessing/multithreading에 유리한 환경이 됩니다.
이 부분이 가상화 기술이 multicore/multithreading의 기치를 높이 들고 있는 현재의 microprocessor에게 있어서 병렬성의 문제를 확보할 수 있는 아주 좋은 수단으로 여겨지게 되는 것입니다.

그런데, 문제는 각 가상 시스템이 host OS의 application이라는 점입니다. 즉, host OS에 문제가 발생하면 전체 가상 시스템에 문제가 발생한다는 문제점이 있는거죠. 이 문제는 아주 치명적입니다. 여러 개의 가상 시스템이 한번에 모두 죽어버릴 수 있는 여지가 있는 것이니까요.

이 문제를 해결하고자 하는 방법이 기존의 user/supervisor 모델에 hypervisor라는 권한(혹은 권한 수준)을 추가하는 것입니다. 즉, 예전에는 O/S가 모든 하드웨어나 서비스에 접근했는데, 이중에 민감한 부분은 hypervisor(혹은 virtual machine manager)라는 firmware가 서비스를 담당하고, 그 위에서 각 OS(실은 VM이겠죠?)들이 도는 구조로 바뀌는 거죠.
예전에 application이 OS에 종속되고, OS가 다시 hyperviosr에 종속되면서 점점 하드웨어에 직접 접근해서 시스템 전체를 불안하게 만드는 것이 허용되지 않게 되는 것입니다.

가상화 “가속” 기술이란 말하자면, 이런 hypervisor를 추가하여 운용할 수 있도록 하는 명령을 추가하는 것으로 보시면 되겠습니다. Microprocessor report상에서는 각 프로세서간의 차이점등 아주 재미있는 내용이 많으니, 관심있으신 분은 꼭 보세요 🙂 (이 부분도 포스팅 하고 싶습니다만, 좀 내용이 너무 전문적일지도 모른다는 생각에.. 혹시라도 요청이 있다면 고려하겠습니다)