All content in this course uses:

Unity 잡 시스템 시작하기

이 튜토리얼에서는 멀티코어 CPU를 활용하기 위해 잡을 사용하는 기본적인 방법을 소개합니다. 

이 튜토리얼에서 배울 내용은 다음과 같습니다.

싱글 스레드 잡을 생성, 예약, 완료합니다.

병렬 잡을 생성, 예약, 완료합니다.

다른 잡에 종속되는 잡을 예약합니다.

Jobs.zip

이 튜토리얼에서는 멀티코어 CPU를 활용하기 위해 잡을 사용하는 기본적인 방법을 소개합니다. GitHub의 

 샘플을 단계별로 살펴보겠습니다.

이 샘플에서는 2D 평면에서 각각 무작위 방향으로 천천히 이동하는 탐색기(파란색 큐브)와 타겟(빨간색 큐브)을 먼저 만나게 됩니다. 이때 과제는 각 탐색기에서 가장 가까운 타겟까지 실시간으로 흰색 디버그 라인을 그리는 것입니다.

우선 잡을 사용하지 않고 문제를 해결하는 방법을 살펴보겠습니다. 그런 다음 잡을 사용하여 이 문제를 해결하는 방법을 알아보고 프로파일을 살펴보면서 성능 향상을 확인하겠습니다.

이 튜토리얼의 약간 다른 버전을 보려면 아래 동영상을 시청하세요.

개요

이 튜토리얼에서는 여러분이 C#과 게임 오브젝트에 대한 기본 지식이 있고 이 교육 과정의 이전 튜토리얼을 완료하여 DOTS와 엔티티의 개념을 이해했다고 가정합니다.

이 튜토리얼을 위한 Unity 프로젝트를 설정하는 방법은 다음과 같습니다. 

새 Unity 프로젝트를 생성합니다

Collections 패키지를 추가하면 종속 관계인 Burst 및 Mathematics 패키지도 자동으로 추가됩니다.

시작하기 전에

탐색기와 타겟의 경우, 방향 벡터를 따라 일정한 속도로 

을 수정하는 MonoBehaviour를 정의해야 합니다. 이를 처리하는 방법은 다음과 같습니다.

 ‘Target.cs’라는 새 스크립트 파일을 생성하고 다음 코드를 추가합니다.

 ‘Seeker.cs’라는 스크립트 파일을 새로 만들고 다음 내용을 추가합니다. 

 단일 루트 게임 오브젝트로 ‘Target’이라는 프리팹을 생성합니다. 이를 빨간색으로 렌더링된 큐브로 만들고 

 단일 루트 게임 오브젝트로 ‘Seeker’라는 프리팹을 생성합니다. 이를 파란색으로 렌더링된 큐브로 만들고 

이제 플레이 모드가 시작할 때 타겟과 탐색기를 생성하는 MonoBehaviour가 필요합니다.

 또 다른 새 스크립트 파일을 생성하고 이름을 ‘Spawner.cs’로 지정한 뒤 다음 코드를 추가합니다.

 컴포넌트의 단일 인스턴스를 게임 오브젝트에 추가하고 해당 프로퍼티를 다음과 같이 설정합니다.

이제 플레이 모드로 들어가면 XZ 평면에서 빨간색과 파란색 큐브가 돌아다니는 것을 볼 수 있습니다. 하지만 각 탐색기(파란색 큐브)와 가장 가까운 타겟(빨간색 큐브)을 연결하는 흰색 디버그 라인은 아직 볼 수 없습니다.

2D 평면을 돌아다니는 탐색기 및 타겟 생성

각 탐색기에 가장 가까운 타겟을 찾고 그 사이에 흰색 디버그 라인을 그리려면 다른 MonoBehaviour가 필요합니다. 이 MonoBehaviour를 추가하는 방법은 다음과 같습니다.

 새 파일을 생성하고 이름을 ‘FindNearest.cs’로 지정한 뒤 다음 코드를 추가합니다. 

 컴포넌트를 새 게임 오브젝트에 추가합니다.

업데이트 중 MonoBehaviour는 모든 탐색기에서 타겟까지의 거리를 확인하고 탐색기와 가장 가까운 타겟 사이에 흰색 디버그 라인을 그립니다.

 플레이 모드에서 흰색 디버그 라인이 그려지는 것을 보려면 

탐색기 1,000개와 타겟 1,000개로 실행되는 일반적인 프레임의 프로파일은 다음과 같습니다.

각 탐색기는 업데이트하는 데 최대 0.33밀리초가 걸리며 프레임의 모든 탐색기를 업데이트하려면 총 340밀리초 이상이 소요됩니다.

매우 훌륭한 결과는 아니지만 이 메서드가 메인 스레드에서만 실행되는 무차별 대입 N^2 솔루션을 사용한다는 점을 고려하면 당연한 결과입니다.

잡 없이 각 탐색기의 가장 가까운 타겟 찾기

