Комментарии 7
Самое важное про burst не сказано. При работе с этим компилятором нужно забыть про Vetor2/3/4, Mtrix4x4. И вместо них использовать float2/3/4 float4x4/4x3/etc. А также всю математику из Math, Mathf заменить на math из пакета Mathematics. Все оптимизации burst завязаны именно на этих структурах и пакете математики, без них будет просадка по производительности т.к. большинство simd оптимизаций не сработают.
Прочитал пока только начало, но уже несколько комментариев.
1) Для обработки множества задач на ограниченном количестве потоков в C# придуман async/await. Может, unity.jobs был придуман до этого?
2)
Используя структуры для работы с Unity Job System, мы обходим стороной проблему гонки состояний
Не катит, от слова совсем. Если объектом хоть как-то пользуются несколько потоков и хотя бы один поток его изменяет, то вместо race condition для классов мы имеем N копий объекта для структур, что вообще не имеет смысла - все потоки, кроме изменяющего, вообще никогда не видят никаких изменений объекта. А если им и не надо их видеть, то это значит, что объект используется локально в одном потоке и проблемы многопоточности тут вообще ни при чем. Тогда остаётся единственное преимущество структур - они не требуют работы с кучей (heap).
3)
Для многопоточной среды это неприемлемо, поскольку джобы должны обращаться к памяти по фиксированным адресам.
Ничего джобы не должны и прекрасно могли бы обращаться к managed объектам, которые двигаются в памяти сборщиком мусора. Причина тут какая-то другая. Автор, вы как-то плаваете в базе дот-нета.
4)
При таком подходе метод (Dispose) для высвобождения данных контейнера будет вызван автоматически при выходе из конструкции.
Не в этом дело. Если написать явный вызов Dispose, то он тоже вызовется "автоматически", то есть просто потому, что он там стоит. А дело в том, что тут Dispose вызовется даже если внутри блока код выкинет исключение.
1) Не особо понял вашу мысль, как асинхронность связана с многопоточность? jobs же должен дать параллельное выполнение а async делает прерывание
как асинхронность связана с многопоточность?
Связана так, что чтобы что-то, любой user-level код, выполнить асинхронно, нужен другой поток. Низкоуровневые операции ввода-вывода не считаем, так как это не user-level код.
Но, вполне возможно, что async/await не рассчитаны на задачи (не заточены под), специфические для unity.
Хотелось бы реальный game dev пример, где выгода от job system побеждает накладные расходы. Подозреваю, что в большинстве случае последовательное исполнение работает даже быстрее такого распараллеливания, которое к тому же перегревает процессор, что ещё более ухудшит производительность.
Оптимизируйте свой код с Unity Job System