Будни #bootstrap

У меня по этой задаче (upver libc++) наступило замечательное состояние "да я ебал".

В конце-концов, это не моя война. Хотят люди из LLVM чистить код - пускай сами имеют дело со сломанными проектами.

А я взял, и:

* https://github.com/pg83/ix/blob/main/pkgs/lib/c%2B%2B/19/patched/0.diff - вернул удаленную специализацию char_traits. Коллеги из clang решили, что создавать std::basic_string из любого типа - это плохо, а на эту возможность заложился много кто.

* Откатил https://github.com/llvm/llvm-project/commit/f9dd885cb6e6b70deff935689bb0dfb7d5b6a1a4 Самое интересное, что в транке у них это уже откачено, а в стабильной ветке - нет. https://github.com/llvm/llvm-project/commit/4f79ef4efff432a93005b156726587c8c5a5ac17

После этого все прошло более-менее нормально.

#Kent

https://www.phoronix.com/news/Bcachefs-Linux-6.14-Merged

"As a follow-up to yesterday's article around the on-disk format changes and other feature work on Bcachefs for Linux 6.14, the changes ended up being merged without issue for this next kernel version. That came after the Bcachefs changes were rejected during the Linux 6.13 cycle due to a Code of Conduct (CoC) committee decision"

"As noted, on Monday saw the Bcachefs pull request for Linux 6.14 submitted with what is hoped to be the last major on-disk format change prior to removing the "experimental" marking on this open-source file-system. Without any commentary by Linus Torvalds or the CoC committee, the changes were indeed merged within a few hours for Linux 6.14"

Кажется, "темная", которую устроили Кенту господа старослужащие, пошла процессу на пользу.

Наверное, это хорошо, потому что сообщество начало подъзаебывать выкрутасы этого господина - https://blog.sesse.net/blog/tech/2025-01-20-21-45_migrating_away_from_bcachefs.html

Очередной self assessment, от того же коллеги.

https://www.npopov.com/2025/01/05/This-year-in-LLVM-2024.html

Хорошая картинка про скорость сборки clang bootstrap прилагается!

В тексте много раз встречается слово "Rust", и автор пишет:

"I updated Rust to LLVM 18 and LLVM 19 this year. Both of these came with very nice perf results (LLVM 18, LLVM 19)"

https://github.com/rust-lang/rust/pull/127513

То есть, LLVM вполне себе работает и на Rust тоже, не только на Clang.

В обсуждении на похорониксе наткнулся прямо на маленький монументальный пост от автора ext2/3/4 fs.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1520191-bcachefs-changes-merged-without-issue-for-the-linux-6-14-kernel?p=1520399#post1520399

Из него следует, что самая-самая свободная fs развивается по сути, по требованиям корпораций, и за деньги корпораций:

"Ext4 does get some new features, but they are ones which companies are willing to fund because the return on investment of developing the feature makes sense from a cost/benefit perspective"

Это, конечно, в пику любителям #GPL, как оружия против жадных корпов.

Ну и вообще, там полно перлов

"This might sound horribly corporate, but there's a story about how the ZFS engineers started the project on the down lo, without asking permission from management or getting input from sales, and presented Sun with what was effectively a fiat accompli. Which might sound great,until you reflect that Sun ended up losing money until they had to sell themselves to another company, and effectively there is no longer much of an engineering organization supporting ZFS"

"The answer I came up with was around 100 person years worth of effort, with one low-end estimate of 50 person years, and a high-end estimate of 200 person-years (but that was for GPFS, which was a cluster file system, and so a lot more complicated). I reported this findings to the meeting, and a certain senior engineer from Intel said, "No, don't tell the manager's that because they will never approve the project! Tell them that btrfs will be ready in 18 months." I'll let people decide when btrfs hit that "enterprise ready status", especially for those sexy new advanced features that were supposed to compete with ZFS, but I don't think it's controversial that it wasn't in 18 months"

...

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

А в моем канале - раньше всех!

https://www.phoronix.com/news/AMD-AMDGPU-Composition-Stack

AMD форкнули Weston (это такой THE Wayland Compositor), и будут его допиливать, используя как демонстрацию возможностей своих видеокарт.

Интересно, зачем это им? Они поверили в Linux на desktop?

https://www.reddit.com/r/rust/comments/1i7m431/whitehouse_press_release_future_software_should/

Гля чо пишут, оказывается, Трамп отменил не только лишь Agile, но и то, что "весь новый код надо пистаь на memory safe языках"!

Наш слоняра!

У нас тут в чате в какой-то момент случился интересный диалог, который начался на "Любому вменяемому человеку очевидно". Как это ни странно, у любого вменяемого человека эта фраза вызывает желание ушатать. С вертушки в щщи.

До III века любому вменяемому человеку было ясно, что Солнце вращается вокруг Земли. Причём до V века Земля была плоской. У тех, кто так не считал, знатно подгорало.

Большим сюрпризом для вменяемых людей оказалось, что наследственная информация хранится в молекулах ДНК. Потому что это же трындец как нерационально в каждой клетке держать полную сборочную инструкцию для всего человека. Ещё вменяемые люди не знали, что гены могут брать и перепрыгивать между видами горизонтальным переносом. Зато вменяемые люди короткое время знали, что память может храниться в РНК и передаваться между организмами.

