University of Tokyo

1/68

チューニングとその周辺

Hiroshi Watanabe Institute for Solid State Physics, University of Tokyo

1.  Introduction 2. Debugging 3. Tunings 4. Publication of Software 5. Summary

Outline

Mar. 14, 2012@CMSI 若手技術交流会（合宿） ［第五回］ 熱海

Collaborators: Masaru Suzuki (Kyushu University) Nobuyasu Ito (University of Tokyo)

University of Tokyo

2/68 自己紹介 (1/2)

I’m not a top runner of HPC!

Who are top runners?

ex) Todo-san, Iwata-san, Ishimura-san, etc... Top runner的なことはそういう人に聞いてください

University of Tokyo

3/68

Q. HPCのtop runnerじゃないならなんなのか？ A. Application Programmer

プログラム歴

小学校 PC-9801F BASIC 中学校から高校 DOSゲー Quick BASIC + アセンブラ (自分はほとんどアセンブラは組んでない) 大学 Borland C++ Builder Windowsのいわゆるフリーソフトをいくつか作成 大学院 数値シミュレーション Percolation, Event-driven MD、MPI馬鹿パラ 名古屋大学情報科学研究科 ActionScriptでFlashをいくつか作った 東京大学情報基盤センター MPIによる非自明並列化 東京大学物性研究所 いまに至る

自己紹介 (2/2)

University of Tokyo

4/68

MS-DOS

これまでに作ったものとか

ドラクエ型RPG (文化祭用：サブプログラマ、BGM、原画) 対戦アクションゲーム (コンテスト用：サブプログラマ、BGM、原画) ダンジョンRPG (高校卒業制作：サブプログラム、BGM)

Windows 対戦アクションゲーム (DOSゲーの移植) パズルゲーム2本 スクリプト言語の統合開発環境 迷路作成プログラム (ヤンメガという漫画の裏表紙になった模様) 量子計算シミュレータQCAD (未踏ソフトウェア採択)

Flash ミニゲーム パズルゲーム その他、交通流シミュレータや物性研クイズなど・・・

University of Tokyo

5/68 渡辺の発言の信頼度

プログラム歴はわりと長い ・プログラム開発方法 ・デバッグの方法 ・「良い」プログラムの書き方 ・複数人でのプログラム開発

←大丈夫

数値計算歴はさほど長くない

・CPU単体チューニング ・メモリマネジメント

←多分大丈夫だが 　　一部怪しい気がする

大規模計算は始めたばかり ・MPIによる非自明並列 ・大規模計算特有の何か ・国策スパコンについての意見その他

←かなり怪しい

また、フリーソフト作家出身なので、ソフトの公開について意見のバイアスあり

University of Tokyo

6/68

渡辺の発言をまるまる信用しないこと

特に僕は「偉そう」に話すので・・・

University of Tokyo

7/68

チューニング、その前に Before optimization

University of Tokyo

8/68

A fast runner is not a good soccer player. H. Watanabe, 2012

Before optimization

University of Tokyo

9/68

Do not optimize. 最適化するな

H. Matsuo, 2011

Before optimization

University of Tokyo

10/68

Q. 最適化、並列化でもっとも大事なことは何か？ What is the most important thing for optimization?

A. バグを入れないこと Keep your program from bugs.

Before optimization

University of Tokyo

11/68 Before optimization

バグを入れない方法

いろいろあるが、特に以下の二つの方法が有効 ・単体テスト ・sort + diff デバッグ

単体テスト

・テストしようとしている部分だけを切り出す ・その部分だけでコンパイル、動作するような最低限のインターフェース ・最適化、並列化する前と後で結果が一致するかを確認する ・本番環境でテストしない

sort + diff デバッグ

・print文デバッグの一種 ・出力情報を保存し、sortしてからdiffを取る ・単体テストと組み合わせて使う

University of Tokyo

12/68

ペアリストとは？

・相互作用距離(カットオフの距離)以内にある粒子対のリスト ・どの粒子同士が近いか？という情報 ・全粒子対についてチェックすると 　　 ・高速に粒子対を作成する方法　→ グリッド探索

グリッド法

・空間をグリッドに切り、その範囲に存在する粒子を登録する

排他的グリッド(Exclusive Grid )法

一つのグリッドに粒子一つ

