#xiaomi

https://www.ixbt.com/news/2022/07/01/oled-4k-dolby-vision-xiaomi.html

Кто-то ждет выставок от Apple, а я вот теперь жду Xiaomi. Через 2 дня они представят свои "прошки", и, если доставка будет работать, это будет мой следующий ноутбук.

Знаете, я из этого бложика вынес всю политику, но вот тут не удержусь.

Я родом из славного города Арзамас-16, родины советской атомной бомбы. Родители полжизни проработали на военку, деды вообще были известными в своих областях учеными.

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

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

Прошло 30 лет, у меня и у моих родителей большинство техники - из Китая. Xiaomi, Honor, Huawei, куча ноунейма, продаваемого известными брендами, etc.

Высокие технологии, скоростные поезда - это все не про Рогозина, который хвастается цацками 30-летней давности, а Китай.

Сетевое оборудование, теперь и легковые машины - это все теперь Китай.

Забавно, что все это произошло на глазах одного поколения, и горько от того, что старшему поколению все божья роса - они почему-то никак не могут увязать эти свои разговоры 30-летней давности и текущее состояние, но зато "Россия встает с колен".

https://github.com/Novum/vkQuake/issues/508
https://github.com/Novum/vkQuake/commit/1af0e6ae56c09a14589a9990e9574bd195a3cd06

Автор #vkquake, судя по всему, родил нечто, что более-менее решает проблему переполнения стека.

Собственно, проблема прошлого "решения" была в том, что он брал за размер стека треда размер стека main, который сильно больше.

Почему я считаю, что это, все еще, не совсем годное решение?

Потому что:

* Он делит стек на 2 части - static, размером 128к, и dynamic- все остальное. static - это под заранее рассчитанные вызовы рекурсивных функций, dynamic - под выделение данных неизвестного заранее размера.

* Отсюда сразу вытекает баг - если, вдруг, static часть станет > 128к, то на маленьких картах все продолжит работать, а на больших - будет падать.

Ладно, на это пофиг, по крайней мере, не хуже, чем было до этого.

Самая мякотка вот в чем -

  max_thread_stack_alloc_size = (size_t)CLAMP (0ll, (int64_t)stacksize - THREAD_STACK_RESERVATION, MAX_STACK_ALLOC_SIZE);

Короче, у него размер static части 128k, и размер стека под musl - 128k, то есть, размер dynamic части - 0.

Поэтому вот тут - https://github.com/Novum/vkQuake/blob/master/Quake/mem.h#L48 мы всегда попадаем в "slow" path.

7 лет в idSoftware, my ass.

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

UPD: воспользовался своим "правом первой ночи", сделал malloc() всегда - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/quake/1/vk/ix.sh#L36.

Будни #bootstrap

Собирал себе какую-то программулю, обнаружил в выхлопе cmake, что она не может найти libavif, хотя зависимость от нее я поставил.

Уже наученный горьким опытом, я обнаружил, что в libavif нет ${out}/lib/cmake.

(кстати, отвлекусь на другую тему - это, конечно, жесть, что разработчики cmake решили сделать свою систему package discovery. Весь unix пользуется pkg-config(*.pc файлы). И жесть в квадрате - нельзя просто попросить найти libXXX, ее надо попросить или через pkg-config, или через встроенный механизм cmake)

https://github.com/AOMediaCodec/libavif/blob/main/CMakeLists.txt#L528

if(BUILD_SHARED_LIBS OR VCPKG_TARGET_TRIPLET)

Охренеть, да? Ну любому же программисту очевидно, что discovery нам нужен только для .so, а для статических библиотек не нужен.

cmake - это херовый интерпретатор языка, похожего на Basic + M4, и зачем-то люди пишут на нем свои сборочные скрипты. Слишком много дурацкой вариативности.

Я выставил в ON вторую переменную, которая нигде больше не используется - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/avif/ix.sh#L11

