seri::diary::graduate_schoolスマートフォン用の表示で見るseri::diary::graduate_school大学院修士課程での研究生活について書いています2019-03-14第168回HPC研究会で口頭発表してきた研究2019年3月14日すでに先週のことなのだが、3月5日から3月7日の間に開催された第168回HPC研究会という研究会にて口頭発表をしてきた。夕食もご飯が美味しかった。何気に初めての学外での研究発表ということになった。査読なしの口頭発表、しかも研究会なので、プロの研究者から見たら大したことのない場なのかも知れない。実際、何回も発表してる「常連」のような雰囲気の人も多く、聞いてる方もずいぶんリラックスしているように見えた。入学以来、学外での研究発表が初めての自分にとっては十分緊張するに値する機会であった。epochの訓練をできるだけ高速化するミニバッチサイズを見つける最適化スクリプトをChainerのExtensionとして実装したよ、という話。今回の発表のために実装したコードは取り急ぎGithubに上げてある。ドキュメントを一切書いてないのだがこちらについてもちゃんとドキュメントを書いて別のブログ(seri::diary)の方で紹介したい。epoch当たりのforward/backwardの処理時間がいい感じに早くなるミニバッチサイズだよ」ってことを自動で判定してくれるやつである。モデルの精度は全く見ておらず、単にGPUを使い切る当たりを狙ってミニバッチサイズを調整する、という感じである。得られた最適値をそのまま使うというより、GPUを使い切るにはこれぐらいのミニバッチサイズになるということが分かるので、そこから精度に影響しない範囲でサイズを調整するとか、精度改善のために学習率を調整するとかバッチ正則化層を入れるなどの、マニュアルチューニングを入れた上で使用することを想定している。VGG16で試した限りではミニバッチサイズ196でも32や54と比べてさほど汎化性能に影響はなかった。GPUをちゃんと使い切れるかどうかというのが気になったというの2つの理由がある。VGG16みたいなトイデータだとバッチサイズは32や64からは明らかに大きくできる余地があった。iterationごとに1秒ほど存在しており、ミニバッチサイズを増加させてもなかなか性能改善につながらないということがわかった。ResNetのサンプルだと、この問題を回避するために非同期でデータをロードするMultiProcessIteratorを使用している。MultiProcessIterator使えばいいじゃん、でこの話は正直言って終わりなのだが、逆に言えばMultiProcessIteratorのような機構がない場合は、画像サイズが32x32から高々224x224になるだけで随分とGPUの利用が阻害されるという問題が簡単に起きるということを示している。これは一般的に知られているんだかいないんだか分からないが、安易に訓練データのサイズを上げることの影響は予想以上に大きいということを示唆しているという点でそれなりに意味のある発見。ないだろうかと勝手に思っているのだが、どうなのだろう。周りに深層学習ガチ勢がいないのでちょっと分からない。ガチ勢が集まる場所で聞いてみたい。今回の研究発表はこんな感じであり、会場からはいくつか質問もいただいて、最低限伝えたいところは伝わったようなのでホッとしている。このOptimizerのコードはそのうち公開する予定である。数百行で作れるExtensionなので、自分の書いた原稿を読めば誰でも作れそうなモンであるが、一応ちゃんと動くものができたのでそれはそれで意味があるのではないだろうか。最近とても精神的につらい。profileseri::diaryseri::diary::competitive_programmingはてなブログをはじめよう!serihiroさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。