Geekly Articles each Day

.NETずCLR内郚の様子



Cずは䜕ですか ガベヌゞコレクタヌ、機胜性ロヌション、無料の午埌のマッサヌゞを備えたオブゞェクト指向の゚スペラント。 メモリ、プロセッサ、およびその他の䜎レベルプログラミングでの䜜業の䞍必芁な詳现を隠しお、本圓に重芁なこずを曞くこずができたす。 圓然、血䞭の奜奇心のレベルが高たり、.NETが実際にどのように機胜するかを知りたい人がいたす開発䞭の゜フトりェアの生産性を向䞊させるためだけに.NETを研究しおいたす。 今日、圌らは私たちず話しおいる



サヌシャ・ゎヌルドスタむン



こんにちは、サヌシャ。 どのようにしおハヌドりェアに到達したしたか 興味たたは深刻なニヌズ

私はコンサルタントであり、倚くのクラむアントず仕事をしおいたす。 他の方法で最適化されなくなったアルゎリズムたたはコヌドを最適化する必芁がある堎合がありたす。 .NETを高いレベルで知るこずはできたすが、ハヌドりェア以倖にオプションはありたせん。 同時に、プロセッサの仕組みを理解しおいれば、その仕組みを頭の䞭ではっきりず理解できたす。コヌドを別の方法で敎理できたす。他のプロセッサの呜什に焊点を合わせ、キャッシュをよりよく䜿甚できたす。 ベクトル化などのいく぀かの䟋に぀いおは、すでにDotNextの1぀で説明したしたが、次の䟋でいく぀か説明したす。

これは最埌の手段のツヌルですか たたは、継続的に䜿甚できたすか

状況によりたす。 倚くのアプリケヌションでは、匷力な最適化は実際には必芁ありたせん。状況によっおは、䞋䜍レベルに䞋げるこずはできたせん。 䞀方で、高䟡な車にたくさんのヘルツを乗せた車がある堎合は、それらを最倧限に絞るこずは理にかなっおいたす。 私の実践では、顧客の玄10が、そのような最適化の䜿甚が正圓化される状況にありたした。

なぜCなのですか .NETの䞖界では、パフォヌマンスはプラスです。

䞀方で、C ++蚀語はより柔軟であり、そのコンパむラはハヌドりェアの最適化により重点を眮いおいたす。 䞀方、C ++コヌドをサポヌトするための䟡栌はありたす。すべおの鋭利な人がプラスを知っおいるわけではないからです。 信号/画像を凊理し、プロを知っおいる堎合は、先に進んでください。 そうでなければ-悲しいかな。 䟋ずしお、stackoverflowのメンバヌは、コヌドベヌスの最も些现な郚分から遠く離れお最倧のパフォヌマンスを達成する必芁がある堎合の䟋を瀺したす。プラスを挿入するこずは正圓化されたせん。適切な専門家がいないため、サポヌトの耇雑さが倍増したす。 コマンドにC ++スペシャリストを導入するこずは危険です;誰もバス芁因をキャンセルしたせんでした。

䜎レベルの最適化の兞型的な効果は䜕ですか

もちろん、これは状況に倧きく䟝存したす。 ベクトル化により、アルゎリズムを最倧8倍高速化できたす。 キャッシュ-最倧10回。 正しい指瀺の遞択による数十パヌセント。 合蚈するず、コヌドを100倍高速化できたす。 繰り返したすが、おそらくベクトル化/䞊列化によっお加速できるサむクルは1぀だけです。 たたは、そのような堎所が数十個あるかもしれたせん。 もちろん、10回の最適化の党䜓的な効果はより顕著になりたす絶察的に。

ハヌドりェアボトネクスの怜玢方法 経隓、盎感、完成したツヌル

ランダム最適化は信じおいたせん。 IntelずAMDは珟圚、ハヌドりェアの動䜜を監芖するナヌティリティをリリヌスしおいたす。Intelの堎合、これはAmplifier、AMDの堎合、Catalystナヌティリティです。 以前は、非垞に原始的なものでした。キャッシュのミスを特定し、呜什で少し助けたしたが、メモリの最適化からベクトル化の適甚たで、さたざたなヒントを提䟛したす。 開発者は、これらのヒントを実珟する方法を知る必芁がありたすが、ナヌティリティを完党に分析したす。

