.NET開発：大人のための9つの質問

.NETは真のクロスプラットフォームになります：しばらくしてASP.NET Coreのリリース日がようやく発表され、JetBrainsはReSharperとIDEAに基づいてVisual Studioの代替を準備しています。 Windows Server 2016は、DockerのWindowsコンテナーのサポートを受け取ります。



新しい機会により、私たちは新しい課題に直面しています。

• 同じコードは、.NET CoreおよびMono、WindowsおよびLinux、dockerコンテナーでどのように機能しますか？
• 今すぐ.NET Coreに切り替えて、新しいプラットフォームを最大限に活用する方法はありますか？
• MonoとXamarinの見通しはどうですか？
• Roslynおよび.NET Coreへの移行に伴い、.NETの「内部」でどのような変更が発生しましたか？

サンクトペテルブルクで開催されたDotNextカンファレンスでは、わずか3週間で20人のスピーカーが.NETプラットフォームの現在と未来、パフォーマンスとマルチスレッドの最適化、.NETプラットフォームとCLRの内部構造、.NETコードのプロファイリングとデバッグについてプレゼンテーションを行います。







それまでの間、4人に.NETの世界における差し迫った変化に関する経験と意見を共有してもらいました。 私たちの質問に答えました：

• .NETプラットフォームの生産性に関する世界的なトップエキスパート、 8回の Microsoft MVP、.NETパフォーマンス「Pro .NETパフォーマンス」 Sasha Goldsteinに関する優れた本の著者。
• Riderのリアクティブマルチプロセス通信プロトコルの主任開発者、JetBrainsのDmitry Ivanov 。
• JetBrainsの別のRider開発者、.NET MVP、Ph.D.、ACM ICPCの銀メダリスト、Weizmann Institute of ScienceのポスドクAndrei Akinshin ;
• CTO PromarketとMonoおよびLinuxの専門家Nikita Tsukanov 。

Roslynへの移行に伴い、.NETで何が変更されましたか？

サーシャ・ゴールドスタイン

Microsoftにとって、Roslynは非常に重要なプロジェクトです。 C＃チームのほぼ全員が、おそらく7年間この作業を行い、非常に長い間リリースできませんでした。 そして今、彼はオープンソースでgithubを使用しており、目の前で言語を変更するプロセス全体を行っています。 一方では、他の言語の構造をC＃に追加するという奇妙なアイデアを持つ人が多くいました。他方では、プロセス全体が公然と行われ、2時間でコンパイラを書く3人が質問に答えることができます。 コミュニティにとって-これはとてもクールです。



アンドレイ・アキンシン

全体として、私はロズリンが本当に好きです。 コンパイラとしては、古いものよりも優れています。パフォーマンスの点で、多くのコードをより有能に、よりうまくコンパイルします。 しかし、C＃コードのコンパイルについて話している場合は、次の段階であるJITコンパイルに興味があります。 少し前まで、MicrosoftはRyuJITと呼ばれる新しい64ビットJITコンパイラを導入しました。



その主なタスクの1つは、JITコンパイル時間を短縮することです。 ユーザーに非常にクイックスタートを提供しますが、このためクールな最適化を行うことができないため、コード自体の実行速度はそれよりも遅く、場合によっては古いJITよりも遅くなります。 同時に、RyuJITはSSEおよびAVX命令を十分に活用できるため、ネイティブコードにアクセスせずに1つのC＃の能力を使用して非常に効果的なプログラムを実装することができます。



パフォーマンスの面では、Microsoftは、現在活発に開発している別のテクノロジ、.NET Nativeに賭けているように思えます。 これまでのところまだ非常に生の状態ですが、有望に見えます。



ニキータ・ツカノフ

Roslynの主な機能は、Microsoftが合理的な速度で新しい機能を追加できるようになったことです。 以前は、アセンブリ用のコンパイラとスタジオ用のコンパイラがありました。 これはなくなりました。コンパイラは1つしか残っておらず、C＃で記述されています。



ドミトリー・イワノフ

APIの観点からは確かに良くなりましたが、パフォーマンスと余分なメモリに問題があり、解決策にはほど遠い状態です。 Visual Studio 2015では、メモリが不足しているため、ReSharperと一緒に巨大なプロジェクトを開くことができません。

