fomit-frame-pointer на Athlon II X2

В продолжение моей соседней темы :)
Если следовать рекоменациям на http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD#Athlon_X2_7x50.2C_Phenom_X3.2FX4.2C_Phenom_II.2C_Athlon_II_X2.2FX3.2FX4 вижу под свой Athlon II X2:

CFLAGS="-march=amdfam10 -O2 -pipe"

В то же время для более младших моделей в дополнение к -pipe ипользуется fomit-frame-pointer
С другой стороны в интернете читаем описание данного флага (fomit-frame-pointer) и видим, что вроде как он дает некий выигрыш...
Ну и третий момент - по факту у меня -march=native, но вроде как говорят, что -pipe и -fomit-frame-pointer должны идти дополнительно, поэтому сейчас имеем:

CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"

Но вопрос - почему на вышеприведенной страничке -fomit-frame-pointer убран из рекомендаций для современных процессоров?

Hmury написал(а): Но вопрос -

Hmury написал(а):
Но вопрос - почему на вышеприведенной страничке -fomit-frame-pointer убран из рекомендаций для современных процессоров?

ИМХО, косяк )))

ИМХО, -fomit-frame-pointer

ИМХО, -fomit-frame-pointer для amd64 включен по умолчанию.
Для x86 да, надо добавлять.

:)

Это что-то с указателями связано? Регистрозависимость помоему...
Наличие -fomit-frame-pointer существенно затруднит отладку приложения, но и немного поднимет быстродействие его.
Решайте что вам надо.

Agressor написал(а): Наличие

Agressor написал(а):
Наличие -fomit-frame-pointer существенно затруднит отладку приложения, но и немного поднимет быстродействие его.

для отладки его по-любому по-другому собирать надо и совсем с другими флагами ;)

Agressor написал(а):Это

Agressor написал(а):
Наличие -fomit-frame-pointer существенно затруднит отладку приложения, но и немного поднимет быстродействие его.
Решайте что вам надо.

Да я в курсе, для чего он.
Просто подумалось - а вдруг не зря убрали?.. Может он как раз с определенными процессорами не очень ладит )
В любом случае - уже запустил пересборку system, посмотрю, чего получится

Hmury написал(а): запустил

Hmury написал(а):
запустил пересборку system, посмотрю, чего получится

А в glibc не забыли флаг glibc-omitfp?

Мы тоже не всего читали Шнитке!.. © В. Вишневский

valet2valet написал(а): ИМХО,

valet2valet написал(а):
ИМХО, -fomit-frame-pointer для amd64 включен по умолчанию.
Для x86 да, надо добавлять.

Так все-таки "ИМХО"? Или есть подтверждения?

Hmury написал(а): есть

Hmury написал(а):
есть подтверждения?

А что для вас есть подтверждение? К примеру, цитата из мана гцц: "...‘-O’ also turns on ‘-fomit-frame-pointer’ on machines where doing so does not interfere with debugging ...skipped... Enabled at levels ‘-O’, ‘-O2’, ‘-O3’, ‘-Os’..." - оно?

Мы тоже не всего читали Шнитке!.. © В. Вишневский

Spoiler написал(а): К

Spoiler написал(а):
К примеру, цитата из мана гцц: "...‘-O’ also turns on ‘-fomit-frame-pointer’ on machines where doing so does not interfere with debugging ...skipped... Enabled at levels ‘-O’, ‘-O2’, ‘-O3’, ‘-Os’..." - оно?

Ну, в общем, почти )
Вот откопал:
http://www.gentoo.ru/node/12389
Немножко смущает фраза:

включен на архитектурах, на которых он не мешает процессу отладки (например amd64)

Думаю, хуже не будет, если для перестраховки все-таки прописать. Мало ли чего он там автоматом надумет - мешает процессу отладки или не мешает, несмотря на amd64 )

Spoiler написал(а):
А в glibc не забыли флаг glibc-omitfp?

Спасибо, не знал. Вот только, опять же, с учетом вышесказанного, почему, интересно, он тогда на amd64 по умолчанию не включен?....

Hmury написал(а): ... Spoiler

Hmury написал(а):
...

Spoiler написал(а):
А в glibc не забыли флаг glibc-omitfp?

Спасибо, не знал. Вот только, опять же, с учетом вышесказанного, почему, интересно, он тогда на amd64 по умолчанию не включен?....