Потом не каждому вменяемому человеку было очевидно, что большинство клеток нашего тела — бактериальные. Да, по массе это меньше, чем полкило, но по количеству их чуть больше человеческих.

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

Казалось нереальным, что птица или оса может использовать магнитное поле Земли для навигации.

Казалось нереальным, что наша память не имеет операции чтения (есть только уничтожающее чтение + перезапись заново).

Гравитация когда-то считалась силой.

И вот до совсем недавних пор было очевидно, что килограмм — это не единица энергии.

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

Наука — это про то, что всем вменяемым людям без исключения очевидно, что хочется ушатывать тем, кто использует квантор общности для дешёвых манипуляций )

--
Вступайте в ряды Фурье! Любому вменяемому человеку очевидно, что атом похож на Солнечную систему. Только меньше и вообще другой!

Между прочим, один из трех (вроде) каналов, на которые я подписан основным аккаунтом в телеге!

Внезапно перевел все наши продукты с jemalloc на mimalloc.

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

- Причина, почему я вообще дернулся в смену аллокатора - клиенты начали ставить новый Raspbian, а там CONFIG_ARM64_16K_PAGES по-умолчанию включены. Jemalloc с 16кб-страницами по-умолчанию не работает и просто крешится на старте

- У jemalloc есть опция выбора максимального размера страницы, которую нужно постоянно включать при компиляции в environment variables. В случае, если размер страницы меньше, чем заданная, есть небольшая пенальти в работе. У mimalloc никаких опций нет, оно работает плюс-минус всегда одинаково

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

- У mimalloc есть "secure"-режим для параноидальных клиентов, который позволяет обходить известные методы атаки на кучу еще до того, как в системе нашли очередную дырку

- Бинарники с mimalloc примерно на 500kb легче

#tcmalloc пижже - https://www.tgoop.com/itpgchannel/369

(fun fact - так же является аллокатором по умолчанию в двух больших поисковых компаниях!)

Но в выборе между jemalloc и mimalloc, конечно, побеждает mimalloc.

https://www.tgoop.com/tech_b0lt_Genona/4960

Я для себя проблемы #haproxy (а это то еще глюкавое поделие!) решил очень просто - https://github.com/pg83/lab/blob/master/lab/cg.py#L460

Если совсем коротко:

timeout 3600s haproxy

Впрочем, я так решаю не только лишь проблемы с haproxy:

https://www.tgoop.com/itpgchannel/370
https://www.tgoop.com/itpgchannel/2401
https://www.tgoop.com/itpgchannel/2262

#reboot

Мне тут справедливо пишут, что тема "почему #tcmalloc пижже" не раскрыта.

Далее - мой личный OPS опыт, основанный на довольно больших prod backend, и на том, что весь мой дистрибутив Linux работает с tcmalloc.

Если взять N аллокаторов, и M бенчмарков/экспериментов в проде, то окажется, что:

* tcmalloc - почти всегда на втором месте (1)

* почти всегда есть аллокатор лучше, для заданного теста/бенчмарка

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

* нет аллокатора, который бы всегда был первым

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

А если не готовы - то это sane default, потому что смотри пункт (1).

Дальше болтология.

Я, знаете ли, очень верю в hard work, и не очень верю в "классную идею, которая зарулит всех".

Google инвестировал, наверное, сотню человеко-лет в свой аллокатор, он собрал все грабли, и подпер их костыликом, этого ни у кого больше нет, отсюда и следует пункт (1), а это очень важно для sane default.

UPD: сслыка от наших радиослушателей - https://www.tgoop.com/psauxww/1345?comment=25405

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

TL;DR - rust больше не нужен!

💥 Релиз GTA Vice City Nextgen Edition всё-таки состоялся. Можно представить, как морально тяжело для ребят из команды RT прошли последние пару дней после блокировки их канала. Но они довели свою работу до конца, хотя объективно говоря, совсем не известно, чем это может аукнуться в будущем. На наших глазах происходит прецедент в сфере моддинга.

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

Подробнее 👉 https://vk.com/vice_city_2?w=wall-28896333_47190

Вспомнил еще интересный аргумент про #tcmalloc.

Сначала - небольшое лирическое отступление.

В нашей корпоративной монорепе (цифры далее - это очень грубое приближение, надеюсь, я не сильно ошибся в порядках) - 10^5 модулей, 10^6 файлов, и 10^7 "запусков" (условно говоря, сборка объектника или запуск теста), которые мы гоняем в нашем CI, на каждый (!) PR, который идет в эту монорепу. Понятное дело, что там есть ранее отсечение - мы не пересобираем то, что заведомо не может поменяться в проверяемом PR.

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

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

Например, когда мы катим новый clang, то сразу натыкаемся на все багло, которое в него посадили, это сразу видно в CI. Кстати, именно поэтому мы всегда берем версию, которая последняя в своей стабильной ветке, нулевые и первые не берем.

К чему это я?

Когда-то, когда я менял предыдущий дефолт на #tcmalloc, я, для эксперимента, послал в наш CI 3 PR, в каждом из которых менял аллокатор по умолчанию на #tcmalloc, mimalloc, и что-то еще.

В случае tcmalloc PR был "почти зеленый", в остальных PR было прилично посыпавшихся тестов!

Вот, такая вот байка про качество кода tcmalloc.