commit -m "better"
Кстати, несмотря на то, что я перешел на 19 clang, я так и не перешел на 19-ую libc++. Они там знатно наломали дров, какое-то очень большое количества софта сломали.
Будни #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
После этого все прошло более-менее нормально.
У меня по этой задаче (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
После этого все прошло более-менее нормально.
GitHub
ix/pkgs/lib/c++/19/patched/0.diff at main · pg83/ix
ix package manager. Contribute to pg83/ix development by creating an account on GitHub.
👍10🐳7❤3🤡3🤮1🥱1
commit -m "better"
Свежую драму от Кента подвезли. Читаешь, думаешь, блин, несправедливо человека банят:
#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
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
Phoronix
Bcachefs Changes Merged Without Issue For The Linux 6.14 Kernel
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
👍9😁3🔥2🤮2💩1🤡1
commit -m "better"
https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.html
Что-то вроде годового self assessment одного из разрабов LLVM.
Что-то вроде годового self assessment одного из разрабов LLVM.
Очередной 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.
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.
👍10🤡7❤2
commit -m "better"
#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…
В обсуждении на похорониксе наткнулся прямо на маленький монументальный пост от автора 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.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"
...
Phoronix Forums
Bcachefs Changes Merged Without Issue For The Linux 6.14 Kernel -
Phoronix Forums
Phoronix Forums
Phoronix: Bcachefs Changes Merged Without Issue For The Linux 6.14 Kernel
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…
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…
😁17🤡7🔥2🤔1
commit -m "better"
В обсуждении на похорониксе наткнулся прямо на маленький монументальный пост от автора 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…
www.opennet.ru
Заметки Теодора Тс'о о ядре Linux, кодексе поведения, ext4, btrfs и ZFS
Перевод размышлений Теодора Тс'о (Theodore Ts'o), создателя файловой системы Ext4, о разработке ext4, файловой системе BcacheFS, ядре Linux, ZFS, кодексе поведения и файловых системах в целом:
😁10🌚7❤4👍3🤡3⚡2
https://www.phoronix.com/news/AMD-AMDGPU-Composition-Stack
AMD форкнули Weston (это такой THE Wayland Compositor), и будут его допиливать, используя как демонстрацию возможностей своих видеокарт.
Интересно, зачем это им? Они поверили в Linux на desktop?
AMD форкнули Weston (это такой THE Wayland Compositor), и будут его допиливать, используя как демонстрацию возможностей своих видеокарт.
Интересно, зачем это им? Они поверили в Linux на desktop?
Phoronix
AMD Announces The AMDGPU Composition Stack "ACS" For Advanced Linux Desktop Features
An unexpected surprise today are AMD Linux software engineers announcing a new project a bit further outside the scope of their open-source graphics drivers..
👍12😁6❤4🌚3🔥2🤔1🤡1
Segment@tion fault
Одним из своих первых указов, Дональд Трамп отменил Agile.
https://www.reddit.com/r/rust/comments/1i7m431/whitehouse_press_release_future_software_should/
Гля чо пишут, оказывается, Трамп отменил не только лишь Agile, но и то, что "весь новый код надо пистаь на memory safe языках"!
Наш слоняра!
Гля чо пишут, оказывается, Трамп отменил не только лишь Agile, но и то, что "весь новый код надо пистаь на memory safe языках"!
Наш слоняра!
Reddit
From the rust community on Reddit
Explore this post and more from the rust community
😁40❤8🔥4🤡4🤔3🐳1
Forwarded from /dev/stdout (direktor interneta)
очередной день когда я указываю эту почту для отправки чека в кфс
😁116🔥11🤡10🤔6💩4💯2🦄1🤷1
Forwarded from Ряды Фурье
У нас тут в чате в какой-то момент случился интересный диалог, который начался на "Любому вменяемому человеку очевидно". Как это ни странно, у любого вменяемого человека эта фраза вызывает желание ушатать. С вертушки в щщи.
До III века любому вменяемому человеку было ясно, что Солнце вращается вокруг Земли. Причём до V века Земля была плоской. У тех, кто так не считал, знатно подгорало.
Большим сюрпризом для вменяемых людей оказалось, что наследственная информация хранится в молекулах ДНК. Потому что это же трындец как нерационально в каждой клетке держать полную сборочную инструкцию для всего человека. Ещё вменяемые люди не знали, что гены могут брать и перепрыгивать между видами горизонтальным переносом. Зато вменяемые люди короткое время знали, что память может храниться в РНК и передаваться между организмами.
Потом не каждому вменяемому человеку было очевидно, что большинство клеток нашего тела — бактериальные. Да, по массе это меньше, чем полкило, но по количеству их чуть больше человеческих.
Вменяемые люди не считали, что электроны могут быть в двух и более местах одновременно. Потом вменяемым людям казалось, что электрон — это вероятностное поле. Новое поколение вменяемых людей вообще считает их множителями.
Казалось нереальным, что птица или оса может использовать магнитное поле Земли для навигации.
Казалось нереальным, что наша память не имеет операции чтения (есть только уничтожающее чтение + перезапись заново).
Гравитация когда-то считалась силой.
И вот до совсем недавних пор было очевидно, что килограмм — это не единица энергии.
Вот вам ещё высказывания: растения не умеют считать и не обладают интеллектом; энтропия не может уменьшаться локально; мозг не регенерирует; гены не управляются внешней средой; сознание не влияет на клеточное здоровье; крокодил больше длинный, чем зелёный — все эти утверждения надо проверять.
Наука — это про то, что всем вменяемым людям без исключения очевидно, что хочется ушатывать тем, кто использует квантор общности для дешёвых манипуляций )
--
Вступайте в ряды Фурье! Любому вменяемому человеку очевидно, чтоатом похож на Солнечную систему. Только меньше и вообще другой!
До III века любому вменяемому человеку было ясно, что Солнце вращается вокруг Земли. Причём до V века Земля была плоской. У тех, кто так не считал, знатно подгорало.
Большим сюрпризом для вменяемых людей оказалось, что наследственная информация хранится в молекулах ДНК. Потому что это же трындец как нерационально в каждой клетке держать полную сборочную инструкцию для всего человека. Ещё вменяемые люди не знали, что гены могут брать и перепрыгивать между видами горизонтальным переносом. Зато вменяемые люди короткое время знали, что память может храниться в РНК и передаваться между организмами.
Потом не каждому вменяемому человеку было очевидно, что большинство клеток нашего тела — бактериальные. Да, по массе это меньше, чем полкило, но по количеству их чуть больше человеческих.
Вменяемые люди не считали, что электроны могут быть в двух и более местах одновременно. Потом вменяемым людям казалось, что электрон — это вероятностное поле. Новое поколение вменяемых людей вообще считает их множителями.
Казалось нереальным, что птица или оса может использовать магнитное поле Земли для навигации.
Казалось нереальным, что наша память не имеет операции чтения (есть только уничтожающее чтение + перезапись заново).
Гравитация когда-то считалась силой.
И вот до совсем недавних пор было очевидно, что килограмм — это не единица энергии.
Вот вам ещё высказывания: растения не умеют считать и не обладают интеллектом; энтропия не может уменьшаться локально; мозг не регенерирует; гены не управляются внешней средой; сознание не влияет на клеточное здоровье; крокодил больше длинный, чем зелёный — все эти утверждения надо проверять.
Наука — это про то, что всем вменяемым людям без исключения очевидно, что хочется ушатывать тем, кто использует квантор общности для дешёвых манипуляций )
--
Вступайте в ряды Фурье! Любому вменяемому человеку очевидно, что
👍27❤15🤡10🔥3🥱3🆒2🤔1🐳1
Ряды Фурье
У нас тут в чате в какой-то момент случился интересный диалог, который начался на "Любому вменяемому человеку очевидно". Как это ни странно, у любого вменяемого человека эта фраза вызывает желание ушатать. С вертушки в щщи. До III века любому вменяемому…
Между прочим, один из трех (вроде) каналов, на которые я подписан основным аккаунтом в телеге!
👍11🥱6🤷4❤2
Forwarded from Segment@tion fault
Внезапно перевел все наши продукты с jemalloc на mimalloc.
Битва аллокаторов - вечный холивар, расскажу свои соображения, а вы добавьте в комментариях.
- Причина, почему я вообще дернулся в смену аллокатора - клиенты начали ставить новый Raspbian, а там CONFIG_ARM64_16K_PAGES по-умолчанию включены. Jemalloc с 16кб-страницами по-умолчанию не работает и просто крешится на старте
- У jemalloc есть опция выбора максимального размера страницы, которую нужно постоянно включать при компиляции в environment variables. В случае, если размер страницы меньше, чем заданная, есть небольшая пенальти в работе. У mimalloc никаких опций нет, оно работает плюс-минус всегда одинаково
- Оба аллокатора я уже не раз гонял в работе, они используют похожие алгоритмы, но по-разному имплементированные. В результате, одни задачи могут быть быстрее на jemalloc, другие - на mimalloc, но в среднем всё будет одинаково и разницу не заметите. На моих задачах mimalloc всё же дает плюс в пару %
- У mimalloc есть "secure"-режим для параноидальных клиентов, который позволяет обходить известные методы атаки на кучу еще до того, как в системе нашли очередную дырку
- Бинарники с mimalloc примерно на 500kb легче
Битва аллокаторов - вечный холивар, расскажу свои соображения, а вы добавьте в комментариях.
- Причина, почему я вообще дернулся в смену аллокатора - клиенты начали ставить новый Raspbian, а там CONFIG_ARM64_16K_PAGES по-умолчанию включены. Jemalloc с 16кб-страницами по-умолчанию не работает и просто крешится на старте
- У jemalloc есть опция выбора максимального размера страницы, которую нужно постоянно включать при компиляции в environment variables. В случае, если размер страницы меньше, чем заданная, есть небольшая пенальти в работе. У mimalloc никаких опций нет, оно работает плюс-минус всегда одинаково
- Оба аллокатора я уже не раз гонял в работе, они используют похожие алгоритмы, но по-разному имплементированные. В результате, одни задачи могут быть быстрее на jemalloc, другие - на mimalloc, но в среднем всё будет одинаково и разницу не заметите. На моих задачах mimalloc всё же дает плюс в пару %
- У mimalloc есть "secure"-режим для параноидальных клиентов, который позволяет обходить известные методы атаки на кучу еще до того, как в системе нашли очередную дырку
- Бинарники с mimalloc примерно на 500kb легче
👏9👍7🔥4🤡3❤1
Segment@tion fault
Внезапно перевел все наши продукты с jemalloc на mimalloc. Битва аллокаторов - вечный холивар, расскажу свои соображения, а вы добавьте в комментариях. - Причина, почему я вообще дернулся в смену аллокатора - клиенты начали ставить новый Raspbian, а там…
#tcmalloc пижже - https://www.tgoop.com/itpgchannel/369
(fun fact - так же является аллокатором по умолчанию в двух больших поисковых компаниях!)
Но в выборе между jemalloc и mimalloc, конечно, побеждает mimalloc.
(fun fact - так же является аллокатором по умолчанию в двух больших поисковых компаниях!)
Но в выборе между jemalloc и mimalloc, конечно, побеждает mimalloc.
Telegram
commit -m "better"
#allocator #tcmalloc #mimalloc
Давеча писал про свой дефолтный аллокатор, и про то, что это, во многом, эмоциональное решение.
Короче, я привел свои эмоции в соответствие реальности, и перешел на tcmalloc по дефолту.
* https://git.sr.ht/~pg/mix/tree/m…
Давеча писал про свой дефолтный аллокатор, и про то, что это, во многом, эмоциональное решение.
Короче, я привел свои эмоции в соответствие реальности, и перешел на tcmalloc по дефолту.
* https://git.sr.ht/~pg/mix/tree/m…
👍9😁5🤡2🆒1
https://www.tgoop.com/tech_b0lt_Genona/4960
Я для себя проблемы #haproxy (а это то еще глюкавое поделие!) решил очень просто - https://github.com/pg83/lab/blob/master/lab/cg.py#L460
Если совсем коротко:
Впрочем, я так решаю не только лишь проблемы с haproxy:
https://www.tgoop.com/itpgchannel/370
https://www.tgoop.com/itpgchannel/2401
https://www.tgoop.com/itpgchannel/2262
#reboot
Я для себя проблемы #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
Telegram
Технологический Болт Генона
Ранее я писал о баге Haproxy: после рестарта треды не завершались, что приводило к их накоплению, память иссякала и приходил OOM Killer.
Проблему решали костылем — директива hard-stop-after принудительно завершает треды после рестарта.
Но Haproxy не сдается…
Проблему решали костылем — директива hard-stop-after принудительно завершает треды после рестарта.
Но Haproxy не сдается…
👍7😁5🤡2🆒1
commit -m "better"
пижже
Мне тут справедливо пишут, что тема "почему #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
Далее - мой личный 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
Telegram
Loyd in E = mc² + AI
Поделюсь и своим опытом по теме современных аллокаторов.
Мы тоже используем mimalloc как дефолт. Но без secure, на некоторых бенчах сильно больше 10% может резать.
Однако лучшим general-purpose аллокатором я считаю гугловый tcmalloc у которого есть важная…
Мы тоже используем mimalloc как дефолт. Но без secure, на некоторых бенчах сильно больше 10% может резать.
Однако лучшим general-purpose аллокатором я считаю гугловый tcmalloc у которого есть важная…
👍19🔥6🆒4❤2
Forwarded from Alexander PolyAK | GTA
💥 Релиз GTA Vice City Nextgen Edition всё-таки состоялся. Можно представить, как морально тяжело для ребят из команды RT прошли последние пару дней после блокировки их канала. Но они довели свою работу до конца, хотя объективно говоря, совсем не известно, чем это может аукнуться в будущем. На наших глазах происходит прецедент в сфере моддинга.
Ну а пока, мы можем испытать совершенно новый игровой опыт. Игра уже готова к использованию и никаких предварительных установок не нужно. С одной стороны, это можно осудить, с другой стороны, по их же словам, до блокировки канала они собирались сделать необходимым наличие лицензионной игры, из уважения к издателю. И можете сами догадаться, почему эти планы изменились.
Подробнее 👉 https://vk.com/vice_city_2?w=wall-28896333_47190
Ну а пока, мы можем испытать совершенно новый игровой опыт. Игра уже готова к использованию и никаких предварительных установок не нужно. С одной стороны, это можно осудить, с другой стороны, по их же словам, до блокировки канала они собирались сделать необходимым наличие лицензионной игры, из уважения к издателю. И можете сами догадаться, почему эти планы изменились.
Подробнее 👉 https://vk.com/vice_city_2?w=wall-28896333_47190
🤩15🥱7👍5🤡2❤1👎1
commit -m "better"
Мне тут справедливо пишут, что тема "почему #tcmalloc пижже" не раскрыта.
Вспомнил еще интересный аргумент про #tcmalloc.
Сначала - небольшое лирическое отступление.
В нашей корпоративной монорепе (цифры далее - это очень грубое приближение, надеюсь, я не сильно ошибся в порядках) - 10^5 модулей, 10^6 файлов, и 10^7 "запусков" (условно говоря, сборка объектника или запуск теста), которые мы гоняем в нашем CI, на каждый (!) PR, который идет в эту монорепу. Понятное дело, что там есть ранее отсечение - мы не пересобираем то, что заведомо не может поменяться в проверяемом PR.
Этим делом в полку загружено несколько тысяч вполне современных серверов.
При таких масштабах всякие проблемы, которые обычно незаметны, всплывают сразу.
Например, когда мы катим новый clang, то сразу натыкаемся на все багло, которое в него посадили, это сразу видно в CI. Кстати, именно поэтому мы всегда берем версию, которая последняя в своей стабильной ветке, нулевые и первые не берем.
К чему это я?
Когда-то, когда я менял предыдущий дефолт на #tcmalloc, я, для эксперимента, послал в наш CI 3 PR, в каждом из которых менял аллокатор по умолчанию на #tcmalloc, mimalloc, и что-то еще.
В случае tcmalloc PR был "почти зеленый", в остальных PR было прилично посыпавшихся тестов!
Вот, такая вот байка про качество кода tcmalloc.
Сначала - небольшое лирическое отступление.
В нашей корпоративной монорепе (цифры далее - это очень грубое приближение, надеюсь, я не сильно ошибся в порядках) - 10^5 модулей, 10^6 файлов, и 10^7 "запусков" (условно говоря, сборка объектника или запуск теста), которые мы гоняем в нашем CI, на каждый (!) PR, который идет в эту монорепу. Понятное дело, что там есть ранее отсечение - мы не пересобираем то, что заведомо не может поменяться в проверяемом PR.
Этим делом в полку загружено несколько тысяч вполне современных серверов.
При таких масштабах всякие проблемы, которые обычно незаметны, всплывают сразу.
Например, когда мы катим новый clang, то сразу натыкаемся на все багло, которое в него посадили, это сразу видно в CI. Кстати, именно поэтому мы всегда берем версию, которая последняя в своей стабильной ветке, нулевые и первые не берем.
К чему это я?
Когда-то, когда я менял предыдущий дефолт на #tcmalloc, я, для эксперимента, послал в наш CI 3 PR, в каждом из которых менял аллокатор по умолчанию на #tcmalloc, mimalloc, и что-то еще.
В случае tcmalloc PR был "почти зеленый", в остальных PR было прилично посыпавшихся тестов!
Вот, такая вот байка про качество кода tcmalloc.
👍26🔥6🤡3🤮1🥱1