CPUに関する話

CPUに関する話

1. 1. CPUに関する話 sejima
2. 2. 免責事項 - 本資料において示される見解は、私自身の見 解であって、私が所属する組織の見解を必ずし も反映したものではありません。ご了承くださ い。
3. 3. はじめに - 最初に推薦図書を列挙しておきます - この手の知識は、十年二十年と役に立つので - 十年後もエンジニアやりたい人は、読んでみて もいいかも
4. 4. 推薦図書 - はじめて読む486 - OSの勉強をするときに読んどくといいかも - CPUの創りかた - Write Great Code〈Vol.1〉 - 比較的プログラマよりの内容 - 電子書籍版 もある - Write Great Code〈Vol.2〉 - 最近のコンパイラだいぶ賢いから、ちと古いかも
5. 5. - これらの書籍、十年くらい前に読んだんですが - いま思い返しても、良い内容だった（という気が するので） - いまはじめて読んだとしても（たぶん）役に立つ - 良い書籍は、十年以上経っても価値があると思 います
6. 6. - ただ、流石に古い気がしなくもないので - 最近の本で良い書籍あったら教えて下さい - 書籍以外でいうと、日本のライターさんは優秀 なので、Web上に日本語でいい記事がけっこう あります。 - わたしはよく後藤弘茂さんや、大原雄介さんの 記事を読んでます
7. 7. 次に、インフラエンジニア向けの一冊 - クラウドを支える技術 ──データセンターサイズ のマシン設計法入門 - Google の人がDCについて書いてる - 個人的には「電気代とビッグデータ」がテーマだ と感じた。彼らのワークロードに最適化するとこ うなるという - 彼らがCPUをどう捉えているかわかって面白い
8. 8. CPUの細かい構造や仕組みについては - 作図が嫌いというかめんどくさいのでカツアイし ます - 各々調べてみてください - というわけではじめます
9. 9. CPUはなぜ遅いのか？ - 消費電力や排熱の都合上、動作周波数を上げ にくい - 電圧上げないとクロック上げられないけど、電圧もクロッ クも消費電力に多大な影響を与える - IPC（Instructions Per Cycle）を上げるのが大 変難しい - execution unit の稼働率を上げるのが難しい
10. 10. そして何より
11. 11. DRAMが遅い
12. 12. CPUから見ると、DRAMは非常に遅い - CPU内部のキャッシュと比べて100倍以上遅い - これは可視化できてて面白い - メモリアクセスを減らせないと、CPUの execution unit の稼働率を上げられない - DRAMの遅さに引きずられる
13. 13. DRAMの遅さに引きずられる？ - CPU内部の execution unit が欲しい速さでは、 DRAMからデータを転送できない - 複数のスレッドやプロセスが、メモリアクセスをし て、メモリからデータを読み込むのを待って - パイプライン がストールする - レジスタの取り合いになるなど、ストールするケースは他 にもあるけど、DRAMの遅さはかなり致命的
14. 14. ちなみに最近の Intel の L1 cache は - いわゆる ハーバード・アーキテクチャ - 命令とデータが別々の領域に格納されてる - 他の cache と異なり、 L1 cache だけは命令と データで二種類ある - 命令がぜんぶ L1 cache から捨てられると大変 なので、これはアリな設計だと思います
15. 15. DRAMが遅いから - CPU の execution unit の稼働率が低いので、 Intel は Hyper-Threading 導入したそう - Typically, applications make use of about 35 percent of the internal processor execution resources. The idea behind Hyper-Threading Technology is to enable better processor usage and to achieve about 50 percent utilization of resources.
16. 16. じゃとりあえず - 広範囲にメモリアクセスすると遅いっていう、至 極簡単で、人類にとって何の役にも立たないサ ンプルコード書いてみたんで - これとこれ - じっさいに見てみましょう
17. 17. で、具体的には - こんな感じでコンパイルして、差分はこんだけ - Xeon L5630 の環境 と E5-2630L v3 の環境 - Xeon L5630 or Xeon E5-2630L v3 - Ubuntu 14.04.3 LTS - kernel 3.13 x86_64 - glibc 2.19 - gcc 4.8.4
18. 18. 実行するとこんだけ違う - けっか - L5630 - E5-2630L v3 - CPUのキャッシュから引けないと、CPUの backend（演算装置）がめっちゃ待たされる
19. 19. 最近のCPUとDRAMだいぶ優秀ですが - clock down してるとだいぶ性能落ちます - L5630 - E5-2630L v3 - L5630 と E5-2630L v3 の差がなくなる勢い - 最近のCPUは clock の落ち幅が大きい傾向に あるので、このへん注意しましょう - Brendan Gregg は AWS でも MSR 見てるよう ですしね
20. 20. 閑話休題 - 据置型ゲーム機の優位性はざっくり以下の２つ - コストパフォーマンス（ゲーミングPCよりかなり安い） - メモリの帯域 - ゲーム機に限らず、GPUを酷使するならメモリの帯 域は重要になる。GPUはメモリの帯域食うので - 少々コスパが悪くても、据置型ゲーム機には、PCで 使われてるものより高速なメモリが積まれてる
21. 21. じゃ、なんでCPUは こんな状況なの？
22. 22. 10年前と比べ、CPUは何が良くなったか - プロセスルールが進んで微細化が進んだ結果、 消費電力減った - 省電力機構が進化した - DRAMの帯域が増えてきた - しかし、まだ足りない。CPUほど進歩してない。 - 動作周波数上げるの難しいから、Coreの数が 増えてきている。特にXeonは劇的に
23. 23. クロック上げるのが難しいから - 電圧を上げないと、クロック（動作周波数）はそ んなに上げられない - 消費電力は、電圧の二乗×動作周波数 に比例 - 電圧上げたくないから、 今でも、x86 は高くても 4GHzくらいの動作周波数しかない - 電圧上げるくらいなら、ということでコアを増やし てる
24. 24. そして
25. 25. トランジスタが 余ってきた
26. 26. トランジスタが余った結果 - コアの数を増やしたけど - キャッシュを増やしたけど - まだ余るので、アンコア（Uncore）を強化する余 裕ができた - Skylake に至っては、カメラ用にISP(Image Signal Processor) まで積んだらしい - 確かにイマドキのWindowsマシンには、組み込みの カメラ普通についてる
27. 27. アンコア？ - CPUに統合された、coreじゃない部分 - メモリコントローラや I/O コントローラなど - プロセッサーコアやキャッシュじゃない部分 - かつてはマザーボード上のチップセットなどで実 現していた、様々な機能を統合している - 消費電力削減やI/Oの性能改善に貢献している
28. 28. アンコアの強化に至る前、2006年ごろ - Intel は Larrabee で many core の夢を見た - 一方、 Sony、 SCE、IBM、東芝は、 Cell という ヘテロジニアスアーキテクチャをもたらした - Cellは扱いが難しいけど性能でたので、ヘテロ ジニアスな設計を他のCPUベンダーは追いか けることになった
29. 29. - トランジスタが余ってきたと思うけど - いまのSRAMやプロセッサーコアだけでは、 CPU上のトランジスタを上手く使い切れない - CellがPPEとSPEを分けたように、CPUの中に 様々な機能を持つものを入れていくほうが効率 がいい
30. 30. ここで Intelさんを 振り返ってみると
31. 31. Intelさんとしてはきっと - いまの Xeon は大勝利 - NetBurst のときの失敗は取り返せた - もはやサーバ市場で恐れるものは無いのだろう - 性能が上がるとサーバの高集約化が進んで、台数の伸びは鈍化する だろうけど - PCやサーバ以外の市場も取らないといけない - 自社のFabを自社製品の製造で埋め尽くせるの が理想
32. 32. Intelは自社の生産ラインを使い切りたい - 研究開発をし、他社の追随を許さない製造技術 を持ち続ける - 研究開発費を回収するために、大量生産する - PCやサーバのCPUだけでは、自社工場の生産 ラインを埋められなくなってきた - NAND Flash の製造で自社工場を活用するの も必然
33. 33. それでも足りない - IDF の資料を見ると、そのとき Intel が取りた がってる市場がうかがい知れるんですが - IDF2012 Beijing に行ってきたとき、 Ultrabook と HPC の話ばかりだったので、「あぁWebサービスなんてIntel から見たら大したことないんだ」と実感できました - Intelは数年前からタブレットやスマートフォン、 いまだとIoT狙ってますけど、研究開発を維持す るために、市場の拡大が必須なわけです
34. 34. そんなIntelさんだけでなく、業界的に - シングルスレッド性能はもう10年前から伸び悩 んでる - 物理的に今の製造技術や、素材の限界があ るそうで - 新しい素材や製造技術の研究が進められてい るみたいですが、実用化するまでまだまだ年月 は必要そう
35. 35. 閑話休題・２ - 現代のトランジスタ製造技術ってすごいんです - 絶縁膜が原子数個分のレベルらしいです - こうなってくると、もう、電流がリークしてもしょう がないですよね？ - ただ、現状を打ち破るには、基礎研究に時間と 経費がかかるんです
36. 36. 個人的に思うんですが - 情報産業は、普通の業界と比べて流行り廃りが 激しいのでドッグイヤーと言われますが - 個人的に、半導体の基礎研究はその７倍の時 間、犬ではなく人間の遅さで進んでると思うので - そう考えると、カーボンナノチューブがノーベル 賞レベルと言われても納得なんですが、我々の ところまで来るのには時間かかるんです
37. 37. だから我々は、 物理学や化学を 支援する必要があると 思います
38. 38. 極論すると
39. 39. エンジニアにとって CERNみたいな研究機関は、 ハードウェアの進化のために 必要なんじゃないでしょうか
40. 40. ムーアの法則が終わると言われてますが - それは、ブレイクスルーとなるような技術革新が 起きるのに時間がかかるせいだと思うので - 半導体の集積密度とは違うけど、例えば、3D NANDを 東芝が発表したのは2007年で、本格的な出荷開始は 2016年とか - 逆に考えると、注意深く見ていさえすれば、次世 代のハードウェアと、それに伴う環境の変化が あるていど予測できるんじゃないかと
41. 41. 最近のIntelさんの Xeonを見て思うに
42. 42. - 5年前の低電圧版Xeonと現在の低電圧版 Xeon 、似たような価格帯のを比べると - 物理コアは4から8に増えつつ、 Last Level Cache は1.6倍に - North Bridge は CPU に統合され、 PCI- Express 経由で GPU や NIC、 NVMe は、 CPU と直結できるようになった
43. 43. DDIOサイコー - NICとCPU直結できるようになって、 Intel Data Direct I/O ができた - NICがメモリを経由せず、LLCに直接読み書き できるようになりました - GbEや10GbEでは、大量のパケット受信すると むかしは大変重かったんですが - これでかなりネットワークの性能改善しました
44. 44. TurboBoostって悪い仕組みじゃない - ARMにはbig.LITTLEっていう構成があります - 高性能なcoreと低消費電力なcoreを、そのときどきで使 い分ける - なんで Intel は採用しないんだろ？って思ったけ ど、 Intel さんには TurboBoost がありました - 性能出したいcoreだけクロック上げて、熱や消費電力を コントロールすればいい - 省電力的にはARMの方が良い構成だけど
45. 45. そろそろTurboBoost使いこなしたい - ただ、サーバのことを考えると、全部のコアを無 駄なくつかえる TurboBoost の方が合理的で - 全力でぶん回したとき、CPU上に無駄なものがないから - 実は、 AWSのC4インスタンス も TurboBoost 使えるんすよ - 次のインフラないしシステムでは、個人的に活 用したいとアイデアを練ってるところ
46. 46. いままで雑多に話し ましたが
47. 47. さて、現時点で我々は - 最近のXeonは選択肢が増えた - いまどんなXeonを買うかというと - Coreの数、メモリの帯域、消費電力のバランス 次第じゃないですかね - Coreに比例してメモリの帯域増えるわけじゃな いんで、Coreそんなにいらないかもしれないし - 実際に動かしてみて評価してみないことには
48. 48. いまコードを書く上で考えるべきは - アンコアが充実して、I/Oが速くなったりしたけど - L2 cache や Last Level Cache の容量増えて きてるけど、これ以上増やしすぎると、キャッ シュ管理のコストが上がってLatency悪くなるの で、SRAMのキャッシュはそんなに増えないん じゃないかなぁ - となると、如何にしてメモリアクセスを削減する か
49. 49. クライアントサイドで考えると - CPUのキャッシュを如何に活用するか（如何に メモリアクセスを抑えるか）によって、高い性能 をもたらせる - ARMの事例ですが、 スクエニの杉本さんは、Android版 スクストのフットプリントを数百KBに収めた - コンソールゲーム業界の職人は、そこまでやっ て性能を叩き出す
50. 50. サーバサイドでは - MySQLみたいに、巨大なメモリに広範囲にアク セスするソフトウェアは、 L2 cache に全ての データが載るわけではないが - ただ L2 cache がムダかというとそうでもないと思います - メモリなどI/Oの帯域を節約できるコードは、結 果として速い - MySQL で table がメモリに載っていても、 full table scan は避けるべき
51. 51. ただ、サーバサイドでも - それでも、メモリの無駄遣いは良くないので - TLB miss 発生するとメモリアクセス増えるし - あと、C/C++ などでコードを書くときは、スタック を上手く使える方がいいんじゃないでしょうか。 スタックは hotspot で、 TLB で引けるだろうし、 CPUのキャッシュに載ってる可能性高いし - 詳しくは Write Great Code でも読んでください
52. 52. そして、 たぶん2-3年くらい後の Xeon には
53. 53. （おそらく）劇的 な変化が来る
54. 54. Xeon に L4 cache として eDRAM が載れば サーバでも（一部の）コードが cache に載る時代が来る
55. 55. Intel のロードマップではまだないけど - 最近の Core i7 では 128MB の eDRAM を L4 cache として使えるようになった - この eDRAM 、実はかなりすぐれもので、いま までの DRAM よりかなり速い - この eDRAM にフィットするコードを書けば、主 記憶へのアクセス減らせるのでサーバでも速い
56. 56. ただ、 Intel さんにお願いしたいのは - PHPなど Lightweight Language のWebアプリ ケーションなら、 L4 cache にフィットするかもし れませんが - MySQLみたいなRDBMSだとムリなんで - L4 cache のあるXeonと無いXeon、あるいは、 L4 cache の無効化ができると嬉しいです - cacheの階層増えるとメモリアクセスのLatency に影響するんで
57. 57. 直近では L4 cache 来るかもだけど - メモリベンダーが想定している未来だと - メモリの階層がかなり増える - Near Memory と Far Memory - OSからみたとき、速いメモリと遅いメモリが混在 するという可能性
58. 58. 近いメモリと遠いメモリ - 実はすでに存在している概念 - 具体的にいうとNUMA - x86 で NUMA の概念がもたらされたのは、 も う十年以上前 - いまでは NUMA も珍しくなくなった - OSのサポートや最適化進んできたし - percona server でも NUMA 向けオプションあるし
59. 59. きっと未来では - NUMA のように、プログラマに受け入れられる 時代になる - 10年先か、20年先はわからないけど - 先ずは Windows で取り入れられるだろうから、 Windows の動向を見守るのがいい - 何気に Windows ってかなり先進的なOSなんで
60. 60. 私が思うに - 速いメモリが1GB～4GBくらいあるなら - Linuxなら、そこに kernelとlibcとPTE載せちゃう のが、合理的だと思うんだ - それで余ったら、large page みたいなノリでプロ セスからも使えるようになるかもしれん - mysqld のコードをそこに割り当てたいな - 楽しみやね
61. 61. ちなみに Xeon Phi では - DDR4 の5倍のバンド幅を持つメモリが、オン パッケージで来る そうですね - なので、来てくれるんじゃないですかね、いつか そのうち。速いメモリってやつが
62. 62. 最後に - 三年後、どんなサービスが流行ってるのか考え るのは難しい - でも、サーバがどんな進化を遂げるかは、ベン ダーのロードマップや、現時点における半導体 の限界を学んでおけば、ある程度予測できる - その変化を予測して備えておけば、エンジニア として準備ができる
63. 63. 半導体を学んで、 サーバの未来を より良くする
64. 64. おわり