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

Представлены результаты тестирования свежих выпусков СУБД Redis 8.0 и Valkey 8.1, в которых были заявлены значительные оптимизации производительности. Во всех проведённых тестах развиваемый сообществом форк обогнал оригинальный проект, в основном благодаря внедрению в Valkey нового механизма для многопоточной обработки ввода/вывода в асинхронном режиме, переданного проекту компанией Amazon.

#perf #fork

https://localmess.github.io/

"We disclose a novel tracking method by Meta and Yandex potentially affecting billions of Android users. We found that native Android apps—including Facebook, Instagram, and several Yandex apps including Maps and Browser—silently listen on fixed local ports for tracking purposes."

https://www.securitylab.ru/news/560030.php
https://github.com/tpde2/tpde
https://arxiv.org/abs/2505.22610
https://discourse.llvm.org/t/tpde-llvm-10-20x-faster-llvm-o0-back-end/86664

"Исследователи из Технического университета Мюнхена (TUM) представили TPDE — инструмент для быстрой компиляции кода, который способен ускорить сборку для архитектур x86_64 и AArch64 в 10–20 раз по сравнению с LLVM Clang на базовом уровне оптимизации -O0. Новый backend-компилятор ориентирован на задачи с минимальной задержкой — например, для JIT-сборки или быстрой отладки без оптимизаций. Исходный код проекта уже доступен на GitHub , а описание архитектуры опубликовано в научной статье на arXiv"

https://www.phoronix.com/news/Redox-OS-Implementing-X11

"Rust-written Redox OS has begun rolling out X11 support within its Orbital display server"

"Another big milestone for Redox OS during the month of May is seeing an initial GTK3 toolkit port"

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

Чувствую, что опять упускаю бизнес-возможность...

https://www.phoronix.com/news/Linux-PCACHE-RFC-v2

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

В копилочку того, почему не надо держать свою #infra, и #gitlab, в частности.

Но, на этот раз, история касается меня непосредственно.

https://github.com/pg83/ix/pull/22

Вот, пришли коллеги из torproject, и сказали, что я приложил их #gitlab.

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

Урл я поправил, но вот даже сам коллега признает, что:

"to be fair, gitlab shouldn't just fall over if you crawl /archive/ endpoints like this"

Наткнулся на забавную штуку.

Есть большой класс — кусок query execution, в некотором смысле state machine. Соответственно, в нём есть мембер переменная enum State : int, по которой делают switch и в которую делают store в этом же switch.

А ещё код был примерно такой, и я заметил, что _unused не используется — и удалил:

void* ...;  
int _unused;  
State _state;  
void* ...;  

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

И тут, собственно, причина, почему я пишу: я заметил, что тесты стали проходить медленнее — процентов на 5-10 от обычного времени (42 vs 46 минут). Ну, подумал, может, совпадение, но решил запустить ещё раз с/без патча. Результаты повторились (к сожалению, это было не единственное изменение в PR).

Пошёл смотреть, какие именно тесты стали медленнее, и заметил, что в половине из них разница в пределах погрешности, но многие тесты кверинга стали заметно медленее.
В общем, методом пристального взгляда я нашёл это место и позапускал с _unused и без. И действительно оказалось, что на ryzen 4 (по крайней мере, 7950X) код с чтением и записью 4 байт по адресу с alignment 4 работает лучше, чем с alignment 8.

Есть у кого идеи, почему?
Возможно, это какой-то затуп store-to-load forwarding-a, но как-то неочевидно, почему это происходит именно в таком сетапе.

Если что, store-to-load forwarding — это оптимизация в процессорах, когда ты пишешь в память x (<= 16?) байт, а потом читаешь <= x байт из того же места — можно не ждать завершения записи.
Неудивительно, что, как и многие другие оптимизации процессора, она работает не всегда. Например, чтение меньшего числа байт (по крайне мере с ненулевого оффсета) обычно работает медленнее.

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

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

Теперь у желающих продолжить развитие X11 появилась подходящая площадка для этого.

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

https://github.com/X11Libre/xserver

