「.NETの世界のカオス-プラットフォームの開発速度に対する合理的な価格」：Andrei Akinshin（JetBrains）とのインタビュー

Riderプロジェクト（JetBrainsの.NET IDE）は、パブリックEAPバージョンに到達しました。開発者の1人であるAndrey Akinshinに詳細を尋ねるときです。 しかし、Riderは「No Slides」という新号の唯一のトピックではありませんでした。 彼に加えて、彼らは話した：

• Andreyが開発しているBenchmarkDotNetライブラリについて
• オープンソースとクロスプラットフォームへのマイクロソフトの動き
• .NETの世界の一般的な条件について、そしてもちろん
• .NET会議DotNext （ ついでに 、 今週金曜日にモスクワで開催されます）について

いつものように、カットの下にインタビューの完全な転写があります。

ライダー

-アンドレイ、皆さんはパブリックEAPを持っていると聞きました。 あなたはこのプロジェクトに1年以上取り組んでいます-あなたの気持ちを教えてください。



-チームとして、私たちは非常に良い気持ちを持っています：私たちは皆、ライダーに座って、90％の時間を書き込みます。 私たちはRiderの最古のユーザーです。なぜなら、少なくとも何かを書くことが可能になった最初のバージョンから使用し始めたからです。



ライダーはとても気に入っています。Riderは非常にクールなIDEであり、主に自分自身のために部分的に開発しているためです。 つまり、不快、迷惑、または不可能なことはすべて、チーム全体が観察していることであり、私たち全員が毎日これらのことに苦しんでいます。 しばらくすると、誰かの手がかゆくなり、この機能を修正します。 RiderはReSharperとIntelliJ IDEAのコードベースにも基づいており、これらはそれぞれ10年以上にわたって開発された非常にクールな製品であり、それぞれに多くの機能があり、それぞれが非常に高度に最適化されています。 Riderでは、すべてがまだ準備ができていませんが、準備ができているものは非常にうまく機能し、私たちはそれを本当に使いたいです。



-ReSharperは、プロセス内または別のプロセスでVisual Studioと連携しますか？



-プロセス内で動作しますが、これは大きな問題です。なぜなら、年は2016年であり、Visual Studioは依然として32ビットプロセスであり、多くのユーザーがReSharperが遅いと不平を言っているからです。 ReSharperの速度は低下せず、以前と同じように動作し、さらに高速に動作しますが、新しいバージョンが追加されるたびにStudioのメモリ消費量が増加し、この32ビットプロセスの一部として近づいています。 また、ブレーキに関しては、Riderはこれを実証しています。Studioプロセスから抜け出し、すべてが飛ぶようになりました。



-そして、なぜReSharperをアウトプロセスにしませんか？



-まず、Studio自体との相互運用という点で非常に困難です。次に、Riderでは、実際にIDEAとReSharperの相互運用を実装しました。 非常に長い間開発してきたカスタムプロトコルの助けを借りてこれを行い、多くの調整を行いました。



すばらしい作業が行われ、非常に使いやすく、すべてが非常に迅速に機能しますが、まだいくつかの問題があり、考えられない、不便なことがあります。 また、2つの製品を接続することもできます。それぞれの製品は自分自身で作成し、それぞれの製品で何でも変更できますが、すでに非常に困難で難しい技術的な作業です。 スタジオでは、これを実装することは非常に困難です。



-そして、少し違った方法で行けば、Riderのアウトプロセスモードを既に使用していることになり、プロトコルがあります。 さて、あなたが夢を見ているなら、すべてをスタジオに統合することは可能ですか、それともすべてをやり直す必要がありますか？



-まあ、純粋に技術的に-はい、それは可能です。時にはそれについて考えることさえあります。 ただし、これは非常に大きな困難な作業であることを理解する必要があります。 これに対処する場合、費用対効果が高いことを十分に理解する必要があり、それに投資する労働量は最終的には報われるでしょう。



-さて、Visual Studioはますます多くのメモリを消費する傾向があります。 消費量が少なくなるという前提条件はなく、なぜ余裕があるのか​​という疑問が生じます。



-さて、明日Visual Studioで何が起こるか誰も知らないので、私たちは今のところそれに座っています。 私が言えることは、今日、そのような計画はありません（実際、ReSharperの人が公然とこれについて話している-およそ著者） 。 今日、私たちはライダーを積極的に見ています。これが私たちの最優先事項です。



