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 LT #3 dalance
Search
dalance
March 25, 2019
Programming
1
950
Rust LT #3 dalance
dalance
March 25, 2019
Tweet
Share
More Decks by dalance
See All by dalance
OSS Silicon EDA #1
dalance
0
220
Make CPU #3 dalance
dalance
1
750
RTL talk #17 dalance
dalance
0
740
ArkEdge LT #1 dalance
dalance
3
640
Shinjuku.rs #8 dalance
dalance
2
780
RTL talk #16 dalance
dalance
1
1k
Other Decks in Programming
See All in Programming
Introducing ReActionView: A new ActionView-compatible ERB Engine @ Rails World 2025, Amsterdam
marcoroth
0
710
楽して成果を出すためのセルフリソース管理
clipnote
0
190
Oracle Database Technology Night 92 Database Connection control FAN-AC
oracle4engineer
PRO
1
470
AI Coding Agentのセキュリティリスク:PRの自己承認とメルカリの対策
s3h
0
240
私の後悔をAWS DMSで解決した話
hiramax
4
210
CJK and Unicode From a PHP Committer
youkidearitai
PRO
0
110
Improving my own Ruby thereafter
sisshiki1969
1
160
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.9k
Ruby×iOSアプリ開発 ~共に歩んだエコシステムの物語~
temoki
0
350
ProxyによるWindow間RPC機構の構築
syumai
3
1.2k
Zendeskのチケットを Amazon Bedrockで 解析した
ryokosuge
3
320
RDoc meets YARD
okuramasafumi
4
170
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
339
57k
The Language of Interfaces
destraynor
161
25k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
Faster Mobile Websites
deanohume
309
31k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Thoughts on Productivity
jonyablonski
70
4.8k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
113
20k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
How GitHub (no longer) Works
holman
315
140k
Transcript
RustとLSI開発 dalance
LSIの設計とは • ソフトウェアの場合 ◦ ソースコードを書く ◦ コンパイル ◦ 実行 •
LSI の場合 ◦ ソースコードを書く(例えば SystemVerilog などで) ◦ コンパイル(的な何か) ◦ 製造
LSIの設計とは • ソフトウェアの場合 ◦ ソースコードを書く ◦ コンパイル ◦ 実行 •
LSI の場合 ◦ ソースコードを書く(例えば SystemVerilog などで) ◦ コンパイル(的な何か) ◦ 製造 よく似ているので、同じような開発 手法やツールが使える。 CI とか git とか。
ソフトと違うところ • ソフトウェアの場合 ◦ ソースコードを書く ◦ コンパイル ◦ 実行 •
LSI の場合 ◦ ソースコードを書く(例えば SystemVerilog などで) ◦ コンパイル(的な何か) ◦ 製造 ここの規模感はだいぶ違う。 コンパイル 1 回に数日~数週間 中間ファイルが数 GB ~数百 GB
ソフトと違うところ • ソフトウェアの場合 ◦ ソースコードを書く ◦ コンパイル ◦ 実行 •
LSI の場合 ◦ ソースコードを書く(例えば SystemVerilog などで) ◦ コンパイル(的な何か) ◦ 製造 ここの規模感はだいぶ違う。 コンパイル 1 回に数日~数週間 中間ファイルが数 GB ~数百 GB 大きなファイルを素早く扱うための サポートツールをRustで書いてます
作ったもの(1) • amber ◦ いわゆる grep alternative ◦ 大きなファイルを分割してマルチスレッドで検索する ▪
ここだけなら ripgrep にも勝っている(普通の検索は ripgrep ものすごく速いです) • ptags ◦ ctags ( vim 用の tag 生成プログラム)のラッパー ▪ LSI 開発時のリポジトリは 1TB 近くになるので、 ctags を普通に実行すると終わらない ◦ .gitignore と git-lfs を除外して、マルチスレッドで並列実行できる
作ったもの(2) • pipecolor ◦ 標準出力をパイプで受け取って色付けするツール ▪ 正規表現でマッチさせて好きな色を付けられる ◦ LSI 系のツールは
cargo/rustc のように色がつかなくて分かりにくいので • procs ◦ プロセス情報表示ツール( ps alternative ) ▪ 標準でカラー表示できて、簡単に絞り込める ◦ LSI 系のツールは貴重な!ライセンスをつかんだまま死んでしまうことがある
まとめ • LSI 開発で(無理やり?) Rust 使ってます • Rust の良いところ ◦
開発速度が速い: cargo/crates.io のおかげで ◦ 実行速度が速い:データが大きくても困らない ◦ エラーハンドリング:予想外の例外で落ちたりしない