net vnext

.NET vNext

岩永信之

++C++; // 未確認飛行 C

自己紹介

• 日本 C ＃ユーザー会• 日本の C# ユーザーを応援するコミュニティです

• codeseek• 「システムの品質はコードに宿る」をポリシーに

活動をしています

• 毎月何かしら勉強会をやっています

今日の内容

• 最近の Microsoft• .NET の近い将来• .NET Native• .NET vNext Cloude Mode

主に .NET プログラムの実行方式の話

最近の MicrosoftOne Windows

Device First, Cloud First

One

• One Microsoft• One Windows• 単一チームで全 Windows を開発• 単一のコア (NT カーネル )• 単一のストア• 単一 API (Windows Runtime)

今、すでにそうなってる / なりつつあ

る

要は、組織改編

Device first, Cloud first

デスクトップクライアントアプリ

Phone/ タブレットクライアントアプリ

サーバーアプリ

既存資産

Mobile firstCloud first

Mobile first, Cloud first

• “first” ( 優先して注力はするが、 only ではない )• 既存のデスクトップへの投資もまだ続く

• Mobile と Cloud• 改めてこれから注力すべき場所を強調

( この方針自体は前から変わってない )

.NET にとっては

• Mobile first• ストア越し ( 審査付き ) のアプリ配布• 低消費電力を求められる

• Cloud first• サーバー上でのソースコード手直し• 共有ホスティング型のサーバーへの対応

.NET Native

.NET vNext Cloud Mode

.NET Framework の実行方式これまでの .NET Framework

中間言語と JIT

中間コードと JIT コンパイル

• .NET Framework の中間言語

• 中間言語があることで• 高級言語のコンパイラーを作る人と、 CPU ごとの

最適化する人の分業化• セキュリティチェックしやすい• 動的リンク時に、コード修正の影響を吸収• 動的な実行 ( リフレクション )