・短距離相互作用

・二次元 ・高密度

非排他的グリッド(Non-Exclusive Grid )法

一つのグリッドに複数粒子

・長距離相互作用

・三次元 ・低密度

sort + diff デバッグの例1 - 粒子対リスト作成 (1/3)

University of Tokyo

13/68 sort + diff デバッグの例1 - 粒子対リスト作成 (2/3)

ポイント

O(N^2)法は、計算時間はかかるが信頼できる O(N)法とO(N^2)法は、同じconfigurationを与えられたら、 同じペアリストを作るはず 手順

初期条件を作るルーチンを作る ペアリスト作成ルーチンを作り、コンパイル、実行できるようにする (単体テスト) O(N)とO(N^2)ルーチンに初期条件を与え、作成したペアリストをダンプする ダンプ方法：作成された粒子対の、番号が若い方を左にして、一行に1ペア

O(N)とO(N^2)でリストの順番が異なるはずなのでsortする $ ./on2code | sort > o2.dat $ ./on1code | sort > o1.dat diffを取る $ diff o1.dat o2.dat 結果が正しければdiffは何も出力しない

いきなり本番環境に組み込んで時間発展、などとは絶対にしない

University of Tokyo

14/68 sort + diff デバッグの例1 - 粒子対リスト作成 (3/3)

並列版のデバッグ

ペアリスト作成の並列化 ・はじっこの粒子が正しく渡されているか？ ・周期境界条件は大丈夫か？

手順

初期条件を作るルーチンを作る 並列版と非並列版のペアリスト作成ルーチンを作る 非並列版はそのままペアリストをダンプ 並列版は「若い番号の粒子が自分の担当の粒子」 であるときだけダンプ sort + diffで一致を確認する

ポイント

まず、並列版と非並列版両方O(N^2)で試す →粒子の受け渡しがバグっているのか、O(N)の並列化が間違っているのか 区別するため

一度に複数の項目を同時にテストしない

University of Tokyo

15/68 sort + diff デバッグの例2 - 粒子情報送信

端の粒子の送り方

(a) ナイーブな送り方

(b) 通信方法を減らした送り方 (もらった粒子をさらに転送することで斜め通信をなくす)

粒子の情報を送ったあと、全粒子座標を出力 sort+diffで二つの方法の結果を比較する

University of Tokyo

16/68 sort + diff デバッグのまとめ

・新しい機能を追加するたびに単体テストをする ・高速化を試すたびに単体テストをする

単体テストとは、ミクロな情報がすべて一致するのを確認することであり、エネルギー保存など、マクロ量のチェックは単体テストではない

・時間はかかるが信用できる方法と比較する ・複数の機能を一度にテストしない ・特に並列プログラムはバグを入れるととても大変なので、事前に 　十分なデバッグが必要

デバッグとは、入れたバグを取ることではなく、そもそもバグを入れないことである

University of Tokyo

17/68

計算機の仕組み

University of Tokyo

18/68

Memory Memory Memory

Cache

CPU

Cache

CPU

Cache

CPU

Network

Programming Hierarchy

Parallelization

Memory Transfer

Tuning

Cache Efficiency Reduce Complexity

Parallelization Algorithm Communication Scheme (OpenMP, MPI)

Specialized Algorithm to Specific Architecture assembler, registers, SIMD

Importance: Memory Transfer > Tuning > Parallelization データ転送がボトルネックになりやすい

University of Tokyo

19/68 CPU (1/2)

RISCと CISC 世の中のCPUアーキテクチャは大別して RISC型とCISC型の二種類 CISC: 　・比較的複雑な命令セット 　・if分岐などに強い (Out of order 実行) 　・Intel Xeon, AMD Opteronなど。 RISC: 　・比較的単純な命令セット 　・行列演算などに強い 　・IBM Power, SPARCなど (京はSPARC VIIIfx)

マルチコアとSIMD化 最近のCPUはほぼマルチコア化とSIMD化で性能をかせいでいる ・マルチコアで性能を出すには、キャッシュとメモリの構造を把握する必要あり ・SIMDについては後述

RISCでOoOだったり、上記の分類に当てはまらないことも多いけど、それはそれ。

University of Tokyo

20/68 CPU (2/2)