А еще я теперь на такие штуки пишу тест, который выполняется прямо в момент сборки - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/avif/ix.sh#L15

После этого шаманства все собралось, как надо.

TIL об https://github.com/posva/catimg

IMHO самая удобная из известных мне программ для просмотра картинок прямо в терминале, не отходя от кассы:

* Не использует богомерзкие sixel

* Использует символы unicode для увеличения разрешения

* Не пытается открыть графическое окно поверх терминала

* Очень компактная. Не пытается реализовать очередную никому не нужную фабрику по загрузке картинок, использует convert из ImageMagick.

* Написана не на перле и баше, а вовсе даже на С.

https://gitlab.gnome.org/GNOME/gtk/-/issues/5004
https://www.phoronix.com/scan.php?page=news_item&px=GTK5-Might-Drop-X11

#gnome

Коллеги рассматривают возможность убрать поддержку X11 из GTK5.

Тикет находится в замороженном состоянии, потому что ссылка на него попала в новости. Поэтому прямо сейчас там ЖЫРА нет, но обязательно будет.

Как ни странно, я тут поддерживаю коллег. X11 никто не пилит, бекенд для него в gtk-gdk уже давно не первого класса.

Поэтому довольно логично в новом коде не поддерживать "загнивающую" технологию. Желающим гонять X11 завсегда остаются более старые версии софта, а если хотите продолжать быть луддитами - ну так, пожалуйста, позиция мейнтейнера Xorg, вроде, открыта.

Гномовцы, конечно, в своем стиле:

"If the "handful of environments" cover 90% of the user base, I would not talk about "massive narrowing" as much as a reallocation of the efforts of a volunteer-driven project."

А ничо, что главный разработчик GTK, Matthias Clasen, он делает примерно 40% коммитов в GTK, работает full time на Red Hat?

Будни #bootstrap

Я тут решил, что, раз уж у меня есть q1, q2, то к ним нужно добавить и q3.

Мой выбор пал на https://github.com/ec-/Quake3e - написано, что оно умеет в vulkan, а я, как вы знаете, строю vulkan first систему. Даже в качестве реализации OpenGL у меня используется Zink.

Сначала мне это показалось нерешаемой задачей - в коде было слишком много завязок на X11, патч получился бы очень большой, а я не люблю большие патчи. Большие патчи потом сложнее накладывать, то есть, мне, как maintainer, придется тратить сильно больше труда.

Но, приглядевшись, я понял, что весь нужный мне патч - это две регулярки на sed - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/quake/3/e/ix.sh#L20

Одной я убираю "плохие" заголовки, второй - регистрацию каких-то функций из glx, которые далее не используются.

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

Вот, хороший пример такого патча.

Если делать его по классике, там несколько сотен строк содержательного кода.

В третий раз в жизни "хачил" компьютерную игру. Причем как-то очень странно - они, зачем-то, оставили в коде проверку на "чистоту" используемых pak файлов, а в инете можно скачать рипнутые. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/quake/3/e/ix.sh#L25 Убрал ее тоже.

Бонус!

Пока разбирался, чо там и как в quak-остроении, обнаружил, что Lord Havoc(автор DarkPlaces), ВНЕЗАПНО, стал Lady Havoc, и вообще, так всегда и было. https://icculus.org/twilight/darkplaces/

#vkquake

Извините, в последний раз, больше не буду, но разъебывать - так разъебывать.

Мне стало интересно, чем занимается программа от коллеги из idSoftware.

Я снял perf record, посмотрел perf report, и увидел:

* В аллокаторе, даже после моих патчей, она проводит 0.2% времени.

* Зато 25% времени программа проводит в https://github.com/Novum/vkQuake/blob/master/Quake/tasks.c#L129 Знающие люди сразу тут увидят наивную попытку реализовать spin wait semaphore, функция называется очень даже правильно.

