Warning: Undefined array key 0 in /var/www/tgoop/function.php on line 65

Warning: Trying to access array offset on value of type null in /var/www/tgoop/function.php on line 65
2520 - Telegram Web
Telegram Web
Forwarded from Loser story
В ydb используется google tcmalloc, well, он примерно двухлетней давности.
Недавно один коллега обратил на это внимание, попробовал обновить и посмотреть на разных бенчмарках, что получится.
Memory usage упал в tcp-c упал аж на 15%, но латенси стало похуже.

Меня заинтересовало, что метрика того сколько занимают tcmalloc кеши изменилась довольно значительно, не только по размеру (как раз те 15%) но и по форме (став меняться динамически).

Я довольно давно не следил за tcmalloc репой (примерно с тех времён как они рассказывали как сделали большие аллокации huge page aware, 21~ год).
Ну и думал придется покопаться в их коммитах чтобы найти что такого в кешах они поменяли.

Но в процессе поиска наткнулся на то что недавно, они написали статью как меняли tcmalloc на скейле гугла последние два года.

https://zzhou612.com/publication/2024-asplos-malloc/2024-asplos-malloc.pdf

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

Но если приводить TLDR, то
1) Взяли больших потребителей внутри гугла (spanner, f1, bigtable, etc) и пару внешних отличающихся workload-ов (redis, tensor flow, etc)
2) Начали все это активно и по разному мерять (a/b тесты, continues profiling, etc)
3) На каждом уровне кеширования нашли определеные проблемы
4) Получили средний профит на своих ворклоадах уровне: 3.5% по памяти, 1.5% по пропускной способности
5) Ещё интересно что как и с большинством идей из tcmalloc многие из этих можно переиспользовать в других аллокаторах

Ещё наверное интересно, что это показывает в какой-то степени насколько general-purpose аллокаторы (jemalloc, tcmalloc-и, может быть mimalloc) сложно сделать лучше чем сейчас.
Не потому что нельзя под конкретный ворклоад написать аллокатор быстрее в 2 раза, а потому что это замедлит другие юзкейсы.

Резюмируя кажется то что я искал, они называют "Heterogeneous per-CPU cache"
собственно включение которого у нас нет https://github.com/google/tcmalloc/commit/2407bb02b75ba00fd066bd5730a42cd319c303b0
сам код
https://github.com/google/tcmalloc/commit/691f9f62affb27764db8ca26f27159172c439001
🔥28
😁20🐳43
💩21😁93👏2🐳2🌚2
commit -m "better"
Photo
This media is not supported in your browser
VIEW IN TELEGRAM
💯46😁8💩41
Forwarded from Ньюсач/Двач
⚡️Путину предложили запретить порно в России. Президент ответил следующее:

Порносайты смотрят во всём мире, потом — котлету заказывают. Это не только наша беда. Нужно предложить альтернативу более интересную, чем порносайты. Чтобы хотелось посмотреть что-то другое.
🐳17💩8👎3😁1🤡1🦄1
😁61😱165
https://www.opennet.ru/opennews/art.shtml?num=62441

29 новых уязвимостей в #gstreamer.

Текст про описание подхода - https://github.blog/security/vulnerability-research/uncovering-gstreamer-secrets/

TL;DR - был использован fuzzer, отдельный интерес представляет то, как коллега строил корпус для фаззинга.

Полагаю, что это только начало, потому что он нашел ошибки только в тех контейнерах, которые он явно таргетировал, а таргетировал он далеко не все, что бывает (mkv/mp4).
🔥15👍5🆒3
https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

TL;DR - из libcurl удаляют альтернативный HTTP/1 backend, основанный на https://hyper.rs/ (кстати, не открывается у меня без VPN, наверное, очередная контора пидорасов! Нет, просто они не осилили QUIC)

Почему?

Закончились деньги из гранта.

Оказалось, что никому не нужно, за 4 года не нашлось ни пользователей, ни разработчиков.
🤷‍♂8🔥6😁43👍3🤔2👌2🐳2🌚2
Forwarded from Записки CPU designer'a (Николай)
Qualcomm выигрывает судебное дело по лицензионному конфликту с Arm

Вкратце, из-за чего Arm решила судиться с Qualcomm:

TLDR: Qualcomm поглотила компанию Nuvia и решила воспользоваться лицензиями ARM, поглощенной компании.
Но в удивительном и прекрасном полупроводниковом бизнесе (и не только) цена на лицензию устанавливается в том числе от того, что за компания запрашивает лицензию.
Видимо, ARM решила, что Qualcomm пытаются считерить с лицензионным соглашением, выдав лицензию Nuvia за свою, а Qualcomm в свою очередь, считает. что имеет права не только на интеллектуальную собственность купленной компании, но и на лицензии. Кто прав тут - скоро увидим в суде