-ユーザーはあなたに何を書いていますか？ あなたはすでにクローズドアーリーアクセスプログラムを持っていました。私はそのメンバーであり、バグを報告しました。私は一般的にアーリーアダプターです。 閉じたEAPユーザーは何人いましたか？



-はい。 Riderで積極的に開発している人は何千人もいると思います。 フィードバックは膨大で非常に優れています。



-「ポジティブ」という意味での「良い」、または「食べ物を与える」という意味で？



-積極的かつ建設的。 早期アクセスプログラム（EAP）により、開発の初期段階で作業しなかったことを特定できました。



-例を挙げてください。



-たとえば、UnityまたはXamarinのサポート。 非常に多くの人々がこれらの目的のためにRiderを使用しようとしていますが、彼らのフィードバックは私たちにとって非常に貴重でした。 私たちは毎日それを使用していますが、UnityまたはXamarinはReSharperチーム全体が毎日開発するテクノロジーではありません。 また、ユーザーが必要とするもの、今の生活で欠けているもの、現在のツールキットで満足していないものを完全に理解していない瞬間もあります。 この点で、フィードバックは非常に貴重です。



時々、彼らは「私たちはそのようにして、すべてが壊れた」というバグレポートを受け取ります。 または、機能のリクエストが来ます：そのような機能があれば素晴らしいでしょう。 このすべてに耳を傾け、人々とコミュニケーションを取り、できるだけ早くそれを実装しようとします。



-現在、何人がRiderに取り組んでいますか？



-コアチーム-10人強ですが、ReSharperチームとIDEAチームもあり、常に協力していることを理解する必要があります。 特定のプラットフォームでバグを見つけたり、機能性に欠けたりする場合があります。他のチームのメンバーに会い、どういうわけかこれらの問題について話し合います。 したがって、私たちは百のためにそれを言うことができます。



-当時の「Without Slides」で、Dima Zhemerov は 、Extension PointsメカニズムによってIDEAがIDEからプラットフォームにどのように変わったかについて話しました。 また、Sergey Shkredov 氏によると 、ReSharperは夜間ビルドで条件付きで検査を実行でき、これはすべてTeamCityなどと結びついています。 これらの2つの場所で統合が行われたことを正しく理解できますか？ つまり、どうやってやったの？



-2つのプロセスがあります。 私たちはそれらを「バックエンド」、実際にはReSharper、「フロントエンド」IDEAと呼びます。 それらの間の通信は、特別なプロトコルに従って実行され、それに従って、本質的に、ビューモデルを駆動します。



「そして、それはソケットの上にありますか？」



-ソケットの上。 私たちはさまざまなオプションについて考えましたが、これは私たちに最も思いついたものです。 最初は、ReSharperのモデル全体を動かしたかったのです。 たとえば、IDEAがJavaをサポートするために構築する構文ツリーがありますが、C＃の構文ツリーを完全に追い抜いた場合、非常に高価な操作になり、パフォーマンスを伸ばすことはできません...



-つまり、データトラフィックですか？



-はい、プロトコルトラフィックは非常に大きくなります。 そのため、私たちは非常に軽量なモデルを駆動し、ビューモデルのみ、ユーザーに表示する必要があるもののみを駆動しています。 UIの情報のみ。



-構文ツリーはReSharperの側にありますか？



-はい。 つまり、ReSharperにはツリーがあり、何らかの方法でそれを処理し、すべての分析を考慮し、単純にIDEAは、たとえば検査サブシステムからのメッセージとともに数行をスローします。



-ただ、私が理解しているように、IDEAは特定の言語で構築し駆動する特定のツリーで動作します。 ここで、どうやら、何度もやり直さなければならなかったでしょう？



-はい、使用していません。たとえば、ReSharperが誤りがあると言ったため、ここでは赤い線で下線を引きます。 IDEA側では分析を行いません。 すべての分析はReSharperによって行われます。 そして、ほとんどの部分でIDEAから「show UI」を使用します。



-つまり、他の言語が統合されているIDEAと統合していません。 そのような統合のためにIDEAでどのくらい書き直す必要がありましたか？



-いいえ、驚くほどそうではありません。



