KR101522444B1 - 소스 코드 처리 방법, 시스템, 및 프로그램 - Google Patents

Abstract

멀티 프로세서 시스템에서 병렬화에 의해 프로그램의 실행을 고속화하는 기법을 제공하는 것이다. 상기 목적은, 고속화하고자 하는 프로그램의 크리티컬 패쓰를 적절하게 커트하여 다른 프로세스로서 나누어, 개별 프로세서에 할당하도록 하는 것으로 달성된다. 본 발명의 처리 프로그램은 복수의 처리 블록으로부터 발생하는 고속화하고 싶은 프로그램의 소스 코드를 읽어 크리티컬 패쓰가 가능한 커트를 모두 테스트하여, 결과의 커트된 처리의 블록의 흐름의 처리 시간이 가장 짧아지는 커트를 찾아낸다. 크리티컬 패쓰가 가능한 커트의 처리는, 커트한 결과의 패쓰에 대해서 재귀적으로 적용된다. 그래서, 이 이상 커트해도, 프로세서간의 통신 시간 등을 가미하면 오히려 전체의 처리 시간이 길어져 버리는 단계에서, 커트를 정지한다. 이것으로 복수의 처리 블록의 군이 얻어진다. 이렇게 해서 분할 생성된 블록 청크의 수가 멀티 프로세서 시스템의 프로세서의 수와 동등 또는 그 이하라면, 개개의 블록 청크는 그대로 컴파일되어, 실행 환경에서, 개별의 프로세서에 각각 할당된다. 분할 생성된 블록 청크의 수가, 멀티 프로세서 시스템의 프로세서의 수보다 많은 경우, 블록 청크가 결합되어 결과의 블록 청크의 수가 프로세서의 수와 동등해지도록 수행한다.

Description

소스 코드 처리 방법, 시스템, 및 프로그램{SOURCE CODE PROCESSING METHOD, SYSTEM, AND PROGRAM}

본 발명은, 멀티 프로세서 시스템에서, 프로그램의 실행을 고속화하는 기법에 관한 것이다.

최근, 과학 기술 계산, 시뮬레이션 등의 분야에서, 복수의 프로세서를 가진, 이른바 멀티 프로세서 시스템이 사용된다. 이와 같은 시스템에서, 어플리케이션 프로그램은, 복수의 프로세서를 생성하여 개별 프로세서에 프로세스를 할당한다. 이러한 프로세서는, 예를 들어, 공유의 메모리 공간을 이용하여 서로 통신하며, 처리를 진행한다.

최근이 되어 특히 활발히 개발되게 된 시뮬레이션의 분야로서 로봇, 자동차, 비행기 등의 메카트로닉스의 플랜트의 시뮬레이션용 소프트웨어가 있다. 전자 부품과 소프트웨어 기술에 발전의 혜택에 의해, 로봇, 자동차, 비행기 등에서는, 신경과 같이 기계 전체에 퍼져 있는 와이어 결선이나 무선 LAN등을 이용하고, 대부분의 제어가 전자적으로 행해진다.

이것들은, 본래 기계적 장치인데, 대량의 제어 소프트웨어도 내장하고 있다. 그 때문에, 제품의 개발에 있어서는, 제어 프로그램의 개발과 테스트에, 긴 시간과 방대한 코스트(cost)와 다수의 인원을 소비할 필요가 나왔다.

이러한 테스트를 위해 종래 수행되고 있는 기법으로서 HILS(Hardware In the Loop Simulation)가 있다. 특히, 자동차 전체의 전자 제어 유닛(ECU)을 테스트하는 환경은, 풀 비클(full-vehicle) HILS로 불린다. 풀 비클 HILS에 대해서는, 실험실 내에서, 실제 ECU가, 엔진, 트랜스미션 기구 등을 에뮬레이션하는 전용의 하드웨어 장치에 접속되어 소정의 시나리오에 따라 테스트를 한다. ECU로부터의 출력은, 감시용의 컴퓨터에 입력되어 또 디스플레이에 표시되고, 테스트 담당자가 디스플레이를 바라보면서, 이상 동작이 있는지 없는지를 체크한다.

그러나, HILS는, 전용의 하드웨어 장치를 사용하여, 그것과 실제 ECU의 사이를 물리적으로 배선해야 하기 때문에, 준비하는데 시간이 많이 걸린다. 또, 다른 ECU로 바꾼 테스트도, 물리적으로 다시 접속해야 하기 때문에 시간이 많이 걸린다. 게다가 실제 ECU를 이용한 테스트이기 때문에, 테스트에 실시간을 필요로 한다. 따라서, 많은 시나리오를 테스트하면, 방대한 시간이 걸린다. 또한, HILS의 에뮬레이션용의 하드웨어 장치는, 일반적으로, 매우 고가이다.

따라서 최근, 고가의 에뮬레이션용 하드웨어 장치를 사용하지 않고서도, 소프트웨어로 구성하는 기법이 제안되고 있다. 이 기법은, SILS(Software In the Loop Simulation)로 불려 ECU에 탑재되는 마이크로 컴퓨터, 입출력 회로, 제어의 시나리오, 엔진이나 트랜스미션 등의 플랜트를 모두, 소프트웨어·시뮬레이터로 구성하는 기법이다. 이것에 의하면, ECU의 하드웨어가 존재하지 않아도 테스트를 실행 가능하다.

이러한 SILS의 구축을 지원하는 시스템으로서는, 예를 들어, CYBERNET SYSTEMS CO. ,LTD. 로부터 입수 가능한 시뮬레이션 모델링 시스템인, MATLAB(R) /Simulink(R)가 있다. MATLAB(R) /Simulink(R)를 사용하면, 도 1에 나타낸 바와 같이, 화면상에 그래피컬 인터페이스에 의해, 기능 블록 A, B, ..., J를 배치하고, 화살표와 같이 그 처리의 흐름을 지정하는 것에 의해, 시뮬레이션 프로그램을 작성할 수 있다.

이렇게 하여, MATLAB(R) /Simulink(R) 상에서, 기능 블록 A, B, . . . , J 등의 블록 선도가 작성되면, Real-Time Workshop(R)의 기능에 의해, 등가인 기능의 C언어의 소스 코드로 변환할 수 있다. 이 C언어의 소스 코드를 컴파일하는 것으로써, 다른 컴퓨터 시스템에서 SILS로서 시뮬레이션을 실행할 수 있다.

특히, 다른 컴퓨터 시스템이 멀티 프로세서 시스템인 경우, 가능한 한, 처리를 분할하고, 개별 프로세서에, 다른 프로세스를 할당해 병렬처리하는 것이 처리 속도의 향상에 유리하다.

이 때문에 종래보다, CP 스케쥴링 기법이 알려져 있다. 여기서 말하는 CP란, 크리티컬 패쓰(critical path)에 대한 것이다. CP 스케줄링 수법을 이용하면, 도 1에 나타낸 블록도가, 도 2에 나타낸 태스크 그래프로 변환된다. 도면으로부터 알 수 있는 바와 같이, 도 2의 태스크 그래프는, 세로 4열이고, 각각의 열의 처리를 개별의 4개의 CPU에 병렬적으로 할당하여, 하나의 CPU에서 처리했을 때와 비교하여, 실질적으로 2배의 속도의 처리를 달성할 수 있다.

그러나, 도 2에서, B→D→F→H→J라고 하는 패쓰는 크리티컬 패쓰로서, 이 크리티컬 패쓰를 처리하는 CPU의 시간 이상, 전체의 처리 시간을 단축할 수 없다.

특허 공개평 6-83608호 공보는, 병렬 계산기에 프로그램 실행의 병목(bottleneck)을, 크리티컬 패쓰 해석부에 의해 찾아내는 것을 개시한다.

특허 공개평 7-21240호 공보는, 논리 회로의 레이아웃 설계에 관한 것이며, 크리티컬 패쓰를 짧게 함과 동시에 커트 라인(cut line)을 횡단하는 네트들(nets)의 수를 최소로 하기 위해, 크리티컬 패쓰를 추출하는 크리티컬 패쓰 추출 장치, 커트 라인을 작성하는 커트 라인 작성 장치, 각 블록의 결합도, 크리티컬 패쓰 정보로부터 각 블록의 머지 쌍을 결정하는 머지 쌍 선택 장치, 머지 쌍 선택 장치로 구한 각 블록의 머지 쌍으로부터 블록의 머지를 수행하는 머지 장치, 커트 라인을 횡단하는 네트들의 수가 최소가 되도록 쌍들(pairs) 교환을 수행하는 쌍-와이즈(pair-wise) 장치로부터 구성된 시스템을 개시한다.

특허 공개평 8-180100호 공보는, 기계의 할당을 수반하는 잡 숍 스케줄링(job shop scheduling) 문제에 대해서, 효율적인 근방(neighborhood)을 생성하고, 근사 해법과 조합시키는 것으로, 최적의 솔루션을 고속으로 구하는 것을 개시한다.

특허 공개평 6-83608호 공보 및 특허 공개평8-180100호 공보는, 태스크 스케줄링의 개요를 개시하는 것에 불과하다.

특허 공개평 7-21240호 공보는, 논리 회로의 레이아웃 설계에서, 크리티컬 패쓰를 짧게 하는 기법에 대해서 설명하지만, 이것은 물리적 레이아웃에 크리티컬 패쓰이고, 소프트웨어의 논리적인 크리티컬 패쓰의 처리에 적용할 수 있는 것은 아니다.

특허 문헌 1：특허 공개평 6-83608호 공보 특허 문헌 2：특허 공개평 7-21240호 공보 특허 문헌 3：특허 공개평 8-180100호 공보

따라서, 이 발명의 목적은 멀티 프로세서 시스템에서 병렬화에 의해 프로그램의 실행을 고속화하는 기법을 제공하는 것에 있다.

상기 목적은, 고속화하고자 하는 프로그램의 크리티컬 패쓰를 적절하게 커트(cut)하여, 다른 프로세스로서 나누어서, 개별의 프로세서에 할당하도록 하는 것으로 달성된다. 이것에 의해, 시뮬레이션의 추정적(speculative) 실행을 위해 최적의 코드를 출력하는 것이 가능하다.

즉, 본 발명의 처리 프로그램은 복수의 처리 블록에서 발생하는, 고속화하고자 하는 프로그램의 소스 코드를 읽어서, 크리티컬 패쓰가 가능한 커트를 모두 테스트하여, 결과의 커트가 된 처리 블록의 흐름의 처리 시간이 제일 적어지는 커트롤 골라낸다.

이와 같은 처리 시간의 추정을(estimimation)을 가능하게 하기 위해, 미리, 처리 프로그램을 컴파일하여, 각 처리 블록의 실행 시간 및 그 외의 값을 계측할 단계(phase)가 수행된다. 이 때 계측되는 값에는, 처리가 다른 프로세서에 겹친 경우에 메시징의 코스트, 추정적 실행을 위해 필요한 처리, 추정(speculation)이 실패한 경우의 롤백(rollback)의 코스트(cost), 또는 각 블록에의 입력 예측이 어느 정도인지(즉, 추정 성공 확률) 등의 계측 데이터도 포함된다.

크리티컬 패쓰가 가능한 커트의 처리는, 커트를 한 결과의 패쓰에 대해서, 재귀적으로 적용된다. 그래서, 이 이상 커트해도, 프로세서 사이의 통신 시간 등을 더하면 오히려 전체의 처리 시간이 길어져 버릴 것 같은 단계에서, 커트를 정지한다. 이것에 의해, 복수의 처리 블록의 군이 얻어진다. 특히, 이 명세서의 설명에서는, 각 처리 블록의 군을, 블록 청크(block chunck)라고 한다.

이렇게 하여 분할 생성된 블록 청크의 수가, 멀티 프로세서 시스템의 프로세서의 수와 동등 또는 그 이하이면, 개개의 블록 청크는, 그대로 컴파일되어서, 실행 환경에서, 개별의 프로세서에 각각, 할당된다.

하지만, 블록 청크의 수가 프로세서의 수보다 많은 경우, 본 발명의 처리 프로그램은, 블록 청크의 수가 프로세서의 수에 동등하게 되도록 블록 청크의 결합을 시도한다. 이때, 바람직하게는, 결과의 결합된 블록 청크 중 크리티컬 패쓰에 관계되는 처리 시간의 최대값이 제일 작아지는 결합이 선택된다.

그 결과의 블록 청크는 컴파일되어, 실행 환경에서 개별 프로세서에 각각 할당한다. 이렇게 하여 모든 블록 청크 하나에 하나의 프로세서가 배정(assign)되기 때문에 최적의 병렬 처리가 수행된다.

이상과 같이, 본 발명에 의하면, 멀티 프로세서 환경에서 크리티컬 패쓰의 길이와 프로세서 할당의 양쪽에 대해 개선된 고속 프로그램의 실행이 가능해진다.또한, 시뮬레이션의 추정적 실행을 위해서 최적한 코드를 출력할 수 있다.

도 1은 시뮬레이션 모델링 툴의 블록 선도의 예를 나타낸 도이다.
도 2는 CP 스케줄링 기법의 예를 나타낸 도이다.
도 3은 본 발명을 실시하기 위한 하드웨어의 블록도이다.
도 4는 본 발명의 하나의 실시 예의 기능 블록도이다.
도 5는 본 발명의 하나의 실시 예의 처리의 흐름을 나타낸 도이다.
도 6은 크리티컬 패쓰를 커트하는 처리의 흐름도이다.
도 7은 크리티컬 패쓰를 커트하는 처리의 흐름도이다.
도 8은 크리티컬 패쓰를 커트하는 처리의 예의 모식도이다.
도 9는 추정(speculation)을 포함한 경우 기대되는 실행 시간을 나타낸 도이다.
도 10은 블록 청크 형성 처리의 예의 모식도이다.
도 11은 CPU 할당용 코드 생성 처리 흐름도이다.
도 12는 CPU 할당용 코드 생성 처리의 흐름도이다.
도 13은 블록 청크 결합 처리의 예의 모식도이다.
도 14는 블록 청크 결합 처리의 예의 모식도이다.
도 15는 블록의 사이의 의존 관계를 설명하기 위한 도이다.

이하, 도면을 참조하여 본 발명의 실시 예의 구성 및 프로세싱을 설명한다. 이하의 기술에서는, 특별히 다르게 언급하지 않는 한, 도면 전체에서 동일 요소는 동일 부호로 참조되는 것으로 한다. 또한, 여기서 설명하는 구성과 프로세싱은, 실시예로서 설명하는 것이지, 본 발명의 기술적 범위를 이러한 실시 예로 한정하여 해석하여서는 아니될 것이다.

