国際会議にshort paperがacceptされた
2019/10/21
この時にsubmitしたpaperの結果が帰ってきて，weak accpet 3, border line 1, reject 1でshort paperとしてacceptされた．
serihiro-graduate-school.hatenadiary.jp
acceptされた会議は6th IEEE/ACM International Conference on Big Data Computing, Applications and Technologiesというやつで，12月にニュージーランドのオークランドで開催される．12月のニュージーランドなので夏なのだろうか．
レビューを読んだら随分と厳しいことが書いてあったのでなぜ通ったのかよく分かってないのだが，weak acceptのポイントをコツコツ重ねたのが効いたのだろうか． とはいえshort paperなのでお情けでページをもらった感じのように思う．
結果が出たのが先週で，先週末に急いで4 ページに再編した． 9 ページ半ぐらい書いたのを無理やり4 ページに納めるためにsectionをまるまる一個削除したり，苦労して書いた図を何枚も削除しなければならなかった．実装に関する詳細もあまり書けなくなった．レビュアー曰く「アイデアは明快で単純」「グラフィカルな説明は不要」とのことだったので意を決してバッサリと削り，それ以外も本筋とは関係が薄い内容をすべて削った．
2 週間ぐらい休みなしでぶっ通しで作業した内容をすべて捨てたような感じで，本当につらかった*1．この期間に，インターンにでも行ってた方が良かったのではないかとかバイトして金貯めて時間のあるうちにどっか旅行にでも行った方が良かったのではないかと色んなことを考えた．仕事でやってるならまだしも，何のリターンもない中で論文を書いているので，色々と厳しい．
最近は就活もしていてうまく行かないこともあって色々とナーバスになりやすいことが増えている． 普通は会社に所属しながら大学院に来るんだと思うけど，仕事を辞めて退路を断って大学院に来るというのは思っていた以上に厳しかった．これも自分が「web屋に戻りたくない」と欲を出してしまってしまった結果なのだから自業自得である．
しかし，エンジニアとしてのキャリアを大きく変えることが出来る確率は，ここ数年では今が一番高いだろうと思う．精神的にぶっ壊れたらおそらくそこで自分は歩みを止めるだろうけど，今はまだ止まっていない．
自分なりの論文の書き方
これは何か
- これまで3本（日本語2本，英語1本）論文を書いた経験を元に自分なりに手順をまとめておく．
- あくまで手順を書き下すのみで，細かいテクニックについては触れない． 合わせて読みたいに参考になりそうな文献をまとめておく．
前提事項
- 筆者はM2の学生．
- 筆者は査読なしの研究会（日本語）と査読付き国際会議（英語）での口頭発表の経験がある
- 筆者は一度国際会議（BDCAT 2019）にshort paperとしてギリギリacceptされた経験を持つ
- 筆者はHPC分野の研究室の人間
- 筆者は深層学習におけるストレージ周りに関する研究が専門
関連研究を読む
- Google scholarとかでキーワード入れて検索する
- 対象のジャーナルや国際会議が絞れるなら過去のproceedingsを直接探す
- 自分の場合，読む論文の優先順位は大体以下の通り
- abstract，conclusionを読んで関連してそうなものを探す
- 見つけた論文はMendeleyとかで管理しておき，いつでもどこでも参照できるようにしておく
- 暇な時に読もう
- 良い論文が見つからないときは素直に指導教官にヘルプを求める
スケジュールを立てる
- 出す会議の締め切りから逆算してスケジュールを立てる
- 24時間作業できるわけがねぇだろ．1日に作業できるのはせいぜい6時間ぐらいで見積もる．
- 人間は見積もりが下手くそないきものである．「自分が直感で立てたスケジュールの2倍が実際にかかる工数である」ぐらいに安全率を取っておくのが無難．
- 土日は休むスケジュールを立てる
- 逆に平日は決めた作業時間は死守する気持ちが重要
研究する
- 研究は基本孤独との戦い
- 他の学生と適度にダベりながらやる
- 孤独を避けるためにも研究室に来て作業する
- 一番の敵は己の心の弱さ
- メンタルを壊さない程度にがんばる
- 毎日日報ををつけると進捗出ている感が出るのでおすすめ
- 淡々と進捗を出し続ける事が重要なので，毎日決まった時間に始め，決まった時間に帰るリズムをキープする
- 深夜に作業するのはテンション上がるけどおすすめしない．体調を崩しやすくなるし，人間は昼間に活動する前提でこの社会はできている．
- 実装について
- バグってて間違った結果を論文に書いてしまうと大変ヤバいので，できればテストを書く
- テスト書いてる暇がない場合でも，動作確認する方法を最初に十分に検討し常に結果が正しいことを確認する
- 仕事と違って人に読ませるコードではないのでコードのメンテナビリティはそこまで重要じゃない．自分が読めれば十分，ということで妥協しつつどんどん進める．
- 仕事と違って研究における実装は「評価結果とセットで初めて価値が生まれる」ぐらいに思っておいた方がいい
- OSSにするのは後からでもできるので，その時に思う存分リファクタしよう
- コードは必ずGitHubかBitbucketなどの外部サービスを利用して管理する
- 性能評価するときのコツ
- 闇雲に計測せず，「何が示せれば自分の主張の裏付けになるか？」をまずしっかり考える
- 自前のtimerコードを挿入して計測してもいいが，profilerが使える場合はprofilerの方がより正確な情報が取れるし変なミスは起きづらい
- print文はできるだけ入れない．性能に与える影響が結構バカにならない（体験談）
- 計測に使うログのフォーマットは後で集計しやすいように最初から整形された状態で出力されるようにしておく
- 自分はログの集計にRを使う事が多いのでCSVにしておくことが多い
- 計測に使ったログは日付，タイムスタンプをファイル名に入れて全部残す
- 計測に使ったログは必ずバックアップを取る
- きびしくなったら素直に指導教官にヘルプを求める
論文を書く
- texのテンプレが指定されている場合はなるべく早く自分の手元でビルドできるかを検証しておく
- 本文は
Motivationから書き始め，次にMethodology,Evaluation,Discussionを書く- 間違っても
Abstract，Introduction，Background，Conclusionといったsectionからは書かない．この辺は書いてるうちにどんどん内容が変わっていくぞ．
- 間違っても
Conclusionは締めなのでちょっとかっこいい事を書いても許される気がする- Contributionを論文序盤で箇条書きで書き出す．
- 最近の国際会議通ってるfull paperは大体1ページ目後半か2ページ目の冒頭ぐらいでContributionに関する言及がある気がする．
- Contributionを箇条書きで書き出してしまえば，あとはその根拠を説明するための文章を書けば論文になるのでそれ以降の文章が書きやすくなる．
- 論文を書くのは実装したり実験したりするのに比べて相当つらい
- とにかく淡々と書き続ける
- 書き続ければ，いつかは終わる
- 筆が止まったら違う章を進めるなどしてスループットを一定に保つ
- 1日中座ってると体調を壊すため適当に体を動かす．筆者は昼食を食べたあとに30分ぐらい学内を散歩するようにしている．
- 用語の表記ゆれは最悪なので避けるようにしたいが，イマイチ筆者も良い方法がわかっていない
- グラフはgnuplotかR + ggplot2で書けばいいと思う*2
- 軸名や軸の数値のフォントサイズはどの論文も小さくて読みづらいものが多いので，大きめのフォントサイズを指定して読みやすくしてやる心遣いをしてやると喜ばれる*3
- グレースケール印刷前提でカラースキームを選ぶ
- グラフは十分な解像度でpdfで出力する
- 図は筆者はフォトショを買う金がないのでdraw.ioを使っている．UMLのテンプレもあるので何かと便利．
- 言葉で説明するのがしんどいな〜と少しでも思ったら図を入れるようにしている
図が少ないと怒られたことはあるが図が多すぎると怒られたことはない- こないだ査読で「こんな図は無くても分かるので不要」と初めて怒られた．そういう査読者もいるようだ．
- 図は十分な解像度でpdfで出力する
- 基本，論文執筆は根性でがんばる
- きびしくなったら素直に指導教官にヘルプを求める
論文を推敲する
- 一通り書き終わったと思った直後の論文というのは，一度もコンパイルも実行もしていないコードみたいなものである
- 必ず間違いや書き漏れがあるので注意して読み直す
- 一変に色々なことをチェックすると漏れるので，以下のようにチェックする内容別に何回も繰り返すのが効率が良い
- 1回目の推敲で文章の前後のつながりがおかしくないかどうかをざっとチェックする．大体は接続詞がおかしい文が見つかる．
- 2回目の推敲で内容に関して過不足をチェックする
- 3回目の推敲でグラフ/図のキャプション，軸名，単位，数値，凡例に誤りがないかをチェックし，文中で正しいグラフ/図を指定しているかをチェックする
- 4回目の推敲で誤字脱字をチェックする
- 5回目の推敲で句読点の位置の正当性，文献番号の前にスペースが入ってるかどうか，カッコの前後にスペースが入っているか，などの細かい点をチェックする
- 6回目の推敲でこれまで書いた内容を何もかも忘れた気持ちで全体を読み直す
- ここまでやっても2,3日寝かせてから読み直すと新たに直したい箇所が見つかる
- 永遠に直したくなるのでどうすりゃいいんだろうなこれ
共著者にチェックしてもらう
- 大体は指導教官になる
- 教授というのは出張がめちゃくちゃ多いため，教授のスケジュールを事前に確認し余裕を持ってチェックを依頼する
その他のコツ
- 無理なスケジュールは立てない
- ちゃんと寝る
- ちゃんと休む
- 規則正しい習慣を達成するために平日は朝から全力で研究する
- 大学院生なんだろ
- ご飯はちゃんと食べる
- つい研究室にカップ麺を買い込んで修羅場感出したくなるけど，よほどヤバくならない限りはやらない．すぐ太るぞ（特に30代は）．
- 困ったら指導教官に頼る
- そのために年間535,800円（国立大学の場合）の学費を払って大学院に在籍している
合わせて読みたい
web上のコンテンツ
書籍
国際会議にfull paperを投稿した話
こっちのブログ全く更新してなかったのでたまには書いてみる．
とある国際会議にfull paperを投稿した．
投稿したのはJSTで8/28．だいぶ余裕をもっての投稿だったが，投稿した直後に締め切りが伸びた．なんでやねん．
内容は今年の5月〜7月に取り組んでいたものをまとめたもので，特定のワークロードにおいてChainerのMultiprocessIteratorを魔改造し，訓練データをreadしてミニバッチを生成するまでの所要時間を高速化する手法の提案である*1．この手の研究，2018年頃から急に増加してきており，ほぼ同じアプローチの研究がすでに複数あるためAcceptは厳しいと考えている．ただ，I/Oに関係する研究はどれもそうだと思うが，パフォーマンスがWorkloadに強く依存する傾向にあるため，「どのWorkloadでもSOTA」という手法は基本的に存在しないと考えている．実際，自分は「共有ストレージが提供されており，計算ノードにローカルストレージを積んでいる共用HPCクラスタ」という環境で「ImageNetを訓練データとして使用する」というWorkloadに限定した手法を提案している．なので，このWorkloadにおける有効性や貢献度が高いと判断されたらAcceptの可能性はなくもないと考えているが，如何せんHPCクラスタを前提としていると見られる先行研究が多いので，どうなることやら．需要はないかもしれないが，いっそのこと，特定のIaaS縛りの環境における高速化，みたいなことを研究するとまだブルーオーシャンかも知れない．
英語での論文投稿について
今回投稿したのはいつものIPSJのHPC研究会ではなく国際会議なので英語で原稿を執筆した．
手元のメモから大体どれぐらい時間がかかったのかを類推すると大体以下の通りであった（1日を8時間とみなし，0.5日以上は1日に切り上げ）．
- SWoPP2019で受けたツッコミをディフェンスするための再評価: 1日
- SWoPP2019に投稿した予稿を日本語で再構築: 2日
- 英訳: 10日
英訳は指導教官の修正を受けながら行ったが，それでもベースは自分で全部英訳せねばならないためかなり時間がかかった．文量としては2カラム A4のよくある論文フォーマットでだいたい9ページぐらいになった．やれやれである．
*1:SWoPP2019でも一部発表済みの内容だが査読中なので詳細は控える
第168回HPC研究会で口頭発表してきた
2019年3月14日
すでに先週のことなのだが、3月5日から3月7日の間に開催された第168回HPC研究会という研究会にて口頭発表をしてきた。
何気に初めての学外での研究発表ということになった。査読なしの口頭発表、しかも研究会なので、プロの研究者から見たら大したことのない場なのかも知れない。実際、何回も発表してる「常連」のような雰囲気の人も多く、聞いてる方もずいぶんリラックスしているように見えた。しかし、入学以来、学外での研究発表が初めての自分にとっては十分緊張するに値する機会であった。
今回発表したネタは深層ニューラルネットワークにおける訓練高速化のための自動最適化というもので、内容的にはChainerで実装したModelで実際にforward/backwardを実行して、処理時間とか訓練処理中のGPUの利用状況をプロファイルして、1 epochの訓練をできるだけ高速化するミニバッチサイズを見つける最適化スクリプトをChainerのExtensionとして実装したよ、という話。
今回の発表のために実装したコードは取り急ぎGithubに上げてある。まだドキュメントを一切書いてないのだがこちらについてもちゃんとドキュメントを書いて別のブログ（seri::diary）の方で紹介したい。
これを使うと、例えばChainer付属のCifar100+VGG16のサンプルスクリプトだと、「V100が刺さってるマシンだとミニバッチサイズ196ぐらいが1 epoch当たりのforward/backwardの処理時間がいい感じに早くなるミニバッチサイズだよ」ってことを自動で判定してくれるやつである。モデルの精度は全く見ておらず、単にGPUを使い切る当たりを狙ってミニバッチサイズを調整する、という感じである。得られた最適値をそのまま使うというより、GPUを使い切るにはこれぐらいのミニバッチサイズになるということが分かるので、そこから精度に影響しない範囲でサイズを調整するとか、精度改善のために学習率を調整するとかバッチ正則化層を入れるなどの、マニュアルチューニングを入れた上で使用することを想定している。
ちなみに今回はCifar100 + VGG16で試した限りではミニバッチサイズ196でも32や54と比べてさほど汎化性能に影響はなかった。たまたまであるが。
この研究のモチベーションとしては、なぜかミニバッチサイズってどの論文でもモデルに関係なく32とか64を使っていて、それが本当に最適なのかが気になったのと、そういうミニバッチサイズで1 GPUをちゃんと使い切れるかどうかというのが気になったというの２つの理由がある。
この研究の結論としては、V100なんかが刺さってるマシンだとCifar100 + VGG16みたいなトイデータだとバッチサイズは32や64からは明らかに大きくできる余地があった。一方でImageNet-1k（224x224にcropしたもの）だとデータのロードやpngからndarrayへの変換処理などの処理時間と思われる、GPUを使わない時間帯が多く存在し、GPUが「遊んでいる」時間帯が1 iterationごとに1秒ほど存在しており、ミニバッチサイズを増加させてもなかなか性能改善につながらないということがわかった。ChainerのImageNet-1k + ResNetのサンプルだと、この問題を回避するために非同期でデータをロードするMultiProcessIteratorを使用している。
じゃあMultiProcessIterator使えばいいじゃん、でこの話は正直言って終わりなのだが、逆に言えばMultiProcessIteratorのような機構がない場合は、画像サイズが32x32から高々224x224になるだけで随分とGPUの利用が阻害されるという問題が簡単に起きるということを示している。これは一般的に知られているんだかいないんだか分からないが、安易に訓練データのサイズを上げることの影響は予想以上に大きいということを示唆しているという点でそれなりに意味のある発見。。なのではないだろうかと勝手に思っているのだが、どうなのだろう。周りに深層学習ガチ勢がいないのでちょっと分からない。ガチ勢が集まる場所で聞いてみたい。
とりあえず今回の研究発表はこんな感じであり、会場からはいくつか質問もいただいて、最低限伝えたいところは伝わったようなのでホッとしている。このOptimizerのコードはそのうち公開する予定である。高々数百行で作れるExtensionなので、自分の書いた原稿を読めば誰でも作れそうなモンであるが、一応ちゃんと動くものができたのでそれはそれで意味があるのではないだろうか。
初めて対外論文書いて気づいたこと
2019年1月27日
- 論文の結論が客観的に説明できるレベルで明確になる前にとりあえず応募してはならない
- 指導教官に論文出せと言われても、論文の要旨を専門外の人間に説明できるレベルで明確に説明できないような状態では絶対に応募すらしてはいけない。
- 書いてる途中に問題に気づいて時間が足りずに論文にまとめられない可能性すらある
- 今回はギリギリなんとかなったがヤバかった
- 指導教官は専門外の研究者の目線でレビューしてくれるので積極的にレビューを依頼して分かりにくい説明を潰していく
- 今回は投稿締め切りの10日前、20日前にWIPレビューを依頼している
- グラフの作成は死ぬほど時間がかかる
- 論文の文章を書くのは信じられないほど時間がかかる
- 今回の論文、texファイルの１日分（実作業時間7時間程度）のdiffを調べたら、2段組pdfにしたときの行数で30行程度しか変更がなかった日もあった
- 研究している自分にとっては完全に常識になっているようなこともゼロから説明する必要があるケースが多いというかほとんどなので、前提知識を確実にかつ端的に説明する方法を身につける必要がある
- 自分がやってる研究がソフトウェア論文に近くなると気づいた段階から、論文にそのままコピペできるクオリティの説明文を進捗MTGの時点で書いておくべし
- 進捗MTGのために研究結果をまとめたり説明スライドを作るのではなく、そのまま論文にコピペできる文章を積み上げていくスタイルに変える
- とにかく普段から論文を積み上げていく習慣を身に着けないといけない
- そうしないと論文は書けない
- いくらブログを書いていても客観的な視点で書かれた読みやすい文章は書けない
煙に巻いているような気分になる
2019年1月17日
HPC研究会に投稿するための論文を書いているが、どうにも自分で書いている論文の説明がどんどんキナ臭く感じてしまい、なかなか筆が進まずにいる。
やる気がでない言い訳とかではなく、どんな風に書いても批判やツッコミが来そうだなという感情が湧いてきてしまい、不安になる。論文なんてのは本来、査読でボコボコに叩かれて生き残ったものだけがカンファレンスで日の目を見られる世界なのだろうから、人に見せる前から批判を恐れている場合ではないはずである。しかし、それにしても自分からみても大した内容ではないことが分かっているため、どうにもそれをちゃんとした研究であるかのように説明することに積極的になれないでいる。
そもそも良い研究とはなにか？ということも良くわからない。良いソフトウェアとは何か？という問いに答えがないように、恐らく答えがない類の問いなのだろうけど、実装したコードの行数とか実験にかけた時間とか、そういう定量的なもので測れるものではない以上、良くわからなくなってくる。別段、自分は研究者になるつもりは全くないので出来が良かろうが悪かろうが今後の人生に及ぼす影響は大きくはないだろうけど、今やるべきことが研究しかないため、それについて成果が出ないというのは自分自身の否定であるかのような心持ちになる。実際、弊研究室では研究成果が全てである。引いては大学という場所がそもそもそういう場所であり、やはり研究を志した人間だけが大学という場所に来るべきなのではなかろうかという、散々自問した問題にまた回帰してしまう。
2019年について
2019年1月1日
初日の出を総合研究棟Bの10階で拝んでそのまま研究室で作業していた。作業が一区切りついてあとは計算ノードさんよろしくお願いしますという感じになったのでブログを書いている。
今日は年初ということもあり、2019年の目標というか予定みたいなものを整理しておきたい。
今年のペース配分
- 1月〜6月に研究に集中してそれ以降はサボってても卒業できるようにする
- 単位についてはM1で受講した講義の単位が全部取れてれば卒業要件 + 11単位になるので、M2は一切講義に出なくても卒業できる
- そうすると8月,9月にインターンに行く時間も取れるし就活の時間も取れる
- 今年投稿するであろう研究会はおそらく168回HPC研究会とSWoPP2019の2つぐらいだが両方とも今年前半なのでやはり前半線が勝負
- 10月以降は心穏やかにやりたい勉強をしながら修論をまとめたい
- 就職先は10月ぐらいまでに決めておくのがベストなのでそう考えると6月ぐらいから就活しておきたい所存
未来予測
1月
- 最後に残った高性能計算特論のレポートを倒す
- 何となく受講を決めた宇宙開発工学特論の集中講義に出る
- 第168回HPC研究会に応募したので論文を書く
- 確定申告の準備
2月
- 第168回HPC研究会の論文投稿締切りが2/5なのでそれまでに提出する
- 発表スライドを作って内部発表する
- 確定申告を行う
3月
- 3/5-3/7の第168回HPC研究会で発表する。山代温泉らしい。行ったことない。
- PFNのオープンハウスに行く。インターンに応募するかはまだ検討中
4月
- M2の間は集中講義以外の講義は基本取らない予定なので研究を進める
- PFNのインターン応募が確か4月末とかの締切なので応募するなら応募する
5月
- 研究を進める
- SWoPPが例年だとだいたい5月ぐらいに応募締切らしいので投稿できそうなら応募する
6月
- 研究を進める
- この辺から就活するかという気もするが急ぐ必要はないのでゆっくりやる
- 下旬ぐらいから修論中間発表の準備をしたほうがいい
7月
- 修論中間発表がある。ネタが２つあるのだがどちらで書くことになるのかは良くわかってない。
- 例年だとSWoPPが7月末〜8月頭らしいので応募してたら参加する
8月
- インターンにいくなら多分この辺から行くんだろう
- そうでなければ研究を進める
9月
- 研究を進める
10月
- 何事もなければこの辺で研究は終了にして修論作成に着手する
- でもM2の人見てると結構ギリギリまで研究活動したり学会発表したりしてるのでいつ修論作成に着手するかは全くわからん
- あとこの辺で就職先決めとかないと厳しそう。なんかこのぐらいの時期に進路調査票みたいのを書くイベントもあるらしいし。
11月
- さすがに修論書いてるやろ
12月
- 修論書いてるやろ
