멀티스레딩 (Multithreading)

Unity는 자체 Native job system을 사용하여 응용 프로그램이 실행되는 기기의 CPU 코어 수에 따라 여러 worker thread에서 Native code를 처리합니다.
Unity uses its own Native job system to process its own native code over multiple worker threads, which are dependent on the number of CPU cores available on the device your application runs on.

일반적으로 Unity는 프로그램 시작 시 기본적으로 실행되는 Main thread에서 코드를 실행합니다.
Usually Unity executes your code on one thread which runs by default at the start of the program, called the main thread

그러나 Job System을 사용하면 Unity는 multithreading, 즉 worker thread를 통해 코드를 실행합니다.
However, when you use the job system, Unity executes your code over the worker threads, which is called multithreading.

Multithreading은 CPU가 여러 코어에서 동시에 많은 스레드를 처리할 수 있는 기능을 활용합니다.
Multithreading takes advantage of a CPU’s capability to process a lot of threads at the same time across multiple cores.

작업이나 명령이 차례로 실행되는 대신 동시에 실행되며, Worker thread는 서로 병렬로 실행되고 완료될 때 결과를 Main thread와 동기화합니다.
The worker threads run in parallel to one another, and synchronize their results with the main thread once completed.

Job System은 CPU 코어의 용량에 맞는 충분한 thread만 확보하여 사용 가능한 CPU 코어 수를 구체적으로 파악하지 않아도 필요한 작업을 유연하게 예약할 수 있습니다.
The job system ensures that there are only enough threads to match the capacity of the CPU cores, which means that you can schedule as many tasks as you need without specifically needing to know how many CPU cores are available.

이것은 다른 잡 시스템이 CPU 코어보다 더 많은 thread를 비효율적으로 생성하는 스레드 풀링과 같은 기술에 의존하는 것과 차별화됩니다.
This differs from other job systems that rely on techniques such as thread pooling, where it’s easier to inefficiently create more threads than CPU cores.

작업 훔치기 (Work stealing)

Job System은 작업 훔치기를 스케줄링 전략의 일환으로 활용하여 worker thread 간에 공유되는 작업 양을 균등하게 조절합니다.
The job system uses work stealing as part of its scheduling strategy to even out the amount of tasks shared across worker threads.

Worker thread 간에는 작업을 빠르게 처리하는 경우가 있기 때문에 하나의 worker thread가 모든 작업을 완료하면
다른 worker thread의 대기열을 확인하고, 그 후 해당 thread에 할당된 작업을 처리합니다.
Worker threads might process tasks faster than others, so once a worker thread has finished processing all of its tasks,
it looks at the other worker threads’ queues and then processes tasks assigned to another worker thread.

안전 시스템 (Safety System)

멀티스레드 코드를 보다 쉽게 작성할 수 있도록, Job System은 모든 잠재적인 경쟁 상태를 감지하고 이로 인한 발생 가능한 버그를 예방합니다.
To make it easier to write multithreaded code, the job system has a safety system that detects all potential race conditions and protects you from the bugs they can cause.

경쟁 상태는 한 작업의 결과가 제어할 수 없는 다른 프로세스의 실행 타이밍에 영향을 받을 때 발생합니다.
A race condition happens when the output of one operation depends on the timing of another process outside of its control.

예를 들어, 잡 시스템이 Main thread의 코드에서 데이터에 대한 레퍼런스를 잡으로 전달하는 경우,
잡이 데이터를 쓰는 동시에 Main thread가 데이터를 읽고 있는지 확인할 수 없습니다.
For example, if the job system sends a reference to data from your code in the main thread to a job,
it can’t verify whether the main thread is reading the data at the same time the job is writing to it. 

이러한 상황은 경쟁 상태를 야기합니다.
This scenario creates a race condition.

이 문제를 해결하기 위해 잡 시스템은 각 잡이 필요로 하는 데이터에 대한 레퍼런스를 Main thread의 데이터 레퍼런스가 아닌 데이터 사본으로 전송합니다.
To solve this problem, the job system sends each job a copy of the data it needs to operate on rather than a reference to the data in the main thread.

이 사본은 데이터를 격리하여 경쟁 상태를 제거합니다.
this copy isolates the data, which eliminates the race condition.

Job System이 데이터를 복사하는 방식에 따라 Job은 blittable 데이터 타입에만 액세스할 수 있습니다.
The way that the job system copies data means that a job can only access blittable data types. (blittable data Type)

이러한 타입은 관리되는 코드와 네이티브 코드 간에 전달할 때 변환이 필요하지 않습니다.
These types don’t need conversion when passed between managed and native code.

Job System은 memcpy를 사용하여 blittable 타입을 복사하고 Unity의 관리되는 부분과 네이티브 부분 간에 데이터를 전송합니다.
The job system uses memcpy to copy blittable types and transfer the data between the managed and native parts of Unity.

잡을 예약할 때 memcpy를 이용하여 데이터를 기본 메모리에 저장하고, 잡을 실행할 때 해당 사본에 대한 관리되는 측의 액세스 권한을 제공합니다.
It uses memcpy to put data into native memory when scheduling jobs and gives the managed side access to that copy when executing jobs.

자세한 내용은 잡 예약을 참조하십시오.

컬렉션 패키지 (Collections package)

컬렉션 패키지는 핵심 Unity 엔진에서 제공하는 job system 외에도 많은 job types과 native containers를 확장합니다.
In addition to the job system provided in the core Unity engine, the Collections package extends many of the job types and native containers.

자세한 내용은 컬렉션 문서를 참조하십시오.
For more information, see the Collections documentation.

잡 타입 (Job types)

• IJob
  작업 스레드에서 단일 작업을 실행합니다.
  Runs a single task on a job thread.
• IJobParallelFor
  작업을 병렬로 실행합니다.
  Runs a task in parallel.
  각각의 병렬로 실행되는 worker thread는 안전하게 worker thread 간에 공유된 데이터에 액세스하기 위한 독점적인 인덱스를 갖습니다.
  Each worker thread that runs in parallel has an exclusive index to access shared data between worker threads safely.
• IJobParallelForTransform
  작업을 병렬로 실행합니다.
  Runs a task in parallel.
  병렬로 실행되는 각각의 worker thread는 독점적인 Transform을 가지고 작업을 수행합니다.
  Each worker thread running in parallel has an exclusive Transform from the transform hierarchy to operate on.
• IJobFor
  IJobParallelFor와 동일하지만, 작업이 병렬로 실행되지 않도록 작업을 예약할 수 있습니다.
  The same as IJobParallelFor, but allows you to schedule the job so that it doesn’t run in parallel.

IJob

interface in Unity.Jobs

https://docs.unity3d.com/kr/2023.2/ScriptReference/Unity.Jobs.IJob.html

설명

IJob을 사용하여 다른 작업 및 기본 스레드와 병렬로 실행되는 단일 작업을 예약합니다.
An interface that allows you to schedule a single job that runs in parallel to other jobs and the main thread.

작업이 예약되면 해당 작업의 실행 메서드가 worker thread에서 호출됩니다.
After a job is scheduled, the job’s Execute method is invoked on a worker thread. 

반환된 JobHandle을 사용하여 작업이 완료되었는지 확인할 수 있습니다.
You can use the returned JobHandle to make sure that the job has completed.