Monoと.NET Coreを比較できますか？ 両方の見通しは何ですか？

サーシャ・ゴールドスタイン

MonoはMITライセンスに切り替わります。 そのため、MicrosoftはCoreFxでMonoチャンクをコピーして使用できます。 モノはゆっくりと消えていくように思えます。 Monoには、.NET Coreがまだ動作しないいくつかのニッチがあります。 しかし、Monoランタイム自体はまあまあです。GCは最近、世代別GCに切り替えたばかりで、JITはあまりうまく機能しません。 そして、多くの場合彼らが書いたフレームワーク自体は本番用ではありません。多くのバグがあり、バグが検出され、長い間修復されていません。 実稼働環境でMonoを使用していたほとんどすべての顧客に問題がありました。 これは、最終的にシステムがまったく機能しなかったことを意味するものではありませんが、これは.NETで使用される品質レベルではありません。



しかし、.NET Coreでも、事態は順調に進んでいません。 プロジェクトは1月に終了する予定でしたが、数日前の3月に、6月末に準備が整うと彼らは言いました。 API、設計モデル、コードの半分は常に変化しています。



先週、ASP.NET MVC 6のプロジェクトを持つクライアントの1人が、2週間ごとにコードを修正するか、ASP.NET MVC 5でバックポートして待機する方が良いかを尋ねました。 質問は簡単ではありません。



アンドレイ・アキンシン

.NET Coreは確かに非常に興味深いプロジェクトであり、大きな前進ですが、今日でも未加工のままです。 多くのライブラリがまだその下に出ていないか、RCにあることを忘れないでください。 さらに、Microsoftは常に名前を変更し、毎日すべてが変更され、いくつかのバグが修正され、他のバグが追加されます。 2年間、project.jsonファイルに基づく新しいプロジェクトシステムが開発および宣伝され、先日、ごみ箱に捨てられ、古き良きcsprojに戻ることを決定しました。 そのような状況は、近い将来、実稼働システムを.NET Coreに移行しようとする欲求を落胆させます。



Monoは15年以上にわたって開発されてきました。 これは、多くの実動コードを実行する大人の堅実なランタイムです。 たとえば、私はJetBrainsでRiderプロジェクト（クロスプラットフォームの.NET IDE）に取り組んでいます。 バックエンドライダー（これは純粋なR＃です）はMonoで起動されますが、.NET Coreではうまく機能しません。 これは非常にうまく機能します。数百のプロジェクトと非常に重要なロジックの健全なアプリケーションで、.NETのすべての機能と* nixの下のすべてが正常に起動します。 もちろん、独自の問題もありますが、それらは正常に機能する順序で完全に解決されます。 .NET Coreへの移行について：この新しいクロスプラットフォームランタイムがより安定するまで待つ必要があります。



ニキータ・ツカノフ

Monoはかなり成熟した環境であり、.NET Coreはまだベータ版と利用可能なライブラリの数を失っています。 たとえば、.NET CoreではSystem.Drawingがサポートされなくなり、Monoでは2000年のシャギーな年に登場しました。



.NET Frameworkのカバレッジのパフォーマンスと品質に関して、MonoはMicrosoftが公開している部分を積極的にそれ自体に移行しています。 MicrosoftがXamarinを買収したことを考えると、プロセスはさらに速くなるはずです。 ある時点で、Monoは.NET Coreのアドオンになりますが、現時点ではMonoを使用するのが理にかなっています。



ドミトリー・イワノフ

私たちは、おそらく、ほぼすべての人が、ある時点でMonoがドロップするという意見を持っています。 Oracleはかつて、HotSpot JVMとJRockitを組み合わせると言っていましたが、最終的にはJRockitを廃止しました。



したがって、おそらく待つ価値があり、Monoから.NET Coreに切り替えてください。 Riderでは、Monoで多くの作業を行っており、多くのエラーがあり、コードの品質が.NET Frameworkよりもはるかに低いことを確認しています。

高性能ソリューションの分野で、独自で独自の何かを考え出す必要がよくありますか、それともすぐに使える優れたライブラリがありますか？

アンドレイ・アキンシン

