seri::diary::graduate_school

大学院修士課程での研究生活について書いています

自分なりの論文の書き方

これは何か

  • これまで3本(日本語2本,英語1本)論文を書いた経験を元に自分なりに手順をまとめておく.
  • あくまで手順を書き下すのみで,細かいテクニックについては触れない. 合わせて読みたいに参考になりそうな文献をまとめておく.

    前提事項

  • 筆者はM2の学生.
  • 筆者は査読なしの国内研究会における口頭発表しか経験がない
  • 筆者は国際会議にfull paperを通した経験なし(投稿はしたが執筆時点で採否が決まっていない)
  • 筆者はHPC分野の研究室の人間
  • 筆者は深層学習におけるストレージ周りに関する研究が専門

関連研究を読む

  • Google scholarとかでキーワード入れて検索する
  • 対象のジャーナルや国際会議が絞れるなら過去のproceedingsを直接探す
  • 自分の場合,読む論文の優先順位は大体以下の通り
    • 国際会議でacceptされたfull paper
    • 国際会議のwork shop paper
    • arXivにしかない論文
    • 日本の研究会の論文*1
  • abstract,conclusionを読んで関連してそうなものを探す
    • 関連していれば熟読する
    • 熟読したら簡単でいいので要約を自分で書いておく
    • 書いた要約は全文検索できる場所に保存しておく.自分の場合はGitHubのissue.
  • 見つけた論文はMendeleyとかで管理しておき,いつでもどこでも参照できるようにしておく
    • 暇な時に読もう
  • 良い論文が見つからないときは素直に指導教官にヘルプを求める

スケジュールを立てる

  • 出す会議の締め切りから逆算してスケジュールを立てる
  • 24時間作業できるわけがねぇだろ.1日に作業できるのはせいぜい6時間ぐらいで見積もる.
  • 人間は見積もりが下手くそないきものである.「自分が直感で立てたスケジュールの2倍が実際にかかる工数である」ぐらいに安全率を取っておくのが無難.
  • 土日は休むスケジュールを立てる
  • 逆に平日は決めた作業時間は死守する気持ちが重要

研究する

  • 研究は基本孤独との戦い
    • 他の学生と適度にダベりながらやる
    • 孤独を避けるためにも研究室に来て作業する
  • 一番の敵は己の心の弱さ
    • メンタルを壊さない程度にがんばる
    • 毎日日報ををつけると進捗出ている感が出るのでおすすめ
  • 淡々と進捗を出し続ける事が重要なので,毎日決まった時間に始め,決まった時間に帰るリズムをキープする
    • 深夜に作業するのはテンション上がるけどおすすめしない.体調を崩しやすくなるし,人間は昼間に活動する前提でこの社会はできている.
  • 実装について
    • バグってて間違った結果を論文に書いてしまうと大変ヤバいので,できればテストを書く
    • テスト書いてる暇がない場合でも,動作確認する方法を最初に十分に検討し常に結果が正しいことを確認する
    • 仕事と違って人に読ませるコードではないのでコードのメンテナビリティはそこまで重要じゃない.自分が読めれば十分,ということで妥協しつつどんどん進める.
    • 仕事と違って研究における実装は「評価結果とセットで初めて価値が生まれる」ぐらいに思っておいた方がいい
    • OSSにするのは後からでもできるので,その時に思う存分リファクタしよう
  • コードは必ずGitHubかBitbucketなどの外部サービスを利用して管理する
    • おすすめはGitHubとBitbucketへの二重管理.GitHubは結構止まる.
      • 筆者はremoteリポジトリを複数登録しておいて両方にpushしている
    • 研究室で管理しているGitリポジトリでも良いが,そのGitサーバが故障する可能性も常に考慮する
  • 性能評価するときのコツ
    • 闇雲に計測せず,「何が示せれば自分の主張の裏付けになるか?」をまずしっかり考える
    • 自前のtimerコードを挿入して計測してもいいが,profilerが使える場合はprofilerの方がより正確な情報が取れるし変なミスは起きづらい
    • print文はできるだけ入れない.性能に与える影響が結構バカにならない(体験談)
    • 計測に使うログのフォーマットは後で集計しやすいように最初から整形された状態で出力されるようにしておく
      • 自分はログの集計にRを使う事が多いのでCSVにしておくことが多い
    • 計測に使ったログは日付,タイムスタンプをファイル名に入れて全部残す
    • 計測に使ったログは必ずバックアップを取る
  • きびしくなったら素直に指導教官にヘルプを求める