종속성으로 다른 작업에 전달될 수도 있으므로 worker thread에서 작업이 차례로 실행되도록 할 수 있습니다.
You can also pass the JobHandle to other jobs as a dependency, which ensures that jobs are executed one after another on the worker threads.

ApplyVelocitySample.cs

using UnityEngine;
using Unity.Collections;
using Unity.Jobs;

class ApplyVelocitySample : MonoBehaviour
{
    // 작업 구조체 정의
    struct VelocityJob : IJob
    {
        // 작업에서 액세스할 모든 데이터를 선언
        // 읽기 전용으로 선언함으로써 여러 작업이 데이터에 병렬로 액세스할 수 있게 함
        [ReadOnly]
        public NativeArray<Vector3> velocity;

        // 기본적으로 컨테이너는 읽기 및 쓰기로 가정됨
        public NativeArray<Vector3> position;

        // 델타 타임은 일반적으로 작업이 프레임 개념을 가지지 않기 때문에 작업에 복사되어야 함
        // 메인 스레드는 동일한 프레임 또는 다음 프레임에 작업을 기다리지만, 작업은 워커 스레드에서 실행될 때 결정적이고 독립적인 방식으로 작업을 수행해야 함
        public float deltaTime;
         
        // 작업에서 실행되는 코드
        public void Execute()
        {
            // 델타 타임과 속도에 기반하여 위치 이동
            for (var i = 0; i < position.Length; i++)
                position[i] = position[i] + velocity[i] * deltaTime;
        }
    }

    public void Update()
    {
        var position = new NativeArray<Vector3>(500, Allocator.Persistent);

        var velocity = new NativeArray<Vector3>(500, Allocator.Persistent);

        int _l = velocity.Length;
        for (var i = 0; i < _l; i++)
            velocity[i] = new Vector3(0, 10, 0);

        // 작업 데이터 초기화
        var job = new VelocityJob()
        {
            deltaTime = Time.deltaTime,
            position = position,
            velocity = velocity
        };

        // 작업 예약, 나중에 대기할 수 있는 JobHandle 반환
        JobHandle jobHandle = job.Schedule();

        // 작업이 완료될 때까지 대기
        // 작업을 즉시 완료하는 것은 권장되지 않으며,
        // 실제로 병렬성을 제공하지 않음
        // 작업을 프레임 초기에 예약하고 나중에 프레임 중에 대기하는 것이 최적임
        jobHandle.Complete();

        Debug.Log(job.position[0]);

        // Native 배열은 수동으로 Dispose해야 함
        position.Dispose();
        velocity.Dispose();
    }
}

IJobParallelFor

interface in Unity.Jobs

https://docs.unity3d.com/2023.3/Documentation/ScriptReference/Unity.Jobs.IJobParallelFor.html

설명

각 Native Container의 요소 또는 고정된 반복 횟수에 대해 동일한 독립적인 작업을 수행하는 작업을 나타내는 인터페이스입니다.
Interface that represents a job that performs the same independent operation for each element of a native container or for a fixed number of iterations.

IJobParallelFor 작업을 예약하면 해당 작업의 Execute(int index) 메서드가 여러 Worker Thread에서 서로 병렬로 호출됩니다.
When you schedule an IJobParallelFor job, its Execute(int index) method is invoked on multiple worker threads in parallel to each other.

Execute(int index)는 0부 제공된 길이까지 각 인덱스에 대해 한 번 실행됩니다.
Execute(int index) is executed once for each index from 0 to the provided length.

각 반복은 다른 반복과 독립적이어야 하며, 안전 시스템은 이 규칙을 강제합니다.
Each iteration must be independent from other iterations and the safety system enforces this rule for you.

인덱스에는 보장된 순서가 없으며 여러 코어에서 병렬로 실행됩니다.
The indices have no guaranteed order and are executed on multiple cores in parallel.

Unity는 제공된 배치 크기 이상으로 작업을 청크로 자동 분할하고 Worker Thread 수, 배열 길이 및 배치 크기에 따라 적절한 수의 작업을 예약합니다.
Unity automatically splits the work into chunks no less than the provided batchSize, and schedules an appropriate number of jobs based on the number of worker threads, the length of the array, and the batch size.

배치 크기는 작업에서 수행되는 작업 양에 따라 선택해야 합니다.
Choose the batch size depending on the amount of work performed in the job.

예를 들어 Vector3를 더하는 간단한 작업은 배치 크기가 32에서 128이어야 합니다.
A simple job, for example adding a couple of Vector3 to each other should have a batch size of 32 to 128.

그러나 수행되는 작업이 매우 비용이 많이 드는 경우 작은 배치 크기를 사용하는 것이 가장 좋습니다. 예를 들어 배치 크기가 1인 경우입니다.
However if the work performed is very expensive then it’s best practice to use a small batch size, for example a batch size of 1.

IJobParallelFor는 작업 훔치기를 수행하기 위해 극소의 연산을 사용합니다. 배치 크기는 작을 수 있지만 무료는 아닙니다.
IJobParallelFor uses atomic operations to perform work stealing. Batch sizes can be small but they are not for free.

반환된 JobHandle을 사용하여 작업이 완료되었는지 확인하거나 다른 작업에 종속성으로 전달하여 Worker Thread에서 작업이 서로 차례대로 실행되도록 할 수 있습니다.
You can use the returned JobHandle to make sure that the job has completed, or you can pass it to other jobs as a dependency to make sure that the jobs are executed one after another on the worker threads.

ApplyVelocityParallelForSample.cs

using Unity.Collections;
using Unity.Jobs;
using UnityEngine;

class ApplyVelocityParallelForSample : MonoBehaviour
{
    struct VelocityJob : IJobParallelFor
    {
        // 작업에서 액세스될 모든 데이터를 선언합니다.
        // 읽기 전용으로 선언함으로써 여러 작업이 데이터에 병렬로 액세스할 수 있습니다.
        [ReadOnly]
        public NativeArray<Vector3> velocity;

        // 기본적으로 컨테이너는 읽기 및 쓰기로 가정됩니다.
        public NativeArray<Vector3> position;

        // 작업은 일반적으로 프레임의 개념이 없기 때문에 델타 타임은 작업으로 복사되어야 합니다.
        // 주 스레드는 작업이 동일한 프레임이나 다음 프레임에 실행되기를 기다리지만,
        // 작업은 언제 워커 스레드에서 실행될지에 관계없이 결정론적으로 독립적으로 작업해야 합니다.
        public float deltaTime;

        // 실제로 작업에서 실행되는 코드
        public void Execute(int i)
        {
            // 델타 타임과 속도에 기반하여 위치를 이동합니다.
            position[i] = position[i] + velocity[i] * deltaTime;
        }
    }

