gcc 4.4.x и -fprofile-** (-fprofile-dir реальная тема в новом компилляторе)

[Fireal]

Господа, УРА!! Теперь в новой версии gcc опцией "-fprofile-dir" можно задавать путь для сбора статистики и последующего её использования, и это работает!!! Пробовал компиллировать libvorbis и vorbis-tools - ускорение ощутимое! На Atllon64 3000+ скорость кодирования из flac'а 19-20x получается, т.е. +10% к моей тотальной оптимизации без использования профилей И это без пересборки мира!

Проблемы начались при пересборки мира, portage упал но видимо не из-за профилей... до этого делал зачистку системы, возможно там накасячил... поставлю gentoo заново, там посмотрим...

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

[Dimanish]

Для тех кто в танке или не каждый день следит за перипетиями в changelog'е gcc - можно поподробнее? В какой конкретно версии gcc появилась возможность использовать сбор статистики?
Как gcc использует эту статистику?
Что за профили и как их включить? Надеюсь имеется соответствующий USE флаг?

[Xaktyc]

Проблемы начались при пересборки мира, portage упал но видимо не из-за профилей..

Портеж работает на питоне, поэтому врядли. Интересно, что конкретно ты там чистил и косячил.

[Fireal]

Для тех кто в танке или не каждый день следит за перипетиями в changelog'е gcc - можно поподробнее? В какой конкретно версии gcc появилась возможность использовать сбор статистики?
Как gcc использует эту статистику?
Что за профили и как их включить? Надеюсь имеется соответствующий USE флаг?

Вот в этой статье многое объясняется GCC: компилляция на форсаже с турбонаддувом, собственно она и вдохновила на эксперименты. Возможность использования профилей появилась давно, но было проблемно организовать сбор нужной статистики в нужном месте. В версии компиллятора 4.4.* появился параметр, задающий самое место, что значительно упростило использование этой вкуснейшей из возможностей
Вот ещё полезная ссылочка по флагам оптимизации
А это собственно та вкусность, которую добавили в новой версии компиллятора:

-fprofile-dir=path
Set the directory to search the profile data files in to path. This option affects only the profile data generated by -fprofile-generate, -ftest-coverage, -fprofile-arcs and used by -fprofile-use and -fbranch-probabilities and its related options. By default, GCC will use the current directory as path thus the profile data file will appear in the same directory as the object file.

Проблемы начались при пересборки мира, portage упал но видимо не из-за профилей..

Портеж работает на питоне, поэтому врядли. Интересно, что конкретно ты там чистил и косячил.

После продолжительного использования системы решил всё удалить и как-бы заново поставить. Сделал emerge --unmerge <весь несистемный софт типа kde, xorg, mplayer и.т.д..>, потом emerge --depclean, далее потестил новую оптимизацию с профилями, и добавя к CFLAGS -fprofile-generate стал делать emerge -vuDN world, сделав перед этим emerge --sync

[Xaktyc]

И как? Собственно в чем был замечен прирост-то?

[Fireal]

И как? Собственно в чем был замечен прирост-то?

Я конкретно oggenc тестировал из пакета vorbis-tools, собрав предварительно libvorbis тоже с обратной связью.
С простой оптимизацией скорость кодирования альбома Deftones Deftones на Athlon64 3000+ из flac'а в ogg была ~16x, с новой же стала ~19.5x.

[sspphheerraa]

Господа, УРА!! Теперь в новой версии gcc опцией "-fprofile-dir" можно задавать путь для сбора статистики и последующего её использования, и это работает!!!

хы, интересно - аналогино кодированию видео в несколько проходов (с использованием статистики предыдущего прохода)
Ждемс тестов компиляции ОО

[Fireal]

Господа, УРА!! Теперь в новой версии gcc опцией "-fprofile-dir" можно задавать путь для сбора статистики и последующего её использования, и это работает!!!

хы, интересно - аналогино кодированию видео в несколько проходов (с использованием статистики предыдущего прохода)
Ждемс тестов компиляции ОО

