В Arch Linux собираются включить LTO по умолчанию

Вредная фича

Чем именно ?

Требуется пояснительная бригада: у фичи есть какие-нибудь минусы, окромя плюсов?

Вижу там в коммеетах пишут, что gdb сжирает память и сегфолтится. Если правда, то невозможность отладки — существенный минус.

Линковка адово тормозит и жрет память. Мы недавно отключили эту срань у себя в проекте, так как после перехода на свежий clang оно перестало умещаться в 64Gb RAM. Прирост по сути там мизерный, около 1%, смысла нет вообще.

Вижу там в коммеетах пишут, что gdb сжирает память и сегфолтится. Если правда, то невозможность отладки — существенный минус.

Всё так

Когда-то читал, что ЛТО может добавлять багов. Также, увеличивается время компиляции и потребление памяти.

Время компиляции, говорят есть пакеты, которые так не соберутся. Полагаю, мейнтенеры арча абгрейдили компы) Ну, посмотрим, что будет

А для Ъ пояснения будут. Что за ЛТО такое? Оптимизация при линковке?

Ну это проблема сборщиков, когда-то сборка андроида с LTO меня подтолкнула к увеличению до 32 гб на домашнем и то почти все сжирала сборка ядра.

А плюсы какие?

Возможно быстрее будет работать.

Снижение размера бинарников в первую очнредь. При статической линковке - значительно, для микроконтроллеров, по-сути - киллерфича. Для десктопов, хз.

Арчеводы – знатные любители прострелить себе колено.

мизерный, около 1%

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

Следом за Сусей, Федорой и Убунтой, в Арче хотят собирать пакеты с ЛТО.

\vbros

А теперь посмотрите, где эти ваши «суси», «федоры» и «убунты» теперь. Глюк на глюке!

\vbros off

А по теме – не нужно. Серьёзно, прирост мизерный (уменьшение размера бинарного файла), зато проблем в первую очередь для разработчиков – выше крыши. Вот на Arch ARM это ещё оправданно, там никто не компилирует на «малинках».

Мы недавно отключили эту срань у себя в проекте, так как после перехода на свежий clang оно перестало умещаться в 64Gb RAM.

А что вы там такое пишете, что с LTO оно аж в 64 гигабайта не помещается?

Для LTO, если я правильно понимаю, надо передавать все исходники на вход компилятору разом, чтобы он это все собрал за одну команду. Т.е. теряем возможность многопоточной сборки, пересборка проекта всегда как сборка с нуля (ccache становится бесполезен), дикое потребление памяти на больших проектах.

Плюсы - на avr LTO может давать более компактный код, небольшой прирост производительности. Больше не знаю.

Думаю достаточно плюсов и пары увесистых header-only библиотек.

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

Посмотрел доки, и впрямь он теперь выписывает в .o байткод, и достаточно только везде -flto добавить.

И это ещё:

https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-LTO-Proposed

«Another notable change being considered at the same time for Arch is using the x86-64-v2 microarchitecture level. This would make Arch Linux faster by allowing to assume some CPU instruction set extensions by default while still running on most x86-64 Intel/AMD hardware from over one decade. This is the same as RHEL9 set to require x86-64-v2 instead of vanilla x86-64.»

Это значит Pentium D и Core 2 Duo в пролёте?

Да. И непонятно для линейки AMD.

Блин. И что мне теперь поставить на свои два музейных экспоната? Теперь даже не понтануться на ЛОРе, что современный Arch пашет на Pentium D.

Да не спеши, это пока только обсуждения. Думаю, год-другой впереди есть. А там либо машина с Pentium D совсем загнётся, либо будет очередной lowarch. (Пишу это с Core 2 Duo)

Успокоил. :)

Мне иногда кажется, что я сам раньше загнусь, чем этот аццкий сотона.

Я решаюсь ядра обновить. Смотрю, переход 5.10 -> 5.11 добавил почти 19 МБ. Столько новых драйверов?

До v2 вряд ли дропнут, требование SSE4.2 сейчас рановато

А теперь-то и в lts ядре CONFIG_ZSWAP_DEFAULT_ON=y

говорят есть пакеты, которые так не соберутся.

И довольно много. У меня на системе таких стоит 45 штук.

Что же касается плачей про долгую компиляцию – дык ся/плюся вообще долго компилируется. Юзайте говнопитон.

Линкеру, кстати, можно передать количество ядер, аналогично make -j16: -lto=16 (в make.conf в CFLAGS, CXXFLAGS, LDFLAGS).

после перехода на свежий clang

Хмм. А на свежий gcc? Т.е. это точно проблема LTO как такового? Не clang специфичная?

А вот это реально вкуснотища была бы )

Особенно для всякого рода хлама, вроде моего AMD A12 9700P.

#!/usr/bin/awk -f

BEGIN {
    while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
    if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 1
    if (level == 1 && /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
    if (level == 2 && /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/) level = 3
    if (level == 3 && /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
    if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
    exit 1
}

Стащиль отсюда.

Очень даже всё понятно )

Все так переживают из-за времени компиляции, как будто им самим это делать,а не мейнтейнерам

Хмм. А на свежий gcc? Т.е. это точно проблема LTO как такового? Не clang специфичная?

Да, lto специфичная, оно и без обновления хорошо кушало памяти.