Разобраться раз и навсегда: Task.WhenAll или Parallel.ForEachAsync в C#

Все хотят писать код, который работает быстро. Часто мы сидим, просматривая написанные алгоритмы и пытаясь понять, что можно сделать, чтобы настроить их производительность. В таком случае часто прибегают к параллельному выполнению задач. Конечно, если можно выполнять задачи параллельно и делать эту работу одновременно, то ожидаемо общее количество времени на обработку сократиться.

Если быстро посмотреть на результаты, которые появляются в интернете при поиске советов по реализации подобных вещей, то можно увидеть, что есть как много похожих, так и различных предложений от различных программистов. В какой-то момент поиска вы, вероятно, столкнётесь с поиском идеей использования Task.WhenAll или Parallel.ForEachAsync.

При чтении некоторых из этих материалов будет видно много различных противоречивых ответов как на StackOverflow, так и по всему интернету. Сегодня я собираюсь сравнить эти два метода с помощью определённых бенчмарков, которые стравят их друг против друга, чтобы, наконец, выяснить применимость каждого из двух методов.

▍ Методика сравнения

Прежде чем, мы перейдём к обзору кода бенчмарков, написанных с помощью популярного NuGet пакета BenchmarkDotNet, стоит отметить, что сравнивая Task.WhenAll и Parallel.ForEachAsync, на самом деле мы будем симулировать два разных типа задач для системы.

Читая многие обсуждения этих двух методов в интернете, можно натолкнуться на предложение испытать методы в рамках парадигмы IO bound vs CPU bound.

Что это вообще означает?

IO bound означает, что написанные вами задачи ожидают завершения выполнения каких-то других вещей, которые не являются частью вашего процесса или вовсе не выполняются на вашем компьютере.

CPU bound в свою очередь, показывает другую ситуацию, когда выполняемая задача загружена выполнением некоторых вычислений.

Поэтому в рамках двух следующих бенчмарков, которые будут рассмотрены, произойдёт попытка смоделировать IO bound работу и CPU bound работу для сравнения методов Task.WhenAll и Parallel.ForEachAsync.

▍ Код бенчмарков

Начнём с примера симуляции IO bound работы. В коде ниже стоит отметить несколько моментов.

Во-первых, бенчмарк сконфигурирован двумя различными параметрами, чтобы в динамике исследовать то, что будет испытывать программа.

Во-вторых, «настоящей» IO bound работы, вроде обращения к стороннему ресурсу, происходить не будет в целях безопасности. В действительности она моделируется через вызов await Task.Delay и управляемо настроенную величину задержки ожидания.

[ShortRunJob]
public class BenchmarkSimulatedIo
{
    [Params(1, 10, 100)]
    public int CollectionCount;
 
    [Params(1, 10, 100, 1000)]
    public int SimulatedIoDelays;
 
    [Benchmark]
    public async Task TaskWhenAll()
    {
        var tasks = Enumerable
            .Range(0, CollectionCount)
            .Select(async _ => await Task.Delay(SimulatedIoDelays))
            .ToArray();
 
        await Task.WhenAll(tasks);
    }
 
    [Benchmark]
    public async Task ParallelForEach() =>
        await Parallel.ForEachAsync(
            Enumerable.Range(0, CollectionCount),
            cancellationToken: default,
            async (i, ct) => await Task.Delay(SimulatedIoDelays, ct));
}

Теперь давайте перейдём к другому классу с бенчмарками, где будет имитироваться работа, нагружающая процессор или CPU bound work.

Как можно заметить, код очень похож на тот, что вы увидели только что выше.

Конечно, параметр задержки поменялся на другой параметр, который будет постепенно увеличивать объём работы, повышая нагрузку на процессор.

Соответственно, моделирование CPU bound работы будет заключаться в вычислении случайных чисел заданное количество раз, что будет держать поток в занятости.

[ShortRunJob]
public class BenchmarkSimulatedCpu
{
    private int[]? _dataSet;
    
    [Params(1, 10, 100)]
    public int CollectionCount;
 
    [Params(1000, 10_000, 100_000, 1_000_000)]
    public int CpuWorkIterations;
 
    [GlobalSetup]
    public void GlobalSetup() =>
        _dataSet = Enumerable.Range(0, CollectionCount).ToArray();
 
    [Benchmark]
    public async Task TaskWhenAll()
    {
        var tasks = _dataSet!.Select(_ =>
        {
            for (var i = 0; i < CpuWorkIterations; i++)
            {
                Random.Shared.Next();
            }
 
            return Task.CompletedTask;
        }).ToArray();
 
        await Task.WhenAll(tasks);
    }
 
    [Benchmark]
    public async Task ParallelForEach() =>
        await Parallel.ForEachAsync(
            _dataSet!,
            cancellationToken: default,
            (_, ct) =>
            {
                for (var i = 0; i < CpuWorkIterations; i++)
                {
                    Random.Shared.Next();
                }
 
                return ValueTask.CompletedTask;
            });
}

▍ Результаты

Посмотрим на результаты бенчмарков, в которых моделировалась IO bound работа.

Если идти последовательно, от самых простых кейсов с наименьшими числами к более сложным, то будет заметно отрезок с двумя концами, разница между которыми в количестве работы.

В частности, мы собираемся сосредоточиться на времени выполнения. Это означает, что необходимо посмотреть на столбец Mean, который и содержит в себе это время.

В целом, перфоманс Task.WhenAll и Parallel.ForEachAsync идёт рука об руку до тех пор, пока количество задач не достигает 100.

Начиная с этой отметки, даже с задержкой в одну миллисекунду Parallel.ForEachAsync ведёт себя значительно медленнее, чем Task.WhenAll. Причём относительное замедление пропорционально количеству ядер CPU.

Теперь перейдём к рассмотрению результатов бенчмарков, в которых моделировалась CPU bound работа. Взаимодействовать с результирующей таблицей будем аналогичным образом.

Напоминаю, что теперь вместо величины задержки ожидания, ниже отображается то количество работы, которое предполагается к загрузке CPU.

При 10 одновременных задачах и нагрузке на уровне 10 000 итераций Parallel.ForEachAsync начинает вырываться вперёд с чуть более, чем двукратным отрывом. При этом с ростом нагрузки растёт кратность отставания Task.WhenAll.

▍ Вывод

Итак, полученные результаты оказались достаточно интересными. Для кого-то, возможно, даже ожидаемыми.

Однако если подводить итоги, то мы увидели следующее: Parallel.ForEachAsync перформил лучше в условиях CPU bound работы, в то время как Task.WhenAll показал себя лучше в условиях IO bound работы.

С чем это может быть связано? Как мне кажется, планировщик потоков за кулисами Parallel.ForEachAsync ограничивает сам себя в терминах того, как много он сможет сделать в параллель. Соответственно, в случае Task.WhenAll никакого троттлинга нет, и всё управление и планирование потоков ложится на плечи операционной системы.

▍ P.S.

Среда выполнения для замера производительности из статьи:

BenchmarkDotNet v0.13.12, macOS Monterey 12.3 (21E230) [Darwin 21.4.0]
Apple M1 Pro, 1 CPU, 10 logical and 10 physical cores
.NET SDK 8.0.100

Полный код всех бенчмарков доступен по ссылке: gist.github.com/Stepami/17ceafbfdd91259a9821fd808e3eb08f

Ещё я веду Telegram-канал StepOne, куда выкладываю много интересного контента про коммерческую разработку, C# и мир IT глазами эксперта.