ゲーム機とCPU 第六世代 DC SH-4 PS2 MIPS (Emotion Engine), VLIW GC IBM PowerPC カスタム (Gekko) Xbox Intel Celeron (PenIII ベース)

第七世代 Wii IBM PowerPC カスタム Xbox 360 IBM PowerPC カスタム PS3 IBM Cell 3.2

University of Tokyo

21/68 Memory Hierarchy

CPU

FPU

FPU L1 L2 Memory

Register

Register

Register

Register

・計算はレジスタ上で行う ・レジスタにのせられた情報はFPUに渡され、レジスタにかえってくる ・メモリアクセスで大事なのは、バンド幅とレイテンシ

Latency CPUにデータを要求されてから、レジスタに届くまでのサイクル数 ・L1キャッシュで数サイクル、L2で10~20サイクル、主記憶は~数百サイクル

Floating Processing Unit

Bandwidth CPUにデータが届き始めてからのデータ転送速度 絶対値(GB/s)よりも、計算速度との比(B/F)の方が良く使われる

University of Tokyo

22/68 レジスタとアセンブリ

アセンブリできること

条件分岐 (if文) メモリへの読み書き 足し算、引き算、掛け算、割り算 (レジスタ)

レジスタ

CPUが計算や比較などを行うための一時変数 すべての計算、比較は、一度レジスタに値を持ってくる必要がある

汎用レジスタ 256個 (めちゃくちゃ多い)ので、レジスタ不足は とりあえず気にしなくて良い (XeonやPOWERは気にする必要あり)

京コンピュータは

知っておくべき命令

とりあえずは和、差、積、積和、積差とそのSIMD版、あと三項演算子(fsel系命令) メモリ管理を考えたらもうちょっと必要かも。

University of Tokyo

23/68 レイテンシとパイプライン (1/3)

レイテンシとは

命令が発行されてから、値が帰ってくるまでのクロック数

fadd fp2,fp0,fp1

fadd fp4,fp2,fp3

fadd fp2,fp0,fp1 # fp2 ← fp0 + fp1 fadd fp4,fp2,fp3 # fp4 ← fp2 + fp3

計算中 計算中 計算中 計算中

計算終了 (fp2使用可)

計算中 計算開始 パイプライン

University of Tokyo

24/68

パイプラインとは

浮動小数点の加算、減算、掛け算といった計算を流れ作業で行う仕組み fadd fp2,fp0,fp1 (A) fadd fp5,fp3,fp4 (B)

(A) 1 (A) 2

(A) 3 (A) 4

(A) 5 (A) 6

fadd fp8,fp3,fp7 (C)

(B) 1 (B) 2

(B) 3 (B) 4

(B) 5 (B) 6

(C) 1 (C) 2

(C) 3 (C) 4

(C) 5

(D) 1 (D) 2

(D) 3 (D) 4

(E) 1 (F) 1 (E) 2

時間

(A) 計算終了 (B) 計算終了

(A) 計算開始

ここだけ見ると、６クロックかかる処理を同時に６つ処理している → 一クロックで一回の計算ができているように見える (レイテンシの隠蔽) これを「スループット が1」と呼ぶ

レイテンシとパイプライン (2/3)

University of Tokyo

25/68

パイプライン数

最近の石のパイプラインはだいたい２本

faddd fp2,fp0,fp1

fmuld fp3,fp1,fp4

計算中

計算中

計算中

計算中

計算終了 (fp2使用可)

計算中

計算開始

パイプライン

計算中

計算中

計算中

計算中

計算中

計算終了

計算開始

パイプライン

実質的に、１クロックで二つの計算が可能 → 2GHz × 2 = 4 GFLOPS

レイテンシとパイプライン (3/3)

※ Load/Storeも出せる場合はIPCは2より増える

University of Tokyo

26/68 積和(差)命令 fmaddd, fmsubd

積和、積差

積和　　　X = A*B+C 積差　　　Y = A*B-C アセンブラでは

fmaddd fp0,fp1,fp2,fp3 # fp0 ← fp1*fp2+fp3 fmsubd fp0,fp1,fp2,fp3 # fp0 ← fp1*fp2+fp3

乗算一つ、加減算一つ、あわせて二つが(実質)1クロックで実行される。 そのパイプラインが二つあるので、あわせて1クロックで４つの演算 → 2GHz × 4 = 8 GFLOPS