特効薬はなく、誰にでも適したユニバーサルライブラリはないと考えています。 タスクのソリューションを選択する必要があります。 データベースを使用する場合、特定のインジケーターで他のデータベースよりも高速に動作するデータベースがあります。グラフィックを使用する場合、2D / 3Dレンダリング用のさまざまな優れたライブラリがありますが、それぞれが独自の範囲のタスクに適しています。 各プロジェクトは独自の方法で一意であることを覚えておく必要があります。 ほとんどの場合、一部のタスクでは、一部のソリューションが他のソリューションに適しています。



非常によくある間違い：「ABC」ライブラリが良いと聞いた人は、それがどんなタスクで、どのシナリオで迅速に動作するかを考えることなく、それを取得して使用します...



重要なポイント：多くの人がパフォーマンスに煩わされ、コードの重要でないセクションの最適化に多くの時間を費やしています。 これにより速度がいくらか向上しますが、誰も気付かないでしょう。 パフォーマンスを向上させるには、調査を行い、ベンチマークを行い、プロファイルを作成する必要があります。



ドミトリー・イワノフ

単一の.NETチームのフレームワーク内でも、プロセス間通信のためのソリューションがいくつかあるため、そうする必要があります。 現在、高パフォーマンスのソリューションは通常、何らかのサーバー負荷を意味します。



1台のマシンのパフォーマンスの問題について話すと、それは絶えず解決されています。これは、たとえば、慣用的なC＃コードをはるかに超えるものだからです。 非常に迅速に多数の配列参照から切り替える必要があるため、安全ではありません。 それなしでは機能しません。 そして、Rider Frameworkでプロトコルを実行し、高いパフォーマンスを実現します。

マルチスレッド.NETプログラミングの主な難点は何ですか？ 主な課題は何ですか？

サーシャ・ゴールドスタイン

多くの開発者にとって、マルチスレッドプログラムで何が起こっているか、メモリアクセスを移動できること、同期を行う必要があること、そして多くの同期がある場合はボトルネックが発生することを想像することは困難です。 これには多くのツールがありますが、それらを知り、使用できるようにする必要があります。



多くの開発者は、マルチプロセッサシステムにアクセスできません。 Core i7ではなく、少なくとも64プロセッサを搭載したサーバーで同じコードを実行すると、まったく異なる問題が発生します。 2％の時間を要した小さなロックが突然50％を占めるようになり、メモリ帯域幅の問題が発生し（メモリシステムがリクエストに十分に迅速に応答できない）、キャッシュが効率的に使用されません。 .NET開発者はほとんどの場合、このようなタスクに直面することさえありません。



アンドレイ・アキンシン

.NETでのマルチスレッドプログラミングの複雑さは、他のプラットフォームと同じだと思います。 マルチスレッドの世界がどのように機能するかを理解する必要があります。 同期プリミティブと同時データ構造に関しては、.NETではこれで十分です。 さらに、async / awaitがC＃5に登場しました。これにより、マルチスレッドコードを美しく理解しやすい方法で記述できます。



ニキータ・ツカノフ

通常、あるスレッドが別のスレッドが所有するデータにアクセスできないようにする方法はありません。 Rustでは、このために多少の通常のシステムが作成されました（割り当てを破壊します）。 .NETでは、これはすでに非常に難しいことではありません。不注意やその他の理由により、あるストリームから別のストリームに何かを転送すると、余分なものが別のストリームに送られることがあります。 そして、所有者スレッドはそれについて何も知らないが、彼らは「この過剰」で働き始めることができます。 この場合、誰も知らないところで競合する書き込み要求が発生します。 プロジェクトが成長するにつれて、プロジェクトの追跡と対処はますます困難になります。



ドミトリー・イワノフ

いい質問です。 私は何年もマルチスレッドをプログラミングし、人々にそれを行う方法を教えてきましたが、私はそれを自分で理解していません。 おそらく、主な課題は最上位レベルで発生します。大規模な開発者チームと大規模な製品に適したモデルを考え出し、誰もがそれに追随し、このモデルの制限に決して陥らないことを願っています。



Roslynチームは、マルチスレッド相互作用のトランザクションモデルを使用することを決定し、メモリウォールにぶつかりました。 悲観的なロックと読み取り/書き込みロックモデルでは、読み取りロックが長時間リリースされ、スムーズな転倒に直面します。



特効薬はなく、新しく絡み合った俳優でさえも節約しません。HelloWorldはうまく機能しますが、実際にはすべてがより複雑です。