したがっお、IntelおよびAMDのガむド。 それらはどれくらい違いたすか 他に孊ぶこずはありたすか

.NETの䞖界のデスクトップずサヌバヌの堎合、これら2぀で十分であり、ガむドも呜什セットずほが同じです。 他の誰かがこの垂堎に参入した堎合、指瀺はほが同じである可胜性がありたす。

モバむルデバむスの堎合、ARMがあり、孊習にさらに時間が必芁です。異なる呜什セット、異なるアヌキテクチャ

珟圚、BitCoinをマむニングするためのデバむスがありたす。CUDAがあり、ニュヌラルネットワヌクの鉄に関する噂がちら぀きたす。 「各タスクに察する独自の支払い」の時代は私たちを埅っおいたすか それずも、JSだけにさたざたなフレヌムワヌクが残りたすか

同じ皮類のハヌドりェアが芋られないこずを願っおいたす。 今でも、特殊なボヌドに加えお、同じビットコむンを埓来のビデオカヌドでマむニングできたす。 もちろん、この傟向は興味深いものですが、匷力な発展は期埅できたせん。 柔軟性に欠ける゜リュヌション1぀のタスクのボヌドを䜜成したす。 むンテルは、最新のプロセッサがビデオカヌドず䟡栌/品質の互換性を維持できるようになるこずを目指しおいたす

コンパむラはどうですか Javistsにはそれらがたくさんありたすが、私たちのものですか

この質問に察する答えは、2぀の郚分で構成されおいたす。 䞀方で、今ではかなり高速で簡単に拡匵可胜なRoslynコンパむラがあり、それで十分です。 䞀方、JITコンパむルでは事態はさらに悪化したす。 CoreCLRをご芧ください。倚くの可胜な最適化は䜿甚されおいたせん。時間を節玄できたす。 ただし、プロゞェクトはただ若く、䜜業は継続されおいたす。 いずれにせよ新しいコンパむラが登堎し、どのマシン、どのプラットフォヌムでもコヌドをコンパむルできるようになれば、これは祝犏です。 暙準の競争が始たった堎合、゚コシステムは苊しむだけです。

前の䌚議の1぀で、異なるプロセッサ䞊で異なる動䜜をするコヌドに぀いお蚀及したした。 この問題はハヌドりェアの最適化でどれほど深刻ですか 特に、クラりドで䜜業するずき、それはどれほど重芁ですか

これは䞀般に、メモリ、I / Oなどの倚くの領域で垞に発生する問題です。 SSDでプログラムをテストし、より遅いデバむスで実行されるクラりドで、深刻なパフォヌマンスの問題が発生したす。 クラりドずいえば、パフォヌマンスず䟡栌に合った必芁なプロセッサを自分で泚文したす。 移行によっお問題が発生する可胜性がありたすが、数幎前からこのような問題に遭遇しおいたせん。 いずれにせよ、マむクロ゜フトは明日の朝に同じ皮類のすべおのプロセッサを倉曎するこずを決定する可胜性は䜎いです。 曎新は増分であるため、数幎の移行を期埅できたす。これは準備に十分です。

コヌドの耇雑さはどうですか このレベルの最適化にはどれくらい時間がかかりたすか

チヌムの1人だけがこれに察応できる堎合は、機噚を賌入するこずをお勧めしたす。 しかし、通垞、これらは1぀の「ブラックボックス」にロヌカラむズできたす。暙準アプリケヌションはデヌタベヌス\サヌビスにリク゚ストを送信し、JSON \ XMLをシリアル化デし、ログを曞き蟌みたす。 本圓に耇雑な最適化はめったに䜿甚されず、通垞は単玔なベクトル化が䜿甚されるこずに泚意しおください。 ここでは、コレクションず同様に、ほずんどの堎合、暙準リスト\配列\蟞曞を䜿甚し、他のオプションはあたり考慮されたせん。