다음으로, 도 3을 참조하여, 본 발명의 실시에 사용되는 컴퓨터의 하드웨어에 대하여 설명한다. 도 5에서, 호스트 버스(302)에는, 복수의 CPU1(304a), CPU2(304b), CPU3(304c), ..., CPUn(304n)가 접속된다. 호스트 버스(502)에는 CPU1(304a), CPU2(304b), CPU3(304c), ...CPUn(304n)의 연산 처리를 위한 메인 메모리(306)가 접속된다.

한편, I/O 버스(308)에는, 키보드(310), 마우스(312), 디스플레이(314) 및 하드디스크 드라이브(316)가 접속된다. I/O 버스(308)는, I/O 브리지(318)를 통해, 호스트 버스(302)에 접속된다. 키보드(310) 및 마우스(312)는 오퍼레이터(operator)가 커맨드를 입력하거나 메뉴를 클릭하는 조작 등의 조작을 위해 사용된다. 디스플레이(314)는 필요에 따라 후술하는 본 발명에 관계되는 프로그램을 GUI에서 조작하기 위한 메뉴를 표시하기 위해 사용된다.

이 목적을 위해 사용되는 바람직한 컴퓨터 시스템의 하드웨어로서, IBM(R)System X가 있다. IBM(R)System X가 사용되는 경우, CPU1(304a), CPU2(304b), CPU3(304c), ..., CPUn(304n)은, 예를 들어, 인텔(R) Xeon (R)이고, 오퍼레이팅 시스템은 Windows(상표) Server 2003이다. 오퍼레이팅 시스템은 하드 디스크 드라이브(316)에 저장되고, 컴퓨터 시스템이 기동할 때에 하드 디스크 드라이브(316)로부터 메인 메모리(306)에 읽혀진다.

또한, 본 발명을 실시하기 위해 사용가능한 컴퓨터 시스템의 하드웨어는, IBM(R) System X로 한정되지 않고, 본 발명의 시뮬레이션 프로그램이 가능한 것이라면, 어떤 컴퓨터 시스템이든지 사용될 수 있다. 오퍼레이팅 시스템도 또한 Windows(R)로 한정되지 않고, Linux(R), Mac OS(R) 등의 어떤 오퍼레이팅 시스템이든지 사용될 수 있다. 또한, 시뮬레이션 프로그램을 고속으로 동작시키기 위해, POWER(상표) 6베이스이고, 오퍼레이팅 시스템이 AIX(상표)의 IBM(R) System P 등의 컴퓨터 시스템을 사용해도 된다.

하드 디스크 드라이브(316)에는, NATLAB(R)/Simulink(R), C 컴파일러 또는, C++ 컴파일러, 본 발명에 관계되는 크리티컬 패쓰를 커트하기 위한 모듈, CPU 할당용 코드 생성 모듈, 처리 블록의 예상되는 실행 시간을 측정하기 위한 모듈 등이 저장되어 있고, 오퍼레이터의 키보드나, 마우스 조작에 응답하여, 메인 메모리(306)에 로드되어 실행된다.

또한, 사용가능한 시뮬레이션 모델링 툴은, MATLAB(R)/Simulink(R)로 한정되지 않고, 오픈 소스(open-source)의 Scilab/Scicos 등 임의의 시뮬레이션 모델링 툴을 사용할 수 있다.

또는, 경우에 따라서는, 시뮬레이션 모델링 툴을 사용하지 않고, 직접, C, C++ 등으로 시뮬레이션 시스템의 소스 코드를 작성하는 것도 가능하며, 이 경우에도, 본 발명은 적용가능하다.

도 4는, 본 발명의 실시 예에 관계되는 기능 블록도이다. 각각의 블록은, 기본적으로, 하드 디스크 드라이브(316)에 저장된 모듈에 대응한다.

도 4에서, 시뮬레이션 모델링 툴(402)은 MATLAB(R)/Simulink(R), Scilab/Scicos 등의 기존의 어떤 툴이든 가능하다. 시뮬레이션 모델링 툴(402)은, 기본적으로는, 오퍼레이터가 디스플레이(314) 상에서 GUI 식으로 기능 블록을 배치하고, 수식 등 필요한 속성을 기술하고, 필요에 따라서, 기능 블록 사이를 관련지어 블록도를 기술하는 것이 가능하도록 하는 기능을 가진다. 시뮬레이션 모델링 툴(402)에는, 기술된 블록 선도에 등가 한 기능을 기술하는 C의 소스 코드를 출력하는 기능을 가진다. C 이외에도, C++, Fortran 등을 사용할 수 있다.

또한, 시뮬레이션 모델링 툴은 다른 퍼스널 컴퓨터에 도입되어 그 퍼스널 컴퓨터에서 발생한 소스 코드를 네트워크 등을 경유하여 하드 디스크 드라이브(316)에 다운로드하도록 할 수도 있다.

이렇게 하여 출력된 소스 코드(404)는 하드 디스크 드라이브(316)에 보존된다. 소스 코드(404)는, 컴파일러(406)에서 컴파일되고, 결과의 실행가능 프로그램은 테스트 모듈(408)로 전송된다.

테스트 모듈(408)은 실행 테스트를 수행하는 기능과 추정적 테스트(speculative test)를 수행하는 기능을 포함한다. 실행 테스트에서는, 소정의 시나리오에 따라, 도 1에 나타낸 것과 같이 각 블록의 평균 처리 시간, 프로세서 간 통신 시간, 및 투기 성공 확률이 측정된다. 평균 시간을 측정하기 위해, 바람직하게는 동일한 시나리오가 복수 회 실행된다. 그 측정 결과(410)는 이후에 사용하기 위해 하드 디스크 드라이브(316)에 보존된다.

추정적 테스트에서는, 다른 소정의 시나리오에 따라, 결과의 실행가능 프로그램을 추정적으로 실행시킨다. 이 시나리오를 반복하는 것으로, 추정 준비(speculation preparation)의 처리 시간 즉, 추정이 실패해서 롤백(rollback)할 경우에 대비하여, 예측한 입력치를 보존하거나 하는 처리를 위한 시간과, 추정 성부(成否) 확인의 처리 시간 즉, 실제의 데이터가 왔을 때에 그것이 예측한 데이터와 일치하는지를 확인하는 처리의 시간과, 롤백 처리 시간 즉, 추정이 실패했다, 즉 예측한 입력과 실제의 값이 다르다는 것을 알았을 때에, 틀린 입력에 근거하여 수행된 처리를 멈추거나, 데이터의 삭제 등의 후 처리에 필요한 시간이 계측된다. 그와 같은 값도 또한 그 계측 결과(410)로서 나중에 사용하기 위해 하드 디스크 드라이브(316)에 보존된다.

