Tag Archives: 멀티프로세서

PeakStream: GPU를 이용한 범용 수치연산!

MPR 10/2일자에 PeakStream이라는 재미있는 라이브러리(플랫폼?)에 대한 내용이 있어서 좀 살펴봤습니다.
PeakStream이라는 회사의 플랫폼은 GPU를 이용하여 범용 수치 연산을 하기 위한 여러가지 방법(API)을 제공하는 것인데요.. 상당히 재미있습니다.

다음 그림은 peakstream의 아키텍쳐를 보여주는데, 간단히 설명드리자면 연산량이 많은 응용분야에서 peakstream의 API를 써서 프로그래밍하고, 이것이 현존하는 GPU에 연산기능을 mapping해서 병렬 연산을 한다는 구조입니다.

”]현재 가장 빠른 GPU의 경우 가장 빠른 dual core x86 CPU보다 7배 이상의 부동 소수점 연산 성능을 지니고 있는 괴물이라고 합니다[출처: MPR 06/10/2]. 게다가 peakstream 백서에서는 그 격차가 매년 2배씩 벌어지고 있다고 합니다. peakstream은 다양한 부동 소수점 연산에 GPU의 성능을 쓰자는 아이디어를 구체화시킨것이라 할 수 있습니다.

Today, the CPU with the best floating point performance is the dual-core Intel Xeon 5160 which offers 48 gflops of single precision floating point performance. In contrast, the commodity high-end  GPU offers 360 gflops of single precision floating-point performance  and more than 50 GBytes/s of bandwidth to local memory. The computational performance growth rate for GPUs over the last few years has exceeded 2x per year. [Hanrahan05]

사실, Nvidia에서는 강력한 쉐이더를 이용해서, 물리 연산을 하는 방법을 제시하고 있으니 아주 새로운 아이디어는 아닙니다만, 쓰기가 쉽지만은 않습니다.
하지만, (예제로 나온)peakstream 코딩은 단지 기존의 부동 소수점 연산을 단지 해당 API에서 제공하는 연산 함수로만 바꾼듯 한 모습을 지닙니다. 즉, 포팅이 아주 쉽다는 것이지요. 지원하는 컴파일러도 GCC, intel compiler, matlab과 같이 많이 사용하는 환경에서는 모두 가능하고 말입니다.

아직까지는  ATI R580 프로세서(X1900 series라네요)만 지원하고 있으며, 하나의 프로세서만(즉, cross-fire 환경을 지원못한다는 말이죠) 사용할 수 있는데, 이 회사가 만들어진것이 2005년 2월, 수면 위로 떠오른것이 2006년 9월이니 이후의 일들을 더 기대해도 될 것 같습니다.

제가 얼마전에 멀티프로세서 환경에서 소프트웨어가 중요하다는 글을 쓴적이 있는데, 소프트웨어 부분에서도 분발하고 있군요.

p.s. 오랫만에 11시 이전에 집에 온 기념 포스팅입니다. ㅠㅠ;

듀얼코어? 쿼드코어?

요즘 들어 듀얼 코어가 일반화되었습니다.
AMD의 X2시리즈를 필두로 데스크탑 시장을 열기 시작하더니, 인텔의 코어듀오시리즈가 이제 본격적으로 어필하고 있는 상황입니다.
AMD는 예전부터 2007년 2분기에 Quad Core를 예정하고 있었고, 얼마전에 인텔 개발자 포럼(IDF)에서 인텔 콘로 쿼드 코어가 2007년 1분기에 출시된다고 선언한적이 있습니다. 그 발언과 더불어 쿼드코어가 네티즌들에게 많이 이야기가 되고 있구요..
”]
쿼드 코어가 기술적인 혁신인가?
간혹 이야기를 보다보면, 쿼드 코어가 대단한 기술적 혁신으로 받아들이는 경우가 있는데.. 사실은 아닙니다. 단지 마케팅적인 요소이지요. 사실 온칩 멀티프로세서(CMP)라 불리는 기술은 최소한 10년이상된 기술입니다. 제가 석사과정에서 했던 일도 네개의 정수코어와 한개의 그래픽 코프로세서를 통합하는 프로젝트였으니까요.. (벌써 8년전일이니.. 오래된 일이죠? 외국에서는 훨씬 오래전부터 시작되었습니다.)
사실 더 깊고 넓은 파이프 라인을 만드는 것 보다, 여러개의 코어를 하나의 칩에 통합하는 칩 멀티프로세서 기법이 기술적으로는 좀더 편한 방법입니다.