-そして、これが機能するために、ReSharperとIDEAのどの部分が対応しましたか？



-あまり編集する必要はありませんでした。APIをもう作成するだけです。 IDEAには独自のコミットがありますが、ほとんどのコミットは、プライベートを使用してパブリックに変更するという事実に関連しています。 他の言語ではできないことを行うため、一部のメソッドは決して引き出されず、呼び出す必要がありました。 そしてもちろん、ReSharperがLinux版とMac版でMono上で正常に動作するように、最大​​の作業が行われました。 クロスプラットフォーム開発について多くのことを学びました:)最近、Riderでクロスプラットフォーム開発に関するセミナーを行いました。 ビデオはすでに利用可能です 。



-Homebrewを使ってMacにMonoをインストールしたという話がありましたが、初期のビルドの1つで、ReSharperはそのようなMonoの表示を拒否しました。 おそらく、最も難しいタスクではないことを理解しています。これをすべて修正することです。 しかし、あなたは今、このタイプの妨害が対処された公共のEAPにいると感じていますか？



-まあ、私たちは最も主要な株の大部分を掻き集めました。 これで、Riderは実際に使用できるIDEです。 そこでは、すべての機能が完全に機能するわけではなく、どこかで何かが落ちることもありますが、ほとんどのスクリプトは機能します。



-リリースが食料品であることは明らかですが、純粋にあなたの主観的なエンジニアリングの感覚に興味があります。生産に入るためには、さらに何をする必要がありますか？ まず最初に何を変更しますか？



「やることはあまりありません。」 まず、安定性に取り組む必要があります...



-まだ落ちている？



-私たちが落ちているわけではありませんが、最近、たとえば、ここにArchLinuxがあり、そこにRiderを置いていますが、何かがうまくいきません。 私たちは、いわば、ArchLinuxでの作業経験があまりないことを理解しています。これはユーザーの大部分ではなく、エキゾチックなシナリオです。



-たとえば、同じJavaはすべてのLinuxで認定されているわけではありません。ディストリビューションがどうあるべきかについて非常に厳密な説明があります。 私の意見では、事実は参照プラットフォームがOracle Linuxであるということです。比較的言えば、Red Hatに似たディストリビューションであり、その後の結果はすべてあります。 残りについては、Javaは保証を与えません。この場所で何をしているのでしょうか。 独自のJVMを提供していますか？



-はい、私たちは私たち自身のJavaとMonoを持ち運び、その上で作業しています。 Linuxの「これら、これら、これら、これら」のバージョンをサポートするために、絶対にどこでも動作するタスクはありません。サポートしない残りの部分は、できるだけ多くのユーザーを幸せにして、IDEを使用できるようにします。



-.NETに関する限り、何を持ち歩いていますか？



-モノ。 まあ、macOSとLinuxでは-特定のバージョンのMono、Windowsでは完全なフレームワークで実行されます-ユーザーが持っているものです。



-彼とのCの問題は少ない？



-はい、ReSharperはもともと完全なフレームワーク上で実行される製品であるためです。 そしてもちろん、Linuxには多くの問題がありました。Mono自体に多大な貢献をし、Monoに多くのパッチを適用します。 これは大量の作業です。



-アップストリームでアップストリームですか？



「はい、もちろん。」 作成するすべての変更セットをプッシュしようとしています。



-今年は多くのMonoがバグを引きましたか？



-多数の筋金入りのバグが見つかったと思います。 たとえば、Monoでは、ミューテックスを使用した作業の実装が不十分でした。 LinuxおよびmacOSには存在しないように見えるミューテックスという名前がありましたが、.NETにはあります。 したがって、どうにかして彼らと一緒に作業をエミュレートする必要がありましたが、完全にエミュレートされていませんでした。NuGetのソースコードでは、NuGetの作業を完全に実装する必要があります。 内部で発生したこの競合状態を2週間キャッチしましたが、名前付きミューテックスだけでなく、通常のミューテックスでも発生することがわかりました。パッチを適用し、修正をMonoに送信しました。

.NETの現在と未来

-聞いて、この「Mono、Xamarin、Microsoft」のおかしな束、そしてさまざまなランタイム（Mono、classic、Core）についての全話-これが、このすべての雑多な動物園と一緒に暮らす方法ですか？



-短い答えはどういうわけか私たちがするでしょう。 このすべてをサポートしようとしています。 もちろん、ほとんどの問題はCoreCLRにあります。これは、これがまだ終わりに達していないと言えるかもしれないからです。 つい最近、Microsoftは新しいVisual Studio 2017を導入し、それに伴ってCoreCLRの新しいチューニングが行われ、そこですべてが再び変更されました。



-待って、バージョン1.0があり、それについて彼らはそれが安定していると言って、それから1.1がリリースされました...



-いいえ、2つの異なることがあります。 ランタイムがあり、それにチューニングがあります。 Rantimeは、その上で実行されるVMです。 そして、チューニングはそれをすべて収集する方法です。



-つまり、新しいチューニングが登場しました。



-はい。 project.jsonファイルに基づくこのようなプロジェクト形式があり、多くの人がそれを聞いたり、それに取り組んだりしました。Microsoftはこのプロジェクトを非常に長い間推進し、「未来はjsonにある」、「プロジェクトをjsonに翻訳する」と述べました。 そして、突然、彼らは「ああ、何かがうまくいかなかったので、csprojに戻ります」と言います。 何ヶ月も前に、project.jsonは既にレガシーであり、サポートされないことが発表されましたが、代替手段はありません。 そして彼女はほんの一週間前に現れました。



-CoreCLRストーリーから私の気持ちを聞いてみると、「カオス」という言葉が思い浮かびます。 同僚とのあなたの気持ちは何ですか？



-もちろん、部分的には、.NETに関連してインフラストラクチャで多くのことが行われ、変化しているため、私たちはあなたに同意します。 しかし、これで十分だと思います。 .NETはそのようなプラットフォームであり、Windowsエコシステムのフレームワーク内で長年にわたって生き続けてきたため、Microsoftは突然戦略を完全に変更し、クロスプラットフォーム、オープンソースなどに向かった。



そして、これが1日で完了しないことは明らかです。これは膨大な量の作業です。 同じCoreCLRを作成し、クロスプラットフォームにし、すべてが携帯電話などで機能するようにします。 みんながこれをできるだけ早くやりたいと思っていることは明らかであり、もちろん、間違いを犯し、それを認識し、ロールバックし、何かを変えなければならないことは明らかです...



-人が.NETで書いて、今日1つのことを聞き、明日別のことを聞いて、すべてを何度もやり直さなければならなくて、「書き直すためにここにあまり時間をかけないで、別のプラットフォームに行きます」



-それはすべて、まさにあなたが開発しているものに依存します。 かつて持っていたプラットフォーム（Windows用の完全なフレームワーク）で開発している場合、そのような問題は発生しません。 あなたは以前のすべての問題を抱えています。



また、CoreCLRでの開発を開始する場合は、タイトルの「プレビュー」という言葉が警告を発し、次に何が起こるかを準備する必要があります。



マイクロソフトは現在、コミュニティに耳を傾けるのに非常に積極的であるため、最先端、最新の技術に座って、彼らの開発に影響を与えようとしている人々がいます：新しいサブセットの何かが気に入らなければ、今は彼らにフィードバックを書く時です そして他の人々は、これらすべてが安定するのを待っています。



-あなたは非常に興味深いトピックに触れました-それはクロスプラットフォームでもあり、オープンソースでもあります。 これら2つの大きなブロックについて話しましょう。 Linuxについては、これについて触れました。.NETとLinuxはしばらくの間一緒にされてきました。 この間に良くなったでしょうか？



-はい！ まず第一に... LinuxとMacで実行できる2つのランタイムがあります-これらはMonoとCoreCLRです。 それらは異なり、それぞれが興味深いものであり、特別な注意に値します。



Monoは、2000年代初頭から開発されたプロジェクトであり、より安定しているほど、ますます深刻なランタイムと見なすことができます。 5年から10年前にモノに翻訳しようとした人が苦しんだら、今は...今、私たちももちろん少し苦しんでいます。 しかし、ReSharperでは、数百のプロジェクトがあり、わずかなきしみはあるものの、2000年代の初めから書かれた数百万のレガシーコード行が起動し、Monoで正常に動作します。 つまり、開発が進行中であり、バグが修正されており、最近では非常に迅速に修正されています。



-あなたが顧客に見ているものから：彼らはCoreCLRに向けて出発しますか？



