Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Rustのasync/awaitとスケジューラの話 / rust-async-await
Search
Osuke
April 28, 2020
Programming
9
3.5k
Rustのasync/awaitとスケジューラの話 / rust-async-await
Osuke
April 28, 2020
Tweet
Share
More Decks by Osuke
See All by Osuke
特許データを使ったマルチモーダルAIの検証事例@LLMProd#4
osuke
0
29
dbtを中心に据えた データ分析とプロダクト開発
osuke
1
840
LayerX Privacy Tech事業部紹介 Tech編
osuke
0
97
(SCIS2021) Anonify: プライバシーを保護した 検証可能な状態遷移モジュール
osuke
1
310
Rustで実装された AWS Nitro Enclaves CLIを読む
osuke
0
250
Rustのパフォーマンスに関するTips
osuke
3
2k
ARM TrustZone入門 / ARM TrustZone intro
osuke
3
7.3k
Anonify
osuke
3
840
Privacy on Blockchain
osuke
1
1.1k
Other Decks in Programming
See All in Programming
Enhancing Applications with Accessibility API
kishikawakatsumi
3
1k
自動テスト実行結果の目的を整理する / Organizing objectives of automated test results
twada
PRO
10
2.1k
Go1.22からの疑似乱数生成器について/go-122-pseudo-random-generator
convto
1
160
TCA魔法学入門🪄
dazy
0
280
複雑なドメインを扱うプロダクトの探索フェーズではいつどのようにテストをするのか / How to testing during exploratory phase
boykush
2
150
CircleCIを活用して AWSへの継続的デリバリーを 実践する
coconala_engineer
1
110
フロントエンドパフォーマンス 入門
shouta2
7
1.5k
Honoとhtmx
yusukebe
6
1.2k
App Router への移行は「改善」となり得るのか?/ Can migration to App Router be an improvement
takefumiyoshii
1
140
object-oriented-conference-2024
fuwasegu
6
1.9k
もうすぐ新年度、Babylon.jsがお勧めな3個の理由
hideg
0
170
孤独のCTOグルメという やや奇抜な企画をやった目的と効果
shoheimitani
3
1k
Featured
See All Featured
Done Done
chrislema
178
15k
BBQ
matthewcrist
78
8.7k
Designing the Hi-DPI Web
ddemaree
275
33k
Adopting Sorbet at Scale
ufuk
66
8.5k
Fontdeck: Realign not Redesign
paulrobertlloyd
75
4.8k
Being A Developer After 40
akosma
56
580k
Keith and Marios Guide to Fast Websites
keithpitt
407
22k
5 minutes of I Can Smell Your CMS
philhawksworth
199
19k
Optimising Largest Contentful Paint
csswizardry
7
2.3k
Six Lessons from altMBA
skipperchong
19
2.9k
Into the Great Unknown - MozCon
thekraken
10
830
XXLCSS - How to scale CSS and keep your sanity
sugarenia
240
1.2M
Transcript
の と スケジューラの話
About Me • • ブロックチェーン技術を軸にプライバシー保護やインターオペラビリティなど の研究開発 @zoom_zoomzo Osuke
None
LayerXでのRustの使い方 • 暗号プロトコル ◦ 安全性がクリティカル ◦ ライブラリが充実 • システムプログラミング言語として ◦
プロセッサレベルのメモリ保護機能 の利用 • などを用いてサーバーサイド開発
OSS in Rust • ゼロ知識証明ベース ◦ ◦ ◦ •
None
None
std::future::future • ステートマシンの抽象化インターフェース ◦ 将来的に値が確定する計算 • ポーリングモデル(繰り返し )で状態をできるだ け進めていく •
すると か を返す ◦ の場合は次の状態へ遷移 ◦ の場合は現在の状態のまま
std::task::Context Pending • 次回はどのタイミングでポーリングすればいいのか問題 ◦ が返ってきてすぐまたポーリングするの は 時間の無駄 • (
の )でステートマシンの状態遷移が 再開可能になるタイミングの通知を設定 • ナイーブな例 ◦ ▪ の場合、スレッドをブロック ◦ ▪ 時に、スレッドのブロックを解除 Ready
example
None
async/await • 非同期関数内で まで状態を進めていく ◦ を繰り返し実行していく • 非同期処理を同期処理のように扱えるシンタックス
async/await • 非同期関数は (再開可能 な計算)のシンタックスシュガー • 非同期関数もステートマシン
• 軽量な実行単位 ◦ メモリ消費量・時間コストが スレッドよりも圧倒 的に効率的 • ( スレッドではなく)グリーンスレッド ◦
◦ ◦ • それぞれのタスクが独立したステートマシン ◦ で生成 • それぞれの が を持つ ◦ non-blockingであることが重要 Task でタスクアロケーションの効率化
Runtime • 非同期計算の実行環境 • に渡さないとランタイムで実行されない ◦ はシステムプログラミング言語として薄く するため言語仕様には組み込まれていない ◦ や
が有名 • がそれぞれの スレッドで実行する をいい感じに配置 ◦ 公平なスケジューリング ◦ がプリエンプションしない
None
Scheduler • 単位の実行をよりパフォーマンスが出るように管理 • などでタスク実行キューをロードバランシング ◦ だと 取得時の競合でパフォーマンス低下する Task Task
Task Task Task exec Task exec
Blocking Call • 非同期タスクはすぐに計算が完了することが期待されている • タスクの移動は したところでのみ起こるので、そのポイントにたどり着くまでに 多くの時間を要する場合は他のタスク実行を妨げる可能性がある • 非同期関数内でブロッキングするタスクの呼び出しは大幅なパフォーマンス低下の
懸念 ◦ 時間のかかるシステムコールの呼び出しなど
Pollute runtime... • ブロッキングタスクが同じスレッドで実行される非同期タスクもブロックしてしまう • ランタイム全体のパフォーマンス低下につながる Task Task Task Task
Task exec Task exec
Blocking Calls in tokio • によってブロッキングな呼び出しはバックグラウンドのブロッキン グスレッドへ • 非同期タスクはブロッキングコールの影響を回避 •
グローバルなスレッドプールなので なライフタイムを持つ必要がある • の代わりに を使うと、現在のスレッドがブロッキ ングスレッドになる ◦ トレイトを要求しない
• ブロッキングする可能性のある呼び出し ◦ システムコール ▪ ▪ ◦ バウンドな重い処理 ◦ 外部クレート依存関数の呼び出し
◦ 他のタスクと同期する必要がある処理 ◦ • 開発者が呼び出す関数が かどうか考慮しバックグラウンドのブロッキング スレッドへ送る必要がある blocking?
gorourtine • スレッド ◦ ブロッキングしている処理を検出 ▪ 開発者は明示的にブロッキングタスクを処理する必要はない ◦ の検出や実行時間の長いタスクのプリエンプションにより、ブロッ キングタスクを他の実行キュー
グローバルキューにエンキュー Task Task Task Task Task exec Task exec sysmon
と の ブロッキング呼び出しに対する対応
async-std • 標準ライブラリに かつハイパフォーマンスな非同期処理イン ターフェースを提供 • とは違う独自の非同期ランタイムも提供 • エコシステム ◦
◦ ◦
async-stdの新しいスケジューラの試み • 時間がかかっているブロッキングな呼び出しをバックグラウンドのスレッドプールへ 自動的に逃す ◦ 実装を見ると少なくとも ごとに 関数を呼び 出す •
以下のような非同期関数内での時間のかかる呼び出しもスケジューラが暗黙的に ブロッキングスレッドで処理する ◦ 開発者がブロッキングコールを意識しなくてよくなる
ランタイム実行のループ内で スレッド生成を行う関数を 呼び出す スレッド タスク実行キュー 処理時間が長いタスクを検出し て新しいスレッドプールへ逃す 部分
Auto-detecting blocking calls
Benchmark https://async.rs/blog/stop-worrying-about-blocking-t he-new-async-std-runtime/
• やっていき • 厳しみ • 一部だけマージ だが、しかし。
tokio • 「 」 • プリエンプション:同じタスクを長時間実行し続けてる状態に対する割り込み処理で タスクをスケジューリング ◦ には存在しない ◦
代わりに、 で が追加 • :タスクごとのオペレーションの上限カウンタ ◦ オペレーション: ◦ タスクが一定数以上 のオペレーションを行うと自動で ◦ タスクがスイッチしたら カウンタはリセット • あくまで 対策なので、 は依然必要
まとめ • も 関数も もステートマシン ◦ や などのランタイム上で状態遷移 ◦ は軽量かつ
であることがパフォーマンス上重要 • 非同期関数内のブロッキングな呼び出しは今後も開発者が明示的に対処する 必要あり
None
We are hiring!! • 全ての経済活動をデジタル化していく仲間を募集しています! https://www.wantedly.com/projects/363053