Мне в обсуждении предложили посмотреть на 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"

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

https://old.reddit.com/r/rust/comments/y4w2kr/llvm_used_by_rustc_is_now_optimized_with_bolt_on/

А вот коллеги применили #BOLT к llvm + rustc.

Пишут, что 3-5% перфа, но получилось применить только на llvm часть, rustc целиком оптимизднуть не получилось.

https://nitter.it/linaasahi/status/1583444549648543744

Между прочим, у #asahi linux какой-то серьезный прогресс за последние несколько месяцев. То год ничего не происходило(с точки зрения графического стека), то на тебе - проходят 99% dEQP - https://chromium.googlesource.com/angle/angle/+/main/doc/dEQP.md - в первый раз слышу, но:

"drawElements (dEQP) is a very robust and comprehensive set of open-source tests for GLES2, GLES3+ and EGL. They provide a huge net of coverage for almost every GL API feature. ANGLE by default builds dEQP testing targets for testing against GLES 2, GLES 3, EGL, and GLES 3.1 (on supported platforms)"

Ну, то есть, явно случилось что-то хорошее.

Еще отмечу, что раньше разработчик(хехе) проверял все на mac(ну, то есть, modesetting занимался mac, а он генерил и слал команды в карточку), то теперь там, в наличии, и modesetting driver для ядра(на rust, ага).

(в фанфары бить пока рановато, прогресс на уровне nouveau, но пользоваться уже можно)

https://github.com/carbon-language/carbon-lang/discussions/2329

У #carbon все еще нет компилятора, но уже есть "Carbon Language community transparency report".

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

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

http://davidbau.com/archives/2010/03/14/the_mystery_of_355113.html

Такая теория чисел нам нравится.

https://daniel.haxx.se/blog/2022/08/12/the-dream-of-auto-detecting-proxies/

Вот тут вот автор curl расписал, почему он не хочет к себе тащить зависимость от libproxy. Давно про нее хотел написать, вот, появился повод.

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

Потому что, в попытке решить простую проблему, добавляет в код кучу новых:

* #plugins Плагинная архитектура - куча загружаемых модулей, каждый под свой DE. Заменяем проблему поиска прокси в DE на поиск плагина для этого DE. Чем это плохо, много раз писал.

* Удивительный факт - плагины используются не по месту! По месу было бы, если бы плагины линковались с библиотеками этого DE, и тогда, действительно, имело бы смысл не загружать в себя чужеродный event loop. Проблема в том, что плагины не линкуются с кодом, а дергают subprocess - https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_kde.cpp#L47 Собственно, это вторая проблема - плагин дергает fork(), чего нельз делать в библиотеке общего назначения.

* Просто код всратого качество - какие-то плагины ловят исключения - https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_kde.cpp#L56, какие-то - нет. https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_gnome3.cpp#L130

* Велосипедизм. https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_gnome3.cpp#L61 - реализация popen2, плохого качества.

Короче, всячески НЕ рекомендую.

Как надо? Надо, конечно, узнавать это через dbus, через xdg portal. Или через переменные среды. Но уж точно не так.

А сегодня у меня короткий рассказ про то, почему же у нас все еще нет self driving cars на наших дорогах.

Дед опять забыл таблетки выпить

"Линус Торвальдс предложил прекратить поддержку CPU i486 в ядре Linux"

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

А, тем временем, на патчи про ускорение сборки ядра от Инго, кажется, положили болт.

#ingo

Я, знаете ли, довольно редко брюзжу в стиле "зачем A B, лучше бы С", обычно предпочитаю "какого хрена XYZ".

Но вот, в данном случае, хочется именно так - https://www.phoronix.com/news/Mesa-AGXV-Apple-Vulkan-VKCube

Какого хрена Зачем 2 сильных разработчицы(хехе) пишут одновременно opengl драйвер, и vulkan драйвер, когда есть прекрасный #zink, который может сделать opengl поверх vulkan? Лучше бы бросили все силы на vulkan драйвер.

(там есть такое полу-оправдание, мол, apple m1/m2 заточены под metal, и полный vulkan сделать для них невозможно, но IMHO оно так себе)

https://medium.com/@alt.cap/time-to-get-fit-an-open-letter-from-altimeter-to-mark-zuckerberg-and-the-meta-board-of-392d94e80a18

