Сообщение Re[11]: Метапрограммирование в примерах от 15.05.2015 6:02
Изменено 15.05.2015 6:08 Evgeny.Panasyuk
Здравствуйте, Tilir, Вы писали:
EP>>Что конкретно имеется в виду? Для какой цели?
T>Посмотреть на плюсовый код после всех шаблонных подстановок. На уровне: "сколько раз раскрылся вот этот вот шаблон и с какими параметрами".
Достаточно спровоцировать warning внутри шаблона — и компилятор выдаст backtrace воплощений шаблонов, со всеми аргументами. Правда нужно учитывать что воплощения могут мемоизироваться, и повторного вывода не будет.
T>Цели в основном: оценка оверхеда по размеру кода,
По-хорошему нужно смотреть на конечный размер после линковки, так как в объектных файлах может быть много функций которые по факту заинлайнены и больше нигде не требуются. Либо же смотреть размер отдельных конкретных функций.
T>поиск узких мест по времени компиляции.
Само по себе раскрытие здесь не сильно поможет. Нужно либо делать ручное "разделяй и властвуй", либо делать профилирование а-ля Templight.
EP>>Если же для оценки оптимальности результирующего кода — то тут естественно нужно смотреть в результирующий ASM.
T>Ассемблер после оптимизирующего компилятора с LTO это мелко рубленная каша, лучше уж IR на начальных фазах.
Если на начальных фазах — то значит не все оптимизации применены, для оценки оптимальности это как-то не айс. А при просмотре ASM обычно есть представление о том что там примерно должны быть, или хотя бы о том чего там быть точно не должно.
EP>>Что конкретно имеется в виду? Для какой цели?
T>Посмотреть на плюсовый код после всех шаблонных подстановок. На уровне: "сколько раз раскрылся вот этот вот шаблон и с какими параметрами".
Достаточно спровоцировать warning внутри шаблона — и компилятор выдаст backtrace воплощений шаблонов, со всеми аргументами. Правда нужно учитывать что воплощения могут мемоизироваться, и повторного вывода не будет.
T>Цели в основном: оценка оверхеда по размеру кода,
По-хорошему нужно смотреть на конечный размер после линковки, так как в объектных файлах может быть много функций которые по факту заинлайнены и больше нигде не требуются. Либо же смотреть размер отдельных конкретных функций.
T>поиск узких мест по времени компиляции.
Само по себе раскрытие здесь не сильно поможет. Нужно либо делать ручное "разделяй и властвуй", либо делать профилирование а-ля Templight.
EP>>Если же для оценки оптимальности результирующего кода — то тут естественно нужно смотреть в результирующий ASM.
T>Ассемблер после оптимизирующего компилятора с LTO это мелко рубленная каша, лучше уж IR на начальных фазах.
Если на начальных фазах — то значит не все оптимизации применены, для оценки оптимальности это как-то не айс. А при просмотре ASM обычно есть представление о том что там примерно должны быть, или хотя бы о том чего там быть точно не должно.
Re[11]: Метапрограммирование в примерах
Здравствуйте, Tilir, Вы писали:
EP>>Что конкретно имеется в виду? Для какой цели?
T>Посмотреть на плюсовый код после всех шаблонных подстановок. На уровне: "сколько раз раскрылся вот этот вот шаблон и с какими параметрами".
Достаточно спровоцировать warning внутри шаблона — и компилятор выдаст backtrace воплощений шаблонов, со всеми аргументами. Правда нужно учитывать что воплощения могут мемоизироваться, и повторного вывода не будет.
T>Цели в основном: оценка оверхеда по размеру кода,
По-хорошему нужно смотреть на конечный размер после линковки, так как в объектных файлах может быть много функций которые по факту заинлайнены и больше нигде не требуются. Либо же смотреть размер отдельных конкретных функций.
T>поиск узких мест по времени компиляции.
Само по себе раскрытие здесь не сильно поможет. Нужно либо делать ручное "разделяй и властвуй", либо делать профилирование а-ля Templight.
EP>>Если же для оценки оптимальности результирующего кода — то тут естественно нужно смотреть в результирующий ASM.
T>Ассемблер после оптимизирующего компилятора с LTO это мелко рубленная каша, лучше уж IR на начальных фазах.
Если на начальных фазах — то значит не все оптимизации применены, для оценки оптимальности это как-то не айс. А при просмотре ASM обычно есть представление о том что там примерно должно быть, или хотя бы о том чего там быть точно не должно.
EP>>Что конкретно имеется в виду? Для какой цели?
T>Посмотреть на плюсовый код после всех шаблонных подстановок. На уровне: "сколько раз раскрылся вот этот вот шаблон и с какими параметрами".
Достаточно спровоцировать warning внутри шаблона — и компилятор выдаст backtrace воплощений шаблонов, со всеми аргументами. Правда нужно учитывать что воплощения могут мемоизироваться, и повторного вывода не будет.
T>Цели в основном: оценка оверхеда по размеру кода,
По-хорошему нужно смотреть на конечный размер после линковки, так как в объектных файлах может быть много функций которые по факту заинлайнены и больше нигде не требуются. Либо же смотреть размер отдельных конкретных функций.
T>поиск узких мест по времени компиляции.
Само по себе раскрытие здесь не сильно поможет. Нужно либо делать ручное "разделяй и властвуй", либо делать профилирование а-ля Templight.
EP>>Если же для оценки оптимальности результирующего кода — то тут естественно нужно смотреть в результирующий ASM.
T>Ассемблер после оптимизирующего компилятора с LTO это мелко рубленная каша, лучше уж IR на начальных фазах.
Если на начальных фазах — то значит не все оптимизации применены, для оценки оптимальности это как-то не айс. А при просмотре ASM обычно есть представление о том что там примерно должно быть, или хотя бы о том чего там быть точно не должно.