https://www.phoronix.com/news/LLVM-Clang-15-Benchmarks

А вот бенчмарк кода, собранного clang15 vs clang14.

Примерно 1% в среднем по больнице, что приятно.

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

https://reviews.llvm.org/rGd5090cd94a8f

Продолжает приземляться поддержка сборки llvm/clang в один большой бинарник, #busybox-style

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

Ожидаю, что размер пакета с clang упадет в 2 - 3 раза. В перфе роста не ожидаю, потому что 99% времени все равно жрет компиляция, и факт того, что всякие ar/lld/etc будут использовать те же кеши, что и бинарник clang, особой роли играть не будут.

И последняя новость из мира LLVM на сегодня.

https://llvmweekly.org/issue/458

"LLVM’s libc gained implementations of fork, rand, srand, waitpid, wait4, execv, execve, kill, strerror_r, and strsignal functions. e3638e8, 38b6f58, 995105d, 3f96581, 9015810, a9f95b7, 07793f9"

Коллеги прямо очень быстро пишут libc от LLVM.

Я осторожно скажу, что не ожидаю ее готовность к концу 2022, но вот в первой половине 23 надеюсь уже "пощупать" (ЕБЖ, конечно).

Лично для меня это самый ожидаемый проект от экосистемы LLVM(после, собственно, самой llvm/clang/lld), потому что, писал и буду писать, авторы что #glibc, что #musl - негодяи с завышенным ЧСВ, и появление еще одного конкурента на этой делянке - это very appropriate.

https://www.opennet.ru/opennews/art.shtml?num=57909

"Постановление предписывает:

Создание национального репозитория ПО с открытым кодом;
Размещение в репозитории программного обеспечения, созданного, в том числе, за бюджетные средства, для повторного использования в других проектах;
Формирование нормативной базы для публикации ПО с открытым кодом"

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

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

UPD: в комментариях предложили назвать это "ГИТЛАГ", звучит хорошо!

https://lwn.net/Articles/910848/

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

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

https://determinate.systems/posts/qemu-fix
https://www.phoronix.com/news/Linux-6.1-Faster-9P

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

Этот текст - не про то, как "мы все сделали хорошо", а про то, как "все на самом деле плохо".

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

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

Буде qemu и Linux написаны на нормальных языках, где использование контейнеров не доставляет боль, там или с самого начала была бы хеш-таблица, или чувак, заметивший и пофиксивший это не попал бы к Линусу в блог и на главную страницу phoronix.

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

https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
https://lwn.net/ml/fedora-devel/CACBV9Zgr_wpM2vkTL=7Mtn+u+8vTHHELfUdnVtavgXhxrwv5dQ@mail.gmail.com/

Федора перестала поддерживать аппаратные кодеки "из коробки".

Я, признаться, не понимаю, зачем эти кодеки вообще нужны, кроме как если вы хотите показывать 4k видео с raspberrypi, но это в любом случае грязное извращение.

Наверное, это имеет смысл во всяких телефонах и планшетах, но не на десктопе.

По мне так все эти аппаратные vdpau/vaapi больше похожи на пузомерку у фанатов Linux - постоянно вижу на всяких форумах срачи про "а у меня не работает va* в firefox/etc", с предложением вправить руки.

Ну и, наверняка же, они дают разный результат у разных вендоров железки, да?

Я собираю #mesa без их поддержки.

https://osgameclones.com/

Набрел вот на каталог open source клонов древних и не очень игр.

Их там неожиданно много, правда, 90% - нерабочее и заброшенное УГ, но поковыряться в этом интересно.

Тут вот у меня(шутка, хе-хе) взяли интервью, https://onebite.dev/a-fake-conversation-between-the-best-programmer-in-the-world-with-a-junior/, но там осталась нераскрытой тема code review, решил ее раскрыть. #gold

Про code review есть много заблуждений:

* "CR нужен, чтобы искать баги". Нет, он нужен не для этого. За все мои несчетные CR найденные баги можно пересчитать по пальцам рук. Баги ищут тесты, прогоны с фаззерами, санитайзерами, в тестовой и canary средах, и так далее.

* "CR нужен, чтобы на выходе был лучший возможный код". У всех ревьюеров свои представления о прекрасном. Если вы на CR занимаетесь тем, что навязываете их кому-то, то в этом нет ничего хорошего. На выходе у вас все равно будет код, не дотягивающий до высоких стандартов, но все участники будут сильно недовольны процессом. А на следующем CR тот, кого ты заставил переписывать свой код, заставит переписать твой. Наверняка у вас в окрестности есть ревьюер, который заставляет переписывать вызов usleep() на вызов std::chrono? Обращусь к таким ревьюерам - поумерьте свой пыл. Код не становится объективно лучше, он просто больше удовлетворяет ваше чувство прекрасного(про него ниже). (С точки зрения best programmer in the world - один человек все равно не может написать весь код во всем мире, поэтому бОльшую часть времени придется иметь дело с говнокодом, и тут ничего не поделать)