Ладно, не будем придираться, обычный такой spin wait. 3000 итераций sem_trylock - ну такое, кажется, многовато.

В любом случае, опытные собаководы заявляют, что spin lock в user space - ну такое. https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 Я на эту заметку уже кидал ссылку, но, все равно, почитайте, красивое.

Если позаменять вызов этой функции на SDL_SemWait, то программа начинает жрать существенно меньше CPU, процентов на 10 - 15, ухудшений в latency я не заметил.

Поэтому, конечно, свою версию я запатчил. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/quake/1/vk/ix.sh#L14

UPD: по просьбам трудящихся - https://github.com/Novum/vkQuake/pull/514

#vkquake

Сперва коллега, конечно, поступил как на КДПВ - сообщил, что под винду так работать не будет(доля правды в его словах вполне есть), и закрыл тикет. https://github.com/Novum/vkQuake/pull/514

Но потом, видимо, выдохнул, и решил, что перф на дороге не валяется. Сошлись мы на том, что он сократил количество попыток trywait в 30(!!) раз. https://github.com/Novum/vkQuake/commit/5cf860d1be6d12a3f269ea8355818ab17e586390

(Я, на самом деле, не понимаю, зачем ему там динамическая выполнялка графа - все, что он разложил в этот граф, занимает 10% потребляемого CPU. Может, ему просто нравится писать динамические graph execution engine, как вот мне, или Ленарту, имеет право)

Ладно, и так сойдет.

https://www.phoronix.com/scan.php?page=news_item&px=KernelMemorySanitizer-v4 #asan

Уже писал, и напишу еще раз.

Самый большой, практически, тектонический, сдвиг в разработке софта за последние 20 лет - это внедрение address sanitizer от Google, Кости Серебряного, и его команды.

До его внедрения в pipeline тестирования мне было страшно катать прод, после - уже совсем нет.

Экспертное мнение - Rust даже рядом не стоит по масштабу улучшений. Ну, то есть, если бы не было санитайзеров, Rust был бы очень крутой штукой, а так - ну, на 20% еще меньше ошибок. Это не на порядок даже.

Собственно, отрадно видеть, как Google, вопреки вольнице кернел хакеров(почему вопреки? А почему санитайзеры гоняет google, и почему они не встроены в CI?), постепенно превращает ядро Linux из месива, в котором ты боишься обновить минорную версию ядра и/или компилятора, в нечто, что хотя бы не упадет на старте.

Будни #bootstrap

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

Недавеча увидел в этом списке exim. Это самый популярный MTA, и я подумал, что "нужно"!

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

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

Вот этот сборочный файл из arch - https://github.com/archlinux/svntogit-community/blob/packages/exim/trunk/exim.Makefile

Я попрошу отметить, что это файл из репозитория Arch.

В комментариях дали ссылку на gentoo - https://gitweb.gentoo.org/repo/gentoo.git/tree/mail-mta/exim/exim-4.96-r1.ebuild#n170

КМК, это какое-то лютое пренебрежение к пользователю.

Или я чего-то недопонял, и есть путь проще?

https://habr.com/ru/amp/post/675036/

тут вот пишут, что Blizzard потребовала удалить с гитхаба альтернативный движок для третьего Warcraft.

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

* На lobsters/HN про это ничего нет. Я прошерстил пару раз, не нашел ничего.

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

* Сам движок всратый, ничего не умеет.

* Коллега заявил об этом прямо день в день юбилея игры, зачем такой PR Blizzard'у?

Фейк? Не фейк?

https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Creator-Microsoft

Вчера стало известно, что Леннарт ушел из RH. Ну ушел и ушел, я не стал про это писать.

Но, знаете ли, удержаться от того, чтобы сообщить, что ушел он в Microsoft, я не могу.

Ну, что же, пожелаем им всем удачи. Звука всем виндоводам хорошего, и скорости загрузки!

