MonoとMS.NETの違いについて話しましょう

.NETのクロスプラットフォーム開発は、日々ますます現実的になっています。 そして、最近の公式のLinux / MacOSサポートの発表後、幸せな未来は少し近くなりました。 ソースコードは現在MITの下にあるため、上の図は以前の関連性を失っています。 ただし、クロスプラットフォームの.NETアプリケーションは長期間作成できます。Monoはこれを支援します。 しかし、コミュニティでの彼に対する態度はかなりあいまいです。 「モノは愚かで、すべてが3倍遅くなる」や「モノの下では何も正常に起動しない」などの言葉をよく耳にします。 さらに、これらの人々から特定の事実を聞くことは非常にまれです。 質問「何が本当に愚かですか？」または「何が正確に機能しませんか？」それらをst迷に陥れます。 すべてではありません（建設的な議論が可能なものもあります）が、ほとんどです。 ほとんどの場合、inする答えは「はい、何も機能しません！」の精神で始まります。 そして、それが機能する場合、非常に遅いです！」 会話の終わりに、Monoでの最後の各マシンコマンドは数倍遅くなり、ソースコードの半分にthrow new Exception()



です。



この投稿では、少し経験を共有したいと思います。 少し前に、 PassportVision製品（ Habréでの発表 ）をLinuxに移植しました。 かなり正常に機能していると言えます。 はい、Microsoftの従来の.NET（以降-MS.NET）上のWindowsよりも少し遅いです。 しかし、それは非常に安定して機能し、パフォーマンスの低下は根本的なものではありません。 同時に、当社の製品は非常に大きく、エンタープライズのカテゴリーに分類され、C＃/.NET機能を最大限に活用しています。 したがって、.NET用の大規模なサーバーアプリケーションを取得するのは現実的です-要望があります。 また、Monoで何かを書いているさまざまな開発者と話す機会がありました-主に成功した物語です。



しかし、なぜモノに対してそれほど否定的なのですか？ 問題は、人々がランタイムの違いを本当に理解したくないということだと思います。 Mono 2.4でLinux用の.NETアプリケーションを起動したが、すぐには起動しませんでした。つまり、Monoは完全に悪いので、使用しません。 そして最後に、唯一の方法は非難することであり、その実装はMS.NETとはわずかに異なります。 新しいMonoバージョンは2ヶ月に1回リリースされ、実装は長い間修正されていますが、人々は詳細を理解することを望まず、貧しいMonoを歩き続け、大切にし続けています。



今日は、ランタイムが異なる場合の例をいくつか示します。 もちろん、すべての違いを持ち出すことはできません-あなたはそれについて本全体を書くことができます。 はい。また、非常にクールな問題を製品コードから引き出すこともできません。ソフトウェアアーキテクチャのコンテキストからそれらを分離して、理解しやすい小さなコードの形にすることは非常に困難です。 今日の私の仕事は、MonoとMS.NETの違いを伝えることです。 これが初心者のMonoプログラマーが、「Mono dumb」という言葉を振り返るのではなく、発生する問題をより広く見て対処するのに役立つことを願っています。

例1.異なるバージョンのコンパイラー

