Multi-Processors.... amdahl's law

Multi-Processors.... | Technology 2006/03/21 15:28  


http://blog.naver.com/cyberyanne/40022898771


Silicon Transistor 기술은 거의 한계에 다다르고 있다. Clock Speed를 높여서 성능의 향상을 얻는 것은 예전처럼 용이하지 않은 것으로 보인다. (INTEL은 4GHz의 벽을 넘지 못하고 있다.) 이미 주요 마이크로프로세서 업체들은 Multi-Core Processor로 접근 방향을 튼지 오래다. AMD는 Dual-Core Opteron을 발표하였으며, INTEL은 Notebook을 겨냥하여 Core-Duo를 발표하였다. 그리고 Multi-Core 추세는 계속 이어질 전망이다. Multi-Processing은 System의 전체적인 성능(Throughput)을 향상시키지만, Peak Performance를 향상시키지는 않는다. 따라서 Game과 같이 Peak Performance가 중요한 애플리케이션에서는 크게 이득이 되지 않을 것이다. 하지만, 동시에 여러개의 작업을 수행하는 Server Application의 경우는 Multi-Processing을 통해 성능의 향상을 얻을 수 있다. (Processor 수를 늘린다고, 그에 비례하여 성능이 향상되는 것은 아니다. 왜냐하면 Processor간 통신에 사용되는 Overhead, Cache의 사용율, 메모리 버스에서의 충돌 등이 성능을 오히려 저해할 수도 있기 때문이다.) 어쨌든, Multi-Processor는 대세가 되었다. 이는 2개의 Core에서 시작해서 4개, 8개, 16개 등으로 점차 늘어날 것이다.



Multi-Processor 구조는 같은 코어를 여러개 사용하는 Homogeneous Multi-processing과 다른 종류의 코어를 연결한  Heterogeneous Multi-processing으로 나누어 생각할 수 있다. 전자의 경우는 Opteron이나 Core-Duo같은 프로세서들이 해당하고, 후자의 예로는 IBM의 Cell 프로세서를 들 수 있다. Cell은 1개의 PowerPC Core와 8개의 DSP Core가 집적된 프로세서이다. 일반적으로 PowerPC와 같은 RISC 코어는 전체 시스템 제어에 주로 사용되며, DSP는 수치 연산에 특화되어 사용된다. Multi-Processor Architecture가 대중화 되면 이제 남은 문제는 이 아키텍쳐에 적합한 S/W를 작성하는 일이다. 기존의 S/W를 Multi-Processor에 맞게 변환하는 작업이나, 혹은 새로 Multi-Processor용 S/W를 작성하는 일이 모두 포함된다. 이것은 쉽게 해결하기 어려운 문제이다. Multi-Processor에서는 Multi-Thread 기반의 프로그래밍이 일반화 될텐데, 다들 알고 있듯이 Multi-Thread Application을 디버깅하는 것은 매우 어렵다. 왜냐하면 한번에 여러 개의 작업이 수행되고, 이들 사이에 연관성이 생기기 때문이다. 게다가, 모든 문제들이 Multi-Processor를 이용한다고 성능이 향상되는 것은 아니다. 문제가 비슷한 형태의 Sub-Problem으로 분할이 가능한 경우에는 Multi-Processor Architecture를 통해 성능의 향상을 얻을 수 있다. 하지만, 이것이 불가능한 경우에는 Processor를 여러 개 써도 성능에는 별 차이가 없게 된다.



따라서, Multi-Processor 환경에서 고민해야 하는 문제는 다음과 같이 정리할 수 있다.


1) 해결해야 하는 문제를 sub-problem으로 분할할 수 있는가? 아니면 Thread Group으로 구현하였을 때, 성능의 향상을 가져올 가능성이 있는가를 확인하는 일이다. (Amdahl's Law, Gustafson's Law 참조!) --> 프로그램은 Sequential 부분과 Parallel 부분으로 구분할 수 있다. Sequential 부분은 반드시 순차적으로 수행되어야 하므로, 프로세서 수에 상관없이 수행 시간이 동일하다. Parallel 부분은 병렬 수행이 가능하므로, 프로세서의 수가 많을 수록 이득을 얻을 수 있다. 예를 들어, 어떤 프로그램의 Sequential 부분이 50%라면, 프로세서 수가 아무리 늘어나도, 2배 이상의 성능향상은 불가능하다는 말이다. 즉, 10초 걸리는 작업을 줄이고 줄여도 5초까지 밖에 안된다. 기존의 S/W를 Multi-Processor Architecture로 재작성/변환하는 경우, Sequential 부분과 Parallel 부분의 확인이 먼저 선행되어야 한다. (이득을 얻을 수 있는가?)



2) Programmer가 일일이 작업을 분할하고, 작업이 수행될 Processor를 지정해 주는 것은 번거롭다. 프로그래머는 하나의 통일된 방법을 사용하여 S/W를 작성하고, 자동화 툴이 프로그램을 분석하여 프로그램을 적절히 분할하고, 병렬화 하며, 해당 부분을 적합한 프로세서에 매핑할 필요가 있다. (말은 쉽지만, 매우 어려운 작업이다.) 과거에 수행되었던 Parallel Compiler 기술들이 여기에서 빛을 발할 수 있다. 소스 코드 레벨에서 변환이 수행될 수도 있고, IR 레벨에서 변환이 수행될 수 있다. IBM의 Octopiler Project가 이런 목표를 지향하고 있다. Cell Processor에 좀 더 쉽게 프로그래밍을 할 수 있도록 하기 위함.



3) 프로그래머가 좀 더 쉽게 Multi-Threaded S/W를 개발할 수 있는 환경이 필요. Graphical Language, 4GL(Script like), 다중 실행 경로를 추적할 수 있는 디버깅 환경. 등등..