静的型付き言語用Just-In-Timeコンパイラの再利用による、動的型付き言語用コンパイラの実装と最適化

IBM Research

静的型付き言語用Just-In-Timeコンパイラの再利用に
よる、動的型付き言語用コンパイラの実装と最適化
Jose Castanos *, David Edelsohn *, Kazuaki Ishizaki +,
Priya Nagpurkar *, Toshio Nakatani +, Takeshi Ogasawara +,
Peng Wu *
+IBM

Research – Tokyo
*IBM T.J. Watson Research Center

kiszk@acm.org
© 2013 IBM Corporation

静的型付け言語用Just-In-Timeコンパイラの再利用に
よる、動的型付き言語用コンパイラの実装と最適化

2

2013/12/04 東京工業大学数理・計算化学専攻専攻談話会


研究の動機とゴール

すでに存在するJust-In-Time(JIT)コンパイラを再利用
して、動的型付き言語の性能を向上させたい
 様々な動的型付け言語（以降、スクリプト言語）が普及
► Perl,

PHP, Python, Ruby, JavaScript…

► 小規模なプログラムに加え、大規模な商用システムでも利用されている

 静的型付き言語（Javaなど）に比べ、性能が低い
► インタプリタ同士の比較で、Python, PHP,
[Computer Language Benchmarks Game 2009]

► さらにJavaには、IBM

RubyはJavaに比べ、2～6倍遅い

Java等JITコンパイラを持つ高性能な処理系がある

 それぞれのスクリプト言語のために、一からJITコンパイラを作る
のは大変
► 静的型付き言語用のコンパイラであれば、

Java JIT compiler, LLVMなど、高性能

なものが存在する

→ 既に存在するJITコンパイラを再利用して、スクリプト言語用の
高性能なJITコンパイラを作ることは出来ないか？
3



選択肢

どのような処理系を選ぶか？
 対象言語は？
► Perl,

PHP, Python, Ruby, JavaScript… といっぱいありますが
今回は（２０１０年当時）、最初の対象としてPythonを選びました

 対象処理系は？
► CPython,

PyPy, Jython, IronPython, Stacklessといくつかありますが

