-
Notifications
You must be signed in to change notification settings - Fork 196
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
ビルド済みエンジンに Rust 実装のコアを含めるようにする #510
Merged
Hiroshiba
merged 10 commits into
VOICEVOX:master
from
PickledChair:feature/use-rust-core
Dec 1, 2022
Merged
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
81b43bd
依存するvoicevox_core, onnxruntime, cuda, cudnnのバージョンを更新
PickledChair 327b207
コアの名前の変更を反映
PickledChair abf33ca
tar.xzを解凍するためのオプションに変更
PickledChair cb7eaaa
cudnnの配布物のディレクトリ名変更に対応
PickledChair fb09ad8
UbuntuとmacOSのバージョンを上げる
PickledChair c13aed8
コアのバージョンを0.14.0-preview.2に上げる
PickledChair bd68707
テスト環境のUbuntuのバージョンを20.04に固定
PickledChair 3a66868
cudnnのダウンロード物の拡張子をtgzからtar.xzに修正
PickledChair 498112f
onnxruntime, cuda, cudnn のライセンスを更新
PickledChair aaeb385
flake8によるlintエラーを抑制
PickledChair File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
あ~~~ universal2じゃなくなると、どうなるんでしたっけ・・・。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
特に影響はないはずです!(エンジンの実行ファイル
run
自体が x64 向けであることから、M1 Mac においてこれまでも universal バイナリのうち x64 向けの部分が rosetta で翻訳されて使われていたと考えられるため。)強いていえば macOS 向けのビルド済みエンジンのサイズが数百 MB 小さくなるので、利点の方が大きいと思います。There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
M1 Mac向けにエンジンのmacOS arm64バイナリもしくはuniversal2バイナリも今後リリースするようにしますかね...?
PyInstallerのドキュメントを見ると、macOS x64(GitHub Actions)上でuniversal2もしくはarm64単体のバイナリをビルド(クロスコンパイル)できそうな感じがしました。コアのファイルサイズが2倍になってしまうので、いったんarm64単体のクロスコンパイルの方がいいかなと思っています。
PythonがmacOS universal2バイナリの提供を始めたのがPython 3.9からのようなので、Python 3.8からPython 3.9以降に移行する必要があるかもです。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
なんと。。。。w
動的ライブラリだからコアはuniversalのほうが使われている・・・とかだったら嬉しいですね・・・。
やっても良いなと思いました。macだと結構重いという意見もちょくちょく見かけるので、動作が軽くなるのであれば嬉しそうです。macだし(?)、容量<動作かなと!
まあどちらにせよ、エンジン側をuniversal2にできないと、コア側をuniversal2にする意味はあまりなさそうですね。
とりあえずエンジン側とコア側にissue作る・・・?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
そうだったら便利だったのですが、実際はそうではないようです……。
一応 universal バイナリの仕組みを大雑把に説明すると、x64 向けのバイナリと arm64 向けのバイナリがくっつけられたバイナリであり、実行環境に合わせて適切な方のバイナリを用いる仕組みになっています(このためバイナリサイズが大きくなります。単純に考えると約2倍のサイズになります。"fat binary" とも呼ばれています)。
M1 Mac において、Rosetta で起動した x64 バイナリが universal バイナリの dylib をロードするときに、dylib 内のどちらのバイナリが用いられるのか気になったので、手元で実験してみました。残念ながら x64 バイナリの方が用いられるようです……(Apple のドキュメントで説明されている方法を参考に、以下のようにどちらのバイナリが実行されているのかを判別する実験を行いました)。
用いられているバイナリの種類の判別実験
検証コード
実験結果
備考:M1 Mac 上でビルド&実行
確かに Python インタプリタ自体は universal2 バイナリを提供していますが、サードパーティ製ライブラリについても universal2 対応を行わなければならないだろう、と考えられます。
調べたところ、最もメジャーなライブラリの1つである NumPy ですら universal2 対応の wheel を PyPI や GitHub Releases で提供していないようです。つまり単純に
pip install
することができません( numpy/numpy#20787 で活発な議論が行われたようですが、コストに見合った需要があるとは考えられないという理由で、universal2 wheel が欲しい開発者自身がツールを使って自分で構築するべき、という結論でとりあえず終わっています。ツールとしてdelocate-fuse
が挙げられています)。これを踏まえると、原理的には、各依存ライブラリについて x64 向けと aarch64 向けの wheel を取得してツールで universal2 wheel にマージするということを事前に行えば、universal2 対応のエンジンを提供することは可能かもしれません。ただ、見通しとしては作業はある程度長期的なものになると思います:
lipo
コマンドで可能)(余談ですが、GitHub Actions の Self-hosted runners が Apple Silicon に対応していることがこの記事に書かれていますが、
setup-python
に問題があり何らかの workaround が必要そうでした。これを用いて universal2 バイナリではなく単純に Apple Silicon 向けのエンジンを用意するという案も考えられます。実行マシンはどうするのか? という疑問はさておき……)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
なるほど・・・・・・・・・・・。盲点でした。
universal2対応までの道のりもよくわかりました・・・。なかなかの道のりですね・・・。
ちなみになのですが、x64 向けと aarch64 向けの両方のバイナリを提供するという感じだとだいぶ楽になったりするのでしょうか・・・?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ビルド環境としてaarch64(Apple Silicon Mac)を使うことができると仮定したとき、Intel Mac 向けに構築したビルド手順をそのまま使いまわせる見込みが大きいと思います。universal ビルドの手順を構築するより単純にかなり手数が減りそうです。