http://babyworm.net/tatter/ 프로세서, SoC, ASIC 설계에 대한 재미난 이야기들. 그리고, 쉼표... ko Thu, 3 Jul 2008 13:50:25 +0900 Textcube 1.6.2 : Arpeggio http://babyworm.net/tatter/attach/1/1116260898.jpg http://babyworm.net/tatter/ 140 134 프로세서, SoC, ASIC 설계에 대한 재미난 이야기들. 그리고, 쉼표... http://babyworm.net/tatter/181#comment376 저도 energy efficient한 프로세서를 연구하고 있습니다. Multicore, heterogeneous multiprocessor와 같은 구조는 energy efficient와 다른 개념이지만 요즘엔 워낙 같이 나올 때가 많기 때문에 따로 떼어놓고 생각하기 힘들죠. (그래서 프로그래머를 언급하셨구요.) 소프트웨어의 입장에서 현재의 thread programming 패러다임에 근본적으로 문제가 있다는 인식이 널리 퍼지고 있는게 사실입니다. 인텔에서 대학마다 multicore 프로그래밍에 대한 강의를 지원하고 많은 돈을 쏟아부었지만 그렇게 큰 효과를 보지 못한 것도 그렇고, 버클리 Ptolemy 시뮬레이터와 같이 십년 동안 디버깅했는데도 순식간에 뻗어버릴 수도 있다는 것도 그런 예지요. 그래서 작년에 Edward Lee 교수가 IEEE Computer에 기고한 "The Problem with Threads"라는 글이 큰 반향을 일으켰던 것이구요. 회사에서 16코어 네트워크프로세서를 써서 시스템을 개발해야 했었는데 소프트웨어개발자에게는 재앙과도 같은 일이었습니다. 이식성은 무조건 포기고 효율적은 커녕 functionally correct하게 만드는 일도 큰 일이었죠. 말이 길어졌는데, 현재 이 분야에서 하드웨어의 성능이 급속히 증가하고 있다고 무조건 좋아할 일은 아닌 것 같습니다. 개인적인 의견으로 이런 점이 하드웨어-oriented 아키텍트들이 가장 빠지기 쉬운 함정이 아닌가 하는 생각입니다. (내가그린) http://babyworm.net/tatter/181#comment376 http://babyworm.net/tatter/181#comment Sat, 23 Jun 2007 23:09:46 +0900 http://babyworm.net/tatter/181#comment378 아.. network processor쪽은 워낙에 multicore들이 많죠. Sequential하게 작성된 프로그램을 multi processor 환경에 맞게 compile해주거나 job assign하는 일은 기본적으로 만만치 않은 테마인 것으로 알고 있습니다. 그렇다고 프로그래머가 parallism을 잘 살려서 프로그램을 짜는 일은 매우 고통스러운 일이지요.. 저의 경우 그야말로 취미 수준에서 MPI를 다루어 보았습니다만, 아주 고통이었습니다. ^^; Multiprocessor 환경에서는 프로그래머, 컴파일러, 운영체제, 프로세서 모두가 서로 다른 level의 정보를 hint로 사용해야만 원하는 성능을 얻을 수 있지 않을까 생각합니다. 모두에게 전향적인 시선을 요구하는 것이지요. :) (babyworm) http://babyworm.net/tatter/181#comment378 http://babyworm.net/tatter/181#comment Mon, 25 Jun 2007 13:49:30 +0900