Утв. 1: время сборки и обновления source-based distro определяется временем сборки используемого браузера. Все остальное - o-малое.

Это, в целом, практический факт, и он довольно понятен:

* Браузер собирается очень долго

* Браузер зависит от кучи всего, поэтому пересобирается на любой чих

Ладно, я чуть-чуть утрирую, на самом деле, в этом списке 2 - 3 самых тяжелых конечных приложения. Чаще всего это браузер, и еще что-нибудь, в моем случае, telegram.

Поэтому моя задача - делать граф как можно площе, и выпиливать все несущественные зависимости от этих 2 - 3 конечных приложений.

Не для того, чтобы они собирались быстрее, а для того, чтобы они собирались сильно реже.

Вот, расскажу про пример такой паразитной цепочки.

Обновлял nettle, это такая криптобиблиотека, и у меня пересобрался телеграм. Казалось бы, где телега, а где nettle,

1) gnutls -> nettle.
2) microhttp(гнутая библиотека для разработки http client-server) -> gnutls
3) elfutils(tool) -> microhttp
4) x264/vpx(кодеки) -> elfutils(tool)
5) -> ffmpeg
6) -> telegram

Все зависимости довольно понятны, и логичны, кроме 3)

В составе elfutils идет debuginfod, которому нужно уметь ходить по http, а всем остальным, нужным мне в сборке, тулзам, из elfutils, http не нужен.

Поэтому я теперь собираю elfutils 2 раза - 1 раз целиком, для пользователя, и второй, в урезанном виде, как сборочный инструмент. Казалось бы, лишняя нагрузка на CPU, но нет, от браузера оторвалось большое поддерево, и, наоборот, ресурсов мы тратим сильно меньше.

Кстати, браузер тоже зависел от gnutls, но эту зависимость я оторвал немного раньше, и заменил ее на openssl.

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

Реклама - наше все!

Сравните заглавную страницу проекта(W): http://www.graphicsmagick.org/

И release notes(R): https://sourceforge.net/projects/graphicsmagick/files/

W: "GraphicsMagick is the swiss army knife of image processing. Comprised of 279K physical lines (according to David A. Wheeler's SLOCCount) of source code in the base package (or 1,275K including 3rd party libraries) it provides a robust and efficient collection of tools and libraries which support reading, writing, and manipulating an image in over 89 major formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, TIFF, and WebP."

R: "For several years now, the burden has entirely been on me (Bob Friesenhahn). I have been sheparding the project for 20 years already (and contributed to ImageMagick and GraphicsMagick combined for 26 years already). It is not reasonable to expect someone with a full time job (and expecting to retire in a few years) to do all of the work."

W: "GM participates in Google's oss-fuzz project (since February, 2018)." (типа, круто, нас фаззят!)

R: "GraphicsMagick is participating in Google's oss-fuzz project due to the contributions and assistance of Alex Gaynor. Since February 4 2018, ??? issues have been opened by oss-fuzz and ?? issues remain open." (фаззят, а issues не закрывают)

Ну и так далее.

https://github.com/Novum/vkQuake/releases/tag/1.20.3

#vkquake

"Fixed multiple parallelism bugs"

Вот жопа, хоть бы спасибо сказал.

У меня есть (короткий) список из нескольких задач, которые надо закрыть, прежде чем можно показать #stal/ix широкой общественности. #libmagic

Это задачи не про перфекционизм, а конкретные вещи, без которых "ничего работать не будет".

Как пример - дать возможность пользователю выбрать 3d драйвер из mesa. Пока у меня все заточено под мой setup из zink + radv, но там надо поддержать и более классическую схему с radeonsi, и intel, и software stack. Nouveau пока трогать не буду, подожду, пока они впилят наработки от open source nvidia.

На днях закрыл две задачи из списка - про размер курсора в gtk приложениях(он у меня был прибит гвоздями, а теперь может быть установлен через XCURSOR_SIZE), и про xdg-open.

