The basic of performance tuning by Higepon at Esper 2008 in Japan

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