    public void Update()
    {
        // 위치에 대한 네이티브 배열 초기화
        var position = new NativeArray<Vector3>(500, Allocator.Temp);

        // 속도에 대한 네이티브 배열 초기화
        var velocity = new NativeArray<Vector3>(500, Allocator.Temp);
        for (var i = 0; i < velocity.Length; i++)
            velocity[i] = new Vector3(0, 10, 0);

        // 작업 데이터 초기화
        var job = new VelocityJob()
        {
            deltaTime = Time.deltaTime,
            position = position,
            velocity = velocity
        };

        // 병렬 작업 예약. 첫 번째 매개변수는 각 반복(iteration)을 수행할 횟수이며,
        // 두 번째 매개변수는 배치 크기(batch size)로,
        // 내부 루프에서 Execute(i)를 불러오는 오버헤드가 없는 값입니다.
        // 각 반복에서 수행할 작업이 많은 경우에는 1의 값을 사용할 수 있습니다.
        // 작업이 매우 적은 경우에는 32 또는 64의 값이 적절합니다.
        JobHandle jobHandle = job.Schedule(position.Length, 64);

        // 작업이 완료될 때까지 대기합니다.
        // 작업을 즉시 완료하는 것은 권장되지 않습니다.
        // 왜냐하면 그렇게 되면 다른 작업이 병렬로 실행되는 기회가 줄어들기 때문입니다.
        // 작업을 프레임 초반에 예약하고, 프레임 후반에 완료되길 기다리는 것이 최적입니다.
        jobHandle.Complete();

        Debug.Log(job.position[0]);

        // 네이티브 배열은 수동으로 해제되어야 합니다.
        position.Dispose();
        velocity.Dispose();
    }
}

IJobParallelForTransform

interface in UnityEngine.Jobs

https://docs.unity3d.com/kr/2023.2/ScriptReference/Jobs.IJobParallelForTransform.html

설명
Description

변환을 위한 병렬 작업을 사용하면 작업에 전달된 모든 변환의 각 위치, 회전 및 배율에 대해 동일한 독립적 작업을 수행할 수 있습니다.
An interface that allows you to perform the same independent operation for each position, rotation and scale of all the transforms passed into a job.

ApplyVelocitySample.cs

using UnityEngine;
using Unity.Collections;
using Unity.Jobs;
using UnityEngine.Jobs;

class ApplyVelocitySample : MonoBehaviour
{
    public struct VelocityJob : IJobParallelForTransform
    {
        // Jobs는 작업에서 액세스 될 모든 데이터를 선언합니다.
        // 읽기 전용으로 선언함으로써 여러 작업이 데이터에 병렬로 액세스할 수 있게 합니다.
        [ReadOnly]
        public NativeArray<Vector3> velocity;

        // 작업에서는 일반적으로 프레임의 개념이 없기 때문에 델타 타임은 작업으로 복사되어야 합니다.
        // 메인 스레드는 작업이 동작하는 동안 같은 프레임 또는 다음 프레임에 대기하지만,
        // 작업은 워커 스레드에서 실행될 때에도 작업이 실행되는 시기에 독립적으로 작업을 수행해야 합니다.
        public float deltaTime;

        // 실제로 작업에서 실행되는 코드
        public void Execute(int index, TransformAccess transform)
        {
            // 델타 타임과 속도를 기반으로 변환을 이동합니다.
            var pos = transform.position;
            pos += velocity[index] * deltaTime;
            transform.position = pos;
        }
    }

    // 인스펙터에서 작업할 변환을 할당합니다.
    [SerializeField] public Transform[] m_Transforms;
    TransformAccessArray m_AccessArray;

    void Awake()
    {
        // 변환을 TransformAccessArray 인스턴스에 저장하여
        // 작업에서 액세스할 수 있도록 합니다.
        m_AccessArray = new TransformAccessArray(m_Transforms);
    }

    void OnDestroy()
    {
        // TransformAccessArray는 수동으로 폐기해야 합니다.
        m_AccessArray.Dispose();
    }

    public void Update()
    {
        var velocity = new NativeArray<Vector3>(m_Transforms.Length, Allocator.Persistent);

        for (var i = 0; i < velocity.Length; ++i)
            velocity[i] = new Vector3(0f, 10f, 0f);

        // 작업 데이터를 초기화합니다.
        var job = new VelocityJob()
        {
            deltaTime = Time.deltaTime,
            velocity = velocity
        };

        // 병렬-for-변환 작업을 예약합니다.
        // 메서드는 작업에서 동작될 TransformAccessArray를 취합니다.
        JobHandle jobHandle = job.Schedule(m_AccessArray);

        // 작업이 완료될 때까지 대기합니다.
        // 작업을 즉시 완료하는 것은 권장되지 않습니다.
        // 왜냐하면 이렇게하면이 작업과 병렬로 다른 작업이 실행될 가능성이 줄어듭니다.
        // 최적으로는 프레임 초반에 작업을 예약한 다음 프레임 중후반에 대기해야 합니다.
        jobHandle.Complete();

        Debug.Log(m_Transforms[0].position);

        // Native 배열은 수동으로 폐기해야 합니다.
        velocity.Dispose();
    }
}

IJobFor

interface in Unity.Jobs

https://docs.unity3d.com/ScriptReference/Unity.Jobs.IJobFor.html

설명
Description

Jobs는 Native Container의 각 요소 또는 고정된 반복 횟수에 대해 동일한 독립적인 작업을 수행할 수 있게 해줍니다.
An interface that represents a job that performs the same independent operation for each element of a native container or for a fixed number of iterations.

이 작업은 작업을 어떻게 스케줄하길 원하는지에 대한 여러 옵션을 허용합니다:
This job type has the following options to schedule work:

• IIJobForExtensions.Run
  작업을 주 스레드에서 실행하고 즉시 완료합니다.
  runs the job on the main thread and finishes immediately.
• IJobForExtensions.Schedule
  작업을 Worker Thread(또는 주 스레드)에서 실행하도록 예약하지만 작업이 단일 스레드에서 수행되어야 함을 나타냅니다.
  schedules the job to run on a worker thread or the main thread, but indicates that the work should happen in a single thread.
  이 옵션은 주 스레드 이외에서 작업을 수행할 수 있게 해주지만, 작업이 순차적으로 수행되기 때문에 이해하기 쉽습니다.
• IJobForExtensions.ScheduleParallel
  작업을 병렬로 실행되도록 예약합니다.
  schedules the job to run on multiple worker threads concurrently.
  이 스케줄링 옵션은 최상의 성능을 제공할 수 있지만, 동시에 여러 Worker Thread에서 동일한 데이터에 접근할 때 발생할 수 있는 충돌을 이해해야 합니다.
  This option allows for work to be done off the main thread, but the work is performed sequentially.
• Execute(int index)
  제공된 길이에 대해 0 에서부터 각 인덱스까지 한 번씩 실행됩니다.
  is executed once for each index from 0 to the provided length.

Run and Schedule 은 작업의 Execute(intindex) 메서드가 순차적으로 호출됨을 보장합니다.
Run and Schedule guarantees that the the job’s Execute(int index) method is invoked sequentially.

Schedule Parallel은 작업의 Execute 메서드를 여러 개의 워커 스레드에서 서로 병렬로 호출하므로 순차적으로 호출하지 않습니다.
ScheduleParallel doesn’t invoke the job’s Execute method sequentially because it’s called from multiple worker threads in parallel to each other.

각 반복은 다른 반복과 독립적이어야 하며 안전 시스템이 이 규칙을 강제합니다.
Each iteration must be independent from other iterations and the safety system enforces this rule for you.

인덱스에는 보장된 순서가 없으며 여러 코어에서 병렬로 실행됩니다.
The indices have no guaranteed order and are executed on multiple cores in parallel.