アセンブリにfmaddd,fmsubdが ずらずら並んでいなければダメ

University of Tokyo

27/68 SIMD化

SIMDとは Single Instruction Multiple Data の略。通称シムド/シムディー。 ベクトル命令のようなもの。 独立な同じ計算を同時に行う。

積和、積差のSIMD fmadd,s X1 = A1*B1+C1 , X2 = A2*B2+C2 を同時に実行 fmsub,s X1 = A1*B1-C1 , X2 = A2*B2-C2 を同時に実行

fmadd,sは、一つで4個の浮動小数点演算を行う。 「京」はこれが同時に二つ走る 4 * 2 * 2 GHz = 16GFlops (ピーク性能)

アセンブリにfmaddd,s fmsubd,sが ずらずら並んでいなければダメ

University of Tokyo

28/68 Summary of CPU architecture

・大雑把にいって世の中のCPUはRISCとCISCの二種類 　・RISC向け、CISC向けでhotspotくらいは変えたほうがいいかも。

・積和のパイプラインを持つCPUでピーク性能を出すためには、 　独立な積和演算がたくさん必要

・Intel系は、積と和は別のパイプライン 　・A1 = B1 + C1, A2 = B2 + C2 　・A3 = B3 * C3 , A4 = B4 * C4

アセンブリを読みましょう 変にプロファイラと格闘するより直接的です

University of Tokyo

29/68

How to use Profiler プロファイラの使い方とか

University of Tokyo

30/68

Sampler What is Profiler? (Sampler)

実行中、一定間隔で「いまどこを実行中か」を調べ、実行時間は その出現回数に比例すると仮定する

Subroutine A

pop

push A

プロファイルオプションつきでコンパイルすると ルーチンの最初と最後にコードを追加する

Subroutine A

Subroutine A Subroutine B Subroutine B Call C

Subroutine C

Subroutine B Subroutine D

A B B C

B D

実行中のルーチン

呼び出しスタック

定期的(例えば1ミリ秒に一度)に いま何が実行中かをカウント

主にHot Spotを探すのに使う

University of Tokyo

31/68 gprof

gprofとは 広く使われるプロファイラ(sampler) Macでは使えないので GUIプロファイラ「Shark」を使う (Lionには無いそうです・・・)

$ gcc -pg test.cc $ ./a.out $ ls a.out gmon.out test.cc $ gprof a.out gmon.out

Flat profile:

Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 100.57 0.93 0.93 1 925.26 925.26 matmat() 0.00 0.93 0.00 1 0.00 0.00 global constructors keyed to A 0.00 0.93 0.00 1 0.00 0.00 __static_initialization_and_destruction_0(int, int) 0.00 0.93 0.00 1 0.00 0.00 init() 0.00 0.93 0.00 1 0.00 0.00 matvec() 0.00 0.93 0.00 1 0.00 0.00 vecvec()

使い方

出力 とりあえず%(割合)だけ見ればいいです

サンプリングレートも少しだけ気にすると吉

University of Tokyo

32/68 Profile結果の解釈 (Sampler)

一部のルーチンが80%以上の計算時間を占めている 　→そのルーチンがホットスポットなので、高速化を試みる

多数のルーチンが計算時間をほぼ均等に使っている 　→最適化をあきらめる

世の中あきらめも肝心です

あきらめたらそこで試合終了じゃないんですか？

University of Tokyo

33/68 What is Profiler? (HW Counter)

HW Counter Hardware Counter CPUがイベントをカウントする機能を持っている時に使える イベントとは？

・整数演算 ・浮動小数点演算 ・キャッシュミス ・バリア待ち ・演算待ち

HW Counterの使い方 システム依存 カウントするイベントの種類を指定。 プログラムの再コンパイルは不必要 カウンタにより取れるイベントが決まっている 　→同じカウンタに割り当てられたイベントが知りたい場合、複数回実行する必要がある

←こっちに気を取られがちだが

←個人的にはこっちが重要だと思う

University of Tokyo

34/68 Profile結果の解釈 (HW Counter)

バリア同期待ち OpenMPのスレッド間のロードインバランスが原因 自動並列化を使ったりするとよく発生 対処：自分でOpenMPを使ってちゃんと考えて書く(それができれば苦労はしないが)

