More Related Content
今から始める、Windows 10＆新.NETへの移行戦略 2014 03-15 業務アプリinsider ソフトウェア方面の先進テクノロジー dotnetconfJP2017_netcore2 What's hot (20)
.NET Coreから概観する.NETのOSSへの取り組み .NET の今と未来 ～ デバイス＆クラウド ネイティブを目指して パターンでわかる! .NET Coreの非同期処理 Linux & Mac OS でも動く！ ～ オープンソース & クロスプラットフォーム .NET の歩き方 ～ Javaで1から10まで書いた話(sanitized) 【Unite Tokyo 2019】大量のアセットも怖くない！～HTTP/2による高速な通信の実装例～ Angular ユーザーなら押さえておきたい！ TypeScript と Visual Studio Code の基礎と活用 Visual studio 2015 update1 ctpとcsi Introducing Fluent Design わんくま名古屋 #37 (20151114) TDD道場 #25 Async deepdive before de:code .NET Conf 2017 Japan Keynote ".NET Everywhere!" Visual Studioで始めるTypeScript開発入門 Similar to .NET vNext (20)
～ Cloud First から Cloud Optimized へ ～ .NET on Cloud が描くモダナイゼーション Cloud から IoT まで、なんでもおまかせ ～ .NET 5 正式リリース！ 今から始める、Windows 10＆新.NETへの移行戦略 Linux & Mac OS でも動く！ ～ クロスプラットフォーム対応に見る ASP.NET Core 5 の可能性 ～ Visual Studio 2019 GA ! ～ 最新情報 & これからの開発スタイル Dot netcore multiplatform 2 .NET の過去、現在、そして未来 ～ .NET 最新アップデート .NET Core と Container, そして Azure Web Apps on Linux による Web アプリ開発最前線 Visual Studio 2019 GA ! ～ 最新情報 & これからの開発スタイル ASP.NET vNext / Visual Studio "14" に見る .NET の未来像 .NET の今とミライ (.NET Conf 2018 Japan Keynote) 20140830 2014年版 C #でできること Empower Every App, Every Developer ～ 統合開発プラットフォーム Visual Studio の進化 ～ The Next Generation for C# Developers .NET Core 5 ～ Windows, Linux, OS X そして Docker まで ～ ASP.NET 新時代に向けて ～ ASP.NET 5 / Visual Studio 2015 基礎解説 More from 信之 岩永 (20)
C# 8.0 Preview in Visual Studio 2019 (16.0) C# 7.2 with .NET Core 2.1 Unityで使える C# 6.0～と .NET 4.6 Orange Cube 自社フレームワーク 2015/3 C#や.NET Frameworkがやっていること .NET vNext
- 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
- 10. 中間コードとJITコンパイル
• .NET Frameworkの中間言語
• 中間言語があることで
• 高級言語のコンパイラーを作る人と、CPUごとの最
適化する人の分業化
• セキュリティ チェックしやすい
• 動的リンク時に、コード修正の影響を吸収
• 動的な実行(リフレクション)
高級言語
(C#など)
中間言語
(IL)
ネイティブ
コード
コンパイル コンパイル
問題は「いつやるか」
- 12. 中間言語: デスクトップでは
利点
• 動的リンク・部分更新しやすい
• セキュリティ検証しやすい
• (ソースコード配布よりは)高速
欠点
• .NET Frameworkのランタイム インストール必須
• (ネイティブ配布よりは)低速
• (ソースコード配布よりは)デバッグ・修正が面倒
JITとかWindowsサービス巡回
とかでないと保証しにくい
PCの性能的に
許容範囲
なんだかんだいって
JITのメリットあり
JIT
そんなに頻繁な
修正しない
- 14. Ngen
• Ngen.exe (Native Image Generator)
• ILを事前にネイティブ化するためのツール
• 自前管理が必要
• アプリのインストーラー※とかを作って明示的に呼び出し
• 参照しているライブラリが更新された時には呼びなおす
必要あり
• かなり面倒なのでアプリを
Ngenすることはめったにない
• .NET自体が標準ライブラリの
高速化のために使ってる
※ 要するに、JITの負担を起動時じゃなくてインストール時に前倒しする
(最初期からある)
- 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)
- 26. 中間言語: サーバーでは
利点
• 動的リンク・部分更新しやすい
• セキュリティ検証しやすい
• (ソースコード配布よりは)高速
欠点
• .NET Frameworkのランタイム インストール必須
• (ネイティブ配布よりは)低速
• (ソースコード配布よりは)デバッグ・修正が面倒
アプリ稼働時間が長くて、
最初の1回だけのコストは
無視できる(低速でもいい)
開発機とサーバー機でバー
ジョンが違って困ることが
サーバー上で確認しつつ
その場でソースコードを修正したい
ソースコード配置
自動パッケージ管理
Cloud Mode
アプリごとに別バー
ジョンを使えない
- 27. .NET vNext Cloud Mode
• クラウド向けの実行形態
• side-by-sideインストール
• ソースコード配布
• パッケージ管理
(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)
- 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公開
- 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!
- 44. .NET vNextプロファイル
• 今のプロファイル
• デスクトップ向け
• Windowsストア アプリ向け
• (Phone, Xbox, Silverlight, …)
• vNextのプロファイル
• .NET Native向け
• ストア アプリ向け － 事前ネイティブ化しにくいところ
• Cloude Mode向け
• GUI関連ごっそりない
- 47. Mobile first, Cloud first
• 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的な書き方したら対応できるって感じみたいだけども。
![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/85/NET-vNext-19-320.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/85/NET-vNext-38-320.jpg)
