Gentoo и оптимизация

Оптимизации graphite уже сто лет как безопасны. С тех пор, как вышел gcc-9.1.0, выставил в системе lto глобально, единственное исключение сделал для glibc. Python собран с pgo. Железо — X230 на i7. Всё работает, пожаловаться не могу.

Спасибо, звучит обнадёживающе.

Эксперимента ради поставил firefox 67 на сборку с pgo и lto. Кажется, только-только он «закончил» собираться... Повиснув без всякого сообщения. Вижу, что portage его(firefox) вроде запустил, но процесс словно заморожен, потребление памяти стабильно и процессор - 0%. Висит так уже минут 5.

Так и должно быть или это ошибка? Боюсь прерывать, собирался 87 минут.

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

Кстати, используй ccache, чтобы ускорить пересборку: мало ли, какой капризный пакет тебе попадётся — придётся собирать заново с «безопасными» опциями.

PGO ты не сможешь поставить глобально на систему, ebuild должен явным образом поддерживать его, ну и да, компиляция будет в 2 раза дольше, потому что приложение сперва скомпилируется, затем будет запущено чтобы сгенерировать профиль а затем уже повторно скомпилируется с учётом профиля.

LTO у меня давно стоит на всю систему, но некоторые пакеты с ним не собираются и приходится попакетно отключать. Этим оно очень хорошо - оно не вызывает крашей и ошибок в рантайме, проблемные пакеты просто не собираются.

Graphite я пробовал включать во времена GCC-5.0 приблизительно. И оно было очень багованное. Многие пакеты приходили в совершенно неюзабельное состояние из за него, например вим кромсал в лютейший треш любой файл, который я пытался в нём редактировать. Так что я его до сих пор побаиваюсь и не хочу включать.

Так же не рискую включать -O3.

Боюсь прерывать, собирался 87 минут

Неплохо для ноута, что за железо?

Спасибо за наводку.

Пересобрал уже gcc, glibc и binutils, но сейчас понял, что забыл включить в последнем default-gold, потому включен просто gold. Его нужно тоже врубать, как я понимаю? Странно будет, если так.

Говорят, что gold с LTO лучше работает, чем bfd. Иногда это действительно имеет значение, но такое случается редко.

Пересобирать binutils не надо, достаточно

binutils-config --linker ld.gold

i7 2670qm + 12гб RAM. Не сказал бы, что выдающиеся параметры, но на работу вполне достаточно.

Всё равно при сборке чуть-чуть уходит в своп, но это не так заметно, если включить zswap и BFQ

выставил в системе lto глобально

Есть ман по настройке?

gcc-9.1.0

А что с 8.3.0?

CFLAGS="${CFLAGS} -flto=4"
CXXFLAGS="${CXXFLAGS} -flto=4"
LDFLAGS="${LDFLAGS} -flto=4"

Вот тебе и весь ман. Вместо 4 подставь количество ядер в системе (или потоков, если ты тоже живёшь опасно и до сих пор не отключил SMT).
Насчёт 8.3.0 ничего не скажу, не пробовал. Знаю точно, что там флаг fno-plt сломан, но включать его глобально — передроч (и для xorg-server до сих пор нужно отключать).

То есть меняем make.conf и emerge -e?

или потоков, если ты тоже живёшь опасно и до сих пор не отключил SMT

Мне «повезло». У меня нет HT.

Насколько сильно оно бьёт по времени сборки? Как минимум в Rust lto может и в 2-3 раза медленнее быть.

То есть меняем make.conf и emerge -e?

Сперва, наверное, всё-таки пересобрать тулчейн, а потом уже emerge -e.

Насколько сильно оно бьёт по времени сборки?

Я на ночь оставил и спать лёг. С утра оно ещё шуршало, как с работы вернулся — уже пересобралось. Точное время не замерял.

пересобрать тулчейн

Сам gcc?

Не только: gcc, binutils и что у тебя там в роли стандартной библиотеки (glibc/uclibc/musl/whatever).

gcc с pgo собирался где-то в 2 раза дольше. Судя по отзывам, с lto у билдов можно считать в 2.5 раза.

Впрочем, насколько я понял, это очень сильно зависит от конкретной конфигурации.

Буду тестировать с системой целиком, по результатам отпишусь. По крайней мере @system точно рискну пересобрать, благо это будет не настолько долго.

-O3 и даже -Ofast можно всюду ставить - проблем и замедлений не встречал (разве что sqlite при сборке проверяет макрос __FAST_MATH__ и обижается). Наоборот, некоторый софт значительно ускоряется. «Предупреждения» эти устарели на 5-10лет.