왜 지금까지 널리 사용되지 않았을까요?
바로, 데스크탑 시장에서는 멀티 프로세서를 사용할 수 있는 소프트웨어가 거의 없었기 때문입니다.
멀티 프로세서를 지원하는 윈도우 데스크탑 OS는 아마도 XP가 최초인 것으로 기억합니다. (NT/2000은 서버/웍스테이션 급이죠?)
멀티 프로세서 OS라고 해도, 프로세스 수준의 멀티 프로세싱을 지원하겠지만.. 데스크탑에서 사용할 수 있는 병렬성은 빤한 수준입니다. 한마디로 그다지 이득이 없다는 겁니다.

차라리, 클럭 주파수를 올리는 것이 수많은 어플리케이션(소위 벤치마크라 이야기되는 부분)에서 사용자에게 어필할 수 있었습니다.

이제는 왜 칩 멀티프로세서가 각광 받을까요?
바로, 주파수 올리기가 어느정도 한계에 도달했기 때문입니다. 주파수 올리기는 필수적으로 전력소모의 증가를 부릅니다. 깊은 파이프라인은 파이프의 효율성을 떨어트리구요..그래서, 대안으로 칩 멀티프로세서가 유용한 “마케팅” 용어로 사용되는 것 같습니다.
또 한가지 중요한 요인은 멀티프로세서를 사용할 여지가 많은 어플리케이션 “멀티미디어”, “게임”이 점점 더 일반화 되고 있다는 점입니다. (물론, 이 분야의 모든 어플리케이션이 멀티 프로세서에서 위력을 발휘하는 것이 아닙니다.멀티프로세서를 위해서 프로그래밍 된 넘들만 힘을 활용할 수 있습니다.)
즉, 사용자들이 알만한 어플리케이션에서 더 좋은 벤치마크 성능을 보여줄 수 있는 시기가 왔다는 점이겠죠.

소프트웨어가 멀티 프로세서 환경을 결정할 것이다.
궁극적으로는 멀티 프로세서 환경의 구축은 피할 수 없는 조류가 되었습니다. 이 이야기는 사실 70-80년대 부터 나오던 이야기입니다.
하지만, 지금 이 시간까지 멀티프로세서가 힘을 발휘할 수 없었던 가장 큰 이유는 “소프트웨어”의 문제입니다.
프로그래머는 기본적으로 “순차적인”알고리즘에 익숙하고, 순차적인 프로그램을 작성합니다.
예를들어 어떤 연산을 하고, 그 결과를 이용해서 분기하여 계산할 것을 결정하는 등의 알고리즘이죠..
이런 순차적인 알고리즘은 이전의 연산/작업이 뒤의 연산/작업에 상당한 의존성(dependency)를 보여주기 때문에 병렬작업이 거의 불가능합니다. 즉, 멀티 프로세서를 사용하더라도, 절대 이것을 사용할 수 없는 것입니다.

멀티미디어 분야에서는 약간 이야기가 달라지는데요.. 각 픽셀에 대한 연산을 병렬적으로 수행할 수 있는 요소가 많아집니다. 즉, 일반적인 프로그램보다는 병렬성의 가능성이 더 높다는 것이죠.. (데이터 형태에서..)
물론, 프로그래머가 병렬성을 살리지 못하면 여전히 멀티 프로세서에서 좋은 결과를 기대할 수 없겠지만 말입니다.

멀티프로세서 환경은 데스크탑 환경에서도 피할수 없는 조류로 자리잡았습니다.
이제, 공은 OS/Compiler/프로그래머에게 넘어갔습니다.