복잡한 작업을 잡으로 옮기면 해당 작업을 메인 스레드에서 워커 스레드로 옮길 수 있고 코드를 버스트 컴파일할 수 있습니다. 잡과 버스트 컴파일된 코드는 관리되는 오브젝트(게임 오브젝트와 게임 오브젝트 컴포넌트 포함)에 액세스할 수 없으므로 먼저 잡에서 처리할 모든 데이터를 

 같은 관리되지 않는 컬렉션에 복사해야 합니다.

: 엄밀히 말하면 잡은 관리되는 오브젝트에 

 그러기 위해서는 특별한 주의가 필요하기 때문에 보통 좋은 방법은 아닙니다. 게다가 속도 개선을 위해 이 잡을 버스트 컴파일하면 버스트 컴파일된 코드는 관리되는 오브젝트에 절대로 액세스할 수 없습니다.

를 사용할 수도 있지만 그 대신 

와 Mathematics 패키지의 수학 함수를 사용하겠습니다. 이 패키지에는 버스트를 위한 특수 최적화 훅이 포함되어 있습니다.

작업을 잡으로 옮기는 방법은 다음과 같습니다.

 새 스크립트 파일을 생성하고 이름을 ‘FindNearestJob.cs’로 지정한 뒤 다음 코드를 추가합니다.

 메서드는 이전과 동일한 무차별 대입 N^2 로직을 사용할 예정이지만, 지금은 버스트 컴파일된 잡에서 실행 중이기 때문에 작업에 CPU 시간이 더 적게 소요되고 메인 스레드 대신 워커 스레드에서 작업을 실행할 수 있습니다.

잡을 실행하려면 해당 잡을 인스턴스화하고 예약합니다.

의 내용을 다음 코드로 변경합니다.

이제 플레이 모드로 들어가서 결과를 프로파일링하면 버스트 컴파일하지 않은 탐색기 1,000개와 타겟 1,000개가 있는 일반적인 프레임은 다음 프로파일과 같습니다.

앞서 봤던 최대 340밀리초보다는 최대 30밀리초가 훨씬 낫지만 이번에는 잡 구조체에 [BurstCompile] 속성을 추가하여 버스트 컴파일을 활성화해 보겠습니다. 또한 메인 메뉴(

)에서 버스트 컴파일이 활성화되어 있어야 합니다.

아래 프로파일은 버스트가 활성화된 결과를 보여 줍니다.

최대 1.5밀리초의 결과가 나오고, 60fps의 예산 목표인 16.6밀리초를 넉넉히 달성합니다. 이제 여유 공간이 많기 때문에 탐색기 10,000개와 타겟 10,000개를 시도해 보겠습니다.

탐색기와 타겟이 10배 증가함에 따라 실행 시간이 70배 증가했습니다. 모든 탐색기가 여전히 모든 타겟까지의 거리를 무차별 대입으로 확인하고 있기 때문에 예상했던 결과입니다.

잡은 메인 스레드에서 실행된다는 점을 이 프로파일에서 알 수 있습니다. 잡 대기열에서 아직 제거되지 않은 잡에 

를 호출하면 이런 현상이 발생할 수 있습니다. 해당 잡이 끝나기를 기다리는 동안 대기 상태(idle)였을 메인 스레드가 잡을 자체적으로 실행할 수 있기 때문입니다.

 MonoBehaviour를 업데이트하는 데 걸리는 시간도 상당히 중요합니다. 특히 탐색기와 타겟의 수가 증가할수록 더욱 중요합니다. 이때 수천 개의 MonoBehaviour를 개별적으로 업데이트하는 오버헤드가 주로 발생합니다. 한 번의 업데이트 호출에서 모든 

을 업데이트하면 더 나은 결과를 얻을 수 있습니다. (게임 오브젝트 대신 엔티티를 사용하는 것이 더 좋은 방법이지만, 이 튜토리얼에서 다룰 범위를 벗어나는 내용입니다.)

싱글 스레드 잡으로 각 탐색기의 가장 가까운 타겟 찾기

배열이나 목록을 처리하는 잡은 인덱스를 하위 범위로 분할하여 작업을 병렬화하는 것이 가능한 경우가 많습니다. 예를 들어 배열의 절반은 한 스레드에서 처리되고 동시에 나머지 절반은 다른 스레드에서 처리될 수 있습니다.

를 사용하여 이러한 방식으로 작업을 분할하는 잡을 편리하게 생성할 수 있으며 

 메서드는 다음 2개의 Int 인수를 사용합니다.

인덱스 수: 처리 중인 배열이나 목록의 크기입니다.

배치 크기: 하위 범위(배치)의 크기입니다.

예를 들어 잡의 인덱스 수가 100이고 배치 크기가 40이면 잡은 3개의 배치로 나뉩니다. 첫 번째 배치는 인덱스 0부터 39까지 처리하고, 두 번째 배치는 인덱스 40부터 79까지 처리하고, 세 번째 배치는 인덱스 80부터 99까지 처리합니다.

워커 스레드는 이러한 배치를 대기열에서 개별적으로 가져오므로 배치는 서로 다른 스레드에서 동시에 처리될 수 있습니다.

