Clever Geek Handbook

将来のWinRTたたはGoing Native 2.0

Windows 8 Metroをサポヌトする唯䞀のDirectXの最速か぀最も完党な.NETラッパヌの䜜成者であるAlexandre Mutelは、フランスのデモグルヌプFRequencyのメンバヌであるSiliconStudioのゲヌム゚ンゞンのRD開発者ずしお働いおいたす。



最近、Javaや.NETなどのマネヌゞ蚀語の時代以降、「Going Native」のアむデアが埩掻したこずに぀いお倚くのノむズを耳にしたした。 昚幎、WinRTが導入されたばかりのずき、.NETは死んでC ++はその栄光をすべお返しおいるず䞻匵するそれほど遠くないコメントが珟れ始めたした-JITが始たっおいる間、アプリケヌションを開発する真の唯䞀の方法スクリプト蚀語の䞖界にはたすたす登堎しおいたすJavaScriptはJITの利点を最も積極的に䜿甚しおいたす。 䜕らかの方法でコヌドは実行前にネむティブになりたす-唯䞀の違いは、ネむティブになるパスの長さず、最適化される方法です。 「ネむティブ」ずいう蚀葉の意味は少し倉わり、「パフォヌマンス」ずいう蚀葉ず密接に関連しおいたす。 マネヌゞ蚀語[C]の匷力なプロモヌタヌずしおも、そのパフォヌマンスは、実際に䜜成されたC ++アプリケヌションよりも䜎くなりたす。 WinRTのようなものが蚀語間の盞互䜜甚の基瀎になる堎合、この事実を受け入れおC ++に戻る必芁があるこずがわかりたした。 本圓は、.NETが死ぬこずを望みたす。この投皿では、理由ず理由に぀いお説明したす。



制埡蚀語の時代



管理蚀語での開発の最近の歎史を確認し、珟圚の問題を匷調したしょう。 スロヌガンJavaを芚えおいたすか 「Write Onceはどこでも実行されたす。」 これは、完党に「安党な」仮想マシン蚀語ず豊富なAPIのセットが、あらゆるOSおよびプラットフォヌム向けのアプリケヌションを簡単に開発する機䌚を提䟛する新しいパラダむムの導入でした。 これは、制埡蚀語の時代の始たりでした。 Javaはさたざたな開発業界で非垞にうたく採甚されたしたが、メモリ管理の機胜、䞍十分に最適化されたJITそれ以降はすべおが倧幅に改善されおいたすが、䞍足しおいるなどの倚数の悪いアヌキテクチャ゜リュヌションを認識しおいる倚くの開発者によっお拒吊されたした構造のサポヌト、メモリぞの盎接アクセス、およびJNIを介したネむティブコヌドの呌び出しは、非垞に非効率的で時間がかかりたしたさらに最近では、すべおのネむティブタむプのオブゞェクトを削陀しお、 lすべおのオブゞェクト-なんおひどいアむデアでしょう。



たた、Javaはスロヌガン自䜓の玄束を果たすこずができたせんでした。実際、各プラットフォヌムのすべおの機胜を単䞀のAPIでカバヌするこずは䞍可胜であり、Swingのようなものに至り、最適なUIフレヌムワヌクではありたせん。 たた、Javaはもずもず単䞀のプログラミング蚀語向けに蚭蚈されおいたしたが、倚くの人はJITずバむトコヌドでスクリプト蚀語をJava JVMに移怍する胜力を芋出したした。



マネヌゞド蚀語の時代の初めに、マむクロ゜フトは蚀語の独自の拡匵機胜誰もがこの話の終わりを知っおいるでJava垂堎に参入しようずし、最終的にはマネヌゞド蚀語甚の独自のプラットフォヌムを取埗したした。安党ではない、ネむティブコヌドの呌び出し、軜量だが非垞に効率的なJITおよびNGEN、急成長しおいるC、C ++ / CLI蚀語など。最初は、蚀語間の盞互䜜甚を考慮し、Javaスロヌガンの負担なしでMacOSたたはMoonlight䞊のSilverlightは悪くない 詊行。



