Microsoft、C#コードをネイティブコードにコンパイルする「.NET Native」を発表 130
発表 部門より
MicrosoftがC#で書かれた.NET Framework向けのプログラムをネイティブコードにコンパイルする「.NET Native」を発表した。現在Preview Release版が公開されている(.NET Framework Blogの記事、 Microsoft .NET Native、 Microsoft .NET Native FAQ、 Compiling Apps with .NET Native、 本家/.)。
C#などの.NET系言語では、コードをコンパイルすると中間コードが生成され、実行時にネイティブコードに変換されるという仕組みを取っていたが、.NET Nativeを使えばC/C++による開発と同様にネイティブコードを生成でき、アプリケーションの起動速度の高速化やメモリ消費の削減といったメリットを享受できるという。対象アーキテクチャは現在のところx64およびARMで、x86は今後対応する模様。また、当初はWindowsストアアプリ(いわゆるMetro UIベースのアプリ)の作成にのみ利用できるが、長期的にはデスクトップアプリなどすべての.NETアプリに対象を広げていくとのこと。Windowsストアアプリの多くがC#を使用しているため、Preview Release版ではC#コードだけをサポートしているが、.NET Nativeの対象を広げていく際にはF#やVBなど他の.NET言語に対応する可能性もあるようだ。
.NET Nativeを使用することで、Windowsストアアプリが最大60%高速に起動し、メモリー使用量が15%～20%減少するという。また、.NET Frameworkの必要な部分が静的にリンクされるため、実行環境の.NET Frameworkには依存しないとのことだ。
なぜC＃のみ？ (スコア:2)
.net全部とならないのが不思議
まぁくそ遅いデスクトップアプリが少しでもまともにになってくれれば良いね
でも例外はいたときの情報どうなるんだろうね？がっかりじゃなきゃいいけど
Re:なぜC＃のみ？ (スコア:5, 参考になる)
C#でもすべての機能をサポートしているわけではないらしい。
というか、以前から話に出てたクラウドコンパイルを外向けに公開しただけの話のような...
この辺参考にした。
http://ufcpp.wordpress.com/2014/04/03/net-native/ [wordpress.com]
Re:なぜC＃のみ？ (スコア:2)
C#の理由はMicrosoft .NET Native FAQ [microsoft.com]の1個目に書いてありますね。C#以外は将来に期待ということで良いのではないでしょうか。
Re: (スコア:0)
今はWindowsストアアプリにしか利用できないそうだよ
Re: (スコア:0)
今どきC♯でくそ遅いデスクトップアプリって間違いなく開発者（コード）の方が問題でしょ？
くそ遅いJavaで作ってるアプリの方がどうにかして欲しい
Re:なぜC＃のみ？ (スコア:1)
すくなくともJavaでなら、下手にAOTコンパイラでネイティブコード作るより、
HotSpotVMで実行時最適化した方が効率がいいから。
AOTコンパイラが廃れたのはそういう理由。
だからC#用としてもとっても今さら感があるし、使うメリットについてもすごく疑問。
Re: (スコア:0)
AOTコンパイルでも実行時プロファイルを取るとかして、JIT相当の最適化を行うことはできると思うんだけどね。
Re: (スコア:0)
Javaアプリはクソ重いけど、.NETアプリが重かったのってv2.0ぐらいまででしょ。
Re: (スコア:0)
.Netが重いというよりWPFがクソ重いよ。
Re: (スコア:0)
なんででしょうね。同じ中間コードで、同じように実行時にネイティブコードにするのだから、同じように事前にネイティブコードにすることができそうなものだけど。
Re: (スコア:0)
無いわけでもない
http://msdn.microsoft.com/ja-jp/library/hh691779(v=vs.110).aspx [microsoft.com]
めんどくさい (スコア:2)
既存のバイナリでも嬉しくなるように、普通に起動時間を短くしてよ。
Re:めんどくさい (スコア:1)
インストーラーがセットアップで ngen 通していればセキュリティーチェックだなんだとか、諸々含めた検証を通した後のネイティブイメージをシステムに登録してくれるし、ちょっとしたツールとかでも利用頻度高いなら (置きたい場所に置いた上で) ngen 通しておくだけでも幸せになれると思うのですが。(パスとシグネチャーをベースに ngen 後のイメージを利用するかを確定したはずなので)
アプリがでかすぎて ngen イメージ確定までに時間かかるって話だったら、そもそも作りを見直した方が良い気がします。(.NET の exe ってかなり小さいし)
そこまでやった上で遅いっていうことなら、多分 .NET がどうこうっていう以前のレベルでシステム側の遅さが問題なんじゃないかと。
# .NET Framework の更新で ngen にアホみたいに時間がかかる話の方が余程……。
Re:めんどくさい (スコア:1)
関連ライブラリの検証まで行うので遅くなるのよ。最悪の場合は署名の失効確認をネットに見に行ってとやるので。
4.0以降はかなり改善された。
がんばれ (スコア:1)
#なんかやたら皮肉が多いな。
まあそれはそれとして、最初に機能性(さらには言語)が制限されてるのは、GC動作とかJIT/VM/などで動いていることが前提になるとか関係する系とかとの作業量トレードオフかなぁ...
他の言語でもそうだけど、なかなか大変だろうな、がんばってほしい。
M-FalconSky (暑いか寒い)
いまさらC# (スコア:0)
Re: (スコア:0)
マルチプロセッサの有効活用
http://msdn.microsoft.com/en-us/library/vstudio/dd460693(v=vs.100).aspx [microsoft.com]
SIMD対応
http://blogs.msdn.com/b/clrcodegeneration/archive/2014/04/03/ryujit-ct... [msdn.com]
アクターモデル
http://blogs.msdn.com/b/dotnet/archive/2014/04/02/available [msdn.com]
Re: (スコア:0)
> これからは並列、並行処理を楽に書ける言語が求められると思う。
だったらC#とF#両方既にでてるんだからいいだろ
キチガイさんか?
関数型言語は並列化に あんまり向かない。 (スコア:0)
参照透過性があろうと、副作用が無かろうと、y=F(x)のyは、xが決まらなければ計算できない。
関数型言語はコンパイラが依存関係を解析しやすいから「自動」並列化がしやすいというだけ。
手続き型言語で並列化できない処理が、関数型言語で並列化できるようになるわけじゃない。
速度を求めないなら、オブジェクト毎にスレッドを割り振って、イベントドリブンで処理させんのが分かりやすい。
Re: (スコア:0)
それは30年くらい前の認識ですね
C#とF#はできることは基本的には同じだけど、F#のほうがはるかに強力な言語サポートがあるのです
Re: (スコア:0)
タイムマシンは実在したのか....
静的リンク (スコア:0)
Joel on Softwareの「申し訳ありませんが、リンカをいただけないでしょうか？ [joelonsoftware.com]」
（日本語訳は書籍版に収録）で要望されていたことが、ようやく実現に向かい始めたわけだ。
Re:静的リンク (スコア:1)
Xamarinが仮想マシンを許可しないiOS向けに開発した技術とほぼ同じだね。
歓迎する理由 (スコア:0)
実行速度の上昇よりもアセンブリからソースコードが簡単に読めなくなることが嬉しいって人も多いと思う
ポインタが無いのでC++で作成するよりは容易だろうけど難読化で誤魔化すよりはクラックされにくくはなるだろうし
Re: (スコア:0)
C#にもポインタあるよ
C#でOSが作れるな (スコア:0)
え？
Re:C#でOSが作れるな (スコア:1)
Microsoft，タイプセーフなオペレーティングシステム Verve を発表 [infoq.com]
Re: (スコア:0)
今まではできなかったんですか？
Re: (スコア:0)
Cosmos「呼んだ？」
RTをオワコンにする気？ (スコア:0)
Windows8では動いてRTでは動かないnativeストアアプリが氾濫してエコシステムがいきなり崩壊する予感がするんですけど。
パフォーマンスがシビアなもののぞいて非推奨にしておいてくれるよね？
Re: (スコア:0)
x64とARMと言う事なんで、どっちかってーと非力なRTでの高速化技術なんじゃね？
むしろx86を切りたいんじゃ。
#Phone? 知らない子ですね…
Re: (スコア:0)
WindowsPhoneもARM対応してるならカバーできるのでは
Re: (スコア:0)
あっちはフルセットの.NET Frameworkではなくて、Compactってつく方だからどうかなーって…。
もともと直接的な互換が無いですし。
Re: (スコア:0)
そういうことでしょう。
RTを存続するメリットが誰にもない気がする。
Re: (スコア:0)
Phoneがあるだろ...
Re: (スコア:0)
FAT Binary の時代キタな。
Re:RTをオワコンにする気？ (スコア:1)
同時にマルチアーキテクチャー/エンディアンなバイナリーという話がございまして。
# Alpha for Windows NT とかその辺を思い出しましたが。
Re:10年遅かったかな (スコア:1)
> ネイティブのObjective-C一本でOSXからiOSまで
> 書けちゃう統合されたAPI&フレームワーク
そんな架空の存在を持ち出されても。
Re:10年遅かったかな (スコア:1)
Process Explorer [microsoft.com]だと.netプロセスが色分けされて表示されるから、いろいろなアプリを起動して見ると面白いかも
Re: (スコア:0)
あなたが知らないだけで使われまくってるぞ。.NETは。
Re: (スコア:0)
根拠いるの？
じゃあ、「たいして普及しなかった」と同じやつで。
Re:10年遅かったかな (スコア:1)
Office？ブラウザ？世界で10程度しか存在しないものを挙げて数の勝負を挑むの？インストール数の勝負だったっけ？ストアアプリでも検索してくれば？
ちなみにOfficeもONE Note連携とかSharePoint関連では.NET必須。
あとはstackoverflowのC#タグが最上位ってのも一つの目安になるのでは。
Re:10年遅かったかな (スコア:3)
はい、どうぞ。
ASP.NET Case Studies [microsoft.com]
Case Studies [microsoft.com]
これはASP.NETかつMicrosoftに公表する許可を出したサイトだけなので、.NET全部だともっと多いですよ。
Re:10年遅かったかな (スコア:1)
MPLAB は最新版で NetBeans ベースになったから外してくんない？
Re: (スコア:0)
阿呆すぎて逆に微笑ましいレベル。
Re: (スコア:0)
#2576496といい、卓越したブーメラン使いだな。
Re: (スコア:0)
遠隔操作ウィルスにも利用されたというくらい普及しているのに。
Re:10年遅かったかな (スコア:1)
C# で C/C++ な DLL とかが直接呼べなかったら、そもそも .NET Framework が Windows (Win32 API) の上に構成できる訳がないんですが、何言ってるんですか?
すべてのコードを純粋なマネージドコードのみで完結した場合の最大のメリットはどのようなアーキテクチャーやエンディアンになっているかを問わない事。
アンマネージドの世界に足突っ込むなら C/C++ で書かれたコードをアーキテクチャーやエンディアンに縛られながら、システムコールをダイレクトに叩くコードとか普通に書けますよ。
保守性の面などからも、普段はあまり好まれるような記述方法ではありませんし、クロスプラットフォームと言う点では「当たり前だけど、アーキテクチャーやエンディアンの違いですべてライブラリーを作り直す必要がある」ネイティブコードを「現代のクロスプラットフォーム」と評価する発想は、ちょっと良く分かりませんけど。
Re:10年遅かったかな (スコア:1)
普通業務用アプリではマイナーなライブラリ呼び出したりしないので。
Re:MSはWindowsストアアプリ(ひいてはWindowsタブレット)を普及させたいだけ (スコア:1)
MSはWindows ストアアプリを普及させたいだけなんじゃないの。
何か問題でも?