* "CR нужен, чтобы разобраться и пофиксить ошибки дизайна системы, ее архитектуры". "А давай ты мне расскажешь, что тут происходит, а я тебе расскажу, как все переделать". В корне неверное представление. Если вы на CR начали обсуждать дизайн, то у вас неверно построена постановка задач. Архитектуру надо обсуждать ДО того, как получена первая итерация кода, а не после.

А зачем тогда нужен CR?

* Для общения людей. Чтобы упыри, которые пишут код в своих подвалах, иногда вылезали на свет, и разговаривали про систему, которую они совместно пишут.

* Важная тема. CR позволяет получить бумагу с печатью, что я не приду и не откоммичу твой коммит, если ты его сделал без CR. Согласие есть полное непротивление сторон. (если есть уверенность, что принимающая сторона не откатит PR, то можно и без ревью, для экономии времени)

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

Как делать хорошие ревью?

* На ревью проверяем только формально верифицируемые и записанные договоренности. Лучше всего, конечно, когда они формализованы настолько, что их может проверить скрипт. Тогда нам остается только проверить зеленые галки, и нажать "ship it".

* Перед ревью умножаем свое чувство прекрасного на 0. Не тешим ЧСВ, придумывая новые и новые проблемы в коде, и отправляя на следующие итерации. Ревью - не экзамен, когда надо найти дыры в знаниях, а разговор равных.

* плохой naming - последнее пристанище негодяя. В том смысле, что никогда не докапываемся до названий, потому что, очевидно, идеальный naming у всех будет разный. А в некоторых VCS поменять путь к файлу в рамках одного PR - боль.

* Стремимся уменьшать число итераций ревью. Я, например, часто пишу так "мне все ОК, но перед коммитом поправь пару мелочей и сделай себе ship it сам на новую итерацию". Дополнительные итерации - это просто потраченное зря время нескольких человек, и машинного времени на проверку. И вы все равно не получите свой "идеальный код", его не бывает.

Идеальное ревью:

* Занимает ровно одну итерацию. Посмотрел на код, на зеленые галки, прикрыл глаза, зажал нос, нажал "ship it". Если часто приходится писать комментарии и отправлять на следующую итерацию - или вы включили свое чувство прекрасного, или у вас слишком мало формализовано правил, которые нужно соблюдать на ревью. Не поленитесь, формализуйте.

Да, в этом тексте я описал CR "от равных равному". Если это CR нубского кода(стажер, джун, и так далее), то CR - это часть обучения, и оно должно быть устроено не так.

https://tigyog.app/d/H7XOvXvC_x/r/goedel-s-first-incompleteness-theorem

Зумеры продолжают захватывать мир.

Теорема Геделя о неполноте в картинках. IMHO тема не раскрыта, лучше почитать википедию.

https://www.nature.com/articles/d41586-022-03256-9

"Authors’ names have ‘astonishing’ influence on peer reviewers. A Nobel prizewinner is six times more likely than someone less well known to get a thumbs-up for acceptance, finds study."

Между тем, в Гугле уже практикуют анонимные ревью. КМК, хорошая тема.

В продолжение темы про chroot - https://github.com/pg83/ix/pull/3/commits/0f09c401ffcd58ec46a7519edb0c2227a90cb1e8

Какой-то кривой патч, непонятно как работающий с симлинками в архиве(abspath не резолвит симлинки в путях), приехал ко мне от доброжелательного робота, видимо, фиксящего какой-то CVE в питонячке.

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

https://lwn.net/ml/linux-kernel/CAHk-=wj6y5fipM2A5kEuOO9qm5PBzUY=-m9viEahhtxT09KR_g@mail.gmail.com/

"Talking about frustration, let me just say that after I got my machine sorted out and caught up with the merge window, I wass somewhat frustrated with various late pull requests. I've mentioned this before, but it's _really_ quite annoying to get quite a few pull requests in the last few days of the merge window.

Yes, the merge window is two weeks, but that's very much to allow me time to look things over, not "two weeks to hurriedly put together a branch that you send Linus on Friday of the second week". The whole "do an all-nighter to get the paper in the day before the dealine" is something that should have gone out the window after highschool. Not for kernel development.

The rule is that things that get sent to me should be ready *before* the merge window opens, not be made ready during the merge window. With some slack for "life happens", of course, but I really get the feeling that a few people treat the end of the merge window as a deadline, missing the whole "it was supposed to be ready before the merge window""

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