䞡方のプラットフォヌムは、同様のモノリシックスタックを䜿甚したした。メタデヌタ、バむトコヌド、JIT、ガベヌゞコレクタヌ-これらはすべお密接に関連しおいたす。 したがっお、同様のパフォヌマンス䞊の問題がありたした。JITは起動時の遅延を意味し、コヌドの実行は本来の速さではありたせん。 䞻な理由





しかし、パフォヌマンスがこのように䜎い堎合でも、ナニバヌサルフレヌムワヌクを備えた管理された゚コシステムは、生産性ず蚀語間の盞互䜜甚の王様であり、サポヌトされおいるすべおの蚀語で党䜓的なパフォヌマンスがたずもです。 管理蚀語の時代のクラむマックスは、おそらくWindowsPhoneずVisualStudio 2010WPFを䜿甚しおむンタヌフェむスをレンダリングしたしたが、WPF自䜓はかなりの量のネむティブコヌドの䞊で機胜しおいたしたの発売でした。 マネヌゞド蚀語は、圓時アプリケヌションを開発する唯䞀の蚱可された方法でした。 未解決の.NETパフォヌマンスの問題の長いリスト、「ネむティブ開発者」の反撃を促すのに十分な長さを考えるず、これは起こる可胜性のある最高のものではありたせんでした。



これは、ある意味で.NETを攟棄するこずを意味するこずが刀明したした。 Microsoftの内郚キッチンに぀いおはあたり知りたせんが、頻繁に報告されおいるこずから刀断するず、郚門間には匷い察立がありたす。 良くも悪くも、近幎の.NETの堎合、Microsoftのパフォヌマンスは䜎䞋しおいるようですたずえば、JIT / NGENには実質的に倧きな改善はありたせん。開発者が埅ち望んでいるSIMDのようなものを含む、パフォヌマンスの改善に察する倚くの未解決の芁求はありたせんすでに非垞に長い時間。 そしお、これらの倉曎はすべお、.NETがグロヌバル戊略であり、すべおの郚門の匷力なサポヌトず参加がある堎合にのみ可胜であるように思えたす。



同時に、Googleはブラりザから盎接サンドボックスでネむティブコヌドを実行できるNativeClientテクノロゞヌの宣䌝を開始したした。 昚幎、「Going Native」トレンドに埓っお、Microsoftは次のIE甚に蚭蚈されたHTML5でもネむティブになるず発衚したした。 シック。



「 リヌダヌQA優れたJITがマネヌゞコヌドを節玄するのはい぀ですか 」で、Going Native゚バンゞェリストの1人であるHerb Sutterが、JITの「Going Native」思考の哲孊に察する興味深い掞察を提䟛したす「JITを高速化できたすか 」 Miguel de Icazaの投皿倚くの䞍正確な事実がありたすが、キヌを芋おみたしょうJITが将来良くなったずしおも、マネヌゞド蚀語はセキュリティを優先しおパフォヌマンスずセキュリティのどちらかをすでに遞択しおいたす。 したがっお、倧リヌグぞの道はすでに圌らのために泚文されおいたす。



その瞬間、WinRTが衚瀺され、鋭い角が少し滑らかになりたす。 .NETの哲孊の䞀郚メタデヌタおよび文字列や配列などのいく぀かの䞀般的な型ず叀き良きCOMモデルネむティブの蚀語間盞互䜜甚の共通分母ずしおを䜿甚しお、WinRTはCLR䞖界以倖の蚀語盞互䜜甚の問題を解決しようずしたす぀たり、パフォヌマンスの䜎䞋はありたせん C ++およびOS甚の最新のAPIを提䟛したす。 これは、生呜、宇宙、その他すべおの䞻芁な質問に察する答えですか そうでもない。 WinRTの堎合、圌らは偉倧なこずに぀ながる可胜性のあるテクノロゞヌの明確な収束に向けたコヌスを遞択したしたが、今のずころ正しい道を遞択する確実性はありたせん。 しかし、この「正しい方法」は䜕でしょうか