[http://docs.python.org/devguide/#other-interpreter-implementations]

► 事実上の標準であり、連携する周辺ソフトウェアの多さを考え、CPython

– 外部インタフェース(Foreign Function Interface)は維持する

 対象コンパイラは？
► IBM

4

Java Just-In-Time compiler （Testarossa）



関連研究

スクリプト言語の高速化
 言語仮想機械(Virtual machine: VM、インタプリタ)を一から作る
► 高性能が期待できる
► 実装の手間が大きい
– コンパイラも一から作る [chrome, firefox, pypy ]
– コンパイラはLLVMを再利用 [Rubinius]

 VMを再利用
► どれだけの性能を出すことができるか？
► 実装の手間は少ない
► スクリプト言語用VMを再利用
– コンパイラはLLVMを再利用、VMはCPythonを再利用 [Unladen-Swallow]

• 我々のアプローチとほぼ同じ（使ったコンパイラが違う）
► 既存のVMの上に、スクリプト言語用VMを構築
– コンパイラはCommon Intermediate Language (CIL)用のJITコンパイラを作り、VMはCIL

で記述 [Spur: Bebenitaら, 2010]
– コンパイラはOpenJDKを再利用、VMはJava言語で記述 [Graal: Wimmerら, 2012]
5



我々の処理系の全体像

既存のソフトウェアに追加したもの
 VMに追加
 実行時の型情報などを取得す
るプロファイラ
 メソッドが、ある程度の回数
インタプリタで実行されたら、
コンパイラを起動する機構
 JITコンパイラに追加したもの
 Pythonバイトコード変換
 スクリプト言語向け最適化

Python
プログラム

VM
CPython
プロファイラ

頻繁に実行されたメソッドの
Pythonバイトコード

実行時情報

Pythonバイトコードから
コンパイラ中間表現に変換
中間表現

スクリプト言語向け
中間表現最適化
中間表現最適化

新しいコンポーネント
再利用したコンポーネント

実行コード生成

JITコンパイラ

実行コード

実行コード
キャッシュ
6



本日の話の流れ

 なるべく短い開発時間で、既存のJITコンパイラをスクリプト言語用に対応させる
► Pythonの１演算毎に、変数の型に関する演算の特殊化(specialization)を適用

[VEE2012]
► それでも細かいところは大変だった
– 言語毎のsemanticsの違いの吸収（特に例外とreflectionへの対応）

 性能が今ひとつなので、更に最適化を行う
► メソッド全体を対象として、変数の型に関する演算の特殊化、変数のボックス化解除

(unboxing)、を適用 [OOPSLA2012]
► 実装は楽ではないところもあった
– 論文にはならないような部分も実装する必要がある（メソッド途中で、最適化されたコンパ

ルされたコードから、インタプリタに実行を移す）

 プロジェクトの振り返り
► コンパイラを違う言語に再利用する際に考慮すること

[OOPSLA2012]

► 大変だったり楽ではなかったけど、新しい処理系の研究・動くものを作る・論文を書く

、のは面白いし楽しい
7





[VEE2012]





[OOPSLA2012]


8



コンパイラの視点からやりたかったこと

静的型付き言語とスクリプト言語の生成コードの複雑さの違い
静的型付き言語
int a, b, c
S1: b = 1
S2: c = a + b

9

スクリプト言語
S1: b = 1
S2: c = a + b






int a, b, c
S1: b = 1
S2: c = a + b

S1: b = 1
S2: c = a + b

1

‣ 変数aとbが持つオブジェクトの型を調べる
‣ 変数aとbが持つオブジェクトから値を取り出す
‣ 変数aとbが持つオブジェクトの型から+の操作を決める
‣ 決められた操作に従って、+の演算を行う
‣ 演算結果をオブジェクトに格納し、変数cに格納する

add r3 <- r2 + 1

機械語なら１命令
10






int a, b, c
S1: b = 1
S2: c = a + b

S1: b = 1
S2: c = a + b

1


object
type: INT
ival: 2013
object
type: INT
ival: 1

‣ 変数aとbが持つオブジェクトの型を調べる (1)
‣ 変数aとbが持つオブジェクトから値を取り出す (2)
‣ 変数aとbが持つオブジェクトの型から+の操作を決める (3)
‣ 決められた操作に従って、+の演算を行う (4)
‣ 演算結果をオブジェクトに格納し、変数iに格納する (5)
b = Int(1)
c = add(a, b)
...

11

add(a, b) {
...
add r3 <- r2 + 1
if (a.type == Int &&
b.type == Int) {
// (1)
int t1 = a.ival, t2 = b.ival // (2)
int i = t1 + t2;
// (3, 4)
return Int(i)
// (5)
else if (a.type ...
機械語なら１命令
...
機械語なら百命令ぐらい？
}


スクリプト言語で、高速化を少し頑張ってみると
バイトコード
CONST
STORE
LOAD
LOAD
ADD
STORE

1 int
b
a
b

S1: b = 1
S2: c = a + b

c

b = Int(1)
c = add(a, b)
...
add(a, b) {
...
b.type == Int) {
int i = a.ival + b.ival;
return Int(i)
else
...
}
12

b = Int(1)
if (a.type == Int && b.type == Int) {
c = Int(i)
} else {
c = add(a, b);
}
機械語なら数十命令？
// cはオブジェクト

add用に、aとbの型を調べた結果に基づいて
+の演算を特殊化したコードを実行するか決定する




スクリプト言語で、高速化をさらに頑張ってみる
S1: b = 1
S2: c = a + b

b = Int(1)
c = add(a, b)
...
add(a, b) {
...
b.type == Int) {
return Int(i)
else
...
}
13


guardによる特殊化
if (a->type == Int) {
c = a.val + 1;
} else {
goto interpreter
}
機械語なら数命令？
// cは単純変数
メソッド全体を見て、+の演算と
変数に関する操作を特殊化する
- bが整数と分かるなら検査を省略
- cが整数として使われるなら単純変数
b = Int(1)
c = Int(i)
} else {
c = add(a, b);
}
機械語なら数十命令？
// cはオブジェクト

versioningによる特殊化



生成されるコードの違いは、かなり少なくなった


int a, b
b = 1
S1: int c = a + b

S1: b = 1
S2: c = a + b


機械語で
１命令 vs. ５命令

type: INT
ival: 2013
object
type: INT
ival: 1


add r3 <- r1 + 1

14

object

// r10はaの持つオブジェクトのアドレス
load r0 <- type(r10)
cmp r0, Int
jne interpreter
load r0 <- ival(r10)
add r3 <- r0 + 1

最初の問題点

スクリプト言語の性能上の問題点の原因
しかし、プログラミングの柔軟性を高めている理由でもある
すべての変数に、任意の型を動的に型付けが可能
► CPU上では、型の判別を行ってから、型ごとに処理が必要

ほとんどの文が、例外を発生する可能性あり（型が合わないとか）
► 例外が発生したかどうか、検査が必要

インスタンス変数に、実行時にフィールドやメソッド（シンボル）を足
したり、削除したり、変えたり、できる
► アクセス時のオーバーヘッドが、変更できない言語に比べ大きくなる

オブジェクトの型や、クラス階層を実行時に変更可能
► 変更できない言語に比べ、実行時のオーバーヘッドが大きくなる

– でもこんなコード、テストコード以外には見ませんでしたが、framework用？

15



貢献

VEEの論文での我々の貢献
スクリプト言語の性能上の問題点を緩和する最適化を実装
► コンパイル時の最適化

– 例外検査の増加によるコンパイラ中間表現複雑化の抑制
► 実行時の最適化

– 型検査による、各演算の単純化
– シンボル・メソッドへのアクセスのオーバーヘッドを減少
– クラス階層検査のオーバーヘッドを減少

それぞれの最適化の効果を測定
► ベンチマークプログラムで、CPythonに比べて、平均で1.76倍高速になりま

した
– Javaの時よりは、速度向上率が低い

16



最適化の例

適用した最適化一覧
最適化

オーバヘッドの
原因

Unladen Swallowと
の比較

シンボルアクセスの高速化

動的型付け

新規

型検査を、検査結果をキャッシュすることによる高速化

動的型付け

新規

hasattr()組み込み関数のコンパイル時検査による高速化

動的型付け

新規

バイトコードのオペランドスタックを、生成コードが使うスタック上に変換

Python

新規

例外処理による、コンパイラ中間表現の複雑化の抑制

動的型付け

新規

実行時プロファイル情報を用いた、演算の特殊化

動的型付け

改善

大域変数と組み込み関数アクセス時の、ハッシュ表引きの省略

動的型付け

改善

Pythonプログラムのローカル変数を、生成コードが使うスタック上に配置

Python

同じ

個別の最適化にご興味がありましたら、VEEの論文を見ていただくか、
質問をどうぞ
17



シンボルアクセスの最適化

静的型付き言語とスクリプト言語の、値の持ち方の違い


S1: Number a = obj.x
…

S1: a = obj.x
…

メモリレイアウト
obj

メモリレイアウト
obj

値

クローズドハッシュ

…

シンボル名

4

5

x

…

8

1
3

z

値

0

z

5

64

y

[1, 2]

72

x

3.4

y

12

シンボル名

_dict_

offset

offset

18




シンボルにアクセスする場合の違い

S1: Number a = obj.x
…

S1: a = obj.x
…

call a <- get_value_dict(obj, ‘x’)

load a <- 12(obj)

クローズドハッシュ
obj

obj

4

5

x

8

1
3

z

シンボル名

値

…

z

5

y

[1, 2]
3.4

y

12

_dict_

x

シンボル名

offset

• 変数objに格納されたオブジェクトの
先頭アドレスから、定数分離れた位
置にある、xの値を読み出す

機械語１命令
19


• 変数objに格納されたオブジェクトが持つ、
シンボルに関するハッシュ表を引いて、x
の値を読み出す

機械語10命令以上


ハッシュ表のエントリに直接アクセス
 クローズドハッシュからシンボルが保持する値を得るときに、ハッシュ表内のイ
ンデックスを使って、表内エントリに直接アクセスする
► インタプリタで実行している時に、objの型情報と表のインデックスをプロファイラが

記録する
– シンボルxの情報は、表インデックス=9に格納されている
► プロファイル情報を利用して、

JITコンパイラが xへのアクセスにハッシュ表引きを

行わないコードを生成する
► 実行時には、表内のエントリに直接アクセスする
– インデックスが正しいかのチェックも必要（例えば、表がresizeされたら☓）

遅い

call a <- get_value_dict(obj, ‘x’)

S1: a = obj.x (index = 9)
クローズドハッシュの表
obj
type=T

_dict_
…

index offset
0
0

シンボル名

値

z

5

8

y

[1, 2]

9
20

64
72

x

3.4


速い

cmp obj, T
jmp ne, slow_path
load tbl <- 0(obj)
load a <- 72(tbl)

性能測定

性能測定
 それぞれの最適化が、どの程度性能に影響をあたえるか？
► 最初はインタプリタで実行されるので、充分な時間実行してから、性能を測定
► 実装した最適化を１つづつoffする

 測定環境
► ハードウェアとOS
– 2.93-GHz Intel Xeon X5670, 24GBメモリ
– Redhat Linux 5.5
► 処理系
– CPython 2.6.4 (32bit) と IBM Testarossa JITコンパイラ

• Testarossaは、IBM Javaで使われています
► ベンチマークプログラム
– Unladen Swallow benchmark
[http://code.google.com/p/unladen-swallow/wiki/Benchmarks]

21



最適化の例

適用した最適化一覧
最適化

オーバヘッドの
原因

Unladen Swallowと
の比較

シンボルアクセスの高速化

動的型付け

新規

型検査を、検査結果をキャッシュすることによる高速化

動的型付け

新規

hasattr()組み込み関数のコンパイル時検査による高速化

動的型付け

新規

バイトコードのオペランドスタックを、生成コードが使うスタック上に変換

Python

新規

例外処理による、コンパイラ中間表現の複雑化の抑制

動的型付け

新規

実行時プロファイル情報を用いた、演算の特殊化

動的型付け

改善

大域変数と組み込み関数アクセス時の、ハッシュ表引きの省略

動的型付け

改善

参照カウントGC用コードに関する、コンパイラ中間表現の複雑化の抑制

Python

同じ

Pythonプログラムのローカル変数を、生成コードが使うスタック上に配置

Python

同じ

22



性能評価

我々の最適化によって、CPythonに比べ1.76倍の性能向上を得た
 最適化を行わずにコンパイルした場合、1.07倍の性能向上しか得られない
 nbodyでは2.74倍、djangoでは2.60倍の高速化
3.0
Cpythonインタプリタからの性能向上

我々の最適化をすべてOFF
我々の最適化をすべてON
バーが長いほうが高性能

2.5

2.0

1.5

23


n
ea
om
ge

ye
s
sl
ow
sp
itf
ire

m
ba

el
d
sp
a

tv
rie

go
dj
an

s
ric
ha
rd

ne
st
o
py

ns

od
y

ue
e
nq

0.5

nb

flo

at

1.0


性能評価

個々の最適化による、性能向上の度合いを調べる
 シンボルアクセスの高速化： float と richards
 isinstanceの高速化： django と rietveld
►

我々の新規最適化

Django フレームワークでは、instanceofを多用している

 演算の特殊化： float と nbody
 global変数へのアクセス時の、ハッシュ表引きの省略： django
Pythonの組み込み関数の呼び出しが高速化された

24

2.13

1.3

1.2

1.1


ge
om
ea
n

sl
o
w
sp
itf
ire

sp
a
m
ba
ye
s

dj
an
go

ric
h
ar
ds

py
st
on
e

nq
ue
en
s

0.9

nb
od
y

1.0

バーが長いほうが高性能

シンボル
型変換
例外
hasattr
特殊化
global変数

flo
at

J コパラ最化oにたきら、能上
IT ンイの適をしとかの性向
ff

2.26
1.4

rie
tv
el
d

►


途中まとめと次の課題

途中まとめと次への課題
 インタプリタに比べて、約1.7倍の性能改善を得ることが出来た
 スクリプト言語のための、より強力な最適化を実装したい
► メソッド全体の情報を利用した、演算の特殊化
► int/float変数のボックス化解除

 コンパイラが持っている最適化を、より活用したい
► 型情報を使った、データフロー最適化
► シンボルアクセスに関する共通部分式最適化
► メソッドインライニング

25



途中まとめと次の課題

途中まとめと次への課題
 インタプリタに比べて、約1.7倍の性能改善を得ることが出来た
 スクリプト言語のための、より強力な最適化を実装したい
► メソッド全体の情報を利用した、演算の特殊化
► int/float変数のボックス化解除

 コンパイラが持っている最適化を、より活用したい
► 型情報を使った、データフロー最適化
► シンボルアクセスに関する共通部分式最適化
► メソッドインライニング

26





[VEE2012]





[OOPSLA2012]


27



貢献

OOPSLAの論文での我々の貢献
► メソッド全体に渡る最適化

– メソッド全体の情報を利用した、演算の特殊化
– int/float変数のボックス化解除

• 変数をレジスタに割り付けて、CPU命令で演算が可能になる

既存のJITコンパイラを再利用する際の落とし穴、をまとめた

28



メソッド全体での最適化

データフロー解析を用いた、特殊化とボックス化解除
型情報とその値をメソッド全体に伝搬させる
► 特殊化のチェックの削減
► 演算の特殊化
► 定数値の伝搬

int/float型変数に対する脱出解析の適用
► 不要なオブジェクト生成の抑制による、ボックス化解除

29



最適化の過程

bに関する、型情報と値情報をメソッド全体に伝搬させる
 bの参照回数と型検査が減る
b = Int(1)
int i = a.val + b.val;
c = Int(i)
} else {
c = add(a, b);
}
// cは型が不定のオブジェクト

b = Int(1)
if (a.type == Int && b.type Int == Int) {
int i = a.val + b.val 1;
c = Int(i)
} else {
c = add(a, b);
}

30



最適化の過程

特殊化されない場合はインタプリタに戻って実行を続ける
 後続で使われるcは、intであることが保証される
► データフロー解析に良い影響を与える
b = Int(1)
if (a.type == Int) {
int i = a.val + 1;
c = Int(i)
} else {
c = add(a, b);
}

b = Int(1)
int i = a.val + 1;
c = Int(i)
} else {
c = add(a, b); goto interpreter
}
// cはintオブジェクト
31


バイトコード
CONST
STORE
LOAD
LOAD
ADD
STORE

1 int
b
a
b
c


最適化の過程

bとcの定義参照を最適化
 bはインタプリタでしか使われない（という解析結果から）ので、定義位置を移動
 cの参照は単純変数である（という解析結果から）ので、不要な定義の消去
b = Int(1)
int i = a.val + 1;
c = Int(i)
} else {
goto interpreter; // a と bはインタプリタで使われる
}
// cはintオブジェクト

