rust.tokyo のまとめ・感想
このブログを書いてる経緯
rust.tokyo 楽しみ！絶対行く！といってたのに申込みを忘れたところ、じゃあスタッフとしてブログを書けという話になったので、ブロガー枠？らしく感想を書きます。とはいえ書けるのは見たやつだけです。
前提
自分は低レベルプログラミングは詳しくないです。年に3日ぐらい思い出したように Rust 勉強することがある。 wasm 周りのエコシステムはずっと追ってる。
会場の雰囲気
組み込み勢とブロックチェーン勢が多そうな気配を感じた。
Visualization of mechanical CAD drawings using WebAssembly and WebGL
Aki / CADDi
(発表資料見つからず)
概要
Computer aided design (CAD) models used in manufacturing represent designs as a topological model composed of geometric primitives. Developing online visualization tools has traditionally required a backend service responsible for parsing CAD files, and providing a frontend-friendly representation of the geometrical data. However with WebAssembly, we can now utilize CAD libraries, originally intended for native applications, inside the browser with minimal dependence on server-side services.
In this talk we will illustrate the use of WebAssembly and WebGL to create platform agnostic visualization applications for mechanical CAD drawings.
内容
- Rust 0.9 の頃から使ってた
- 3D モデリングから 2D の図面に起こす 2D procurement というフェーズがある。2D の procurement に rust を使ってる
- WASM は普及したよ(IE以外)
- 実際どんなコードか（文字が潰れて読めない。資料見るしかなさそう）
- Rust + JS は相性がいい。自然に相互に呼び出せる。でも rust から見るとちょっと unsafe。
- Wasm のバイナリフォーマットについて
- import section / export section 呼び出し規約
- code section: コード
- data section: データ格納されてる場所
- memory section: linear memory
- Harvard-like architecture
- WebGL で何ができるか
- 今難しいところ
- CJK Rendering(Font, garbled text)
- native syscall 含むコードの変換
- Ecosystem
- wasm-bingden, web-sys, js-sys
質問
- JS の cos/sin 呼んでるけど、Rust の cos/sin 呼べないの？
- 数学ライブラリを用意できれば。テーブルまで実装すれば
- ベジェとかbスプラインとかやると数学関数呼び出したくなると思うけど
- 数学ライブラリの出来が良ければ。ただあんまりできが良くないのが多くて、実際 使ってるライブラリの bスプラインの実装に課題がある
- Math.sin 呼ぶのオーバーヘッドにならない？
- 実行環境次第だが、ほぼ問題ない
- Rust の std を呼んでないのはなぜか
- no std でコンパイルしてる。 linear memory の中で alloc 読んだりはしてる
- std はいれることはできるが、組み込みなので容量を意識して入れてない
- libm つかった？
- js 呼ぶほうがてっとり速かった
- nostd 言うほどサイズ縮むか？
- std そのものより std があることで色々呼び出しはじめるほうが問題
- 組み込みの人間なので、nostd 当然みたいなノリ
- 直接質問した: WASMとのブリッジは数値型の受け渡しだから速いのであって、文字列とかきついんでない？
- たぶんそう。きつい
エッジMLシステムをC/C++からRustへ移行した事例
加藤倫弘 / Tomohiro KATO
https://docs.google.com/presentation/d/1HOL9jheJnKkh2q7w3hU_px-je1qL7lxrSXV-0P1hces/edit#slide=id.p1
概要
我々は、ドライブレコーダーに組み込んで運用しているML(Machine Learning: 機械学習)システムの実装言語をC/C++からRustに移行しました。
Rustへの移行目的は、品質と生産性の向上です。デバイスへデプロイするシステム は簡単に変更できないため高い品質が求められます。また最新のアルゴリズムを短 期間で実装・テスト・デプロイするためには言語やその周辺ツールの生産性の高さ が求められました。もちろんリソースの少ないデバイスを対象としたため、C/C++同等やそれ以上の性能も必要でした。
本発表では、同様にC/C++からRustへの移行を検討している方や、MLシステムを構 築している方の参考になるように、Rustをプロダクト開発で使うために解決した以下のようなトピックについて説明します。
- C/C++で開発する上での課題とRustで解決されたことはなにか
- C/C++から移行する上での技術的な課題や学習コストをどう乗り越えたか
- テストやドキュメント、デプロイの自動化などをどうするか
- ディープラーニングや画像処理、それらの性能計測をRustでどう実装するか
内容
- C++ から Rust へ移行した話
- プロダクション向けに Rust 使ってみてどうだったか
- ハードウェア構成はわけあって喋れない
- 組み込み出身
- DriveChat
- 危険な運転をしていないか判定するサービス(to B)
- 運転行動の改善レポートなどを生成
- 研究開発は Python でやって、それをプロダクションで再実装
- ウェブに比べてバグがシビア
- C++の課題
- Rust 移行への決め手
- リファクタしやすい
- Rust で ML なら ndarray for numpy user を読め
- numpy からの移植が楽
- Rust で DL 実装するには
- 問題が解決したか
- スピード: pure rust で問題なし。DL周りは binding で解決
- 品質: エコシステムがよいのでロジックに注力できる。コンパイラの警告の品質が良い
- コード量が減って、場所によっては半分以下になった
- SEGV がなくなった
- まとめ
- Rust で生産性が上がってインクリメンタルな改善が可能になった
質問
感想
- ndarray, cargo make 良さそう
Rustによる数値計算の現状と課題
@termoshtt
https://docs.google.com/presentation/d/1iujcfg2y3CMMgEO8BvX2__w_dbl4zQWQrK3ULaStD4E/edit
概要
多くの数値計算ライブラリはFortranやC++で書かれており、これらの代替としてRustが注目されており、いくつかのコアとなるライブラリの開発も進んでいます。この講演ではRustのゼロコスト抽象化を数値計算ライブラリの設計にどうやって応用していくかについて議論し、その有用性と今のRust数値計算エコシステムに足りていない事についてまとめる事で、より多くの数値計算エンジニアにRustを広める事を目指します。
内容
- アカデミックで C++ で乱流の計算・可視化をしていた
- 流体・個体・熱伝導・気象・海洋などは、問題ごとに専用ソフトウェアを作って、特殊なスパコンで実行する必要がある
- 典型的な数値計算プロジェクト
- なぜ Rust
- 並列化/SIMD
- num-traits
- Trait でアルゴリズムを実装
- 常微分方程式: Runge-Kutta
- termoshtt/eom
- (コードの説明、むずい)
- Trait で数値型に意味づけすることが可能になった
- 利用
- cc-rs: 小さなコード片ならこれで済む
- 共有ライブラリ so, a を使う
- rust-bindgen
- なぜ Rust か
- パッケージ管理機構が現代的 (ないとおかしいんですが…)
- semver でバージョニング (これもあって当然なんですが…)
- ndarray, pyo3
- Benchmarking
- bheisler/criterion.rs (criterion-rs)
- 統計処理・前回比較が取れる
- Cargo FrameGraph
- Pros
- Cons
- rust-cuda working group
- プラットフォームごとにサポート tier がある （1/2/3）
- nvptx を tier2 にしたい…
- rust-cuda/cuda-sys
- まとめ
- GPU(たぶんGPGPU)周りが辛い
Web-based Data Visualization with Rust and WebAssembly
Yosuke Onoue / @_likr
https://speakerdeck.com/likr/web-based-data-visualization-with-rust-and-webassembly
概要
Webベースのデータビジュアライゼーションの需要は高まっていますが、大量のデータをWebブラウザ上で処理するためにはパフォーマンス上の課題が発生します。そのようなWebでのパフォーマンス上の課題を解決するために、WebAssemblyと呼ばれるWebブラウザ上で実行可能なバイナリフォーマット言語が新たに整備されてきました。WebAssemblyはRustによって公式にサポートされているため、Rustの表現力とパフォーマンスの恩恵を受けながらWebAssemblyを用いた開発を行うことができます。本セッションでは、WebAssemblyの概要やRustによるWebAssembly開発の方法、RustとWebAssemblyの今後の展望をネットワークビジュアライゼーションでの事例を混じえてご紹介します。
内容
- 情報可視化の研究者
- いろんなデータをどう人間に見せるかの基礎研究
- 可視化: 昔は一枚の絵を書くことだった => 人間とのインタラクション重視へ
- 人間がデータと対話する場 => Visual Analytics
- 専門家ではない人も使うものになった
- なぜ Web でやるか
- ベンダに依存しない標準的なプラットフォームである
- インターフェースとして普及してるので、専門的な操作への入り口になりやすい
- かんたんにシェアできる(デスクトップアプリと比べて)
- Web の難しさ
- パフォーマンスに難
- 60fps <16ms
- レスポンス <100ms
- PheGeNet
- Framework: Vue.js
- Rendering: WebGL
- Network Layout: Rust and web assamebly
- Rust and wasm
- モダンブラウザなら動く
- バイナリ形式の言語
- 低オーバーヘッド
- Multithreading and SIMD
- Rust にとって wasm はファーストクラスのサポート (wasm32-unknown-unknown)
- 実行形式
- Emscriptn
- cdylib
- wasm-bindgen
- wasm-bindgen
- JS フレンドリーな binding
- js-sys: Rust <-> JS
- web-sys: ブラウザAPI
- wasm-pack
- 色々あるけど、これがおすすめ
wasm-pack buildで crate から js を一括出力create-wasm-pack
- 細かい wasm-bindgen 伝わらない話
- Err が JS とシームレスに受け渡せる
- Testing:
wasm-pack test --chromeが便利 (rust レベルの wasm ビルドの実行テスト) - Webpack 抜きでやる:
wasm-pack build --taget web
- パフォーマンス： wasm は速いのか
- 大雑把に: rust で長い間で走ってる場合は速い。高頻度で Rust/JS を細切れに呼びあうと遅い
- そもそもJSが気持ち悪いぐらい速い
- よく調整されたJSはRustと同じぐらい速い
- しかしシングルスレッドの JavaScript は現代的な CPU の一部しか使えていない
- Rust Wasm は Multithreading や太い 128bit の SIMD に活路を見出すといいのでは
- まとめ
- wasm は Web の限界を押し上げるもの
いつの間にか社の中核製品にRustが使われていた件について
@aznhe21
概要
オプティムでは第4次産業革命を担う企業として「世界一、AIを実用化する企業になる」というスローガンのもと様々なサービスを開発しています。そんなオプティムの中核製品であるAI Cameraは高速な画像解析を低コストで導入するサービスです。このAI Cameraのコア部分にはRustを採用しており、その高速性・安定性を支えています。
内容
- R&D やってる
- Optim について
- Rust をどこで使っているか
- Rust 採用理由
- 現状
- 依存が 739 crate
- クリーンビルド 5分以上
- ダイエットしたい
- なぜ Rust
- 今後やりたいこと
- WebAssembly/Wasi でプラグイン作りたい
- 画像最適化: image/imageproc が遅い。画像処理が辛い
Making an opinionated Web framework
@qnighy
https://speakerdeck.com/qnighy/making-an-opinionated-web-framework
概要
Some Web frameworks such as Ruby on Rails intentionally force a specific software architecture and, as a result, called opinionated frameworks. Opinionated frameworks have several advantages: a standardized directory layout helps newbies to understand the codebase. They are also designed to guide programmers to adapt the program to the corresponding software architecture. So the codebase will be more tolerant of rapid growth. I think that such an opinionated Web framework written in Rust would accelerate Rust adoption in the Web programming area. I'm attempting to make it by myself, using existing Web frameworks as a reference. In this talk, I'd like to describe how I thought and learned during design and implementation.
内容
- Watedly / Rails / Go
- rust の言語仕様が好き
- go は良い言語だけど… rust だったらハマらなかったはずのもの…
- どういう要件の場合、 rust で置き換えられるか？
- Single Feature Server / サーバーレスでいいもの
- 採用を訴えるだけの、エコシステムがない => 作ろう
- Real World: Example apps に基づいて作ってみる
- gothinkster/realworld
- 非同期の実装が2つある / tokio(デファクト) vs rustasyn(オフィシャル)
- => 公式「エコシステムに関与しなくていい気がしてきた」 => オフィシャルじゃないオフィシャルだったものになった
- Protobuf から 実装を生成するスキーマファースト設計
- 例外処理:
- actix-web Error Trait を提供
- gotham: 何も考えてない
- スキーマファーストだとアプリケーションの Error 型の自由度が問題になる
- Nails では
enum NailsErrorとした。 - 型が複雑になるより、ある程度 Optional な RuntimeValidation に寄せてしまう
- Nails では
- DI 実装する場合、注入した Context をどう引き回すか。 arctix-web にもその問題がある。0系と1系で実装が変わってる
LT
注意: 自分が lifetime の細かい挙動に理解してないため、理解が曖昧
- Python イテレータと Rust の借用
- Rust 製テキストエディタで Fuzzing
- 純 Rust でテキストエディタを作ってる kiro-editor
- Build your own text editor を読んで勉強して実装 (C実装)
- Tooling: 普通にやりそうなことは一通りやってる。 fuzzing もやってる。日本だとfuzzingやってる人少なさそう。
- なぜ fuzzing: 速い/安い/うまい。 Chromium や Linux カーネルでバグ発見の実績あり
- cargo-fuzz を使う
- UTF8 として decode できたときだけ、エディタにそのシーケンスに入力させる
- デモ: 10件目でみつかった。本当はもっと色々突っ込む必要があるが、このように簡単に試せる
- Lifetime tricks for streaming and zero-allocation parsing
- zero copy parsing は最高
- streaming: メモリ制限があるが、だいたい速い(とくに相手が外部ネットワークの場合は)
- streaming はだいたいチャンクで来る。チャンクに対してのメモリアロケーションが必要になる
- 同じコンテンツの中身が複数のチャンクにまたがってることもある。
- 例: PKZIP / deflate stream
- 解決策: unparsed 状態でバッファして、溜まったら parse する
- 複数の chunk から生成された parsed object のライフタイム何になる？
- enum で Long Short を作って割り振って、Long を取る (というコードを示されたが、よくわからなかった)
Contributing to Rust
@argorak
概要
This session will give you a practical guidance to start contributing to the Rust project, either the compiler or other parts of it. This can range from technical changes to documentation or translation. You will learn
内容
- rust core team / rust trainer since 2015
- Contirbution とは...
- Code
- Triage/Review
- Documentation
- Moderation
- etc
- だけではなく…
- 教育
- ライブラリを書く
- カンファレンスの運営
- Rust Project の Scope
- 70 のチーム、 200人のメンバー、5000人以上のコントリビューター
- コードを書くだけではない
- Team の例
- Lang Team
- Compiler Team
- Vendor Relationship
- Ecosystem
- Marketing
- コミュニティの事例
- https://github.com/rust-community/team
- rust-gamedev/wg
- rust-embedded/wg
- 気軽に参加したり抜けたりできるから参加してね
- 普通は週に 30分から2時間 ぐらいの活動がある
- 5~10分ぐらい参加したい => 別に大きなタスクに取り組む必要がないよ => Triage Team
- 今の Rust Project の課題
- 成長痛
- 情報が多すぎる
- ドキュメントが足りない
- フィードバックがほしい！
- 地理的な話
- Timezone に合わせたチームがある。小さいサイクルでレビューを回す。
- ネイティブじゃない言語でのコミュニケーションは難しい。異なる言語をつないでくれる Meta communicator がいてくれるととても嬉しい
- Effective contribution is local
質問
- Rust と Ruby で謎のコミュニティのつながりがあるのは？
- 謎ではない。すでにある繋がりを利用したから。ゼロからコミュニティワークをしたい人を集めた。
感想
- 言語仕様で話題になるのは Trait, Ownership, Iterator って感じ
- ライフタイムで詰むパターンと unsafe 使うときの
- 言われてるほど学習コストとC/C++からの移行コストは高くないので、最初は趣味でいいから雑にいれていけというメッセージを感じた
- pyo3 や cpython のような python バインディングの話が多かった。ML 文脈で image crate への言及も多い
- エコシステムが優秀、という言葉の背景に、C++のエコシステムの不出来への恨み節がこもってる人が多かった
- C/C++からの移行とは別に、web から rust へ進出した人はほぼ見ない。 @_likr さんも言っていたが、V8 が速すぎるのがJSからの移行モチベーションを下げてるのでは、という話
- 懇親会のケータリングが豪華で美味しかった
めちゃくちゃ熱量があった。次回もやりたいみたいなので期待
今回は、組み込み業界、ウェブ業界に偏ってたので、たぶん使ってそうなゲーム業界の話も聞きたいね、という話を主催の @dorayakikun としていました。今回は以上です。