Вот -flto или -fwhole-program не стоит ставить глобально - я встречал замедления работы софта от него.

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

glibc в ебилде стрипает флаги (flag-o-matic.eclass), оставляя только -O2 -march=native -Wall -pipe и -Wl,--sort-common -Wl,--hash-style=gnu -Wl,--as-needed и т.п.

Наоборот, некоторый софт значительно ускоряется.

Хм, значит стоит попробовать, попытка не пытка.

-march=native ещё не забудь

Заметил, кстати, что часто рекомендуют ставить именно native вместо конкретного семейства процессора. КМК так, конечно, система получается универсальнее, но оптимизация будет страдать. Хотя мб я ошибаюсь и оно само подхватывает тип процессора когда можно. Но судя по логам при native это не так.

Сейчас использую именно -marc=*processorfamily*, всё работает отлично.

Нет, всё наоборот: native включает все опции под твой процессор. А «конкретное семейство» - нет.

часть больших проектов собирается криво (прямо при сборке просят стандартный набор флагов - О2), и, конечно, никто не отменял мурзилок по gcc (версия) и твоим флагам проца.

Серьёзные пацаны упарываются по сборке каждого большого пакета, а на целую систему пилят некий надор стандартов (в силу своей компетенции).

Особо упоротые интересуются и набором программ, понимая, что LFS не их выбор, а свободы хочется - выбирают CRUX (много рутины сделано «за тебя»), пилят свой набор софта, костылей, ядер, условий компиляций (ярче, чем у Коровы. Gentoo в этом плане менее гибкая), и нагло плюют на любителей медитации «ради медитации».

Но судя по логам при native это не так.

Я плакать... Ты, видимо, рано взялся за вопрос «оптимизации», если не читал, что делают данные флаги.

Куда катиццо мир? (взгрустнул)

Оптимизации graphite уже сто лет как безопасны. С тех пор, как вышел gcc-9.1.0, выставил в системе lto глобально, единственное исключение сделал для glibc. Python собран с pgo. Железо — X230 на i7. Всё работает, пожаловаться не могу.

Вот только как работает?

Но никто не мешает вручную настроить CPU_FLAGS_X86.

Удивительно, но некоторые билды берут их вообще из USE, так что на всякий прописал и туда.

march=native еще кеши под проц выставляет. sse нужные включает, ненужные выключает и т.п.

Ну спасибо ))) Я прямо и не знал, честно ))) Читать неплохо. В документации много написано.

Или просто ты начал, или знатный тролль )))

CPU_FLAGS_X86 это USE=«cpu_flags_x86_mmx cpu_flags_x86_sse» и т.д.))

Сейчас использую именно -marc=*processorfamily*, всё работает отлично.

Что это и зачем оно? Как это оптимизирует? В чем отличия от флага «native»?

Что будет, если поставить один флаг и тыцнуть флаги сборки, а потом второй? Какая будет разница?

Да, сравни скорость работы с lto и без. LTO-то как раз нифига не безопасная оптимизация, хотя на вики про это ничего нет.

да эти флаги используются в 2-3 пакетах (чаще связано с работой кодировки видео, если не ошибаюсь, давно gentoo не видел)

без lto libxul.so 100Mb

с lto 80Mb

https://github.com/InBetweenNames/gentooLTO
Пробовал, не впечатлило. Некоторые нужные пакеты не собирались. Откатился.

Ну так ты выставь flto и попробуй собрать. У меня не вышло, хотя flag-o-matic я не отключал.

Субъективно ухудшений не вижу. Я убедился, что система с такими настройками работает не хуже, чем раньше. Любопытство удовлетворено, и хватит с меня.

Да, сравни скорость работы с lto и без.

Расскажешь, как измерить — сравню.

LTO-то как раз нифига не безопасная оптимизация

В 9.1.0 хорошо зделоли, грю маладца.

тесты, тесты ))) Я вот считаю, что надо писать осмысленно флаги. Или не писать. В случае с https://wiki.gentoo.org/wiki/File:Larry-nefarius-v2.svg с данной личностью и её зоопарком на десктопе в общих настройках не зря рекомендуют всё усреднённое...

Ну и, конечно, я рад, что тебе повезло и ты не видишь разницы (а вот компиляция явно дольше :), так что реже обновляйся)

Я вот считаю, что надо писать осмысленно.

Я тоже так считаю. Поэтому и говорю: у меня не было задачи Заоптемезиравать™ всё, я другое проверял — взлетит оно или не взлетит. Взлетело.

тесты, тесты )))

