Простой "IJob" монолитный (не разбивается на куски), но способен работать параллельно другим, если нет с ними зависимости. Как собственно и "Entities.ForEach", только он всегда однопоточный ( в главном потоке) .
В идеале мне бы хотя бы для "Manual iteration" https://docs.unity3d.com/Packages/com.u ... ation.html
2) Причина, мне нужно создавать отдельные массивы (буферы) для каждого потока (пакета или как оно там, в общем на каждое отдельный блок обработки Job), что бы туда записывать данные и избегать условий гонки (возможности одновременной попытки записать в одно и то же место). А потом я просто отдельно сложу все результаты.
3) Вижу пару вариантов, но они сомнительны, но всё же.
3.a)Первый и очень не хочу делать, так как всё сделал в "Manual iteration" и там как то всё понятнее ( явно ). Никогда не ладил с тем, что не знаю как устроено под капотом. Но и узнавать как там под капотом плохо умею, мозг слабоват для этого.
В общем планировать "IJob" вручную, распределять буферы и куски массивов вручную.
3.b) Второй. В "Manual iteration" при планировании "IJobParallelFor" в "...Schedule(chunks.Length, bloks, inputDeps);"
int bloks = ( chunks.Length / System.Environment.ProcessorCount ) + 1; //+1, что бы не создавать условия проверки на ноль.
Но на сколько это хорошее решение, потоки же вообще не в прямой зависимости от ядер делаются? Пакетов от Job-са например может быть 16, а ядра всего 4... ( Умножить System.Environment.ProcessorCount на три перед делением? ) И можно ли так гарантированно знать на сколько пакетов распределится работа?
System.Environment.ProcessorCount - https://docs.microsoft.com/en-us/dotnet ... mework-4.8
