Каковы хорошие эвристики для встроенных функций?

Question

Учитывая, что вы пытаетесь оптимизировать только скорость, какова хорошая эвристика для принятия решения о включении функции или нет? Очевидно, что размер кода должен быть важен, но есть ли другие факторы, которые обычно используются, когда, скажем, gcc или icc определяют, встроить ли вызов функции? Была ли значительная академическая работа в этом районе?

Answer 1

В Википедии есть a несколько абзацев об этом, с некоторыми ссылками внизу:

• Помимо проблем с размером памяти и кешем, еще одним соображением является давление регистра . С точки зрения компилятора «добавленные переменные из встроенной процедуры могут потреблять дополнительные регистры, а в области, где давление в регистре уже высокое, это может вызвать разлив, что вызывает дополнительные обращения к ОЗУ».

Языки с JIT-компиляторами и загрузкой классов времени выполнения имеют другие компромиссы, так как виртуальные методы статически не известны, однако JIT может собирать информацию о профилировании во время выполнения, такую ​​как частота вызова метода:

• Проектирование, реализация и оценка оптимизаций в компиляторе Just-in-Time (для Java) рассказывает о методе встраивания статических методов и динамически загружаемых классов и его улучшениях в производительности.

• Практика JUDO: Java в условиях динамической оптимизации утверждает, что их «политика встраивания основана на размере кода и информации о профилировании. Если частота выполнения записи метода ниже определенного порога, метод не является встроенным, потому что он рассматривается как холодный метод. Чтобы избежать взрыва кода, мы не включаем метод с размером байт-кода более 25 байтов ... Чтобы избежать встраивания по глубокой цепочке вызовов, вложение останавливается, когда накопленный размер встроенного байтового кода в цепочке вызовов превышает 40 байтов. " Несмотря на то, что они имеют информацию о профилировании во время выполнения (частоту вызова метода), они все же стараются избегать встраивания больших функций или цепочек функций для предотвращения раздувания.

Поиск в Google Scholar обнаруживает ряд статей, например

• Влияние оптимизации расширения кода на структуру кэша команд
• Встраивание функций в зависимости от размера кода для встроенных процессоров

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

• Справочник по проектированию компиляторов: оптимизация и генерация машинного кода содержит главу о методах статистического и машинного обучения в проектировании компиляторов, с эвристикой для установки различных параметров и профилирования результатов. Эта глава ссылается на документ Vaswani et al. Чувствительные к микроархитектуре эмпирические модели для оптимизации компиляторов , где они предлагают "использование эмпирического моделирования". методы построения чувствительных к микроархитектуре моделей для оптимизации компилятора ".

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

Answer 2

Насколько я видел, размер функции - это единственный фактор, используемый компиляторами для определения inline. Однако, если вы выполняете оптимизацию по профилю (PGO), я считаю, что компилятор может использовать другие переменные, такие как количество вызовов / время установления вызова.

Answer 3

В .NET в основном по размеру. Измерьте размер родительской функции и дочерней функции в скомпилированных байтах. Затем измерьте размер объединенной функции. Если объединенная функция меньше, то встраивание - хорошая идея.

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

Answer 4

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

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