commit -m "better"
TL;DR - уж не "преттипринтеры для всех", а "а дайте мы тут свою задачу в swift решим, а счастье для всех остальных - завтра".
https://github.com/llvm/llvm-project/commit/9a9c1d4a6155
TL;DR - запилили и вмержили, наверное, этим даже можно попробовать воспользоваться извне swift, если, вдруг, кому надо pretty printers для своих структур данных!
TL;DR - запилили и вмержили, наверное, этим даже можно попробовать воспользоваться извне swift, если, вдруг, кому надо pretty printers для своих структур данных!
GitHub
[lldb] Implement a formatter bytecode interpreter in C++ · llvm/llvm-project@9a9c1d4
Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.
👍7🤔4🥴2🆒1
Forwarded from The After Times
This media is not supported in your browser
VIEW IN TELEGRAM
😁21❤4🐳4👎2💯1
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
Недавно один коллега обратил на это внимание, попробовал обновить и посмотреть на разных бенчмарках, что получится.
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
Forwarded from Ньюсач/Двач
⚡️Путину предложили запретить порно в России. Президент ответил следующее:
Порносайты смотрят во всём мире, потом — котлету заказывают. Это не только наша беда. Нужно предложить альтернативу более интересную, чем порносайты. Чтобы хотелось посмотреть что-то другое.
🐳17💩8👎3😁1🤡1🦄1
Ньюсач/Двач
⚡️Путину предложили запретить порно в России. Президент ответил следующее: Порносайты смотрят во всём мире, потом — котлету заказывают. Это не только наша беда. Нужно предложить альтернативу более интересную, чем порносайты. Чтобы хотелось посмотреть что…
Даже Путину можно про порно, а те, кто наставил каках в https://www.tgoop.com/itpgchannel/2510 - ханжи и снобы!
👍25💩11😁10👎3🍓2❤1🤡1🥴1
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).
29 новых уязвимостей в #gstreamer.
Текст про описание подхода - https://github.blog/security/vulnerability-research/uncovering-gstreamer-secrets/
TL;DR - был использован fuzzer, отдельный интерес представляет то, как коллега строил корпус для фаззинга.
Полагаю, что это только начало, потому что он нашел ошибки только в тех контейнерах, которые он явно таргетировал, а таргетировал он далеко не все, что бывает (mkv/mp4).
www.opennet.ru
В мультимедийном фреймворке GStreamer выявлено 29 уязвимостей
В мультимедийном фреймворке GStreamer, используемом в GNOME, выявлено 29 уязвимостей. Восемь уязвимостей приводят к записи данных за пределы буфера, а одна (CVE-2024-47540) к перезаписи указателя на функцию. Указанные уязвимости могут потенциально использоваться…
🔥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 года не нашлось ни пользователей, ни разработчиков.
TL;DR - из libcurl удаляют альтернативный HTTP/1 backend, основанный на https://hyper.rs/ (
Почему?
Оказалось, что никому не нужно, за 4 года не нашлось ни пользователей, ни разработчиков.
daniel.haxx.se
dropping hyper
The ride is coming to an end. The experiment is done. We tried, but we admit defeat. Four years ago we started adding support for an alternative HTTP backend in curl. It would use a library written in rust, called hyper. The idea was to introduce an alternative…
🤷♂8🔥6😁4❤3👍3🤔2👌2🐳2🌚2
Forwarded from Записки CPU designer'a (Николай)
Qualcomm выигрывает судебное дело по лицензионному конфликту с Arm
Вкратце, из-за чего Arm решила судиться с Qualcomm:
Об этом я рассуждал в одном из старых постов почему RISC-V становится все востребованне и актуальнее из-за концепции свободной ISA.
Какой суд вынес вердикт?
Судебное решение подтвердило, что Qualcomm не нарушала лицензионное соглашение с Arm, приобретя Nuvia. Это позволяет Qualcomm продолжать использовать технологии Arm для разработки чипов, включая процессоры Oryon и Snapdragon X. Однако неопределённость остаётся: суд не вынес решения о том, нарушила ли Nuvia свои обязательства перед Arm. Это открывает возможность для повторного разбирательства, что в итоге может привести к новым попыткам пересмотра условий лицензирования.
Я только рад, что нас ждет только больше ARM чипов для декстопных решений.
Thinkpad же активно выпускает ноутбуки на базе ARM-чипов, что особенно круто для батарейной электроники. Однако пока что программная экосистема и совместимость с x86-приложениями оставляют желать лучшего.
Когда-нибудь дождёмся переноса EDA для проектирования ASIC на 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
The Verge
Qualcomm wins a legal battle over Arm chip licensing
The jury delivered a win for Qualcomm with a split verdict.
👍9🐳4❤2
Как-то обсуждали, что fish shell перепишут на Rust - https://www.tgoop.com/it_pg_talks/20668
И, пожалуйста, переписали - https://github.com/fish-shell/fish-shell/releases/tag/4.0b1 (ну, не все, но большую часть, ладно).
Но зато закрыли тикет про то, что в fish shell не хватает
Как без этого можно вообще писать серьезные скрипты, я не знаю.
Но точно знаю, что "переписывать на Rust" явно больше fun, чем пилить какие-то продуктовые фичи.
И, пожалуйста, переписали - 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, чем пилить какие-то продуктовые фичи.
Telegram
АртЁм in commit -m "better chat"
-hey did you hear the good news? fish our beloved shell is finally making the move, to rust!
-but aren't they going to change the name to crabshell then? (c)
-but aren't they going to change the name to crabshell then? (c)
😁21👍9💩4👎3🗿2❤1
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 иногда выигрывает на копеечку, но регулярно сливает в разы, на определенных нагрузках.
Заметка от Миши с фороникса, про то, что не надо использовать васянские сборки ядра 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 иногда выигрывает на копеечку, но регулярно сливает в разы, на определенных нагрузках.
Phoronix
Liquorix vs. Linux 6.12 Upstream Kernel Performance Across Many Workloads
A Phoronix Premium subscriber a while back requested some fresh benchmarks of how the Liquorix downstream of the Linux kernel is comparing against the latest upstream kernel..
👍14
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(), а асинхронно - это какой-то леденящий душу пиздец!
"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
commit -m "better"
Ну и, конечно, очень приятно, что это не kernel panic, а вполне себе падение user space приложухи, которую можно перезапустить.
#sched_ext
История из серии "очумелые ручки".
В какой-то момент экспериментов с scx, я решил, что надо запускать userspace часть с каким-нибудь RT приоритетом, потому что решения про шедулинг - это важно, и нужно уметь получать их за предсказуемое время, да же?
Вот, сделал запуск через
И получил моментальный freeze всей системы, такие дела.
Так же попробовал bpfland, вместо rustland - по словам авторов, это то же самое, что и rustland, но полностью в ядре, в виде #ebpf программы https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_bpfland/README.md.
Работает оно довольно стабильно, но, к сожалению, отзывчивость GUI оно только ухудшает, артефакты заметны невооруженным взглядом.
Мне интересно, в каких условиях вообще возможно воспроизвести предполагаемый результат?
История из серии "очумелые ручки".
В какой-то момент экспериментов с 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 оно только ухудшает, артефакты заметны невооруженным взглядом.
Мне интересно, в каких условиях вообще возможно воспроизвести предполагаемый результат?
GitHub
ix/pkgs/bin/scx/rust/land/runit/ix.sh at main · pg83/ix
ix package manager. Contribute to pg83/ix development by creating an account on GitHub.
❤5👍3🔥3🤔1🥱1🆒1