論文を書く

  • texのテンプレが指定されている場合はなるべく早く自分の手元でビルドできるかを検証しておく
  • 本文は Motivation から書き始め,次に Methodology, Evaluation, Discussion を書く
    • 間違っても AbstractIntroductionBackgroundConclusionといったsectionからは書かない.この辺は書いてるうちにどんどん内容が変わっていくぞ.
  • Conclusion は締めなのでちょっとかっこいい事を書いても許される気がする
  • Contributionを論文序盤で箇条書きで書き出す.
    • 最近の国際会議通ってるfull paperは大体1ページ目後半か2ページ目の冒頭ぐらいでContributionに関する言及がある気がする.
    • Contributionを箇条書きで書き出してしまえば,あとはその根拠を説明するための文章を書けば論文になるのでそれ以降の文章が書きやすくなる.
  • 論文を書くのは実装したり実験したりするのに比べて相当つらい
    • とにかく淡々と書き続ける
    • 書き続ければ,いつかは終わる
    • 筆が止まったら違う章を進めるなどしてスループットを一定に保つ
  • 1日中座ってると体調を壊すため適当に体を動かす.筆者は昼食を食べたあとに30分ぐらい学内を散歩するようにしている.
  • 用語の表記ゆれは最悪なので避けるようにしたいが,イマイチ筆者も良い方法がわかっていない
    • とりあえず頻出する用語はtex\newcommandエイリアス代わりのコマンドを定義してそれを使うようにしている
  • グラフはgnuplotかR + ggplot2で書けばいいと思う*2
    • 軸名や軸の数値のフォントサイズはどの論文も小さくて読みづらいものが多いので,大きめのフォントサイズを指定して読みやすくしてやる心遣いをしてやると喜ばれる*3
    • グレースケール印刷前提でカラースキームを選ぶ
    • グラフは十分な解像度でpdfで出力する
  • 図は筆者はフォトショを買う金がないのでdraw.ioを使っている.UMLのテンプレもあるので何かと便利.
    • 言葉で説明するのがしんどいな〜と少しでも思ったら図を入れるようにしている
    • 図が少ないと怒られたことはあるが図が多すぎると怒られたことはない
    • 図は十分な解像度でpdfで出力する
  • 基本,論文執筆は根性でがんばる
  • きびしくなったら素直に指導教官にヘルプを求める

論文を推敲する

  • 一通り書き終わったと思った直後の論文というのは,一度もコンパイルも実行もしていないコードみたいなものである
  • 必ず間違いや書き漏れがあるので注意して読み直す
  • 一変に色々なことをチェックすると漏れるので,以下のようにチェックする内容別に何回も繰り返すのが効率が良い
    • 1回目の推敲で文章の前後のつながりがおかしくないかどうかをざっとチェックする.大体は接続詞がおかしい文が見つかる.
    • 2回目の推敲で内容に関して過不足をチェックする
    • 3回目の推敲でグラフ/図のキャプション,軸名,単位,数値,凡例に誤りがないかをチェックし,文中で正しいグラフ/図を指定しているかをチェックする
    • 4回目の推敲で誤字脱字をチェックする
    • 5回目の推敲で句読点の位置の正当性,文献番号の前にスペースが入ってるかどうか,カッコの前後にスペースが入っているか,などの細かい点をチェックする
    • 6回目の推敲でこれまで書いた内容を何もかも忘れた気持ちで全体を読み直す
  • ここまでやっても2,3日寝かせてから読み直すと新たに直したい箇所が見つかる
  • 永遠に直したくなるのでどうすりゃいいんだろうなこれ

共著者にチェックしてもらう

  • 大体は指導教官になる
  • 教授というのは出張がめちゃくちゃ多いため,教授のスケジュールを事前に確認し余裕を持ってチェックを依頼する

その他のコツ

  • 無理なスケジュールは立てない
  • ちゃんと寝る
  • ちゃんと休む
  • 上記を達成するために普段から全力で研究する
    • 大学院生なんだろ
  • ご飯はちゃんと食べる
    • つい研究室にカップ麺を買い込んで修羅場感出したくなるけど,よほどヤバくならない限りはやらない.すぐ太るぞ(特に30代は).
  • 困ったら指導教官に頼る
    • そのために年間535,800円(国立大学の場合)の学費を払って大学院に在籍している

合わせて読みたい

*1:自分の場合は所属しているHPC研究会を中心にIPSJの論文を読む

*2:筆者はR + ggplot2派.データの前処理をしてからグラフを作るのでRでまとめてスクリプトにできて楽なので

