この記事はtraPアドベントカレンダー2019の 56日目(12/25) の記事です。
19の翠(sappi_red)です。普段はSysAd班で部内サービスを触ってます。
このアドベントカレンダーではこれが二記事目で、一記事目はそのSysAd班でのことを書いているのでよろしければそちらもぜひ。^[1]

Web Assembly

2013年頃に「C言語などのJavaScriptではない別の言語をブラウザで効率よく実行したい」というasm.jsやPNaClが登場しました。
それらの流れを汲み取りながら開発が進められてきたWeb Assemblyの仕様が、6年ほど経った今月の頭にW3Cで勧告に到達しました。

このニュースを見て、以前より気になっていたTensorFlow.jsのwasm対応のissueを思い出し、確認したところアルファ版が出ていることに気づきました。
これは試してみるしかないということで試してみました。

TensorFlow.jsのwasmを試す

以前、らんぷろ(traPの全体集会でのLT)で発表した定点動画から背景画像を抽出するツール(ソース)で試していきます。
らんぷろのときは、時間指定もできずシングルスレッドで処理をするようなものでしたが、今回前後の時間指定ができるようにし、処理もマルチスレッドに書き換えました。^[2]

実行するとこのように抽出できます。^[3]

以下の図のように処理を行っています。

利用しているモデルはPretrained Tensorflow.js ModelsにあるBodyPix v2のMobileNetV1(multiplier 0.75)です。

READMEの通りにimportなどをするだけで特に難しいことをせずに簡単にwasm版に差し替えられました。^[4]

ですが、アルファ版ということもあり、そんなにサポートされている関数は多くないので、サポートされてない関数使ってるよっていうエラーが出ました。

ということでプルリクをいくつか送って動くようにしました！^[5]
これらのプルリクはマージされて、TensorFlow.js backend wasm v1.5.0-alpha4で利用可能になってます！

パフォーマンス

JSはJavaScript版のことで、Chromeの設定から「ハードウェアアクセラレーションが使用可能な場合は使用する」を無効にすることで計測しました。
wasmは「ハードウェアアクセラレーションが…」を無効にして、Chrome Flagsなどをdefaultの状態でwasm版を実行したものです。
wasm-Sは上記wasmの状態からchrome://flagsのwasm SIMDを有効に変えた状態でのwasm版を計測したものです。^[6]
WebGLは「ハードウェアアクセラレーションが…」を有効にしたものです。

^が前についている値はシングルスレッドで実行しています。
()で表記したものはChromeのタブ一つで使えるメモリで足りなくなって落ちたり、処理がほぼ進まなくなったりするのでフラグ^[7]をつけて実行したものです。(なので自分のツールの実装でこれらの画質のものを処理するのはあまり実用的ではない)
タスクマネージャーを見るとChromeに落とされているのがわかりますね。

自分が実装した関数はSIMDに対応させれていないこととSIMDに対応していない関数が他にもあるので、wasm with SIMDは今後速くなっていくと思われます。(有効にすると軒並み遅くなる原因はわからないですが…)(うまく有効にできてなさそう…)

大学に持っていっているノートPC(i7 8550U/RAM 8GB/Intel UHD Graphics 620)だとJS版では動きはじめすらしないのがwasm版だとそこそこ動きます。速さの傾向は上の表と同じ感じです。(1440pとかは時間がかかりすぎるのとメモリが足りないですが)

公式のREADMEでは、wasm版の利点としてWebGL版よりも幅広い端末で利用可能である点と、重くないモデルであればWebGL版とほぼ同等、重いモデルであってもWebGL版より5～7倍程度の遅いだけでありJS版よりは相当速いという点があると書かれています。
さらにこれら以外の利点として、モデルの処理が軽い場合ならGPUのオーバーヘッドのが大きいのかCPUでマルチスレッドでwasmを用いて処理を行う方がかなり速く処理ができるということがわかりました。^[8]
また、マルチスレッド化することでモデルの処理が重い場合でもWebGL版の1.5～3倍あたりまで近づけるということもわかりました。
CPUとGPUの性能のバランスにもよりますが、利用した環境は割と一般的なバランスだと思います。
wasm自体からマルチスレッドを利用できるようにする提案も出ているので(現在Stage2)、JavaScriptを介しているこのツールの実装よりも今後高速に動作するようになるでしょう。

タスクマネージャーを見ると、GPUのVideo Decodeの欄が頭打ちになっていたみたいだったので、「ハードウェアアクセラレーションを有効にして動画のデコードをGPUで行うようにして、モデルの処理はwasmを利用してCPUで行うようにすると、もしかしたら速くなるかもしれない」と思い、試したのですが、上の表のwasmよりも遅くなりました。原因として、GPUとCPU間のPCIeの転送速度が足りないのかもしれないですがよくわからないです。(これが原因ならX570マザーボードにしてグラボをRadeon RX 5700 XTあたりにすると改善するのですが、さすがに調達できないので…)

ただし、この計測はChrome77という少し古いバージョンで行っています。最新版のChrome(Stable/Dev/Beta/Canary)で行うとJS版の動作がすごく遅いということがあったのが理由です。また、動画のデコード処理をGPUで行ってwasm版を使用するとうまく動かないということも発生しました。(よくわからないですが内部的なblob:～.webmの206 Partialリクエストがうまく返ってこないみたいです)

利用したツール(ソース)は?p_time=true&wasm=true&single=trueをURLにつけることで動作を変更できるようにしてあります。指定しなかったものはfalseとして扱われます。

• p_timeはコンソールに処理時間を出力する
• wasmはwasmを使用する
• singleはシングルスレッドで処理をする

終わりに

wasm版が出たことで今後軽いモデルを手元で動かすことはある程度気軽に行えるようになっていくのかなって思います。
細かなところで活用されていくと面白そうです。

コラム

#ifdef _WIN64 // 利用したマシンはWindowsの64bitなのでifdefの中が実行される
  size_t memory_limit = static_cast<size_t>(sandbox::kDataSizeLimit);

  int64_t GB = 1024 * 1024 * 1024;
 
  int64_t physical_memory = base::SysInfo::AmountOfPhysicalMemory();
  if (physical_memory > 16 * GB) {
    memory_limit = 16 * GB;
  } else if (physical_memory > 8 * GB) {
    memory_limit = 8 * GB; //利用したマシンの物理メモリは16GBちょうどなのでこっち
  }
  return policy->SetJobMemoryLimit(memory_limit); // 最大8GBまでにセットされる
#else
  return sandbox::SBOX_ALL_OK;
#endif