ビルド済みエンジンに Rust 実装のコアを含めるようにする #510
Conversation
Coverage ResultResultを開く
|
今まではGithub Actionsがサポートする一番古いOSでビルドしていたので、コア側もlatestではなく一番古いものを指定するようにするのはありかなと思いました。 |
調査ありがとうございます！面白いことがおきました。 そしてmacos-11の方ですが、今確認したところmacos-latestは 原因は不明ですが、一瞬macos-12がlatestになったのかなと思いました。 |
|
（@PickledChair さんに聞いたのですが、 |
|
基本的には最初に提案した
という意見ですが、Linux を常用していないので Ubuntu のサポートバージョンの感覚がちょっとよくわかっていません……（macOS の方は、GitHub Actions でビルドするようにしている以上は仕方がないかな……という感じです）
賛成です……！（少なくともビルド用の CI に関して。テスト用途の CI は latest を使うままにして良さそうです。）コアの方では latest 指定が多いのでそちらも変更したいですね。 |
私はLinuxユーザなのですが使ってるのがArch Linuxというローリングリリースのディストロなので、Ubuntu使いの感覚はよくわからないです。デスクトップ用途/サーバー用途で18.04→20.04 (OR 22.04)のアップグレードがどれほど大変なのかによりますが、やったことが無いので...
同じく賛成です。 |
コアも20.04が良いと思ってます。 |
|
Ubuntuについてですが、基本的に新しいLTSのバージョンにアップデートするで良いかなと思います。私はそうしてます。 |
|
ただ Github Actionsのlatestの先が20.04になってるのでまだ20.04でいいかもです |
|
できるかぎりいろんなユーザー環境で動くと嬉しいという思いがあります！ （まあどちらにせよ今回の対象はubuntu 20.04ですね･･･！） |
UbuntuはWindowsほど互換性を意識しているものではないので、LTSサポート期間中でもバージョンが違ったら動かなくなるというのは普通にありえます。現にいまバージョンを変えようとしている18.04はまだLTSサポート期間中ですがこういった事態になっているのでたとえLTSサポート期間中であってもどこかのタイミングで切り替えなければならないことは留意しておいたほうが良いと思います。 |
|
PRわけるべきだとは思いますが、ダウンロードスクリプト使うようにしたほうが良さそうですね |
|
ubuntuのバージョン管理に関して、なるほどです。なんかいつの間にか動かないみたいなのが普通にありえるんですね。 なるべく多くのユーザーに届けたいのはバリューをそう定めているためです。 あとlatestを使わずに固定しておくのは、サポートしていると思っていたOSバージョンがいつの間にか切れていた（切っていた）ということを避けられるので、メンテナ的にはバージョン指定のが嬉しいです。 |
既にあるダウンロード＋ビルド機構をダウンロードスクリプトに合うようように改変するのには時間がかかるので一長一短って感じでしょうか。 |
|
@PickledChair おまたせしました、ubuntu20などでビルドしたリリースを作ってみました！ |
ありがとうございます！ このバージョンのコアを用いた試験的なリリースをまた作ってみました https://github.com/PickledChair/voicevox_engine/releases/tag/0.14.0-pickledchair-preview.2 今回はビルド後のテストも全て通るようになりました https://github.com/PickledChair/voicevox_engine/actions/runs/3539386199/jobs/5942421157
ご指摘ありがとうございます！ 当初、初めからダウンロードスクリプトを用いる予定だったのですが、作業量が多そう（問題が起きた時のデバッグが大変そう）だったので、とりあえず単純な変更に留めた上での PR としました（ @Hiroshiba さんのアドバイスもありました）。ダウンロードスクリプトを使うようにした方が良いというのは私も同意見です。Issue 作成ありがとうございます……！ |
|
おー！！
なるほどです。とりあえず20.04で確認できればOKなのかなと思いました！！ |
| artifact_name: windows-nvidia | ||
| # Mac CPU (x64 arch only) | ||
| - os: macos-11 | ||
| architecture: "x64" | ||
| voicevox_core_asset_prefix: voicevox_core-osx-universal2-cpu |
There was a problem hiding this comment.
あ～～～ universal2じゃなくなると、どうなるんでしたっけ･･･。
There was a problem hiding this comment.
特に影響はないはずです！（エンジンの実行ファイル run 自体が x64 向けであることから、M1 Mac においてこれまでも universal バイナリのうち x64 向けの部分が rosetta で翻訳されて使われていたと考えられるため。）強いていえば macOS 向けのビルド済みエンジンのサイズが数百 MB 小さくなるので、利点の方が大きいと思います。
There was a problem hiding this comment.
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.
エンジンの実行ファイル run 自体が x64 向けであることから、M1 Mac においてこれまでも universal バイナリのうち x64 向けの部分が rosetta で翻訳されて使われていたと考えられるため。
なんと。。。。ｗ
動的ライブラリだからコアはuniversalのほうが使われている･･･とかだったら嬉しいですね･･･。
M1 Mac向けにエンジンのmacOS arm64バイナリもしくはuniversal2バイナリも今後リリースするようにしますかね...?
コアのファイルサイズが2倍になってしまう
やっても良いなと思いました。macだと結構重いという意見もちょくちょく見かけるので、動作が軽くなるのであれば嬉しそうです。macだし（？）、容量＜動作かなと！
まあどちらにせよ、エンジン側をuniversal2にできないと、コア側をuniversal2にする意味はあまりなさそうですね。
とりあえずエンジン側とコア側にissue作る･･･？
There was a problem hiding this comment.
動的ライブラリだからコアはuniversalのほうが使われている･･･とかだったら嬉しいですね･･･。
そうだったら便利だったのですが、実際はそうではないようです……。
一応 universal バイナリの仕組みを大雑把に説明すると、x64 向けのバイナリと arm64 向けのバイナリがくっつけられたバイナリであり、実行環境に合わせて適切な方のバイナリを用いる仕組みになっています（このためバイナリサイズが大きくなります。単純に考えると約２倍のサイズになります。"fat binary" とも呼ばれています）。
M1 Mac において、Rosetta で起動した x64 バイナリが universal バイナリの dylib をロードするときに、dylib 内のどちらのバイナリが用いられるのか気になったので、手元で実験してみました。残念ながら x64 バイナリの方が用いられるようです……（Apple のドキュメントで説明されている方法を参考に、以下のようにどちらのバイナリが実行されているのかを判別する実験を行いました）。
用いられているバイナリの種類の判別実験
検証コード
/* test.c（このコードを universal バイナリの libtest.dylib へとビルドする） */
#include <sys/sysctl.h>
#include <sys/errno.h>
/* 実装されているバイナリがarm64なら0, x64なら1, エラーなら-1を返す */
int processIsTranslated() {
int ret = 0;
size_t size = sizeof(ret);
if (sysctlbyname("sysctl.proc_translated", &ret, &size, NULL, 0) == -1) {
if (errno == ENOENT)
return 0;
return -1;
}
return ret;
}/* main.c（このコードから実行ファイルをビルドする。arm64 バイナリは main, x64 バイナリは main1） */
#include <stdio.h>
#include <dlfcn.h>
int processIsTranslated();
int main() {
void *handle = dlopen("libtest.dylib", RTLD_LAZY);
if (handle == 0) {
fprintf(stderr, "%s\n", dlerror());
return 1;
}
int (*processIsTranslated)(void) = dlsym(handle, "processIsTranslated");
int processKind = processIsTranslated();
switch (processKind) {
case 0: printf("native process\n"); break;
case 1: printf("translated process\n"); break;
default: printf("occur error\n"); break;
}
return 0;
}実験結果
備考：M1 Mac 上でビルド＆実行
$ lipo -info libtest.dylib
Architectures in the fat file: libtest.dylib are: x86_64 arm64
$ cc -o main -arch arm64 main.c
$ lipo -info main
Non-fat file: main is architecture: arm64
$ ./main
native process
$ cc -o main1 -arch x86_64 main.c
$ lipo -info main1
Non-fat file: main1 is architecture: x86_64
$ ./main1
translated process
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以降に移行する必要があるかもです。
確かに Python インタプリタ自体は universal2 バイナリを提供していますが、サードパーティ製ライブラリについても universal2 対応を行わなければならないだろう、と考えられます。
調べたところ、最もメジャーなライブラリの１つである NumPy ですら universal2 対応の wheel を PyPI や GitHub Releases で提供していないようです。つまり単純に pip install することができません（ numpy/numpy#20787 で活発な議論が行われたようですが、コストに見合った需要があるとは考えられないという理由で、universal2 wheel が欲しい開発者自身がツールを使って自分で構築するべき、という結論でとりあえず終わっています。ツールとして delocate-fuse が挙げられています）。
これを踏まえると、原理的には、各依存ライブラリについて x64 向けと aarch64 向けの wheel を取得してツールで universal2 wheel にマージするということを事前に行えば、universal2 対応のエンジンを提供することは可能かもしれません。ただ、見通しとしては作業はある程度長期的なものになると思います：
- Python 自体のバージョン更新（少なくとも 3.9 以降、理想的には 3.10 以降）
- 依存ライブラリのバージョン更新（NumPy を含む一部のサードパーティライブラリは、現在のバージョン指定では Apple Silicon Mac ではインストールできない）
- コアの universal2 バイナリの作成（これは
lipoコマンドで可能） - 前述の universal2 wheel のマージ処理の構築
- PyInstaller でのビルド処理における universal2 ビルド対応
（余談ですが、GitHub Actions の Self-hosted runners が Apple Silicon に対応していることがこの記事に書かれていますが、setup-python に問題があり何らかの workaround が必要そうでした。これを用いて universal2 バイナリではなく単純に Apple Silicon 向けのエンジンを用意するという案も考えられます。実行マシンはどうするのか？ という疑問はさておき……）
There was a problem hiding this comment.
確かに Python インタプリタ自体は universal2 バイナリを提供していますが、サードパーティ製ライブラリについても universal2 対応を行わなければならないだろう、と考えられます。
なるほど･･･････････。盲点でした。
universal2対応までの道のりもよくわかりました･･･。なかなかの道のりですね･･･。
ちなみになのですが、x64 向けと aarch64 向けの両方のバイナリを提供するという感じだとだいぶ楽になったりするのでしょうか･･･？
There was a problem hiding this comment.
ちなみになのですが、x64 向けと aarch64 向けの両方のバイナリを提供するという感じだとだいぶ楽になったりするのでしょうか･･･？
ビルド環境としてaarch64（Apple Silicon Mac）を使うことができると仮定したとき、Intel Mac 向けに構築したビルド手順をそのまま使いまわせる見込みが大きいと思います。universal ビルドの手順を構築するより単純にかなり手数が減りそうです。
|
@aoirint さんもレビュー頂けると心強いです！！ |
|
このPRで更新しているONNX Runtime, CUDA Toolkit, cuDNNのバージョンは更新しておきたいかもです。 |
本当ですね……とりあえずご提案の通り、 |
|
おお･･･ライセンス部分まで考えが及んでいませんでした。ありがとうございます 🙇♂️ |
|
Pythonバージョンを見ていて気付いたのですが、 Python 3.8のリリースサイクルを見ると、バイナリ更新（新しいバグ修正バージョンの公式バイナリがリリースされる期間）が2021年5月の3.8.10で終わっていて、Windows向けビルドのPythonバージョンが古い原因になっていそうかもです（もしかすると、サードパーティのPythonバイナリ=actions/setup-pythonではPython Foundationが署名できないから...?）。 Python 3.9も同じくバイナリ更新が2022年5月で終わっているようです。
|
|
あー、サポート期限はもっと長いけど、バイナリリリースはかなり短いんですね･･･。 |
|
マージします！リリースも作ってみようと思います 🙏 |
内容
配布するビルド済みエンジンに初めから含めるコアを Rust 実装のものにする変更です。0.14.0-preview.1 のコアを用いています。
関連して、onnxruntime, cuda, cudnn のバージョンを、コアのリポジトリで用意されているダウンロードスクリプトでダウンロードされるバージョンの方に揃えました。
自分のリポジトリで試験的なリリースを作成しました： https://github.com/PickledChair/voicevox_engine/releases/tag/0.14.0-pickledchair-preview.1
関連 Issue
close #481
その他
最後に行われるビルド済みエンジンの動作テストにおいて、最初は Ubuntu と macOS でのテストが失敗していました（ログ：https://github.com/PickledChair/voicevox_engine/actions/runs/3451900628 ）。
OS のバージョンを上げると、Ubuntu についてはテストが成功するようになりました（ログ：https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22/ ）。macOS では引き続き失敗します。
以下に各環境ごとの状況を説明します。
Ubuntu
テスト環境のバージョンを 18.04 から 20.04 に上げると、テストが成功するようになりました。原因はコアのビルド環境のバージョン（
ubuntu-latest）と glibc のバージョンが異なるからです。問題解決のための選択肢が２つあります：
macOS
テスト環境のバージョンには macOS 10.15 が使われていました。これも GitHub Actions のタスクランナーとしては deprecated になっていました cf. https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22/ 。テスト失敗の原因は Ubuntu の場合と同様で、コアのビルド環境 （
macos-latest。これはmacos-12にあたる）と libc++ のバージョンが異なるからです。そして、次のバージョンである macOS 11 にバージョンをあげてもテストが失敗します。libc++ の互換性がなくなったのは
macos-11とmacos-12の間のようです（実際、手元の環境 macOS 12 と 13 ではビルドしたエンジンが起動可能できました）。問題解決のための選択肢が２つあります：
以上を考えると、個人的には
のが選択肢として良いと考えました。その他のご意見がありましたらご提案いただけると幸いです。