キャッシュ待ち

浮動小数点キャッシュ待ち 対処：メモリ配置の最適化 (連続アクセス、パディング・・・) ただし、本質的に演算が軽い時には対処が難しい

演算待ち

浮動小数点演算待ち A=B+C D=A*E ←この演算は、前の演算が終わらないと実行できない 対処：アルゴリズムの見直し (それができれば略)

SIMD化率が低い 対処できる場合もあるが、あきらめた方がはやいと思う それでも対処したい人へ： ループカウンタ間の依存関係を減らしてsoftware pipeliningを促進

University of Tokyo

35/68

Memory Management

University of Tokyo

36/68 仮想メモリとページング (1/2)

Virtual Memory 現在の一般的なOSでは、メモリをページと呼ばれる仮想記憶で管理する。

仮想メモリを使う理由 ・不連続なメモリ空間を論理的には連続に見せることができる 　仮想メモリなしでは、メモリに余裕があっても連続領域が取れない場合　　 　　にメモリ割り当てができないことがある ・スワッピングが可能になる 　記憶容量としてハードディスクも使えるため、物理メモリより広い論理 　メモリ空間が取れる。

ハードディスク 仮想メモリ (論理メモリ)

物理メモリ

物理メモリ内では不連続に割り当てられているかもしれない

一部がハードディスクにスワップされているかもしれない

論理メモリでは連続に見えても・・・

University of Tokyo

37/68 仮想メモリとページング (2/2)

数値計算で何が問題になるか？ F90のallocateや、Cでnew、mallocされた時点では物理メモリの 割り当てがされていない場合がある

real*8, allocatable :: work(:) allocate (work(10000)) do i=1, 10000 work(i) = i end do

この時点では予約だけされて、まだ物理アドレスが割り当てられない

はじめて触った時点で、メモリがページ単位で割り当てられる (First touch の原則)

よくある問題： 最初に馬鹿でかい配列を動的に確保しているプログラムの初期化がすごく遅い 　・地球シミュレータからT2Kへの移植とかで問題になることが多い。 　・OSがLinuxである京でも発生する可能性がある

解決策： 　・メモリを静的に確保する(?) 　・mallocではなくcallocを使う (Fortranではどうやるのか知りません) 　・メモリを確保した直後、ページ単位で全体を触っておく

まぁ、そういうこともあると覚えておいてください

University of Tokyo

38/68 NUMA (1/2)

NUMAとは 非対称メモリアクセス(Non-Uniform Memory Access)の略 CPUにつながっている物理メモリに近いメモリと遠いメモリの区別がある 京コンピュータはNUMAではないが、物性研System BはNUMA

CPU CPU QPI

Memory

Memory

Memory

Memory

Memory

Memory

Fast access

Slow access 特にlatency

University of Tokyo

39/68

数値計算で何が問題になるか？

NUMA (2/2)

OpenMPでCPUをまたぐ並列化をする際、初期化を適当にやると 作業領域がコアから遠い物理メモリに割り当てられてしまう

QPI

CORE CORE

CORE CORE

CORE CORE

CORE CORE

OpenMPのスレッドを作る前に配列を初期化 　→root プロセスの近くにメモリ割り当て その後OpenMPでスレッド並列 　→遠いメモリをアクセス(遅い)

Touch

解決策： 　スレッドに対応する物理コアに近いところにメモリが割り当てられるように、スレッドごとに配列を用意した上、OpenMPでスレッド並列化した後にtouchとか

詳しくはNUMA最適化でググれ

University of Tokyo

40/68 Byte / Flop

Byte/Flop

Ratio of memory bandwidth (Byte/s) to computational power (FLOPS)

Meaning of B/F

One double precision variable is 64bit, 8 Byte We need at least two variables to calculate something = 16 Byte We have to store at least one result = 8 Byte. We need at least 24 Byte load/store for one calculation.

B/F = 0.5 means that CPU can calculate 48 times during 24 Byte transfer.

If you fetch two double precision variables, you have to calculate at least 48 times, or CPU will be idle.

Usually B/F = 0.1～0.5

Reuse of the fetched data is necessary.

University of Tokyo

41/68

Mesh Information どの空間に粒子が存在するかを多次元配列で実装すると効率が悪い int GridParticleNumber[GridX][GridY]; int GridParticleIndex[GridX][GridY][GridMax];