Unity는 작업을 제공된 batchSize 이상의 크기로 자동으로 나누고 워커 스레드 수, 배열의 길이 및 배치 크기에 따라 적절한 수의 작업을 예약합니다.
Unity automatically splits the work into chunks of no less than the provided batchSize,
and schedules an appropriate number of jobs based on the number of worker threads, the length of the array and the batch size.

배치 크기는 일반적으로 작업에서 수행되는 작업 양에 따라 선택되어야 합니다.
You should choose the batch size based on the amount of work performed in the job.

예를 들어 몇 개의 Vector3를 더하는 간단한 작업은 일반적으로 32에서 128의 배치 크기를 가질 수 있습니다.
A simple job, for example adding a couple of Vector3 to each other should have a batch size of 32 to 128.

그러나 수행되는 작업이 매우 비용이 많이 들 경우 작은 배치 크기를 사용하는 것이 좋습니다. 비용이 많이 드는 작업의 경우 배치 크기 1도 충분합니다.
However, if the work performed is very expensive then it’s best practice to use a small batch size, for example, a batch size of 1.

IJobFor는 atomic 연산을 사용하여 작업 스틸링을 수행합니다. 배치 크기는 작지만 무료가 아닙니다.
 IJobFor performs work stealing using atomic operations. Batch sizes can be small but they are not for free.

반환된 JobHandle은 작업이 완료되었는지를 확인하는 데 사용할 수 있습니다.
You can use the returned JobHandle to check that the job has completed, or pass it to other jobs as a dependency.

JobHandle을 종속성으로 전달하면 작업이 워커 스레드에서 하나씩 순차적으로 실행되도록 보장됩니다.
When you pass a JobHandle as a dependency, it ensures that the jobs are executed one after another on the worker threads.

ApplyVelocityParallelForSample.cs

using UnityEngine;
using Unity.Collections;
using Unity.Jobs;

class ApplyVelocityParallelForSample : MonoBehaviour
{
    struct VelocityJob : IJobFor
    {
        // Jobs는 작업에서 액세스할 모든 데이터를 선언합니다.
        // 읽기 전용으로 선언함으로써 여러 작업이 데이터에 병렬로 액세스할 수 있습니다.
        [ReadOnly]
        public NativeArray<Vector3> velocity;

        // 기본적으로 컨테이너는 읽기 및 쓰기로 가정됩니다.
        public NativeArray<Vector3> position;

        // 델타 타임은 일반적으로 프레임의 개념이 없는 작업에서 작업이 수행됩니다.
        // 메인 스레드는 작업이 동일한 프레임 또는 다음 프레임에 실행되기를 기다립니다.
        // 그러나 작업은 워커 스레드에서 실행될 때에 프레임의 개념을 가지지 않아야 합니다.
        public float deltaTime;

        // 작업에서 실행되는 실제 코드
        public void Execute(int i)
        {
            // 델타 타임과 속도를 기반으로 위치를 이동시킵니다.
            position[i] = position[i] + velocity[i] * deltaTime;
        }
    }

    public void Update()
    {
        var position = new NativeArray<Vector3>(500, Allocator.Persistent);

        var velocity = new NativeArray<Vector3>(500, Allocator.Persistent);
        for (var i = 0; i < velocity.Length; i++)
            velocity[i] = new Vector3(0, 10, 0);

        // 작업 데이터 초기화
        var job = new VelocityJob()
        {
            deltaTime = Time.deltaTime,
            position = position,
            velocity = velocity
        };

        // 작업을 즉시 메인 스레드에서 실행하도록 예약합니다. 첫 번째 매개 변수는 각각의 반복 횟수입니다.
        job.Run(position.Length);

        // 나중에 단일 워커 스레드에서 작업을 예약합니다.
        // 첫 번째 매개 변수는 각각의 반복 횟수입니다.
        // 두 번째 매개 변수는 이 작업의 종속성에 사용할 JobHandle입니다.
        // 종속성은 작업이 종속성이 완료된 후에 워커 스레드에서 실행되도록 보장합니다.
        // 이 경우 작업이 어떤 것에도 의존하지 않기 때문에 기본 값을 사용할 수 있습니다.
        JobHandle scheduleJobDependency = new JobHandle();
        JobHandle scheduleJobHandle = job.Schedule(position.Length, scheduleJobDependency);

        // 병렬 워커 스레드에서 작업을 실행하도록 예약합니다.
        // 첫 번째 매개 변수는 각각의 반복 횟수입니다.
        // 두 번째 매개 변수는 배치 크기이며,
        // 본질적으로는 Execute(i)를 루프에서 호출하는 오버헤드가 없는 내부 루프입니다.
        // 각 반복에서 많은 작업이 있는 경우 값이 1이 합리적일 수 있습니다.
        // 매우 적은 작업이 있는 경우 32 또는 64의 값이 합리적일 수 있습니다.
        // 세 번째 매개 변수는 이 작업의 종속성에 사용할 JobHandle입니다.
        // 종속성은 작업이 종속성이 완료된 후에 워커 스레드에서 실행되도록 보장합니다.
        JobHandle scheduleParallelJobHandle = job.ScheduleParallel(position.Length, 64, scheduleJobHandle);

        // 작업이 완료될 때까지 기다립니다.
        // 작업을 즉시 완료하는 것은 권장되지 않습니다.
        // 왜냐하면 이렇게 하면이 작업과 병렬로 다른 작업이 실행되는 기회가 줄어들기 때문입니다.
        // 최적으로는 프레임 초반에 작업을 예약하고 나중에 프레임에서 기다리는 것이 좋습니다.
        scheduleParallelJobHandle.Complete();

        Debug.Log(job.position[0]);

        // Native 배열은 수동으로 해제되어야 합니다.
        position.Dispose();
        velocity.Dispose();
    }
}

요약 (Summary)

1. IJob:
   • 단일 스레드 방식으로 작업을 실행합니다.
   • 병렬화가 필요하지 않은 작업에 적합합니다.
   • IJob 인터페이스를 구현하며 Execute() 메서드를 제공합니다.
2. IJobParallelFor:
   • 일련의 인덱스에 대해 병렬로 작업을 실행합니다.
   • 각 인덱스에 대해 병렬로 호출되는 작업에 유용합니다.
   • IJobParallelFor 인터페이스를 구현하며 Execute(int index) 메서드를 제공합니다.
   • 지정된 범위 내의 각 인덱스에 대해 Execute 메서드가 병렬로 호출됩니다.
3. IJobParallelForTransform:
   • Transform 구성 요소에 대한 병렬화된 작업을 수행하는 특수한 작업입니다.
   • 여러 개체의 변환에 대한 작업을 병렬화하려는 경우에 사용됩니다.
   • IJobParallelForTransform 인터페이스를 구현하며 Execute(int index, TransformAccess transform) 메서드를 제공합니다.
   • Transform 구성 요소를 병렬로 수정할 수 있습니다.
4. IJobFor:
   • 단일 스레드 방식으로 작업을 실행하지만 인덱스의 범위를 반복합니다.
   • 병렬화는 이루어지지 않지만 여러 인덱스에 대해 순차적으로 작업을 수행합니다.
   • IJobFor 인터페이스를 구현하며 Execute(int index) 메서드를 제공합니다.
   • 지정된 범위 내의 각 인덱스에 대해 Execute 메서드가 순차적으로 호출됩니다.

