Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
パタヘネ輪読: 第一章
Search
kota-yata
October 15, 2024
Programming
0
34
パタヘネ輪読: 第一章
kota-yata
October 15, 2024
Tweet
Share
More Decks by kota-yata
See All by kota-yata
Media over QUICとRTMP+HLSの比較
kota_yata
1
790
2023年秋 中村研 WIP発表資料
kota_yata
0
45
2023年春 中澤大越研 WIP発表資料
kota_yata
0
27
BigIntの良いとこ悪いとこ
kota_yata
0
49
末尾呼び出し最適化とJavaScript
kota_yata
12
10k
Catenaryの技術のこと
kota_yata
0
390
年越しアイデンティティ
kota_yata
0
370
Principle of SSI
kota_yata
0
450
What are the interns at Code for Japan doing?
kota_yata
0
380
Other Decks in Programming
See All in Programming
Scalaから始めるOpenFeature入門 / Scalaわいわい勉強会 #4
arthur1
1
330
良いユニットテストを書こう
mototakatsu
7
2.2k
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
770
採用事例の少ないSvelteを選んだ理由と それを正解にするためにやっていること
oekazuma
2
1k
「Chatwork」Android版アプリを 支える単体テストの現在
okuzawats
0
180
rails stats で紐解く ANDPAD のイマを支える技術たち
andpad
1
290
なまけものオバケたち -PHP 8.4 に入った新機能の紹介-
tanakahisateru
1
120
RWC 2024 DICOM & ISO/IEC 2022
m_seki
0
210
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
470
Semantic Kernelのネイティブプラグインで知識拡張をしてみる
tomokusaba
0
180
フロントエンドのディレクトリ構成どうしてる? Feature-Sliced Design 導入体験談
osakatechlab
8
4.1k
Security_for_introducing_eBPF
kentatada
0
110
Featured
See All Featured
Designing for humans not robots
tammielis
250
25k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Adopting Sorbet at Scale
ufuk
73
9.1k
It's Worth the Effort
3n
183
28k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
Six Lessons from altMBA
skipperchong
27
3.5k
How GitHub (no longer) Works
holman
311
140k
Visualization
eitanlees
146
15k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Automating Front-end Workflow
addyosmani
1366
200k
Transcript
パタヘネ輪読: 第⼀章 Arch B2 Kota
全体の流れ • はじめに:コンピュータの急速な進歩 • はじめに:この本で学べること • 「コンピュータ‧アーキテクチャにおける7つの主要なアイディア」 • プログラムの裏側:ソフトウェアの階層化と抽象化 •
ハードウェアの話:コンピュータの構成要素 • ハードウェアの話:iPhone XS Maxの中⾝を⾒る • 集積回路の進化と⽣産⼯程 2
全体の流れ 3 • コンピュータの「性能が良い」とは? • コンピュータの消費電⼒の限界 • マルチプロセッサへの変遷と並列処理 • Intel
Core i7のベンチマークテストを⾒る • Pythonの⾏列乗算プログラムで⾒る⾼速化 • コンピュータに関する誤信
コンピュータの急速な進歩 4 • コンピュータは1940年代後半の出現以来、急速に進歩している >もし運輸産業がコンピュータ産業と同じ速度で進歩していたとすれば、今⽇ ニューヨークからロンドンまで旅⾏するのに必要な時間は1秒、料⾦は1セントに なっているはずである かつては空想のものだった携帯電話、検索エンジン、あるいは⾞載コンピュータが 当たり前の世の中になった
コンピュータの急速な進歩 5 • パーソナルコンピュータ ◦ 低コストかつそれなりの性能が求められる • サーバー ◦ 単⼀の複雑なアプリケーションを動かす場合や⼩規模なタスクを⼤量に扱う場合がある
◦ 処理能⼒、容量は⽤途によって⼤きく異なる(⼩さいWebサーバーからスパコンまで) • 組み込みコンピュータ ◦ ⾃動⾞やテレビから冷蔵庫まで、あらゆるハードウェアに組み込まれるプロセッサ ◦ ⽐較的低い性能でコストと消費電⼒を最⼩限に抑えることが求められる 進歩に伴ってコンピュータの利⽤形態も多様化した
コンピュータの急速な進歩 6 ポストPCの時代:スマホ、タブレット端末(PMD)の台頭
この本で学べること 7 • 1960-1970年代のコンピュータの主な制約はメモリ容量だったが、現在ではそ れはほとんど問題ではない ◦ プロセッサの並列性や記憶容量の階層性に対する理解の⽅が重要 ◦ PMDやクラウド上のプログラムについてはエネルギー効率も重要な要因の⼀つ 昔に⽐べて、現代のプログラマは知るべき知識が⼤きく増えている
→だからこそ、その根底になるソフトウェアとコンピュータの内部知識をこの本で学ぼう
この本で学べること 8 • ⾼⽔準⾔語で書かれたプログラムがハードウェア向けにどう翻訳され、どう実⾏される のか • プログラムを実⾏するためにソフトウェアはハードウェアにどんな指⽰を出すのか • プログラムの性能はどう決まり、どう性能改善できるのか •
ハードウェア設計者は性能‧エネルギー効率のためにどのような技法を⽤いているのか • 逐次処理から並列処理への転換はなぜ起きたのか、またどういう結果をもたらすのか • 商⽤コンピュータが誕⽣して以来、現代のコンピューティングの基礎を築くためにどの ようなアイディアが考案されたのか >以上の質問に対する答えを理解しないままで、現代のコンピュータにおけるプログラム性能を改善 しようとしたり、ここのアプリケーションでコンピュータ間の優劣にどんな特性が影響するかを評 価しようとしたりすることは慎んでほしい
コンピュータ‧アーキテクチャにおける7つの主要なアイディア 9 • 抽象化 ◦ 下位レベルのプログラムの詳細を隠すことによりモデルを単純化する • 「⼀般的な場合」の⾼速化 ◦ 多くの場合、「⼀般的な場合」は稀な場合よりも⾼速化が単純である
◦ 「⼀般的な場合」は様々な指標の測定によって初めて可能になる(ベンチマーク) • 並列処理 ◦ この本通して頻繁に登場するアイディア 過去60年のコンピュータ設計において考案された7つの主要なアイディア
コンピュータ‧アーキテクチャにおける7つの主要なアイディア 10 • パイプライン処理 ◦ ⾮常に多様される並列処理⽅式 ◦ ⽕事場のバケツリレー • 場合の予測
◦ 「先に許可を求めるよりも、後で許しを請す⽅が良い」 ◦ 処理の中で、ある程度予測のつく処理を先に実⾏してしまう • 記憶の階層化 ◦ 最⾼速だがビット当たりのコストが⾼い最⼩容量のメモリを最上部、その逆を最下部に 配置することでコストを抑えつつ性能を改善した 過去60年のコンピュータ設計において考案された7つの主要なアイディア
コンピュータ‧アーキテクチャにおける7つの主要なアイディア 11 • 冗⻑化 ◦ 商⽤のサーバーなどであれば特に、⼀つの物理的な装置が故障しても動き続けるような ⾼い信頼性が求められる ◦ 故障した時に替えがきくような冗⻑なコンポーネントを⽤意する 第5版では「ムーアの法則に従って設計する」も含まれていたらしい
• 集積回路のリソースは毎年倍増するという法則 • 近年ではこの法則の正確性は低下してきた(指数的な成⻑は続かない) 過去60年のコンピュータ設計において考案された7つの主要なアイディア
プログラムの裏側 12 • コンピュータのハードウェアが実⾏できる命令の数はとても少ない • ソフトウェアをレイヤーに分け、⾼⽔準の処理を単純な命令の組み合わせ に変換していくことで、複雑で⼤規模なアプリケーションの実⾏が可能に なる ソフトウェアの抽象化
プログラムの裏側 13 • コンピュータのハードウェアが実⾏できる命令の数はとても少ない • ソフトウェアをレイヤーに分け、⾼⽔準の処理を単純な命令の組み合わせ に変換していくことで、複雑で⼤規模なアプリケーションの実⾏が可能に なる ソフトウェアの抽象化 :
⾚⾝の寿司を提供したい →⾚⾝を切る →シャリを握る →⾚⾝をシャリの上に乗せる →客に差し出す
プログラムの裏側 14 • コンピュータのハードウェアが実⾏できる命令の数はとても少ない • ソフトウェアをレイヤーに分け、⾼⽔準の処理を単純な命令の組み合わせ に変換していくことで、複雑で⼤規模なアプリケーションの実⾏が可能に なる ソフトウェアの抽象化 :
⾚⾝の寿司を提供したい →⾚⾝を切る →シャリを握る →⾚⾝をシャリの上に乗せる →客に差し出す : シャリを握る →ご飯を炊く →酢飯にする →適当な分量掴み取る →握る より低いレイヤ
プログラムの裏側 15 • ハードウェアとソフトウェアの最低⽔準のインターフェースとなる⾔語体 系を命令セットアーキテクチャと呼ぶ ソフトウェアの抽象化
プログラムの裏側 16 • ハードウェアは電気的な0/1の信号のみを理解する • アルファベットと同じように、0/1の組み合わせでハードウェアに命令を 伝えている(これを機械語という) • 命令を⽂字で書けるようにアセンブリ⾔語が作られた ◦
⼀命令⼀⾏で書いていく⾔語 ◦ アセンブリ⾔語を機械語に翻訳するシステムをアセンブラという ◦ しかしこれでは実際のアプリケーションを書くにはコード量が多すぎる。。 ▪ 例えばどのアセンブリ⾔語でもHello Worldを出⼒するのに10-20⾏は書く必要があ る ⾼⽔準⾔語からハードウェアの⾔語へ:⾔語の抽象化
プログラムの裏側 17 • より多くのことを⼀度に書きたい→⾼⽔準⾔語の誕⽣ ◦ CとかRustとか、いわゆるプログラミング⾔語 ◦ ⾼⽔準⾔語をアセンブリ⾔語に変換するシステムをコンパイラという ◎ 擬似的な例
⾼⽔準⾔語: A+B → アセンブリ⾔語: add A, B → 機械語: 1000110010100000 ⾼⽔準⾔語からハードウェアの⾔語へ:⾔語の抽象化 ⾼⽔準⾔語を使うことで、プログラムをコンピュータから独⽴させられる
ハードウェアの話:コンピュータの構成要素 18 • データの⼊⼒ ◦ マイクやキーボード、マウスのような⼊⼒装置 • データの出⼒ ◦ スピーカーやディスプレイなどの出⼒装置
• データの記憶 ◦ HDD、メモリなどの記憶装置 • データの処理 ◦ プロセッサでの演算、制御など コンピュータ‧ハードウェアの役割
ハードウェアの話:iPhone XS Maxの中⾝を⾒る 19 装置の⼤部分は⼊出⼒装置で占められている • ディスプレイ、カメラ、マイク、スピーカー、加速度計 etc. これがプロセッサとメモリ を格納した基板
ハードウェアの話:iPhone XS Maxの中⾝を⾒る 20 プロセッサ(CPU) • 数値演算や条件判定などを⾏い、 他のコンポーネントの動作を制御 する役割を持つ PMIC
• 電源管理装置 • 疑問:なんでこんなにあるのか A12のようにCPU、GPUなど多機能を1 チップに集約したものをSoC (System on Chip)という
ハードウェアの話:iPhone XS Maxの中⾝を⾒る 21 キャッシュはSRAMを使⽤している • 「フリップフロップ回路」なる複雑な回路 • リフレッシュ動作が要らないかつ⾼速 ⼀⽅メモリ(1次記憶)はDRAMを⽤いる
• 電荷で情報を保持する • 定期的にリフレッシュ動作が必要 さらに下位の2次記憶にはフラッシュメモリが⽤ いられる • より低速でより安価&不揮発 記憶の階層化
集積回路の進化と⽣産⼯程 22 プロセッサ、メモリを構成する技術とその性能の進化 集積回路はトランジスタを1つのチップにまとめて接続したもの • プロセッサになる • ムーアの法則: 1チップに載るトランジスタ数は約2年ごとに倍増する
集積回路の進化と⽣産⼯程 23 ムーアの法則の低下 • 近年では⼤体3年で2倍くらいという感じ
集積回路の進化と⽣産⼯程 24 • シリコンは砂の中に含まれ、電気を中程度通すので半導体とも呼ばれる • 特別な化学処理を施すことで以下の3つの性質のいずれかを持たせる ◦ 電気をよく通す導体にする ◦ 電気を通さない絶縁体にする
◦ 条件に応じで電気を通したり通さなかったりする物体にする ▪ (これがトランジスタ) 集積回路はシリコンからなる
集積回路の進化と⽣産⼯程 25 • シリコンの結晶、シリコンインゴットを輪切りにして円形のウエーハを作る • ウエーハに多重な⼯程でパターンを焼き付ける • ウエーハをテストし、その後構成要素のダイ(後のチップ)に切り分ける • ダイはその後パッケージングされ、さらなるテストを経て出荷される
集積回路の進化と⽣産⼯程 26 ウエーハを⼩さく分割することで、傷がついた場合に破棄する部分を最⼩限に 抑える • ウエーハ内のダイのテスト成功率を歩留まり(yield)という • ダイのサイズが⼤きいと歩留まりが下がり、単⼀ウエーハに載せられるダ イの数も減る→コスト増加 •
現在はダイ、つまりチップ内のトランジスタの最⼩単位が5nmになるレ ベルまで⼩型化が進んでいる なぜ細かくダイに分けるのか
コンピュータの「性能が良い」とは? 27 ⾶⾏機の「性能」を定義しにくいのと同様コンピュータの「性能」も難しい 搭乗員数だったらエアバス、航続距離だったら777、巡航速度ならコンコルドだ けど輸送能⼒はエアバス🤔…
コンピュータの「性能が良い」とは? 28 サーバーなどの⼤型コンピュータであれば複数のユーザーの複数のタスクを 限られたスレッドで処理している(タイムシェアリング⽅式) • タイムシェアリングできることもまた性能。。。 個⼈のコンピュータユーザーは実⾏時間の短さに関⼼があるが、データセン ターの管理者は⼀定時間内に終了した作業の総量(スループット)、⼀定時間 に送信できるデータ量(バンド幅)に関⼼がある 1タスクを速く終わらせれば性能が良いのか?
コンピュータの「性能が良い」とは? 29 主にタスク(プログラム)の実⾏時間の短さに注⽬する • 実⾏時間が短い=性能が良い • XがYよりn倍速ければ、実⾏時間はYの⽅がXよりもn倍⻑い • ここでいう実⾏時間とは、プロセッサが実際にタスクの処理に費やした 時間(CPU実⾏時間)である
◦ 前述のタイムシェアリング⽅式の場合、応答時間が必ずしもCPU実⾏時間とは限らない この本の最初数章における性能の定義
コンピュータの「性能が良い」とは? 30 • コンピュータは、クロックというタイミング単位で処理を⾏う ◦ その周期をクロックサイクル時間、その逆数をクロック周波数という ◦ CPU実⾏時間 = プログラムのクロックサイクル数
/ クロック周波数 コンピュータにおける「時間」
コンピュータの「性能が良い」とは? 31 • コンピュータは、クロックというタイミング単位で処理を⾏う ◦ その周期をクロックサイクル時間、その逆数をクロック周波数という ◦ CPU実⾏時間 = プログラムのクロックサイクル数
/ クロック周波数 コンピュータにおける「時間」 ⼤トロ(1000サイクル)を握る
コンピュータの「性能が良い」とは? 32 • コンピュータは、クロックというタイミング単位で処理を⾏う ◦ その周期をクロックサイクル時間、その逆数をクロック周波数という ◦ CPU実⾏時間 = プログラムのクロックサイクル数
/ クロック周波数 コンピュータにおける「時間」 寿司職⼈A(1GHz) 1秒間に10億クロック クロックサイクル時間は1ns ⼤トロのCPU実⾏時間は1μs 1秒間に100万⼤トロ ⼤トロ(1000サイクル)を握る
コンピュータの「性能が良い」とは? 33 • コンピュータは、クロックというタイミング単位で処理を⾏う ◦ その周期をクロックサイクル時間、その逆数をクロック周波数という ◦ CPU実⾏時間 = プログラムのクロックサイクル数
/ クロック周波数 コンピュータにおける「時間」 寿司職⼈B(2GHz) 1秒間に20億クロック クロックサイクル時間は0.5ns ⼤トロのCPU実⾏時間は0.5μs 1秒間に200万⼤トロ ⼤トロ(1000サイクル)を握る 寿司職⼈A(1GHz) 1秒間に10億クロック クロックサイクル時間は1ns ⼤トロのCPU実⾏時間は1μs 1秒間に100万⼤トロ
コンピュータの「性能が良い」とは? 34 • コンピュータは、クロックというタイミング単位で処理を⾏う ◦ その周期をクロックサイクル時間、その逆数をクロック周波数という ◦ CPU実⾏時間 = プログラムのクロックサイクル数
/ クロック周波数 コンピュータにおける「時間」 プログラムの性能を上げるには、プログラムのクロックサイクル数を減ら すか、クロック周波数を上げる必要がある
コンピュータの「性能が良い」とは? 35 • 実際にコンピュータが実⾏する命令は、命令ごとに必要なクロックサイ クル数が異なる ◦ CPI(命令あたりの平均クロックサイクル数)とプログラムの命令数をかければそのプロ グラムのクロックサイクル数が算出できる プログラムのクロックサイクル数はどう算出するのか?
コンピュータの「性能が良い」とは? 36 CPU実⾏時間 = 実⾏命令数 * CPI * クロックサイクル時間 もしくは
CPU実⾏時間 = 実⾏命令数 * CPI / クロック周波数 - - - - - - - - - - - - - - まとめ:古典的なCPU性能⽅程式 • クロックサイクル時間は通常コンピュータのスペックとして公開されている • 実⾏命令数はシミュレータ、ハードウェアカウンタなどを通して計算する • CPIはメモリシステムやプロセッサの構造などによるため計算が難しい
コンピュータの消費電⼒の限界 37 9世代のIntelマイクロプロセッサに⾒るクロック周波数と消費電⼒の変遷 • 2004年あたり以降から両⽅とも頭打ちになっている ◦ 量産品であるマイクロプロセッサの冷却能⼒に限界が来た 電⼒にものを⾔わせて1つのプロセッサの性能を追求する時代の終焉
コンピュータの消費電⼒の限界 38 集積回路内の⼀つのトランジスタに必要な電⼒は以下の式で算出される 消費電⼒ = ½ * 容量性負荷 * 電圧^2
* 切り替え周波数 • 集積回路の主要テクノロジであるCMOSにおいて、エネルギー消費の主要因はトラ ンジスタの0/1の切替の動的エネルギーである ◦ これは½ * 容量性負荷 * 電圧^2で求められる ◦ 容量性負荷は、コンデンサの電荷が変わる際の抵抗のようなもの?? 消費電⼒の算出⽅法
コンピュータの消費電⼒の限界 39 なぜ電⼒が30倍になる間にクロック周波数は1000倍に上昇していたのか? • 電⼒は電圧の2乗の関数である • 世代が進むごとに、プロセッサが要する電圧は約15%下げられてきた • クロック周波数の成⻑に⽐べて消費電⼒は低く抑えられてきた
マルチプロセッサへの変遷と並列処理 40
マルチプロセッサへの変遷と並列処理 41 • 2006年時点で、すべてのメーカーが1つのチップに複数のプロセッサを載せた マイクロプロセッサを出荷するようになった ◦ これはスループットの向上に⼤きく貢献した ◦ 「コア」と呼ばれるものは単⼀のプロセッサで、マイクロプロセッサはnコア‧マイクロプロ セッサなどと呼ばれるようになった
• これにより、プログラマは並列処理を前提としたプログラミング技術を求めら れるようになった ◦ 古くから存在するパイプライン処理などは命令レベル並列性と呼ばれ、プログラマ、コンパイ ラ共に逐次処理と同じ書き⽅で何も問題はなかった ◦ この頃からプログラマは、並列処理のためのスケジューリング、負荷の平準化、同期のオー バーヘッドの減少に取り組む必要が出てきたのである ※並列処理については各章に説明が頻出する
Intel Core i7のベンチマークテストを⾒る 42 • CPUに対するベンチマークセット ◦ 「⼀般的な場合」の性能を判断するための、汎⽤的な処理を⽤いたベンチマーク • 今回の例ではSPEC
CPU 2017を⽤いる ◦ 10本の整数⽤ベンチマークと13本の浮動⼩数点⽤ベンチマーク ◦ 対象はIntel Xeon E5-2650L SPEC CPU
Intel Core i7のベンチマークテストを⾒る 43 CPU実⾏時間 = 実⾏命令数 * CPI *
クロックサイクル時間
Intel Core i7のベンチマークテストを⾒る 44 SPECratio = 実⾏時間 / 基準プロセッサ上での実⾏時間
Intel Core i7のベンチマークテストを⾒る 45 • SPECが出す、電⼒測定⽤のベンチマーク • ある期間サーバーを稼働させ10%刻みで負荷を変化させる SPECpower
Pythonの⾏列乗算プログラムで⾒る⾼速化 46 • これをIntel Skylake Xeon上で実⾏する ◦ ⾏列が960*960の時に約5分、4096*4096になると6時間になる ◦ 2章ではこれをc⾔語版に変換、3章では部分的に並列化を⾏う、4章では...
今後の章の⾼速化に使われるPythonプログラム
Pythonの⾏列乗算プログラムで⾒る⾼速化 47
コンピュータに関する誤信 48 • あるコンピュータ上で実⾏に100秒かかるプログラムがあり、そのうち80 秒が乗算に占められているとする ◦ この時乗算をどれだけ効率化しても、プログラム全体の実⾏速度を5倍以上速くすること は不可能である ◦ 改善後の実⾏時間
= 改善後の乗算にかかる時間 + 20秒 ◦ ある⾯を改善したことによる性能向上はその改善された機能の割合に制約される ▪ →Amdahlの法則(経済学においては収穫逓減の法則と呼ばれる) コンピュータの⼀⾯を改善すればそれに等しい性能向上が得られる
コンピュータに関する誤信 49 • 2020年において、SPECpower向きに構成されたコンピュータでも、負荷 が10%の時に以前としてピーク電⼒の33%を使⽤している ◦ ⼀般的なシステムであればさらに結果は悪くなる ◦ この問題が解決できれば、環境にも良いコンピュータが実現できる
コンピュータの利⽤率が低ければ消費電⼒は少ない
コンピュータに関する誤信 50 • 前述の通り、クロック周波数、命令数、CPIはそれぞれ別の要素に影響さ れ、どれが⽋けても正確な性能評価には⾄らない • MIPS = 実⾏命令数 /
(実⾏時間 * 10^6) なる直感的な指標があるが、命令 の働きが考慮されておらず、命令セットが異なるとこの指標は役に⽴たな い 性能の尺度に性能⽅程式の⼀部を⽤いる
おわりに 51 • コンピュータのあらゆる場⾯で抽象化の概念が⽤いられている • この本では特に並列処理を重要していて、全章にこのトピックが登場する • コンピュータの性能の尺度として有効なのは実⾏時間のみである