Implement by one-dimensional array

Memory Efficiency (1/2)

O(N) Partial Sort Cache Efficiency Latency

University of Tokyo

42/68

Pair Information Since interaction is short-range, we have to construct pair list, whish is a list of interacting particle-pairs.

Sorting with particle number

fetch/ store data of one particle per pair Data of key-particles are on register.

Simple Implementation causes, random access in memory fetch/store data of two particles per pair

Memory Efficiency (2/2)

University of Tokyo

43/68

Spatial Sorting

Cache Effieicency (1/2)

University of Tokyo

44/68

Efficiency of Spatial Sorting

L2 Cache (256 KB)

L3 Cache (8 MB)

Cache Effieicency (2/2)

University of Tokyo

45/68 Summary of Memory Management

・CPUチューニングの前にメモリアクセスのチェックを ・とにかくキャッシュにのせる ・メモリアクセスの最適化は、ある種のソートになっていることが多い 　(特にPartial Sortは有効であることが多い) ・メモリアクセスの最適化は、計算機を選ばないことが多い 　（CPUチューニングはアーキテクチャに強く依存する） 並列化の前にメモリアクセスの最適化をする ・メモリアクセスの最適化をすると、データの持ち方が変わる 　→並列化の通信ルーチンが強く影響を受ける 　　 (まぁ、ちゃんと作るならどうせ何度も組み直すことにはなると思う) ・逆にNUMA最適化など、並列化をにらんだデータ構造を持つ必要もある 　→要するになんども組み直す必要があるということ

必要なデータがほぼキャッシュに載っており、CPUの 計算待ちがほとんどになって初めてCPUチューニングへ

University of Tokyo

46/68

CPU Tuning

といっても一般的にやれることはあんまりない

University of Tokyo

47/68 Cost of Conditional Branch (1/3)

L×L×L three-dimensional system. Free boundary condition Calculate force between all particle-pairs. N=20000 (all particles on cache) (1)  Without cutoff (2)  With cutoff (continue) (3)  With cutoff (fsel)

Condition

Test code contain only force-calculation (hot-spot). Effect of conditional branch due to the cutoff.

Benchmark Test

CPU Architecture

Intel Xeon (2.93GHz) IBM POWER6 (3.5GHz)

University of Tokyo

48/68

void calcforce(void){ for(int i=0;i<N-1;i++){ for(int j=i+1;j<N;j++){ const double dx = q[j][X] - q[i][X]; const double dy = q[j][Y] - q[i][Y]; const double dz = q[j][Z] - q[i][Z]; const double r2 = (dx*dx + dy*dy + dz*dz); const double r6 = r2*r2*r2; double df = (24.0*r6-48.0)/(r6*r6*r2)*dt; p[i][X] += df*dx; p[i][Y] += df*dy; p[i][Z] += df*dz; p[j][X] -= df*dx; p[j][Y] -= df*dy; p[j][Z] -= df*dz; } } }

void calcforce(void){ for(int i=0;i<N-1;i++){ for(int j=i+1;j<N;j++){ const double dx = q[j][X] - q[i][X]; const double dy = q[j][Y] - q[i][Y]; const double dz = q[j][Z] - q[i][Z]; const double r2 = (dx*dx + dy*dy + dz*dz); if (r2 > CUTOFF) continue; const double r6 = r2*r2*r2; double df = (24.0*r6-48.0)/(r6*r6*r2)*dt; p[i][X] += df*dx; p[i][Y] += df*dy; p[i][Z] += df*dz; p[j][X] -= df*dx; p[j][Y] -= df*dy; p[j][Z] -= df*dz; } } }

Without Branch With Branch

Cost of Conditional Branch (2/3)

University of Tokyo

49/68

Elapsed Time [SEC]

While POWER is faster than Xeon without branch, it becomes twice slower by twice than Xeon with branch.

Conditional branch is quite expensive for IBM POWER, since it is in-order execution. Intel Xeon has branch predictor and it allows us to execute out-of-order.

Cost of Conditional Branch (3/3)

University of Tokyo

50/68

Conditional Branch Elimination

1.  foreach interacting particles 2.  r ← particle distance 3.  if distance > cutoff length then continue 4.  f ← calculate force 5.  p ← update momenta 6.  next