*3:と思っている

国際会議に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研究会という研究会にて口頭発表をしてきた。

f:id:serihiro:20190306124203j:plain
会場兼宿泊場所の旅館「瑠璃光」。朝食も夕食もご飯が美味しかった。

何気に初めての学外での研究発表ということになった。査読なしの口頭発表、しかも研究会なので、プロの研究者から見たら大したことのない場なのかも知れない。実際、何回も発表してる「常連」のような雰囲気の人も多く、聞いてる方もずいぶんリラックスしているように見えた。しかし、入学以来、学外での研究発表が初めての自分にとっては十分緊張するに値する機会であった。

今回発表したネタは深層ニューラルネットワークにおける訓練高速化のための自動最適化というもので、内容的にはChainerで実装したModelで実際にforward/backwardを実行して、処理時間とか訓練処理中のGPUの利用状況をプロファイルして、1 epochの訓練をできるだけ高速化するミニバッチサイズを見つける最適化スクリプトをChainerのExtensionとして実装したよ、という話。

今回の発表のために実装したコードは取り急ぎGithubに上げてある。まだドキュメントを一切書いてないのだがこちらについてもちゃんとドキュメントを書いて別のブログ(seri::diary)の方で紹介したい。

github.com

これを使うと、例えばChainer付属のCifar100+VGG16のサンプルスクリプトだと、「V100が刺さってるマシンだとミニバッチサイズ196ぐらいが1 epoch当たりのforward/backwardの処理時間がいい感じに早くなるミニバッチサイズだよ」ってことを自動で判定してくれるやつである。モデルの精度は全く見ておらず、単にGPUを使い切る当たりを狙ってミニバッチサイズを調整する、という感じである。得られた最適値をそのまま使うというより、GPUを使い切るにはこれぐらいのミニバッチサイズになるということが分かるので、そこから精度に影響しない範囲でサイズを調整するとか、精度改善のために学習率を調整するとかバッチ正則化層を入れるなどの、マニュアルチューニングを入れた上で使用することを想定している。

f:id:serihiro:20190314223512p:plain
得られた最適値で実際に1 epoch訓練したときにかかった時間を計測してみた結果

ちなみに今回はCifar100 + VGG16で試した限りではミニバッチサイズ196でも32や54と比べてさほど汎化性能に影響はなかった。たまたまであるが。

f:id:serihiro:20190314224949p:plain
Cifar100 + VGG16でバッチサイズを変えて100 epoch訓練したときのmain/validation accuracy

この研究のモチベーションとしては、なぜかミニバッチサイズってどの論文でもモデルに関係なく32とか64を使っていて、それが本当に最適なのかが気になったのと、そういうミニバッチサイズで1 GPUをちゃんと使い切れるかどうかというのが気になったというの2つの理由がある。