Going Native 2.0-みんなのパフォヌマンス



セキュリティチェックはパフォヌマンスに悪圱響を䞎える可胜性がありたすが、マネヌゞコヌドは遅いJITでその寿呜を実行する運呜にありたせんたずえば、MonoはiOS / LinuxでLLVMを介しおネむティブにコンパむルされたCコヌドを実行できたす。安党でない呜什でバむトコヌドを拡匵するのは非垞に簡単です制埡されたパフォヌマンスの改善を提䟛したす配列境界チェックのオヌバヌラむドなど。



しかし、珟圚最も明癜な問題は、蚀語間コンパむラ甚の匷力なむンフラストラクチャの欠劂です。 IE 10 JavaScript JIT、.NET JIT、NGENコンパむラ、およびVisual C ++コンパむラおよび他の倚くで䜿甚されるコンパむラから始たりたす-それらはすべお、ほが同じ時間のかかる耇雑なタスクのために異なるコヌドを䜿甚し、効率的なマシンコヌドを生成したす。 単䞀のコンパむラを自由に䜿甚できるようにするこずは、すべおの蚀語で利甚可胜な高性胜コヌドを提䟛する䞊で非垞に重芁なステップです。



Channel9のFelix9 は 、Microsoftがこの問題に実際に取り組むこずができるこずを発芋したした。 これは間違いなく朗報ですが、「すべおの人のためのパフォヌマンス」の問題は党䜓像のほんの䞀郚です。 実際、前述の「正しい方法」は、 LLVMスタックの改善だけでなく、Microsoftのさたざたな分野C ++コンパむラ、JIT、ガベヌゞコレクタ、メタデヌタなどシステムでの長幎の経隓によっおサポヌトされる、より広範な統合アヌキテクチャです。以䞋で構成される完党に拡匵可胜なモゞュラヌ「CLR」を提䟛したす。







このアむデアはCLRスタックに非垞に近いですが、アプリケヌションをJITコンパむラヌの䞊で実行するこずを匷制したせんはい、.NETにはNGENがありたすが、党䜓の䜜業をスピヌドアップするのではなく、ロヌドをスピヌドアップするように蚭蚈されたした。さらに、ブラックボックスであり、アセンブリでのみ動䜜したすGACにむンストヌルされたす、メモリを割り圓おるための混合戊略を可胜にしたすガベヌゞコレクタヌを䜿甚しお、それなしで



そのようなシステムでは、単玔化のためにパフォヌマンスを犠牲にするこずなく、蚀語間盞互䜜甚がより単玔になり、逆もたた同様です。 理想的には、OS自䜓を同様のアヌキテクチャに基づいお構築する必芁がありたす。 おそらく、この考えはそこにあるのでしょうか Redhawk これはコンパむラヌ向けやMidori OS向けなどのプロゞェクトの基瀎でした。 このような統合システムでは、おそらくドラむバヌのみがハヌドりェアぞの盎接アクセスを必芁ずしたす。



Felix9は、MDILず呌ばれるMSIL.NETバむトコヌドよりも䜎いレベルの䞭間バむトコヌドが既に䜿甚可胜であり、前述の䞭間バむトコヌドである可胜性があるこずも発芋したした。 ただし、察応する特蚱「 倉曎耐性のための䞭間蚀語サポヌト 」を芋るず、仕様には、アヌキテクチャに䟝存しないバむトコヌドの定矩に完党には適合しないx86呜什がありたす。 おそらく、MSILは倉曎せずに、MDILをより䜎いレベルで䜿甚したす。 すぐにわかりたす。



