https://deterministic.space/secret-life-of-cows.html
статья про Cow в #rust. забавляет название "тайная жизнь коров" =)
статья про Cow в #rust. забавляет название "тайная жизнь коров" =)
Pascal’s Scribbles
The Secret Life of Cows
A lot of people at RustFest Paris mentioned Cows– which may be surprising if you’ve never seen std::borrow::Cow!
https://llogiq.github.io/2020/03/14/ootb.html прикольная техника резервирования места, и для этого не нужно боксить (ложить явно в хип) а можно сделать просто резервацию
let t_holder;
let opt_t = if has_t {
t_holder = get_t();
Some(&t_holder)
} else {
None
}
https://llogiq.github.io/2017/06/01/perf-pitfalls.html
#rust Performance Pitfalls
когда то нарвался на пару путктов отсюда
#rust Performance Pitfalls
когда то нарвался на пару путктов отсюда
собственно для стэйт машин хорошо подойдет замена прямо из памяти, что бы не аллоцировать лишний раз в промежуточную переменную https://github.com/rust-unofficial/patterns/blob/master/idioms/mem-replace.md
GitHub
patterns/mem-replace.md at main · rust-unofficial/patterns
A catalogue of Rust design patterns, anti-patterns and idioms - patterns/mem-replace.md at main · rust-unofficial/patterns
во. шикарная статья про оптимизацию кода коровами (как же меня забавляет этот тип =)) в #rust
https://oribenshir.github.io/afternoon_rusting/blog/copy-on-write
https://oribenshir.github.io/afternoon_rusting/blog/copy-on-write
oribenshir.github.io
Optimizations That Aren't, Or Are They?
This blog is designed to cover topics related to both Rust & C++ languages. This blog has emphasis on strong typing and design choices.
https://oribenshir.github.io/afternoon_rusting//blog/enum-and-pattern-matching-part-1
https://oribenshir.github.io/afternoon_rusting/blog/enum-and-pattern-matching-part-2
про инамы и паттерн матчинг в #rust
https://oribenshir.github.io/afternoon_rusting/blog/enum-and-pattern-matching-part-2
про инамы и паттерн матчинг в #rust
oribenshir.github.io
Rust for OOP - Enums & Pattern Matching - Part 1
This blog is designed to cover topics related to both Rust & C++ languages. This blog has emphasis on strong typing and design choices.
https://oribenshir.github.io/afternoon_rusting/blog/closures и еще про замыкания в #rust определения Fn/FnMut/FnOnce мне нравится больше чем то что я читал в официалной доке
oribenshir.github.io
Rust for OOP - Closures
This blog is designed to cover topics related to both Rust & C++ languages. This blog has emphasis on strong typing and design choices.
https://articles.bchlr.de/traits-dynamic-dispatch-upcasting шикарная статья про dyn типы, vtable, про полиморфизм и даже путь #rust в отношении имплементации наследования в C++ и апкастинг. сразу видна и проблема и то как явно это решается
https://anssi-fr.github.io/rust-guide/01_introduction.html небольшой гайд по секьюрному #rust. тут про библиотеки что помогают искать проблемы, утечки памяти, систему типов и ffi
anssi-fr.github.io
Introduction - Secure Rust Guidelines
Recommendations for secure applications development with Rust
https://medium.com/@pailee.wai/how-we-migrate-our-framework-into-async-await-c67b160e16be немного про миграцию старых фьюч на async/await в #rust
Medium
How we migrate our framework into async/await
The logs of async/await migration in Obsidian-rs
https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html чтото мимо меня промчался тот факт что больше в #rust не нужен mod.rs в каждой субдериктории
https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html видел эту книгу, забыл про то что она есть. И как оказалось некоторые сложности с асинхронщиной в #rust, что я героически решил, в ней хорошо описаны 🙈
интересные результаты переписывания блокируюещго раста на async/await. хочу поделиться
дано:
16к строк кода в блокирующем многопоточном виде. хороший nvme SSD, гигобитная сеть, 24поточный Xeon 2678 в 3.3ГГц на ядро.
результат:
выигрыш отрицательный.
было 4.2сек сейчас 4.9сек. это проход 2000 файлов и пересчет параметров. жестко (для меня это большие цифры, если что). большее количество файлов имеет тот же эффект. поэтому обычно проверяю на этих 2к файлов с десяток раз, для правдоподобности, разброс малый очень
большую часть io задач у меня приходится на чтение с диска (цпу зубодробилку смысла нет на async/await переписывать). и когда куплен оч хороший nvme SSD то вообще оказывается в забрать в 24 потока блокирующе в буфер весь файлик быстрей. (фс настроена без лога времени доступа и тп, полностью под скорость) И возможно это уже приколы того как работает железо, шина и nvme, тут я уже теряюсь, может вы подскажете
сами файлики редко больше 30мб, там числовые данные, предобработанные и лежат сразу в бинарном виде что бы просто загрузить в память, нетратя лишний раз цпу. поэтому влияние самих файлов не особо заметно. заметно то что код пришлось менять так что бы оно того поддерживало, без блокирующих штук. и видимо таки есть оверхэд константный, пересчет обычно тратит все ядра на 100% и оно не троттлит, проверял
но вот для слабых систем уже чувствуется что не просело, а даже иногда выигрывает. чем хуже винт тем заметней
и получается что даже учтя все возможные проблемы, и убрав все что могло быть блокирующим в io задачах - прироста не дало
неожиданные результаты для меня тем, что и вроде как круто что железо хорошее, но вот вопрос стоили ли мои две недели переписывания того или нет. если хороший nvme SSD Samsung 970 EVO Plus стоит всего 100$ (понятное дело можно найти и дешевле), и мне нужно заменить на 10тачках, то я попал в просак...
с другой стороны это мои первые потуги в стабильном асинхронном расте. Может кто работал с ним уже ? я вот 100% уверен что чтото упустил, и можно дотюнить.
дано:
16к строк кода в блокирующем многопоточном виде. хороший nvme SSD, гигобитная сеть, 24поточный Xeon 2678 в 3.3ГГц на ядро.
результат:
выигрыш отрицательный.
было 4.2сек сейчас 4.9сек. это проход 2000 файлов и пересчет параметров. жестко (для меня это большие цифры, если что). большее количество файлов имеет тот же эффект. поэтому обычно проверяю на этих 2к файлов с десяток раз, для правдоподобности, разброс малый очень
большую часть io задач у меня приходится на чтение с диска (цпу зубодробилку смысла нет на async/await переписывать). и когда куплен оч хороший nvme SSD то вообще оказывается в забрать в 24 потока блокирующе в буфер весь файлик быстрей. (фс настроена без лога времени доступа и тп, полностью под скорость) И возможно это уже приколы того как работает железо, шина и nvme, тут я уже теряюсь, может вы подскажете
сами файлики редко больше 30мб, там числовые данные, предобработанные и лежат сразу в бинарном виде что бы просто загрузить в память, нетратя лишний раз цпу. поэтому влияние самих файлов не особо заметно. заметно то что код пришлось менять так что бы оно того поддерживало, без блокирующих штук. и видимо таки есть оверхэд константный, пересчет обычно тратит все ядра на 100% и оно не троттлит, проверял
но вот для слабых систем уже чувствуется что не просело, а даже иногда выигрывает. чем хуже винт тем заметней
и получается что даже учтя все возможные проблемы, и убрав все что могло быть блокирующим в io задачах - прироста не дало
неожиданные результаты для меня тем, что и вроде как круто что железо хорошее, но вот вопрос стоили ли мои две недели переписывания того или нет. если хороший nvme SSD Samsung 970 EVO Plus стоит всего 100$ (понятное дело можно найти и дешевле), и мне нужно заменить на 10тачках, то я попал в просак...
с другой стороны это мои первые потуги в стабильном асинхронном расте. Может кто работал с ним уже ? я вот 100% уверен что чтото упустил, и можно дотюнить.
короче это был кэш)). скатина блин. вылетело из головы что он в кернеле есть и если файлы загружать понятным образом, то кернел сам сохраняет в памяти, так как файлы небольшие
кэш подтягивается системой почти предиктивно, он не забивает всю память и не забирает все файлы, всеравно диск так или иначе меряется. но уже асинхронщина не дает прелестей, так как кернел загрузил в память мгновенно. и уже оттуда читает буфером, что впрочем может равнятся тупому реюзанию скопированной памяти
https://k6.io/ тула что бы деть стресс и нагрузочные тесты апишек. надо не забыть, явно пригодится скоро.
скриптом можно сэмулировать любые перепады трафика и отхэндлить любые косяки разными способами (счетчиками, рейтами и т.п.)
скриптом можно сэмулировать любые перепады трафика и отхэндлить любые косяки разными способами (счетчиками, рейтами и т.п.)
k6.io
Load testing for engineering teams | Grafana k6
k6 is an open-source tool and cloud service that makes load testing easy for developers and QA engineers.
https://engineering.mongodb.com/post/getting-storage-engines-ready-for-fast-storage-devices статья очень мне в тему сейчас. про
Memory-mapped files для ускорения работы с дискомMongoDB
MongoDB Engineering Blog | MongoDB Blog
MongoDB's blog includes technical tutorials, MongoDB best practices, customer stories, and industry news related to the leading non-relational database.
https://www.youtube.com/watch?v=8cV4ZvHXQL4 забавный оч старый но хороший доклад про то как работает eventloop в #js не видел перевода до сегодня
https://www.youtube.com/watch?v=K_wnB9ibCMg&feature=youtu.be помимо токио есть еще вогон проектов. забавны ее невыспавшиеся круги вокруг глаз, как у меня. вот до чего доводит #rust
YouTube
An Async Story. Katharina Fey
Katharina lives in Berlin and works as a software engineer at Ferrous Systems. She’s been writing Rust actively since 2017, is author of many crates and is an active community member. Currently she’s part of the CLI working group, the community team, and…
обратил внимание то что пол проекта в многопоточностях и конкуренции, и это совершенно не имеет никакой боли в поддержке, вообще стало обычным делом при работе с #rust