Very expensive for RISC

1.  foreach interacting particles 2.  r ← particle distance 3.  f ← calculate force 4.  if distance > cutoff length then f ←0 5.  p ← update momenta 6.  next

fsel in assembler instruction

Efficient if the cost of the conditional jump is more expensive than the additional cost for force calculation.

Conditional Branch Elimination (1/2)

University of Tokyo

51/68

Elapsed Time [SEC]

IBM Power becomes faster than Xeon using “fsel” built-in function.

if (r2>CUTOFF) continue; df = __fsel(r2-CUTOFF,0.0, df);

You have to include “builtins.h”

fsel fp0,fp1,fp2,fp3 fp0 = (fp1 > 0)? fp2: fp3;

Conditional Branch Elimination (2/2)

University of Tokyo

52/68

Division Elimination 1.  foreach interacting particles 2.  r2 ← the square of the distance 3.  r6 ← r2*r2*r2 4.  r14← r6*r6*2 5.  f ← (24.0*r6-48.0)/r14 6.  update momenta 7.  next

Division

A1 = 1/B1 A2 = 1/B2

D = 1/(B1*B2) A1 =D*B2 A2 =D*B1

1.  foreach particles pairs A,B 2.  r14_a ← 14th power of distance of particle pair A 3.  r14_b ← 14th power of distance of particle pair B 4.  D = 1/(r14_a * r14_b) 5.  f_a ← (24.0*r6_a-48.0) *D*r14_b 6.  f_b ← (24.0*r6_b-48.0) *D*r14_a 7.  Update momenta 8.  next

Doubly Unrolled Div. -1 Mul. +3

割り算が「重い」石で有効

Other kinds of CPU Tuning (1/2)

University of Tokyo

53/68

Software Pipelining

Distance

Force

Update Momenta

Distance

Force

Update Momenta

Distance

Distance

Force

Update Momenta

Distance

Force

Update Momenta

Loop Counter

Distance

Force

Update Momenta

Force

Update Momenta

Distance

Force

Distance

・独立な計算を増やすのが目的 ・条件分岐が含まれるとかなり面倒 ・単純なループアンロールはレジスタ不足に陥り易い ・たまにコンパイラが自動でやってくれたりする(ループ方向のSIMD化)

Other kinds of CPU Tuning (2/2)

University of Tokyo

54/68 CPU Dependent Tuning Summary

CPU Tunings depend on CPU architecture.

We have to prepare the codes for architecture to architecture.

基本的には趣味の世界

世の中には全部intrinsic 命令でホットスポットを書く廃人もいるにはいる

University of Tokyo

55/68

Software Publication ソース公開のススメ

University of Tokyo

56/68 作ったプログラムをどうするか

ソフトウェア資産の一生

えらい先生が何かプロジェクトを提案して予算を獲得する その予算でPDを雇ってプログラムを開発する プロジェクト終了とともにプログラム開発ストップ そのまま誰にも使われずに朽ちて行く・・・

なぜそうなるのか？

プログラムは生き物であり、メンテしないと死んでしまう プログラムのメンテには開発者としての愛着が必要 予算ありきでプログラムを作ると基本的には同じ道を辿る

どうにかできないのか

予算を取ってプログラムを作るのではなく、開発されているプログラムを 予算によって支援する 開発段階からソースを公開する

University of Tokyo

57/68 なぜソースを公開するのか

ソース非公開ということ

ソースが非公開だと、そのプログラムはブラックボックスになる ブラックボックスのプログラムは 　・安定していなければならない 　　(不正な計算に対してAbortせず、誤った答えを出しても、ユーザはわからない) 　・マニュアルが整理されていなければならない 　・開発がとまった時がプログラムの死ぬ時

オープンソースソフトウェア

ソースを公開していれば・・・ ・ユーザが必要な時に自分で機能変更ができる ・質問があったら「ソース読め」と言える ・開発が止まっても、別の人が開発を引き継ぐ可能性がある ・そのプログラムの一部機能(特に最適化技術)が別のプログラムに 　取り込まれていくこともある

University of Tokyo

58/68 ソース公開の難しさ

えらい先生が反対する

せっかくの技術、ノウハウが流出する →　技術、ノウハウの流出は分野振興にとって望ましいことのはず　