Про xdg-open расскажу сегодня.

У вменяемого приложения под Linux есть два способа открыть какой-то внешний по отношению к себе файл:

* позвать портал через dbus.

* позвать command line тулзу xdg-open, передав ей путь к файлу или url.

Предполагается, что каждое DE будет предоставлять свой портал, или свой скрипт xdg-open(я тут немного упрощаю, для простоты объяснения).

К сожалению, in the wild я нашел только реализацию от freedesktop, и она настолько всратая, что у меня, при попытке это описать, остаются только матерные слова.

https://www.freedesktop.org/wiki/Software/xdg-utils/

(кстати, у невменяемых приложений есть и другие пути, например, KDE-шники любят долбиться в KParts, убил бы их за это, но это в следующей серии)

У меня какое-то время была заглушка для xdg-open, которая просто все открывала в браузере - https://github.com/pg83/ix/blob/99291c90267d7b690bc39fca7224c0a20b76334c/pkgs/bin/xdg/open/ix.sh#L8

Браузер умеет открывать почти все, и это решало 90% моих задач.

Но, кажется, людям такое отдавать несколько стыдно, но и насилолвать свой мозг через xdg-open от freedesktop мне не хотелось.

Поэтому я решил воспользоваться знанием того, какие у меня бинарники вообще бывают в дистрибутиве, и написал вот такой вот скрипт - https://github.com/pg83/ix/blob/main/pkgs/bin/xdg/open/scripts/xdg-open

Он определяет mime type переданного файла, и пытается для каждого известного типа выбрать наиболее подходящую программу из PATH. Ну и проваливается в браузер, если ничего не найдено(тут есть "мелкая" проблемка - а что, если xdg-open позвал браузер?).

Программы отсортированы по их известности. Потому что я предполагаю, что менее известная == более специализированная для пользователя, не просто же так он ее установил.

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

На мой взгляд, план этот потерпел фиаско. #fast_python

https://github.com/faster-cpython/ideas/blob/main/main-vs-310.rst

(Кстати, fellow kids, учитесь составлять презы - невнимательный читатель может подумать, что ускорили в 1.5 - 2 раза, а geometric mean - всего +25%)

Ускорили на четверть, хотя, по плану из https://github.com/markshannon/faster-cpython/blob/master/plan.md, каждый следующий релиз должен давать +50%, отложили релиз 3.11 еще на несколько месяцев, потому что он ведет себя нестабильно - https://www.spinics.net/lists/fedora-devel/msg302880.html

https://news.ycombinator.com/item?id=32002057

А что с удалением GIL? ХЗ, я не заметил какой-то активности про внедрение https://github.com/colesbury/nogil #nogil

Гвидо - на мыло, я так думаю.

Например, набор классных еженедельных дайджестов на разные темы: https://discu.eu/weekly/

Если лень читать HN/Lobsters/Reddit, то все сливки за неделю - там.

https://github.com/jaor/xmobar#were-using-github-under-protest

Тем временем, наткнулся на первого мамкиного съезжатора с github. #sfc #gnu #gpl #charity

Кстати, я сам, лично, выкладывал что-то под GPL, только когда был literallly голодным студентом. Ну, посудите сами, мне тут жрать нечего, а кто-то, НА ХАЛЯВУ, воспользуется моим бесценным кодом.

После того, как:

* Заработал первые деньги

* На собственной шкуре убедился, что copyleft делит весь софт на 2 плохо связанные части(я тут намеренно не указал OSS, потому что корпорации довольно охотно отдают код под permissive license, да и сами используют тоже). Произошло это примерно так - я, вдруг, понял, что я, Антон, могу использовать кусок GPL2 библиотеки base64 во внешнем проекте, но я, Антон, не могу же использовать ее внутри Я, а, значит, Столлман не за меня, а против корпораций. И это не моя война, так как я хочу иметь возможность использовать OSS софт в любом контексте. Сумасшедшие фанатики тут делают вывод, что все должно быть под GPL, я же сделал вывод, что надо делиться, и не требовать ничего взамен, чтобы не создавать проблем какому-нибудь другому Anton, где-нить совершенно в другом месте.

