LINUX.ORG.RU

Удаление -march=native из CFLAGS

 , ,


0

1

Для унификации сборки пакетов и обновлений хочется удалить на физическом компе из CFLAGS параметр -march=native. Насколько безопасно для работоспособности системы будет смешивать пакеты со старыми настройками и новыми? Чую, что не должно поломаться, но всё равно неуютно.:)

В данный момент у меня в make.conf такие настройки:

CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"

В виртуалке (переносимая на разные компы) для тестов такие настройки:

CFLAGS="-O2 -pipe"
CXXFLAGS="${CFLAGS}"

Окружение и список пакетов в них примерно одинаковый, поэтому из виртуалки можно притащить бинарные архивы и распаковать в систему (и потом один раз собирать, а не 2). Или можно не торопясь потихоньку заменять? Тем более, что мне могут поставлять сборки с теми же настройками системы, как в виртуалке. CHOST прописан одинаковый.

★★★★★

Я Gentoo не ставил несколько лет и могу ошибаться, но мне думается, что не указывая march и mtune в CFLAGS не убирает их.

Посмотри какие значения для этих опций проставляет компилятор.

Открывай его документацию.

Т.е. в идеале должна либо жёстко прописана архитектура процессора в march, под который собирать или указан mtune. И не указывая march означает, что указано march=native.

infomeh ★★
()

Поставь хоть вместо этого -msse4.2 или что там минимально поддерживают все твои процы.

anonymous
()

Не взлетит, пиши -march=core2 где core2 минимальная интересующая архитектура. Или пиши максимально интересующую и -mtune=generic. Попробуй заодно минимально интересующую затюнить.

anonymous
()

Недавно ставил Gentoo и там четыре переменных теперь:

COMMON_FLAGS="-march=native -O2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"


Для fortran ещё?

dm_al
()
Ответ на: комментарий от infomeh

В Вики генту пока ничего не нашёл кроме того, что предупреждают не указывать -march=native при использовании distcc.

grem ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Учитывая, что основной комп с core i3 2010 года, то лететь ему всё равно сложно.

@dm_al, ага, но в ebuild это обычно всё равно явным образом указывают, если что-то собирается фортран компилятором.

grem ★★★★★
() автор топика

если я не ошибаюсь, то без указания -march будет -march=generic

eternal_sorrow ★★★★★
()

Не понял что и зачем нужно.
ЕМНИП -march=native лучше не писать; лучше указывать конкретную целевую архитектуру.
Если ты хочешь переносить бинарники с одного компа на другой, то пиши архитектуру, которая совместима с обоими компами. Например -march=x86-64 (естественно, все оптимизации, которые специфичные для конкретной архитектуры задействованы не будут).
Смешивать пакеты из разных архитектур - не вижу проблемы. Архтитектура влияет только на набор CPU инструкций в бинарнике, если часть пакетов, к примеру, будет на -march=x86-64, а часть -march=core2, и ты это запустишь на Core 2, то ничего сломаться не должно; гораздо опаснее смешивать пакеты, скомпиленные разными компиляторами.

Kroz ★★★★★
()

Компилятор без указания -march будет считать что таргет уровня вроде i686 или самых первых x86_64, а именно просто забудь о том, что делает генту гентой. С таким же успехом ты можешь поставить какой-нибудь Debian и не тратить время на пересборку.

Я бы на твоём месте вычислил минимальный уровень из всего парка машин что у тебя есть и его оставить в -march, а в -mtune прописать тот проц, который чаще всего используется.

Например, у меня есть ноутбук с Haswell и основной комп с Ryzen. Чтобы не греть ноутбук компиляцией, да и пользуюсь я им редко, я буду собирать на основном компьютере с такими флагами: -march=haswell -mtune=znver1.

Таким образом компилятор будет генерировать код совместимый с Haswell, но отдавать предпочтение в оптимизациях под Ryzen.

a1batross ★★★★★
()
Ответ на: комментарий от anonymous

Всё-таки есть x86-64, но учитывая, что

‘core2’
Intel Core 2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support.

, то может прокатит и на старых amd процах, если я туда тоже притащу бинарники.

Можно посмотреть, что прописано в make.conf от stage3 и stage4.

grem ★★★★★
() автор топика
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от a1batross

Спасибо. Почитал подробнее про список архитектур и свои основной «минимальный» проц. Так как он относится к Clarkdale, то в march лучше указать westmere, в том числе и на удалённой виртуалке (там, емнип, проц семейства Hasswell) и там всё пересобирать, чтобы побыстрее. Либо выставить там и пересобирать потихоньку сеты.

grem ★★★★★
() автор топика
Ответ на: комментарий от Kroz

ЕМНИП -march=native лучше не писать лучше указывать конкретную

Нет. «Конкретная архитектура» содержит не все флаги порой. Хотя для distcc понятно что нужно прописывать явно.

Архтитектура влияет только на набор CPU инструкций в бинарнике

Нет. Ещё размер кэшей, ну и выставляет соответствующие оптимизации.

anonymous
()
Ответ на: комментарий от infomeh

если конпелять gcc с флагом -march=native, есть риск, что рантайм компилятора (libgcc и прочее) соберётся с новейшими инструкциями, и потом программы, сконпиленные этим конпелятором не будут запускаться на более древних процах

Harald ★★★★★
()
Ответ на: комментарий от infomeh

Да, я так и понял. Просто обычно либо ничего не указывал, либо native, либо конкретную архитектуру. Но цели переноса собранных пакетов не было.

