1.
2008/9/13
パフォーマンスチューニングの
基礎の基礎
Cybozu Labs, Inc
ひげぽん
higepon@labs.cybozu.co.jp

2.
自己紹介
ひげぽん（蓑輪太郎）
Mosh
R6RS Scheme インタプリタ
http://code.google.com/p/mosh-scheme/
Mona
オープンソース OS
http://www.monaos.org
2

3.
Mona
3

4.
Mona
オープンソースOS
2002年∼
FD/CD起動
GUI
フルカラー
音
ネットワーク
3

5.
未踏ソフトウェアとの関わり
4

6.
未踏ソフトウェアとの関わり
Mona における次世代Schemeシェルの開発
2006年度下期 並木PM
Mona の「標準のシェル」にSchemeを採用
Scheme からプロセスを起動
ウィンドウを操作
4

7.
近況
5

8.
近況
サイボウズ・ラボ株式会社へ転職
ソフトウェアの開発・研究
5

9.
近況
サイボウズ・ラボ株式会社へ転職
ソフトウェアの開発・研究
R6RS Scheme インタプリタ Mosh 開発中
広範囲で使われる Scheme を目指して
いずれは Mona に移植したい
5

10.
近況
サイボウズ・ラボ株式会社へ転職
ソフトウェアの開発・研究
R6RS Scheme インタプリタ Mosh 開発中
広範囲で使われる Scheme を目指して
いずれは Mona に移植したい
5
あれ？自己紹介・近況だけだと
間が持たないぞ

11.
6
パフォーマンスチューニング
の基礎の基礎

12.
7
パフォーマンスチューニング
の問題

13.
こんな経験はありませんか？
8

14.
こんな経験はありませんか？
いくらチューニングしても速くならない
8

15.
こんな経験はありませんか？
いくらチューニングしても速くならない
チューニング中に森に迷い込んでしまった
8

16.
こんな経験はありませんか？
いくらチューニングしても速くならない
チューニング中に森に迷い込んでしまった
速くするには大幅に変更が必要
しかもそれで速くなるかは分からない
8

17.
こんな経験はありませんか？
いくらチューニングしても速くならない
チューニング中に森に迷い込んでしまった
速くするには大幅に変更が必要
しかもそれで速くなるかは分からない
勘でチューニングしたら
速くなった→ Great
速くならない、遅くなった→ orz...
8

18.
問題点
9

19.
問題点
方法論がいまいち浸透していない
9

20.
問題点
方法論がいまいち浸透していない
コーディング・設計は良い例がたくさん
9

21.
問題点
方法論がいまいち浸透していない
コーディング・設計は良い例がたくさん
チューニングは？
まだまだ少ない
9

22.
問題点
方法論がいまいち浸透していない
コーディング・設計は良い例がたくさん
チューニングは？
まだまだ少ない
経験の豊富なプログラマでも
チューニング方法は自己流が多い
9

23.
今日の発表
10

24.
今日の発表
パフォーマンスチューニングの基礎の基礎
10

25.
今日の発表
パフォーマンスチューニングの基礎の基礎
Mosh の開発での苦労した経験を元に
速いソフトウェアを作りたい人を対象に
言語にできるだけ依存しないテクニックを紹介
一部 Mosh 固有のトピック
10

26.
11
パフォーマンスチューニングで
やってはいけないこと

27.
その1
12

28.
その1
パフォーマンスは後回し
リリース直前にパフォーマンスチューニングすれ
ばOK?
12

29.
その1
パフォーマンスは後回し
リリース直前にパフォーマンスチューニングすれ
ばOK?
最悪の場合どうにもならなくなる
12

30.
その1
パフォーマンスは後回し
リリース直前にパフォーマンスチューニングすれ
ばOK?
最悪の場合どうにもならなくなる
最初に作った Scheme は遅かった 12

31.
その2
13

32.
その2
自戒の念も込めて
13

33.
その2
自戒の念も込めて
ここがいかにも遅そうだから
memcached にキャッシュしよう
インライン展開しよう
インラインアセンブラにしよう
13

34.
その2
自戒の念も込めて
ここがいかにも遅そうだから
memcached にキャッシュしよう
インライン展開しよう
インラインアセンブラにしよう
誰でも経験があるはず
13

35.
その2
自戒の念も込めて
ここがいかにも遅そうだから
memcached にキャッシュしよう
インライン展開しよう
インラインアセンブラにしよう
誰でも経験があるはず
これはなぜだめか？
13