Я, конечно, хотел бы ему посочувствовать, но он сам построил такую немасштабируемую махину.

Мне в обсуждении предложили посмотреть на pledge(), а вот и рассказ про то, почему он не работает в Linux в полной мере - https://blog.gnoack.org/post/pledge-on-linux/

Кожаные математики показывают зубы.
Или.
Битва людей и машин началась.

Вчера писал пост о том, как АльфаТензор создал произведения искусства в области математики, уделал кожаных мешков на их поле и о том, почему математика - не наука.

Оказывается, математики почитали про успехи АльфаТензора, напряглись и подали виду.

Вот статья, которая начинается так:
"В ответ на недавнюю статью в Nature, которая объявила об ИИ-алгоритме для умножения 5х5-матриц с 96 умножениями, что на два меньше, чем предыдущая рекорд, мы представляем алгоритм, который выполняет работу только с 95 умножениями."

Они также представили новое(!) решение для 4 × 4-матриц, требующих 47 умножений - то есть ровно такое же, как сделал ИИ. Решений может быть много и разных, и счет идет на умножения.

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

Воистину ИИ делает кожаный род лучше, умнее и работоспособнее!

https://arxiv.org/abs/2210.04045

https://www.phoronix.com/news/USB4-v2.0-Specification

В комментариях как-то обсуждали разъем type-c, и было высказано предположение, что решение Евросоюза якобы замедлит развитие технологий.

Вот, пожалуйста, продолжение развития type-c, в 2 раза быстрее.

В целом, совершенно непонятно, зачем больше физических проводов, чем в type-c, для любой задачи по передаче данных!

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

Например, есть точка зрения, что одним из стимулов развития процессоростроения стала говенная архитектура x86. Типа, как извернуться, и быстро исполнять такой совершенно убогий код? Конечно, придумывать все более лучшие оптимизации(как в железе, так и в софте).

Многие великие умы сломали мозг на тему, почему же математика так хорошо описывает окружающий нас мир. А я чем хуже?

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

Я лично всегда считал, что эта связь - это аксиоматика натуральных чисел, например, https://ru.wikipedia.org/wiki/Аксиомы_Пеано

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

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

Поэтому математика так хорошо описывает известный нам мир.

Кстати, теоремы Геделя о неполноте - они именно про системы, включающие в себя арифметику, то есть, арифметика - это одна из самых простых известных систем, но достаточно сложная, чтобы содержать в себе "странные" утверждения. Совпадение?

(Почему она хорошо описывает микро- и макро- мир? А точно хорошо? Мне вот не нравится, как она это делает, выглядит несколько притянутым за уши, одна комплекснозначная волновая функция чего стоит)

У меня есть определенная "чуйка" на чтение changelog в OSS проектах.

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

Так, знаете ли, и сказать, и умолчать что-то.

Поэтому, когда я полез читать https://releases.llvm.org/14.0.0/tools/lld/docs/ReleaseNotes.html (не спрашивайте), то сразу обратил внимание на "Several performance improvements were done to speed LLD up on projects with a lot of framework flags and library lookups. Large Swift-based projects will benefit significantly. (D113073, D113063, D113153, D113235)"

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

https://reviews.llvm.org/D113073
https://reviews.llvm.org/D113063
https://reviews.llvm.org/D113153

Там прямо классический набор - читаем содержимое директорий(одних и тех же) много раз, читаем одни и те же файлы много раз, делаем stat на одни и те же файлы много раз, все это в разных контекстах.

Конечно, оно у них взорвалось, пришлось добавлять кеши. Сделано это некрасиво, через глобальный объект, без блокировок.

Посмотрел на их код, однажды им предстоит изобрести еще и такую оптимизацию - если нам надо проверить наличие нескольких файлов в наборе директорий, то часто вместо вызова кучи stat() нужно сделать listdir() на все директории, и лукапить пути в хеш-таблицах.

Короче, mold vs. lld - это не "отличное против хорошего", это "человек сделал очевидные оптимизации" vs "на скорость положили с прибором".

https://www.oilshell.org/blog/2022/10/garbage-collector.html

Тут вот коллега пишет status update про oil shell.

Пишут, что занимались garbage collector. Ну, конечно, это основное, что надо пилить, когда ты решил запилить shell.

Я почему-то совсем не удивлен:

"We haven't finished our collector, but it passes many tests, and I believe we have good solutions to some tricky problems. I hope that experienced engineers will provide feedback, and help us with the code"

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

Еще они пишут, что кто-то на это дал грант:

"with help from an NLnet grant"

Я явно чего-то в этой жизни не понимаю.