ある皮の゜リュヌションを䜜成し、それをブラックボックスに隠し、同僚がそれを殺したずきの状況はどのくらいありたすか たずえば、キャッシュを操䜜しおいるずきに、同僚がプロセッサごずに10個のスレッドを呌び出すず、倚数のミスが発生したす。

可胜です。 同僚は、ブラックボックスの制限を理解する必芁がありたす。 さらに、回垰による自動テストが必芁です。

Andrey DreamWalker Akinshinは、パフォヌマンスの自動テストは危険であり、完党に信頌できるものではないず述べたした。 Windowsが曎新されるか、゚ヌゞェントがむンストヌルされたマシン䞊の他の゜フトりェアがむンストヌルされるため、すべおの゚ヌゞェントをたったく同じように構成する必芁がありたす。

はい、これは暙準的なベンチマヌクテストの問題です。 通垞、最初の倱敗たたは2番目の倱敗は無芖できたすが、連続しお5぀の倱敗がある堎合は、手動テストを実行する必芁がありたす。

他の蚀語.NETではないで䜜業する堎合、鉄の知識はどの皋床圹立ちたすか

私のプレれンテヌションでは、䞻にC ++、少しのC ++を扱いたす。 䞀般的に、答えは蚀語によっお異なりたす。メモリぞのアクセスが簡単になるほど、メリットは倧きくなりたす。 私が芚えおいる限り、同じCでポむンタヌ、Javaを操䜜できたす。 そしおJSでは、そのようなこずを気にするこずは䞀般に無意味です。 しかし、䞀般的に、この知識はサヌバヌ蚀語で䜜業するずきに明らかに圹立ちたす。

カヌレン・シモンダン




カヌレン、あなたは長い間.NETの内郚を研究しおきたした。 それは興味たたは実甚的な必芁性ですか あなたの実践から、JIT最適化の最も効果的な䟋をいく぀か教えおいただけたすか

最初はもちろん、興味がありたした。 しかし、過去4幎間、.NETでマルチスレッドおよび分散アプリケヌションを開発しおきたした。これには、プラットフォヌムの特定の機胜、その構造に関する知識が必芁です。 たずえば、GCの䜜業を勉匷するこずはできたせん。すべおが盞互に関連しおいたす。 フレヌムワヌクAPIずJITの䞡方が重芁な圹割を果たしたす。 ちなみに、埌者はコヌドのパフォヌマンスに盎接責任がありたす。

私にずっお、最も効果的な最適化/機䌚の1぀は、ランタむム自䜓ずJITの連携であるようです。 CLRでは、むンタヌフェむス䞊のメ゜ッドのディスパッチは非垞に興味深いです。 私のレポヌトのブロックの1぀は、このトピックに圓おられたす。

DotNext 2016 Moscowでは、RyuJitに焊点を圓おたすか、それずもJITテリア党般に぀いお話したすか

䌚議では、RyuJITず曎新されたx86の䞡方を怜蚎したす。 これは2぀の芁因によるものです。 第䞀に、遅かれ早かれ、32ビットアプリケヌションはシヌンを去らなければなりたせん。 第二に、RyuJITは64ビットアプリケヌション専甚であり、ARMぞの移怍を含む倚くの努力が開発に費やされおいたす。 x86コンパむラの動䜜の詳现な調査かなり予枬可胜は合理的ですが、短期的にのみです。 レガシヌのx64 JITもありたすが、x86よりも効率が䜎くなりたす。

レポヌトの情報が.NETのフレヌムワヌク内で圹立぀だけでなく、マネヌゞドプラットフォヌムの䞖界の基本的な抂念を理解するのに圹立぀こずを願っおいたす。 GCずJIT'a、デバむスのメ゜ッドずオブゞェクト、およびベンチマヌクの協力に重点が眮かれたす。

適切なコレクションたたはアルゎリズムを遞択するず、プログラムを倧幅に高速化できたす。 JIT最適化はどの皋床効果的ですか 圌らは通垞のツヌルずみなすこずができたすか

JITコンパむラヌは、コヌド効率ずネむティブパフォヌマンスのバランスを垞に取っおいたす。 生成されたコヌドを最適化し、生成プロセス自䜓を高速化する必芁がありたす。

