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

Балансировка нагрузки не бесплатна; она требует затрат на переключение контекста (ядру), поиск незанятых процессоров и выбор работы для переназначения. Особенно на машине, где задачи переключаются постоянно, десятки раз в секунду, эта стоимость возрастает.

Так в чем же разница? Перекладывание работы означает, что вы дополнительно нагружаете избыточные ресурсы (занятые процессоры) накладными расходами на балансировку нагрузки. Зачем прерывать занятый процессор административными делами, если рядом есть процессор, которому нечего делать? С другой стороны, кража работы позволяет незанятым процессорам управлять балансировщиком нагрузки, пока занятые процессоры занимаются своими делами. Кража работы экономит время.

Example

Consider: Процессор A имеет две задачи, назначенные ему. Они занимают время a1 и a2, соответственно. Процессор B, находящийся неподалеку (возможно, на расстоянии отскока кэша), простаивает. Процессоры идентичны во всех отношениях. Мы предполагаем, что код для каждой задачи и ядра находится в i-кэше обоих процессоров (без дополнительных страничных ошибок при распределении нагрузки).

Переключение контекста любого вида (включая балансировку нагрузки) занимает время c.

Без балансировки нагрузки

Время выполнения задач будет a1 + a2 + c. Процессор A выполнит всю работу и понесет одно переключение контекста между двумя задачами.

Кража работы

Предположим, что B украдет a2, затратив на это время переключения контекста. Работа будет выполнена за max(a1, a2 + c) времени. Предположим, что процессор A начинает работать над a1; пока он это делает, процессор B украдет a2 и не прервет обработку a1. Все накладные расходы на B - это свободные циклы.

Если a2 была более короткой задачей, то в этом сценарии вы эффективно скрыли стоимость переключения контекста; общее время составляет a1.

Перекладывание работы

Предположим, что B завершает a2, как описано выше, но A несет затраты на его перемещение ("перекладывание" работы). Работа в этом случае будет выполнена за max(a1, a2) + c времени; переключение контекста теперь всегда добавляется к общему времени, а не скрывается. Циклы простоя процессора B были потрачены впустую; вместо этого занятый процессор A потратил время на перекладывание работы на B.

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

Как ваш поток решает, когда это так. много работы, чтобы он прекратил выполнять эту работу, чтобы найти друга, который поможет?

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

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

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

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

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

Я думаю, что ваше отредактированное предложение с потоком отправки, выполняющим «умное» распределение работы, потенциально является преждевременной оптимизацией против кражи работы. Неужели ваши незанятые потоки так сильно ударяют по шине, что ваши неактивные потоки не могут выполнять какую-либо работу? Затем наступает время оптимизировать кражу работы.

Итак, в отличие от «Кража работы», то, что на самом деле подразумевается здесь под «Рабочим пожиманием плечами», является нормальной авансовой работой стратегия планирования, учитывающая процессор, лояльность кеша и памяти и масштабируемая.

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

Основное преимущество алгоритмов "кражи работы" заключается в том, что накладные расходы на перемещение работы снижаются до 0, когда все заняты. Таким образом, накладные расходы возникают только тогда, когда какой-то процессор иначе простаивал бы, и эти накладные расходы в основном оплачиваются простаивающим процессором, а занятый процессор несет лишь очень небольшие расходы, связанные с синхронизацией шины.

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

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

Боюсь, я не знаю, что вы можете найти в Google.