Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Rustのパフォーマンスに関するTips
Search
Osuke
November 24, 2020
Programming
3
3.9k
Rustのパフォーマンスに関するTips
Osuke
November 24, 2020
Tweet
Share
More Decks by Osuke
See All by Osuke
特許データを使ったマルチモーダルAIの検証事例@LLMProd#4
osuke
0
290
dbtを中心に据えた データ分析とプロダクト開発
osuke
1
1.1k
LayerX Privacy Tech事業部紹介 Tech編
osuke
0
230
(SCIS2021) Anonify: プライバシーを保護した 検証可能な状態遷移モジュール
osuke
1
410
Rustで実装された AWS Nitro Enclaves CLIを読む
osuke
0
390
ARM TrustZone入門 / ARM TrustZone intro
osuke
9
9.3k
Anonify
osuke
3
1.1k
Rustのasync/awaitとスケジューラの話 / rust-async-await
osuke
9
4.1k
Privacy on Blockchain
osuke
1
1.3k
Other Decks in Programming
See All in Programming
Github Copilotのチャット履歴ビューワーを作りました~WPF、dotnet10もあるよ~ #clrh111
katsuyuzu
0
120
C-Shared Buildで突破するAI Agent バックテストの壁
po3rin
0
400
リリース時」テストから「デイリー実行」へ!開発マネージャが取り組んだ、レガシー自動テストのモダン化戦略
goataka
0
130
【Streamlit x Snowflake】データ基盤からアプリ開発・AI活用まで、すべてをSnowflake内で実現
ayumu_yamaguchi
1
120
Full-Cycle Reactivity in Angular: SignalStore mit Signal Forms und Resources
manfredsteyer
PRO
0
150
Go コードベースの構成と AI コンテキスト定義
andpad
0
130
マスタデータ問題、マイクロサービスでどう解くか
kts
0
110
「コードは上から下へ読むのが一番」と思った時に、思い出してほしい話
panda728
PRO
39
26k
TestingOsaka6_Ozono
o3
0
170
複数人でのCLI/Infrastructure as Codeの暮らしを良くする
shmokmt
5
2.3k
LT資料
t3tra
6
960
Microservices rules: What good looks like
cer
PRO
0
1.6k
Featured
See All Featured
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
87
The Invisible Side of Design
smashingmag
302
51k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
320
How to Ace a Technical Interview
jacobian
281
24k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
570
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
60
37k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
0
3.3k
Done Done
chrislema
186
16k
Designing for humans not robots
tammielis
254
26k
Six Lessons from altMBA
skipperchong
29
4.1k
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
120
AI Search: Where Are We & What Can We Do About It?
aleyda
0
6.7k
Transcript
1 Rustのパフォーマンスに関するTips Osuke Sudo 2020/11/24 @下町.rs#4
2 @zoom_zoomzo Osuke ソフトウェアエンジニア@LayerX • 暗号技術・TEEを用いたデータのプライバシー保護 ・改ざん耐性手法の研究開発 • Anonifyの開発
3 アジェンダ • Inlining • Smaller enum size • SmallVec
/ ArrayVec • Cow
4 Inlining
5 • インライン展開: ◦ 呼び出される関数のコードをインラインで展開することで関数呼び出しのオーバーヘッドを 削減 ◦ バイナリコードサイズは増加 • 頻繁に呼び出す小さい関数はインライン展開するとパフォーマンスが改善することもある
• 最適化レベルや関数のサイズなどに基づきコンパイラがインライン展開を最適化 Inlining https://github.com/rust-lang/rust/pull/50564/commits/77c40f8c6f8cc472f6438f7724d60bf3b7718a0c
6 • アノテーションをつけることで特定の関数をマニュアルでインライン展開 • #[inline] ◦ crate境界内で、その関数を(できるだけ)インライン展開 • #[inline(always)] ◦
crate境界内で、ほとんどの場合でその関数をインライン展開 • #[inline(never)] ◦ その関数を(できるだけ)インライン展開しない Inlining
7 Inlining 同じ関数でも頻繁に呼ばれる箇所はインライン展開、逆にあまり呼ばれない箇所はインライン展開しない https://github.com/rust-lang/rust/pull/64420/commits/a2261ad66400c3145f96ebff0d9b75e910fa89dd
8 Smaller enums
9 • Enumの要素のうち、他の要素と比べて大きなサイズの型をBox化 ◦ A::Zにヒープ割り当てが必要になる代わりにAのサイズが削減 ▪ assert_eq!(std::mem::size_of::<A>(), 108); ▪ assert_eq!(std::mem::size_of::<B>(),
16); ◦ 特にA::Zの使用が比較的少ない場合、不要なアロケーションを避けることができ るのパフォーマンス向上しやすい Smaller Enums
10 Smaller Enums • x86-64上でSubtypeだけのサイズが大きく120bytes → Box化して32bytes。 https://github.com/rust-lang/rust/pull/64394/commits/7f0637da5144c7435e88ea3805021882f077d50c
11 SmallVec
12 SmallVec: https://github.com/servo/rust-smallvec • Vec<T>の代わりにSmallVec<[T; N]>を使うと、N個の要素はスタックに保持され、 N+1個以降の要素はヒープに保持される • 比較的少数の要素を持つVecがたくさんあるようなケースでアロケーションコストを削 減することが可能
• 一方、SmallVecはアクセス時に特定の要素がアロケーションされているか、していな いかチェックする必要があるので、通常の操作はVecよりわずかにコスト増 • 要素数(N)が多かったり、型(T)のサイズが大きかったりするとコピーコストが増 えることがあるので要ベンチマーク
13 SmallVec 滅多に要素数が3以上にならないので、SmallVec<[_; 4]>に変更することでベンチマーク4%改善 https://github.com/rust-lang/rust/pull/55383/commits/526dc1421b48e3ee8357d58d997e7a0f4bb26915
14 ArrayVec: https://github.com/bluss/arrayvec たくさんの小さいベクタとその最大長が分かるケースでは、アロケーションへのフォールバックがない 分、SmallVecよりArrayVecの方が良い https://github.com/rust-lang/rust/pull/74310/commits/c492ca40a288d8a85353ba112c4d38fe87ef453e
15 Cow
16 Cow • 多くの場合read-onlyだが、たまに mutable、毎回Cloneするのは不要なコ スト • 参照型の状態で所有型やmutationが必 要になったときに、はじめてcloneする ◦
Clone-on-write
17 Cow • 参照型と所有型のEnumであるCowを使うと不要なアロケーションを削減できることが ある • ライフタイムなどコードの複雑性が上がってしまうこともあるので注意
18 Cow • &strを引数にとって、関数内でStringに変換するのは毎回アロケーションが発生 • 一方、実際に引数に渡すのは&’staticかStringがほとんどのケース https://github.com/rust-lang/rust/pull/56336/commits/787959c20d062d396b97a5566e0a766d963af022
19 • Nicholas Nethercote ◦ The Rust Performance Book ▪
https://nnethercote.github.io/perf-book/ ◦ Blog posts ▪ https://blog.mozilla.org/nnethercote/ • Rust Performance Pitfalls ◦ https://llogiq.github.io/2017/06/01/perf-pitfalls.html References