Совместное использование withTaskGroup и async let
Ниже приведена упрощенная версия того, как я использую withTaskGroup:
let allResults = await withTaskGroup(of: ([Double], Float, Float, Int).self,
returning: FinalResult.self,
body: { taskGroup in
for operation in operations {
taskGroup.addTask { @MainActor in
let value = await operation.execute()
return value
}
}
// Collect child task results here...
})
Функция execute выглядит следующим образом, когда процессы включают довольно интенсивные математические вычисления, такие как извлечение признаков для модели машинного обучения:
func execute() async -> ([Double], Float, Float, Int) {
async let result0: [Double] = process0() ?? []
async let result1: Float = process1() ?? -1
async let result2: Float = process2()
async let result3: Int = process3()
return (await result0, await result1, await result2, await result3)
}
Проблема, с которой я сталкиваюсь, заключается в том, что окончательный результат непостоянен, иногда я получаю правильные результаты, а иногда нет. Например, иногда я получаю массив всех нулей для 512 функций (длина массива), когда они должны быть ненулевыми числами. Наоборот, если бы я просто использовал for loop вместо withTaskGroup, результат был бы более последовательным.
Поэтому мне интересно, есть ли какие-либо последствия использования withTaskGroup и async let вместе, поскольку это параллель параллели. В отличие от параллелизма, мое понимание параллелизма заключается в том, что каждое ядро ЦП назначается для одновременной обработки задач, но если бы я предоставил 4 operations, это означает, что 4 x 4 = 16 параллельных процессов, что больше, чем количество доступных ядер.
В Swift Concurrency параллель или нет не может быть определена таким образом. Это решает исполнитель Актера и задача требует контекста. И если вы хотите спроектировать высокопроизводительное выполнение параллелизма. Вы должны использовать libDispatch's DispatchQueue.concurrentPerform(iterations:execute:) с выделенной синхронизацией. На самом деле, swift Concurrency не предназначен для параллельного выполнения. TaskGroup довольно медленный для большого параллельного выполнения.
@ Арбуз, могу ли я использовать DispatchQueue.concurrentPerform(iterations:execute:) вместе с асинхронным ожиданием?
FWIW, если у вас есть гонки данных, как предполагает Роб Нейпир, переход на concurrentPerform ничего не сделает, чтобы это исправить. А в хорошо спроектированном параллельном коде (где вы «шагаете», чтобы максимизировать работу за итерацию) разница между concurrentPerform и группой задач становится в значительной степени несущественной. Кроме того, в целом, если вы много работаете с CoreML, преимущества параллелизма в ЦП несколько уменьшаются, когда вычисления связаны с ГП или НС.
Отвечая на ваш вопрос, технически вы можете использовать concurrentPerform в сочетании с async-await. Но это не идеально, потому что кооперативный пул потоков больше не может рассуждать об использовании ЦП, если у вас есть GCD, связывающий ядра. Если вы на самом деле не используете совместный пул потоков во время использования concurrentPerform, это, вероятно, минимальная проблема. Но, как я уже сказал, мои эмпирические сравнения между хорошо спроектированными concurrentPerform и целевыми группами в любом случае показывают очень скромные преимущества. Кроме того, вам, вероятно, следует сначала исправить проблемы с гонкой данных (или что-то еще).
@Роб Большое спасибо. Это очень информативно.
Ответы 1
Это определенно не проблема. Проблема гораздо более вероятна в том, что ваш код в process1() и т. д. не является потокобезопасным (например, полагаясь на данные, считанные из свойств, которые не являются потокобезопасными, или манипулирует возвращаемым массивом недопустимым образом). Превышение количества ядер не вызовет логической проблемы, если вы правильно написали код. Это может вызвать проблемы с производительностью, в зависимости от многих факторов, но не вызовет проблем с корректностью.
Вы можете включить «Строгую проверку параллелизма» в настройках сборки, что может помочь вам найти ошибки. (Он также может найти множество проблем в Foundation, которые вы не можете исправить, поэтому иногда лучше использовать его для изолированного кода или небольшого проекта.)
Спасибо. Я попробую настройку проверки Strict Concurrency. Всегда ли это может быть связано с гонкой данных?
Нет, есть несколько возможных ошибок. Это зависит от того, что находится в коде process. Но, учитывая ваше описание, первое, что я предполагаю, это то, что вы обращаетесь к данным между потоками недопустимым образом.
Не должно быть проблем с
async letв связке с группами задач. Ваша проблема скорее всего в другом. Я бы предложил создать минимальный воспроизводимый пример проблемы.