高性能なコードを書くために低レベルの詳細を理解する必要がありますか、または現代のフレームワークがこの必要性を排除しますか？

サーシャ・ゴールドスタイン

配信しないでください。 唯一の質問は、どの程度必要かです。 アセンブラーの読み取り、メモリモデル、プロセッサの動作方法の理解が必要ですか？ 標準的なヒント-作業中のレベルより少なくとも1つ下のレベルを理解します。 .NETで作業している場合は、OS、ランタイム、GC、フレームワークの仕組みを理解する必要があります。 これがないと、問題を見つけたとしても、それを修正する方法がわかりません。



アンドレイ・アキンシン

プログラマーが解決するタスクに依存します。 90％の時間、車から最大限の力を引き出すタスクはありませんが、プログラマーはバグのない信頼性の高い、読みやすいコードを確保することを検討する必要があります。 問題が発生した残りの10％の場合（または、問題が明確に発生すると推測します）、それらを解決しようとしますが、はい、すべてが内部でどのように発生するかを知る必要があります。



多くの人々は、この人生で何が起こっているのか理解せずにパフォーマンスの問題を解決しようとします：彼らは間違ったベンチマークを作り、曲がりくねったプロファイルを作成し、物事を遅くし、それに多くの作業時間を費やす奇妙なコードを書きます。 これらの10％のパフォーマンスクリティカルなケースにうまく対処するには、すべてが内部にどのように配置されているかについて多くを知る必要があります。



ニキータ・ツカノフ

抽象化の問題は、それらがリークする傾向があるため、チームには、すべてが内部でどのように機能するかを理解している1人が必要なことです。 数学をよく知っている人でも同じです。 従来の低レベルの問題は、メモリリーク、ネイティブコードの例外、ヒープの破損です。



ドミトリー・イワノフ

私の意見では、.NETエンジニアは、少なくともプロセッサとプロセッサキャッシュの動作、分岐予測の動作の少しを理解し、アレイとディスクへのシリアルアクセスが常に並列よりも高速に動作する理由を理解する必要があります。

「スローダウン」した場合はどうすればよいですか？ 最初の2-3ステップは何ですか？

サーシャ・ゴールドスタイン

推測なし。 ツールを実行し、プロセスで何が起こっているかについての情報を取得する必要があります。 メモリ、CPU、スレッドの数を確認してください。 現在、多くの無料のユーティリティがあります。 その後、多数のメソッドがあります。 私のお気に入りはUSE（使用率、飽和、エラー）です。 LinuxパフォーマンスのエキスパートであるBrendan Greggによって発明されました。 使用率とは、リソース（CPU、メモリ、ディスクなど）ごとに使用量を決定する必要があることを意味します。 飽和-これらのすべてのリソースについて、たとえば、一度に1つのディスクから30個のファイルを読み取るかどうかなど、サブスクリプションが過剰かどうかを判断する必要があることを意味します。 エラー-プログラム内のエラーの数。 その後、何かを最適化できます。プロセッサを追加するか、コードを改善します。 それは一般的です。



アンドレイ・アキンシン

最初に行うことは、何が正確に遅くなるかをプロファイルし理解することです。 非常によくある間違いは、プロファイリングなしの最適化です。 ボトルネックが見つかったら、次の質問は「コードのこのセクションの速度が低下するのはなぜですか」という質問を自問することです。 ここでは、本当に多くの知識が必要な場合があります。どの要因が本当に重要かを推測し、それらのみを確認する必要があります。そうしないと、プログラマーが不必要な作業に多くの時間を費やす危険があります。 そして3番目のステップは、問題を修正し、プログラムが実際に高速に動作することを慎重に確認することです（また、最適化中に何も中断されなかったことも確認します）。



ドミトリー・イワノフ

クラシックでは、プロファイラーを使用してボトルネックを見つけて修正することをお勧めします。 しかし、すでにこれを数回行っている場合、率直に言ってボトルネックは残っておらず、数行修正することでプログラムを数回スピードアップすることはできません。 これらの場合には、アプローチを修正する必要がある場合があります。たとえば、コードによってAssert'esを挿入し、割り当てられた時間内に操作が完了するようにします。 そして、チームの各メンバーに、自分の責任範囲に該当するパフォーマンスアサーションを修正するよう強制します。 また、メモリトラフィックを確認して、それとの戦いを開始することも役立ちます。 安全でない場所に行くことさえ可能です。