-今のところ言うのは難しいです。 コミュニティはCoreCLRに非常に興味があり、多くの人々が開発を追いかけ、何かを試み、試みています。 しかし、これはまだプレビューであり、CoreCLRを介してあらゆる種類のエンタープライズを行うには時期尚早です。



-ロズリンはどうですか？ 新しいスタジオが登場しましたが、コンパイラには何がありますか？



-ロズリンは開発中です。 C＃7は近日公開予定です。プレビューは、新しいStudioで既に利用可能です。 ロズリンはすべて順調です。



-Roslynに付属するC＃7-箱から出してすぐに？ この間にロズリンは進歩していますか？



-はい。 バグを修正し、開発します...古いレガシーコンパイラからRoslynに切り替えることで得た最も重要な機会は、言語をより簡単に開発できるようになったことです。 言語の観点から必要な機能と、実装よりも正確にそれらを実装する方法にもっと集中できます。 古いコンパイラでは、新しい機能を追加することは非常に困難でしたが、Roslynを使用するとはるかに簡単になりました。



-ロズリンを自分のどこかにドラッグして、それについて何かしようとしましたか？



-まあ、どうですか。 コンパイラとして使用します。 MSビルドの下で動作し、それを利用して新しいプロジェクトがコンパイルされます。 しかし、アナライザーや検査に関しては、ReSharperにはさらに多くの機能が実装されているため、それが提供するものは必要ありません。 私は何回も、非常にクールな検査、よりインテリジェントに言うでしょう。 また、Roslynは2ギガバイトのメモリを簡単に消費できます。 この点で、ReSharperコードベースは、メモリを使用してさらに経済的であり、キャッシュを積極的に使用します。 つまり、Roslynへの移行による利益はなく、問題があるだけです。



-パフォーマンスについて話しましょう。 CoreCLR、Roslynは、Monoと従来のレガシーコンパイラを比較しました。 つまり、2つのランタイムは、パフォーマンスが異なります。 どう見えますか？



-言うのは間違いなく非常に難しい...最近、新しいRyuJIT JITコンパイラがあります。 現在、完全なフレームワークとCoreCLRの両方で、64ビットバージョンのみが使用可能です。 また、CoreCLR 1.2.0では、x86バージョンも約束されています。



RyuJITは非常に興味深いプロジェクトです。 一方で、古いJITは開発が難しく、多くの問題を抱えており、2.0などの.NETの古いバージョンに対する多くのハックを抱えていたため、彼らがそれを始めたのは良いことです。 しかし、ひどく判明したのは、たとえば、RyuJITがパフォーマンスのいくつかの面で古いレガシーJITよりも劣っていることです。 つまり、そこにいた人たちは、JITの速度が可能な限り速いことを強調しました。 このため、いくつかの適切な最適化は適用されません。



しかし、良い面は、RyuJITが非常に積極的に開発していることです。 githubで非常に積極的に開発されており、たとえば、RyuJITがAVXおよびSSE命令を操作するための優れた統合を実現できるように、アーキテクチャが改善されています。 そして最適化は進化しています。 GitHub, «, , - , ». , .



— -?



— CoreCLR CoreFX. , «, ». — - , , , , , - , .



— , , , — , , — . .



— , , .NET , - …



— , , .



— , .



— Microsoft. , — GitHub, — ? .NET- — ?



— . Microsoft — GitHub. . , , , , - . issue GitHub, , issue Microsoft, …



— .



— ! , Microsoft. issue . , , , , .



. ASP.NET- Kestrel -10 - . . , …



— .NET- — nginx, Apache?



— — Java, C++, . Kestrel . , : Microsoft, Kestrel.



— ?



-はい。 ore Team , , - , .

Microsoft Open Source

Microsoft, , , , ?



-はい。 Microsoft - , , -. Microsoft , , , .



— ?



— , , Open Source, . , , Microsoft Linux Foundation.



— , : , ?



— , , - , , Linux . , , Azure…



— «»! Microsoft. , , , Azure, , .



— , , , , , . , , Linux.



— business value.



— , Red Hat. Red Hat , .NET — Red Hat…



— , : Microsoft Azure, . Linux ( , Windows, ). , Microsoft , Azure.



— , , .



— , ? Linux Open Source.



