-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
コアの実装言語を C++ から Rust へ移行する #128
Comments
RustでC APIを提供するライブラリを初めて書きましたが、現状pointerが多いのでそのまま実装していくとRustらしいコードがかけずRustのメリットである安全性が享受されにくくなりそうです。そのためC export用の関数定義とinternalとしてRustとしての関数定義を用意しました。将来的にはinternal側にある関数定義をリファクタリングで変えてRustっぽくかけるようにしたいなと考えてます。 個人的に考えてるPros/Consも書いてみます Pros
逆に非同期処理についてはC++とRustでそこまで書きやすさは変わらないと思います。C++20でコルーチンに関するコア言語機能が入ったはずなので。 Cons
学習コストについてですがC++も学習コストは高いのであまり変わらないと思います。 |
Rust ちょっとわかるので何かお手伝いできそうであればお声がけさせていただきます…! |
ちょっとタスクを忘れないようにメモしておきます!
|
早めにonnxruntimeとリンクして動作させることができるか試したほうが良さそうですね。これができないとそもそもRust移行することができないので。 |
wrapperの活用が手軽で良さそうに感じました! |
API を見る限り、 |
それでは initializeと内部のStatus(?)の機能の一部機能実装からですかね?ちょっとやってみます |
やってみたんですが、Rustのonnxruntime wrapper だとuse_gpuが有効時に設定されたときにつかう ExecutionModeの設定や、 cudaに関する設定に使う関数がwrapperだと定義されてないようです。 |
|
お試しありがとうございます!! やっぱりRustは魅力的なので、できれば前進したいのが個人的な本音です。 詳しくないのですが、cargoはgithubから気軽にパッケージ持ってくることはできそうでしょうか。 |
以下のような感じで Cargo.toml に書くとできます: [dependencies]
clap = "2.27.1" # from crates.io
# crates.ioから
rand = { git = "https://github.com/rust-lang-nursery/rand" } # from online repo
# オンラインのレポジトリから
bar = { path = "../bar" } # from a path in the local filesystem
# ローカルのファイルシステムのパスから 引用: https://doc.rust-jp.rs/rust-by-example-ja/cargo/deps.html |
@Hiroshiba @PickledChair とりあえずforkしたのですがそもそもonnxruntime-rsで参照してるonnxruntimeの対象バージョンが1.8と少し古いようなのでそこから直していったほうがいいかもです。最新版は1.11のようです |
おお…結構古いですね… そもそもrust用のラッパーを作らず、直接dll叩くみたいなことができたりするのでしょうか。 |
RustにはCヘッダーからRustコードを生成する機能があります。onnxruntime-rsでも内部的にはその自動生成を使用してます。(onnxruntime-sysというcrateがそれです)。これがdllを直接叩くというのに該当するかと |
なるほどです。 |
はい。わたしもちょうどそれを考えていました。 |
openjtalkのbind用crateも作る必要がありますがそれはおそらくこのリポジトリで管理されると思うので、それに合わせるなら個人的にはこのリポジトリでonnxruntime bind用crateを作って良いかなと思いました |
ちょっと試しにforkしたリポジトリでonnxruntimeのバージョン上げてみたのですがコンパイル通りました。 |
たしかに一緒にcreat管理しても良いなと感じました。 |
onnxruntime導入PR作りました |
調べたところ、「macOS の arm64 版には対応しているものの、onnxruntime を自動でダウンロードする処理がまだない」という感じに思えました。環境変数として また、関連する話題なのですが、現在の voicevox_core の C++ 実装では macOS 向けに universal binary の dylib を提供していますが、現在 Cargo には universal binary をビルドするための仕組みが存在していないようなので、もし今後も universal binary を提供する場合、macOS の |
@PickledChair 自動ダウンロードの話です。ORT_STRATEGY=systemの使用については特に考えてませんでした。 |
理解しました! 実際、ビルド時に自動ダウンロードしてくれた方が便利なので、後々 M1 Mac 向けに対応を加えたいところではありますね。 |
現在 onnxruntime に関する作業を進めているかと思うのですが、落ち着いたらタスクを整理して複数 issue に分割(あるいはプロジェクトとしてまとめる)していただけるとありがたいです。 |
ご意見ありがとうございます。この issue を立てた当初からそのつもりでいたのですが、時間が取れずそのままになってしまっていました。週末に今後の工程を考えてみて、ここで提案したいと思っています。その結果に沿って issue 分割等を行えればと思います。 |
RPATHがされていないとdynamiclink時にLD_LIBRARY_PATHの設定を行わないとlink errorになってしまうため refs VOICEVOX#128
現在Cargo.lockファイルはgit管理対象外になっているが、cargoにはCargo.lockファイルをgit管理対象に入れるべき場合とそうでない場合がある。 Cargo.lockファイルをgit管理対象に入れないべき場合はcargo.ioなどでソースファイルごとライブラリとして公開し、ユーザー側でビルドする場合 git管理対象に入れる場合は配布形態がバイナリ等ソースコードに依存しない形で配布する場合 本リポジトリはcdylib形式でdllバイナリとして配布することを目的としているのでgit管理対象に入れるべきケースになる 詳しくは公式ドキュメントを参照のこと https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html refs VOICEVOX#128
* internalを構造体化して薄いラッパーにした testコードを書きやすくするため、internalのコードを一部を除いて構造体のメンバ関数とした refs VOICEVOX#128 (comment) * lint errorを修正した
* OpenJtalkを実装した refs VOICEVOX#128 * open_jtalk-rs更新 * Update crates/voicevox_core/src/engine/open_jtalk.rs mecab2njdが抜けていたので追加 Co-authored-by: Gray Suitcase <[email protected]> Co-authored-by: Gray Suitcase <[email protected]>
unsafeなコードを原則禁止にした unsafe_codeをdenyにすることにより、うっかりunsafeコードを書くのを防ぐことが目的 例外としてc関数向けの実装である c_export moduleと、static領域に配置する必要があるStatus structについてはunsafeを使うことを許可している refs VOICEVOX#128
linux,macosのshared libraryをバージョンつきのものを配置するように変更 サンプル実装より、現在配置してるshared libraryはバージョンなしのため実行に失敗するためバージョンつきのものに変更する必要がある refs VOICEVOX#128 VOICEVOX#197 (comment)
pythonのexample書くにはmainとのconflictを解消してからにしたほうがよさそう |
現状 https://github.com/VOICEVOX/voicevox_core/blob/main/core/_core.py は消えてる状態になってるんですが、これってengineからcore使う際に必要なんですかね?そうでないならexample内に実装を寄せてしまおうかと思うのですが |
あとWindowsのexampleは私の方ではやれなさそうです(環境無いので) |
Python パッケージ化をどうするかによるのかもしれません。前の Python example では example を動作させる前にコアを 一方、Python example を現在のエンジンと同様に
Windows 環境は一応あるのですが、普段 Visual Studio を全く触らないので、自分がやるとしたら調べながらの作業になり、結構時間がかかってしまいそうです……。元の Windows example を書いたのは @shigobu さんだったと思うのですが、お忙しくなければ新しいコアへの追従をお願いしたい感じがあります(それが一番早そうです)。もし @shigobu さんを含め他の方の都合がつかなければ、私がやることを検討したいと思います。 |
前者は新しく生まれ変わるpython exampleで代替できそうです。逆にpip周りの知識がいらなくなって利便性上がりそう。 パッケージとして配布するかに関しては・・・いったんこのブランチでは考えない方針にし、パッケージを配付するかを考えるissueを作る方針でどうでしょう。 |
Windows exampl修正します。 |
@shigobu ありがとうございます、本当に助かります……!(急にメンションを飛ばしてすみませんでした🙇) 以前からの変更点としては、
のような感じだと思います(他の変更点が漏れていたらすみません)。もし他に必要な情報等ありましたら PR 等で気軽にご質問ください……! |
coreのheader fileもzip同梱のものを使う必要があります |
* pythonのexampleを新しい形に変更した refs #128 * typo修正 Co-authored-by: Hiroshiba <[email protected]> * 不要な手順を削除した Co-authored-by: Hiroshiba <[email protected]>
製品版の方でもビルドできました!!(動作確認はまだですが。。) |
お疲れ様でした!!!!!!!!!!!!!!! |
内容
(以下の記述は必要に応じてアップデートしていきます。改善すべき点があればご指摘ください。)
現在、コアライブラリは C++ で記述されています。C++ は優れた言語ですが、ビルドツールなどを含め現代的でない部分が存在し、それにより開発の難しさを感じることがあります。ここで、開発言語として新たに Rust を採用することによって、開発体験が向上することが期待されるため、Rust による実装への移行を模索する意義があると考えられます。
この Issue では Rust による実装を段階的に進めるに当たって、実装の進め方や方針の議論、進捗の整理等を行うことができればと思います。
Pros 良くなる点
Cons 悪くなる点
その他、より詳しい Pros/Cons:
#128 (comment)
実現方法
作業は当面 rust branch で行われる予定です。
考えられる作業一覧:
VOICEVOX org 下に管理を移すか、あるいはオリジナルのリポジトリへの PR を目指すかは未定当面は VOICEVOX org 下で管理する (https://github.com/VOICEVOX/onnxruntime-rs) 。initialize
[Rust]onnxruntimeをrust版voicevox_coreに導入 #135finalize
[Rust]internalのfinalizeを実装した #160load_model
[Rust]internal.rsに load_modelを実装した #150is_load_model
[Rust]is_model_loadedを実装した #151metas
[Rust]load_metas,metasを実装した #140supported_devices
[Rust] supported_devices を実装した #149yukarin_s_forward
[Rust] yukarin_s_forward を実装した #157yukarin_sa_forward
[Rust] yukarin_sa_forward と decode_forward を実装(yukarin_s_forward の再実装含む) #158decode_forward
last_error_message
Rustへの移行 #126kana_parser
を含まないので、新規に実装する必要がある kana_parser 実装 #155VoicevoxResultCode
voicevox_load_openjtalk_dict
[Rust] voicevox_load_openjtalk_dict を実装した #184voicevox_tts
voicevox_tts_from_kana
[Rust] voicevox_tts_from_kana の実装 #193voicevox_wav_free
[Rust] voicevox_tts と voicevox_wav_free の実装 #186voicevox_error_result_to_message
また、並行して自動ビルド・テストも整備する:
最後に、新しいコアが期待通りに動くか確認して、移行作業完了としたいです(main branch へのマージ後に確認?)。
その他
ビルド可能な最初の貢献は @qwerty2501 さんによって行われています (#126) ありがとうございます!
The text was updated successfully, but these errors were encountered: