Максимальное использование параллельной библиотеки задач .NET

• Если результаты должны быть заказаны, то для того, чтобы вы могли распараллелить цикл, вы должны иметь возможность выполнять фактическую работу в любом порядке, а затем сортировать результаты. Это может быть или не быть более эффективным, чем выполнение работы в первую очередь, в зависимости от ситуации. Если преимущество распараллеливания работы, которое может быть выполнено в любом порядке, больше, чем стоимость заказа результатов, тогда это чистая прибыль. Если эта задача просто недостаточно сложна, ваше оборудование не позволяет много распараллеливать или если оно не распараллеливается хорошо (т.е. У вас много ожиданий из-за зависимостей данных), то сортировка результатов может занять больше (или, что еще хуже, распараллеливание цикла занимает больше времени даже без сортировки, см. второй вопрос), и поэтому вы не должны его распараллеливать.

  Обратите внимание, что если фактические единицы работы должны выполняться в определенном порядке, а не просто нуждаться в результатах в определенном порядке, то вы либо не сможете их распараллелить, либо не сможете распараллелить его почти так же эффективно. Если вы неправильно синхронизируете доступ к ресурсам общего доступа, вы фактически получите неправильный результат (как это было в вашем случае). Для этого вам нужно помнить, что оптимизация производительности бессмысленна, если вы не можете найти правильный результат.

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

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

Ясно, что TPL не является хорошим инструментом для построения упорядоченного набора, подобного запросу.

Если у вас есть ряд задач для выполнения множества элементов, вы можете использовать BlockingCollection. Задачи могут выполняться параллельно, но порядок набора поддерживается.

Класс BlockingCollection

• Это не лучше или хуже для неупорядоченных списков - ваша проблема в # 1 заключалась в том, что у вас была общая зависимость от StringBuilder, поэтому сбой параллельного запроса. TPL прекрасно работает над независимыми подразделениями. Даже тогда есть простые трюки, которые вы можете использовать для принудительной оценки параллельного запроса и сохранения исходного порядка результатов при завершении параллельных операций.

• TPL и PLINQ являются технически отличными вещами; PLINQ использует TPL для достижения этой цели. Тем не менее PLINQ пытается проверить вашу архитектуру и структурировать выполнение набора, насколько это возможно. TPL - это просто оболочка вокруг архитектуры задачи. Это зависит от вас, чтобы определить, накладные расходы на создание задачи (что-то вроде 1 МБ памяти), а накладные расходы на переключение контекста для выполнения задач больше, чем просто запуск задачи в серийном порядке.

В точке 1, если вы используете TPL, вы не знаете, в каком порядке запускается эта задача. Это красота параллельных и последовательных. Есть средства для контроля порядка вещей, но тогда вы, вероятно, потеряете преимущества параллельных.

В 2: TPL использует многоядерные процессоры из коробки. Но при использовании нескольких потоков на самом деле всегда накладные расходы. Нагрузка на планировщик увеличивается, переход потока (контекста) не является бесплатным. Чтобы синхронизировать данные во избежание гоночных условий, вам, вероятно, понадобится механизм блокировки, который также добавит накладные расходы.

Создание быстрого параллельного алгоритма с использованием TPL сделано намного проще, но все же своего рода искусство.