Компиляция будет естественно дольше Тут фишка в производительности софта после пересборки...

[proDOOMman]

А я думал, что это работает как ccache

[Fireal]

А я думал, что это работает как ccache

Надо было тему в программирование однако, ибо фишка дистронезависима....

[proDOOMman]

А я думал, что это работает как ccache

Надо было тему в программирование однако, ибо фишка дистронезависима....

Но только в генте gcc используется так часто ;-)

[Fireal]

А я думал, что это работает как ccache

Надо было тему в программирование однако, ибо фишка дистронезависима....

Но только в генте gcc используется так часто ;-)

Бгг А Debian? Он ведь тоже source-based, просто не все об этом знают

[Poor Fred]

Тут фишка в производительности софта после пересборки...

Я вот только не понял - действует ли оптимизация для другой, обновленной, версии проги? Или каждый раз надо два раза пересобирать?

[Fireal]

Тут фишка в производительности софта после пересборки...

Я вот только не понял - действует ли оптимизация для другой, обновленной, версии проги? Или каждый раз надо два раза пересобирать?

2 раза пересобирать. Между пересборками нужно ещё и запускать прогу, чтобы набрать статистику

[Poor Fred]

Между пересборками нужно ещё и запускать прогу, чтобы набрать статистику

Да это понятно.

Похоже, для десктопа не очень подходит. Скорее для встраиваемых или редко обновляемых систем.

[sspphheerraa]

Компиляция будет естественно дольше Тут фишка в производительности софта после пересборки...

да я понял фишку
/видео тоже в несколько проходов кодируется дольше чем в один, - фишка в том что размер многопроходного меньше при одинаковом качестве

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

Между пересборками нужно ещё и запускать прогу, чтобы набрать статистику

Да это понятно.

Похоже, для десктопа не очень подходит. Скорее для встраиваемых или редко обновляемых систем.

Почему7 для таких монстров как KDE или OO это, по-моему, более чем актуально... а ведь это типичные десктопные компоненты

[serzh-z]

на данный момент с использованием прелинка ОО достаточно быстро работает если самосборный,

Как может помочь прелинк OOo, если ощутимая часть OOo написана на Java, а *большая* часть библиотек подгружается динамически?

[Poor Fred]

Почему7 для таких монстров как KDE или OO это, по-моему, более чем актуально... а ведь это типичные десктопные компоненты

Ну если только 3,5 А 4-ка то и дело обновляется, да новые релизы выходят.
Давеча попробовал пересобрать с этим флагом все qt-*, но некоторые не стали с ним собираться. Пришлось их пропустить. Так это надо тогда записывать, что именно собралось с новым флагом и что нужно будет позже пересобрать. Короче, практически махнул на эту фичу рукой. Так, если только отдельные проги, Firefox, Thunderbird там к примеру...

[mikki43306]

...а может и сам gcc)

[sspphheerraa]

на данный момент с использованием прелинка ОО достаточно быстро работает если самосборный,

Как может помочь прелинк OOo, если ощутимая часть OOo написана на Java, а *большая* часть библиотек подгружается динамически?

не знаю, но факт остается фактом (прирост в 2 секунды при запуске появился)
фигня, а приятно

[serzh-z]

прирост в 2 секунды при запуске появился

Гм, ну я бы этого и не заметил - ибо с секундомером за компьютером не сижу. =)

[sspphheerraa]

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

[Fireal]

Ещё вот интересно... на сколько эта профильная оптимизация зависит от типа процессора? Ведь заключается она в построении более оптимального кода на основе анализа работы программы... т.е. будем ли мы иметь эту оптимизацию в бинарных дистрибутивах, устанавливаемых на разные процессоры?...
А может уже имеем?

[sspphheerraa]

сомневаюсь

[Gogast]

можно иметь.
если при пересборке использовать статистику, получаемую только в процессе сборки.
тоесть используя общие флаги типа -m32 или -m64 вместо -march= и сразуже, без запуска пересобирая её ещё раз