Downloaded 31 times
![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)
ほぼネイティブ](https://image.slidesharecdn.com/dotnetvnext-140823032247-phpapp01/75/NET-vNext-19-2048.jpg)
![補足: SIMD演算
• Single Instruction Multiple Data
演算
回路
入力
出力
普通の命令
• 1命令1データ
演算
回路
入力
出力
SIMD命令
• 1命令複数データ
入力 入力 入力
出力 出力 出力
単純な累算処理※なら
並列度の分だけ高速化
※ ↓こういうの
for (var i = 0; i < length; ++i)
output[i] = F(input[i]);](https://image.slidesharecdn.com/dotnetvnext-140823032247-phpapp01/75/NET-vNext-38-2048.jpg)
More Related Content
.NET vNext
- 1.
- 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, Cloudfirst デスクトップ クライアント アプリ Phone/タブレット クライアント アプリ サーバー アプリ 既存資産 Mobile firstCloud first
- 7. Mobile first, Cloudfirst • “first” (優先して注力はするが、onlyではない) • 既存のデスクトップへの投資もまだ続く • MobileとCloud • 改めてこれから注力すべき場所を強調 (この方針自体は前から変わってない)
- 8. .NETにとっては • Mobile first •ストア越し(審査付き)のアプリ配布 • 低消費電力を求められる • Cloud first • サーバー上でのソースコード手直し • 共有ホスティング型のサーバーへの対応 .NET Native .NET vNext Cloud Mode
- 9.
- 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 (NativeImage Generator) • ILを事前にネイティブ化するためのツール • 自前管理が必要 • アプリのインストーラー※とかを作って明示的に呼び出し • 参照しているライブラリが更新された時には呼びなおす 必要あり • かなり面倒なのでアプリを Ngenすることはめったにない • .NET自体が標準ライブラリの 高速化のために使ってる ※ 要するに、JITの負担を起動時じゃなくてインストール時に前倒しする (最初期からある)
- 15. Auto-Ngen • NgenがWindowsサービスとして常に動いてる • アイドル時に動作 •利用頻度の高いものを自動的にNgen • デスクトップ アプリの場合はGACアセンブリのみ • Windowsストア アプリの場合はすべてのアセンブリ • よく使うアプリの起動はだいぶ早くなる • インストール直後の起動は相変わらず遅い (.NET 4.5)
- 16. 問題: 実行環境の多様化 デスクトップ クライアント アプリ Phone/タブレット クライアントアプリ サーバー アプリ 既存資産 Mobile firstCloud first 要件が変わる
- 17.
- 18. 中間言語: 携帯デバイスでは 利点 • 動的リンク・部分更新しやすい •セキュリティ検証しやすい • (ソースコード配布よりは)高速 欠点 • .NET Frameworkのランタイム インストール必須 • (ネイティブ配布よりは)低速 • (ソースコード配布よりは)デバッグ・修正が面倒 ストア サーバー上で やればいい ランタイム分のストレージ 容量使いたくない 性能的に結構困る ストア サーバー上で ネイティブ化 .NET Native
- 19. MDIL※ • 部分的に、事前ネイティブ化 • 動的リンクに必要な情報だけ中間言語を残す pushebp 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 inthe 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: inthe Cloud • 基本的にストア アプリ用 • セキュリティ保証などはサーバー上で • アップロード時にはIL、審査付き • クライアント デバイス的には低コスト • JITのコストなし、ランタイムのインストール不要 • Visual Studio上で直接ネイティブ化も可能 • 通常版の.NETとの差で問題が起きないかの確認用 • 特にパフォーマンス (vNext)
- 23. .NET Native: 最適化 •「事前にJIT相当の処理」以上の最適化も • C++最適化コンパイラーと成果共有 • シリアライズなどのコードを事前に展開 • 型情報を見たいからリフレクションを使ってただけで、 実際にはビルド時に型が確定してることが多い • 必要な分だけ静的リンク • ライブラリをまたいだ最適化が可能 • 不要コードは残さないので実行可能ファイルのサイズは 膨らまない (vNext)
- 24. .NET Native: リフレクション •リフレクションも使える ただし… • XAML {Binding}など、推論が効く部分は自動判定し てくれる • それ以外は、自分で「この型はリフレクションで 使ってる」という情報を書かないとダメ (Runtime Directiveファイル) • 動的コード生成は無理 • 式ツリーなどはインタープリター方式になるので遅い (vNext)
- 25.
- 26. 中間言語: サーバーでは 利点 • 動的リンク・部分更新しやすい •セキュリティ検証しやすい • (ソースコード配布よりは)高速 欠点 • .NET Frameworkのランタイム インストール必須 • (ネイティブ配布よりは)低速 • (ソースコード配布よりは)デバッグ・修正が面倒 アプリ稼働時間が長くて、 最初の1回だけのコストは 無視できる(低速でもいい) 開発機とサーバー機でバー ジョンが違って困ることが サーバー上で確認しつつ その場でソースコードを修正したい ソースコード配置 自動パッケージ管理 Cloud Mode アプリごとに別バー ジョンを使えない
- 27. .NET vNext CloudMode • クラウド向けの実行形態 • side-by-sideインストール • ソースコード配布 • パッケージ管理 (vNext)
- 28. side-by-sideインストール • (サーバーにインストールするんじゃなく) アプリごとに別.NETランタイムを使える • (同一サーバーで) アプリごとにバージョンを変えれる •共有ホスティング型のサーバーでも安心 • バージョン更新するかどうかをアプリ単位で判断できる • 開発時と完全に同じバージョンを使える • (.NETではめったに見ないけども) バージョン違いに起因する問題を回避できる (vNext)
- 29. ソースコード配置 • ビルドという工程不要 • ソースコード書き替えて、ブラウザー更新するだけ •サーバー上で編集可能 • メモリ上で全部コンパイル • コンパイル結果を一時ファイルに残さない • ディスクI/Oがネックになりにくい • .NET Compiler Service (Roslyn)を利用 (vNext)
- 30. 補足: .NET CompilerPlatform† • 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.
- 34. 新形式(kproj) • JSON (project.json)でプロジェクト設定を管理 "dependencies":{ "Newtonsoft.Json": "", "System.Console": "", "Classlibrary1": "" } パッケージ参照 アセンブリ参照 プロジェクト参照 (必要ならバージョン を明示的に指定)
- 35. ASP.NET vNext • .NETvNext (これまでのまとめ) • ソースコード配置 • 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演算 • SingleInstruction 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.
- 43.
- 44. .NET vNextプロファイル • 今のプロファイル •デスクトップ向け • Windowsストア アプリ向け • (Phone, Xbox, Silverlight, …) • vNextのプロファイル • .NET Native向け • ストア アプリ向け － 事前ネイティブ化しにくいところ • Cloude Mode向け • GUI関連ごっそりない
- 45.
- 46. 実行環境の多様化 デスクトップ クライアント アプリ Phone/タブレット クライアント アプリ サーバーアプリ 既存資産 Mobile firstCloud first
- 47. Mobile first, Cloudfirst • Mobile: .NET Native • ストア サーバー上でのネイティブ化 • かなりアグレッシブな最適化付き • 一応、リフレクションも利用可能 • Cloud: .NET vNext Cloud Mode • side-by-sideインストール • ソースコード配置 • パッケージ管理
Editor's Notes
- #6 http://japan.zdnet.com/os/analysis/35051280/ いろいろな用途に対して一貫したモデルで開発できるのがMSの強みなのに、縦割りな仕事してどうすんだと。 社内競争で緊張感があったっていう利点もなくはなかっただろうけど。 チームというか、バルマーVSシノフスキー的対立がなかったらPhoneの立ち位置ももう少しましになってたかもしれず。 そういうところを改善しなきゃいけない。
- #8 とはいえ。 今、MSの好調な部門はOffice 365とAzureで、 シノフスキー(Phone系やってた)がさって、ナデラ(Azureな人)がCEOになり 元ノキア従業員を中心に18000人のリストラがあり Azureは開発的にもScotGuっていうカリスマが率いてて 割とパワーバランスはCloudの方によってると思う。.NETのイノベーションもCloud方面からの方が多きそう。
- #11 一度中間言語を挟むってこと自体は、たいていの言語がやってる。 コンパイラーの内部でだけ中間言語使うものとか、実行時のだけ使うものとかもあるけども。
- #15 http://msdn.microsoft.com/ja-jp/library/6t9t5wcf(v=vs.110).aspx インストールに時間がかかるってのもそれはそれで大問題。最初が肝心。いまどき、インストールってだけでも敬遠されるのに、さらに時間かかるとかかったるい。 ほんといまどきは「インストールしてください」ってあるだけでユーザーを9割失う。
- #16 逆に、使ってないもののネイティブ イメージを削除したりも自動 .NET Framework自体のインストールの遅さもかなり改善(.NET標準ライブラリ全部をNgenしない。Auto-Ngenのサービスに任せる)
- #21 http://blogs.msdn.com/b/msgulfcommunity/archive/2013/03/16/compile-in-the-cloud-with-wp8.aspx http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL
- #22 http://blogs.msdn.com/b/msgulfcommunity/archive/2013/03/16/compile-in-the-cloud-with-wp8.aspx http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL
- #24 P/Invokeとかのマーシャリングもコード事前展開
- #29 言葉を選ばずに言えば、Node.js的な実行形態
- #30 言葉を選ばずに言えば、Node.js的な実行形態
- #31 IDE連携が一番最初の大きな目的なんだけども、Cloud Firstな.NETでも大活躍
- #32 ライブラリどころか、ランタイム自体もクラウドのリポジトリからとってくるのよねぇ。 あと、どうも、Phone向けのMDIL生成ツールと同名のexe (crossgen)がK Runtimeに入ってるんで、パッケージの分はいったんMDIL化してそう。 毎回parseとか、毎回JITはしたくないんじゃないかと。
- #36 OWINは、デフォ状態で対応してるというよりは、ライブラリでUseOwin的な書き方したら対応できるって感じみたいだけども。