또한, 추정 성공 확률은, 사실은 실제로 추정 실행을 수행하지 않아도 산출할 수 있다. 추정 실행에서는, 본래 와야 할 입력이 오기 전에 처리가 실행되기 때문에, 그 입력을 예측하여 처리가 실행된다. 따라서, 추정이 성공할 확률은, 입력에 대한 예측이 적중할 확률과 동등해진다. 그 입력을 예측하는 알고리즘이 정해져 있으면, 실제로 추정 실행을 하지 않아도(즉, 예측한 입력 데이터에 근거하는 블록의 처리를 실행하지 않아도) 실제의 입력 데이터만으로, 예측 알고리즘의 예측 성공 확률을 산출할 수 있다. 즉, 단지 실행 테스트에서, 각 블록에 대한 입력을 기록해 두고, 그 입력 데이터 계열(input data series)에서, 입력 예측 알고리즘의 예측 성공률을 산출하는 것으로, 추정 성공 확률을 구할 수 있다. 한편, 추정 실행을 했을 때, 또는 추정 실행이 실패했을 때에 어느 정도의 시간이 걸리는지는, 실제로 추정 실행을 하지 않으면 모른다. 이 때문에, 그것들의 정보를 얻기 위해 추정 테스트가 수행된다. 단, 추정 실행의 실장(implementation)이 정해지면, 추정 준비나 추정의 성부 확인, 추정 실패시의 롤백에 필요한 처리 시간은, 입력 데이터 량에 비례한 처리 시간이 될 것으로 예상된다. 따라서, 추정적 테스트에서는, 모든 블록을 추정적으로 실행하지 않아도 되고, 몇 개의, 입력 데이터 량이 다른 블록을 추정적으로 실행하는 것으로, 입력 데이터 량과 추정 관련 처리 시간의 관계가 얻어져, 이것에 근거하여 모든 경우의 코스트를 산출할 수 있다.

크리티컬 패쓰의 커트 모듈(412)은, 소스 코드(404)를 원칙적으로 블록 단위로 처리하여, 크리티컬 패쓰를 찾아내고, 커트를 넣어서, 최적한 실행 시간이 되는 커트를 찾아내는 기능을 가진다. 이 때, 측정 결과(410)의 정보가 사용된다. 모듈(412)은 또한, 크리티컬 패쓰의 커트 기능을 재귀적으로 적용하여, 도 10에 나타낸 것처럼, 작게 나눈 블록 청크를 얻는다. 그렇게 해서 생성한 블록 청크의 정보(414)는, 나중에 사용하기 위해, 하드 디스크 드라이브(316)에 보존된다. 크리티컬 패쓰의 커트 기능은 후반부에 흐름도를 참조하여 상세하게 설명한다.

CPU 할당용 코드 생성 모듈(416)은, 블록 청크의 정보(414)와 측정 결과(410)를 이용하여, CPU(1)~ CPU(n)에 할당할 코드(418a, 418b, ..., 418m)를 생성한다. 만약 블록 청크의 수가 CPU(1)~ CPU(n)의 수보다 적거나 같으면, 각 블록 청크의 코드는 그대로 CPU(1)~CPU(n)에 할당된다.

그러나 만약 블록 청크의 수가 CPU(1)~ CPU(n)의 수보다 많으면, 도 14에 모식적으로 나타낸 것처럼, 블록 청크의 수가 CPU(1)~ CPU(n)의 수와 같아지도록, 블록 청크끼리 결합된다. 단, 이 때의 결합은, 바람직하게는, 결과의 크리티컬 패쓰의 기대되는 실행 시간이 제일 짧아지도록 최적으로 선택된다. CPU 할당용 코드 생성 기능도 후반부에 흐름도를 참조하여 상세하게 설명한다.

이 결과 생성되는 것은 CPU(1)~ CPU(n)에 할당하는 코드(418a, 418b, ..., 418m)과, 의존 관계의 정보(420)이다. 의존 관계의 정보(420)가 필요한 이유는 다음과 같다. 즉, 도 10에 나타낸 것처럼, 원래의 처리의 흐름이 크리티컬 패쓰의 커트 기능에 의해 분단되면, 원래의 블록 간의 의존 관계가 끊어져 버리는 일이 있다. 이것을 막기 위해서, 모듈(416)은, 예를 들면, CPU(1)~ CPU(n)에 할당하는 코드(418a, 418b, ..., 418m) 중 어느 코드가 다른 어느 코드로 사용되는 변수를 리턴할 지 등의 의존 관계의 정보(420)도 제공한다. 실제, 의존 관계의 정보(420)는 크리티컬 패쓰의 커트 모듈(412)에 의해 커트할 시에 작성되기 때문에, CPU 할당용 코드 생성 모듈(416)은 그것을 이용하게 된다.

이렇게 하여 생성된 코드(418a, 418b, ..., 418m)는 컴파일러(422)에서 개별적으로 실행가능 프로그램으로서 컴파일되어, 실행 환경(424)에서는, 대응하는 CPU(1)~ CPU(n) 상에서 병렬 실행되도록 개별적으로 할당된다. 또한, 의존 관계의 정보(420)는 CPU(1)~ CPU(n)에 의해 공동으로 참조 가능하게, 메인 메모리(306)의 공동 메모리 영역에 배치되고, CPU(1)~ CPU(n)이 코드(418a, 418b, ..., 418m)를 실행할 때에, 필요에 따라서, 다른 CPU 상에서 실행되는 코드의 정보를 참조하기 위해 사용된다.

도 5는, 이 실시 예의 전체의 처리의 흐름을 나타낸다. 이는 작업 순서를 나타내는 흐름이며, 개별적으로는 꼭 컴퓨터의 처리의 흐름과는 대응하지 않는다는 것을 이해해 주길 바란다.

도 5에서 단계(502)에서는, 개발자 또는 작업자가, MATLAB(R)/Simulink(R) 등의 시뮬레이션 모델링 툴(402)을 사용하여, 특정의 시뮬레이션 대상의 블록도를, 도 3에 나타낸 시스템 또는 다른 컴퓨터 상에서 작성한다.

단계(504)에서는, 개발자 또는 작업자가 작성한 블록도에 대응하는 소스 코드(404)를 시뮬레이션 모델링 툴(402)의 기능을 사용하여 생성하고, 하드 디스크 드라이브(316)에 보존한다.

단계(506)에서는, 개발자 또는 작업자가 컴파일러(406)를 사용하여 소스 코드(404)를 컴파일한다. 컴파일된 실행 가능 프로그램은, 도시되지 않았으나, 일단, 하드 디스크 드라이브(316)에 보존된다.

단계(508)에서는, 개발자 또는 작업자가 컴파일된 실행 프로그램을 사용하여, 테스트 모듈(408)에서 실행 테스트를 수행한다. 이 결과 얻어진 블록의 평균 처리 시간, 프로세서 간 통신 시간, 및 추정 성공 확률의 실행 시간의 계측 데이터는, 단계(510)에서, 계측 결과(410)로서 하드 디스크 드라이브(316)에 보존된다.

단계(512)에서는, 개발자 또는 작업자가 컴파일된 실행 프로그램을 사용하여, 테스트 모듈(408)에서 추정 테스트를 수행한다. 이 결과 얻어진 추정 준비의 처리 시간, 추정 성부 확인의 처리 시간, 및 롤백 처리 시간의 계측 데이터는, 단계(514)에서, 계측 결과(410)으로서 하드 디스크 드라이브(316)에 보존된다.

단계(516)에서는 개발자 또는 작업자의 조작에 응답하여 컴퓨터의 처리가 개시된다. 즉, 기본적으로 단계(516)에서부터 단계(524)까지는 컴퓨터의 처리에 따라 자동적으로 진행한다.