"To accomplish this goal, we recommend a three step plan that will double FCF to $40 B per year and focus the company’s teams and investments:
* Reduce headcount expense by at least 20%;
* Reduce annual capex by at least $5 B from $30B to $25B; and
* Limit investment in metaverse / Reality Labs to no more than $5B per year"

Тут вот коллегам рекомендуют прекратить жрать в 3 рта ужаться.

Это все весьма интересно, но вот у нас с товарищами вопрос - вот эти 20% - они будут выбираться по performance review, или там тоже будут квоты на ЛГБТ и прочие меньшинства?

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

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

Что тут примечательно?

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

* Предлагаю прочесть коротенький текст https://wiki.alopex.li/RiscIn2022, чтобы проникнуться фактом - ISA - это API, и, на самом деле, современным вендорам пофиг, через какое API они работают. ARM хорош не потому, что это API классное, а потому что у него есть хорошие референсные дизайны. Стоит появиться IP вендору, который предоставит хорошие дизайны для RISC-V, сойдет лавина, запомните этот твит.

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

Продолжаем тему, почему же повторять vfs в userspace - так себе затея. Казалось бы, ничего сложного, но никто, с первого раза, правильно не пишет.

Вообще, конечно, если поразмыслить, то просто chroot мало, потому что:

* надо или вызывать fork + chroot
* или уметь возвращать root назад, что-то типа effective root, но тут очевидные проблемы с многопотоком

Вышел Python 3.11: Python for WorkTaskGroups, Миша с фороникса пишет, что ажно на треть быстрее - https://www.phoronix.com/review/python-311-performance

В релизе написано, что ажно на 22% быстрее - https://www.python.org/downloads/release/python-3110/. (еще там какой-то научпоп для решения вращающейся черной дыры)

Где они берут такие цифры, я не понимаю, у меня на реальной задаче(скажем, построение сборочного графа для всех пакетов из #IX) профит приходится искать с лупой.

https://habr.com/ru/company/vk/blog/694536/

Тут коллеги запилили интересное решение для параллельной сборки большого числа исходников.

Понятно, что я никак не могу пройти мимо такой значимой штуки!

Какую задачу решали коллеги?

У них есть 200к сгенерированных из php с/с++ исходников, лапшеобразных, без особых мета-изысков. Они не зависят друг от друга, а зависят, грубо говоря, от "php.h". Если вы знаете, что такое cython, то вы знаете, о чем идет речь.

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

Собственно, схема nocc очень напоминает схему с distcc:

* локальный оркестратор
* линковка локальная
* кодогенерация локальная
* на воркерах нет full repository view, в пакете для воркера содержатся все нужные данные

Что поменялось:

* content addressable global cache, как для исходников, так и для .o файлов - то есть, мы сначала передаем md5, а потом, если файла нет в кеше, то докачиваем его

* самое, КМК, главное - локально мы не препроцессим исходник, а парсим его примитивным(быстрым!) парсером, майня в процессе includes. На удаленный сервер в пакете отправляется исходник + все нужные заголовки(с компрессией через global cache)

Собственно, тем самым, расшиваем узкое место distcc.

До настоящих распределенных CI/CD систем это пока не дотягивает. Все же, надо уметь раскладывать в граф весь процесс, а не только компиляцию.

Для исходной задачи, конечно, решение весьма разумно, потому что:

* БОльшая часть исходников зависит только от небольшого, и заранее известного, числа заголовков.

* Обладая контролем над системой, можно сделать приятные оптимизации. Например, разметить сгенеренные файлы так, чтобы почти не парсить их на предмет includes(напомню - узкое место - препроцессор).

Что я хочу еще сказать?

С небольшой толикой везения, коллег ждет явный OSS успех!

Потому что их решение обладает интересным свойством - оно ничем не хуже, чем distcc, а в каких-то аспектах сильно лучше.

Пользователям distcc нет никаких причин не перейти на новую технологию.

(Если тут поспекулировать про распределенные CI/CD от того же Яндекса, или Гугла, и их перспективы в OSS - они, конечно, сильно мощнее, но их никто и никогда не сумеет развернуть за пределами инфраструктуры этих компаний)