この研究の結論としては、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レビューを依頼している
  • グラフの作成は死ぬほど時間がかかる
    • グラフは普段から論文に貼って一般公開できるクオリティのものを作り込んでおく
    • ggplot2でグラフ書くにしてもMakefileとかでコマンド一発で最新化できるようにしておく
    • 今回はグラフの見た目の試行錯誤の時間が長かったのでRmdにしたが、今後元データやファイルが増えたらCLIから実行できるようにしたほうが良さそう)
  • 論文の文章を書くのは信じられないほど時間がかかる
    • 今回の論文、texファイルの1日分(実作業時間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月

2月

  • 第168回HPC研究会の論文投稿締切りが2/5なのでそれまでに提出する
  • 発表スライドを作って内部発表する
  • 確定申告を行う

3月

4月

  • M2の間は集中講義以外の講義は基本取らない予定なので研究を進める
  • PFNのインターン応募が確か4月末とかの締切なので応募するなら応募する

5月

  • 研究を進める
  • SWoPPが例年だとだいたい5月ぐらいに応募締切らしいので投稿できそうなら応募する

6月

  • 研究を進める
  • この辺から就活するかという気もするが急ぐ必要はないのでゆっくりやる
  • 下旬ぐらいから修論中間発表の準備をしたほうがいい

7月

  • 修論中間発表がある。ネタが2つあるのだがどちらで書くことになるのかは良くわかってない。
  • 例年だとSWoPPが7月末〜8月頭らしいので応募してたら参加する

8月

  • インターンにいくなら多分この辺から行くんだろう
  • そうでなければ研究を進める

9月

  • 研究を進める

10月

  • 何事もなければこの辺で研究は終了にして修論作成に着手する
  • でもM2の人見てると結構ギリギリまで研究活動したり学会発表したりしてるのでいつ修論作成に着手するかは全くわからん
  • あとこの辺で就職先決めとかないと厳しそう。なんかこのぐらいの時期に進路調査票みたいのを書くイベントもあるらしいし。

11月

  • さすがに修論書いてるやろ

12月

近況

2018年12月7日

今年も残す所あと僅かであり、秋学期ABの講義期間も間もなく終わりを迎えようとしている。
秋学期ABが終わって、願わくば今受けてる講義すべてで単位が取れれば修了要件を満たすことができるため、もう講義を取る必要がなくなる。 今のペースだと必要単位数+10単位ぐらいの単位を取って修了するペースである。多分取りすぎであり、おかげで毎日のように課題のコードを書いたり専門外の論文を読んだりレポートを書いたりしている。

講義が終わったらあとは修論を仕上げるために研究に勤しむだけなのだが、入学前に思っていたよりも、多くの講義はあっさりというか簡単だったという印象である。

もっとエグい実装や論文読みを課せられる講義があるのかと身構えていたのだが、殆どの講義でそんなことはなく普通にやってれば終わってしまうような課題ばかりだった。*1 特に実装関係はホント簡単だったのでこれでいいのかという気持ちなのだが、まぁ好きで書いてる人は放っておいても書けるようになるし、研究で書く必要がない人は全く書かないし、、みたいな感じなので、実装力は重要視してないのかもしれない。この一年で自分が課題で書いたもっとも複雑なコードはrubyで500行ぐらいで書いたマルチプロセスで動作するMapReduceフレームワークのコードぐらいで、短いものだと多分10行ぐらいの穴埋め問題的なやつを書いて動作確認しただけだと思う。それ以外でも入門書のサンプルコード程度である。

このような講義を受けてきて最近思うのは、世に出ている日本語の入門書というのは実はすごく充実しているのではないかということである。自分は社会人になってから書籍に頼って勉強してきたワケだが、それらのその辺の本屋で買える入門書はとても実用性が高いものだったのではないかと感じるようになった。つまり、大学の講義レベルの内容を読むだけで学べるぐらいには良い内容の本がその辺の本屋に売っている、といっても過言ではないのかもしれない。世の中のCS専攻を出ていないエンジニア達よ、技術書を買って勉強すれば基礎分野なら十分CS専攻卒と張り合えるぞ、多分。

一方で、講義で扱わなければ恐らく一生読まなかったであろう本に出会えることもあり、こういうのはきっと大学の講義固有の価値なんだろうなと思う。
秋学期に並列システムアーキテクチャに関する講義を取っているのだが、そこで教科書として使っている本は自分にとってまさに「知らないこと」を学べる一冊だった。

Introduction to Parallel Computing

Introduction to Parallel Computing

自分は並列システムというと、マルチスレッド/マルチプロセスの実装の仕方みたいな話しか知らなかったのだが、そもそもなぜ並列化が必要なのか?という話から始まり、インストラクションレベルの並列化、つまりパイプライン、スーパースカラに代表されるプロセッサレベルの技術から解説される。ソフトとハードの両面でどのような技術が用いられて並列に動作するシステムが実現できているかを解説している。
この本の特徴として、メモリバンド幅がどれだけパフォーマンスに影響を与えるかという話をあらゆる例題を用いて説明している。一貫して「メモリシステムはCPUよりはるかに遅い」ということを繰り返し主張している。具体的には「1サイクルでアクセスできるL1キャッシュと100サイクルでアクセスできるメモリがあって、キャッシュヒット率が10%落ちるとプログラムのレイテンシがどれぐらい落ちるか」といった感じで、具体的なスペックを示したシステムを例として読者に考えさせている。
この辺の考え方はうっすらと知っていた程度で、具体的な数値について考えたことがなかった。しかし実際に計算してみることでどれぐらいキャッシュミスがパフォーマンスに影響を与えるかということがよく分かる。これは独学でやっていたら恐らく手をつけなかった、というより、この手の話は日本語だとちゃんと解説されている本が少ないと思われるので出会わなかったかも知れない。そういう意味でこの本はここで読む機会を持つことが出来てよかったし、実際キャッシュヒット率を意識した実装は重要である。単純な1000x1000ぐらいの行列同士の積を二重ループで求めるようなシンプルな処理でもキャッシュヒット率が下がると露骨に処理時間が長くなるのは他の講義でも体験した。

*1:もちろんエグい課題がある講義もあったが全体で見れば1割ぐらいである