, я ни строчки не отдавал под copyleft лицензиями.

copyleft - это лицензия очень жадных(и голодных, а оттого жадных) людей, которые готовы делать добро, только если им пообещают, что на это ответят добром.

Простите за моралофажество, но это не по-христиански.

Замахнулся на святое - на ImGui.

#shell

https://github.com/ocornut/imgui

Давно хотел попробовать собрать себе что-то интересное с использованием этой библиотеки:

* пощупать вживую immediate mode gui.

* для галочки, что, вот, "и это у меня работает".

* мне кажется, что ее концепция упраления окнами весьма хорошо ложится на sway.

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

ImGui мне пока кажется весьма странным зверем - у нее какое-то бешеное количество звезд на github, в 10 раз больше, чем, скажем, у wxWidgets.

Но при этом, пользовательских приложений на ней практически не сыскать, по крайней мере, в репозиториях.

Но при этом, в changelog к новому релизу imgui - с десяток скриншотов https://github.com/ocornut/imgui/releases/tag/v1.88 новых приложений, которые ее используют.

Короче, какая-то совершенно непонятная мне экономика.

Еще про imgui у меня есть завиральная идея - а что, если взять wlroots, и сделать его одним из поставщиков графического контекста для imgui, как, скажем, sdl, или egl? И в цикле рисования gui просто завести по одному окну на каждое wayland-окно, и отрисовать в нем буфер приложения?

Кажется, если не считать io, то, строк за 200 можно соорудить весьма неплохой композитор.

Да, да, я, в фоне, продолжаю думать на эту тему, никак она меня не отпускает. #cardboard

Я, как-то, уже писал про то, как, на мой взгляд, должен быть устроен композитор на ноутбуке, но, с ходу, не могу найти текст про это, поэтому напишу еще раз.

Вот так:

https://github.com/paperwm/PaperWM
https://github.com/cardboardwm/cardboard

Первый тормозит, и под gnome shelll, второй - заброшен.

Короче, из release notes я себе нашел приложение для тренировки - https://github.com/sgiurgiu/reddit_desktop

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

Но об этом в следующей серии.

https://www.phoronix.com/scan.php?page=article&item=linux-kernel-o3&num=9 #O3

У меня тут, в закромах, завалялась ссылка про тестирование Мишей сборки ядра с -O3.

Видимо, как ответ на возникушую в lkml дискуссию про сборку ядра с -O3, которую Линус быстренько прекратил https://lore.kernel.org/lkml/CA+55aFz2sNBbZyg-_i8_Ldr2e8o9dfvdSfHHuRzVtP2VMAUWPg@mail.gmail.com/

В целом, я про -O3 думаю так:

* Погромировать никто не умеет, поэтому код надо собирать так, как его чаще всего собирают. С -O2, так с -O2. По крайней мере, пока компиляторы спекулируют на UB.

* Сумасшедших, которые собирают ядро с -O3, или там с LTO, я вообще не понимаю. В нормальной нагрузке ядро занимает 3-5%(если, конечно, вы не пишете DPI для Путина). Ну сделаете вы это быстрее на 10%, и чо? Чтобы что?

* Позиция Линуса мне не нравится. Из-за того, что он отказывается писать на нормальном С, компиляторостроителям приходится поддерживать разного рода хаки, да и не каждая версия компилятора подходит для сборки ядра. Сейчас реже, а раньше в каждом дистре была бережно прикопанная версия gcc для этой задачи.

По ссылке есть 1 тест, который стал существенно быстрее, это похоже на валенок на пульте, который надо просто зачинить в ядре, и отставание должно свестись в 0.