https://docs.unity3d.com/2023.3/Documentation/Manual/job-system-custom-nativecontainer.html

커스텀 네이티브 컨테이너 구현 (Implement a custom native container)

사용자 정의 네이티브 컨테이너를 구현하려면 해당 유형에 NativeContainer 속성을 부여해야 합니다.
To implement a custom native container, you must annotate your type with the the NativeContainer attribute.

또한 네이티브 컨테이너가 안전 시스템과 통합되는 방식을 이해해야 합니다.
You should also understand how native containers are integrated with the safety system.

구현해야 할 두 가지 주요 요소가 있습니다:
There are two major elements to implement:

• 사용 추적(Usage Tracking) :
  • Unity가 NativeContainer 인스턴스를 사용하는 예약된 작업을 추적하도록 허용하여
    두 작업이 동시에 동일한 네이티브 컨테이너에 쓰기를 시도하는 등의 충돌을 감지하고 방지합니다.
    Allows Unity to keep track of scheduled jobs that use a NativeContainer instance,
    so that it can detect and prevent potential conflicts, such as two jobs writing to the same native container at the same time.
• 누수 추적(Leak Tracking) :
  • NativeContainer 가 제대로 Dispose되지 않은 경우를 감지합니다.
    Detects when a NativeContainer isn’t disposed of properly.
    이러한 상황에서는 메모리 누수가 발생하여 NativeContainer 에 할당된 메모리가 프로그램의 나머지 수명 동안 사용할 수 없게 됩니다.
     In this situation, a memory leak happens, where the memory allocated to the NativeContainer becomes unavailable for the entire remaining lifetime of the program.

사용량 추적 구현 (Implement usage tracking)

사용 추적을 구현하려면 코드에서 AtomicSafetyHandle 클래스를 사용합니다.
To access usage tracking in your code, use the AtomicSafetyHandle class.

AtomicSafetyHandle은 주어진 NativeContainer에 대해 안전 시스템이 저장하는 중앙 정보에 대한 참조를 보유하며,
NativeContainer의 메서드가 안전 시스템과 상호 작용하는 주요 방법입니다.
AtomicSafetyHandle holds a reference to the central information that the safety system stores for a given NativeContainer,
and is the main way that the methods of a NativeContainer interact with the safety system.

따라서 모든 NativeContainer 인스턴스는 m_Safety라는 이름의 AtomicSafetyHandle 필드를 포함해야 합니다.
Because of this, every NativeContainer instance must contain an AtomicSafetyHandle field named m_Safety.

각 AtomicSafetyHandle은 현재 컨텍스트에서 NativeContainer에 수행할 수 있는 작업 유형을 나타내는 플래그 집합을 저장합니다.
Each AtomicSafetyHandle stores a set of flags that indicate what types of operation can be performed on the native container in the current context.

작업이 NativeContainer 인스턴스를 포함하는 경우 작업 시스템은 자동으로 AtomicSafetyHandle의 플래그를 구성하여
해당 작업에서 NativeContainer를 사용할 수 있는 방식을 반영합니다.
When a job contains a NativeContainer instance, the job system automatically configures
the flags in the AtomicSafetyHandle to reflect the way that the native container can be used in that job.

작업이 NativeContainer 인스턴스에서 읽기를 시도할 때 작업 시스템은 읽기 전에 CheckReadAndThrow 메서드를 호출하여
작업이 NativeContainer에 대한 읽기 액세스 권한이 있는지 확인합니다.
When a job tries to read from a NativeContainer instance, the job system calls the CheckReadAndThrow method before reading,
to confirm that the job has read access to the native container.

마찬가지로 작업이 NativeContainer에 쓰기를 시도할 때 작업 시스템은 쓰기 전에 CheckWriteAndThrow를 호출하여
작업이 NativeContainer에 대한 쓰기 액세스 권한이 있는지 확인합니다.
Similarly, when a job tries to write to a native container, the job system calls CheckWriteAndThrow before writing, to check that the job has write access to the native container. 

두 작업이 동일한 NativeContainer 인스턴스를 할당 받은 경우에도, 해당 네이티브 컨테이너에 대해 별도의 AtomicSafetyHandle 객체를 갖습니다.
Two jobs that have been assigned the same NativeContainer instance have separate AtomicSafetyHandle objects for that native container,

따라서 두 작업은 동일한 중앙 정보를 참조하더라도,
각각이 네이티브 컨테이너에 대한 읽기 및 쓰기 액세스를 나타내는 별도의 플래그를 유지할 수 있습니다.
so although they both reference the same set of central information,
they can each hold separate flags that indicate what read and write access each job has to the native container.

누출 추적 구현 (Implement leak tracking)

Unity’s native code는 주로 누수 추적을 구현합니다.
Unity’s native code primarily implements leak tracking.

UnsafeUtility.MallocTracked 메서드를 사용하여 NativeContainer 데이터를 저장하는 데 필요한 메모리를 할당하고,
이를 해제하기 위해 UnsafeUtility.FreeTracked를 사용합니다.
It uses the UnsafeUtility.MallocTracked method to allocate the memory needed to store NativeContainer data,
and then uses UnsafeUtility.FreeTracked to dispose of it.

이전 유니티 버전에서는 DisposeSentinel 클래스가 누수 추적을 제공했습니다.
In earlier versions of Unity the DisposeSentinel class provides leak tracking.

가비지 컬렉터가 DisposeSentinel 객체를 수집할 때 유니티는 메모리 누수를 보고합니다.
Unity reports a memory leak when the garbage collector collects the DisposeSentinel object.

DisposeSentinel을 만들려면 Create 메서드를 사용하며, 이 메서드를 사용하면 AtomicSafetyHandle을 동시에 초기화할 필요가 없습니다.
To create a DisposeSentinel, use the Create method, which also initializes the AtomicSafetyHandle at the same time.

ativeContainer가 Dispose될 때 Dispose 메서드는 DisposeSentinel과 AtomicSafetyHandle을 한 번에 처리합니다.
When the NativeContainer is disposed of, the Dispose method disposes of both the DisposeSentinel and the AtomicSafetyHandle in a single call.

누수가 발생한 NativeContainer가 생성된 위치를 식별하려면 메모리가 원래 할당된 위치의 스택 트레이스를 캡처할 수 있습니다.
To identify where the leaked NativeContainer was created, you can capture the stack trace of where the memory was originally allocated.

이를 위해 NativeLeakDetection.Mode 속성을 사용하고 에디터에서는
Preferences > Jobs > Leak Detection Level로 이동하여 필요한 누수 검출 수준을 선택할 수 있습니다.
To do this, use the NativeLeakDetection.Mode property. You can also access this property in the Editor.
To do this, go to Preferences > Jobs > Leak Detection Level and choose the leak detection level you need.

중첩된 네이티브 컨테이너 (Nested native containers)

안전 시스템은 작업에서 중첩된 NativeContainer를 지원하지 않습니다.
The safety system doesn’t support nested native containers in jobs,

To prevent scheduling jobs that use nested native containers, use SetNestedContainer, which flags a NativeContainer as nested when they contain other NativeContainer instances.

