Узкое место традиционного последовательного цикла CPU

Эволюционный процесс опирается на разнообразие популяции, а разнообразие означает многократный рост размера популяции и числа оценок. Когда число оценок кандидатов достигает десятков тысяч,традиционный последовательный цикл CPU就成了整条流水线上最窄的一段：它一次只处理一个个体，硬件的并行能力几乎被闲置。

По одной за раз: модель выполнения последовательного цикла

Самая простая реализация рассматривает всю популяцию как список и в цикле поочерёдно извлекает особей: взять особь → декодировать в конкретные параметры → вызвать функцию оценки → записать приспособленность обратно. Соседние итерации почти не перекрываются: пока результат оценки не вернулся, запись не может продвинуться; пока запись не завершена, следующей особи некуда поместить результат. В итоге многоядерные, SIMD- и GPU-блоки большую часть времени простаивают, наблюдая, как одна особь проходит конвейер до конца.

Откуда же берутся накладные расходы

Линейно растущее число оценок: общее число оценок примерно равно размеру популяции × числу поколений; при достижении порядка 10⁵ время последовательного выполнения по часам растёт почти линейно.
Поштучное выполнение на уровне интерпретатора: поочерёдный цикл по особям, проверка границ и диспетчеризация типов дают фиксированные, но высокие постоянные накладные расходы.
Несогласованный доступ к памяти и пересылка данных: извлекаемые по одной особи часто расположены в памяти несогласованно, доля попаданий в кэш низкая, а затраты на пересылку оплачиваются снова и снова.
Синхронизация и планирование: чтобы получить следующую особь, поток выполнения вынужден снова и снова останавливаться и возобновляться.

Переводим масштаб во время

Возьмём популяцию из 1000 особей и 100 поколений — всего около 100 тысяч оценок кандидатов. Если одна оценка занимает в среднем 1 мс, только этап оценки последовательно потребует около 100 секунд, не считая затрат на вычисления операторов и планирование; если для поддержания разнообразия увеличить число перезапусков с 1 до 5, затраты почти линейно вырастут до примерно 500 секунд. Если тот же объём работы организовать по пакетам и передать параллельной аппаратуре, время по часам будет определяться главным образом числом пакетов, а не числом особей.

Когда это узкое место сужается

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

Структурное узкое место, а не дефект кода

Узкое место последовательного цикла CPU лежит на уровне модели выполнения: точечная оптимизация кода его не устранит. Чтобы действительно решить проблему, нужно перестроить поштучную обработку в пакетную — пакетирование, тензоризация и параллельное планирование; это же служит непосредственным мотивом для последующего проектирования тензоризованного вычислительного графа.

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

Возьмём популяцию 1000 особей и 100 поколений — всего около 100 тысяч оценок кандидатов; при 1 мс на оценку последовательно только этап оценки займёт около 100 секунд, а при 5 перезапусках почти линейно вырастет примерно до 500 секунд. После перехода к пакетной организации и передачи параллельной аппаратуре время по часам определяется главным образом числом пакетов, а не числом особей.

Вопрос 1

В традиционных эволюционных вычислениях кандидаты оцениваются по одной особи в последовательном цикле CPU. В чём главное ограничение модели выполнения?

Невозможность любых операций записи или обновления популяции

Соседние итерации почти не перекрываются, а многоядерные, SIMD- и GPU-блоки большую часть времени простаивают

Возможность обрабатывать только бинарное представление особей

Невозможность задать функцию приспособленности и, следовательно, оценить любого кандидата

Вопрос 2

Размер популяции 1000, 100 поколений, среднее время одной оценки кандидата — 1 мс. Каково примерное время по часам только этапа оценки при последовательном выполнении?

Около 100 секунд

Около 1 секунды

Около 10 секунд

Около 10000 секунд

Вопрос 3

Какой из следующих факторов НЕ увеличивает постоянные накладные расходы последовательного цикла?

Поштучный цикл на уровне интерпретатора

Поштучная проверка границ и диспетчеризация типов

Тензоризованное пакетное планирование

Несогласованный доступ к памяти и частые пересылки данных

Вопрос 4

При модели выполнения с пакетным параллелизмом что в основном определяет время по часам для того же общего объёма работы (например, 10⁵ оценок)?

Число пакетов и время на один пакет

Общее число особей-кандидатов

Длина кодировки популяции

Значение случайного зерна

Вопрос 5

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

Для поддержания разнообразия требуется выполнять несколько независимых перезапусков

Одна оценка занимает микросекунды, а размер популяции — лишь порядка сотен особей

Функция оценки включает дорогостоящее высокоточное физическое моделирование

Одна оценка занимает миллисекунды, а размер популяции — десятки тысяч особей

Кейс: выбор модели выполнения при ста тысячах оценок

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

Команда оптимизирует набор инженерных параметров с помощью эволюционного алгоритма: размер популяции 1000, 100 поколений, оценка каждой особи требует вызова симуляции, занимающей в среднем 1 мс. Текущая реализация — традиционный последовательный цикл CPU с поочерёдным выполнением декодирования, оценки и записи. Команда хочет, не снижая качества решения, сократить каждый цикл эксперимента с десяти с лишним минут до уровня минут; при этом для поддержания разнообразия популяции планируется увеличить число независимых перезапусков с 1 до 5.

Оцените время по часам только этапа оценки в текущей последовательной реализации и объясните, как изменится ситуация при увеличении числа перезапусков с 1 до 5. Исходя из этого определите, на чём следует сосредоточить оптимизацию.

Ответ:
Число оценок кандидатов за один запуск составляет примерно 1000 × 100 = 10⁵, что при 1 мс даёт около 100 секунд; при 5 перезапусках это около 5 × 10⁵ оценок, то есть примерно 500 секунд, а время по часам растёт почти линейно. Это показывает, что точечная настройка внутри операторов даёт ограниченную выгоду, а оптимизацию следует направить на уровень модели выполнения — пакетирование, тензоризацию и параллельное планирование, чтобы время по часам определялось числом пакетов, а не числом особей.

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

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