2014/8/23 こみゅぷらす にて

1. .NET vNext
岩永 信之

2. 自己紹介
• 日本C＃ユーザー会
• 日本のC#ユーザーを応援するコミュニティです
• codeseek
• 「システムの品質はコードに宿る」をポリシーに活
動をしています
• 毎月何かしら勉強会をやっています

3. 今日の内容
• 最近のMicrosoft
• .NETの近い将来
• .NET Native
• .NET vNext Cloude Mode
主に.NETプログラムの
実行方式の話

4. 最近のMicrosoft
One Windows
Device First, Cloud First

5. One
• One Microsoft
• One Windows
• 単一チームで全Windowsを開発
• 単一のコア(NTカーネル)
• 単一のストア
• 単一API (Windows Runtime)
今、すでにそう
なってる/なりつつある
要は、組織改編

6. Device first, Cloud first
デスクトップ
クライアント アプリ
Phone/タブレット
クライアント アプリ
サーバー アプリ
既存資産
Mobile firstCloud first

7. Mobile first, Cloud first
• “first” (優先して注力はするが、onlyではない)
• 既存のデスクトップへの投資もまだ続く
• MobileとCloud
• 改めてこれから注力すべき場所を強調
(この方針自体は前から変わってない)

8. .NETにとっては
• Mobile first
• ストア越し(審査付き)のアプリ配布
• 低消費電力を求められる
• Cloud first
• サーバー上でのソースコード手直し
• 共有ホスティング型のサーバーへの対応
.NET Native
.NET vNext Cloud Mode

9. .NET Frameworkの
実行方式
これまでの.NET Framework
中間言語とJIT