b = Int(1)
int i = a.val + 1;
c = Int(i)
} else {
b = Int(1);
goto interpreter;
}
// cはint変数
32


c = a.val + 1;
} else {
b = Int(1);
goto interpreter;
}
// cは単純変数

性能評価

さらなる最適化によって、CPythonに比べ2.15倍の性能向上を得た
前の性能評価のグラフは1.76倍だったのが、2.15倍まで増えた
►単純変数を扱う、floatとnbodyの伸びが著しい

1.9倍から6.0倍

2.7倍から4.1倍

1.76倍から
2.15倍

33
33



ここまでのまとめ

最適化を頑張ってみた
 が、インタプリタ・実行時ルーチン・コンパイラを一から作った、pypyには勝てな
い

→何が問題なのか

34





[VEE2012]





[OOPSLA2012]


35



落とし穴

JITコンパイラを再利用する際の、落とし穴
 Guard-baseの特殊化はとても重要
► 既存のコンパイラの最適化の適用を促進する
► 実行時プロファイル情報が必要

 実行時ルーチンの最適化が容易ではない
► 呼び呼ばれ関係が長い
► オブジェクト操作（メモリ操作）が多い

 JITコンパイラに注目しすぎて、VMや実行時ルーチンの重要性を過小評価する
► VMや実行時ルーチンで複雑な処理が行われ、これらの処理は時間がかかる
► オブジェクトの形は重要

 コードのインライニングが重要