Из описания флага:

glibc-omitfp: Configure glibc with --enable-omitfp which lets the build system determine when it is safe to use -fomit-frame-pointer

Интересный флаг - определяет, безопасно ли использовать -fomit-frame-pointer :) - значит риск есть!
т.е. вы включили -fomit-frame-pointer, думаете, что процесс пошел, а ваша система решила - а фиг вам - и либЦ его использовать не будет! А другие-то компоненты его используют!

Кто-нибудь из программистов-гуру может прокомментировать эту ситуацию?

кСТАТИ, У МЕНЯ

model name : AMD Athlon(tm) II P320 Dual-Core Processor

и

CFLAGS="-march=amdfam10 -O2 -pipe"

SysA написал(а): Интересный

SysA написал(а):
Интересный флаг - определяет, безопасно ли использовать -fomit-frame-pointer :) - значит риск есть!
т.е. вы включили -fomit-frame-pointer, думаете, что процесс пошел, а ваша система решила - а фиг вам - и либЦ его использовать не будет! А другие-то компоненты его используют!

Установка Gentoo Linux написал(а):
Каковы последствия применения -fomit-frame-pointer в опциях компилятора (make.conf: CFLAGS/CXXFLAGS)?

Опция -fomit-frame-pointer указывает компилятору, что можно не создавать специальный пролог функции, там где это не требуется.

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

Отрицательным - на некоторых архитектурах отсутствие пролога приведёт к тому, что отладчик не сможет развернуть стек вызовов, что сделает отладку программы в большинстве случаев невозможной или бесполезной. Так же для таких програм не будут иметь смысл отчёты об ошибках, содержащие дамп стека вызовов, созданного во время "падения" программы.

Компилятор GCC автоматически управляет опцией -fomit-frame-pointer при включенной оптимизации, любого уровня (-O). Это означает, что при сборке программы для архитектуры, на которой невозможно развернуть стек без наличия указателя на кадр стека, опция -fomit-frame-pointer не будет включена.

К архитектурам, на которых наличие опции -fomit-frame-pointer не затруднит отладку программы, относятся, например, x86_64, SPARC и т.д. К архитектурам, на которых опции -fomit-frame-pointer сделает отладку невозможной - x86. Из чего следует, что одновременное использование опции -O и -fomit-frame-pointer имеет смысл лишь при сборке системы только для x86, на x86_64 эта опция будет включена автоматически.

Резюме: если вы собираете систему для x86, вам не требуется отлаживать программы и вы не желаете слать разработчикам детальные отчёты об ошибках, но хотите немного выиграть в скорости - можете спокойно добавить -fomit-frame-pointer в свой CFLAGS/CXXFLAGS. Если же вы собираете для другой архитектуры, такой как x86_64, с включенной оптимизации, то вообще можете не обращать внимание на -fomit-frame-pointer.

:)

Theli, спасибо за развернутый ответ!
Все таки есть время этим заниматься!
Эх... Вернуться бы лет 10 назад (не во времени...)

Agressor написал(а): Theli,

Agressor написал(а):
Theli, спасибо за развернутый ответ!

Присоединяюсь к благодарности )
В конце концов решил его убрать, все-таки сижу на тестовой ветке - может, действительно, придется со временем о каких-нибудь багах рапортовать, пусть лучше будет )

SysA написал(а):
кСТАТИ, У МЕНЯ

model name : AMD Athlon(tm) II P320 Dual-Core Processor

и

CFLAGS="-march=amdfam10 -O2 -pipe"

А вот, кстати, я поэтому всю эту историю и затеял...
Если посмотреть, что включает march=native (например, вот как здесь предлагают - http://deviousway.ya.ru/replies.xml?item_no=49 ), то видно, что включает он явно больше всяческих опций, чем просто -march=amdfam10 .... Ведь даже само название статьи на http://en.gentoo-wiki.com/wiki/Safe_Cflags/ - "Safe Flags" говорит о том, что это только 100% безопасные и общие для некоторых семейств процессоров флаги.
Включая же -march=native , мы:
1) оптимизируем уже именно под свой, конкретный живой процессор;
2) с выходом обновлений и изменений gcc - возможно, разработчики что-то там будут менять, добавлять-убирать опции, при march=native это произойдет автоматически, при ручных опциях - останется как было, пока не обновятся мануалы и HOWTO....

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".