C#とILとネイティブと

C#とILとネイティブと
岩永信之

本日の内容
• C#コードのコンパイル過程
• どうしてIL (.NETの中間言語)なのか
• ライブラリのコード変更の影響
• ソースコード配付でない理由
• ネイティブコード配付でない理由

• ネイティブコード化
• Ngen、MDIL、Project “N”

C#、ILの
コンパイルの過程
C# → IL → ネイティブ

コンパイル
C#
コード
C#コンパイラー

IL
JITコンパイラー

ネイティブ
コード

コンパイル
.NET言語
C#の他にも
• Visual Basic
C#コンパイラー • F#
• …

C#
コード

IL

static int GetVolume(Point p)
JITコンパイラー {
return p.X * p.Y * p.Z;
}
ネイティブ

コード

コンパイル
C#
コード

IL

ネイティブ
コード

Intermediate Language
.NET共通の中間言語
.maxstack
IL_0000:
IL_0001:
IL_0006:
IL_0007:
IL_000c:
IL_000d:
IL_000e:
IL_0013:
IL_0014:

8
ldarg.0
ldfld int32 Point::X
ldarg.0
ldfld int32 Point::Y
mul
ldarg.0
ldfld int32 Point::Z
mul
ret

コンパイル
C#
コード

IL

ネイティブ
コード

ネイティブコード
CPUごとの命令列
push
mov
cmp
je
call
mov
lea
imul
lea
imul
pop
ret

ebp
ebp,esp
dword ptr ds:[5011058h],0
00FE2A01
74B7AEA8
eax,dword ptr [ebp+8]
edx,[ebp+8]
eax,dword ptr [edx+4]
edx,[ebp+8]
ebp
0Ch