의 내용을 다음 코드로 바꿉니다.

 호출에 파라미터를 추가하여 잡에서 수행할 

 호출 수와 배치 크기(100)를 지정해야 합니다.

아래 이미지는 탐색기가 10,000개고 타겟이 10,000개인 일반적인 프레임에서 병렬 잡 솔루션을 활용한 경우의 프로파일입니다. 

작업이 16개 코어로 분할되면 총 CPU 시간은 최대 260밀리초가 소요되지만 시작부터 끝까지는 17밀리초 미만으로 소요됩니다.

시작부터 끝까지 걸리는 시간을 단축하기 위해 총 CPU 시간을 더 많이 사용하는 것이 더 나은지는 상황에 따라 크게 달라집니다. 동시에 다른 작업을 수행해야 하는 경우 더 적은 수의 코어에서 잡이 실행되도록 제한하는 것이 더 나을 수 있습니다. 이 예제에서는 다른 작업을 수행하지 않으므로 시작부터 종료까지의 시간이 짧을수록 좋습니다.

병렬 잡을 활용하여 각 탐색기의 가장 가까운 타겟 찾기

지금까지는 가공되지 않은 무차별 대입 N^2 알고리즘을 사용했습니다. 대규모로 훨씬 더 나은 성능을 얻으려면 타겟을 쿼드트리 또는 k-d 트리로 정렬하는 등의 방식으로 데이터를 구성해야 합니다. 

단순성을 유지하기 위해 단일 차원을 따라 타겟을 정렬할 수 있습니다. x 좌표 또는 z 좌표로 정렬할지는 임의로 정하면 되지만, 여기서는 x 좌표를 선택해 보겠습니다. 개별 탐색기에 가장 가까운 타겟을 찾는 작업은 다음 3단계로 수행할 수 있습니다.

바이너리 검색을 수행하여 탐색기의 x 좌표에 가장 가까운 x 좌표를 지닌 타겟을 찾습니다.

해당 타겟의 인덱스에서 배열의 위아래로 2차원 거리가 더 짧은 타겟을 검색합니다.

배열을 위아래로 검색할 때 x축 거리가 현재 후보까지의 2차원 거리를 초과하면 루프를 종료합니다.

이 방식의 장점은 현재 후보까지의 2차원 거리보다 x축 거리가 더 큰 타겟을 확인할 필요가 없다는 것입니다. 따라서 검색 시 각 탐색기의 모든 개별 타겟을 고려할 필요가 없습니다.

이렇게 보다 스마트한 알고리즘을 구현하는 방법은 다음과 같습니다.

 잡이 실행되기 전에 탐색기의 

이 x 좌표를 기준으로 정렬되어 있어야 합니다. 정렬을 수행하기 위해 직접 잡을 작성할 수도 있지만 그 대신 

이라는 NativeArray 확장 메서드를 호출해 보겠습니다. 이 메서드는 SortJob 구조체를 반환합니다.

 메서드는 2개의 잡을 예약합니다. 

는 배열의 개별 세그먼트를 병렬로 정렬하고 

는 정렬된 세그먼트를 병합합니다. (병합 알고리즘은 병렬화가 불가능하기 때문에 별도의 싱글 스레드 잡에서 병합을 수행해야 합니다.)

 잡이 실행을 시작해야 하므로 

 잡에 종속됩니다. 일반적으로 워커 스레드는 어떤 잡을 실행하기 전 여기에 종속된 모든 잡이 실행을 완료하기까지 기다립니다. 잡 종속성을 활용해 예약된 잡 중에서 실행 순서를 효과적으로 지정할 수 있습니다.

에서 잡 예약 코드를 다음과 같이 변경합니다.

아래 이미지는 탐색기가 10,000개고 타겟이 10,000개인 일반적인 프레임에서 이 새로운 솔루션을 활용한 경우의 프로파일입니다.

은 총 CPU 시간이 최대 7.5밀리초이며 시작부터 끝까지는 최대 0.5밀리초가 소요됩니다.

프로파일을 확대하면 정렬 잡을 확인할 수 있습니다.

는 시작부터 끝까지 0.1밀리초 미만이 소요되고 싱글 스레드 

는 최대 0.5밀리초가 소요됩니다. 따라서 타겟 위치를 정렬하기 위해 현재 추가 작업을 처리하고 있음에도 불구하고 전체 워크로드가 급격히 감소했습니다.

병렬 잡과 스마트 알고리즘을 활용하여 각 탐색기의 가장 가까운 타겟 찾기

위에서 언급한 것처럼 타겟 및 탐색기 MonoBehaviour의 많은 업데이트가 낳은 비효율성으로 인해 프레임 시간이 많이 소모됩니다. 이 오버헤드를 해결하기 위해 게임 오브젝트를 엔티티로 대체해 볼 수 있습니다.

추가로 시도해 볼 만한 작업

이 교육 과정의 다음 튜토리얼에서는 잡에서 엔티티에 액세스하고 수정해 보겠습니다.

Unity Version 6.0