► プログラムのメソッド間

– 呼び出しコストの削減や最適化範囲の拡大
► プログラムと、ライブラリや実行時ルーチン間
– プログラムと、ライブラリや実行時ルーチンが、異なる言語で書かれていると容易ではない
36



落とし穴の例

オブジェクトの形は性能に大きく影響を与える
 CPython – ハッシュ表に基づいたシンボルアクセス（遅い）
► 表の大きさが大きいが実装が容易
► アクセスにハッシュの表引きが必要

→ アクセスに大きいコストが必要

obj

obj

_dict_

_class_

_dict_

{‘x’:1, ‘y’:2, ‘z’:3}

class A

_class_

{‘x’:1.2, ‘z’:-1, ‘y’:0.1}

 pypy – 単純な表に基づいたシンボルアクセス(速い) (Pythonのslotsのようなもの）
► 表の大きさが小さい
► baseアドレス+offsetでアクセスするコードを生成できる

が必要

obj

obj

_stroage_ _class_

1

→ アクセスに大きいコスト

2

3

class A
‘x’ 0 ‘y’

_storage_ _class_

1.2
1

‘z’

0.1

-1

2
http://morepypy.blogspot.jp/2010/11/efficiently-implementing-python-objects.html

37



落とし穴の例

プログラムと実行時ルーチン間
 プログラムとライブラリが、異なる最適化対象になる
►

２つを合わせた最適化は容易ではない

►

特殊化である程度回避できるが、特殊化したい操作が増えてくると、労働集約的になってくる

 プログラムとライブラリが、同じ最適化対象となる
►

２つ合わせた最適化が容易

►

ライブラリの実行パスが長い・複雑、だと効果が無い→Graal/Truffleは単純化を促進するか？
プログラム

ライブラリ

記述言語

最適化対象

記述言語

最適化対象

Python


C

機械語

Unladen Swallow Python


C

機械語

JVM

Java

Java bytecode

Java

Java bytecode

pypy

Python

pypy中間表現

RPython

pypy中間表現

SPUR

JavaScript

CIL

JavaScript
C#など

CIL

Jython

Python

Java bytecode

Java

Java bytecode

我々の実装

38



落とし穴に落ちないために

JITコンパイラを再利用する際のTIPS
実行時ルーチンの挙動を理解しよう
► オーバヘッドが多いのはどこなのか？
► なぜ、そのオーバヘッドが起きるのか？

– オブジェクトフォーマット？
– メソッド呼び出し？
– 演算の複雑さ？
– ユーザープログラムと実行時ルーチンの境界？
– プログラムの書き方？

実行時ルーチンのパスをなるべく短くしよう
► 言語の設計
► 実行時ルーチンの書き方
► 最適化

既存のコンパイラの最適化を効率よく再利用するために、特殊化
を頑張ろう
39



今日の話のまとめ

言語・システムの研究の一経験について
► 特殊化は必須の最適化
► 特に、整数・浮動小数点型に対しては、CPUの性能をより引き出す

言語処理系の性能を向上させるには、幅広い知識が必要
► プログラムの使われ方

– 言語単独で用いられる？他のライブラリとつながる？
► 適用される最適化と生成されるコードへの理解

– 単純に見えるコードでも、プロセッサ上では複雑な処理を行っている
– 複雑なコードでも、最適化で単純なコードにできる？
► プログラムのコンパイル・リンクのされ方

– 言語が提供するライブラリ、実行時ルーチン、はどのようにコンパイルされる？

既存の処理系・コンパイラを効率よく再利用して、言語実装の研究を行
えば、容易に効率よく、新しい技術を研究・開発ができる
40



静的型付き言語用Just-In-Timeコンパイラの再利用による、動的型付き言語用コンパイラの実装と最適化

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Viewers also liked

Viewers also liked (20)

Similar to 静的型付き言語用Just-In-Timeコンパイラの再利用による、動的型付き言語用コンパイラの実装と最適化

Similar to 静的型付き言語用Just-In-Timeコンパイラの再利用による、動的型付き言語用コンパイラの実装と最適化 (20)

More from Kazuaki Ishizaki

More from Kazuaki Ishizaki (19)

静的型付き言語用Just-In-Timeコンパイラの再利用による、動的型付き言語用コンパイラの実装と最適化