例
• (C#で)こんな型があったとして
public struct Point
{
public int X;
public int Y;
public int Z;
}

• 整数のフィールドを3つ持つ

例
• こんなメソッドを書いたとする
{
}

• フィールドの掛け算

IL
• C#コンパイル結果のIL
.method private hidebysig static int32
GetVolue(valuetype Point p) cil managed
{
.maxstack 8
型とかフィールド
IL_0000: ldarg.0
IL_0001: ldfld
int32 Point::X
の名前がそのまま
IL_0006: ldarg.0
残ってる
IL_0007: ldfld
int32 Point::Y
IL_000c: mul
型情報
IL_000d: ldarg.0
メタデータ
IL_000e: ldfld
int32 Point::Z
IL_0013: mul
IL_0014: ret
}

• JIT結果 (x64の場合)
push
mov
cmp
je
call
mov
lea
imul
lea
imul
pop
ret

ebp
ebp,esp
00FE2A01
74B7AEA8
edx,[ebp+8]
edx,[ebp+8]
ebp
0Ch

4とか8とかの数値に
型情報は残らない

メモリレイアウト
• この4とか8の意味

Point
X

public struct Point
{
public int X;
public int Y;
public int Z;
}

Y

4バイト

8バイト

Z

※レイアウトがどうなるかは環境依存

メモリレイアウト
• この4とか8の意味
ILの時点までは名前
で参照してる
public struct Point

Point
X

{
public int X;
public int Y;
public int Z;
}

Y

4バイト

8バイト

ネイティブコードは
レイアウトを見て
Z
数値で参照してる
※レイアウトがどうなるかは環境依存

数値でのフィールド参照
• C#で擬似的に書くと
{
}
var pp = (byte*)&p;
var x = *((int*)pp);
var y = *((int*)(pp + 4));
var z = *((int*)(pp + 8));
return x * y * z;

4とか8とかの数値に

※これ、一応C#として有効なコード(unsafe)

ここまでまとめ
• メモリレイアウト
C#
コード

IL

ネイティブ
コード

ILまでは型情報を残している
フィールド名で値を参照

ネイティブコードになると型情報が残らない
レイアウト上のオフセット数値で値を参照

おまけ: ILの見方
• ildasm.exe
• Program Files以下
• Microsoft SDKsWindows[Windowsのバージョ
ン]binNETFX[.NETのバージョン]

おまけ: Nativeの見方
• Visual Studioのメニューから
• デバッグ実行時に
• [デバッグ] → [ウィンドウ] → [逆アセンブル]
• Ctrl+Alt+D

依存関係
• 開発体制としてありがちな状況
他社製
ライブラリ

自社製
ライブラリ

アプリ

依存関係
• もちろん、実際はもっと複雑な依存関係が
• 多対多
• 多段

• 開発者と利用者は別
•
•
•
•

別人
別チーム
別会社
他国

今回の例でいうと
• Point型の開発者と利用者がわかれてると仮定
他社製
ライブラリ
public struct Point
{
public int X;
public int Y;
public int Z;
}

自社製
ライブラリ
int GetVolume(Point p)
{
}

• この状況で、Point型への変更が
GetVolumeメソッド側に及ぼす影響を考える

変更してみる
• 大して影響しなさそうな
ほんの些細な変更をしてみる
public struct Point
{
public int X;
public int Y;
public int Z;
}

public struct Point
{
public int X;
public int Z;
public int Y;
}
フィールドの順序変更

その結果起きること
• メモリレイアウトが変わる※
Point

Point

X

Y

Z

Z

※

X

Y

この例（フィールド）以外にも、仮想メソッドテーブルとかいろいろ変わる

C#レベルでの影響
• 影響なし

• Point構造体がX, Y, Zという名前の3つのintを持って
ることには変わりない
利用側(GetVolumeメソッド側)は
変更があったことを知る必要すらない
再コンパイルの必要なし

ILレベルでの影響
• 影響なし
IL_0000:
IL_0001:
IL_0006:
IL_0007:
IL_000c:
IL_000d:
IL_000e:
IL_0013:
IL_0014:

ldarg.0
ldfld
ldarg.0
ldfld
mul
ldarg.0
ldfld
mul
ret

int32 Point::X
int32 Point::Y

int32

名前で参照してるん
だから特に影響ない
Point::Z
JITが吸収してくれる

ネイティブレベルでの影響
• ここで影響が出る
push
mov
cmp
je
call
mov
lea
imul
lea
imul
pop
ret

ebp
ebp,esp
00FE2A01
74B7AEA8
edx,[ebp+8]
8
edx,[ebp+8]
更新が必要
4
ebp
0Ch
利用側の再コンパイルが必要
ライブラリ側だけの差し替えじゃダメ

• プログラムのほんの些細な変更によって
• メモリレイアウトが変化する
• 利用側(ライブラリ側とは別人が保守)に影響
C#、JITレベルだと影響なし
ネイティブレベルだと影響が出る
• .NET製プログラム/ライブラリ
をILの状態で配布する
最大の理由
• 事前のネイティブ化が難しい

ソースコード配布
スクリプト言語ならそんな問題こと考えなくていいよ？
ただし… 遅い

ネイティブ配布しないとして
• ILなんていう中途半端な状態にする必要ある
の？
• スクリプト言語みたいにソースコード配付すれば？

• 理由はパフォーマンス
• 測ってみよう

方法
• C#には動的に（C#プログラム中で）コンパイ
ルする仕組みがいくつかあるので
• C#コードをコンパイル
• 構文木からコード生成
• ILコンパイル
この辺りを使って比較

高級言語
(C#)

parse
構文木

emit
IL

JIT
ネイティブ
コード

高級言語
(C#)

parse
構文木

emit
IL

JIT
ネイティブ
コード

• parse (構文解析、文法説明)
• (C#みたいな)自然言語に近い
文法を解析
• コンパイラーが扱いやすい
データ形式に変換

高級言語
(C#)

parse
構文木

emit
IL

JIT
ネイティブ
コード

• emit (放射、発行)
• コンピューターが解釈できる
命令を出力する
• (.NETの場合、CPU命令じゃな
くて、ILの仮想マシン命令)
• (もちろん言語によっては直接
CPUネイティブ命令を出力)

高級言語
(C#)

parse
構文木

emit
IL

JIT
ネイティブ
コード

• JIT (Just In Time)
• プログラムを初めて実行する
その瞬間に
• IL仮想マシン命令からCPUネ
イティブ命令に変換

動的コンパイル用ライブラリ
高級言語
(C#)

Roslyn

parse
構文木

式ツリー
(System.Linq.Expressions)

emit
ILGenerator

IL

JIT
ネイティブ
コード

例
• さっきの↓これを生成してみる
{
}

C#コードから
• Roslyn※
var engine = new ScriptEngine();
var session = engine.CreateSession();
session.AddReference(typeof(Point).Assembly);
session.ImportNamespace("System");
session.ImportNamespace("MyNamespace");
return session.Execute<Func<Point, int>>(
"p => p.X * p.Y * p.Z");

※ コードネーム(まだ正式名称じゃない)

今開発中の新しいC#コンパイラー
C#をスクリプト言語的に実行する機能も持つ

C#コードから
• Roslyn
ポイントの行:
session.Execute<Func<Point, int>>("p => p.X * p.Y * p.Z")

C#ソースコードをコンパイル
parse→emit→JIT
C#→[parse]→構文木→[emit]→IL→[JIT]→Native

構文木から
• System.Linq.Expressions
var
var
var
var
var

t
x
y
z
p

=
=
=
=
=

typeof(Point);
t.GetField("X");
t.GetField("Y");
t.GetField("Z");
Expression.Parameter(typeof(Point));

var ex = Expression.Lambda<Func<Point, int>>(
Expression.Multiply(
Expression.Field(p, x),
Expression.Field(p, y)),
Expression.Field(p, z)),
p);

return ex.Compile();

構文木から
• System.Linq.Expressions
ポイントの行:
Expression.Lambda<Func<Point, int>>(
Expression.Field(p, x),
Expression.Field(p, y)),
Expression.Field(p, z)),

構文木から
• 図で表すと

匿名関数を作る
本体

パラメーター

Multiply
pから
Zを読む

p

Multiply

pから
Yを読む

pから
Xを読む


ILを直接生成
• ILGenerator
var t = typeof(Point);
var x = t.GetField("X");
var y = t.GetField("Y");
var z = t.GetField("Z");
var m = new DynamicMethod("GetVolume", typeof(int), new[] { t });
m.DefineParameter(1, ParameterAttributes.In, "p");
var gen = m.GetILGenerator();
gen.Emit(OpCodes.Ldarg_0);
gen.Emit(OpCodes.Ldfld, x);
gen.Emit(OpCodes.Ldfld, y);
gen.Emit(OpCodes.Mul);
gen.Emit(OpCodes.Ldfld, z);
gen.Emit(OpCodes.Ret);

ILを直接生成
• ILGenerator
ポイントの行:
var gen = m.GetILGenerator();

ILを直接生成
• さっき見せたILコードと一緒
IL_0000:
IL_0001:
IL_0006:
IL_0007:
IL_000c:
IL_000d:
IL_000e:
IL_0013:
IL_0014:

ldarg.0
ldfld int32 Point::X
ldarg.0
ldfld int32 Point::Y
mul
ldarg.0
ldfld int32 Point::Z
mul
ret



実行
• コード生成+呼び出しを1000回ループ
かかった時間[ミリ秒]
ILGenerator
(JIT)

39.89

Expressions
(emit→JIT)

67.94

倍遅い

2桁遅い

Roslyn
4314
(parse→emit→JIT)

※うちのPCでの計測の場合

※

測るたびに1割程度はぶれる

要するに
高級言語
(C#)

parse
構文木

emit
IL

JIT
ネイティブ
コード

ここがダントツで重い
残りの部分より2桁くらい遅い

スクリプト言語だと
このコストが丸ごとかかる

補足: このコストは初回のみ
• 何度も同じメソッドを呼ぶ場合
負担はだいぶ小さい
GetVolume(p1);
GetVolume(p2);
GetVolume(p3);
GetVolume(p4);

※

JITとか※の処理はここでだけ発生
ネイティブ化済みの
コードを実行

C#みたいにIL配布する場合はJITのみ
スクリプト言語みたいにソースコード配付する場合はparse→emit→JIT

補足: このコストは初回のみ
とはいえ
• JITですら遅いって言われる
• どうしてもネイティブと比べられる
(比較対象があると結構気になる)
• 特に、起動直後に遅くなる
(最初が肝心なのに)

• これでも、C#は構文的にparseが早い部類
(構文によってはもっと遅い)

• やっぱ事前ネイティブ化の要求はある
• JITのコストですら嫌われる
• 特に、起動直後の遅さ

• ましてparseからやるとさらに2桁遅い

事前ネイティブ化
「やっぱり最初からネイティブにしたい」となったとき
に

選択肢
• 配付形式の選択肢
• ネイティブか
• 中間形式(IL)か
• ソースコード(スクリプト)か

どれがいい？
• 状況によるので選びたい
• さらに別の選択肢: 部分的にネイティブ化

おまけ: 連携も1つの選択肢
• スクリプト言語との連携

• DLR (Dynamic Language Runtime)
• スクリプト言語実装基板

• Iron Pythonなど
• スクリプト言語の.NET実装

• ネイティブとの連携

• WinMD (Windows Metadata)
• .NETの型情報を.NET以外でも使う

• WinRT (Windows Runtime)

• .NETからも参照しやすいネイティブライブラリ

連携もいいんだけど、C#使いたい…

C#でスクリプティング
• ASP.NET
• C#ソースコードのままサイトに配置可能
• 初回アクセス時が異様に遅かった※ものの…
ASP.NET 4/IIS 7.5からは自動実行に

• Azure Websites上のコードならオンライン編集可能
• Visual Studio Online “Monaco”†

• Roslyn (新しいC#コンパイラー)

• C#をスクリプト的に実行する機能も持つ
※

初回アクセス時にコンパイルしてた
コンパイル(parseから)の遅さは先ほどの例の通り
† コードネーム(まだ正式名称じゃない)
ブラウザ上で編集できるエディター

C#でネイティブ
• どの道、最終的にはネイティブ化(JIT)してるん
だから
• ネイティブ化自体はそんなに難しくない
• Mono ※はAOT†コンパイル機能を持ってる

• 問題は「コード変更の影響」で説明した通り
• ライブラリ側のレイアウトとかが変わった時の再コ
ンパイル

Ngen → Auto-Ngen → MDIL → Project “N ”
※ .NET

Framework互換のオープンソース実装
† Ahead of Time: ビルドの時点でネイティブコードにコンパイル

補足: ネイティブだけど
• ここでいう「C#でネイティブ」「.NETアプリ
のネイティブ化」とは
• IL命令をCPUネイティブ命令に置き替えること
• CPUネイティブ命令であってもmanaged
• .NETランタイムを参照していて、メモリ操作などは
.NET Frameworkの管理下

Ngen
• Ngen.exe
• Native Image Generator
• ILを事前にネイティブ化するためのツール
• 自前管理が必要
• アプリのインストーラー※とかを作って明示的に呼び出し
• 参照しているライブラリが更新された時には呼びなおす
必要あり

• かなり面倒なのでアプリを
Ngenすることはめったにない
• .NET自体が標準ライブラリの
高速化のために使ってる
※

要するに、JITの負担を起動時じゃなくてインストール時に前倒しする

Auto-Ngen
• .NET Framework 4.5以降なら

• NgenがWindowsサービスとして常に動いてる
• アイドル時に動作

• 利用頻度の高いものを自動的にNgen
• デスクトップアプリの場合はGACアセンブリのみ
• Windowsストアアプリの場合はすべてのアセンブリ

• よく使うアプリの起動はだいぶ早くなる
• インストール直後の起動は相変わらず遅い

MDIL (ネイティブのおさらい)
• おさらい: ネイティブコードだと
push
mov
cmp
je
call
mov
lea
imul
lea
imul
pop
ret

ebp
ebp,esp
00FE2A01
参照しているライブラリ
74B7AEA8
eax,dword ptr [ebp+8] のレイアウトが変わった
edx,[ebp+8]
時に再コンパイルが必要
edx,[ebp+8]
ebp
0Ch

MDIL (部分的にネイティブ化)
• じゃあ、こんな形式があればいいんじゃ？
push
mov
cmp
je
call
mov
lea
imul
lea
imul
pop
ret

ほぼネイティブ

ebp
レイアウトのところ
ebp,esp
dword ptr ds:[5011058h],0 だけ抽象的に型情報
00FE2A01
を残しておく
74B7AEA8
eax,dword ptr [ebp+8]Point::X
int32
edx,[ebp+8]
eax,dword ptr [edx+4]Point::Y
int32
edx,[ebp+8]
eax,dword ptr [edx+8]Point::Z
int32
ebp
0Ch

MDIL (Compile in the Cloud)
• 実際、Windows Phoneのストアでは
そういう形式が使われている: MDIL
(Machine Dependent Intermediate Language)
C#コード

開発環境でILにコンパイル

MDILコンパイラー

Windowsストアサーバー
上でILをMDIL化
(Compile in the Cloud)

IL

MDIL
リンカー


Windows Phone実機上では
レイアウトの解決(リンク)だけ行う

• インストール直後の起動も安心

Project N
• コードネーム“Project N”※
• C#/.NETコードを直接(ビルド時に)ネイティブ化す
る話も出てるみたい
• 詳細はまだ何も語られてない
• Auto-NgenとかMDILの流れをくむものっぽい

※ http://www.zdnet.com/microsoft-shows-off-its-next-generation-project-n-compiler-technology-7000023156/

• 事前ネイティブ化はそんなに楽じゃない
• ライブラリのコード変更の影響を吸収しないといけ
ない

• かといってアプリ起動のたびにJITしたくない
• Auto-Ngen → MDIL → Project N？

• アイドル時間を使ってネイティブ化したり
• 部分的にネイティブ化したり

まとめ
• C# → IL(中間言語) → ネイティブ
• ILの意義
• ライブラリのコード変更の影響を吸収
• ソースコード配付よりはだいぶ高速

• ネイティブコード化

• Auto-Ngen → MDIL → Project N
• アイドル時間を使ってネイティブ化したり
• 部分的にネイティブ化したり

C#とILとネイティブと

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a C#とILとネイティブと

Similar a C#とILとネイティブと (20)

Más de 信之岩永

Más de 信之岩永 (20)

Último

Último (10)