パフォーマンスの問題を探す際にお気に入りのツールは何ですか？

サーシャ・ゴールドスタイン

Windowsでは、パフォーマンスカウンターから開始する必要があります。 その後、状況に依存します。 多くの問題はPerfViewでしか解決できませんが、大きな視覚化の問題があります。 ちなみに、Visual Studio Profilerは非常に優れています。ところで、スタンドアロンバージョンがあります。 dotMemoryまたは.NET Memory Profiler –メモリプロファイリング用。



アンドレイ・アキンシン

私はBenchmarkDotNetユーティリティのメンテナーです。 このライブラリの最新バージョンは既に安定して動作しており、ベンチマークのための十分な機会を提供しています。 残念ながら、インターネットの多くの人々は、ストップウォッチと数サイクルに基づいて、独自の自家製ベンチマークを常に作成しようとしています。 同時に、彼らはすべての段階で彼らが気付いていない問題に囲まれており、実験の結論を完全に台無しにする可能性があります。 しかし、これは問題の一部にすぎません。すべてのレーキを奇跡的にパスし、この特定の状況で、実際に有用なものを測定する正しいコードを書くことができます。 ただし、スタジオではデフォルトでこの構成が選択されているため、初心者のパフォーマンスエンジニアは2人に1人しかDEBUGでベンチマークを開始しません。



これにより、測定値が完全に台無しになる可能性があることを説明する価値はありますか。 BenchmarkDotNetは、ユーザーにデバッグ設定とアタッチされたデバッガーを大きな赤い文字でscり、一般的なベンチマーク手法に準拠し、適切な加熱を行い、各プロセスを異なるプロセスで数回実行し、異なる環境を比較し、統計を考慮するなどを可能にします 現在、プロジェクトの周りにコミュニティが集まっており、ライブラリは多くのパフォーマンス研究にとって便利で人気のあるツールになりつつあります。



プロファイリングとして、JetBrains製品のdotMemoryとdotTraceをお勧めします。 私は頻繁にそれらを使用し、私は本当に、それらが本当に好きです。



ドミトリー・イワノフ

すべてのツール：dotTrace、dotMemory。 ほとんどすべてに十分です。 sys内部ユーティリティを見る必要がある場合があります。

.NET Performanceを読んで見ることをお勧めしますか？

サーシャ・ゴールドスタイン

オンラインには多くの資料があり、複数サイトに関する私のコースがあります。Microsoft開発者の古いブログ（Rico Mariani、Chris Bru、Vance Morrison）には非常に多くの情報があります。 本について：私の本Pro .NET Performanceがありますが、新しい本があります -Ben Watsonの "High Performance .NET Applications"です。 また、非常に興味深いことに書かれています。 さらに、.NETデバイスについて何かを知り、理解する必要があります。 C＃を介した古典的な本CLRがあります。 少し時代遅れですが、例外やデリゲートがどのように機能するかなど、いくつかのポイントは他のどこにも言及されていません。



アンドレイ・アキンシン

アルゴリズム、データ構造、使用するプラットフォームについての基本的な知識がなければ、私は上下に移動し、CPUレベルに移動しません（一部の人はそうしようとしています）。 .NETによると、同じRichterを読んで、基本クラスがどのように機能し、なぜそれらが優れているのかを理解できます。 ランタイムデバイスを理解することは非常に重要です。GCの仕組み、クラスの構造との違い、JITコンパイラとは何かなど。



さらに、最新のハードウェア、特にIntelプロセッサ（少なくとも一般的には）がどのように機能するかを理解しておくといいでしょう。 これに関して、インターネットには多くのリソースがありますが、これは非常に読みにくいことがよくあります。夕方には本を読んでCPUデバイスの詳細を把握することはできません。



ただし、パフォーマンスに特化していないが、企業で働いている人はこれを必要としません。 私はそのような人々に一般的な博学を広め、視野を広げるよう勧めます。 この点で、DotNextのような会議に出席することは素晴らしいことです。 私自身は、専門的に行っていない分野のレポートを見るのが大好きです。 いずれにせよ、私はプログラミングのすべての分野に完全に従事する時間はありませんが、少なくとも私は一般的な考えを持ち、関連するトピックについて他のプログラマーと話すことができます。 新しい領域に関連する問題を解決する必要がある場合は、どの方向から検索を開始し、何をグーグル検索するかがわかります。