단계(516)에서는, 크리티컬 패쓰의 커트 모듈(412)에 의해 소스 코드(404)가 처리된다. 구체적인 처리는 후술하지만, 소스 코드(404)에 기술된 전체의 처리 흐름에서 크리티컬 패쓰를 알고리즘에 의해 발견하여, 그것을 처리 시간적으로 최적하게 커트하고, 커트한 후의 처리 흐름에서, 크리티컬 패쓰를 커트한다고 하는 처리를 재귀적으로 수행한다. 이 때에, 계측 결과(410)가 이용된다.

이 결과, 도 10에 나타낸 것처럼 복수의 블록 청크가 얻어지기 때문에, 단계(518)에서, 그것들에 관한 정보가 블록 청크(414)로서 하드 디스크 드라이브(316)에 보존된다. 또한, 이 때 보존되는 데이터 구조는, XML 등과 같이, 컴퓨터로 해독할 수 있고, 소스 코드 내용과 연결 관계(링크)의 양쪽을 표현 가능한 임의의 데이터 구조를 이용할 수 있다.

단계(520)에서는, 블록 청크(514)의 정보를 이용하여, CPU 할당용 코드 생성 모듈(416)이 CPU(1)~ CPU(n)에 개별적으로 할당하기 위해서 코드를 생성한다. 즉, 만약 블록 청크의 수가 CPU(1)~CPU(n)의 개수보다 적으면, 그대로 하나씩 CPU(1)~CPU(n)에 할당한다. 한편, CPU(1)~ CPU(n)의 개수보다 블록 청크의 수가 많으면, CPU(1)~ CPU(n)의 개수와 동등해지도록 블록 청크가 실행 시간적으로 최단이 되도록 결합한다. 이 때에, 측정 결과(410)가 이용된다.

단계(522)에서는, 모듈(416)에 의해 생성된 코드가 컴파일러(422)에 의해 컴파일되어, 단계(524)에서, 각각에 대응하는 프로세서 CPU(1)~CPU(n)에 할당되어 각각 실행된다.

다음으로, 도 6과 도 7의 흐름도를 참고하여, 도 5의 단계(516)에 대응하는 크리티컬 패쓰의 커트 처리를 설명한다. 단계(602)에서는, 크리티컬 패쓰의 최적의 커트를 찾아내는 처리가 수행된다. 여기에서 최적의 커트가 어떤 것인지를 설명하기 위해 도 8을 참조한다.

도 8에서는 블록 A~I에서 발생하는 처리의 흐름이 나타내었다. 여기에서, 크리티컬 패쓰를 발견하는 알고리즘에 의해, B-C-D-E-F가 크리티컬 패쓰라고 확인(identify)되었다고 하면, 단계(602)에서는, B-C-D-E-F에 따른 가능한 커트 c2, c3, c4를 크리티컬 패쓰의 커트 모듈(412)이 순차 테스트하게 된다. 예를 들면, 컷 c3을 테스트한다는 것은 c3에서 크리티컬 패쓰를 커트하고, 도 8에 나타낸 것처럼, 커트된 흐름은 논리적으로 옆으로 이동된다. 그러면, 두 개의 흐름이 병치된다. 여기서 커트 c3을 평가한다. 커트 c3을 평가한다는 것은, 만약 추정 성공 확률이 100%라고 가정하면, 병치된 두 개의 흐름의 기대되는 실행 시간을 비교하여, 더 긴 쪽의 값 T_c를 평가하게 된다. 그러나, 일반적으로는, 추정 성공 확률은 100%보다 낮기 때문에, 도 9에서 설명한 것처럼, 추정 성공 확률을 고려하여, T_c가 평가된다. 이와 같은 T_c가 제일 짧아지는 커트를 최적한 커트라고 한다.

최적한 커트를 찾아내기 위한 보다 자세한 처리(서브루틴)는 후반부에 도 7의 흐름도를 참조하여 설명한다.

또한, 각 블록의 기대되는 실행 시간은, 도 5의 단계(508)에 나타낸 실행 테스트에서 미리 계측되고, 계측 결과(410)로서 하드 디스크 드라이브(316)에 보존된다. 이와 같은 계측 결과(410)가, 주어진 흐름의 기대되는 실행 시간을 계산할 때에 사용되는 것에 유의하길 바란다.

실제, 실행 시간을 평가(estimate)하기 위해, 단순히 흐름에 따라서 블록의 기대되는 실행 시간을 실행하는 것만으로는 안 된다. 이에 관한 것을 도 9를 참조하여 설명한다.

여기서 다음과 같은 변수를 정의한다. 여기서, 코스트란 시간이라고 간주해도 된다.

MSCxy: 블록 X와 블록 Y가 커트될 때의 블록 X로부터 블록 Y에 대한 메시지 송신 코스트.

MRCxy: 블록 X와 블록 Y가 커트될 때의 블록 X로부터 블록 Y에 대한 메시지 수신 코스트.

SCxy: 블록 X로부터 블록 Y에 대한 추정 코스트.

SCCxy: 블록 X로부터 블록 Y에 대한 추정 체크 코스트.

RBCxy: 블록 X로부터 블록 Y에 대한 추정이 실패했을 경우의 롤백 코스트.

이것들의 블록 사이의 코스트도, 도 5의 단계(508)에 나타낸 실행 코스트 및 단계(512)에서 나타낸 투기 테스트에서 미리 계측되어, 계측 결과(410)로서 하드 디스크 드라이브(316)에 보존된다.

그러면, 크리티컬 패쓰 B-C-D-E-F의 C와 D의 사이에 커트 c를 넣는다는 것은, 결과의 기대되는 실행 시간을 도 9에 나타낸 것처럼, 추정이 성공한 경우와 추정이 실패한 경우와의 기대치에서 평가할 필요가 있다.

추정이 성공한 경우는, 커트한 결과의 두 개의 흐름의 긴 쪽의 실행 시간이 결과의 기대되는 시간이 되고, 그것은,

T_cs = |D|+|E|+|F|+SCcd+MRCif+MRCcd+SCCcd

여기서, 예를 들면 |D|는, 블록 D의 실행 시간을 나타낸다.

한편, 추정이 실패했을 경우는, B-C와, D-E-F가 직렬 실행되기 때문에, 기대되는 시간은,

T_cf = |B|+|C|+|D|+|E|+|F|+MRCac+MSCcd+MRCcd+RBCcd+MRCif

그런데, 이와 같은 추정의 성공 확률 p_c는, 도 5의 단계(508)에 나타낸 실행 테스트에서 미리 계측되고, 계측 결과(410)로서 하드 디스크 드라이브(316)에 보존된다. 이것을 이용하여, 결과의 기대되는 실행 시간은,

T_c = p_cT_cs + (1-p_c)T_cf 로 계산된다.

도 6의 흐름도로 돌아와서, 단계(602)의 처리의 결과를 가지고, 단계(604)에서는 크리티컬 패쓰의 커트 모듈(412)이 최적의 커트가 존재하는지를 결정한다. 최적의 커트가 존재한다는 것은, 커트한 결과, 전체의 기대되는 처리의 시간이 단축되는 것을 의미한다. 어떤 경우에도 커트하면 처리 시간이 단축된다고는 할 수 없다. 즉, 상기한 송신 코스트, 수신 코스트, 및 추정 코스트를 감안해 보면, 커트해도 처리 시간의 단축을 도모할 수 없는 경우가 있다. 그와 같은 경우 단계(604)에서 최적의 커트가 존재하지 않는다고 결정하여, 단계(606)에서, 현재 평가하고 있는 블록 청크의 정보가 바람직하게는 하드 디스크 드라이브(316)에 보존된다.