Together we'll make X great again!

https://www.phoronix.com/review/snapdragon-x1-gcc-clang/3

На этот раз Миша сравнивает clang с gcc на Qualcomm Snapdragon X Elite laptop.

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

TL;DR - clang довольно уверенно отрывается от gcc на 2 - 3 процента, как и в прошлый раз.

(cамые внимательные читатели могут заметить, что этот текст - почти полная копипаста предыдущего текста на эту тему, https://www.tgoop.com/itpgchannel/2208, но это и логично, если подумать)

как объяснить гуманитариям, что такое gaussian splatting

спер тут

https://arxiv.org/html/2501.06716v1#S1

TL;DR - динамическая линковка тормозит, поэтому давайте делать ее 1 раз на все приложения сразу, когда в системе меняется набор .so (и/или программ).

"Despite its widespread use, dynamic linking limits the performance and dependency management of applications. On the performance side, dynamic linking is surprisingly expensive; Becker et al. show that dynamic linking accounts for 74% of the total runtime for short-lived programs (Becker and Chakraborty, 2018), and our analysis shows that large applications spend most of their startup time on dynamic linking (section 2.1)"

Что я могу на это сказать?

* Предложенный метод решает только одну из проблем, которые я обозначил в https://www.tgoop.com/itpgchannel/2939

* Предложенный метод - далеко не нов. В glibc уже был prelink, и его оттуда выпилили к херам, потому что поддерживать такой кеш - сложно. https://wiki.gentoo.org/wiki/Prelink/ru:

"The glibc upstream has removed prelink support in glibc-2.35, so support for prelinking cannot be kept. The core package sys-devel/prelink explained below, is no longer available from the Gentoo ebuild repository since Feb 23, 2022. See bug #579374 or bug #726062 for details."

* Предложенный метод только увеличивает сложность всей системы, а, значит, только усугубляет какие-то из проблем, которые я описал в https://www.tgoop.com/itpgchannel/2939

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

#mold

https://www.phoronix.com/news/Mold-2.40.1-Released

"Mold 2.40.1 Delivers More Performance - Including A New Algorithm Generated By ChatGPT"

"Improve multi-glob pattern matcher so that it's linear-time

I asked ChatGPT how to match multiple glob patterns simultaneously with a given input string, while avoiding the textbook-style NFA-to-DFA conversion. Then it suggested that I implement a bitvector-based NFA simulation algorithm that I wasn't aware. I don't think I could have come up with it myself easily. This is impressive. ChatGPT is so good at programming and sometimes much better than me! It may not be to long before AI writes all the code for me"

Хе-хе, Rui решил прокатиться на волне AI хайпа.

UPD: Миша с похороникса, как обычно, неверно прочел текст changelog. ChatGPT указал, что такой алгоритм существует ("суммаризовал" данные, что у AI получается хорошо), а код писал, конечно, сам Rui.

Будни #bootstrap

За прошедшее время я завел себе полный кеш исходников на huggingface (счастья и здоровья этим проклятым капиталистам, пока они дают околобесплатный хостинг для произвольного объема данных) - https://huggingface.co/datasets/stal-ix/pkgsrc/tree/main, и на ghcr.io (это место, где github хранит контейнерные слои, там unlimited, в отличие от github lfs) - https://github.com/orgs/stal-ix/packages. Этим проклятым капиталистам тоже счастья и здоровья, ага.

Я, кстати, такой не один, на ghcr.io "хостится" homebrew.

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

Поэтому я взял, и удалил пользовательские зеркала из конфига - https://github.com/pg83/ix/commit/869f6bf18ebf1709ea3ee2ac3eacf90037596725

А пост я пишу, чтобы еще раз сказать спасибо всем тем, кто поддерживал зеркала проекта в сложное время! Вам, конечно, тоже счастья и здоровья!

#mirror, the end.

https://github.com/X11Libre/xserver/issues/4

Некоторые приложения зависают с Xlibre при загрузке. Потому что нефиг рефачить без тестов почем зря.

X11, который вы (луддиты) заслужили!