36.
その2
自戒の念も込めて
ここがいかにも遅そうだから
memcached にキャッシュしよう
インライン展開しよう
インラインアセンブラにしよう
14

37.
その2
自戒の念も込めて
ここがいかにも遅そうだから
memcached にキャッシュしよう
インライン展開しよう
インラインアセンブラにしよう
14
計測していない！

38.
その2
15

39.
その2
計測せよ
直感はまちがいかも
その関数一度も呼ばれないかも
遅いがユーザー応答時間への影響は少ないかも
15

40.
その2
計測せよ
直感はまちがいかも
その関数一度も呼ばれないかも
遅いがユーザー応答時間への影響は少ないかも
小さなパフォーマンス事項で壊してはだめ
良いデザイン
機能性
柔軟性 15

41.
16
良いデザイン？
機能性？
柔軟性？

42.
良いデザイン？機能性？柔軟性？
17

43.
良いデザイン？機能性？柔軟性？
memcached にキャッシュしたとする
キャッシュ ON/OFF の2通りでテスト
キャッシュの Expire の境界チェック
memcached 環境の構築
コードが増える
17

44.
良いデザイン？機能性？柔軟性？
memcached にキャッシュしたとする
キャッシュ ON/OFF の2通りでテスト
キャッシュの Expire の境界チェック
memcached 環境の構築
コードが増える
コードの本来の目的がぼんやりする
17

45.
良いデザイン？機能性？柔軟性？
memcached にキャッシュしたとする
キャッシュ ON/OFF の2通りでテスト
キャッシュの Expire の境界チェック
memcached 環境の構築
コードが増える
コードの本来の目的がぼんやりする
開発、テスト、改修時に気にする必要
17

46.
Memcached の使用例
18
use Cache::Memcached;
$memd = new Cache::Memcached {
'servers' => [ "10.0.0.15:11211", "10.0.0.15:11212", "/var/sock/memcached",
"10.0.0.17:11211", [ "10.0.0.17:11211", 3 ] ],
'debug' => 0,
'compress_threshold' => 10_000,
};
$memd->set_servers($array_ref);
$memd->set_compress_threshold(10_000);
$memd->enable_compress(0);
$memd->set("my_key", "Some value");
$memd->set("object_key", { 'complex' => [ "object", 2, 4 ]});
$val = $memd->get("my_key");

47.
良いデザイン？機能性？柔軟性？
19

48.
良いデザイン？機能性？柔軟性？
inline にしたとする
19

49.
良いデザイン？機能性？柔軟性？
inline にしたとする
実装をヘッダに書くor マクロ
build dependencies
平均 build 時間が増える
インターフェースが読みづらくなる
19

50.
良いデザイン？機能性？柔軟性？
inline にしたとする
実装をヘッダに書くor マクロ
build dependencies
平均 build 時間が増える
インターフェースが読みづらくなる
賛否両論ありそう
19

51.
良いデザイン？機能性？柔軟性？
20

52.
良いデザイン？機能性？柔軟性？
インラインアセンブラ
20
uint32_t l,h;
asm volatile("rdtsc n"
"mov %%eax, %0 n"
"mov %%edx, %1 n"
: "=m"(l), "=m"(h)
: /* no */
: "eax", "edx");
*timeL = l;
*timeH = h;

53.
というわけで
21

54.
というわけで
測定せず直感だけで
良いデザインを壊すのは NG
21

55.
というわけで
測定せず直感だけで
良いデザインを壊すのは NG
でも誤解しないでほしい
挙げられたテクニックは有効な場所もある
トレードオフがあるだけ
21

56.
大事なこと
22
パフォーマンスチューニングには
コスト・リスク
があることを理解しよう

57.
23
これらをふまえて
どうすれば良いか？

58.
チューニングを開発プロセス
24

59.
チューニングを開発プロセス
開発の最初から
チューニングを開発プロセスに取り込む
24

60.
チューニングを開発プロセス
開発の最初から
チューニングを開発プロセスに取り込む
最初にゴール・目標を決める
24

61.
チューニングを開発プロセス
開発の最初から
チューニングを開発プロセスに取り込む
最初にゴール・目標を決める
短いサイクルをまわそう
開発
測定
チューニング
24

62.
0. 最初にゴール・目標を決める
25

63.
0. 最初にゴール・目標を決める
例
500 msec 以内にレスポンスを返す
25