이는 작업 시스템이 큰 NativeContainer 인스턴스 내의 각 개별 NativeContainer에 대한 AtomicSafetyHandle을 올바르게 구성할 수 없기 때문입니다.
because the job system can’t correctly configure the AtomicSafetyHandle for each individual NativeContainer inside the larger NativeContainer instance.

중첩된 NativeContainer를 사용하는 작업을 예약하지 않도록 방지하려면 SetNestedContainer 플래그를 사용하십시오.
To prevent scheduling jobs that use nested native containers, use SetNestedContainer,

이 메서드는 다른 NativeContainer 인스턴스를 포함할 때 해당 NativeContainer를 중첩된 것으로 플래그 지정합니다.
which flags a NativeContainer as nested when they contain other NativeContainer instances.

안전 ID 및 오류 메시지 (Safety IDs and error messages)

Safety system은 코드가 안전성 제약을 준수하지 않을 때 발생하는 오류 메시지를 제공합니다.
The safety system provides error messages that indicate when your code doesn’t adhere to safety constraints.

오류 메시지를 더 명확하게 만들기 위해 NativeContainer 객체의 이름을 safety system에 등록할 수 있습니다.
To help make the error messages clearer, you can register a NativeContainer object’s name with the safety system.

이름을 등록하려면 NewStaticSafetyId를 사용하고, 이는 SetStaticSafetyId에 전달할 safety ID를 반환합니다.
To register a name, use NewStaticSafetyId, which returns a safety ID that you can pass to SetStaticSafetyId.

한 번 safety ID를 생성하면 NativeContainer의 모든 인스턴스에서 재사용할 수 있으므로
주로 컨테이너 클래스의 정적 멤버에 저장하는 것이 일반적인 패턴입니다.
Once you create a safety ID, you can reuse it for all instances of the NativeContainer,
so a common pattern is to store it in a static member of the container class.

또한 SetCustomErrorMessage를 사용하여 특정 안전성 제약 위반에 대한 사용자 지정 오류 메시지를 재정의할 수도 있습니다.
You can also override the error messages for specific safety constraint violations with SetCustomErrorMessage.

추가 리소스 (Additional resources)

• NativeContainer 구조 복사
  Copying NativeContainer structures
• 사용자 정의 NativeContainer 예
  Custom NativeContainer example

https://docs.unity3d.com/2023.3/Documentation/Manual/job-system-custom-nativecontainer-example.html

사용자 정의 NativeContainer 예제 (Custom NativeContainer example)

NativeContainer다음은 추가 전용 목록인 사용자 정의의 전체 예입니다 .
The following is a complete example of a custom NativeContainer as an append-only list.

읽기 및 쓰기 작업의 기본 보호는 물론 앨리어싱 뷰 생성 및 무효화를 보여줍니다.
It demonstrates basic protection of read and write operations, as well as creating and invalidating aliasing views.

다른 예는 NativeContainerAttribute API 설명서를 참조하세요.
For another example, see the NativeContainerAttribute API documentation.

using System;
using System.Runtime.InteropServices;
using Unity.Collections.LowLevel.Unsafe;
using Unity.Collections;

// NativeContainer로 구조체를 표시합니다. 이는 job 시스템에 AtomicSafetyHandle이 포함되어 있음을 나타냅니다.
[NativeContainer]
public unsafe struct NativeAppendOnlyList<T> : IDisposable where T : unmanaged
{
    // 원시 포인터는 일반적으로 job에 전달되는 구조체 내에서 허용되지 않지만, 안전 시스템으로 보호되므로 이 제한을 해제할 수 있습니다.
    [NativeDisableUnsafePtrRestriction]
    internal void* m_Buffer;
    internal int m_Length;
    internal Allocator m_AllocatorLabel;

    // ENABLE_UNITY_COLLECTIONS_CHECKS 정의로만 안전 시스템 멤버를 선언하고 사용해야 합니다.
    // 프로젝트의 최종 빌드에서는 성능상의 이유로 안전 시스템이 비활성화되므로 이러한 API는 해당 빌드에서 사용할 수 없습니다.
#if ENABLE_UNITY_COLLECTIONS_CHECKS

    // AtomicSafetyHandle 필드는 'm_Safety'로 정확히 명명되어야 합니다.
    internal AtomicSafetyHandle m_Safety;

    // 이 유형을 해당 유형에서 파생된 이름을 사용하여 정적으로 안전 시스템에 등록합니다.
    internal static readonly int s_staticSafetyId = AtomicSafetyHandle.NewStaticSafetyId<NativeAppendOnlyList<T>>();
#endif

    public NativeAppendOnlyList(Allocator allocator, params T[] initialItems)
    {
        m_Length = initialItems.Length;
        m_AllocatorLabel = allocator;

        // 초기 버퍼의 크기(바이트)를 계산하고 할당합니다.
        int totalSize = UnsafeUtility.SizeOf<T>() * m_Length;
        m_Buffer = UnsafeUtility.MallocTracked(totalSize, UnsafeUtility.AlignOf<T>(), m_AllocatorLabel, 1);

        // 배열에서 데이터를 버퍼로 복사합니다.
        var handle = GCHandle.Alloc(initialItems, GCHandleType.Pinned);
        try
        {
            UnsafeUtility.MemCpy(m_Buffer, handle.AddrOfPinnedObject().ToPointer(), totalSize);
        }
        finally
        {
            handle.Free();
        }

#if ENABLE_UNITY_COLLECTIONS_CHECKS
        // AtomicSafetyHandle 및 DisposeSentinel 생성
        m_Safety = AtomicSafetyHandle.Create();

        // AtomicSafetyHandle에 안전 ID 설정하여 오류 메시지가 이 컨테이너 유형을 올바르게 설명하도록 함
        AtomicSafetyHandle.SetStaticSafetyId(ref m_Safety, s_staticSafetyId);

        // 이 컨테이너가 중첩 컨테이너인지 확인하고 중첩 컨테이너 플래그 설정
        if (UnsafeUtility.IsNativeContainerType<T>())
            AtomicSafetyHandle.SetNestedContainer(m_Safety, true);
#endif
    }

    public int Length
    {
        get
        {
#if ENABLE_UNITY_COLLECTIONS_CHECKS
            // 컨테이너에 대한 정보를 읽을 수 있는지 확인합니다.
            // 이는 원시 컨테이너에서 읽을 수 없거나 네이티브 컨테이너가 해제된 경우 InvalidOperationException을 throw합니다.
            AtomicSafetyHandle.CheckReadAndThrow(m_Safety);
#endif
            return m_Length;
        }
    }

    public T this[int index]
    {
        get
        {
#if ENABLE_UNITY_COLLECTIONS_CHECKS
            // 현재 네이티브 컨테이너에서 읽을 수 있는지 확인합니다.
            AtomicSafetyHandle.CheckReadAndThrow(m_Safety);
#endif

            // 버퍼에서 값을 읽어 반환합니다.
            return UnsafeUtility.ReadArrayElement<T>(m_Buffer, index);
        }

        set
        {
#if ENABLE_UNITY_COLLECTIONS_CHECKS
            // 현재 네이티브 컨테이너에 쓸 수 있는지 확인합니다.
            AtomicSafetyHandle.CheckWriteAndThrow(m_Safety);
#endif
            // 값을 버퍼에 씁니다.
            UnsafeUtility.WriteArrayElement(m_Buffer, index, value);
        }
    }

