Comments 2
>Соответственно, порядок подстановок выглядит достаточно случайным.
Порядок подстановки определен — от меньших функций к большим, для больших функций удельная стоимость вызова невелика. Для того чтобы оптимизации не зависели от инлайнинга есть Inter-Procedural Optimization в icc.
> Т.е. наилучшую пользу от подстановок можно получить с использованием динамического профилировщика.
PGO используется очень редко т.к. толку от нее немного. Раньше, когда от порядка условий зависела скорость выполнения программы от PGO было больше толку.
>Если программисту ясно, что какие-то вычисления будут выполняться редко, то имеет смысл выносить их в отдельные функции и запрещать их подставлять директивно. Это улучшит локальность выполняемого кода и, скорее всего, приведет к небольшому выигрышу в производительности за счет более оптимального использования подсистемы кешей.
Никакого увеличения локальности не произойдет. Выигрыш в увеличении полезного обьема кэша за счет убирания фрейма вызова функции минимален.
Вообщем статься из разряда «вредных советов». Единственное о чем нужно было упомянуть — ключи -ip, -ipo и -inline-level=0 (выключение инлайнинга для профилировки).
Порядок подстановки определен — от меньших функций к большим, для больших функций удельная стоимость вызова невелика. Для того чтобы оптимизации не зависели от инлайнинга есть Inter-Procedural Optimization в icc.
> Т.е. наилучшую пользу от подстановок можно получить с использованием динамического профилировщика.
PGO используется очень редко т.к. толку от нее немного. Раньше, когда от порядка условий зависела скорость выполнения программы от PGO было больше толку.
>Если программисту ясно, что какие-то вычисления будут выполняться редко, то имеет смысл выносить их в отдельные функции и запрещать их подставлять директивно. Это улучшит локальность выполняемого кода и, скорее всего, приведет к небольшому выигрышу в производительности за счет более оптимального использования подсистемы кешей.
Никакого увеличения локальности не произойдет. Выигрыш в увеличении полезного обьема кэша за счет убирания фрейма вызова функции минимален.
Вообщем статься из разряда «вредных советов». Единственное о чем нужно было упомянуть — ключи -ip, -ipo и -inline-level=0 (выключение инлайнинга для профилировки).
Спасибо за ваш комментарий.
Подстановка — одна из главных межпроцедурных оптимизаций (Inter-Procedural Optimization). Все скалярные и цикловые оптимизации страдают от наличия вызовов в коде. Векторизация циклов с вызовами не выполняется (кроме случаев векторных функций), Для того, чтобы протянуть в вызываемую функцию константный аргумент нужно выполнять клонирование функций, что не всегда является возможным. Можно провести массу примеров, когда подстановка улучшает производительность. Поэтому не понял вашу первую мысль.
От PGO достаточно много толку. Некоторые оптимизации выполняются только с PGO, например, трансформации данных. Благодаря примерному представлению о размерах массивов эффективней выполняются цикловые оптимизации. Мой эксперимент показывает, что с PGO эффективней выполняются подстановки. Т.е. PGO мало используется потому, что не все программисты представляют какие PGO решает задачи + не все заинтересованы в получении высокой производительности. Смысл вашего посыла о порядке условий от меня ускользнул. Какой порядок условий вы имеете в виду и почему от него перестала зависеть скорость выполнения программы?
Компиляторы и gcc и icc занимаются тем, что выносят в специальные области «холодный» код. Аналогом является вынос холодного кода в функции и запрет их подстановки. Мне кажется вы не поняли, о чем идет речь, поскольку непонятно, что вы имеете в виду под «убиранием фрейма вызова функции» в этом контексте.
Подстановка — одна из главных межпроцедурных оптимизаций (Inter-Procedural Optimization). Все скалярные и цикловые оптимизации страдают от наличия вызовов в коде. Векторизация циклов с вызовами не выполняется (кроме случаев векторных функций), Для того, чтобы протянуть в вызываемую функцию константный аргумент нужно выполнять клонирование функций, что не всегда является возможным. Можно провести массу примеров, когда подстановка улучшает производительность. Поэтому не понял вашу первую мысль.
От PGO достаточно много толку. Некоторые оптимизации выполняются только с PGO, например, трансформации данных. Благодаря примерному представлению о размерах массивов эффективней выполняются цикловые оптимизации. Мой эксперимент показывает, что с PGO эффективней выполняются подстановки. Т.е. PGO мало используется потому, что не все программисты представляют какие PGO решает задачи + не все заинтересованы в получении высокой производительности. Смысл вашего посыла о порядке условий от меня ускользнул. Какой порядок условий вы имеете в виду и почему от него перестала зависеть скорость выполнения программы?
Компиляторы и gcc и icc занимаются тем, что выносят в специальные области «холодный» код. Аналогом является вынос холодного кода в функции и запрет их подстановки. Мне кажется вы не поняли, о чем идет речь, поскольку непонятно, что вы имеете в виду под «убиранием фрейма вызова функции» в этом контексте.
Sign up to leave a comment.
Критерий выгодности подстановки и динамическая профилировка