Дядь, ну ты хоть расскажи тогда, какие тесты, сколько гонять, на что смотреть.

действительно ли -O3 толще -O2

Да, так как -O3 включает более агрессивный инлайнинг, раскрутку циклов и подобные штуки. Разница зависит от собираемого кода, разумеется. (дисклеймер: я -O3 юзаю только для сборки своего софта, на всю систему его ставить считаю несусветной глупостью, стоит использовать только для пакетов критичных к скорости работы и с обязательной проверкой полученного ускорения)

и какой быстрее?

Зависит от собираемого кода, в каких-то случаях может вообще -Os быть быстрее всех

Не ломает ли систему lto?

Где-то видел черные списки, хотя мне хотелось бы увидеть белые, т.е. списки пакетов где это что-то дает кроме замедления сборки и потенциальных багов

Их два - первый «по времени», второй - «спасибо Татьяне за синий скрин» креш-тест. После флагов многие приложения работают нестабильно. На десктопе ты просто перезапускаешь, другие ситуации мы не рассматриваем.

Всё, манул пришел, корм распугал. Пойду в другую тему...

Выполнил вот это:

gcc -march=native -E -v - </dev/null 2>&1 | grep cc1

И получил, что native выдаёт вот такое:

l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=sandybridge

Но он врёт, у меня не такой кеш. Более того, даже по инструкциям он немного привирает, если смотреть на выхлоп

grep -m1 ^flag /proc/cpuinfo | tr ' ' '\n' | sort

Или я чего-то не понял, или определяет native далеко не идеально. ЧЯДНТ?

Ничего не понял.
Во-первых, по времени чего? Компиляции? Запуска? Исполнения? Если компиляции, то и так понятно, что с LTO будет дольше. Если исполнения, то как именно замерять (если мы не говорим о цифромолках типа архиваторов или кодеков)?
Во-вторых, я верно понимаю, что креш-тест — это проверка на то, что оно запускается и работает? В таком случае, этот тест система успешно выдерживает уже примерно месяц. Или речь о каком-то конкретном испытании?

вот первое - это правильно, это «по нашему». Как и писал - «ВСЁ», что касается времени. Второе - это не только запуск, это нестабильная работа. Баги вылезают резко, бешенно и неожиданно.

«ВСЁ», что касается времени
Баги вылезают резко, бешенно и неожиданно.

Ну так я тебя спрашиваю: как протестировать, где методика-то? Как именно ты предлагаешь тестировать «ВСЁ» и что конкретно составляет это ВСЁ?

Можно абстрактно рассуждать о тестах, многократных измерениях, соблюдении идентичных условий, репрезентативной выборке и трёх сигмах, а также о нужности всего этого в настоящем исследовании. Однако:

• я не утверждал, что описанные выше опции дают безусловный выигрыш;
• я не заявлял, что получил какой-либо выигрыш;
• моей целью было проверить работоспособность своей системы, собранной с такими настройками;
• эта цель выполнена: я проверил, система работает.

Скорость работы измеряется не в мегабайтах.

Собери с lto и без него какую-нибудь программу, что обсчитывает что-то со 100% загрузкой проца и замерь знимаемое ей время.

если мы не говорим о цифромолках

А что-то кроме них вообще кого-то интересует? Тот же браузер - цифромолка, запускай mozilla kraken.

Зависит от собираемого кода, в каких-то случаях может вообще -Os быть быстрее всех

Тут я, кончено немного перегнул, с большой долей вероятности -O3 будет самым быстрым, если только проигрыш от кэш-эффектов не перевесит выигрыш. Но прирост может быть очень незначительным, а кэш-эффекты какие-то все равно будут, плюс увеличение размеров бинарников и сопуствующее (небольшое, но все же) увеличение жора памяти, плюс дольше сборка, плюс возможны баги с новыми версиями компилятора

Тот же браузер - цифромолка

Не весь. JS-движок - да, отчасти цифромолка, но когда в дело включается JIT (а всякие кракены тестят его как раз, там цифромольные задачи на JS), то больше зависит от качества выхлопа JIT-компилятора, чем от того, насколько заоптимизирован сам компилятор при его сборке.

а сколько у тебя кеш2? 12Mb?

Ответ всё ещё на уровне «ну протестируй там как-нибудь, придумай, — а мы тебе потом расскажем, почему твой тест никуда не годится».

Что делать-то будем? JSON парсить, видео кодировать, исходники ядра паковать, что? Чем конкретно, какой программой? С какими опциями? В каких условиях? Сколько раз? Чем будем время замерять: простого time хватит, или нужно что-то похитрее?