KR101745392B1 - 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체 - Google Patents

Abstract

병렬 처리 프로그램을 정형화된 태스크 그래프로 변환하고, 변환된 태스크 그래프로부터 병렬 처리 프로그램의 분석이 가능하도록 하는, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체에 관한 것이다.
본 발명인, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체를 사용함으로써, 복수의 프로세서에서 실행될 수 있는 병렬 처리 프로그램에서 야기될 수 있는 다양한 문제점을 정적 분석을 통해 찾을 수 있도록 하는 장점이 있다.

Description

프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체{PROGRAM ANALYZING DEVICE AND COMPUTER READBLE RECORDING MEDIUM RECORDING ANALYZING PROGRAM}

본 발명은 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체에 관한 것으로서, 구체적으로는 병렬 처리 프로그램을 정형화된 태스크 그래프로 변환하고, 변환된 태스크 그래프로부터 병렬 처리 프로그램의 분석이 가능하도록 하는, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체에 관한 것이다.

병렬 처리 프로그램(parallel program)은 경쟁 상태(race condition)이나 데드락(deadlock)과 같은 동기화 에러에 취약하기에, 병렬 처리 프로그램을 작성하는데 상당한 어려움과 개발상 디버깅을 하는데 어려움을 가지고 있다.

이에 따라 병렬 처리 프로그램을 분석하고 이해하는 것이 중요한 문제가 되고 이러한 문제점을 해소하기 위해서 정적으로(static) 혹은 동적으로(dynamic) 분석하는 여러 가지 툴(tool)이나 방법론 등이 개발되었다.

