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

Вот, простая и понятная демонстрация мысли про то, что Linux-у останется роль POSIX подсистемы и FS в каких-нибудь нормальных OS.

Заголовок новости врет, там, конечно, не "RTOS на Rust как Linux subsystem", а "Linux запущен как процесс в RTOS на Rust, для обеспечения POSIX слоя". Потому что иначе обеспечить гарантии RTOS просто невозможно.

Спутником управляет надежный код на Rust (хорошо, что не очередное поделие на C), Linux обеспечивают "удобный gui для админа" (ну или там ssh, неважно).

Туда ему и дорога.

https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default #gold #LTO #perf

В ubutu включили -fno-omit-frame-pointer для 64 битных систем, по умолчанию.

Хорошая новость, из разряда "долго тупили, но опомнились, и сделали по уму".

Много раз писал, и буду писать, что вам, в среднем, не нужны оптимизации "последних 5% перфа", которые сильно усложняют отладку, и ухудшают время сборки:

- LTO. Коллеги, если вы включаете LTO в своих сборках, то вы подписываетесь на то, что будете регулярно чинить проблемы, которые просто не возникают у других людей. По двум причинам:

* Вы начинаете использовать код, который используется меньше, чем 1% пользователей вашего компилятора. Этот код хуже отлажен, в нем больше багов, он чаще будет генерить некорректный код в результате.

* Вы подвергаете свою кодовую базу стрессу, который мог совсем не предполагаться теми, кто пишет весь остальной код в вашем репозитории. Представьте себе монорепу, в которой вы пишете маленькую программу, она использует кучу библиотек из монорепы, и вы решили собрать ее с LTO. Вы наложили новый контракт на используемый вами код, и его никто не будет соблюдать, кроме вас.

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

Людям, которые принимают решение о выкатке кода в прод, дам совет. Если вам кто-то приносит 5% перфа, полученного за счет LTO, шлите его в хуй, спросите, за чей счет банкет, и кто будет этот код обслуживать дальше, и чинить всякие веселые баги в компиляторе, и в вашей кодовой базе. Это совершенно не бесплатные 5%, вы за них будете платить все время жизни вашего софта.

LTO имеет смысл для браузера, который собирается и отлаживается очень большой командой, и используется много кем.

Твоей программе, username, он не нужен.

- fomit-frame-pointer. Отладка затрудняется, корки совершенно бессмысленные, стектрейсы для записи в лог стоят дорого. Современные компиляторы сводят ущерб от frame pointer к минимуму.

Я иду дальше, и запрещаю UB в следующих случаях:

https://github.com/pg83/ix/blob/main/pkgs/lib/build/opt/safe/ix.sh#L4

Да, я отключаю UB в переполнениях с целыми числами, и выключаю strict aliasing.

Желающие отлаживать всякие интересные (нет) корки могут себе это отключить, на всю систему, или на отдельный пакет.

Не на правах рекламы.

https://iina.io/
https://github.com/iina/iina

Нормальный медиаплеер для macOS, и не богомерзкий (потому что плюгин на плюгине и плюгином погоняет) VLC!

GUI над mpv, на кошерном swift (выглядит как "настоящее" приложение под macOS), красота, да и только!

Удивительно, репе 7 лет, а я узнал про этот плеер всего неделю назад.

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

Первый сетевой драйвер на #Rust в ядре. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=cbe0e415089636170aa6eb540ca4af5dc9842a60

Ажно 135 строк кода, 134 из которых - взаимодействие с остальным ядром, ничего интересного, проходим мимо.

Зато классный срачик на похорониксе - https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1429237-the-first-rust-written-network-phy-driver-set-to-land-in-linux-6-8

Коллеги спорят, можно ли писать "боевой" код на С, или нельзя.

Это, очевидно, instance of https://ru.wikipedia.org/wiki/%D0%9D%D0%B8_%D0%BE%D0%B4%D0%B8%D0%BD_%D0%B8%D1%81%D1%82%D0%B8%D0%BD%D0%BD%D1%8B%D0%B9_%D1%88%D0%BE%D1%82%D0%BB%D0%B0%D0%BD%D0%B4%D0%B5%D1%86, поэтому принимать участие в этом обсуждении я не вижу никакого смысла, только скажу, что писать надежный код на С - запредельно дорого.

https://github.com/CuarzoSoftware/Louvre/releases/tag/v1.1.0-1

Чувак прямо как услышал меня:

License updated from GPLv3 to MIT.

Еще одна причина посмотреть на библиотеку внимательнее.

#llvmweekly

https://github.com/llvm/llvm-project/commit/f7407411a1da

Прикольная оптимизация для deque-подобных контейнеров (это когда контейнер состоит из указателей на сегменты, в которых уже и хранятся реальные элементы) - а давайте std::find будет работать не через ++it (который очень дорогая операция, потому что надо проверять, не в конце ли мы сегмента, и прыгать в начало следующего), а как бы знать, что контейнер состоит из сегментов, и поиск внутри сегмента делать более эффективно.

Вот надо еще inplace sort так оптимизировать, чтобы блоки для сортировки (и последующего слияния, например) совпали с сегментами деки, стало бы совсем хорошо.

.

https://lwn.net/SubscriberLink/954787/41470c731eda02a4/

#gccrs

rust in gcc стагнирует, и далек даже от того состояния, в котором сейчас находится #mrustc. mrustc уже умеет в 1.54, а вот эти вот товарищи пытаются в 1.49, да и то, там конь еще не валялся.

https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=GCC+Rust+Update.pdf

Пролистал слайды про устройство proc macro в gccrs, смерть смерть кладбище, тоска, они собираются точно так же динамически линковать и загружать .so, как это сейчас делает rustc.

А, значит, они мне совершенно бесполезны.

https://www.opennet.ru/opennews/art.shtml?num=60317
https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/

"Использование SSH поверх UNIX-сокета вместо sudo для избавления от #suid-файлов"

Видимо, это не такое уж и безумие, раз пришло в голову не только мне?

(напомню, что я ровно в таком setup живу с самого первого boot в #stal/#ix, по модулю того, что так и не удосужился настроить UDS, вместо сетевого порта)

Тут вот в тележеньке появилась кнопка "похожие каналы". Ну или не появилась, а я просто слоупок.

Вот, два самых похожих на мой канала.

Мне тут почему-то вспоминается анекдот про ВМиК:

- Подскажите, как пройти до ВМК?
- Это где-то между МехМат-ом и цирком, немного ближе к цирку!

https://nickb.dev/blog/the-dark-side-of-inlining-and-monomorphization/ #perf

Зумеры, в очередной раз, переизобретают и переописывают то, что всем заинтересованным людям давно известно - чрезмерный inline-инг (современное его название - мономорфизация, но кому какое дело?) - не только полезно, но и очень вредно.

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