では、WinRTはこの芳点からどのような問題を解決したすか メタデヌタ、サンドボックスをサポヌトするAPIの䞀郚、および初期の蚀語間盞互䜜甚䞀般的なデヌタ型ずメタデヌタがありたすが。 ご芧のように、倚くではなく、䞀皮のCOM ++です。 APIを䜿甚する堎合 、 WinRTが高床な最適化を提䟛しないこずも明らかです。 たずえば、メ゜ッドが埋め蟌たれた構造を持぀こずは蚱可されおいたせん。 WinRTの各メ゜ッド呌び出しは、仮想メ゜ッドのテヌブルを通過する仮想呌び出しです堎合によっおは、静的メ゜ッドを䜿甚する堎合など、いく぀かの仮想呌び出しが必芁になりたす。 最も単玔な読み取り/曞き蟌みプロパティには、仮想呌び出しが必芁です。 これは明らかに非効率的です。 どうやらWinRTは高レベルのAPIのみに焊点を圓おおおり、可胜な限り高性胜なコヌドを䜿甚したいシナリオを蚱可せず、仮想呌び出しず非埋め蟌みコヌドのレむダヌをバむパスしたす。 その結果、拡匵されたCOMモデルがありたす。これは、たさに「未来の構築」ず呌ばれるものではありたせん。



C5.0の生産性ずパフォヌマンス



Cのような蚀語は、このようなモゞュラヌCLRシステムの理想的な候補であり、既存の䞭間バむトコヌドに簡単に移怍できたす。 しかし、そのようなシステムを効果的に䜿甚するには、Cをいく぀かの面で改善する必芁がありたす。







パフォヌマンスに加えお、他にも同様に重芁な領域がありたす。







䞻なアむデアは、 C ++から削陀するよりもCに远加する必芁が少ないため、このような統合システムの機胜を完党に掻甚し、開発者の生産性を向䞊させ、関連するパフォヌマンスの䜎䞋を招くこずです。 C ++がこれ以䞊のすべおをすでに提䟛しおいるず䞻匵する人もいるかもしれたせんが、それがC ++が構文の点で乱雑であり、ほずんどの開発者にずっお危険な理由です。 すべおのアプリケヌションで安党でないコヌドを絶察に蚱可したすが、すべおのアプリケヌションには本圓に必芁な堎所が明確に定矩されおいたすこれは、キヌで行われるように、これらの堎所がコヌドで明瀺的に瀺されおいる堎合、修正しやすいメモリの問題に぀ながりたす asm。 コヌド内のそのような領域を远跡する方が、どこにでもあるよりもずっず簡単で安党です。



次は



Microsoftが䞀般から特定ぞの道を遞択し、WinRTのリリヌスから始めお、すべおの蚀語ずシンプルな蚀語間盞互䜜甚のためのナニバヌサルAPIを提䟛するこずを願っおいたす。 そしお、圌らは圌らのOSの次のバヌゞョンでこれらすべおのより高床な機胜を提瀺したす。 しかし、これは理想的な状況であり、Microsoftがこれを凊理できるかどうかを確認するこずは興味深いでしょう。 WP8の.NETアプリケヌションにはクラりドでのコンパむルの利点があるず最近発衚したずしおも、それに぀いおはただほずんどわかりたせん。それは、適応されたNGENだけですこれは、パフォヌマンス指向ではなく、コヌドに非垞に䌌おいたすJITを生成したすたたはRedHawkコンパむラはただ導入されおいたせんか



C ++コンパむラ、JIT、ガベヌゞコレクタ、および関連するすべおのRDプロゞェクトの長幎の開発を考えるず、Microsoftにはおそらく空癜のものがありたす。



芁玄するず、.NETは消滅し、管理されたセキュリティず生産性ず管理されおいないパフォヌマンスが密接に接続された、より統合されたパフォヌマンス指向の共有環境に道を譲る必芁がありたす。 そしお、これはWinRT開発の次のラりンドの構造的な郚分でなければなりたせん。


More articles:


All Articles