Сообщение Re[7]: Ширина кода - газетная vs книжная от 14.01.2025 10:29
Изменено 14.01.2025 11:20 serg_joker
Re[7]: Ширина кода - газетная vs книжная
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А любой ли компилятор сумеет это свернуть в код без формирования функции и ее вызова?
Наверняка не любой, и не при любых настройках оптимизаци.
Мне ответ на этот вопрос неинтересен. А интересен ответ ответ на "будут ли компиляторы, которыми я пользуюсь для сборки релиза генерировать код не хуже, чем без IIL".
И да, мой ответ был бы скорее всего да (99%) для данного кода, но если важно, то нужно проверить.
Задачи написания максимально эффективного и максимально читабельного(что вообще субъективно) кода вообще конфликтуют зачастую.
А вот встречный вопрос:
предположим, что TypeWithLongName нетривиален и его копия/перемещение дороги.
А любой ли компилятор сможет в случае тернарного выражения выкинуть промежуточный временный объект-результат собственно тернарного выражения и сразу создавать VarWithLongName без копии/перемещения?
Хинт — нет, не любой и не с любыми настройками оптимизации (msvc /O0 точно не выкинет, возможно и с оптимизацией тоже) и тут стоимость копии может превысить расходы на вызов лямбды.
А версия с лямбдой — да, т.к. RVO.
Кроме того, у тебя там `?:`, т.е. бранч, стоимость миспредикшена которого может превысить стоимость вызова.
В случае с if, я могу добавить `[likely]]` и потенциально улучшить код, для тернарного оператора такой опции нет.
Короче, как всегда, написание оптимального кода без профилирования — дело неблагодарное.
Конкретно данный пример я бы написал с лямбдой, из-за RVO.
ЕМ>А любой ли компилятор сумеет это свернуть в код без формирования функции и ее вызова?
Наверняка не любой, и не при любых настройках оптимизаци.
Мне ответ на этот вопрос неинтересен. А интересен ответ ответ на "будут ли компиляторы, которыми я пользуюсь для сборки релиза генерировать код не хуже, чем без IIL".
И да, мой ответ был бы скорее всего да (99%) для данного кода, но если важно, то нужно проверить.
Задачи написания максимально эффективного и максимально читабельного(что вообще субъективно) кода вообще конфликтуют зачастую.
А вот встречный вопрос:
предположим, что TypeWithLongName нетривиален и его копия/перемещение дороги.
А любой ли компилятор сможет в случае тернарного выражения выкинуть промежуточный временный объект-результат собственно тернарного выражения и сразу создавать VarWithLongName без копии/перемещения?
Хинт — нет, не любой и не с любыми настройками оптимизации (msvc /O0 точно не выкинет, возможно и с оптимизацией тоже) и тут стоимость копии может превысить расходы на вызов лямбды.
А версия с лямбдой — да, т.к. RVO.
Кроме того, у тебя там `?:`, т.е. бранч, стоимость миспредикшена которого может превысить стоимость вызова.
В случае с if, я могу добавить `[likely]]` и потенциально улучшить код, для тернарного оператора такой опции нет.
Короче, как всегда, написание оптимального кода без профилирования — дело неблагодарное.
Конкретно данный пример я бы написал с лямбдой, из-за RVO.
Re[7]: Ширина кода - газетная vs книжная
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А любой ли компилятор сумеет это свернуть в код без формирования функции и ее вызова?
Наверняка не любой, и не при любых настройках оптимизаци.
Мне ответ на этот вопрос неинтересен. А интересен ответ ответ на "будут ли компиляторы, которыми я пользуюсь для сборки релиза генерировать код не хуже, чем без IIL".
И да, мой ответ был бы скорее всего да (99%) для данного кода, но если важно, то нужно проверить.
"Любой компилятор" может в принципе не поддерживать C++11 и выше, mandatory RVO, разворот циклов и множество других вещей, влияющих на скорость выполнения. Смысла ориентироваться на "любой компилятор" не вижу никакого смысла.
Задачи написания максимально эффективного с точки зрения выполнения и максимально читабельного (что вообще субъективно) кода вообще конфликтуют зачастую.
А вот встречный вопрос:
предположим, что TypeWithLongName нетривиален и его копия/перемещение дороги.
А любой ли компилятор сможет в случае тернарного выражения выкинуть промежуточный временный объект-результат собственно тернарного выражения и сразу создавать VarWithLongName без копии/перемещения?
Хинт — нет, не любой и не с любыми настройками оптимизации (msvc /O0 точно не выкинет, возможно и с оптимизацией тоже) и тут стоимость копии может превысить расходы на вызов лямбды.
А версия с лямбдой — да, т.к. RVO.
Кроме того, у тебя там `?:`, т.е. бранч, стоимость миспредикшена которого может превысить стоимость вызова.
В случае с if, я могу добавить `[likely]]` и потенциально улучшить код, для тернарного оператора такой опции нет.
Короче, как всегда, написание оптимального кода без профилирования — дело неблагодарное.
Конкретно данный пример я бы написал с лямбдой, из-за RVO.
ЕМ>А любой ли компилятор сумеет это свернуть в код без формирования функции и ее вызова?
Наверняка не любой, и не при любых настройках оптимизаци.
Мне ответ на этот вопрос неинтересен. А интересен ответ ответ на "будут ли компиляторы, которыми я пользуюсь для сборки релиза генерировать код не хуже, чем без IIL".
И да, мой ответ был бы скорее всего да (99%) для данного кода, но если важно, то нужно проверить.
"Любой компилятор" может в принципе не поддерживать C++11 и выше, mandatory RVO, разворот циклов и множество других вещей, влияющих на скорость выполнения. Смысла ориентироваться на "любой компилятор" не вижу никакого смысла.
Задачи написания максимально эффективного с точки зрения выполнения и максимально читабельного (что вообще субъективно) кода вообще конфликтуют зачастую.
А вот встречный вопрос:
предположим, что TypeWithLongName нетривиален и его копия/перемещение дороги.
А любой ли компилятор сможет в случае тернарного выражения выкинуть промежуточный временный объект-результат собственно тернарного выражения и сразу создавать VarWithLongName без копии/перемещения?
Хинт — нет, не любой и не с любыми настройками оптимизации (msvc /O0 точно не выкинет, возможно и с оптимизацией тоже) и тут стоимость копии может превысить расходы на вызов лямбды.
А версия с лямбдой — да, т.к. RVO.
Кроме того, у тебя там `?:`, т.е. бранч, стоимость миспредикшена которого может превысить стоимость вызова.
В случае с if, я могу добавить `[likely]]` и потенциально улучшить код, для тернарного оператора такой опции нет.
Короче, как всегда, написание оптимального кода без профилирования — дело неблагодарное.
Конкретно данный пример я бы написал с лямбдой, из-за RVO.