한편, 단계(604)에서 최적의 커트가 존재한다고 결정되면, 크리티컬 패쓰의 커트 모듈(412)은, 단계(608)에서, 커트된 블록을 이동시킨다. 이것은, 도 8에 나타낸 것과 같은 처리이다.

단계(610)에서는, 커트되어 발생한 패쓰의 집합 전체에 대해서, 도 6의 흐름도의 처리가 재귀적으로 호출된다. 도 8의 블록에서 설명하면, 우선 블록 A, B, C, D, E, F, G, H, I에 대해서 도 6의 흐름도의 처리가 적용된 결과, 블록 A, B, C, D, E, F와, 블록 G, H, I로 나뉘어, 거기서, 도 6의 흐름도의 처리가 재귀적으로 호출된다.

다음으로, 도 7의 흐름도를 참조하여, 도 6의 단계(602)의 처리를 더욱 상세하게 설명한다. 단계(702)에서는, 크리티컬 패쓰를 찾아내는 처리가 수행된다. 처리 흐름에 대해서 크리티컬 패쓰를 찾아내는 처리 자체는 종래에 알려져 있으며,

예를 들면, http://www.kogures.com/hitoshi/webtext/pt-pert/index.html에 기술된 PERT의 방법 등을 사용할 수 있다.

단계(704)에서는, t_min = 크리티컬 패쓰에 따라서 기대되는 시간, c_min = null, C = 크리티컬 패쓰가 가능한 커트의 집합으로 세트된다.

단계(706)에서는, C가 비었는지를 결정하고, 비어있지 않으면, 단계(708)로 진행하여, C로부터 커트 c를 꺼낸다.

단계(710)에서는 커트 c의 기대되는 실행 시간이 계산되어, 그것이 t_c에 대입된다. 여기에서의 실행 시간의 계산은, 도 9에 관련하여 설명한, 추정 실행의 경우도 포함한다.

단계(712)에서는, t_c < t_min 인지를 결정하여, 만약 그렇다면, 단계(714)에서 t_min = t_c, c_min = c로 세트된다.

이와 같이, C의 모든 커트에 대해서, 단계(708, 710, 712 및 714)가 실행되어, 결과의 c_min이 도 6의 단계 602로 리턴된다. 이 때, C의 어떠한 커트도, t_min = 크리티컬 패쓰에 따라서 기대되는 시간보다 처리 시간을 단축시키지 않는 경우가 있다. 이와 같은 경우, 단계(712)에서의 결정은 긍정적(YES)으로 되지 않기 때문에, 단계(714)는 실행되지 않고, 따라서, c_min = null로 남아 있다. 그러면, 도 6의 단계(604)의 결정은 부정적(NO)이 된다.

이와 같은 처리의 결과를 모식적으로 나타낸 것이, 도 10이다. 도 10의 왼쪽에 나타낸 블록의 처리의 흐름이, 도 6의 흐름도에 나타낸 처리의 재귀적 흐름에 의해 복수 부분으로 커트되어, 도 10의 오른쪽에 나타낸 것과 같이, 세분화된 복수의 블록 청크가 얻어진다.

다음으로, 도 11과 도 12의 흐름도를 참조해서, 도 5의 단계(520)에 대응하는 CPU 할당 코드 생성의 처리를 설명한다. 이것은, 도 4의 CPU 할당 코드 생성 모듈(416)에 의해 실행된다.

단계(1102)에서는, p=프로세서(CPU)의 수, b=블록 청크의 수로 세트된다.

단계(1104)에서는, p<b인지를 결정한다. 이것이 부정적(NO), 즉, p>=b라면, 그대로 블록 청크를 개개에 할당할 뿐인 수의 프로세서가 있으므로, 단계(1106)에서, 적절한 개개의 블록 청크를 개개의 프로세서에 할당하여 처리는 종료한다.

단계(1104)에서, p<b라고 결정되었으면, 그대로 블록 청크를 개개에 할당하기에는 프로세서의 수가 부족한 것을 의미하기 때문에, 단계(1108)에서, 두 개의 블록 청크를 결합해서, 블록 청크의 수를 한 개 줄이는 처리가 수행된다.

두 개의 블록 청크를 결합한다고 하는 것은, 그 결합한 블록 청크에서, 크리티컬 패쓰가 길어져 기대되는 처리 시간이 길어지는 경우가 있다. 여기서 단계(1108)에서는, 두 개의 블록 청크를 결합한 결과의 기대되는 처리 시간이 최단이 되도록 최적의 조합을 찾아낸다. 그와 같은 처리를 모식적으로 나타낸 것이, 도 14이다.

단계(1110)에서는, b가 1 줄어들어, 단계(1104)의 판단 단계로 돌아온다. 이렇게 해서, p=b가 되기까지, 단계(1108)와 단계(1110)가 반복된다.

P=b이면, 단계(1104)가 부정적(NO)이 된다. 그러면 지금이야말로, 그대로 블록 청크를 개개에 할당하는 것 뿐인 수의 프로세서가 있기 때문에, 단계(1106)에서, 그 시점에 보존된 결과의 개개의 블록 청크를 개개의 프로세서에 할당해서, 처리는 종료한다.

또한, 몇 개의 CPU를 다른 처리를 위해서 보류하고 싶은 경우에는, b>P가 되기까지 블록 청크의 수를 줄이는 경우가 있다.

도 12는, 도 11의 단계(1108)의 처리를 보다 상세하게 나타낸 흐름도이다. 도 12에서, 단계(1202)에서는, S₁ = 현재의 블록 청크의 집합, t_min = ∝, u_min = ∝, b₁ = b₂ = null로 주어진다. 여기에서, ∝라고 하는 것은, 이 상황에서, 실제적으로 상정되는 수보다 충분히 큰 적당한 정수라고 하는 의미이다.

단계(1204)에서는 S₁이 비었는지를 결정하여, 만약 비었다면 처리가 완료되고, 도 11의 흐름도의 단계(1108)에 돌아온다. S₁이 비어있지 않으면, 단계(1206)에서 S₁으로부터 하나의 블록 청크 s₁이 꺼내진다.

단계(1208)에서는, S₂ = 현재의 블록 청크의 집합이라고 세트된다. 단계(1210)에서는, S₂가 비었는지를 결정하여, 만약 비었다면, 단계(1204)로 돌아온다. S₂가 비어있지 않으면, 단계(1212)에서, S₂로부터 하나의 블록 청크 s₂가 꺼내진다.

단계(1214)에서, s₂가 s₁의 아래에 결합되었을 때의 실행 시간이, 도 4에 나타낸 각 블록의 계측 결과(410)를 사용하여 계산되어, T_s1s2에 대입된다. 여기에서, s₂=s₁이 되는 경우는 생략된다. 또, 어느 블록 청크도, 오리지널 블록의 흐름의 일부이기 때문에, 임의의 두 개의 블록 청크의 사이에서, 어느 쪽이 원래부터 업스트림(upstream) 측이었는지를 결정할 수 있는 경우가 있다. 여기서, 바람직하게는, 단계(1214)에서는, 오리지널의 업스트림/다운스트림 관계가 결정할 수 있다면, 이 업스트림/다운스트림 관계를 유지하도록, 결합시켜도 된다.