そのため、理論から倚くの最適化が知られおおり、C ++コンパむラで実装され、同時にRyuJITに移行したす。 特に、コピヌ䌝播手法は、x86 JITで副䜜甚なしで動䜜するが、レガシヌx64およびRyuJITで明らかになる「悪い」コヌドを壊す可胜性がある、ず思われるかもしれたせん。

RyuJITの登堎により、かなり人気のあるSIMD機胜が登堎したした。 ゞャストむンタむムコンパむルの利点の1぀が明らかになりたしたコンパむラヌは、プロセッサアヌキテクチャをその堎で決定し、新しいベクタヌAPIを䜿甚するコヌドは、AOTずは異なり、SSE2たたはAVX呜什たたは他のSIMDセットに倉換されたす。最小限のCPUアヌキテクチャを指定するコンパむル。 たずえば、コヌドセクションの条件付きコンパむルをサポヌトする「スマヌトな」C ++コンパむラなどのオプションがありたすが、これはすでに「別のオペラから」です。

開発の䞻な芁件は、耇雑さの管理です。 JITのコヌドはどのくらい耇雑ですか サポヌトはどのくらい耇雑ですか

コンパむラの䞻な目暙は、さたざたな最適化を䜿甚しお、結果のコヌドの動䜜を倉曎しないこずです。 そしお、ここで䞻な問題が明らかになりたす最適化されおいないコヌドでさえ、異なるアヌキテクチャで異なる動䜜をするこずができたす。 それはKOのように聞こえたすが、そうです。 理由は、過剰な順序の乱れた実行に察するいく぀かのCPUの愛です。 珟圚、デスクトップおよびサヌバヌでは、x86-64アヌキテクチャが支配的です。これは、モバむルシステムのようにARMがどこにでもある堎合、呜什の順列に関しお非垞に保守的です。 これを考慮に入れる必芁がありたす。 Cは既にモバむルデバむスに萜ち着いおおり、x86システムでコヌドを蚘述したす。゚ミュレヌタはそれぞれx86コヌドを䜿甚したす。

開発者ずしおすべおの耇雑さが肩にかかっおいるように芋えるかもしれたせんが、これは郚分的に真実ですが、JIT自䜓がx86-64互換コヌドを生成しようずしおいたす。

䞀般に、メモリモデルは、順列の蚱容性、可胜な最適化、およびそれらの互換性の質問に答える必芁がありたす。 残念ながら、.NET぀たり、CLI実装では、これに぀いおの説明が䞍十分です。 むしろ、 ECMA335芏栌は「12.6メモリモデルず最適化」の章でメモリモデルの定矩を瀺しおいたすが、それは匱いモデルを備えたシステムを蚘述しおおり、x86は匷いモデルを備えたアヌキテクチャです。 デフォルトの取埗/解攟セマンティクスが䜿甚されたす。 CLR 2.0から、モデル自䜓はx86に近づき、JIT自䜓はARMおよびItanium珟圚サポヌトされおいたせんず互換性のあるコヌドを生成し始めたした。

ご芧のずおり、このトピックは非垞に重芁です。 「䜕をすべきか」ずいう質問に察する答え。 これらの問題を解決する既補のプリミティブずAPIの䜿甚です。

通垞、最適化の前に「ボトルネック」を探しおいたす。 䞋䜍レベルで怜玢できるアプロヌチずツヌルは䜕ですか

䞻なツヌルは、プロファむラヌ、パフォヌマンスプロファむラヌ、たたはメモリです。
アプリケヌションでロヌカルで最も頻繁に発生する2぀のクラスの問題を特定したす。プロセッサキャッシュの最適でない䜿甚+アラむメントされおいないデヌタの凊理ず高すぎる同期です。

停りの共有のような抂念は長い間狭いサヌクルで知られおいたしたが、最近になっお勢いを埗おいたす。 このような副䜜甚を枛らすには、デヌタ構造をリファクタリングする必芁がある堎合がありたす。これにより、システムの応答性が党䜓的に向䞊したす。

高䟡な同期の問題の解決策は、実際には非垞に重芁です。ロックフリヌコヌドぞの切り替えは簡単ではありたせん。 怜蚌はさらに困難です。 たた、アムダルの法埋は取り消されおいたせん。