ドミトリー・イワノフ

Sasha Goldsteinのレポートにアクセスしてください:)彼の本を読んでから、パフォーマンスの最適化を必要とするタスクを必ず実行してください。そうしないと、脳は情報を不必要に単純に破棄します。

サンクトペテルブルクのDotNextで何を話しますか？

サーシャ・ゴールドスタイン

プロファイリングツールとメモリモデルに関する2つのレポートがあります。 最初に、PerfViewを使用します。 分析するパフォーマンスの問題を含むコード例を用意しました。 PerfViewは、ETWテクノロジーのフロントエンドです。 ちなみに彼女については、DotNextに関する別のレポートがあります。 ETWは、ログを収集できるテクノロジーです。 Windows、.NET、CLR、ASP.NETの多くのコンポーネントがこのログに書き込みます。 そして、これらのログを非常に高速で書き込みます。 PerfViewは、ETWログの効果的な分析です：CPU、ランタイム、データベースアクセス、割り当てプロファイリング。



2番目のレポートは、メモリモデルに関するものです。 メモリモデルは、すべての高レベル言語のすべてのメモリ操作の「怖い」名前です。 プログラムが1つのスレッドで動作する場合、すべてが単純ですが、多くのスレッドがある場合、状況は変わります。 書き込みと読み取りは、指定した順序にならない場合があります。コンパイラは通常、メモリアクセスの一部を最適化できます。 プロセッサでも同じです。 そして、ポートがIntelからARMに作られると、すべてのiPhone、Android、またはPower PCになり、すべての車で、プロセッサ自体がより多くを許可するため、多くのすべてが機能しなくなります。



Intelが正常に動作する場合、いくつかの理論的および実用的な例を示しますが、iPhoneで破損したり、1つのストリームから複数のストリームに切り替えたときにIntelが切り替わった場合、このコードを見ている人はほとんどいませんそれが問題です。 メモリモデルの微妙さを分析した後、正しい同期で正しいマルチスレッドコードを構築する方法の例に進みます。



アンドレイ・アキンシン

算術についてお話します。 単純な算術式でプログラマが迷惑な間違いを犯し、その後数週間にわたって検索されるバグを作成する方法を何度も見てきました（なぜ、そこで数学の部分が正しく機能しないのですか？）浮動小数点。



算術パフォーマンスや、数式を高速化するために数式で実行できる単純な変容について考える人はさらに少なくなります。



たとえば、CPUはハードウェアレベルで1つのスレッドに送られるコマンドも並列化できますが、適切な並列化を行うには、適切に記述する必要のある適切なコードが必要です。 ボトルネックが見つかり、計算を最適化する必要がある場合は、追加の知識を適用してコードを少し工夫するのが理にかなっています。



ニキータ・ツカノフ

開発と展開のためのインフラストラクチャの要素としてのDockerについて話す予定です。 マイクロサービスを迅速かつ効率的に展開および管理する方法。 また、DockerでWindows Server Coreを実行する方法についても説明します。



ドミトリー・イワノフ

Riderは、IdeaとReSharperのハイブリッドです。 共通のリアクティブモデルを使用します。 アイデアはいくつかのパラメーターを設定し、R＃はそれに応答し、レンダリングに必要なデータを設定します。このようなプロセスは数回繰り返すことができます。



Rider Frameworkは、ターゲット言語のDSLからのJavaおよび.NETリアクティブライブラリおよびモデルジェネレーターです。 DSLはKotlinで記述されています。これは、Kotlinの構文機能により、Groovyスタイルのメタプログラミングが許可されているためです。 レポートはライブデモになります。



私のレポートは、アウトプロセスアプリケーションを作成したい人や、リアクティブフレームワークに関心があり、デスクトップアプリケーションにリアクティブモデルを使用したい人に役立つと思います。

---

スピーカーに質問がある場合は、ハードコアの.NETを受け取り、サンクトペテルブルクの天気が何回、何回変わるかを知りたいと思います。6月3日にDotNext 2016 Piterカンファレンスでお待ちしています。