В копилочку того, почему не надо держать свою #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!

как объяснить гуманитариям, что такое 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.group-telegram.com/itpgchannel.com/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.group-telegram.com/itpgchannel.com/2939

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

Будни #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.

Будни #bootstrap

Случилось страшное, два одинаковых питона, собранных на двух разных хостах моей #homelab #lab:

lab1 # python3
Python 3.12.7 (main, Jun  9 2025, 09:12:41) [Clang 20.1.5 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import uuid
>>> ^D

lab2 # python3
Python 3.12.7 (main, Jun 10 2025, 11:25:34) [Clang 20.1.5 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import uuid
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ModuleNotFoundError: No module named 'uuid'
>>>

Я, конечно, предположил где такое может происходить (python frozen.py во втором случае не сумел понять, что используется модуль uuid, и не добавил его в заморозку), но выглядит максимально всрато.

Такие configure скрипты нам не нужны!

Тут вот один наш коллега показал, как у него хостилось зеркало #stal/ix, я аж смахнул слезу умиления, увидев знакомый логотип.

AOSP project is coming to an end


Comments  on lobsters

https://jasone.github.io/2025/06/12/jemalloc-postmortem/

"The jemalloc memory allocator was first conceived in early 2004, and has been in public use for about 20 years now. Thanks to the nature of open source software licensing, jemalloc will remain publicly available indefinitely. But active upstream development has come to an end. This post briefly describes jemalloc’s development phases, each with some success/failure highlights, followed by some retrospective commentary"

Тут вот ко мне пришли любители X11, и начали рассказывать, что им очень-очень нужен X11 - https://github.com/stal-ix/ix/issues/746

Свой ответ я переписывал раз 5, прежде чем отправить.

https://www.usenix.org/system/files/osdi22-huang-lexiang.pdf

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