非常に簡単な例から始めましょう。 C＃プログラムがあり、それをコンパイルしたいとします。 知っているように、標準コンパイラは単にC＃コードを対応するILコードに変換し、アセンブリの形式で実行します。 さらに、翻訳プロセスには特に巧妙な最適化が含まれていません。JITが最適化を担当しているためです。 翻訳は非常に簡単であり、経験豊富な.NET開発者は多くの場合、どのようなILコマンドが発生するかを把握できます。 しかし、何らかの理由で、多くの開発者はこのプロセスが明確であることを確信しています。 「ソースプログラムをILにマップする方法はまさに1つである」ということを証明しようと、かなり熱烈な議論がいくつかありました。 通常、人々は「仕様があります！」という素晴らしい議論でこれを動機付けます。 仕様では多くの有用なことが述べられていることを保証したいのですが、任意の番組を放送するための唯一のオプションについては何も言われていません。 さらに、コンパイラのバージョンが異なると、翻訳ロジックが異なる場合があります。 これを説明する非常に簡単な例を取り上げました。 次のコードを検討してください。

 var numbers = new int[] { 1, 2, 3 };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Mono 2.10+およびMS.NETでは、次のようなものが表示されます。

 IL_0000: ldc.i4.3 IL_0001: newarr [mscorlib]System.Int32 IL_0006: dup IL_0007: ldtoken field valuetype '<PrivateImplementationDetails>{de495e46-bf42-4605-a020-39ddddfe413c}'/'$ArrayType=12' '<PrivateImplementationDetails>{de495e46-bf42-4605-a020-39ddddfe413c}'::'$field-0' IL_000c: call void class [mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class [mscorlib]System.Array, valuetype [mscorlib]System.RuntimeFieldHandle) IL_0011: stloc.0 // ... .field assembly static valuetype '<PrivateImplementationDetails>{de495e46-bf42-4605-a020-39ddddfe413c}'/'$ArrayType=12' '$field-0' at D_00004000 // ... .data D_00004000 = bytearray ( 01 00 00 00 02 00 00 00 03 00 00 00) // size: 12
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例からわかるように、ソース要素の値は特別なバイト配列に保存されます。 しかし、Mono 2.4.4の時代（信じられませんが、それを使用する人はまだいます）、コンパイラはそれほど賢くありませんでした：

 IL_0000: ldc.i4.3 IL_0001: newarr [mscorlib]System.Int32 IL_0006: dup IL_0007: ldc.i4.0 IL_0008: ldc.i4.1 IL_0009: stelem.i4 IL_000a: dup IL_000b: ldc.i4.1 IL_000c: ldc.i4.2 IL_000d: stelem.i4 IL_000e: dup IL_000f: ldc.i4.2 IL_0010: ldc.i4.3 IL_0011: stelem.i4 IL_0012: stloc.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、ここでは次のことが起こります。

 var numbers = new int[3]; numbers[0] = 1; numbers[1] = 2; numbers[2] = 3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

機能的には何も変更されていませんが、コンパイラのバージョンが異なると異なるコードを生成できることがわかりました。 ただし、コードの動作は同じままであるため、この例はそれほど興味深いものではありません（Monoの古いバージョンのパフォーマンスのわずかな低下を除きます）。 さらに興味深い例に移りましょう。

例2. ILを使用した作業の違い

