WORLDのさらなる高速化なと

M. Morise (忍者系研究者) @m_morise

ところでWORLDにCUDAを導入する案がありましたが，音声処理のようにFFT長が4桁前半の場合，全然早くならないオチがあり断念しました．

しゅらぴばー @shurabaP

@m_morise 前検討したことがあったんですがボトルネックはどのあたりなのですか？次元数高くて嫌だなあという程度でやめたのですが。

M. Morise (忍者系研究者) @m_morise

@shurabaP 主にボードとの通信速度ですね．大量のデータを一度に渡してFFTする用途じゃないと通信速度のほうが高くつきます．

しゅらぴばー @shurabaP

@m_morise ああ、やはりですか。上りも遅そうですが下りは悲惨だろうなあと考えて没にした記憶があります。学科としてはまさにそこが専門なんですけどね。

M. Morise (忍者系研究者) @m_morise

@shurabaP 音声処理の場合，GPGPUにメリットは無さそうです．やはりOpenMPなどの導入で並行処理にするのが時代の流れにはあいそうですね．WORLDの実装は並列処理と相性が良くなるようフレーム単位で完結させるように書いています．

しゅらぴばー @shurabaP

@m_morise やはりそうですか．どのシステムを対象にするかですが，最近のCPUでは並列化が高速化に直結してしまうので工夫の市街がなくて悲しいです．その分いろいろ処理できてありがたいんですけどね…

しゅらぴばー @shurabaP

音声のGPGPUとか点数が多すぎていいイメージが思い浮かばない．信号処理のプリミティブなところをGPGPUで，っていうのはあまりいい方法では無いんだろうなあ．

M. Morise (忍者系研究者) @m_morise

@shurabaP 歌声に話を限定するなら全ての処理を内部的にサンプリングを22.05 kHzに落とすだけで随分とパフォーマンスは上がりますけどね．音声なら22.05 kHzサンプリングでも品質にあまり影響しません．

M. Morise (忍者系研究者) @m_morise

@shurabaP それと，どこまでオンライン性を求めるかも重要ですね．無理して1%速度を挙げるために品質を下げるくらいなら，半年くらい待って新しいPC導入するほうが良いという考えもありますので，そのトレードオフは色々悩みがあります．

しゅらぴばー @shurabaP

@m_morise ひとまず今のところCore2Duoをベースに考えているんですが，買い換えタイミング考えたらそろそろCore iシリーズを考えていいような気もします．大量のメモリアクセスがある音声信号処理だと，Core iの速度は異常に速いのでマルチスレッダイズで事足りるかも…

M. Morise (忍者系研究者) @m_morise

@shurabaP それと使い手がどのくらい気が長いのかは我輩には分からないところです．自分で使う分には今の速度で全く不満はありませんけど，人によってはダメなんだろうな，と．

しゅらぴばー @shurabaP

@m_morise 僕は割と気が短い方なので，リアルタイムに合成できないとちょっと，となるので今回変な高速化していますが…正直モーフィングやその他のアルゴリズム側の重さも実装で異なるはずなので，マルチスレッダイズして余裕がある現在は十分であると判断はしています．

M. Morise (忍者系研究者) @m_morise

@shurabaP 合成の場合，理論的にはストリーミング再生に間に合えば問題無いですね．信号処理レベルでの高速化はもはや重箱の隅をつつく程度の改善しか期待できないので，我輩は自分の得意なテーブルで勝負することにします．

しゅらぴばー @shurabaP

@m_morise 合成を考えればWORLDは名前の通りものすごく速いので，分析をどうごまかすか力技に任せるのか，と言ったところでしょうか．実装側で速度がどうとでもなると思いますし，下地にするには十分というかものすごく速いはずです．

しゅらぴばー @shurabaP

WORLDの速度は，実装側で殺さなければ，十分すぎるのでｓ．

しゅらぴばー @shurabaP

速度は応用アプリ側の実装で遅くなるし…

Eji @ejiwarp

@shurabaP ログを見るとなんかGPGPUの話をしていたらしい。以前 @heigazen さんのところも確かにCUDAで言語分析とかの話があったけどどうなってるのかな。

しゅらぴばー @shurabaP

@ejiwarp どうなんでしょう．本来専門のはずなんですが，あまり詳しくなくてお恥ずかしい…WORLDはじめ音声分析合成系などの低レベルAPIの場合データ数が多すぎて扱いづらいのは間違いないです．データの転送がネックですしね．

Eji @ejiwarp

@shurabaP GPGPUはやはり画像みたいなものがやりやすいよね。ピクセルの間にあまり関連性が多くないから並行化しやすいとか。音は時間性的なもので....

しゅらぴばー @shurabaP

@ejiwarp 組んでみないとわからないのですが，GPGPU内で処理が完結するならお得にはなるかもしれないけど，ちょっといい使い道が思いつかないです．なんかもう，Core i7とかで8スレッド立ててぶん回したほうが楽そうとか思ってしまいます…

Eji @ejiwarp

@shurabaP ただ8スレット以上はサーバー用CPUなんで値段かかるよね。Appendみたいな複数DB同時合成はすごく性能かかるものになると実用化はだいぶ先になるから惜しいね....そこでGPGPUを考えるだがさすがにためになさそう。

しゅらぴばー @shurabaP

@ejiwarp WORLDの合成速度ならCore2Duoで2コア使えば工夫次第でなんとでも，とか思ってしまいます．合成だけならものすごく速いので，高速化するほどではないです，多分．HMMの学習は時間がかかるので，その辺高速化している人たちはいるみたいですが．

Eji @ejiwarp

@shurabaP あ、たしかにそうですね＞GPGPUを利用してHMMの学習時間の短縮化

しゅらぴばー @shurabaP

@ejiwarp 確率・統計モデルは門外漢というか勉強し始めたばかりなので，ちょっとどうなってるかは分かりません．