そもそも「サイエンス第一」なんでしょ？

公開は恥ずかしい 自分のプログラムはつたないので、公開するのが恥ずかしい →公開して恥ずかしくないようなプログラムを組めるように努力する バグってたら恥ずかしい →バグってるプログラムで論文書いちゃダメです

公開するためには 最初からソースを公開すると宣言し、賛同する人だけでプロジェクトを開始する →最初なぁなぁにしておいて、複数人が関わったあとに公開するのは不可能

University of Tokyo

59/68 ソフトウェアの公開方法

公開場所 公開場所として大学のサーバはあまり良くない 　→開発者が異動することが多いから まして年限つきのプロジェクトのサーバに置くのはダメ 　→プロジェクト終了後、サーバも消えるかやっかいもの扱いされる運命だから

というわけで、公共のソースコードリポジトリがおすすめ SourceForge.net, SourceForge.jp, GitHub ... ソース公開するのがどうしてもイヤ、というならgoogle sitesとか・・・

上記の場所に公開して、プロジェクトや大学のサーバからリンクする

University of Tokyo

60/68 SorceForge.net の例

http://mdacp.sourceforge.net/ http://sourceforge.net/projects/mdacp/stats/traffic

プロジェクトのウェブページは好きなようにいじることができる ダウンロード統計も自動で取ってくれる

University of Tokyo

61/68 SorceForge.jp の例 http://qcad.sourceforge.jp/ http://sourceforge.jp/projects/qcad/devel

プロジェクトのウェブページは好きなようにいじることができる ダウンロード統計も自動で取ってくれる 個人的な意見としては、本家(SF.net)より日本版(SF.jp)の方が使い勝手が良い気がする

University of Tokyo

62/68 GitHubの例

https://github.com/kaityo256/flash/blob/master/sentos/Sentos.as https://github.com/kaityo256

gitでアクセスする 無料(有料オプションで、非公開リポジトリを作ることもできる) 簡易SNS的な機能もある(気になる人をTwitterみたいにフォローしたり)

ソースが色付きで表示されたりする

University of Tokyo

63/68 Summary of Software Publication

・アカデミアで開発されたプログラムは、ソースを公開しないと ほぼ死ぬと思う

・プロジェクトでソフトウェアを作るとだいたいうまくいかない。

・うまくいくのは「もともと作って公開するつもりだったソフトウェア」 をプロジェクトの形で支援、環境を整えること

・プロジェクトの支援とは？ 　・公開場所を提供することではない 　・マンパワーを提供することでもない 　・開発者がそのプログラムに集中することを仕事として認めること

University of Tokyo

64/68

Future of HPC HPCの将来

University of Tokyo

65/68

I don’t know.

そういうことはHPCのTop runnerに聞いてください。

University of Tokyo

66/68 今後どうなるの？ (1/2)

ペタスケール (10^15) エクサスケール (10^18)

コア コア コア コア

L2 L2 L2 L2 L3

CPU

Memory

Network

キャッシュ最適化

NUMA最適化

SIMD

OpenMP

MPI

コア

コア

コア

コア

コア

コア

コア

コア

コア

コア

L2 L2

L3

AC AC AC AC AC

Memory

Memory Memory

Network

メニーコア化

ヘテロ化

多階層キャッシュ

非一様通信

ただでさえ複雑なのに、より複雑に 一人の人間がプログラム組めるのか？

University of Tokyo

67/68

情報(システム)屋さんと数値計算屋さんのギャップ きれいなシステム vs. 使えるシステム

欲しいもの：まともなHPC言語、コンパイラ、システム、耐障害性、etc. 提案されるもの：馬鹿パラしか使えないシステム、障害時に縮退運転可能な 　　　　　　　　　　ジョブシステム、etc

今後どうなるの？ (2/2)

プログラムを組むコスト

プログラムを組むのが大変になる 　→分業制が不可避？ 　　すでにそういう分野がある。それでいいのか？それしかないのか？

CPUは国産であるべきか？ CPUを作るのをやめたらコンパイラは作れなくなる(?) コンパイラが作れない国には新しいHPC言語は作れない(?)

University of Tokyo

68/68 全体のまとめのようなもの

最適化、高速化、並列化は好きな人がやればいい

おしまい