Эффективно ли внутри параллельных задач создавать параллельные задачи?
Т.е. Есть к примеру 4*n одинаковых по вычислительной емкости задач: 4*n-1 задач описываются одной функцией funct1(int) и можно применить Parallel.For и одна задача другой функцией funct2(int). Процессор 4-х ядерный. Имеет ли смысл делать Parallel.Invoke на две задачи: первая Parallel.For на 4*n-1 задач, вторая на funct2?
Или лучше сделать массив Task на все задачи (будут издержки на создание объектов Task)?
Или внешнего Parallel.Invoke не делать (тогда funct2 будет в синхронном режиме)?
Re: Эффективно ли внутри параллельных задач создавать параллельные задачи.
Здравствуйте, Passerby, Вы писали:
P>Эффективно ли внутри параллельных задач создавать параллельные задачи?
Теоретически — пофиг. Они всё равно исполняются только на доступных ресурсах. А практически, есть смысл посмотреть на трудоёмкость отдельной задачи: если там два умножения, вообще нет смысла городить огород — просто последовательно выполни все вычисления. Если задачи трудоёмкие, есть смысл параллелить всё.
Очень эффективно (цифры насколько именно и когда - внутри)
Здравствуйте, Passerby, Вы писали:
P>Эффективно ли внутри параллельных задач создавать параллельные задачи? P>Т.е. Есть к примеру 4*n одинаковых по вычислительной емкости задач: 4*n-1 задач описываются одной функцией funct1(int) и можно применить Parallel.For и одна задача другой функцией funct2(int). Процессор 4-х ядерный. Имеет ли смысл делать Parallel.Invoke на две задачи: первая Parallel.For на 4*n-1 задач, вторая на funct2? P>Или лучше сделать массив Task на все задачи (будут издержки на создание объектов Task)? P>Или внешнего Parallel.Invoke не делать (тогда funct2 будет в синхронном режиме)?
Очень.
Латенси в .NET Core — примерно 1 микросекунда на распараллеливание сложения двух чисел c дефолтовым TaskScheduler. В облаках где старые ксеоны 5-ти летней давности. Если нужно точно — то это Хасвел 2.3 Ггц.
В старом framework и моно затраты СИЛЬНО больше:
— 6 микросекунд в NET Framework 4.8.
— 22 микросекунды в Mono 6.6
— 32 микросекунды в моно 5.10
Вот сам код чтоб было понятно:
[Benchmark]
public async Task<int> AwaitLatency()
{
var y = await Task.Run(() => 42);
return y;
}
Боятся нужно только того, что твой код вызовут не с дефолтным TaskScheduler-ом и издержки на распараллеливание миллиона тасков будет не одна секунда а скажем 1000 секунд
Здравствуйте, Passerby, Вы писали:
P>Здравствуйте, VladCore, Вы писали: VC>>- 6 микросекунд в NET Framework 4.8.
P>А сами операции над числами, массивами, словарями где быстрее: NET Framework 4.8 или NET Core?
не смейся но зависит от версии .NET Core
Числодробительные задачи быстрее всего в NET Core 3.0/3.1
Потом в топе — Mono и 6й и 5й версии.
Потом Net Core 2.0/2.1/2.2
Хуже всех Net Framework 4.8
Под числодробительными задачами я в бенчмарк "засунул" три очень популярных:
— QuickSort
— SHA256
— и распаковка GZip
Все три на строго Managed C#. Я их сам конечно не писал а взял реализации из открытых источников
Отчеты по всем трем — в том же бенчмарке что и по ссылке выше.
P.S. да, действительно, в 2018 и 2019 году пока в сентябре не вышел .NET Core 3.0 MONO БЫЛ БЫСТРЕЕ CORE в математике, хотя при этом жутко тормозил в асинхронщине.
Здравствуйте, VladCore, Вы писали: VC>не смейся но зависит от версии .NET Core
Так и должно быть. Реализация совершенствуется. Некоторое время назад, выбирая, на чем писать, где-то прочел, что пока NET Core медленнее чем FraimWork. Может, уже изменилось.
