쓰고보니 상당히 거창한 제목입니다.
요즘 프로세서 로드맵 작성중이라는 말씀을 드렸는데, 회사에 중대한 일이 생겨서 전면적으로 홀드 상태입니다. 가용 자원이나 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가 제공하는 기능을 충분히 활용하고 있는 상태는 아닙니다.
점차 나아지겠습니다만, 프로그래머의 역량 강화가 매우 시급한 상황입니다.
저도 energy efficient한 프로세서를 연구하고 있습니다.
Multicore, heterogeneous multiprocessor와 같은 구조는 energy efficient와 다른 개념이지만
요즘엔 워낙 같이 나올 때가 많기 때문에 따로 떼어놓고 생각하기 힘들죠. (그래서 프로그래머를 언급하셨구요.)
소프트웨어의 입장에서 현재의 thread programming 패러다임에 근본적으로 문제가 있다는 인식이 널리 퍼지고 있는게 사실입니다. 인텔에서 대학마다 multicore 프로그래밍에 대한 강의를 지원하고 많은 돈을 쏟아부었지만 그렇게 큰 효과를 보지 못한 것도 그렇고, 버클리 Ptolemy 시뮬레이터와 같이 십년 동안 디버깅했는데도 순식간에 뻗어버릴 수도 있다는 것도 그런 예지요. 그래서 작년에 Edward Lee 교수가 IEEE Computer에 기고한 “The Problem with Threads”라는 글이 큰 반향을 일으켰던 것이구요.
회사에서 16코어 네트워크프로세서를 써서 시스템을 개발해야 했었는데 소프트웨어개발자에게는 재앙과도 같은 일이었습니다. 이식성은 무조건 포기고 효율적은 커녕 functionally correct하게 만드는 일도 큰 일이었죠.
말이 길어졌는데, 현재 이 분야에서 하드웨어의 성능이 급속히 증가하고 있다고 무조건 좋아할 일은 아닌 것 같습니다. 개인적인 의견으로 이런 점이 하드웨어-oriented 아키텍트들이 가장 빠지기 쉬운 함정이 아닌가 하는 생각입니다.
아.. network processor쪽은 워낙에 multicore들이 많죠.
Sequential하게 작성된 프로그램을 multi processor 환경에 맞게 compile해주거나 job assign하는 일은 기본적으로 만만치 않은 테마인 것으로 알고 있습니다.
그렇다고 프로그래머가 parallism을 잘 살려서 프로그램을 짜는 일은 매우 고통스러운 일이지요.. 저의 경우 그야말로 취미 수준에서 MPI를 다루어 보았습니다만, 아주 고통이었습니다. ^^;
Multiprocessor 환경에서는 프로그래머, 컴파일러, 운영체제, 프로세서 모두가 서로 다른 level의 정보를 hint로 사용해야만 원하는 성능을 얻을 수 있지 않을까 생각합니다. 모두에게 전향적인 시선을 요구하는 것이지요. 🙂