    public void Add(T value)
    {
#if ENABLE_UNITY_COLLECTIONS_CHECKS
        // 현재 네이티브 컨테이너를 수정(쓰기)할 수 있는지 확인하고 그렇다면 보조 버전을 증가시켜서
        // 뷰가 무효화되도록 합니다. 왜냐하면 크기와 버퍼에 대한 포인터를 변경할 것이기 때문입니다.
        AtomicSafetyHandle.CheckWriteAndBumpSecondaryVersion(m_Safety);
#endif

        // 현재 버퍼를 원소 하나를 추가할 공간이 있는 새로운 버퍼로 교체합니다.
        int newTotalSize = (m_Length + 1) * UnsafeUtility.SizeOf<T>();
        void* newBuffer = UnsafeUtility.MallocTracked(newTotalSize, UnsafeUtility.AlignOf<T>(), m_AllocatorLabel, 1);
        UnsafeUtility.MemCpy(newBuffer, m_Buffer, m_Length * UnsafeUtility.SizeOf<T>());
        UnsafeUtility.FreeTracked(m_Buffer, m_AllocatorLabel);
        m_Buffer = newBuffer;

        // 새 원소를 버퍼 끝에 넣고 길이를 증가시킵니다.
        UnsafeUtility.WriteArrayElement(m_Buffer, m_Length++, value);
    }

    public NativeArray<T> AsArray()
    {
#if ENABLE_UNITY_COLLECTIONS_CHECKS
        // 현재 버퍼 포인터를 사용하여 뷰를 만들 수 있는지 안전하게 확인합니다.
        AtomicSafetyHandle.CheckGetSecondaryDataPointerAndThrow(m_Safety);

        // AtomicSafetyHandle의 복사본을 만들고 해당 복사본을 기본 대신 보조 버전을 사용하도록 표시합니다.
        AtomicSafetyHandle handleForArray = m_Safety;
        AtomicSafetyHandle.UseSecondaryVersion(ref handleForArray);
#endif

        // 현재 크기를 사용하여 버퍼에 별칭을 설정하는 새 NativeArray를 만듭니다.
        // 이 작업은 데이터를 할당하거나 복사하지 않고 현재 버퍼를 가리키는 NativeArray<T>를 설정합니다.
        var array = NativeArrayUnsafeUtility.ConvertExistingDataToNativeArray<T>(m_Buffer, m_Length, Allocator.None);

#if ENABLE_UNITY_COLLECTIONS_CHECKS
        // 새로 만든 NativeArray에 AtomicSafetyHandle을 설정합니다. 설정한 핸들은 앞서 복사한 핸들을 사용합니다.
        NativeArrayUnsafeUtility.SetAtomicSafetyHandle(ref array, handleForArray);
#endif

        return array;
    }

    public void Dispose()
    {
#if ENABLE_UNITY_COLLECTIONS_CHECKS
        AtomicSafetyHandle.CheckDeallocateAndThrow(m_Safety);
        AtomicSafetyHandle.Release(m_Safety);
#endif

        // 버퍼를 해제합니다.
        UnsafeUtility.FreeTracked(m_Buffer, m_AllocatorLabel);
        m_Buffer = null;
        m_Length = 0;
    }
}

종속성 결합 (Combining dependencies)

작업이 많은 종속성을 가지고 있다면 JobHandle.CombineDependencies  메서드를 사용하여 이를 병합할 수 있습니다.
If a job has a lot of dependencies, you can use the method JobHandle.CombineDependencies to merge them.

CombineDependencies 를 사용하면 종속성을 Schedule 메서드로 전달할 수 있습니다.
CombineDependencies allows you to pass dependencies onto the Schedule method.

NativeArray<JobHandle> handles = new NativeArray<JobHandle>(numJobs, Allocator.TempJob);

// Populate `handles` with `JobHandles` from multiple scheduled jobs...

JobHandle jh = JobHandle.CombineDependencies(handles);

다중 작업 및 종속성 예제 (An example of multiple jobs and dependencies)

다음은 여러 작업이 여러 종속성을 가진 예제입니다.
The following is an example of multiple jobs that have multiple dependencies.

작업 코드(MyJob 및 AddOneJob)를 Update 및 LateUpdate 코드와 별도의 파일에 두는 것이 좋지만 명확성을 위해 이 예제는 하나의 파일에 포함되어 있습니다.
It’s best practice to put the job code (MyJob and AddOneJob) in a separate file to the Update and LateUpdate code, but for the purposes of clarity, this example is one file:

using UnityEngine;
using Unity.Collections;
using Unity.Jobs;

public class MyDependentJob : MonoBehaviour
{
    // 결과를 저장할 하나의 float를 담는 NativeArray 생성. 이 예제는 작업이 완료될 때까지 기다립니다.
    NativeArray<float> result;
    // 결과에 액세스하기 위한 JobHandle 생성
    JobHandle secondHandle;

    // 첫 번째 작업 설정
    public struct MyJob : IJob
    {
        public float a;
        public float b;
        public NativeArray<float> result;

        public void Execute()
        {
            result[0] = a + b;
        }
    }

    // 값에 1을 더하는 두 번째 작업 설정
    public struct AddOneJob : IJob
    {
        public NativeArray<float> result;

        public void Execute()
        {
            result[0] = result[0] + 1;
        }
    }

    // 매 프레임마다 호출되는 업데이트 메서드
    void Update()
    {
        // 첫 번째 작업에 대한 작업 데이터 설정
        result = new NativeArray<float>(1, Allocator.TempJob);

        MyJob jobData = new MyJob
        {
            a = 10,
            b = 10,
            result = result
        };

        // 첫 번째 작업 예약
        JobHandle firstHandle = jobData.Schedule();

        // 두 번째 작업에 대한 데이터 설정
        AddOneJob incJobData = new AddOneJob
        {
            result = result
        };

        // 두 번째 작업 예약
        secondHandle = incJobData.Schedule(firstHandle);
    }

    private void LateUpdate()
    {
        // 프레임 내 나중에 작업이 완료될 때까지 대기
        secondHandle.Complete();

        // NativeArray의 모든 복사본이 동일한 메모리를 가리키므로 "당신의" NativeArray 복사본에서 결과에 액세스할 수 있습니다.
        // float aPlusBPlusOne = result[0];

        // 결과 배열이 할당한 메모리 해제
        result.Dispose();
    }
}

ParallelFor 작업 예약 (Schedule a ParallelFor job)

ParallelFor 작업을 예약하려면 사용할 NativeArray 데이터 소스의 길이를 지정해야 합니다.
To schedule a ParallelFor job, you must specify the length of the NativeArray data source that you want to split.

구조체에 여러 개가 있을 경우 데이터 소스로 사용할 NativeArray를 작업 시스템이 알 수 없습니다..
The job system doesn’t know which NativeArray you want to use as the data source if there are several in the struct.

길이는 또한 작업 시스템에게 기대할 Execute 메서드의 수를 알려줍니다.
The length also tells the job system how many Execute methods to expect.

In Unity’s native code, the scheduling of ParallelFor jobs is more complicated.
유니티의 네이티브 코드에서 ParallelFor 작업을 예약하는 것은 더 복잡합니다.