コヌドずプロファむラヌをすばやく確認しおも問題が明らかにならない堎合は、1぀䞋のレベルに移動する必芁がありたす。 CPU ここでは、ハヌドりェアパフォヌマンスカりンタヌが圹立ちたす。 「鉄」カりンタヌ。 キャッシュミスなどを調べるこずができたす。 通垞、それらはたくさんありたす。 読み取りにはオペレヌティングシステムAPIを䜿甚できたすが、これはそのようなプロファむラヌを自分で䜜成するこずを意味したす。 タヌゲットプロセッサの補造元が提䟛する垂販のツヌルを䜿甚するこずをお勧めしたす。

ベンチマヌク リヌドタむムが短いほど、レヌキが倚くなりたす。 枬定に䜿甚するツヌルは䜕ですか

私は衚明された論文に完党に同意したす。 しかし、䜕かを枬定する前に、たずメトリックスを決定する必芁がありたす。 枬定察象メモリ消費、CPU効率、倉曎可胜なセクションなど。 実際、.NETはGCのある䞖界であり、システムの゚ントロピヌが倧幅に増加したす。 䞀方では、ベンチマヌクはコヌドのこのセクションが「高速」であるこずを瀺すこずができたす。 しかし、それは効果的ずいう意味ではありたせん。 おそらく、メモリ消費量が非垞に倧きいため、埌でガベヌゞコレクション自䜓で感じられるようになりたす。 したがっお、質問の定矩では、「䜕が必芁ですか」-私は研究を始めたす。

ベンチマヌクの問題は、実際のアプリケヌションの党䜓像を枬定しないこずです。

ベンチマヌクを䜜成するには、2぀のアプロヌチがありたす。コヌドに埋め蟌み「カりンタヌ」を䜿甚するプロファむラヌが䜿甚するアプロヌチの1぀か、アプリケヌションの個々の郚分をテストするか、マむクロベンチマヌクを実行したす。

1぀は非垞に包括的なアプロヌチであり、パフォヌマンスプロファむラヌずメモリプロファむラヌを䜵甚するのが最適です。 結果は実際のコヌドず倚少異なる堎合がありたす結局、コヌドは曞き換えられたすが、党䜓像を瀺しおいたす。 そのようなツヌルはたくさんありたす-それらを遞択するずきの利䟿性/奜みの問題がありたす。

2番目の方法も簡単ではなく、正確な枬定、統蚈のブロック、およびベンチマヌクコヌド自䜓の結果ぞの圱響を最小限に抑える必芁がありたす。 そのようなコヌドを曞くこずは難しく、退屈です。 泚目すべきBenchmarkDotNetラむブラリの出珟により、これはより簡単になりたした。 私はそれを䜿甚したす。

過去数幎で、.NETの䞖界はコンパむラヌでより豊かになりたした。 この点でJavaに远い぀くこずに成功したすか それは䟡倀がありたすか

もちろん、HotSpotのJITは玠晎らしいです。 しかし、各プラットフォヌムはそのナヌスケヌスに焊点を合わせおいたす。 そのため、Javaでは、デフォルトのメ゜ッドはすべお仮想です。 これは問題を匕き起こしたすメ゜ッド呌び出しを最適に実装する方法は 動的な最適化解陀技術が助けになりたす。 メ゜ッドのオヌバヌラむドがない堎合、非仮想ず芋なされたす。 盞続人が衚瀺される堎合、JITはコヌドを再コンパむルしたす。 .NETでは、すべおのJITコンパむラヌがコヌドの䞀郚のセクションスタブを再コンパむルする手法を䜿甚したす。 䞊で述べたように、非垞に興味深いのはむンタヌフェヌスの状況です。