예를 들어, 인텔 등에서 개발한 CPU는 복수개의 프로세서 코어를 포함하여, 프로그램의 수행 성능을 향상시키고 있고, 또한 엔비디아(NVidia) 등에서는 복수의 프로세서 코어를 가지는 GPU(General Processing Unit)의 제공과 함께, CUDA(Compute Unified Device Architecture, J. Nickolls, J. Nickolls, I. Buck, M. Garland, K. Skadron, Scalable Parallel Programming with CUDA," ACM Queue, vol. 6, no. 2, Mar./Apr. 2008, pp. 40-53, 참조)라는 개발 환경을 제공하여, CPU와 GPU의 결합으로 프로그램의 속도 향상을 할 수 있도록 한다.

여기서 GPU는 , 커널(kernel)이라고 불리는 복수의 CUDA 쓰레드(thread)를 실행할 수 있고, 이러한 커널은 인텔 CPU와 같은 호스트 CPU에 의해서 호출된다. 그리고 CUDA에서는 독립적으로 처리될 수 있는 다수의 커널을 생성할 수 있고, 이러한 커널은 GPU 상의 메모리와 프로세서들을 이용해서 실행되게 된다.

또한 CUDA 개발 환경은 비동기 방식의 동작을 비동기 API를 사용하여 지원하며, 호스트 CPU와 GPU를 포함하는 이종 아키텍처와 분리된 메모리를 가정한다.

그리고 CUDA 개발 환경상에서, 병렬로 처리할 수 있도록 하는, GPU를 위한 다양한 쓰레드(thread)를 제공한다.

CUDA와 같은 개발 환경에서 프로그램의 개발은 앞서 문제점에서 지적한 바와 같이 많은 어려움에 봉착하게 된다. 왜냐하면, CUDA가 지원하는 이종 아키텍처 상에서 속도 향상을 위해 비동기 API를 사용하는 경우에, 프로그램의 속도 분석, 쓰페드 간의 데이터 송수신 패턴 분석, 프로그램상의 병목지점(bottleneck)의 결정, 경쟁 상태가 있는지의 결정 등이 용이하지 않기 때문이다. 이러한 문제점은 비동기 API를 사용하는 경우에는 해당 API는 단지 호출 후에 바로 반환(return)하여, 언제 끝날지를 예상하기 힘들어 더욱 어려워지게 된다. 더욱이 쓰레드 간에 송수신 되는 데이터를 일반적으로 사용되는 공유 메모리(shared memory)를 이용하는 경우에는, 이 공유 메모리 상에서 야기될 수 있는 여러 가지 문제로 병렬 처리 프로그램의 개발이 더욱더 어려워지게 된다.

이와 같이, 복수의 프로세서를 이용해서 프로그램을 개발하는 것은 더 이상 옵션이 아니며 속도 향상을 위해선 이미 제공된 하드웨어 환경상에서 병렬로 처리하는 프로그램을 제작 및 공급하는 것이 필수 불가결하게 되었다.

한편, 몇몇 문헌(V. Adve, M. Vernon, "parallel program performance prediction using deterministic task graph analysis" ACM Transactions on Computer Systems, vol. 22. no. 1, Feb. 2004, Q. Li, Y. Ruan, ShidaYang, and T. Jiang, "An optimal scheduling algorithm for fork-join task graphs", Parallel and Distributed Computing, Applications and Technologies, pp. 587-589, Aug. 2003, 참조)에서는 병렬 처리 프로그램을 위한 정적 분석 방법을 제시하였다. 이러한 정적 분석 방법은 포크-조인(fork-join) 태스크 그래프를 이용해서 이종 아키텍처 상에서의 멀티 쓰레드 프로그램을 분석한다. 이러한 분석 방법은 데이터의 병렬 처리에서 프로그램의 지연(latency) 시간에 초점을 맞추었다.

하지만 이러한 문헌들은 포크-조인 태스크 그래프를 사용하나, 일반적으로 사용되어지는 공유 메모리를 사용하는 경우에 멀티 쓰레드 프로그램의 분석을 제공하지는 못하는 문제점이 있다.

또한 알려진 툴(Intel Inspector XE, http://software.intel.com/en-us/articles/intel-inspector-xe/)은 멀티 쓰레드 프로그램을 검증할 수 있도록 하나, 프로그램의 성능을 예측하지 못하는 문제점이 있다.

따라서, 이종 아키텍처 상에서 수행되는 병렬 처리 프로그램의 성능을 예측할 수 있고, 문제점을 분석할 수 있는 새로운 방식의 프로그램 분석 장치 및 새로운 방식을 포함하는 프로그램 저장 매체가 필요하다.

본 발명은 상술한 문제점을 해결하기 위해서 안출한 것으로서, 병렬 처리 프로그램의 정적 분석을 통해, 병렬 처리 프로그램의 성능 측정 및, 경쟁 상태, 병목 지점을 검출할 수 있도록 하는, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체를 제공하는데 그 목적이 있다.

또한 본 발명은, 포크-조인 모델과는 상이한 정형화된 데이터-플로우 모델을 이용하여, 병렬 처리 프로그램의 성능을 측정하고, 병렬 처리 프로그램을 분석할 수 있도록 하는, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체를 제공하는데 그 목적이 있다.

또한 본 발명은, 이종 아키텍처 상에서, 공유 메모리를 이용하는 병렬 처리 프로그램을 분석하고 성능을 측정할 수 있도록 하는, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체를 제공하는데 그 목적이 있다.

본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

상기와 같은 목적을 달성하기 위한, 프로그램 분석 장치는, 프로그램 코드를 수신하는 프로그램 수신부와 수신된 프로그램 코드로부터 태스크 그래프를 생성하는 태스크 그래프 생성부와 태스크 그래프의 분석을 위해, 태스크 그래프를 시뮬레이션(Simulation)하는 시뮬레이션부를 포함하며, 태스크 그래프는, 하나 이상의 노드(node)와 하나 이상의 에지(edge)를 포함하고, 에지는 3 개 이상의 에지 타입 중 하나인 것을 특징으로 한다.

또한 상기와 같은 목적을 달성하기 위한, 프로그램을 기록한 컴퓨터 판독 가능한 저장매체는, 프로그램 코드를 수신하는 프로그램 수신 수단과 수신된 프로그램 코드로부터 태스크 그래프를 생성하는 태스크 그래프 생성 수단과 태스크 그래프의 분석을 위해, 태스크 그래프를 시뮬레이션(Simulation)하는 시뮬레이션 수단을 실행하는 프로그램을 포함하고, 태스크 그래프는, 하나 이상의 노드(node)와 하나 이상의 에지(edge)를 포함하고, 에지는 3 개 이상의 에지 타입 중 하나인 것을 특징으로 한다.

상기와 같은 본 발명에 따른, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체는, 병렬 처리 프로그램의 정적 분석을 통해, 병렬 처리 프로그램의 성능 측정 및, 데이터 경쟁 여부, 병목 지점을 검출할 수 있도록 하고 최적의 (공유) 메모리 크기와 최적의 아키텍처와 아키텍처에 최적의 태스크 맵핑(분배)을 결정할 수 있도록 하는 장점이 있다.

또한 상기와 같은 본 발명에 따른, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체는, 포크-조인 모델과는 상이한 정형화된 데이터-플로우 모델을 이용하여, 병렬 처리 프로그램의 성능을 측정하고, 병렬 처리 프로그램을 분석할 수 있도록 하는, 장점이 있다.

또한 상기와 같은 본 발명에 따른, 프로그램 분석 장치 및 분석용 프로그램을 기록한 컴퓨터 판독 가능한 저장매체는, 이종 아키텍처 상에서, 공유 메모리를 이용하는 병렬 처리 프로그램을 분석하고 성능을 측정할 수 있도록 하는, 장점이 있다.

본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

도 1은 본 발명인 프로그램 분석 장치의 블록도의 일 실시예를 도시한 도면이다.
도 2는, 프로그램 수신부에서 수신할 수 있는 프로그램 코드의 예시적인 실시예를 도시한 도면이다.
도 3은, 프로그램 수신부로부터 수신한 프로그램 코드로부터 생성된 태스크 그래프의 예시적인 실시예를 도시한 도면이다.
도 4는, 도 3의 태스크 그래프에 초기 토큰을 삽입한 그래프이다.
도 5는, 시뮬레이션부가 시뮬레이션을 위해 실행하는 슈도 코드(Pseudo code)를 나타낸다.
도 6은, 태스크 그래프 생성부와 시뮬레이션부를 이용한 응용 사례를 위한 매트릭스 곱셈을 위한 기능 블록도를 도시한 도면이다.
도 7은, 도 6의 응용 사례에 대해서 스트림이 각각 하나, 두 개인 경우의 초기 토큰을 포함하는 태스크 그래프를 도시한 도면이다.
도 8은, 도 7의 태스크 그래프를 이용하여 시뮬레이션 한 결과를 스케줄 다이어그램으로 도시한 도면이다.

상술한 목적, 특징 및 장점은 첨부된 도면을 참조하여 상세하게 후술 되어 있는 상세한 설명을 통하여 더욱 명확해 질 것이며, 그에 따라 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명의 기술적 사상을 용이하게 실시할 수 있을 것이다. 또한, 본 발명을 설명함에 있어서 본 발명과 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에 그 상세한 설명을 생략하기로 한다. 이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시 예를 상세히 설명하기로 한다.

도 1은 본 발명인 프로그램 분석 장치의 블록도의 일 실시예를 도시한 도면이다. 도 1 에 따르면 프로그램 분석 장치는 프로그램 수신부(110), 파라미터 수신부(120), 태스크 그래프 생성부(130), 및 시뮬레이션부(140)를 포함한다.

이러한 프로그램 분석 장치는 특정 하드웨어 장치상에서 구현될 수 있고 예를 들어 특정 하드웨어 장치상에서 프로그램의 형태로 구성되어 특정 하드웨어 장치의 프로세서(210)에 의해서 구동될 수 있다.

예를 들어 특정 하드웨어 장치는, 프로그램을 구동할 수 있는 하나 이상의 프로세서(210)와, 프로그램을 저장할 수 있는 메모리(220), 사용자로부터 키보드 및/또는 마우스 등과 같은 입력 유닛으로부터 사용자의 명령을 수신할 수 있는 사용자 입력부(230), 사용자에게 프로그램 분석의 결과를 디스플레이하고 사용자에게 명령을 가이드할 수 있도록 하는, 예를 들어 LCD 모니터, 디스플레이부(240)를 포함한다.

이러한 특정 하드웨어 장치는, 컴퓨터, 노트북, 네트워크상에 연결된 서버, 혹은 전용의 셋탑 박스일 수 있다.

그리고 이러한 프로그램 분석 장치는, CD나 DVD, 플로피 디스크, USB 메모리 등과 같은 저장 매체에 프로그램의 형태로 저장될 수 있다. 이하에서는 프로그램 분석 장치의 각 블록에 대해서 간단히 살펴보도록 한다.

프로그램 수신부(110)는, 사용자 입력부(230)와 디스플레이부(240)를 이용하여, 사용자로부터 프로그램 분석을 하고자 하는 프로그램 코드를 수신한다.

이러한 프로그램 코드는, 예를 들어 CUDA 개발 환경을 이용하여 개발된 프로그램 코드(C, C++ 언어를 이용한 확장 코드)일 수 있다. 이러한 프로그램 코드에는 다수의 병렬로 수행 가능한 쓰레드 코드를 포함할 수 있고, 쓰레드 간에 공유하여 데이터나 신호를 송수신할 수 있는 공유 버퍼나 혹은 변수를 포함할 수 있다.

이러한 공유할 수 있는 버퍼나 변수는 세마포어(Semaphore), 락(lock)과 같은 동기화 API 등을 이용하여 동기화될 수 있다.

태스크 그래프 생성부(130)는, 프로그램 수신부(110)로부터 수신된 하나 이상의 쓰레드 코드를 포함하는 프로그램 코드로부터 태스크 그래프를 생성한다. 이러한 태스크 그래프는 데이터-플로 그래프(Data-Flow Graph)의 형태를 띨 수 있다.

여기서 태스크 그래프 생성부(130)는, 동기 API나, 함수(예를 들어 쓰레드 함수나 커널 함수 등)를 식별할 수 있는 데이터 베이스 혹은 룩업(lookup) 테이블을 포함할 수 있다. 이러한 테이블(데이터 베이스)을 이용해서, 동기 API나 함수를 용이하게 식별할 수 있다.

태스크 그래프 생성부(130)는, 하나 이상의 쓰레드 코드로부터 노드와 에지를 생성한다. 여기서 노드는 실행가능한 태스크를 나타내고, 에지는 각 노드 간의 의존성을 나타낸다. 이러한 에지는 적어도 3가지 타입의 에지를 포함할 수 있다.

파라미터 수신부(120)는, 태스크 그래프 생성부(130)에서 생성된 태스크 그래프가 수행될 특정 하드웨어 아키텍처, 쓰레드의 개수, 에지 상에 할당할 수 있는 버퍼의 개수 등과 같은 태스크 그래프가 특정 아키텍처에서 프로그램 코드가 수행될 때 성능 등에 영향을 미치는 파라미터를 수신한다.

하드웨어 아키텍처는 태스크 그래프가 수행될 프로세서의 개수와, 해당 프로세서가 하나 이상의 프로세서 코어를 포함하는 경우에는 프로세서 코어의 개수를 포함한다.

예를 들어, 파라미터로 입력되는 하드웨어 아키텍처는, 인텔의 CPU와 같은 호스트 CPU와, 호스트 CPU와 PCI 버스를 통해 연결된, 복수의 프로세서를 포함하고, 각각의 복수의 프로세서는 다시 복수의 프로세서 코어를 포함하는 GPU 일 수 있다.

혹은 하드웨어 아키텍처는, 복수의 프로세서를 포함하고, 각 프로세서간에 공유 메모리를 사용할 수 있는 CPU 일 수 있다.

따라서, 이러한 하드웨어 아키텍처 상에서 실행될 때의 프로그램 코드의 성능 분석을 할 수 있다.

시뮬레이션부(140)는, 태스크 그래프 생성부(130)에서 생성된 태스크 그래프에 대해서, 파라미터 수신부(120)로부터 수신된 파라미터를 이용해서, 태스크 그래프를 시뮬레이션한다. 이러한 태스크 그래프의 시뮬레이션을 통해서, 프로그램 코드의 총 수행 시간, 태스크 그래프 상의 각 노드의 수행 시간과, 총 수행 시간에서의 각 노드의 점유 시간, 데드락(Deadlock) 발생 여부, 경쟁 상태(race condition)의 발생 여부를 결정할 수 있도록 한다.

이상의 도 1에서 각 기능 블록에 대해서 간단히 살펴보았다. 이하에서는 각 기능 블록에 대해서 예시적인 도면을 통해서 상세히 살펴보도록 한다.

도 2는, 프로그램 수신부(110)에서 수신할 수 있는 프로그램 코드의 예시적인 실시예를 도시한 도면이다.

도 2의 (a), (b), (c)와 같이, 프로그램 코드는 특정 프로그램 언어 혹은, 특정 하드웨어 아키텍처를 고려한 코드일 수 있다. 이러한 프로그램 코드는, C 언어나, 혹은 C 언어와 유사한 예를 들어 CUDA 프로그램 환경을 위한 코드(도 2의 (c) 참조) 일 수 있다.

프로그램 수신부(110)는 사용자의 선택에 따라, 프로그램 코드를 수신하고, 이를 태스크 그래프 생성부(130)에 전달한다.

도 3은, 프로그램 수신부(110)로부터 수신한 프로그램 코드로부터 생성부(130)에 의해 생성된 태스크 그래프의 예시적인 실시예를 도시한 도면이다.

이러한 도 3의 (a), (b), (c)는 태스크 그래프 생성부(130)에 의해서 생성할 수 있다.

태스크 그래프 생성부(130)에 대한 상세한 설명에 앞서, 태스크 그래프 생성부(130)에서 생성하는 정형화된 그래프 모델에 대해서 설명한다.

태스크 그래프 생성부(130)는 SDF(Synchoronous Data Flow) 그래프의 시멘틱(Semantic)을 기본적으로 따르며, SDF 그래프를 공유 메모리를 고려하여 확장한다.

기존의 SDF 그래프(E. A. Lee and D. G. Messerschmitt, "Static scheduling of synchronous data flow programs for digital signal processing",IEEE Trans. On Comp., vol. 36, no. 1, pp. 24-35, 1987, 참조)는 정형화된 모델링 그래프로서, SDF 그래프 상의 노드는 실행 태스크를 나타내고, 에지는 두 노드 간의 FIFO 통신 채널을 나타내며, SDF 그래프 상의 노드는 샘플 레이트라고 불리는 두 개의 숫자를 가진다.

두 개의 샘플 레이트 중 하나는, 해당 노드가 실행되기 위해서 필요한 입력 데이터(각 에지별로)의 개수를 나타내고, 나머지 하나는, 해당 노드가 실행된 후의 출력 데이터(각 에지별로)의 개수를 나타내며, 이러한 샘플 레이트는 미리 모델링 단계에서 정의되거나, 혹은 프로그램 코드의 분석을 통해서 결정될 수 있다.

이러한 기존의 SDF 그래프는, 에지가 데이터의 흐름만을 도시하여, 공유 메모리를 사용할 수 없고, 각각의 에지에 대해서 별도의 FIFO 만을 사용할 수 있을 뿐이다.

태스크 그래프 생성부(130)는 수신된 프로그램 코드로부터 태스크 그래프를 생성하기 위해서, 몇 가지 결정된 규칙에 따라, 수신된 프로그램 코드의 일부를 각각 노드로 할당하고, 각각의 노드 간의 몇 가지 의존성에 따라서, 노드 간의 에지를 삽입하여 태스크 그래프를 생성한다.

여기서 에지의 타입에는 3가지 이상이 있으며, 이 3가지 이상의 에지의 타입에 따른 연결 관계에 따라 공유 메모리(버퍼)를 이용할 수 있는지를 결정할 수 있다.

먼저, 노드를 분할하기 위한 규칙에는,

① 프로그램 코드에서 서로 상이한 쓰레드(thread)의 코드는 서로 상이한 노드에 할당된다.

② 할당된 노드 내의 코드에서 공유된 리소스에 대한 블록킹(blocking) 동작이 있는 경우, 상기 할당된 노드를 다시 두 개의 노드로 분할하고, 블록킹 동작은 분할된 두 개의 노드 중 두 번째 노드에 포함된다.

③ 할당된 노드 내의 코드에서 공유된 리소스에 대한 릴리스 동작이 있는 경우, 상기 할당된 노드를 다시 두 개의 노드로 분할하고 릴리스 동작은 분할된 두 개의 노드 중에 두 번째 노드에 포함된다.

상기와 같이 규칙 ① 내지 ③을 적용하여 프로그램 코드를 노드로 분할함으로써, 각각의 노드는 스케줄링에 따라 실행 가능할 때, 노드 내에서 블록킹 동작이 없는 상태에서 바로 실행할 수 있다.

즉 하나의 노드가 스케줄링이 되면, 해당 노드는 단일 실행 단위로 실행된다.

예를 들어 블록킹 동작을 포함하는 노드는, 규칙 ②에 따라, 이미 노드의 입력 에지를 통해서 입력 데이터가 이용 가능할 때만 실행될 수 있도록 구성하므로, 블록킹 동작을 포함하는 노드가 스케줄링 되어 실행시에는 바로 실행할 수 있다. 따라서, 상기와 같은 규칙으로, 각각의 노드는 시뮬레이션부(140)에 의한 시뮬레이션시에(예, 스케쥴링) 하나의 실행 유닛으로 동작하게 된다.

여기서, 릴리스 동작, 블록킹 동작, 쓰레드 코드의 구별은 용이하게 실시할 수 있다. 예를 들어, 각 동작 또는 코드는 함수의 이름이나, 모듈의 이름으로 구별할 수 있고, 이러한 이름을 데이터 베이스 혹은 룩업 테이블을 구성하여 식별하고, 이에 따라 상기의 규칙들을 적용할 수 있다.

태스크 그래프 생성부(130)는 상기 규칙에 따라 생성된 노드에 대해서 각각의 노드 간의 의존 관계에 따라, 3가지 이상의 타입의 에지를 노드 간에 삽입한다.

3가지 이상의 타입의 에지에는, 트루-디펜든시(true-dependency) 에지와, 안티-디펜든시(anti-dependency) 에지와, 콘트롤-디펜든시(control-dependency) 에지를 포함한다.

콘트롤-디펜든시(control-dependency) 에지는, 프로그램 코드 상에 기재된 순서(즉 프로그램 코드의 라인간의 실행 순서)에 의해서 발생하는 에지이다. 이러한 콘트롤-디펜든시 에지는 예를 들어, 하나의 쓰레드에 포함된 코드가 두 개 이상의 노드로 분할될 때 생성되는 에지이다.

예를 들어 도 2 (a)의, 4 ~ 6 line은 3 line 이후에 실행되어야 하고, 또한 3 line은 "While" 루프에 의해서, 4 ~ 6 line 이후에 실행되어야 해서, 하나의 콘트롤 디펜든시 루프를 형성(도 3의 (a)의 A1, A2 간 참조)한다.

트루-디펜든시(true-dependency) 에지는, 공유 메모리(버퍼)를 쓰는 노드와 읽는 노드간의 의존 관계를 나타내는 에지이다. 이러한 트루-디펜든시 에지는 공유 메모리를 특정 노드가 쓴(혹은 수정) 후에, 쓴 공유 메모리를 다시 읽어 들여야 함을(도 3의 (a)의 A2, B 간 참조) 나타낸다.

안티-디펜든시(anti-dependency) 에지는, 공유 메모리에 대해서 특정 노드가 읽어 들인 후에 다시 공유 메모리를 특정 노드가 다시 쓸 수 있다는 의존 관계(write after read relation)를 나타내는 에지이다.

도 3의 (a) 내지 (b)는, 도 2의 (a) 내지 (b)의 프로그램 코드에 대해서, 각각 규칙 ① 내지 ③을 적용하고, 노드 간의 의존 관계에 따라 에지를 생성한 태스크 그래프이다.

여기서, 도 3의 (a)의 노드 A2와 B 사이에는, 안티-디펜든시 에지와 트루-디펜든시 에지를 포함하는 사이클(Cycle)을 형성하고, 도 3의 (b)의 노드 A, B, C 사이에도, 안티-디펜든시 에지와 트루-디펜든시 에지를 포함하는 사이클(Cycle)을 형성하는 것을 알 수 있고, 이로부터, 도 3의 (a)의 노드 A2와 B 사이에 공유 메모리를 이용할 수 있음을 알 수 있고, 도 3의 (b)의 노드 A, B, C 사이에서 공유 메모리를 이용하여 각 노드 간에 메모리를 공유할 수 있음을 알 수 있다.

즉 하나의 공유 메모리에 대해서 쓰기와 읽기가 일어나고 반복하기에 이러한 사이클을 포함하는 공유 메모리에 대해서는 메모리를 공유할 수 있음을 정적(statically)으로 알 수 있다.

도 3의 (c)는, 도 3의 (a) 내지 (b)의 확장 형태로서, 예를 들어 이종 아키텍처(호스트 CPU와 GPU를 이용하는 프로그램 코드)상에서 실행되는 프로그램 코드(도 2의 (c), CUDA 개발 환경에서)에 따라 생성된 태스크 그래프이다.

먼저 도 2의 (c)를 참조하면, 도 2의 (c)의 프로그램 코드는 호스트 CPU(예를 들어 인텔 CPU) 상에서 실행되는 쓰레드(Thread) 코드이다. 도 2의 (c) 코드에서 알 수 있는 바와 같이, 병렬 처리의 속도 향상을 위해, 비동기 동작용 API를 포함할 수 있다.

이러한 비동기 동작용 API는 예를 들어 호스트 CPU의 메모리로부터 GPU의 메모리로의 복사 동작(asyncCopyHtoD)이나, 반대로의 메모리 복사 동작을 포함한다. 이러한 비동기 동작용 API는 정형화된 그래프에서 모델링의 어려움을 제공한다.

예를 들어 호스트 CPU와 GPU 간의 전체 성능 측정, 상호 작용 등을 예측하지 못하게 하는 문제가 발생된다.

이러한 문제점을 해결하기 위해서, 앞서 살펴본 규칙 ① 내지 ③의 적용 후에, 이러한 규칙을 더 확장한다.

확장되는 규칙에는,

④ 비동기 동작용 API와 GPU 실행 호출 함수(여기서는 kernel)는 기존 노드로부터 새로운 노드를 생성한다.

⑤ 새로운 노드의 함수 호출의 인자(argument)로 포함된 호스트 CPU 또는 GPU 의 메모리 포인터는, 해당 메모리(버퍼)에 유효한 데이터가 있는지 여부에 따라서, 트루-디펜든시 에지나 안티-디펜든시 에지 타입의 입력 에지(기존 노드로부터)를 형성한다.

⑥ 새로운 노드의 모든 입력 에지는 다시 후속하는 새로운 노드로 출력하는 에지를 형성한다.

⑦ 동기화 함수(예 도 2의 (c)의 syncStream)는 새롭게 생성되어 연결된 에지의 마지막 노드(즉 본 예에서는 연관된 스트림 상의)의 에지를 입력으로 받는다.

⑧ 반복 주기의 차이(iteration difference)가 있는 경우(현재 스트림과 이전 스트림)에, 에지에 토큰을 삽입한다. (토큰에 대해서는 이하에서 자세히 살펴본다)

⑨ 커널 함수의 호출이 호스트 CPU 또는 GPU의 메모리 포인터 인자가 없는 경우에는 콘트롤-디펜든시 에지가 입력으로 삽입된다.

이러한 기존 규칙과 추가적인 규칙에 따라, 도 2의 (c)의 CUDA 프로그램으로부터 생성된 태스크 그래프(도 3의 (c))를 살펴보도록 한다.

먼저 호스트 CPU 상의 코드는 블록킹 동작(규칙 ②, line 7 참조)에 의해 A1, A2 노드로 분할되고, 코드의 루프와, 코드의 순서로 인해, 두 개의 콘트롤-디펜든시(control-dependency) 에지가 A1과 A2 노드 사이에 삽입된다.

코드 상에는 비동기 동작이 3개가 있고(line 4, line 5, line 6), 이러한 비동기 동작(규칙 ④)은 각각 분리된 노드를 형성한다.

Host-to-Device 복사 함수(line 4)는 두 개의 포인터가 있고, 이 두 개의 포인터로 인해 두 개의 에지를 생성하여, A1 노드로부터 HtoD 노드로 연결한다.

여기서, 호스트 버퍼는 이미 line 3에서 생성되었으므로, 트루-디펜든시 에지를 생성하고, 디바이스 버퍼는 초기에 비어 있는 버퍼이므로 앤티-디펜든시 에지를 형성(규칙 ⑤)한다.

이러한 코드는 비록 락킹(locking)과 같은 공개적인 방법을 사용하지 않지만, 버퍼 간의 순차적인 사용을 보장하고 프로그램의 정확한 수행을 위해서 시멘틱(semantic) 상에서 락킹과 같은 상호 배제(mutual exclusion)를 보장해야 한다.

이렇게 생성된 트루-디펜든시 에지와 앤티-디펜든시 에지는 후속하는 커널 노드와 DtoH 노드로 포워딩(규칙 ⑥) 된다. 여기서, 호스트 버퍼를 위한 트루-디펜든시 에지는 앤티-디펜든시 에지로 변경되고, 디바이스 버퍼를 위한 앤티-디펜든시 에지는 트루-디펜든시 에지로 변경된다.

왜냐하면, 호스트 버퍼의 데이터가 디바이스(GPU)로 복사가 완료되면, 호스트 버퍼는 이미 소비를 완료한 것이 되고, 반면에 디바이스 버퍼는 디바이스(GPU) 상에서 특정 기능을 수행하여 채워져야 하기 때문이다.

여기서 비록 호스트 버퍼가 디바이스로 복사가 완료된 후에는 호스트 버퍼의 재 사용이 가능할 수 있지만, 프로그램 코드의 동기화 함수(syncStream)를 고려하여 재사용이 되지 않도록 할 수 있다. 이렇게 구성함으로써, 프로그램 코드와 이후에 볼 시뮬레이션부(140)의 시뮬레이션 간에 정확한 시간적인 일치를 가져올 수 있다. 이를 위해 모든 에지가 동기화 함수(syncStream)를 포함하는 노드로 릴레이(규칙 ⑦)된다.

여기서, 도 2의 (c)의 line 7에서는 반복 주기가 상이함으로 알 수 있다. 즉 DtoH 노드는 현재 스트림에 대해서 동작을 하고 있으나, line 7의 syncStream 함수는 이전 스트림에 대해서 동작하여, 규칙 ⑧에 따라 토큰을 삽입한다.

도 4는, 생성된 태스크 그래프에 초기 토큰을 삽이한 예시적인 실시예를 도시한 도면이다. 이러한 토큰을 이용하여 시뮬레이션부(140)는 태스크 그래프의 시뮬레이션이 가능하다. 예를 들어, 특정 노드의 모든 입력 에지에 토큰이 있는 노드는 스케쥴링을 할 수 있고, 따라서 실행할 수 있다. 그리고 이러한 토큰은 스케쥴링이 됨에 따라 토큰이 이동하고, 이에 따라 후속하는 노드를 다시 스케쥴링할 수 있도록 한다.

여기서는, 태스크 그래프에 있는 모든 노드의 샘플 레이트는 1로 가정한다. 즉, 각 노드는 모든 입력 에지에 하나의 토큰이 있으면 스케줄링이 가능하며, 스케줄링이 된 후에, 출력 에지에 하나의 토큰을 출력할 수 있다.

이러한 도 4의 (a), (b), (c)는 태스크 그래프 생성부(130) 혹은 시뮬레이션 부(140)에 의해서 생성할 수 있다.

토큰의 의미는 에지의 타입에 따라서, 달라질 수 있다. 예를 들어, 콘트롤-디펜드시 에지에 있는 토큰은 노드 간의 실행 순서를 나타낸다.

앤티-디펜든시 에지와 트루-디펜든시 에지는 공유 메모리의 사용 순서에 관한 것이므로, 앤티-디펜든시 에지의 토큰은 비어 있는 공유 메모리(버퍼)를 나타내고, 트루-디펜든시 에지에 있는 토큰은 공유 메모리가 채워져 있는 상태를 나타낸다.

이러한 앤티-디펜든시 에지와 트루-디펜든시 에지에는 하나 이상의 토큰을 사용할 수 있고, 따라서 이 토큰의 개수에 따라서 공유 메모리의 크기가 결정될 수 있고, 특히 앤티-디펜든시 에지와 트루-디펜든시 에지를 포함하는 노드의 사이클에 따라서 공유 메모리의 사용 여부를 결정할 수 있다.

이하에서는 각 실시예에 대한 초기 토큰의 삽입 형태를 살펴본다.

도 4의 (a)는, 도 3의 (a)의 태스크 그래프에 초기 토큰을 삽입한 그래프이다.

도 3의 (a)에서는 두 개의 사이클이 존재한다. 하나의 사이클은 A1과 A2 노드 간의 콘트롤-디펜든시 에지에 의한 사이클과, A2와 B 간의 앤티-디펜든시 에지와 트루-디펜든시 에지에 의한 사이클이 존재한다.

콘트롤-디펜든시 에지는 코드 순서에 의한 에지이고, A1이 A2보다 먼저 실행되어야 하므로(프로그램 코드의 실행 순서), A1의 입력 에지에 초기의 토큰을 삽입한다.

한편, 앤티-디펜든시 에지와 트루-디펜든시 에지는 공유 메모리에 관한 에지이므로, 버퍼가 비어 있는 것을 나타내는 앤티-디펜든시 에지에 초기 토큰을 삽입한다. 앤티-디펜든시 에지와 트루-디펜든시 에지의 토큰은 앞서 살펴본 바와 같이, 공유 메모리의 크기를 나타내므로, 토큰의 개수는 사용자의 입력에 따라서, 혹은 시뮬레이션의 결과에 따라서 달라질 수 있다.

도 4의 (b)는, 도 3의 (b)의 태스크 그래프에 초기 토큰을 삽입한 그래프이다.

여기서는, 하나의 앤티-디펜든시 에지와 트루-디펜든시 에지의 사이클만이 존재한다. 한편, 여기서는 앤피-디펜든시 에지에 두 개의 토큰이 있는 것을 나타내고 이는, 두 개의 공유 버퍼가 있음을 의미한다.

도 4의 (c)는, 도 3의 (c)의 태스크 그래프에 초기 토큰을 삽입한 그래프이다.

도 4의 (c)에서는 A2와 A1 사이의 3개의 에지에 대해서, 초기 토큰을 삽입하였고, 또한 규칙 ⑧에 따라 DtoH 노드와 A2 노드 사이의 두 개의 에지에 대해서 토큰을 삽입하였다. 따라 이 예에서는 호스트 버퍼와 디바이스 버퍼에 대해서는 각각 두 개의 버퍼를 가지게 된다. 이러한 추가적인 토큰의 삽입은 비동기 방식으로 인한 데드락을 방지할 수 있도록 한다.

여기서 호스트 버퍼에 대한, DtoH 노드에서 A2 노드의 에지(트루-디펜든시 에지)의 토큰은 더미 데이터가 삽입된 버퍼(트루-디펜든시 에지)이고, 결국 이 호스트 버퍼는 도 2의 (c)의 라인 8에서의 출력은 더미 데이터의 출력을 의미한다.

이하에서는 앞서 살펴본, 초기 토큰이 삽입된 그래프에 대한 시뮬레이션부(140)에서 수행되는 시뮬레이션에 대해서 살펴보도록 한다.

파라미터	설명
N	노드의 세트
D	디바이스(프로세서 코어 혹은 스트림 프로세서)의 세트
TIME : N --> time	각 노드의 실행 시간
MAP : N --> G	디바이스가 어떤 디바이스 그룹에 포함되는지를 결정하는 맵핑, 여기서, G는 디바이스 그룹의 세트
Group : D --> G	디바이스가 어떤 디바이스 그룹에 포함되는지
Input : N --> P(N x tokens)	각 노드의 입력 에지의 세트
Output : N --> P(N x tokens)	각 노드의 출력 에지의 세트
Schedule : G x R --> N	주어진 디바이스 그룹과 실행 준비된 노드의 세트 중에서 스케줄 될 노드, 여기서 R 은 실행 준비된 노드의 세트

표 1은, 정적 분석을 위한 입력 파라미터를 나타낸다. 이러한 파라미터는 노드의 실행을 위해, 하드웨어 아키텍처를 고려한다.

예를 들어, 태스크 그래프가 호스트 CPU와 GPU로 구성되고, 호스트 CPU와 GPU 사이에 PCI 버스로 연결되어 있고, 여기서 호스트 CPU는 네개의 프로세서 코어를 포함하고, GPU는 복수의 스트림 프로세서를 포함하고, 각 스트림 프로세서는 다른 스트림 프로세서와는 별도로 독립적으로 동작 가능하고, 여기서 각 스트림 프로세서는 또한 복수의 프로세서 코어를 포함할 수 있다.

따라서, 입력된 태스크 그래프가 수행될 하드웨어 아키텍처의 입력이 필요하며, 이를 MAP 함수와, Group 함수로 구현된다. 예를 들어, 디바이스 그룹에는 네개의 프로세서 코어를 포함하는 호스트 CPU 그룹과, 복수의 스트림 프로세서를 포함하는 GPU 그룹으로 나뉠 수 있다.

또한 호스트 CPU 그룹에는 네개의 프로세서 코어(디바이스)를 포함하고, GPU 그룹에는 복수의 스트림 프로세서(디바이스)를 포함한다.

TIME 함수는 각 노드의 실행 시간을 나타내며, 각 노드의 실행 시간은 노드에 대응하는 코드의 실제 실행에 의해서 혹은 코드에 있는 함수 등으로부터의 예측을 통해서 계산될 수 있다. 물론 이러한 TIME 함수는 실행 시간을 고려하지 않는 경우에는 유닛 시간(예 1로)으로 설정할 수 있다.

MAP 함수는, 각 노드가 어떤 디바이스 그룹에 속하는지를 결정하며, MAP 함수는 사용자의 입력으로 혹은, 정정 분석을 통한 결과에 따라 자동으로 변경될 수 있다.

Group 함수는, 특정 디바이스가 어떤 그룹에 속하는지를 나타낸다. 따라서, MAP 함수를 통해 각 노드는 할당된 디바이스 그룹 상의 하나의 특정 디바이스에 할당되어 스케줄링 될 수 있도록 한다.

Input 함수는, 각 노드에 대하여 소비될 토큰의 개수를 나타낸다. 예를 들어 각 노드는 하나 이상의 에지를 포함할 수 있고, 각 에지는 하나 이상의 토큰을 포함할 수 있다. 특정 노드가 스케쥴링이 될때, 스케줄링이 되는 노드는 해당 노드의 입력 에지에서 해당 노드가 소비할 모든 토큰이 있는 노드가 될 것이다.

Output 함수는, 각 노드가 스케줄링이 된 후에 생성하는 에지에서의 토큰의 개수를 나타낸다.

이러한 Input 함수와 Output 함수는 태스크 그래프로부터 자동으로 태스크 그래프의 시멘틱을 분석하여 수신할 수 있다.

이러한 입력 파라미터는 파라미터 수신부(120)로부터 수신된 파라미터 일 수 있다. 예를 들어, 각 노드의 실행 시간은 태스크 그래프에 포함된 실행 시간을 이용해서 자동으로 혹은 사용자의 입력을 통해 수동으로 수신할 수 있다.

또한 MAP 함수는 사용자의 입력을 통해서 어떤 노드가 어떤 디바이스 그룹(예 호스트 CPU 그룹, GPU 그룹 등)에 할당되는지를 파라미터 수신부(120)를 통해 입력할 수도 있고, 혹은 초기 할당 이후에, 시뮬레이션부(140)의 반복 수행에 따라서 자동으로 변경하여 입력하도록 구성할 수 있다.

또한 Group 함수 또한 파라미터 수신부(120)를 통해 수신할 수 있다.

도 5는, 시뮬레이션부(140)가 시뮬레이션을 위해 실행하는 정적 분석을 가능케 하는 슈도(Pseudo) 코드를 나타내고, 표 2는, 도 5의 슈도 코드에서 사용되는 변수를 나타낸다.

변수	설명
E	실행 노드의 세트
R	준비 노드의 세트
I	휴지(idle) 디바이스의 세트
	노드i가 실행되는 디바이스
	노드 i가 디스패치된 최근 시간
	총 진행 시간

도 5의 슈도 코드를 간단히 살펴보면, 초기에 실행 노드의 세트와 준비 노드의 세트는 비어 있고(line 1, 2 참조), 모든 디바이스는 휴지 상태(line 3)에 있다.

도 5의 line 5의 반복은 최대 진행 시간을 초과하거나 혹은 최대 반복 횟수를 초과하는 경우에 중단될 수 있고, 혹은 더 이상 스케줄링이 되지 않을 때(데드락의 발생 등) 중단될 수 있다.

line 6에서, 현재 준비된 노드를 찾고 이를 준비된 노드의 세트에 삽입한다.

여기서 준비된 노드는, 태스크 그래프 상에서, 해당 노드의 각각의 입력 에지에 토큰이 있고, 각각의 에지에 있는 토큰이 해당 노드의 실행에 필요한 토큰의 개수 이상인, 노드이다.

그리고 line 9에서, 준비된 노드를 준비된 노드에 대해 할당된 디바이스 그룹 상의 휴지 중인 디바이스에 할당하고, 스케줄링한다.

그리고 line 17과 18에서, 다음으로 완료 가능한 태스크(노드)를 확인하고 총 진행 시간을 갱신한다.

만약 반복 과정 동안에, 준비 노드의 세트에 노드가 없는 경우에는 데드락에 빠진 것을 판단할 수 있다.

이러한 정적 분석을 통해서, 프로그램 코드의 총 수행 시간을 알 수 있고, 데드락에 빠진 것을 확인할 수 있으며, 디바이스 그룹 내의 디바이스 들의 사용 실태(예, 실행 시간, 휴지 시간)를 확인할 수 있으며, 또한 총 수행 시간의 형성에 가장 영향을 미친 패스(critical path)나 각 노드의 점유 시간 등을 확인할 수 있다.

이러한 각종 정적 분석의 결과는 하나의 다이어그램으로 표시될 수 있고, 이러한 다이어그램에는 디바이스와, 노드의 할당, 노드의 실행 시간 등을 알 수 있고, 그리고 가장 영향을 많이 미친 패스에 대해서 추출할 수 있도록 한다.

즉 도 5의 슈도 코드를 이용해서, 각 노드가 어디에 할당되었는지, 각 디바이스가 언제 사용되는지 등을 자동을 알 수 있도록 하는 다이어그램을 생성할 수 있다.

그리고 이러한 정적 분석을 통해서, 프로그램 코드의 성능을 개선할 수 있는 다양한 옵션을 선택할 수 있다. 이러한 옵션에는 버퍼(토큰)의 개수를 늘릴 수도 있고, 특정 노드의 수행을 다른 디바이스 그룹으로 변경할 수도 있으며, 또한 쓰레드의 개수를 변경할 수도 있다.

이러한 버퍼(토큰)의 개수를 변경할 수 있도록 하여, 주어진 프로그램 코드에 대한 최적의 공유 메모리(버퍼)의 크기를 결정할 수 있도록 하고, 그리고 특정 노드의 디바이스 그룹을 다른 디바이스 그룹으로 변경할 수 있도록 하여, 노드와 특정 아키텍처 상에서의 디바이스 그룹 간의 최적의 맵핑을 결정할 수 있도록 하고 또한 최적의 아키텍처를 결정할 수 있도록 한다.

도 6은, 이상에서 살펴본 태스크 그래프 생성부(130)와 시뮬레이션부(140)를 이용한 응용 사례를 위한 매트릭스 곱셈을 수행하는 기능 블록도를 도시한 도면이다.

도 6에서는, 매트릭스 생성 모듈과 CPU 랩퍼(Wrapper) 모듈 및 체크(Checker) 모듈은 호스트 CPU 상에서 수행되는 독립적인 쓰레드들이고, 매트릭스 곱셈 모듈은 GPU에서 수행되는 쓰레드이다.

여기서는 매트릭스 곱셈 모듈이 GPU 상에서 수행될 때 몇 개의 스트림으로 분리되는 것이 성능 향상에 기여하는지를 살펴본다.

여기서 스트림이란, GPU 상에서 다른 스트림과 독립적으로 수행될 수 있는, 프로그램 실행 유닛이며, 일반적으로 GPU는 다수의 스트림을 수용하고 다른 스트림과 독립적으로 수행할 수 있는 복수의 프로세서 코어가 있다.

먼저, 호스트 CPU와 GPU 사이에는 동기화 API를 사용할 수 있고 혹은 비동기화 API를 사용할 수 있다. 비동기화 API를 사용하는 경우에도, 결국 체크 모듈에서 GPU에서 계산된 결과를 동기화해야 하므로, 하나의 커널(스트림)을 사용하는 경우에는 비동기화 API를 사용하는 경우나 동기화 API를 사용하는 경우나 유사한 성능 결과를 나타냄을 발견하였다.

따라서, 몇 개의 스트림을 사용하는 것이 본 응용 예에서 효율적인지를 판단할 필요가 있고, 이에 따라, 본 발명에서 제안한 프로그램 분석 장치를 이용하여 스트림이 하나인 경우(도 7의 (a))와 스트림이 두 개인 경우(도 7의 (b))에 대해서 태스크 그래프를 각각 생성하고, 시뮬레이션에 따라 그 실행 시간을 각각(도 8의 (a), (b))알 수 있는 스케줄 다이어그램을 시뮬레이션부(140)에 의해서 출력하였다.

도 8의 (a)에서 알 수 있는 바와 같이, 동기화 API를 사용하는 경우나 하나의 스트림을 사용하는 경우에는, 데이터 복사와 GPU에서의 실행이 순차화되어 있고, 이것이 총 수행 시간에 영향을 미치는 패스(Critical Path)를 형성함을 알 수 있다.

반면에 도 8의 (b)에서 알 수 있는 바와 같이, 두 개의 스트림을 사용하는 경우에는, GPU와 호스트 CPU 간의 데이터 복사에 필요한 시간과 GPU 커널에서 소요되는 시간이 오브랩됨을 알 수 있고, 따라서, 이로부터 더 이상의 스트림 개수의 증가는 성능 향상에 영향을 미치지 않는 것을 알 수 있고, 두 개의 스트림을 이용하는 경우에는 GPU가 총 수행 시간에 영향을 미치는 패스임을 알 수 있다.

이상으로, 정적 분석을 통해 프로그램 코드를 분석하는 장치에 대해서 살펴보았다. 이러한 프로그램 코드의 분석 장치를 이용해서, 쓰레드 간에 공유할 수 있는 공유 메모리를 이용하면서도 정적으로 분석할 수 있는 장치를 제공할 수 있고, 또한 특정 하드웨어 아키텍처를 고려하여 정적으로 프로그램을 분석할 수 있도록 한다.

이러한 프로그램 분석 장치는, 실제로 프로그램 코드를 특정 아키텍처 상의 CPU나 GPU 상의 프로세서를 위한 어셈블리 코드로 컴파일되어 구동할 필요가 없고, 컴파일 이전 단계에서 프로그램의 문제점을 분석하도록 하여 이종 아키텍처나 공유 메모리를 사용하는 프로그램상에서 발생할 수 있는 다양한 문제점을 해소할 수 있을 것이다.

이러한 프로그램 분석 장치는 프로그램을 포함하는 컴퓨터 판독 가능한 저장 매체를 구성할 수 있고, 여기서 프로그램은 프로그램 코드를 수신하는 프로그램 수신 수단과 수신된 프로그램 코드로부터 태스크 그래프를 생성하는 태스크 그래프 생성 수단과 태스크 그래프의 분석을 위해, 태스크 그래프를 시뮬레이션(Simulation)하는 시뮬레이션 수단을 실행하도록 구성된다.

이상에서 설명한 본 발명은, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 있어 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로 전술한 실시 예 및 첨부된 도면에 의해 한정되는 것이 아니다.

110 : 프로그램 수신부 120 : 파라미터 수신부
130 : 태스크 그래프 생성부 140 : 시뮬레이션부
210 : 프로세서 220 : 메모리
230 : 사용자 입력부 240 : 디스플레이부

Claims (10)

1. 프로그램 코드를 수신하는 프로그램 수신부;
   수신된 프로그램 코드로부터 태스크 그래프를 생성하는 태스크 그래프 생성부; 및
   태스크 그래프의 분석을 위해, 태스크 그래프를 시뮬레이션(Simulation)하는 시뮬레이션부를 포함하며,
   상기 태스크 그래프는, 하나 이상의 노드(node)와 하나 이상의 에지(edge)를 포함하고, 상기 에지는 3 개 이상의 에지 타입 중 하나이며,
   상기 시뮬레이션부 또는 태스크 그래프 생성부는, 시뮬레이션 이전에 상기 태스크 그래프 상의 에지에 적어도 하나의 토큰을 삽입하고,
   토큰이 삽입된 에지의 타입에 따라 토큰의 의미가 달라지고 상기 태스크 그래프의 에지 상에 삽입된 토큰의 개수는 버퍼의 개수를 나타내며,
   상기 시뮬레이션부는, 태스크 그래프 상의 토큰의 위치에 따라, 다음 실행 가능한 노드를 결정하고, 결정된 노드가 생성하는 출력을 결정된 노드의 출력 에지 상에 토큰으로 삽입하는 것을 특징으로 하는,
   프로그램 분석 장치.
2. 제1항에 있어서,
   상기 3 개 이상의 에지 타입은, 트루-디펜든시(true-dependency) 에지와, 안티-디펜든시(anti-dependency) 에지와, 콘트롤-디펜든시(control-dependency) 에지를 포함하는 것을 특징으로 하는,
   프로그램 분석 장치.
3. 삭제
4. 삭제
5. 제1항에 있어서,
   프로그램 코드가 실행될 프로세서의 개수와 각 프로세서 내의 프로세서의 코어의 개수를 포함하는 설정 파라미터를 수신하는, 파라미터 수신부를 더 포함하며,
   상기 시뮬레이션부는, 상기 설정 파라미터에 따라서 상기 태스크 그래프의 노드 각각을 프로세서 혹은 프로세서 내의 프로세서 코어에 할당하여 시뮬레이션(Simulation)하며, 시뮬레이션 결과에 따라 프로그램 코드의 문제점을 정적으로 분석하는 것을 특징으로 하는,
   프로그램 분석 장치.
6. 프로그램 코드를 수신하는 프로그램 수신부;
   수신된 프로그램 코드로부터 태스크 그래프를 생성하는 태스크 그래프 생성부; 및
   태스크 그래프의 분석을 위해, 태스크 그래프를 시뮬레이션(Simulation)하는 시뮬레이션부를 포함하며,
   상기 태스크 그래프는, 하나 이상의 노드(node)와 하나 이상의 에지(edge)를 포함하고, 상기 에지는 3 개 이상의 에지 타입 중 하나이며,
   태스크 그래프 생성부는, 결정된 규칙에 따라, 상기 프로그램 코드를 태스크 그래프로 생성하며,
   상기 결정된 규칙은, ① 프로그램 코드에서 서로 상이한 쓰레드(thread)의 코드는 서로 상이한 노드에 할당되고, ② 할당된 노드 내의 코드에서 공유된 리소스에 대한 블록킹(blocking) 동작이 있는 경우, 상기 할당된 노드를 다시 두 개의 노드로 분할하고 ③ 할당된 노드 내의 코드에서 공유된 리소스에 대한 릴리스 동작이 있는 경우, 상기 할당된 노드를 다시 두 개의 노드로 분할하는 것을 특징으로 하는,
   프로그램 분석 장치.
7. 제6항에 있어서,
   상기 결정된 규칙 ②에서, 상기 블록킹 동작은 분할된 두 개의 노드 중 두 번째 노드 상에 포함되며, 상기 결정된 규칙 ③에서, 상기 릴리스 동작은 분할된 두 개의 노드 중 두 번째 노드 상에 포함되어,
   상기 시뮬레이션부는, 태스크 그래프 상의 노드 단위로 시뮬레이션할 수 있는 것을 특징으로 하는,
   프로그램 분석 장치.
8. 제6항에 있어서,
   상기 프로그램 코드는 프로세서 간의 비동기 동작(Asynchronous operation)과 동기 동작(Synchronous operation)을 포함하며,
   상기 결정된 규칙은, ④ 상기 ① 내지 ③에 따라 생성된 노드 내의 프로세서 간의 비동기 동작을 별도의 노드로 생성하고 ⑤ 상기 ① 내지 ③에 따라 생성된 노드를 상기 별도의 노드로 에지를 생성하여 연결하는 것을 더 포함하는 것을 특징으로 하는,
   프로그램 분석 장치.
9. 제8항에 있어서,
   프로그램 코드가 실행될 복수의 프로세서의 개수와 각 프로세서 내의 프로세서의 코어의 개수를 포함하는 설정 파라미터를 수신하는, 파라미터 수신부를 더 포함하며,
   상기 시뮬레이션부는, 상기 설정 파라미터에 따라서 상기 태스크 그래프의 노드 각각을 프로세서 혹은 프로세서 내의 프로세서 코어에 할당하여 시뮬레이션(Simulation)하며, 시뮬레이션 결과에 따라 프로그램 코드의 문제점을 정적으로 분석하며,
   상기 복수의 프로세서 중 하나는 호스트 CPU 이며, 상기 복수의 프로세서 중 다른 하나는 복수의 프로세서 코어를 포함하는 GPU(Graphic Processing Unit)인 것을 특징으로 하는,
   프로그램 분석 장치.
10. 프로그램을 기록한 컴퓨터 판독 가능한 저장매체로서,
    상기 프로그램은,
    프로그램 코드를 수신하는 프로그램 수신 수단;
    수신된 프로그램 코드로부터 태스크 그래프를 생성하는 태스크 그래프 생성 수단; 및
    태스크 그래프의 분석을 위해, 태스크 그래프를 시뮬레이션(Simulation)하는 시뮬레이션 수단을 실행하며,
    상기 태스크 그래프는, 하나 이상의 노드(node)와 하나 이상의 에지(edge)를 포함하고, 상기 에지는 3 개 이상의 에지 타입 중 하나이며,
    상기 시뮬레이션 수단 또는 태스크 그래프 생성 수단은, 시뮬레이션 이전에 상기 태스크 그래프 상의 에지에 적어도 하나의 토큰을 삽입하고,
    토큰이 삽입된 에지의 타입에 따라 토큰의 의미가 달라지고 상기 태스크 그래프의 에지 상에 삽입된 토큰의 개수는 버퍼의 개수를 나타내며,
    상기 시뮬레이션 수단은, 태스크 그래프 상의 토큰의 위치에 따라, 다음 실행 가능한 노드를 결정하고, 결정된 노드가 생성하는 출력을 결정된 노드의 출력 에지 상에 토큰으로 삽입하는 것을 특징으로 하는,
    프로그램을 기록한 컴퓨터 판독 가능한 저장매체.

Images