Скорее всего по умолчанию всё-таки native не ставится. Другое дело, что в доках gcc они пишут, что в новых версиях компилятора наборы для -mtune=generic меняются так как разработчики стараются отслеживать текущее положение рынка.

grem ★★★★★
() автор топика

У меня есть скриптик-набросок, но не знаю его полезность для тебя:

diff <(gcc -march=$MARCH1 -Q --help=target) <(gcc -march=$MARCH2 -Q --help=target)

Вместо -march=$MARCH1 можно подставить свои целевые значения, вплоть до того -march=corei7-avx -mtune=athlon -mno-avx и смотреть разницу.

Пример:

diff <(gcc -march=corei7 -Q –help=target) <(gcc -march=native -Q –help=target)

anonymous
()
Ответ на: комментарий от anonymous

Конкретная архитектура» содержит не все флаги порой.

И наоборот - архитектура содержит, но у самого проца Интел инструкции порезал.

boowai ★★★★
()

Вопрос практически по теме.

Что если собирать Gentoo не с "-march=native", а к примеру с "-march=haswell".

Есть ли профит? Все ли флаги подтянет?

neocrust ★★★★★
()
Последнее исправление: neocrust (всего исправлений: 2)
Ответ на: комментарий от neocrust

Я сравнил именно для haswell и чуть отличаются: у native активен mamb, и отключены mbmi, mbmi2, mf16c, mfma, mxsaveopt

grem ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Это на случай если arch=native выставит mtune=generic, такая фигня с gcc постоянно. А то, что выставляет не все возможности это тоже баг может быть. А может быть и нет, avx на сандиках например половинчатый (и работает более эффективно с флагом делящим регистры, актуальный гцц должен быть в курсе).

anonymous
()
Ответ на: комментарий от grem

Native хуже, меня тут на лоре как-то убедили что лучше, но через несколько лет оказалось, что это не так. Лучше всего выставлять конкретную архитектуру, эвристика компилятора всегда хромает. Кроме того бывают следующее исправленное поколение с тем же названием, см. зионы, а гцц может определять как предыдущее.

anonymous
()
Ответ на: комментарий от neocrust

Получается, что не все инструкции автоматом определяет. Вот gcc 8.3 fma для native не включает.

grem ★★★★★
() автор топика

Насколько я знаю, -march=native -O2 это настройка по умолчанию если вы удалите её из make.conf, то она всё равно применится. -pipe это для ускорения компиляции за счёт памяти, но никак не должно влиять на результат.

А если вам нужно унифицировать сборку, то была какая то настройка архитектуры вроде generic_x86_64 (но точно не так).

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

Native хуже, меня тут на лоре как-то убедили что лучше, но через несколько лет оказалось, что это не так.

Глупенький - это твоё „лучше“ или „хуже“ субъективно и нельзя измерить поверенной линейкой.

Мало того то что „лучше“ для 99% ПО в системе может быть „хуже“ для оставшегося 1% ПО и именно на этот 1% ты и обратил внимание. Как тебе такое?

init_6 ★★★★★
()
Ответ на: комментарий от init_6

Купили как-то суровым сибирским лесорубам японскую бензопилу. Собрались в кружок лесорубы, решили ее испытать. Завели ее, подсунули ей деревце. «Вжик» — сказала японская пила. «У, бля...» — сказали лесорубы. Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила. «Ух, бля!» — сказали лесорубы. Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила. «Ух ты, бля!!» — сказали лесорубы. Подсунули ей железный лом. «КРЯК!» — сказала пила. «Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами…

anonymous
()
Ответ на: комментарий от anonymous

Мало того дабы объективно получить это самое твоё „лучше“ надо каждый пакет в системе собирать с несколькими разными CFLAGS и скорее всего USE и после каждой сборки проводить некое тестирование каждого собранного пакета дабы найти идеальную комбинацию. Но сперва для этого ebuild-ы обязаны молча жрать системные CFLAGS а не по тихому заменять неугодные CFLAGS своими сбственными как они сейчас и делают.

init_6 ★★★★★
()
Ответ на: комментарий от a1batross

С таким же успехом ты можешь поставить какой-нибудь Debian и не тратить время на пересборку.

И тратить время на выпиливание systemd из Debian. Впрочем, если автор уже потратил время на впиливание systemd в Gentoo, то... у автора очень много времени.

Gentooshnik ★★★★★
()
Ответ на: комментарий от Gentooshnik

И тратить время на выпиливание systemd

Можно просто не быть поехавшим и не тратить, например.

anonymous
()
Ответ на: комментарий от neocrust

Наткнулся на один момент: хоть у меня проц и westmere, но AES, заявленный для архитектуры, поддерживается только в линейке процов верхнего ценового диапазона. Поэтому указания только -march=westmere мне недостаточно. Нужно добавить -no-aes и, на всякий случай, -no-avx.

grem ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Знаю, что не было. Случаи разные бывают.

grem ★★★★★
() автор топика
Ответ на: комментарий от anonymous

native почему-то ещё отрубает pclmul, хотя я не нашёл информации, что он отсутствует в моём процессоре westmere core i3, в отличие от aes (aes есть в westmere core i5 и мощнее).

По крайней мере после распаковки бинарников собранных с -march=westmere -mno-aes ... система на вид не поломана. По крайней мере иксы загрузились теперь и пакет ругавшийся на отсутствие поддержки aes собрался.

grem ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.