단계(1216)에서는, T_s1s2가 T_min과 동등한지를 결정한다. 만약 동등하다면, 단계(1218)에서, s₂가 s₁의 아래에 결합되었을 때의 기대되는 코스트가 계산되어, U_s1s2에 대입된다. 여기에서 코스트란, 각 블록의 실행 시간, 서로 다른 프로세서에 걸친 프로세서 사이의 메시지 송수신 코스트, 추정 코스트, 추정 체크 코스트, 추정 실패 시의 롤백 코스트에, 가능한 추정 성부의 조합 때마다 추정 성공 확률로 중요도를 부여하여 산출하는, 모든 CPU 소비 시간의 기대치이다.

다음으로, 단계(1220)에서는 U_s1s2 < U_min 인지를 결정하여, 만약 그렇다면, 단계(1222)에서, T_min = t_s1s2, b₁ = s₁, b₂ = s₂, U_min에는, s₂가 s₁의 아래에 결합되었을 때의 기대되는 코스트가 대입된다. 단계(1222)에서부터는, 단계(1210)의 결정으로 돌아온다.

한편, 단계(1216)에서, T_s1s2가 T_min과 동등하지 않으면, 단계(1224)에 진행하고, 여기서, T_s1s2 < T_min 인지가 결정된다. 만약 그렇다면, 단계(1222)가 실행되고 나서 단계(1210)의 결정으로 돌아온다. 그렇지 않다면, 단계(1224)로부터 바로 단계(1210)의 결정으로 돌아온다.

도 13은, 블록 청크의 결합의 예를 나타낸다. 그 예에서는, 도시한 대로 블록 청크 bc1, bc2, bc3, bc4의 4개가 있다고 하자. 그러면 이제부터는, 오리지널 흐름의 업스트림/다운스트림을 선택하지 않는다면, 12가지의 결합이 가능하지만, 그 모든 것을 망라해서 설명하는 것은 길기 때문에, 대표적으로, 왼쪽 아래에 나타낸, bc3이 bc2의 아래에 결합된 경우와, 오른쪽 아래에 나타낸 bc4가 bc1의 아래에 결합된 경우에 대해서 설명한다.

우선, bc3이 bc2의 아래에 결합된 경우라면, 기대되는 실행 시간 t_bc2bc3과, 기대되는 코스트 U_bc2bc3은 각각, 다음과 같이 계산된다.

t_bc2bc3 = |B|+|C|+|D|+|E|+|F|+MRCac+MRCif

U_bc2bc3 = |A|+|B|+|C|+|D|+|E|+|F|+|G|+|G|+|H|+|I|+MRCac+MRCif+MSCac+MSCif

한편, bc4가 bc1의 아래에 결합된 경우라면, 기대되는 실행 시간 t_bcbc4와, 기대되는 코스트 U_bc1bc4는 각각, 다음과 같이 계산된다.

여기서, p₁ 및 p₂는 도시된 경로에서의 추정 성공 확률이다.

상기의 개개의 값은 모두, 계측 결과(410)으로부터 취득된다.

도 14는, 블록 청크 bc1, bc2, bc3, bc4, bc5, bc6의 6개 있으며, 한편 CPU가 5개밖에 없는 경우에, 블록 청크를 하나 줄이기 위해서, CPU 할당용 코드 생성 모듈(416)이, 두 개의 블록 청크의 결합을 시도할 경우의 처리를 나타낸 도이다.

도 14의 왼쪽 아래의 경우에서는, bc4의 아래에 bc6이 결합되어, 결과적으로, bc3이 전체의 최장 실행 시간 t_s1s2가 된다.

도 14의 오른쪽 아래의 경우에서는, bc1의 아래에 bc5가 결합되어, 결과적으로, bc1이 전체의 최장 실행 시간 t_s1s2가 된다.

CPU 할당용 코드 생성 모듈(416)은, 모든 가능한 블록 청크의 조합에 최장의 실행 시간 t_s1s2를 계산해서, 결과적으로 최단의 t_s1s2를 나타내는 블록 청크의 결합을 선택한다.

이와 같이 하여 생성된 CPU 마다 코드는, 각각, 컴파일러(422)에 의해 컴파일 되어 실행 가능 코드에 변환되면, 일단 하드 디스크 드라이브(316)에 보존된다.

그런데, 원래부터 연결되어 있던 블록의 흐름에 커트를 넣으면, 커트된 결과의 각각의 블록의 사이의 의존 관계가 끊어져 버리는 경우가 있기 때문에, 그와 같은 정보를 보충할 필요가 생긴다. 도 15는, 그와 같은 의존 관계를 설명하기 위한 모식도이다.

도 15에서, 블록 A 및 블록 C로부터 발생하는 코드를 Code 1, 블록 B 및 블록 D로부터 발생하는 코드를 Code 2, 블록 F, 블록 H 및 블록 J로부터 발생하는 코드를 Code3, 블록 E, 블록 G 및 블록 I로부터 발생하는 코드를 Code 4라고 한다.

Code 1, Code 2, Code 3, Code 4의 내용은, 도 15에 도시한 대로이다. 그것을 보면, Code 3의 인수(argument)가, 각각, Code 1, Code 2의 Code 4의 최초 결과 값을 사용하고 있다는 것을 알 수 있다.

그것은 예를 들면, 하기와 같이 기술된다.

1st output of Code 1 -> 1st argument of Code 3

1st output of Code 2 -> 2nd argument of Code 3

1st output of Code 3 -> 3rd argument of Code 3

이와 같은 정보는, CPU 할당 코드 생성 모듈(416)이, 개개의 CPU 할당용 코드를 생성할 때에 같이 생성한다.

의존 관계의 정보는, 개개의 CPU 할당용 코드를 포함해서, 컴파일러(422)에 통지할 수 있지만, 바람직하게는, 직접 실행 환경(424)의 공유 메모리 상에 배치하는 등으로, CPU(1)~CPU(n)가 할당된 코드를 실행할 때에, 의존 관계의 정보를 참조할 수 있도록 한다.

이렇게 해서, 오퍼레이터의 조작에 의해, 시뮬레이션 동작이 개시되면, 컴파일러 된 각 CPU용의 실시 가능한 프로그램이 순차, 실행 환경(424)에 의해 메인 메모리(306)에 읽혀져, 실행 환경(424)은, 개개의 실행 가능 프로그램에 관해서 생성한 프로세스를, 개별의 프로세서에 할당한다. 이렇게 해서, 복수의 실행 가능 프로그램에 분할된 시뮬레이션 프로그램은, 개개의 프로세서에 의해 병렬적으로 실행된다.

이상의 실시 예에서는, 시뮬레이션 모델링 툴을 이용해서 생성한 프로그램 소스 코드에 근거하여, 복수의 CPU에 할당하여 병렬화하는 처리에 대해서 설명하였는데, 본 발명은, 그와 같은 시뮬레이션 프로그램 소스 코드로 한정되지 않고, 처리 블록 단위가 확인할 수 있고, 또, 그 흐름이 기술되어 있다면, 임의의 소스 코드에 적용 가능하다.

404 소스 코드
406, 422 컴파일러
412 크리티컬 패쓰의 커트 모듈
418 CPU용 코드
420 의존 관계 정보

Claims (27)