유니티가 ParallelFor 작업을 예약하면 작업 시스템은 작업을 코어 간에 분배하기 위해 작업을 일련의 배치로 나눕니다.
When Unity schedules a ParallelFor job, the job system divides the work into batches to distribute between cores.

각 배치에는 Execute 메서드의 하위 집합이 포함되어 있습니다.
Each batch contains a subset of Execute methods.

그런 다음 job system은 유니티의 네이티브 작업 시스템에서 CPU 코어 당 하나의 작업을 예약하고 해당 네이티브 작업을 배치에 전달하여 완료합니다.
The job system then schedules one job in Unity’s native job system per CPU core and passes that native job to the batches to complete.

다른 Native 작업보다 네이티브 작업이 일부 배치를 먼저 완료하면 남은 배치를 다른 네이티브 작업에서 빼앗아 갑니다.
When a native job completes its batches before others, it steals remaining batches from the other native jobs.

이 때 캐시 지역성을 보장하기 위해 네이티브 작업의 남은 배치의 절반만을 한 번에 빼앗습니다.
It only steals half of a native job’s remaining batches at a time, to ensure cache locality.

이 프로세스를 최적화하려면 배치 카운트를 지정해야 합니다.
To optimize the process, you need to specify a batch count.

배치 카운트는 얼마나 많은 작업을 얻을지 및 스레드 간 작업 재분배가 얼마나 미세한지를 제어합니다.
The batch count controls how many jobs you get, and how fine-grained the redistribution of work between threads is.

낮은 배치 카운트(예: 1)는 스레드 간 작업을 균등하게 분배합니다.
Having a low batch count, such as 1, gives you an even distribution of work between threads.

그러나 이에는 어느 정도의 오버헤드가 따르므로 때로는 배치 수를 늘리는 것이 더 나을 수 있습니다.
However, it comes with some overhead, so sometimes it’s better to increase the batch count.

1에서 시작하여 성능 향상이 미미할 때까지 배치 수를 늘리는 것이 좋은 전략입니다.
Starting at 1 and increasing the batch count until there are negligible performance gains is a good strategy.

다음은 ParallelFor 작업을 예약하는 예시입니다.
The following is an example of scheduling a ParallelFor job

Job code:

// Job adding two floating point values together
public struct MyParallelJob : IJobParallelFor
{
    [ReadOnly]
    public NativeArray<float> a;
    [ReadOnly]
    public NativeArray<float> b;
    public NativeArray<float> result;

    public void Execute(int i)
    {
        result[i] = a[i] + b[i];
    }
}

Main thread code:

NativeArray<float> a = new NativeArray<float>(2, Allocator.TempJob);

NativeArray<float> b = new NativeArray<float>(2, Allocator.TempJob);

NativeArray<float> result = new NativeArray<float>(2, Allocator.TempJob);

a[0] = 1.1;
b[0] = 2.2;
a[1] = 3.3;
b[1] = 4.4;

MyParallelJob jobData = new MyParallelJob();
jobData.a = a;
jobData.b = b;
jobData.result = result;

// 결과 배열의 각 인덱스에 대해 하나의 Execute로 작업을 예약하고 각 처리 배치당 항목은 1개
JobHandle handle = jobData.Schedule(result.Length, 1);

// 작업이 완료될 때까지 기다립니다.
handle.Complete();

// 배열에 할당된 메모리를 해제합니다.
a.Dispose();
b.Dispose();
result.Dispose();

ParallelForTransform jobs

ParallelForTransform 작업은 Transforms에 특화된 또 다른 ParallelFor 작업 유형입니다.
A ParallelForTransform job is another type of ParallelFor job designed specifically for operating on Transforms.

이는 작업에서 Transform 작업을 효율적으로 수행하는 데 유용합니다.
It’s useful for working on Transform operations from jobs efficiently.

더 많은 정보는 ParallelForTransform API 문서를 참조하세요.
For more information, see the ParallelForTransform API documentation.

https://docs.unity3d.com/2023.3/Documentation/ScriptReference/Jobs.IJobParallelForTransform.html

IJobParallelForTransform

interface in UnityEngine.Jobs

Job에 전달된 모든 변환의 위치, 회전 및 크기에 대해 동일한 독립적인 작업을 수행할 수 있도록 하는 인터페이스입니다.
An interface that allows you to perform the same independent operation for each position, rotation and scale of all the transforms passed into a job.

using UnityEngine;
using Unity.Collections;
using Unity.Jobs;
using UnityEngine.Jobs;

class ApplyVelocitySample : MonoBehaviour
{
    public struct VelocityJob : IJobParallelForTransform
    {
        // 작업에서 액세스될 모든 데이터를 선언합니다.
        // 읽기 전용으로 선언함으로써 여러 작업에서 데이터에 병렬로 액세스할 수 있습니다.
        [ReadOnly]
        public NativeArray<Vector3> velocity;

        // 작업에서 프레임 개념이 일반적으로 없기 때문에 델타 타임을 작업으로 복사해야 합니다.
        // 메인 스레드는 동일한 프레임이나 다음 프레임에 작업을 기다리지만,
        // 작업은 작업자 스레드에서 실행되는 시점에 상관없이 작업을 결정적으로 수행해야 합니다.
        public float deltaTime;

        // 작업에서 실제로 실행되는 코드
        public void Execute(int index, TransformAccess transform)
        {
            // 델타 타임과 속도를 기반으로 변환을 이동시킵니다.
            var pos = transform.position;
            pos += velocity[index] * deltaTime;
            transform.position = pos;
        }
    }

    // 작업에서 조작할 변환을 인스펙터에서 할당합니다.
    [SerializeField] public Transform[] m_Transforms;
    TransformAccessArray m_AccessArray;

    void Awake()
    {
        // 변환을 TransformAccessArray 인스턴스에 저장하여 작업에서 액세스할 수 있도록 합니다.
        m_AccessArray = new TransformAccessArray(m_Transforms);
    }

    void OnDestroy()
    {
        // TransformAccessArrays는 수동으로 Dispose해야 합니다.
        m_AccessArray.Dispose();
    }

    public void Update()
    {
        var velocity = new NativeArray<Vector3>(m_Transforms.Length, Allocator.Persistent);

        for (var i = 0; i < velocity.Length; ++i)
            velocity[i] = new Vector3(0f, 10f, 0f);

        // 작업 데이터 초기화
        var job = new VelocityJob()
        {
            deltaTime = Time.deltaTime,
            velocity = velocity
        };

        // 병렬로 변환 작업을 예약합니다.
        // 이 메서드는 작업에서 조작할 변환을 포함하는 TransformAccessArray를 취합니다.
        JobHandle jobHandle = job.Schedule(m_AccessArray);

        // 작업이 완료되었는지 확인합니다.
        // 작업을 즉시 완료하면 이와 병렬로 다른 작업이 실행될 가능성이 감소합니다.
        // 작업을 프레임 초반에 예약하고 나중에 프레임에서 기다리는 것이 좋습니다.
        jobHandle.Complete();

        Debug.Log(m_Transforms[0].position);

        // Native 배열은 수동으로 Dispose해야 합니다.
        velocity.Dispose();
    }
}