64.
0. 最初にゴール・目標を決める
例
500 msec 以内にレスポンスを返す
ゴール・目標がないと
今十分速いのか？が分からない
後どれくらい速くなればいいか分からない
25

65.
0. 最初にゴール・目標を決める
例
500 msec 以内にレスポンスを返す
ゴール・目標がないと
今十分速いのか？が分からない
後どれくらい速くなればいいか分からない
作る前から正確な目標は立てられないよ？
良い指摘
25

66.
1. 開発
26

67.
1. 開発
パフォーマンスのことは考えない
26

68.
1. 開発
パフォーマンスのことは考えない
良いデザイン・良いコードに集中
パフォーマンスを気にする時間はすぐ後にある
26

69.
1. 開発
パフォーマンスのことは考えない
良いデザイン・良いコードに集中
パフォーマンスを気にする時間はすぐ後にある
でも「ウズウズするんだ」
「良い高速化手法思いついた」
「もしかしたら遅いかも」
コメントにメモしておく
26

70.
2. 計測
27

71.
2. 計測
目標に到達しているか？計測する
27

72.
2. 計測
目標に到達しているか？計測する
短いサイクルで計測する
27

73.
2. 計測
目標に到達しているか？計測する
短いサイクルで計測する
遅くなったら一つ前の開発が悪い
一つ前なのでコードを良く覚えている
あとからチューニングするよりもやりやすい
27

74.
2. 計測
目標に到達しているか？計測する
短いサイクルで計測する
遅くなったら一つ前の開発が悪い
一つ前なのでコードを良く覚えている
あとからチューニングするよりもやりやすい
簡単に計測できる仕組みづくりが大切
27

75.
3. チューニング
28

76.
3. チューニング
目標を満たしていなければ
初めてチューニングに取りかかる
メモが役に立つかも？
28

77.
まとめると
29

78.
まとめると
短いサイクルをまわそう
開発
良いデザイン・良いコードに集中
パフォーマンスのことは考えない
測定
ゴール・目標満たしている？
チューニング
29

79.
まとめると
短いサイクルをまわそう
開発
良いデザイン・良いコードに集中
パフォーマンスのことは考えない
測定
ゴール・目標満たしている？
チューニング
速いコードをサイクルごとに維持する
29

80.
30
測定・チューニングの
テクニック

81.
31
測定

82.
環境構築
32

83.
環境構築
初期の環境構築で効率が変わる
32

84.
環境構築
初期の環境構築で効率が変わる
測定するデータの準備
より本番に近い形で
32

85.
環境構築
初期の環境構築で効率が変わる
測定するデータの準備
より本番に近い形で
測定は楽をしよう
気軽に測定できるように
測定が楽しくなるように
半自動化
make bench など 32

86.
記録と参照
33

87.
記録と参照
目標 1sec
33

88.
記録と参照
目標 1sec
33
チューニング項目 sec
A 12.29
B 10.05
C 9.55
D 9.53
E 7.57
F 5.98
G 4.4
H 4.3

89.
記録と参照
目標 1sec
33
チューニング項目 sec
A 12.29
B 10.05
C 9.55
D 9.53
E 7.57
F 5.98
G 4.4
H 4.3
過去のデータを保持
レポジトリに入れる

90.
グラフで一目瞭然
34
グラフを描く

91.
グラフで一目瞭然
34
0
2.5
5.0
7.5
10.0
12.5
15.0
チューニング
グラフを描く

92.
35
チューニング

93.
遅いところはどこか？ の道具
36

94.
遅いところはどこか？ の道具
プロファイラ
gcc なら gprof
36

95.
遅いところはどこか？ の道具
プロファイラ
gcc なら gprof
プロファイラがない場合は？
ストップウォッチ
ログ方式
プロファイラ実装
36

96.
遅いところはどこか？ の道具
プロファイラ
gcc なら gprof
プロファイラがない場合は？
ストップウォッチ
ログ方式
プロファイラ実装
道具の選定・準備に時間をかけるべし
36

97.
37
VM（Mosh）開発固有の話

98.
VM 固有の話
38

99.
VM 固有の話
VM では普通のプロファイラが使えない
関数単位のプロファイラ gprof
実行時間の大半が run ループ
runループのどこが遅いか分からない
38

100.
VM 固有の話
VM では普通のプロファイラが使えない
関数単位のプロファイラ gprof
実行時間の大半が run ループ
runループのどこが遅いか分からない
38
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
58.33 0.98 0.98 86 11.40 14.55 scheme::VM::run