1. 컴퓨터의 처리에 의해, 멀티 프로세서 시스템에서 병렬 실행 가능하게 하기 위해 소스 코드를 생성하는 방법으로,
   프로그램의 소스 코드를 입력하는 단계;
   상기 컴퓨터의 처리에 의해, 상기 프로그램의 소스 코드의 처리의 크리티컬 패쓰(critical path)를 찾아내는 단계; 및
   상기 크리티컬 패쓰를 커트(cut)하여, 상기 멀티 프로세서 시스템의 개개의 프로세서마다 대응하게 상기 소스 코드를 분할하는 단계;를 포함하고,
   상기 소스 코드를 컴파일하여 실행하고 상기 소스 코드의 처리 블록 단위의 처리 시간을 계측하여 기록하는 단계;를 더 포함하고,
   상기 소스 코드를 분할하는 단계는 상기 기록된 처리 시간을 이용하여, 분할된 소스 코드 중 가장 긴 기대되는 처리 시간을 갖는 소스 코드의 기대되는 처리 시간이 적어도 원래의 소스 코드의 처리 시간보다 짧아지도록 분할을 수행하고,
   처리가 서로 다른 프로세서에 걸쳐있는 때의 메시징의 코스트, 추정적(speculative) 실행을 위해 필요한 처리, 추정이 실패했을 때의 롤백(rollback)의 코스트, 및 각 블록에의 입력의 예측이 어느 정도 맞는지의 추정 성공 확률의 데이터를 또한 계측하여 기록하는 단계를 더 포함하고,
   상기 소스 코드를 분할하는 단계는, 상기 기록된 처리 시간을 이용하여, 분할된 소스 코드 중 가장 긴 기대되는 처리 시간을 갖는 소스 코드의 기대되는 처리 시간을 최소화하도록 분할을 수행하는
   소스 코드 처리 방법.
2. 삭제
3. 삭제
4. 삭제
5. 청구항 1에 있어서,
   상기 분할된 소스 코드의 사이의 변수 및 인수의 의존 관계의 정보를 포함하는 정보를 출력하는 단계를 더 포함하는
   소스 코드 처리 방법.
6. 청구항 1에 있어서,
   상기 멀티 프로세서 시스템의 프로세서의 개수와 상기 분할된 소스 코드의 개수를 비교하고, 상기 분할된 소스 코드의 개수가 프로세서의 개수보다 많은 것에 응답하여, 상기 분할된 소스 코드의 개수가 프로세서의 개수와 동등하거나 그 이하가 되도록 상기 분할된 소스 코드를 결합하는 단계를 더 포함하는
   소스 코드 처리 방법.
7. 삭제
8. 청구항 1에 있어서, 상기 소스 코드는 시뮬레이션 모델링 툴의 기능에 의해 생성된 것이며, 상기 소스 코드의 처리 블록 단위는 시뮬레이션 모델링 툴 상의 블록도(block diagram)의 블록에 대응하는
   소스 코드 처리 방법.
9. 컴퓨터의 처리에 의해, 멀티 프로세서 시스템에서 병렬 실행 가능하도록 하기 위해 복수의 소스 코드를 생성하는 시스템으로,
   프로그램의 소스 코드를 보존하는 기록 수단,
   상기 컴퓨터의 처리에 의해, 상기 프로그램의 소스 코드를 읽어, 상기 소스 코드의 처리의 크리티컬 패쓰(critical path)를 찾아내는 수단,
   상기 크리티컬 패쓰를 커트(cut)하여, 상기 멀티 프로세서 시스템의 개개의 프로세서마다 대응하게 상기 소스 코드를 분할하는 수단,
   상기 소스 코드를 컴파일하여 실행하고 상기 소스 코드의 처리 블록 단위의 처리 시간을 계측하여 기록하는 수단을 포함하고,
   상기 소스 코드를 분할하는 수단은, 상기 기록된 처리 시간을 이용하여, 분할된 소스 코드 중 가장 긴 기대되는 처리 시간을 갖는 소스 코드의 기대되는 처리 시간이 적어도 원래의 소스 코드의 처리 시간보다 짧아지도록 분할을 수행하고,
   상기 처리 시간을 계측하여 기록하는 수단은, 처리가 서로 다른 프로세서에 걸쳐있는 때의 메시징의 코스트, 추정적(speculative) 실행을 위해 필요한 처리, 추정이 실패했을 때의 롤백(rollback)의 코스트, 및 각 블록에의 입력의 예측이 어느 정도 맞는지의 추정 성공 확률의 데이터를 또한 계측하여 기록하고,
   상기 소스 코드를 분할하는 수단은, 상기 기록된 처리 시간을 이용하여, 분할된 소스 코드 중 가장 긴 기대되는 처리 시간을 갖는 소스 코드의 기대되는 처리 시간을 최소화하도록 분할을 수행하는
   소스 코드 처리 시스템.
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 멀티 프로세서 시스템에 의해 병렬 실행 가능한 복수의 프로그램을 실행하는 컴퓨터 시스템으로,
    프로그램의 소스 코드를 보존하는 기록 수단,
    상기 컴퓨터의 처리에 의해, 상기 프로그램의 소스 코드를 읽어, 상기 소스 코드의 처리 크리티컬 패쓰(critical path)를 찾아내는 수단,
    상기 크리티컬 패쓰를 커트(cut)하여, 상기 멀티 프로세서 시스템의 개개의 프로세서마다 대응하게 상기 소스 코드를 분할하는 수단,
    상기 분할된 소스 코드를 컴파일하는 수단,
    상기 컴파일된 실행 가능 프로그램을 상기 멀티 프로세서 시스템의 개별의 프로세서에 할당하는 수단,
    상기 소스 코드를 컴파일하여 실행하고 상기 소스 코드의 처리 블록 단위의 처리 시간을 계측하여 기록하는 수단을 포함하고,
    상기 소스 코드를 분할하는 수단은, 상기 기록된 처리 시간을 이용하여, 분할된 소스 코드 중 가장 긴 기대되는 처리 시간을 갖는 소스 코드의 기대되는 처리 시간이 적어도 원래의 소스 코드의 처리 시간보다 짧아지도록 분할을 수행하고,
    상기 처리 시간을 계측하여 기록하는 수단은, 처리가 서로 다른 프로세서에 걸쳐있는 때의 메시징의 코스트, 추정적(speculative) 실행을 위해 필요한 처리, 추정이 실패했을 때의 롤백(rollback)의 코스트, 및 각 블록에의 입력의 예측이 어느 정도 맞는지의 추정 성공 확률의 데이터를 또한 계측하여 기록하고,
    상기 소스 코드를 분할하는 수단은, 상기 기록된 처리 시간을 이용하여, 분할된 소스 코드 중 가장 긴 기대되는 처리 시간을 갖는 소스 코드의 기대되는 처리 시간을 최소화하도록 분할을 수행하는
    컴퓨터 시스템.
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 컴퓨터 판독가능 매체에 있어서,
    상기 컴퓨터 판독가능 매체는 컴퓨터의 처리에 의해 멀티 프로세서 시스템에서 병렬 실행 가능하게 하기 위해 소스 코드를 생성하는 컴퓨터 프로그램을 포함하고, 상기 컴퓨터 프로그램은 상기 청구항 제1항, 제5항, 제6항 및 제8항 중 어느 한 항에 기재된 방법의 각 단계를 컴퓨터가 실행하도록 하는,
    컴퓨터 판독가능 매체.
24. 삭제
25. 삭제
26. 삭제
27. 삭제

Images