10. 中間コードとJITコンパイル
• .NET Frameworkの中間言語
• 中間言語があることで
• 高級言語のコンパイラーを作る人と、CPUごとの最
適化する人の分業化
• セキュリティ チェックしやすい
• 動的リンク時に、コード修正の影響を吸収
• 動的な実行(リフレクション)
高級言語
(C#など)
中間言語
(IL)
ネイティブ
コード
コンパイル コンパイル
問題は「いつやるか」

11. 中間言語の良し悪し
利点
• 動的リンク・部分更新しやすい
• セキュリティ検証しやすい
• (ソースコード配布よりは)高速
欠点
• .NET Frameworkのランタイム インストール必須
• (ネイティブ配布よりは)低速
• (ソースコード配布よりは)デバッグ・修正が面倒
用途によっては…

12. 中間言語: デスクトップでは
利点
• 動的リンク・部分更新しやすい
• セキュリティ検証しやすい
• (ソースコード配布よりは)高速
欠点
• .NET Frameworkのランタイム インストール必須
• (ネイティブ配布よりは)低速
• (ソースコード配布よりは)デバッグ・修正が面倒
JITとかWindowsサービス巡回
とかでないと保証しにくい
PCの性能的に
許容範囲
なんだかんだいって
JITのメリットあり
JIT
そんなに頻繁な
修正しない

13. Just-in-Time
• 実行した瞬間にコンパイル
高級言語
(C#など)
中間言語
(IL)
ネイティブ
コード
コンパイル コンパイル
開発環境 実行環境
配布
ビルド時 Just-in-Time
(実行した瞬間)
起動した瞬間が重い
起動のたびに処理が走る
(最初期からある)

14. Ngen
• Ngen.exe (Native Image Generator)
• ILを事前にネイティブ化するためのツール
• 自前管理が必要
• アプリのインストーラー※とかを作って明示的に呼び出し
• 参照しているライブラリが更新された時には呼びなおす
必要あり
• かなり面倒なのでアプリを
Ngenすることはめったにない
• .NET自体が標準ライブラリの
高速化のために使ってる
※ 要するに、JITの負担を起動時じゃなくてインストール時に前倒しする
(最初期からある)

15. Auto-Ngen
• NgenがWindowsサービスとして常に動いてる
• アイドル時に動作
• 利用頻度の高いものを自動的にNgen
• デスクトップ アプリの場合はGACアセンブリのみ
• Windowsストア アプリの場合はすべてのアセンブリ
• よく使うアプリの起動はだいぶ早くなる
• インストール直後の起動は相変わらず遅い
(.NET 4.5)

16. 問題: 実行環境の多様化
デスクトップ
クライアント アプリ
Phone/タブレット
クライアント アプリ
サーバー アプリ
既存資産
Mobile firstCloud first
要件が変わる

17. Mobile first
携帯端末中心の.NET Framework
端末側の負担を減らす

18. 中間言語: 携帯デバイスでは
利点
• 動的リンク・部分更新しやすい
• セキュリティ検証しやすい
• (ソースコード配布よりは)高速
欠点
• .NET Frameworkのランタイム インストール必須
• (ネイティブ配布よりは)低速
• (ソースコード配布よりは)デバッグ・修正が面倒
ストア サーバー上で
やればいい
ランタイム分のストレージ
容量使いたくない
性能的に結構困る
ストア サーバー上で
ネイティブ化
.NET Native

19. MDIL※
• 部分的に、事前ネイティブ化
• 動的リンクに必要な情報だけ中間言語を残す
push ebp
mov ebp,esp
cmp dword ptr ds:[5011058h],0
je 00FE2A01
call 74B7AEA8
mov eax,dword ptr [ebp+8]
lea edx,[ebp+8]
imul eax,dword ptr [edx+4]
lea edx,[ebp+8]
imul eax,dword ptr [edx+8]
pop ebp
ret 0Ch
int32 Point::X
int32 Point::Y
int32 Point::Z
型情報だけ残す
(動的リンクに必要)
※ Machine Dependent Intermediate Language
(Windows Phone 8)
ほぼネイティブ

20. MDIL (Compile in the Cloud)
• ストア サーバー上でMDIL化までやっておく
C#コード
IL
MDIL
ネイティブ コード
C#コンパイラー
MDILコンパイラー
リンカー
開発環境でILにコンパイル
Windowsストア サーバー
上でILをMDIL化
Windows Phone実機上では
レイアウトの解決(リンク)だけ行う
インストール直後の起動も高速
(Windows Phone 8)

21. .NET Native
• ストア サーバー上でネイティブ化
C#コンパイラー
開発環境でILにコンパイル
Windowsストア サーバー
上でネイティブ化
ネイティブ化したものを
デバイスに配布
C#コード
IL
事前コード生成
ILレベル最適化
MDIL
ネイティブ
コード
crossgen
コンパイラー
(vNext)

22. .NET Native: in the Cloud
• 基本的にストア アプリ用
• セキュリティ保証などはサーバー上で
• アップロード時にはIL、審査付き
• クライアント デバイス的には低コスト
• JITのコストなし、ランタイムのインストール不要
• Visual Studio上で直接ネイティブ化も可能
• 通常版の.NETとの差で問題が起きないかの確認用
• 特にパフォーマンス
(vNext)

23. .NET Native: 最適化
• 「事前にJIT相当の処理」以上の最適化も
• C++最適化コンパイラーと成果共有
• シリアライズなどのコードを事前に展開
• 型情報を見たいからリフレクションを使ってただけで、
実際にはビルド時に型が確定してることが多い
• 必要な分だけ静的リンク
• ライブラリをまたいだ最適化が可能
• 不要コードは残さないので実行可能ファイルのサイズは
膨らまない
(vNext)

24. .NET Native: リフレクション
• リフレクションも使える
ただし…
• XAML {Binding}など、推論が効く部分は自動判定し
てくれる
• それ以外は、自分で「この型はリフレクションで
使ってる」という情報を書かないとダメ
(Runtime Directiveファイル)
• 動的コード生成は無理
• 式ツリーなどはインタープリター方式になるので遅い
(vNext)

25. Cloud first
サーバー、特にクラウド中心の.NET Framework
手軽なソースコード更新
side-by-sideランタイム

26. 中間言語: サーバーでは
利点
• 動的リンク・部分更新しやすい
• セキュリティ検証しやすい
• (ソースコード配布よりは)高速
欠点
• .NET Frameworkのランタイム インストール必須
• (ネイティブ配布よりは)低速
• (ソースコード配布よりは)デバッグ・修正が面倒
アプリ稼働時間が長くて、
最初の1回だけのコストは
無視できる(低速でもいい)
開発機とサーバー機でバー
ジョンが違って困ることが
サーバー上で確認しつつ
その場でソースコードを修正したい
ソースコード配置
自動パッケージ管理
Cloud Mode
アプリごとに別バー
ジョンを使えない

27. .NET vNext Cloud Mode
• クラウド向けの実行形態
• side-by-sideインストール
• ソースコード配布
• パッケージ管理
(vNext)

28. side-by-sideインストール
• (サーバーにインストールするんじゃなく)
アプリごとに別.NETランタイムを使える
• (同一サーバーで)
アプリごとにバージョンを変えれる
• 共有ホスティング型のサーバーでも安心
• バージョン更新するかどうかをアプリ単位で判断できる
• 開発時と完全に同じバージョンを使える
• (.NETではめったに見ないけども)
バージョン違いに起因する問題を回避できる
(vNext)

29. ソースコード配置
• ビルドという工程不要
• ソースコード書き替えて、ブラウザー更新するだけ
• サーバー上で編集可能
• メモリ上で全部コンパイル
• コンパイル結果を一時ファイルに残さない
• ディスクI/Oがネックになりにくい
• .NET Compiler Service (Roslyn)を利用
(vNext)

30. 補足: .NET Compiler Platform†
• C#/VBコンパイラーを再設計・再実装
• .NET実装 (C#実装のC#/VB実装のVBコンパイラー)
• コンパイラーの内部データを誰でも自由に使える
• 用途
• C#スクリプティング
• ソースコード配置
• .NET vNext (Cloud First)
• コード解析
• IDE連携、静的解析ツール
† コードネーム“Roslyn”って呼ばれてたやつの正式名称

31. パッケージ管理
• 自動パッケージ管理
開発機 アプリ サーバー パッケージ リポジトリ
例
http://nuget.org
http://myget.org
project.json
*.cs
"dependencies": {
"Library.A": "",
"Library.B": ""
}
var c = new Configuration();
c.AddJsonFile("config.json");
a.UseServices(services => …);
ソースコードとパッ
ケージ利用情報だけ
をアップロード
サーバー上で
編集可能
.NETランタイムや、
ライブラリの不足・更新
はクラウドから取得
利用するパッケージ
の情報ファイル
(vNext)

32. kproj
• (Visual Studio上の)新しいプロジェクト形式
• 「プロジェクト」と「アセンブリ参照」と「パッ
ケージ」を区別しない
• プロジェクト: 同一ソリューション内の他のプロジェクト
を参照
• アセンブリ参照: 標準ライブラリなどのDLLを参照
• パッケージ: NuGetを利用してWeb公開されているライブ
ラリを参照
• JSONで管理
(vNext)

33. 旧形式(csproj)

34. 新形式(kproj)
• JSON (project.json)でプロジェクト設定を管理
"dependencies": {
"Newtonsoft.Json": "",
"System.Console": "",
"Classlibrary1": ""
}
パッケージ参照
アセンブリ参照
プロジェクト参照
(必要ならバージョン
を明示的に指定)

35. ASP.NET vNext
• .NET vNext (これまでのまとめ)
• ソースコード配置
• side-by-sideインストール
• パッケージ管理
• これに加えて
• IIS(など、特定のアプリサーバー)依存脱却
• 脱System.Webアセンブリ
• OWIN (Open Web Inteface for .NET)
• Monoでのホストも可能
• ASP.NET MVC / Web API / Web Pagesの統合
• オープンソース、GitHub公開

36. その他補足

37. RyuJIT
• JITコンパイラーも新しくなる
• 既存資産にも投資は続いてる
• JIT方式しなくなるわけじゃない(適材適所)
• RyuJITの大きな改善点
• 起動時間短縮
• 今まで64bit JITコンパイラーはサーバー向けだったので、
起動に重きを置かれてなかった
• SIMD演算対応

38. 補足: SIMD演算
• Single Instruction Multiple Data
演算
回路
入力
出力
普通の命令
• 1命令1データ
演算
回路
入力
出力
SIMD命令
• 1命令複数データ
入力 入力 入力
出力 出力 出力
単純な累算処理※なら
並列度の分だけ高速化
※ ↓こういうの
for (var i = 0; i < length; ++i)
output[i] = F(input[i]);

39. 標準ライブラリ
• ランタイムが3系統別実装
• JIT
• .NET Native
• Cloud Mode
• 1つの“標準”ライブラリで保守するのは大変
• どうしても事前ネイティブ化しにくい…
• サーバーにGUIコンポーネント要るの？…
• フットプリント的に余計なもの載せれない…
new!
new!

40. 1つの標準にできるのか？
デスクトップ
クライアント アプリ
Phone/タブレット
クライアント アプリ
サーバー アプリ
既存資産
Mobile firstCloud first
共通部分
この共通部分だけを
「標準」にすべき？
PCLみたいな仕組み必須

41. PCL(Portable Class Library)
• 実行環境ごとに
別の「標準ライブラリ」
プロファイルを用意
• ライブラリ側でどの
実行環境をターゲットに
するか選ぶ
実行環境ごとに
別メタデータを提供
ターゲット選択

42. PCLの例
• 例: 2環境
共通部分

43. PCLの例
• 例: 3環境
共通部分

44. .NET vNextプロファイル
• 今のプロファイル
• デスクトップ向け
• Windowsストア アプリ向け
• (Phone, Xbox, Silverlight, …)
• vNextのプロファイル
• .NET Native向け
• ストア アプリ向け － 事前ネイティブ化しにくいところ
• Cloude Mode向け
• GUI関連ごっそりない

45. まとめ

46. 実行環境の多様化
デスクトップ
クライアント アプリ
Phone/タブレット
クライアント アプリ
サーバー アプリ
既存資産
Mobile firstCloud first

47. Mobile first, Cloud first
• Mobile: .NET Native
• ストア サーバー上でのネイティブ化
• かなりアグレッシブな最適化付き
• 一応、リフレクションも利用可能
• Cloud: .NET vNext Cloud Mode
• side-by-sideインストール
• ソースコード配置
• パッケージ管理