Об этом я рассуждал в одном из старых постов почему RISC-V становится все востребованне и актуальнее из-за концепции свободной ISA.

Какой суд вынес вердикт?

Судебное решение подтвердило, что Qualcomm не нарушала лицензионное соглашение с Arm, приобретя Nuvia. Это позволяет Qualcomm продолжать использовать технологии Arm для разработки чипов, включая процессоры Oryon и Snapdragon X. Однако неопределённость остаётся: суд не вынес решения о том, нарушила ли Nuvia свои обязательства перед Arm. Это открывает возможность для повторного разбирательства, что в итоге может привести к новым попыткам пересмотра условий лицензирования.

Я только рад, что нас ждет только больше ARM чипов для декстопных решений.
Thinkpad же активно выпускает ноутбуки на базе ARM-чипов, что особенно круто для батарейной электроники. Однако пока что программная экосистема и совместимость с x86-приложениями оставляют желать лучшего.

Когда-нибудь дождёмся переноса EDA для проектирования ASIC на ARM-машины, дождёмся же?👀👀👀

Схожее мнение и у автора канала Паразитное сопротивление. Для полноты картины рекомендую ознакомиться и с его постом — клик.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🐳42
Как-то обсуждали, что fish shell перепишут на Rust - https://www.tgoop.com/it_pg_talks/20668

И, пожалуйста, переписали - https://github.com/fish-shell/fish-shell/releases/tag/4.0b1 (ну, не все, но большую часть, ладно).

Но зато закрыли тикет про то, что в fish shell не хватает set -e, то есть, выхода, когда какая-то команда завершилась с ошибкой - https://github.com/fish-shell/fish-shell/issues/510

Как без этого можно вообще писать серьезные скрипты, я не знаю.

Но точно знаю, что "переписывать на Rust" явно больше fun, чем пилить какие-то продуктовые фичи.
😁21👍9💩4👎3🗿21
https://www.phoronix.com/news/Linux-6.12-Liquorix-Performance

Заметка от Миши с фороникса, про то, что не надо использовать васянские сборки ядра Linux, потому что получается плохо.

"On a geo mean basis across all of the benchmarks, the upstream kernel ended up being faster by 21%"

https://openbenchmarking.org/result/2412205-PTS-LIQUORIX70&sgm=1&swl=1 - вот тут вот особенно хорошо видно, что Liquorix иногда выигрывает на копеечку, но регулярно сливает в разы, на определенных нагрузках.
👍14
😁52🤣112🔥1🙈1
https://lwn.net/SubscriberLink/1002371/0ff2be6a2c7624ca/

"Process creation in io_uring"

Пишут про добавление clone() в #io_uring.

Я, даже не читая текст, закатил глаза, и подумал "#ebpf", потому что это очень разумно - загрузить через io_uring программу, которая сделает необходимый setup, и позовет clone()

(вообще, напомню в данном контексте свой текст от 21 года - https://www.tgoop.com/itpgchannel/56)

И, пожалуйста, первый же комментарий про это - https://lwn.net/Articles/1003051/

Но, в целом, этот текст (и дикуссия по ссылкам) не дает ответа на самый главный вопрос - а какая семантика у асинхронного clone()?

Тут же основная проблема - а что происходит, если clone() реально происходит хз когда, когда программа имеет неизвестное состояние блокировок/открытых fd/memory maps и так далее?

Синхронно-то сложно обеспечить нормальное окружение для clone(), а асинхронно - это какой-то леденящий душу пиздец!
👍12🔥5🤔4🆒2🤯1
Forwarded from Блог*
😁47🔥6🐳6💅4🗿3🦄3👍1
Forwarded from Above all that is random
😁32
commit -m "better"
Ну и, конечно, очень приятно, что это не kernel panic, а вполне себе падение user space приложухи, которую можно перезапустить.
#sched_ext

История из серии "очумелые ручки".

В какой-то момент экспериментов с scx, я решил, что надо запускать userspace часть с каким-нибудь RT приоритетом, потому что решения про шедулинг - это важно, и нужно уметь получать их за предсказуемое время, да же?

Вот, сделал запуск через chrt -f 1 - https://github.com/pg83/ix/blob/main/pkgs/bin/scx/rust/land/runit/ix.sh#L5

И получил моментальный freeze всей системы, такие дела.

Так же попробовал bpfland, вместо rustland - по словам авторов, это то же самое, что и rustland, но полностью в ядре, в виде #ebpf программы https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_bpfland/README.md.

Работает оно довольно стабильно, но, к сожалению, отзывчивость GUI оно только ухудшает, артефакты заметны невооруженным взглядом.

Мне интересно, в каких условиях вообще возможно воспроизвести предполагаемый результат?
5👍3🔥3🤔1🥱1🆒1
2025/07/09 05:14:48
Back to Top
HTML Embed Code: