1.83K subscribers
3.3K photos
131 videos
15 files
3.57K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
Блог*
#music youtube.com/watch?v=abBW51X-x-w
Если вам это понравилось, то вот вам ещё #music подобного плана.

youtube.com/watch?v=U4GXNzom6ik
👍5🥰1💩1🤡1
#meme про траву и клещей
16😁1
5🌚3👍1
😁286👍1🤡1
#prog #rust

Esteban Kuber продолжает улучшать диагностики парсера rustc. Теперь парсер ещё и восстанавливается от маркеров конфликта слияния.

github.com/rust-lang/rust/pull/106242
🔥7👍2
std::collections::#Map

std::collections::🅱🌳Map
🥰84🥴2👍1
Блог*
std::collections::#Map std::collections::🅱🌳Map
Хотя что это я

#⃣🗺

🅱🌳🗺
🔥9🥴7
Forwarded from Саламандра. Сдвиг окна Овертона (Яна Ике 🔥 (огонёк одобряем))
Команда: берёт нового разработчика
Разработчик:
🥰8👍1
#prog #rust #itsec

Watch out for DoS when using Rust’s popular Hyper package

TL;DR: функция hyper::body::to_bytes выделяет память под запрос целиком, и попытка выделить большой объём памяти вызывает ошибку аллокации и, как следствие, прерывание работы программы. При этом для эксплуатации такого поведения не обязательно реально генерировать громадное содержимое запроса — достаточно сделать chunked запрос и передать один чанк, который не передаёт содержимое целиком. to_bytes в этом случае выделяет память, ориентируясь на значение Content-Length, которое, разумеется, может быть крайне большим.

Справедливости ради, про опасность потребления произвольного количества памяти в документации указано. С другой стороны, тот факт, что для эксплуатации этого поведения не обязательно реального генерировать большой запрос — не столь очевиден.
👍6
#prog #rust

Если ждать достаточно долго, то можно дождаться исполнения своего желания. В данном случае — желания разобраться с конкурентностью на низком уровне.

Небезызвестная Mara Bos опубликовала свою книгу: Rust Atomics and Locks: Low-Level Concurrency in Practice. Все главы можно прочитать бесплатно онлайн.
👏13🔥9👍2
#prog #rust

В C (и в C++) есть цикл for, который состоит из заголовка с тремя частями и тела:


for (init; continue_condition; iter_action)
body;

Особенностью третьего выражения (которое я назвал iter_action, а в стандарте называется expression-3) является тот факт, что оно вычисляется в конце каждой итерации, причём вне зависимости от того, завершилась ли итерация нормально или же раньше посредством оператора continue.

В Rust непосредственного аналога подобному циклу нет. Конечно, можно прописывать необходимые операции перед каждым оператором continue, но это не DRY и способствует внесению ошибок — хотя бы из-за возможной необходимости менять код синхронно в нескольких местах. Но это не значит, что аналогичного нельзя добиться!

Для получения аналогичного поведения нам понадобится labeled block break. init просто перемещается за пределы цикла, continue_condition становится условием итерации, а iter_action перемещается в конец тела, чтобы всегда исполняться в конце итерации. Тело цикла помещается в блок с меткой, и для перехода к исполнению iter_action мы соответствующий оператор continue заменяем на break с меткой блока.

Покажу это на примере. Пусть есть вот такой код на C:

for (int c = 0; c < 10; ++c) {
op1(c);
if (cond(c)) {
++c;
continue;
}
op2(c);
}

Вот так будет выглядеть аналог по описанной выше трансформации:

let mut c = 0;
while c < 10 {
'loop_body: {
op1(c);
if cond(c) {
c += 1;
break 'loop_body;
}
op2(c);
};
c += 1;
}

Из недостатков данного подхода — то, что, в отличие от сишного оригинала, действия в конце итерации и условие продолжении итерации разнесены друг от друга. Для решения этой проблемы напрашивается макрос, но, к сожалению, на декларативных макросах сделать это весьма трудоёмко: нужно поменять continue на break 'loop_body, поменять break на break 'whole_loop (ещё и добавить 'whole_loop на цикл в целом) — и при этом не трогать break и continue во вложенных циклах. Проще сделать процедурный. При этом, конечно, оно не будет нормально работать в случае, если в теле цикла есть макросы, которые раскрываются в код, содержащий break и/или continue.

Другой недостаток — это то, что break по метке для произвольного блока — фича из недавнего релиза Rust, и, соответственно, на старых версиях работать не будет. К счастью, это при необходимости легко исправить: к блоку после метки приписывается ключевое слово loop — превращая, таким образом, в цикл — а в конце содержимого дописывается break. Собственно, именно так люди раньше и делали до тех пор, пока данную фичу не завезли.
🤯1
Forwarded from Байки Тейвата | Genshin Impact
Игроки в Геншин — самые набожные люди. Они очень часто молятся.
5👎2
#prog #performancetrap #video

"Performance Matters" by Emery Berger

Фактически презентация двух инструментов для анализа производительности.

Первый — Stabilizer. Производительность программ в немалой степени зависит от того, как данные располагаются в памяти, и от окружения, в котором программы запускаются. Автор видео ссылается на статью, которая показывает, что эффект этих переменных может быть весьма значителен и перекрывать даже разницу между оптимизированным и неоптимизированным кодом. Stabilizer в рантайме каждые пол-секунды меняет раскладку кода и данных в куче, что позволяет снимать профиль производительности с учётом всех возможных влияний раскладки кода. Из-за применимости в данном случае центральной предельной теоремы общее влияние раскладки описывается (для достаточно большого количества исследованных данных) нормальным распределением, что позволяет задействовать статистические методы для того, чтобы замерить, насколько вклад в изменение производительности обусловлен изменениями в коде. К сожалению, этот инструмент более активно не развивается.

Второй инструмент (более живой) — это coz, causal profiler. Этот профайлер позволяет ценой небольших аннотаций исходного кода оценить, насколько сильно изменение производительности одного компонента сказывается на производительности системы в целом. Так как просто взять и ускорить код невозможно, coz достигает требуемых эффектов за счёт замедления всех остальных компонентов. В видео рассказывается о том, как coz помог в реальных случаях, на какие неожиданные узкие места указывал и о том, насколько хорошо замеренные прибавки в производительности согласовывались с предсказаниями инструмента.

Забавно, что это видео я уже смотрел, Даня упоминал coz у себя на канале, но только сейчас наткнулся на него снова и выложил у себя.
🔥3👍2