— . . Microsoft, , - . Apple Google. - .



— — . , Windows Phone .



— ? Windows Store . , . — .



— , .



— , . , Microsoft Xamarin Mobile Development C#.



— DotNext ( ) ( ), . DotNext , , Xamarin.Forms. , . , , , .



— , , . - DotNext -, , , , - , . Xamarin - , , .



C# — , Xamarin , Windows, Android, iOS. , . .



, Google Play App Store, native. , - « », , , , , , , C# — .



— ?



— - . , , - API, API. , . native API, UI, .



Rider, Xamarin, , .



— , , ?



— , « » — . , .



— , .NET ?



— .



— Xamarin ?



— , , , , , Rider 1.0 , .

BenchmarkDotNet

— , JetBrains: , , BenchmarkDotNet . ?



— , .NET Foundation, , .



— , BencmarkDotNet?



— , Roslyn, ColeCLR ( RyuJIT ), Entity Framework, Microsoft , , Cake , .NET. .



— , ?



— , : , . — - -, — .NET Foundation.



— ? , , Java: , , , . ?



— , . Kestrel, , BenchmarkDotNet . — , , …



— , Microsoft . , BenchmarkDotNet — , Microsoft. ?



— , , high performance. , . 20 , , - . BenchmarkDotNet - -, , -, , « ».



— , — , , .



— , , … . Java- JMH, , — JMH…



— , , JMH, «A , B». .



— , , , , . - , . , N , - .



, - , . , , . , . - , , , , , .



— JMH?



-はい。



— BenchmarkDotNet ? , ?



— . -, , Java .NET , . Java . . Java , , .



— , Java JVM, , - , , . .NET CLR, CLR, Mono — , . JMH, , HotSpot, , . , .NET ?



— . , . , Mono, CoreCLR. , - -. .



, - Mono , , . これが最初の瞬間です。 — , , , , , . JMH — , , . . , , .



— BenchmarkDotNet , , JetBrains?



— — , , . — , , . , , , .



, . , Rider , , , - , , , . , , , .



— JMH, , , . , , , , , . - ?



-はい。 BenchmarkDotNet. , , , , .



— footprint?



— , . , memory traffic. , -JIT-, . .



— ? , — , . ?



— , . , .



— - ?



— . , , .



— DotNext ?



— , . DotNext , .



— , ?



— -.



— . — . , — . ?



— , , , . — , , , , .



, Intel , , , -, , AMD, ARM, Samsung— .



-はい。 , Intel, - …



— ?



— , Intel?



— , « , ». Microsoft, — . Intel?



— -, , Microsoft . Intel , , — …



— , , , Intel . Java , Intel : « intrinsic, , ...»



— .NET, , .



— , Intel Microsoft .



— . . , , , , .

native

— , . .NET, : . - ?



— . .



— ?



, . NGen, — , ahead of time-.



— ? . ? : GCC , 70 . internal representation .



— NGen , , , , , , profile-guided optimization : , - .



— , , , NGen', - ?



— , , , , . , JIT-. , , - , . … , - , .



— , . JIT- . footprint, , , .



— .



— , NGen, , ?



— .NET Native. , Windows-. , , .



.NET, , .NET Native, . , , .NET- native . , , LLVM. C++ , .NET C++, .



— C++?



— .



— managed?



— , . , , , , . Microsoft , , , , , - , - , .



— , Microsoft , , , . : - — ? ? Rider, « IDE, C#-, ». ?



— - , .NET-.



— , - . , , , - -, . . , : Rider?



— . , , , , , preview. , , . . , , .



, -, . , , .



— Microsoft. , Microsoft , . , Microsoft, MS-, . 15 , - . business value , .



-それは本当です。 , — , . 2-4 — .



— : 2-3 , , Stack Overflow, Medium, . , Microsoft ? ?



— . , , Microsoft , .



— . ReSharper, - . Microsoft , . 1.1 1.0 , , 1.0. ?



— , , , , - . CoreCLR, . preview 2, preview 3. preview 2 , , , N , . , preview 3, 1.0. stable- .



- Rider, , . . C# , , - , . , , , , .

---

今週金曜日にモスクワで行われたDotNextカンファレンスで、アンドレイと話をすることができます。そこでは、.NETプラットフォームでの算術演算の速度についてプレゼンテーションを行います。