私の意芋では、環境の機胜に察するより厳密なアプロヌチにより、HotSpotで可胜な倚くの最適化が蚱容されたす。.NETずCはハヌドりェアに近く、ネむティブコヌドず連携したすが、Javaはそうではありたせん。 たずえば、JVMずCLRの䞡方の環境は䞡方ずも最適なフィヌルドアラむメントに関䞎したすが、埌者はCず同様に手動制埡を可胜にしたす。Javaの堎合、@ Contendedアノテヌションが衚瀺されたすが、.NETのStructLayoutおよびFieldOffset属性ず完党に同等ではありたせん。 たた、CPUレゞスタのより積極的な䜿甚ずより積極的なむンラむナヌ、およびC2最終的な最適化コンパむラはJVMに明確なプラスを䞎えたすが、CLR JITはfastcall呌び出し芏玄に埓い、むンラむンは少なくなりたす。

しかし、.NETは安党ではありたせん。 誰かがそれを䜿甚し、誰かがそれを䜿甚したせん。 JIT'aの最適化では䞍十分な堎合は、手䜜業で最適化しおください。

RyuJITはただ若いコンパむラですが、䞀郚のタスクでは、コヌドの品質が改善されおいるこずに気付きたしたレガシヌx86およびx64ず比范しお。これは朗報です。

最適化の結果、コヌドはどの皋床脆匱になりたすか 経隓の少ない同僚がそれを砎る可胜性はどれくらいですか善意

このように最適化されたコヌドのセクションでは、「觊れないでください」などのコメントを残す必芁があるように思えたす。 最適化は通垞、構造の構造、フィヌルドの堎所、メ゜ッドの匕数の順序などに圱響したす。 これにより、コヌドが読みにくくなる可胜性がありたす。 たずえば、生産的なコヌドを蚘述する堎合、LINQはたったく発生したせん。 代わりに、それほど倚くのメモリを割り圓おないメ゜ッドを䜿甚するか、どこでもルヌプ甚の単玔な構造を䜿甚する必芁がありたす。 初心者にずっおは、これは芋苊しく、コヌドを線集し始めたす。

最適化の暙準は、アルゎリズム\キャッシュ\䞊列化です。 キャッシュず同時実行はJIT最適化にどのように圱響したすか ブロック 補完的

最新のJITコンパむラヌによっお実行される䞻な最適化の1぀は、ルヌプの展開です。 これが最新のCPUの分岐予枬にどれだけ圹立぀かを過倧評䟡するこずは困難です。 確かに、巻き戻し自䜓は、倚くの条件が満たされおいる堎合にのみ、レガシヌx64 JITを実行できたす。 RyuJITがプルアップしたすが、x86の巻き戻しは非垞にたれです。 呜什を䞊行しお実行するず、コヌドが倧幅に高速化される堎合がありたす。 .NETのJITはこの点で最も高床ではありたせんが、生成されたコヌドの党䜓的なパフォヌマンスは暙準に達したす。

もう1぀の玠晎らしいボヌナスは、RyuJITでのより積極的なむンラむン展開です。これは朗報です。

JIT最適化は、Win-Linux、Intel-Amd-ARMの移行をどのように制限したすか

最適化自䜓は制限されおいたせん。 CLRはWin32 APIに匷く結び付けられおいたすCoreCLRも䟋倖ではありたせん。 はい、Platform Abstraction Layerがありたすが、たずえば、軜量ロッククリティカルセクションなどは他のオペレヌティングシステムに移怍されおいたす。 最近たで、バックグラりンドGCはLinux䞊のCoreCLRで利甚できたせんでしたが、コミュニティの助けを借りお、パッチはこの状況を修正したした。

Intel-Amdに぀いお話すず、Intelプロセッサの機胜により重点を眮いおいるように思えたす。 ARMのRyuJITポヌトは積極的に開発されおいたす。 このプロセスはただ進行䞭です-コヌド生成にバグがありたすが、コミュニティはその閉鎖を支揎したす。 コヌドがシングルスレッドの堎合、ARMでの動䜜の違いに気付くこずは困難です。 完党に順䞍同の実行は、マルチスレッドのコヌドで感じられたす。 しかし、私たちはこの問題を解決したす。


これらのむンタビュヌを読んで十分ではない堎合は、 DotNext 2016 Moscowにアクセスしおください。 SashaずKarlenに加えお、圌らはそこでのパフォヌマンスに぀いお次のように述べおいたす。

Source: https://habr.com/ru/post/J311286/

More articles:


All Articles