高級言語(C# など )

中間言語(IL)

ネイティブコード

コンパイルコンパイル

問題は「いつやるか」

中間言語の良し悪し

利点•動的リンク・部分更新しやすい•セキュリティ検証しやすい•(ソースコード配布よりは )高速

欠点•.NET Frameworkのランタイムインストール必須•(ネイティブ配布よりは)低速•(ソースコード配布よりは)デバッグ・修正が面倒

用途によっては…

中間言語 : デスクトップでは



JIT とか Windows サービス巡回とかでないと保証しにくい

PC の性能的に許容範囲

なんだかんだいってJIT のメリットあり

JIT

そんなに頻繁な修正しない

Just-in-Time

• 実行した瞬間にコンパイル

高級言語(C# など )

中間言語(IL)


コンパイルコンパイル

開発環境実行環境

配布

ビルド時 Just-in-Time( 実行した瞬

間 )起動した瞬間が重い起動のたびに処理が走る

( 最初期からある )

Ngen

• Ngen.exe (Native Image Generator)• IL を事前にネイティブ化するためのツール• 自前管理が必要

• アプリのインストーラー※とかを作って明示的に呼び出し

• 参照しているライブラリが更新された時には呼びなおす必要あり •かなり面倒なのでアプリを

Ngen することはめったにない• .NET 自体が標準ライブラリ

の高速化のために使ってる

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

( 最初期からある )

Auto-Ngen

• Ngen が Windows サービスとして常に動いてる• アイドル時に動作• 利用頻度の高いものを自動的に Ngen

• デスクトップアプリの場合は GAC アセンブリのみ• Windows ストアアプリの場合はすべてのアセンブリ•よく使うアプリの起動はだいぶ早くなる•インストール直後の起動は相変わらず遅

い

(.NET 4.5)

問題 : 実行環境の多様化




既存資産

Mobile firstCloud first要件が変わる

Mobile first携帯端末中心の .NET Framework

端末側の負担を減らす

中間言語 : 携帯デバイスでは



ストアサーバー上でやればいい

ランタイム分のストレージ容量使いたくない

性能的に結構困る

ストアサーバー上でネイティブ化

.NET Native

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::Xint32

Point::Yint32

Point::Z

型情報だけ残す( 動的リンクに必

要 )

※ Machine Dependent Intermediate Language

(Windows Phone 8)

ほぼネイティブ

MDIL (Compile in the Cloud)• ストアサーバー上で MDIL 化までやっておく

C#コード

IL

MDIL


C# コンパイラー

MDIL コンパイラー

リンカー

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

Windows ストアサーバー上で IL を MDIL 化

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

インストール直後の起動も高速

(Windows Phone 8)

.NET Native

• ストアサーバー上でネイティブ化

C# コンパイラー開発環境で IL にコンパイル

Windows ストアサーバー上でネイティブ化

ネイティブ化したものをデバイスに配布

C#コード

IL

事前コード生成

ILレベル最適化

MDIL


crossgenコンパイラー

(vNext)

.NET Native: in the Cloud

•基本的にストアアプリ用• セキュリティ保証などはサーバー上で

• アップロード時には IL 、審査付き• クライアントデバイス的には低コスト

• JIT のコストなし、ランタイムのインストール不要

• Visual Studio 上で直接ネイティブ化も可能• 通常版の .NET との差で問題が起きないかの確認

用• 特にパフォーマンス

(vNext)

.NET Native: 最適化

• 「事前に JIT相当の処理」以上の最適化も• C++ 最適化コンパイラーと成果共有• シリアライズなどのコードを事前に展開

• 型情報を見たいからリフレクションを使ってただけで、実際にはビルド時に型が確定してることが多い

• 必要な分だけ静的リンク• ライブラリをまたいだ最適化が可能• 不要コードは残さないので実行可能ファイルのサイズは膨らまない

(vNext)

.NET Native: リフレクション• リフレクションも使える

ただし…• XAML {Binding} など、推論が効く部分は自動判定してくれる• それ以外は、自分で「この型はリフレクションで

使ってる」という情報を書かないとダメ(Runtime Directive ファイル )• 動的コード生成は無理

• 式ツリーなどはインタープリター方式になるので遅い

(vNext)

Cloud firstサーバー、特にクラウド中心の .NET Framework

手軽なソースコード更新side-by-side ランタイム

中間言語 : サーバーでは



アプリ稼働時間が長くて、最初の 1 回だけのコストは無視できる ( 低速でもいい )

開発機とサーバー機でバージョンが違って困ることが

サーバー上で確認しつつその場でソースコードを修正したい

ソースコード配置自動パッケージ管理

Cloud Modeアプリごとに別バージョンを使えない

.NET vNext Cloud Mode

• クラウド向けの実行形態• side-by-side インストール• ソースコード配布• パッケージ管理

(vNext)

side-by-side インストール

• ( サーバーにインストールするんじゃなく )アプリごとに別 .NET ランタイムを使える• (同一サーバーで )

アプリごとにバージョンを変えれる• 共有ホスティング型のサーバーでも安心• バージョン更新するかどうかをアプリ単位で判断できる

• 開発時と完全に同じバージョンを使える• (.NET ではめったに見ないけども )

バージョン違いに起因する問題を回避できる

(vNext)

ソースコード配置

• ビルドという工程不要• ソースコード書き替えて、ブラウザー更新するだけ• サーバー上で編集可能

• メモリ上で全部コンパイル• コンパイル結果を一時ファイルに残さない• ディスク I/O がネックになりにくい

• .NET Compiler Service (Roslyn) を利用

(vNext)

補足 : .NET Compiler Platform†• C#/VB コンパイラーを再設計・再実装• .NET 実装 (C# 実装の C#/VB 実装の VB コンパイ

ラー )• コンパイラーの内部データを誰でも自由に使える

• 用途• C# スクリプティング• ソースコード配置

• .NET vNext (Cloud First)

• コード解析• IDE連携、静的解析ツール

† コードネーム“ Roslyn” って呼ばれてたやつの正式名称

パッケージ管理

• 自動パッケージ管理開発機アプリサーバーパッケージリポジトリ

例http://nuget.orghttp://myget.org

project.json

*.cs

"dependencies": { "Library.A": "", "Library.B": ""}

var c = new Configuration();c.AddJsonFile("config.json");a.UseServices(services => …);

ソースコードとパッケージ利用情報だけをアップ

ロード

サーバー上で編集可能

.NET ランタイムや、ライブラリの不足・更新

はクラウドから取得

利用するパッケージの情報ファイル

(vNext)

http://nuget.org/

http://myget.org/

kproj

• (Visual Studio 上の ) 新しいプロジェクト形式• 「プロジェクト」と「アセンブリ参照」と「パッケージ」を区別しない• プロジェクト : 同一ソリューション内の他のプロジェク

トを参照• アセンブリ参照 : 標準ライブラリなどの DLL を参照• パッケージ : NuGet を利用して Web公開されているラ

イブラリを参照• JSON で管理

(vNext)

旧形式 (csproj)

アセンブリ参照プロジェクト参照

パッケージ参照

新形式 (kproj)

• JSON (project.json) でプロジェクト設定を管理"dependencies": { "Newtonsoft.Json": "", "System.Console": "", "Classlibrary1": ""}

パッケージ参照アセンブリ参照

プロジェクト参照

( 必要ならバージョンを明示的に指定 )

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公開

その他補足

RyuJIT

• JIT コンパイラーも新しくなる• 既存資産にも投資は続いてる• JIT 方式しなくなるわけじゃない ( 適材適所 )

• RyuJIT の大きな改善点• 起動時間短縮

• 今まで 64bit JIT コンパイラーはサーバー向けだったので、起動に重きを置かれてなかった

• SIMD演算対応

補足 : SIMD演算

• Single Instruction Multiple Data

演算回路

入力

出力

普通の命令• 1命令 1 データ

演算回路

入力

出力

SIMD命令• 1命令複数データ

入力入力入力

出力出力出力

単純な累算処理※なら並列度の分だけ高速化

※ ↓こういうのfor (var i = 0; i < length; ++i) output[i] = F(input[i]);

標準ライブラリ

• ランタイムが 3系統別実装 • JIT• .NET Native• Cloud Mode

• 1 つの“標準”ライブラリで保守するのは大変• どうしても事前ネイティブ化しにくい…• サーバーに GUI コンポーネント要るの？…• フットプリント的に余計なもの載せれない…

new!

new!

1 つの標準にできるのか？




既存資産


共通部分

この共通部分だけを「標準」にすべき？

PCLみたいな仕組み必須

PCL(Portable Class Library)

• 実行環境ごとに別の「標準ライブラリ」プロファイルを用意• ライブラリ側でどの

実行環境をターゲットにするか選ぶ

実行環境ごとに別メタデータを提供

ターゲット選択

PCL の例

•例 : 2 環境

共通部分

PCL の例

•例 : 3 環境

共通部分

.NET vNext プロファイル

• 今のプロファイル• デスクトップ向け• Windows ストアアプリ向け• (Phone, Xbox, Silverlight, …)

• vNext のプロファイル• .NET Native向け

• ストアアプリ向け－事前ネイティブ化しにくいところ• Cloude Mode向け

• GUI関連ごっそりない

まとめ

実行環境の多様化




既存資産


Mobile first, Cloud first

• Mobile: .NET Native• ストアサーバー上でのネイティブ化• かなりアグレッシブな最適化付き• 一応、リフレクションも利用可能

• Cloud: .NET vNext Cloud Mode• side-by-side インストール• ソースコード配置• パッケージ管理

net vnext

Technology