「朝型人間が成功する」のは本当なのか？
Disclaimer：この記事には、夜型人間による、朝型生活を善とする社会規範への反抗と怨嗟が多分に含まれています。
勤務先の社内では、読書会というイベントが行われています。ここで、「What the Most Successful People Do Before Breakfast: A Short Guide to Making Over Your Mornings」という書籍が紹介されていました。
- 作者: Laura Vanderkam
- 出版社/メーカー: Portfolio
- 発売日: 2012/06/12
- メディア: Kindle版
- この商品を含むブログを見る
基本的には、「成功者には朝型人間が多い、だからみんなも早く起きましょう」という本です。
さて、自分がいつも疑問に思うのが、「成功者には朝型人間が多い。だからあなたも朝型生活をしましょう」という論理展開についてです。
そもそも事実は？
「成功者には朝型が多い」というのは事実なのでしょうか？
もっといえば、人間には様々な個性や体質の人がいる中で、成功者には有意に朝型人間がおおいのでしょうか？
ほとんどの「朝活本」では、「誰々〜は何時に起きる、誰々〜は何時に起きる、〜」という具合で著名企業のCEOや政治家などの名前を列挙することによって「成功者には朝型人間が多い」ことを前提として印象付けようとしています。これは統計的事実なのでしょうか？
Quoraのこの質問 では、質問者がまさに同じ疑問を直球でぶつけています。それに対する答えは…「朝型だから成功するわけではないが、朝型の人の方がエネルギッシュで社会に貢献したいという意欲が強いからではないでしょうか？」というもの。うーん。
また、Quoraの質問からリンクされているこのページ には、朝型ではない成功者の例がありました。マーク・ザッカーバーグ、ウォーレン・バフェット、ウィンストン・チャーチル。しかし、これでも結局個別サンプルでしかありませんし、知りたいことは何もわからないままです。
次に見つけたのが 6 Facts About the Sleep of Famous People というページです。このページによれば、
Early Birds?
Yep! These successful people have that trait in common – they’re up early with 56% rising from 4 a.m. to 5:30 a.m. Out of those, 28% — the largest single percentage – are up at 5 a.m. Another 33% are out of bed by 7 a.m. – leaving only 11% who are in bed until 8 or 9 a.m.
成功者のうち、8時か9時までベッドで寝ているのは11%に過ぎない‥と。果たしてこれが（一般のビジネスパーソンと比較して）多いのか少ないのかよくわかりませんが、確かに絶対値としては成功者の56%が5時半までに起きているということのようです。（ただし、データの出処は不明）。
因果関係は？
さて、百歩譲りまして、「成功者には朝型が（有意に）多い」という相関関係があるとして、それはなぜなのでしょうか？いろいろ理由は考えられます。
仮説(1) 朝型であることが成功に有利（正の因果関係）
多くの「朝活本」の論旨であるところの、「朝型であることはあなたを成功に導く。だからあなたも朝型生活にしましょう」という論理がまさに正しいというケースです。
仮説(2) 成功した結果、朝型生活にせざるを得なくなった（逆の相関関係）
企業トップとして成功すると、多忙を極めます。また、決定を下すこと、そして自分の判断の遅れによって会社の動き、社員の働きを止めないことが重要になると考えられます。そのために、
- 部下がスムーズに仕事を始められるように指示などを朝イチに出しておく必要がある
- 運動などの個人の時間は朝しか取れない（夜は家族と過ごす）
などの理由によって、結果的に朝型にせざるを得ない、という可能性があります。「成功することによって、結果的に朝型になった」という逆の因果関係です。
仮説(3) 別の原因で朝型生活になった（第三の要因による疑似相関）
「成功者である」ことと、「朝型である」が共通の別の原因によって引き起こされている事も考えられます。
例えば、
- 人間は、歳を重ねると朝型になる。また、成功者には中高年が多い
- 育児をすることによって朝型生活にせざるを得ないので、結果的に朝型生活になった
など。
あるいは、朝型生活を長期間維持するためには忍耐と継続力が重要なので、そのような人は成功しやすいということなのかもしれません。つまり、「忍耐力・勤勉さ」という第三の要因による疑似相関ということになりますね。この場合、もともと夜型の人が朝型にしたからと言って成功する確率が高まるわけではないということになります。
仮説(4) 偶然
たまたま取ったデータがそうだったのかもしれませんし、「朝活本」ではそのようなデータをことさら強調しているだけかもしれません。
また、「朝型でも夜型でも、睡眠時間が取れてればどっちでもいいけど、朝型が良いという風潮があるので朝型にしてる」というケースもあるかもしれません。これもある意味で、第三の要因による擬似相関とも言えるかもしれません。
結論（は特にない）
特に結論はありませんが、データをよこせ！という感じですね。↑で紹介した本には書いてあるのかもしれません。
印象論ですが、これだけ有名な話で、古来からことわざなどでも広く言われ、しかも様々な国や文化で共通に言われているとなると、学術的に調べた結果が存在しても良さそうですが、探しても見当たらないということは…あっ（察し）（個人の印象です）
AWSのElastic Fabric Adapter
AWS re:Invent 2018において、Amazonが開発する新しいネットワークアダプタ Elastic Fabric Adapter (EFA) が発表されたようです。
HPC的なまともなアプリをスケールさせようと思うと、どうしてもネットワークがネックになります。普通のスパコンでは、Infiniband等のハイスピードインターコネクトが実装されているので、速度的には100G〜200Gくらいでるのですが、普通のクラウド環境だと一桁遅いので、通信が重すぎてちっとも計算が進まないということになります。近年、AWSを始めとしたクラウド環境はどんどんHPC分野をターゲットにしているので、スパコンなみのハイスピードインターコネクトが求められていました。
[NEW LAUNCH!] Scaling Tightly-coupled HPC workloads on HPC with Elastic Fabric Adapter and High Bandwidth (Network Optimized) EC2 Instances. (ENT360) - AWS re:Invent 2018 from Amazon Web Services
www.slideshare.net
とうとうインターコネクトもAmazonが自前開発しちゃうんですね・・・。正確には、以前に買収した企業の製品（の後継）らしいです。確かに、Infinibandをそのまま使うのは仮想化とかResource Isolation的につらいし、かといってEthernetでRoCEか？というとそれも違うよねーということで独自開発という感じでしょうか。実績と柔軟性だけみれば100G Ethernetですが、対応スイッチは高いし（IPのパケット処理は重いので）、RDMAとかを考え出すとつらい（RoCEはRoutingのデッドロック等の問題があり運用がつらいらしい）とか…。いろいろありそうです。
EFAの特徴としては
- インターフェースはlibfabric
- MPIからの利用を想定
- c5nインスタンスの中からENA（Elastic Network Adapter??）が見えて、それが実際にホスト上に存在するアダプタにマッピングされる（という図に見える）
- （HPC network performance with EFAというページでは、MPI multistreamの性能評価の結果らしきものが掲載されているが、軸の説明がなにもないのでよくわりません。横軸は並列数かな？）
というあたりでしょうか。また、通信の種類としては、
- RDM: Reliable unordered datagrams, タグマッチング無し
- DGRAM: Unreliable unordered datagrams with flow limit
- RxR: libfabric interface over RDM, 完了順序保証, タグマッチングあり、Max MessageSizeが大きい（メインメモリより大きい）
- SRD: Scalable Reliable Datagram、順序保証なし、到着保証あり、レイテンシが桁で少ない
などがあるようです。InfinibandだとReliable datagramはあまり使うことが少ないので面白いな〜と思います。AWSのデータセンター向けに設計されたプロトコルだということで、そのあたりが関係してそう。
2019年上半期にGAということで、現在Preview申し込み受付中とのこと。
感想
インターフェースに使われているライブラリが今どきlibfabricかーと思わないことはないのですが、通信をDatagramベースにすることによって既存インターコネクトの問題点を回避してAWSに適した設計になっていると思うので、その点は興味深いです。
なお、NCCLにも対応しているとのこと。NCCLはVerbsだったはずだけどどうやってんだろ…と思ったら、普通に気合で書き直しているっぽい・・・？これから読んでみます。
まあ、インターフェースとして提供するライブラリをどうするかというのは難しい問題ですね。今から開発するならUCXベースにするのが普通だと思いますが、数年前からずっと開発していたとなると、Verbsにするよりはlibfabricのほうが100倍マシということは同意します。
最近読んだもの 2019/01/30
不定期に、最近読んだ論文、本、Webページをメモしていきます。
論文：Taxonomist: Application Detection through Rich Monitoring Data
スパコン上で流れいてるジョブを（管理者側）から判別できると良いことがある。次世代スパコンの設計に役立つ、不正なアプリ（マイナーとかパスワードクラッキングとか）を検出して禁止できるなど。しかし、判別は難しい。なぜなら、バイナリは名前が変更されている、ユーザーが書いた複雑なシェルスクリプトから実行される、同じプログラムでもコンパイルオプションによっても挙動は変わる、から。
そこで、既存のシステムMetricsから、機械学習を用いてアプリを特定する手法を提案した。アプリケーションが実行されるときに、実行性能に影響を与えない時系列メトリクスを取得し、max, min, mean, stddev, skew, kurtosis, 5th, 25th, 50th, 75th, 95th percentile などの特徴量に加工してrandom forestで学習させた。F-score95％。
論文：GPipe: Efficient Training of Giant Neural Networks using Pipeline Parallelism
モデル並列の実装例。ミニバッチをマイクロバッチに分割して処理をパイプライン化することにより、1つのネットワークを複数のアクセラレーター上で分散実行。必要に応じてRecomputeテクニックを用いて通信量を削減。データ並列とも共存可能。パラメーター数を5.5億まで増やしたAmoebaNetを実行してImageNetでTop-1 accuracy 84.3%。４倍の数のGPUを用いて3.5倍の高速化。
- レイヤーごとにGPUの台数を変えることができると、なお良さそう（できるのかな？）
- この研究の評価だと8GPUだけど、もっと台数増やしてGlobal Minibatch size増やしたほうが、もっと効率良さそう。
関連：
論文：Software Engineering at Google
GoogleでのSoftware Engineeringのまとめ。 シングルリポジトリ、コード20億行、3500万コミット、毎日4万コミットを格納というGoogle社のソフトウェアがどのように開発されているかというまとめ。
コード管理、テスト、レビュー、プログラミング言語、コード品質、デバッグ、プロファイリングなどについて概要が書かれています。他にも、20%ルール（現在は廃止されているという情報もある）、OKR、人事、設備、トレーニングなどについても言及。
本：シリコンバレー式 自分を変える最強の食事
読み方が難しい本だと思いました。
本書は、いわゆるバターコーヒーの発祥の本。
この本で受け取るべきメッセージは、
- 自分が何を食べているのかを把握し、それをコントロールし、固定し、記録し、そして自分の体調を観察しよう
- 新しいこと（食べ物）を試すときは、食生活と体調が安定しているときに一つずつ変えてみて観察しよう
- 常識にとらわれずに、自分の体で実験しよう（そして、この本も真に受けずに自分の体で試してみよう）
ということだと思います。本文には、この食品は良い／この食品は悪い、ということがずっと書かれていますが、それらは枝葉末節です。国が違えば食品規制も違うし、人が違えば体質も体調も違います。枝葉末節／個別の項目を真に受けるのではなく、「常識を疑い、自分自身の体と向き合い、測定と観察をもとにバイオハックをおこなおう」という本でした。これをよんで、TV番組で紹介された食品を翌日スーパーで買い漁るタイプの人は読んではいけない本。
本：第六大陸〈1〉 (ハヤカワ文庫JA)
小川一水さんのSF小説。
SF小説というのは誤解を恐れずざっくり分けると、①現代社会と地続きの近未来、②現代社会と切り離された遠い未来、があると思いますが、この小説は前者。極地建設を得意とする民間企業が、資産家の企業オーナーから月面施設の建設を依頼されるという話。
地続き近未来系のSF小説は、「技術的なディテールが正確であること」と、「そこに少しだけ飛躍した画期的な技術／発見がある」ことが大事なところです。そして、その「キモ」が、いかに「ありそうだけど無い」という絶妙のラインであり、そして実際の技術的ディテールと融合するか、というのが小説の見どころですね。