101.
runループ
39
void run()
{
for (;;) {
switch(instruction) {
case CALL:
/* 何か */
case XXX:
/* 何か */
case YYY:
/* 何か */
}
... たくさん続く
}
}
どの命令が遅いか
分からない

102.
qprof
40

103.
qprof
qprof はどのアドレスが遅いかが分かる
命令（ラベル）のアドレスとマッチング可能
40

104.
qprof
qprof はどのアドレスが遅いかが分かる
命令（ラベル）のアドレスとマッチング可能
40
qprof -ginstruction -i 1 -o qprof.log ./mosh
scheme::VM::run(scheme::Object) [0x8051c8b] 12 ( 4%)
scheme::VM::run(scheme::Object) [0x8051c92] 2 ( 1%)
scheme::VM::run(scheme::Object) [0x8051d84] 3 ( 1%)
scheme::VM::run(scheme::Object) [0x8051d90] 1 ( 0%)
scheme::VM::run(scheme::Object) [0x8051da4] 1 ( 0%)

105.
VM固有の話
41

106.
VM固有の話
プロファイラではC++の世界しか見えない
例えば Mosh なら Scheme の世界を見たい
どの Scheme 手続きが遅いのか？
何回呼ばれているのか
41

107.
VM固有の話
プロファイラではC++の世界しか見えない
例えば Mosh なら Scheme の世界を見たい
どの Scheme 手続きが遅いのか？
何回呼ばれているのか
自前でプロファイラを作ろう
意外と簡単
41

108.
プロファイラを作ろう
42

109.
プロファイラを作ろう
プロファイラのやること
一定の間隔で実行を割り込み
そのときの「何をしていたか？」を記録
call された関数と回数を記録
42

110.
プロファイラを作ろう
プロファイラのやること
一定の間隔で実行を割り込み
そのときの「何をしていたか？」を記録
call された関数と回数を記録
SIGPROFを利用する
プロファイラ用のシグナル
シグナルハンドラで
「プログラムカウンタ」を記録
42

111.
実装
43
struct sigaction act;
act.sa_handler = &signal_handler;
act.sa_flags = SA_RESTART;
if (sigaction(SIGPROF, &act, NULL) != 0) {
callAssertionViolationImmidiaImmediately("profiler",
"sigaction failed");
} テキスト
startTimer();
void VM::collectProfile()
{
static int i = 0;
if (!profilerRunning_) return;
if (i >= SAMPLE_NUM) {
stopTimer();
} else {
samples_[i++] = cl_;
}
totalSampleCount_++;
}
シグナルとタイマの設定
シグナルハンドラ

112.
Mosh のプロファイラ
44
time% msec calls name location
27 3510 190 (lambda x y) compiler.scm:8458
8 1140 143356 (lambda i) compiler.scm:9644
8 1110 4039 (pass3/$lambda iform loca...) compiler.scm:9213
7 990 - (<top-level>)
5 650 8456 (pass3/$call iform locals...) compiler.scm:9064
3 500 197791 (lambda s) compiler.scm:9682
2 290 811697 (set-intersect lst1 lst2) compiler.scm:5270
1 220 198 (lambda lst1 lst2) compiler.scm:5249
1 200 2 (lambda x y) compiler.scm:8449
1 190 38872 (lambda i l labels-seen) compiler.scm:8318
1 180 1 (lambda i code) compiler.scm:9072
1 170 42257 (pass1/sexp->iform sexp l...) compiler.scm:7074
1 160 1 (lambda i code) compiler.scm:9072
1 150 197 (lambda x lst) compiler.scm:5246
1 140 215 (lambda i) compiler.scm:8401
1 130 2788 (pass3/$if iform locals f...) compiler.scm:8921
1 130 192 (lambda x lst) compiler.scm:5246

113.
まとめ
45

114.
まとめ
最初にゴールを決めろ
45

115.
まとめ
最初にゴールを決めろ
良いデザインを壊すな・測定せよ
45

116.
まとめ
最初にゴールを決めろ
良いデザインを壊すな・測定せよ
グラフを描け
45

117.
まとめ
最初にゴールを決めろ
良いデザインを壊すな・測定せよ
グラフを描け
開発プロセスに含めよ
開発
測定
チューニング
45

118.
宣伝
46

119.
宣伝
Shibuya.lisp
Lisp系言語のコミュニティを立ち上げました
10月18日に Tech talk #1 を開催予定
http://shibuya.lisp-users.org/
46