実践では、MS.NETとMonoで簡単な「自明な」コードがほぼ同じように機能することを示しています。 そして、問題は、コードにそれほど些細なことが現れないときに最もよく起こります。 少し前まで、John Skeetは「文字列が文字列ではないのはいつですか？」 （ impwxからのロシア語翻訳 ）というすばらしい投稿を書きました。 要するに、投稿の内容は、次の例を考慮して削減されます。

 [Description(Value)] class Test { const string Value = "X\ud800Y"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C＃の文字列は、UTF-16の一連の単語です。 そして、 "X\ud800Y"



の値はあまり良く"X\ud800Y"



ません、なぜなら サロゲートペア0xD800



の0xD800



ワードが含まれ、その後0xD800



ワード（間隔0xDC00..0xDFFF



）が0xDC00..0xDFFF



はずですが、代わりにY



（ 0x0059



）が付きます。 ILコードで属性コンストラクターの引数を格納するためにUTF-8が使用されるため、問題が始まります。 ただし、John Skeetにはすべてが非常によく描かれているので、元の投稿を読むことをお勧めします。



この困難な状況でMS.NETとMonoがどのように動作するかに興味がありました（ 詳細なメモ ）。 そして、それらは異なる振る舞いをします。 最初の違いはコンパイル時に見られます。 MS.NETは、 58 ED A0 80 59



としてメタデータに文字列値を配置し、 58 59 BF BD 00



としてMonoを配置します（両方の値は無効なUTF-8行です）。 2番目の違いは、受信したアプリケーションを実行することで確認できます。 MS.NETは両方のバージョンを実行し、属性引数の値（それぞれ0058 fffd fffd 0059



および0058 0059 fffd fffd 0000



の形式）を正常に取得でき、Monoはそのような無効な文字列をチョークして、それぞれの場合にnull



を返しnull



。 このため、Monoで実行しようとすると、ジョンスキートの小さな例がすぐに見つかりました。



問題は、エンコーディング間で文字列を変換する異なる実装にあります。 この例が気に入っているのは、そのミニマリズムにより、MS.NETとMonoの両方がコンパイル時に異なるILコードを生成し、アプリケーションの起動時に異なるILコードを生成できることを示しているためです。

例3. Monoのバグ

はい、Monoにはバグがあります。 そして、はい、彼らは非常に少なくありません、私たちはそれと共に生きなければなりません。 幸いなことに、それらをヒットする必要はめったにありません。また、オープンなバグのうち、重大なバグはあまりありません。 1つの話をしましょう。PassportVisionをMonoに移植するとき、あまり気に入らない瞬間に出会いました。 多くの条件に応じて、コード生成を処理し、その場でロジックの一部を作成する必要がありました。 TypeBuilderを使用して新しい型を作成し、これらの型は特定のインターフェイスを実装しました。 Monoでのコード生成について多くの新しいことを学びましたが 、その大部分はコンテキストから簡単に伝えることは非常に困難です。 しかし、1つのバグが非常に簡単に再現されましたTypeBuilder.CreateType()



メソッドは、宣言されたインターフェイスのスコープをチェックしませんでした。 つまりコード

 private interface IFoo {} // ... void Main() { var assemblyBuilder = Thread.GetDomain().DefineDynamicAssembly( new AssemblyName("FooAssembly"), AssemblyBuilderAccess.Run); var moduleBuilder = assemblyBuilder.DefineDynamicModule("FooAssembly"); TypeBuilder typeBuilder = moduleBuilder.DefineType("Foo", TypeAttributes.Public, typeof(object), new[] { typeof(IFoo) }); typeBuilder.CreateType(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MS.NETに該当しました（そうあるべきです）が、Monoでは正常に機能しました。 私はこの状況にあまり満足していなかったので、 バグを始めました。 Xamarinのメンバーに敬意を表します-5日後に修正しました。 Mono 3.8.0（8月にリリースされた）を使用している場合、このバグは引き続き存在しますが、Mono 3.10.0 は修正されました 。



この問題は特に重大ではありませんが、それでも多くの不便を私に与えました。 ただし、バグトラッカーにはまだ約5,000件の未解決の問題があります。 したがって、Monoには特定のエラーがあり、小さな瞬間の動作がバージョンごとに変わる可能性があることに留意する必要があります（おそらく、バグレポートのために、更新後に誰かが動作を停止したためです）。 可能であれば、Monoの最新の安定バージョンの下に座った方が良いでしょう。

例4. .NETのバグ

そのような会話の後、石は通常モノの方向に飛び始めます。彼らはそれは一種の悪いことであり、それにバグがあると言います。 そして、誰もがマイクロソフトがバグを行っていることをどういうわけか忘れています。 次の話では、私の友人に一定数の神経細胞がかかりました。 次のコミットの後、ビルドサーバーはテストが失敗したことを報告しました。 さらに、稼働中のマシンではすばらしい仕事をしましたが、ビルドサーバーに落ちました。 バグの検索方法に関する魅力的な説明は省略し、要点を説明します。ビルドサーバーと作業マシンに異なるバージョンの.NET Frameworkがインストールされました：4.0および4.5。 しかし、バグ自体はその行でした

 new Uri("http://localhost/%2F1").AbsoluteUri
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TargetFrameworkに応じて異なる結果を生成します（ 詳細な注 ）。 4.0では、スラッシュエスケープ（別名%2F



）のバグがありました。この行はhttp://localhost//1



返しました。 このバグはRFC 3986に従って4.5で修正され、新しい結果はhttp://localhost/%2F1



。



そして、Monoはどうですか？ また、8月に修正された同様のバグがありました（修正はMono 3.10.0に含まれています）。 この例は、同じ問題が異なる.NET実装で発生し、新しいバージョンで修正できることを教えてくれます。 真のクロスプラットフォームアプリケーションは、バージョンごとに変更されたプラットフォーム機能を使用しないか、さまざまなランタイムで機能し続けるために非常に有能に使用する必要があります。

例5.標準クラスの実装の微妙さ

別の有益な話をさせてください。 ある優れた会社の社員は、構造をハッシュテーブルのキーとして使用することを決定しました。 悪いことは何もありませんでした。アプリケーションは正常に動作しました。 少し遅くなりましたが、それほど重大ではありません。 そして、ある日、連中はMonoでアプリケーションを起動することにしました。 そして、見よ：それは何倍も速く動き始めた。 「ああ、なんて良いモノなのか、その下ですべてがどれだけ速く機能するのか」と彼らは喜んだ。 私を悩ませた唯一のことは、そうではなく、どこかが間違っていたという考えでした。



この例を理解するには、MS.NETの構造に対するGetHashCodeの実装について少し読む必要があります（ 優れたハブポスト）。 つまり、ハッシュ関数には2つのバージョンがあります。1つは参照フィールドとフィールド間の空きスペースのない構造用で、もう1つは他のすべてのバージョン用です。 思慮深い読者が推測したかもしれませんが、私たちの仲間はキー構造でうまくいきませんでした（つまり、フィールド間に「穴」がありました;明示的なGetHashCode（）を登録することを誰も気にしませんでした）。 そしてこの場合、構造の最初のフィールドに基づいたハッシュ関数の2番目のバージョンが使用されます。 例を考えてみましょう：

 var a1 = new KeyValuePair<int, int>(1, 2); var a2 = new KeyValuePair<int, int>(1, 3); Console.WriteLine(a1.GetHashCode() == a2.GetHashCode()); var b1 = new KeyValuePair<int, string>(1, "x"); var b2 = new KeyValuePair<int, string>(1, "y"); Console.WriteLine(b1.GetHashCode() == b2.GetHashCode());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、MS.NETでFalse True



を出力します。 ハッシュa1



とa2



は異なり（すべてのフィールドに基づいて計算されます）、 b1



とb2



ハッシュは一致します（最初のフィールドに基づいてのみ計算されます）。 Mono開発者は、さまざまなバージョンのハッシュ関数に煩わされないことに決めました。彼らは、すべてのフィールドに基づいて機能するものを作成しました（ GetHashCodeおよびInternalGetHashCodeを参照）。 したがって、上記のコードはすべてのハッシュが異なるため、モノラルの下でFalse False



を出力します。



ハッシュテーブルを使用して、楽しい仲間に話を戻しましょう。 状況を正しい角度から見ると、そのアプリケーションはMonoでは動作しませんでしたが、MS.NETでは動作が遅くなりました。 そして、最初のフィールドが一致するため、多くのキーが同じハッシュを持っているという事実のため、速度が低下しました。 些細なことのように思えますが、パフォーマンスにはかなり強い影響がありました。



ご存知のとおり、.NETの内部構造について誰かに話すと、彼らはしばしばフレーズで私を批判します。「なぜこれをすべて知る必要があるのですか。 このような内部実装の詳細は、現実の世界では決して役に立ちません 。」 そして、私は答えます：「まあ、もちろん、彼らは誰にも役に立たないでしょう。」

.NEXT

私はそのような物語を非常に長い間毒殺することができますが、この投稿では、一般的な問題の概要を示し、人々にもう一度考えさせたいだけでした。 C＃プログラムが環境に応じて異なる動作をする複雑な世界に住んでいるという事実を考えてください。 動作の違いは、.NETアプリケーションがさまざまなプラットフォームで迅速かつ安定して動作することを保証するために対処できる非常に具体的なものにかかっています。



もっとおもしろい話を聞きたい場合は、 .NEXTカンファレンス（2014年12月8日、モスクワ、ラディソンスラビャンスカヤ）の一環として私のレポートをご覧ください。 引き続き、さまざまなプラットフォームのトピックについて説明します。メモリを操作するMonoの機能と、JITコンパイラの実装の違いについて説明します。 そして、私は一日中サイトをさまようことになるので、.NETについてキャッチしてチャットすることができます。



また、Habrazhiteliの楽しいストーリーが十分にあることを願っています。 私は彼らを聞いてうれしいです=）