提案：ハッシュランダム化サポートを追加

public static HashCode Randomized<T> { get; } // or CreateRandomized<T>
or 
public static HashCode Randomized(Type type); // or CreateRandomized(Type type)

同じタイプの同じランダム化ハッシュを取得するには、 TまたはType typeが必要です。

提案：コレクションのサポートを追加する

public HashCode Combine<T>(T[] values);
public HashCode Combine<T>(T[] values, IEqualityComparer<T> comparer);
public HashCode Combine<T>(Span<T> values);
public HashCode Combine<T>(Span<T> values, IEqualityComparer<T> comparer);
public HashCode Combine<T>(IEnumerable<T> values);
public HashCode Combine<T>(IEnumerable<T> IEqualityComparer<T> comparer);

次のコードHashCode.Empty.Combine(_field1).Combine(_field2).Combine(_field3).Combine(_field4).Combine(_field5);は、Combine呼び出しなしでインライン最適化する必要があるため、オーバーロードCombine(_field1, _field2, _field3, _field4, _field5)は必要ないと思います。

@AlexRadch

提案：コレクションのサポートを追加する

はい、それはこの提案の最終的な計画の一部でした。 ただし、これらのメソッドを追加する前に、APIがどのように表示されるかに焦点を当てることが重要だと思います。

彼は、coreclrの文字列に使用されるMarvin32ハッシュなど、別のアルゴリズムを使用したいと考えていました。 これには、HashCodeのサイズを8バイトに拡張する必要があります。

4バイトまたは8バイト相当のデータを内部に格納するHash32およびHash64タイプがあるのはどうですか？ それぞれの長所/短所を文書化します。 Hash64はXには適していますが、速度が低下する可能性があります。 Hash32の方が高速ですが、分散されていない可能性があります（または実際のトレードオフは何でも）。

彼はハッシュシードをランダム化したかったので、ハッシュは決定論的ではありませんでした。

これは便利な動作のようです。 しかし、私はこれを制御したい人々を見ることができました。 したがって、ハッシュを作成するには2つの方法が必要です。1つはシードを取得しない（そしてランダムシードを使用する）方法で、もう1つはシードを提供できるようにする方法です。

注：Roslynは、これがFxで提供されることを望んでいます。 ユーザーにGetHashCodeを吐き出す機能を追加しています。 現在、次のようなコードを生成します。

c# public override int GetHashCode() { var hashCode = -1923861349; hashCode = hashCode * -1521134295 + this.b.GetHashCode(); hashCode = hashCode * -1521134295 + this.i.GetHashCode(); hashCode = hashCode * -1521134295 + EqualityComparer<string>.Default.GetHashCode(this.s); return hashCode; }

これは素晴らしい経験ではなく、多くの醜い概念を明らかにします。 代わりに呼び出すことができるHash.WhateverAPIがあるとワクワクします。

ありがとう！

MurmurHashはどうですか？ 適度に高速で、非常に優れたハッシュ特性を備えています。 また、2つの異なる実装があります。1つは32ビットハッシュを吐き出すもので、もう1つは128ビットハッシュを吐き出すものです。

32ビット形式と128ビット形式の両方のベクトル化された実装もあります。

@tannergooding MurmurHashは高速ですが、このブログ投稿の音からすると安全ではありません。

@jkotas 、昨年の議論以来、32ビットで4バイトを超える構造体に対してより良いコードを生成することに関してJITで何か作業がありましたか？ また、 @ CyrusNajmabadiの提案についてどう思いますか？

4バイトまたは8バイト相当のデータを内部に格納するHash32およびHash64タイプがあるのはどうですか？ それぞれの長所/短所を文書化します。 Hash64はXには適していますが、速度が低下する可能性があります。 Hash32の方が高速ですが、分散されていない可能性があります（または実際のトレードオフは何でも）。

私はまだこのタイプが開発者に提供するのに非常に価値があると思います、そしてそれが2.0でそれを持っていることは素晴らしいでしょう。

@jamesqo 、この実装は暗号的に安全である必要はないと思います（これが、明示的な暗号ハッシュ関数の目的です）。

また、その記事はMurmur2にも適用されます。 この問題は、Murmur3アルゴリズムで解決されました。

昨年の議論以来、32ビットで4バイトを超える構造体に対してより良いコードを生成することに関するJIT

私は何も知りません。

@CyrusNajmabadiの提案についてどう思いますか

フレームワークタイプは、95％以上のケースでうまく機能する単純な選択である必要があります。 それらは最速のものではないかもしれませんが、それは問題ありません。 Hash32とHash64のどちらかを選択するのは簡単な選択ではありません。

それは私にとっては大丈夫です。 しかし、少なくともこれらの95％のケースに対して十分な解決策を得ることができますか？ 今は何もありません...：-/

hashCode = hashCode * -1521134295 + EqualityComparer.Default.GetHashCode（this.s）;

@CyrusNajmabadiなぜthis.s.GetHashCode（）だけでなく、ここでEqualityComparerを呼び出しているのですか？

非構造体の場合：nullをチェックする必要がないようにします。

これは、舞台裏でも匿名型に対して生成するものに近いものです。 既知のnull以外の値の場合を最適化して、ユーザーにとってより快適なコードを生成します。 ただし、このためのAPIが組み込まれていると便利です。

EqualityComparer.Default.GetHashCodeの呼び出しは、nullをチェックするよりも10倍以上高価です。

EqualityComparer.Default.GetHashCodeの呼び出しは、nullをチェックするよりも10倍以上コストがかかります。

問題のように聞こえます。 良いハッシュコードAPIがあれば、Fxで呼び出すことができます:)

（また、匿名型でもその問題が発生します。これは、そこで生成されるものでもあるためです）。

タプルに対して何をするかはわかりませんが、似ていると思います。

タプルに対して何をするかはわかりませんが、似ていると思います。

System.Tupleは、歴史的な理由でEqualityComparer<Object>.Defaultを通過します。 System.ValueTupleは、nullチェックを使用してObject.GetHashCodeを呼び出します-https ：//github.com/dotnet/coreclr/blob/master/src/mscorlib/shared/System/ValueTuple.cs#L809。

大野。 タプルは「HashHelpers」を使用できるようです。 ユーザーが同じ利益を得ることができるように、それを公開することはできますか？

素晴らしい。 私は同じようなことをしてうれしいです。 匿名タイプから始めたのは、それらが妥当なベストプラクティスであると考えたためです。 そうでない場合は、それで問題ありません。 :)

しかし、それは私がここにいる理由ではありません。 私は実際にハッシュを効果的に組み合わせるシステムを手に入れるためにここにいます。 それが提供できる場合は、乱数をハードコーディングしてハッシュ値を自分で組み合わせるのではなく、喜んでその呼び出しに移ります。

コンパイラーが生成したコードに最適だと思うAPIの形は何でしょうか？

文字通り、以前に提示された32ビットソリューションのいずれも私には問題ありません。 ちなみに、64ビットソリューションは私には問題ありません。 「ハッシュをある種の合理的な方法で組み合わせて、合理的に分散された結果を生成できる」という、取得できるAPIの一種です。

私はこれらのステートメントを調整することはできません：

サイズが4バイトの不変のHashCode構造体がありました。 提供されたハッシュコードをDJBX33Xのようなアルゴリズムを介して独自のハッシュコードと混合し、新しいHashCodeを返すCombine（int）メソッドがありました。

@jkotasは、DJBX33Xのようなアルゴリズムが十分に堅牢であるとは考えていませんでした。

と

フレームワークタイプは、95％以上のケースでうまく機能する単純な選択である必要があります。

95％のケースで十分に機能する単純な32ビットの累積ハッシュを思い付くことができませんか？ ここでうまく処理されていないケースは何ですか、そしてなぜそれらが95％のケースにあると思いますか？

@jkotas 、パフォーマンスはこのタイプにとって本当に重要ですか？ 平均して、ハッシュテーブルルックアップのようなものであり、これはいくつかの構造体コピーよりもはるかに時間がかかると思います。 ボトルネックであることが判明した場合は、APIのリリース後に32ビットの構造体コピーを最適化するようJITチームに依頼して、最適化に取り組んでいる人がいないときにこのAPIをブロックするのではなく、何らかのインセンティブを得るのが妥当でしょうか。コピー？

95％のケースで十分に機能する単純な32ビットの累積ハッシュを思い付くことができませんか？

デフォルトでは、文字列の32ビット累積ハッシュが非常にひどく焼かれています。そのため、.NETCoreの文字列のMarvinハッシュ-https：//github.com/dotnet/corert/blob/87e58839d6629b5f90777f886a2f52d7a99c076f/src/System.Private.CoreLib/ src / System / Marvin.cs＃L25。 ここで同じ過ちを繰り返したくないと思います。

@jkotas 、パフォーマンスはこのタイプにとって本当に重要ですか？

パフォーマンスは重要ではないと思います。 このAPIは自動生成されたコンパイラコードで使用されるように見えるので、見た目よりも小さい生成コードを優先する必要があると思います。 非流暢なパターンはより小さなコードです。

文字列のハッシュを累積するデフォルトの32ビットは本当にひどく焼かれています

それは95％の場合のようには思えません。 私たちは通常の開発者が、今日手動で物事を行うすべてのタイプに「十分に良い」ハッシュを望んでいることについて話している。

このAPIは自動生成されたコンパイラコードで使用されるように見えるので、見た目よりも小さい生成コードを優先する必要があると思います。 非流暢なパターンはより小さなコードです。

これはRoslynコンパイラでは使用できません。 これは、ユーザーがタイプのGetHashCodesを生成するのを支援するときにRoslynIDEが使用するためのものです。 これは、ユーザーが表示して維持する必要のあるコードであり、次のような賢明なものがあります。

`` `c＃
Hash.Combine（this.A？.GetHashCode（）?? 0、
this.B？.GetHashCode（）?? 0、
this.C？.GetHashCode（）?? 0）;

is a lot nicer than a user seeing and having to maintain:

```c#
            var hashCode = -1923861349;
            hashCode = hashCode * -1521134295 + this.b.GetHashCode();
            hashCode = hashCode * -1521134295 + this.i.GetHashCode();
            hashCode = hashCode * -1521134295 + EqualityComparer<string>.Default.GetHashCode(this.s);
            return hashCode;

つまり、Fxにはすでにこのコードがあります。

https://github.com/dotnet/roslyn/blob/master/src/Compilers/Test/Resources/Core/NetFX/ValueTuple/ValueTuple.cs#L5

タプルには十分だと思います。 自分のタイプで利用できるようにすることがなぜそんなに問題になるのか、私にはわかりません。

注：これをroslynで行うことも検討しました。

c# return (this.A, this.B, this.C).GetHashCode();

しかし今、あなたは人々に、ある種の合理的なデフォルトのハッシュ動作を得るためだけに（潜在的に大きな）構造体を生成するように強制しています。

私たちは通常の開発者が、今日手動で物事を行うすべてのタイプに「十分に良い」ハッシュを望んでいることについて話している。

元の文字列ハッシュは、通常の開発者にとってうまく機能する「十分に良い」ハッシュでした。 しかし、ASP.NET Webサーバーは、受信したものをハッシュテーブルに保存する傾向があるため、DoS攻撃に対して脆弱であることが発見されました。 したがって、「十分に良い」ハッシュは基本的に悪いセキュリティ問題になりました。

タプルには十分だと思います

必ずしもそうとは限りません。 タプルのバックストップ測定を行い、ハッシュコードをランダム化して、後でアルゴリズムを変更するオプションを提供しました。

     return Hash.Combine(this.A?.GetHashCode() ?? 0,
                         this.B?.GetHashCode() ?? 0,
                         this.C?.GetHashCode() ?? 0);

これは私には合理的に見えます。

私はあなたのポジトインを取得しません。 あなたは2つのことを言っているようです：

元の文字列ハッシュは、通常の開発者にとってうまく機能する「十分に良い」ハッシュでした。 しかし、ASP.NET Webサーバーは、受信したものをハッシュテーブルに保存する傾向があるため、DoS攻撃に対して脆弱であることが発見されました。 したがって、「十分に良い」ハッシュは基本的に悪いセキュリティ問題になりました。

その場合は、セキュリティやDoSに懸念がある人に適したハッシュコードを提供しましょう。

フレームワークタイプは、95％以上のケースでうまく機能する単純な選択である必要があります。

その場合は、95％のケースに十分なハッシュコードを提供しましょう。 セキュリティ/ DoSに懸念がある人は、その目的のために文書化された専用のフォームを使用できます。

必ずしもそうとは限りません。 タプルのバックストップ測定を行い、ハッシュコードをランダム化して、後でアルゴリズムを変更するオプションを提供しました。

Ok。 ユーザーが同じメカニズムを使用できるように、それを公開できますか？

-
「普遍的な解決策を作ることができないので、誰もが自分で解決しなければならない」と言っているように聞こえるので、私はここで本当に苦労しています。 これは、最悪の場所の1つに思えます。確かに、ほとんどのお客様は、DoSの懸念のために独自の「マービンハッシュ」を作成することを考えていないためです。 それらは、フィールドハッシュを1つの最終ハッシュに追加、排他的論理和、またはその他の方法でうまく組み合わせていないだけです。

95％のケースを気にする場合は、一般的に優れたenoghハッシュを作成する必要があります。 5％のケースを気にする場合は、そのための特別なソリューションを提供できます。

これは私には合理的に見えます。

すばらしい:)次に公開できますか：

`` `c＃
名前空間System.Numerics.Hashing
{{
内部静的クラスHashHelpers
{{
public static readonly int RandomSeed = new Random（）。Next（Int32.MinValue、Int32.MaxValue）;

    public static int Combine(int h1, int h2)
    {
        // RyuJIT optimizes this to use the ROL instruction
        // Related GitHub pull request: dotnet/coreclr#1830
        uint rol5 = ((uint)h1 << 5) | ((uint)h1 >> 27);
        return ((int)rol5 + h1) ^ h2;
    }
}

Roslyn could then generate:

```c#
     return Hash.Combine(Hash.RandomSeed,
                         this.A?.GetHashCode() ?? 0,
                         this.B?.GetHashCode() ?? 0,
                         this.C?.GetHashCode() ?? 0);

これには、ほとんどの場合に実際に「十分に良い」という利点がありますが、ランダムでないハッシュに依存しないように、ランダムな値で初期化するという良い道を人々に導きます。

セキュリティ/ DoSに懸念がある人は、その目的のために文書化された専用のフォームを使用できます。

すべてのASP.NETアプリには、セキュリティ/ DoSの懸念があります。

すばらしい:)次に公開できますか：

これは私が合理的だと言ったこととは異なります。

https://github.com/aspnet/Common/blob/dev/shared/Microsoft.Extensions.HashCodeCombiner.Sources/HashCodeCombiner.csについてどう思いますか。 これは、ASP.NETの内部で今日多くの場所で使用されているものであり、私が非常に満足しているものです（ただし、結合関数をより強力にする必要があります。実装の詳細を調整し続けることができます）。

@jkotas聞いたよ：p

したがって、ここでの問題は、開発者がDoS攻撃の影響を受けやすい時期がわからないことです。これは、開発者がそれについて何も考えていないためです。そのため、Marvin32を使用するように文字列を切り替えました。

それを証明する方法がないので、「95％のケースは問題ではない」という道を進むべきではありません。パフォーマンスコストがあっても、注意を怠る必要があります。 それから離れる場合は、ハッシュコードの実装には、「これで十分だ」と判断するだけでなく、暗号化ボードのレビューが必要です。

すべてのASP.NETアプリには、セキュリティ/ DoSの懸念があります。

Ok。 では、今日、誰もハッシュコードの助けを借りていないため、うまく機能していない可能性があるという問題にどのように対処していますか？ 明らかに、そのような世界の状態を持つことは容認されています。 では、今日人々が手で転がしているものよりもパフォーマンスが優れていると思われる合理的なハッシュシステムを提供することによって何が害されるのでしょうか。

それを証明する方法がないので、パフォーマンスが犠牲になったとしても、注意を怠らなければなりません。

あなたが何かを提供しなければ、人々はただひどいことをし続けるでしょう。 完璧なものが何もないという理由で「十分に良い」を拒否することは、今日の現状が悪いことを意味します。

すべてのASP.NETアプリには、セキュリティ/ DoSの懸念があります。

これを説明できますか？ 私が理解しているように、任意の入力を受け入れて、入力を特別に細工できる場合はパフォーマンスが低下するデータ構造にそれを格納する場合、DoSの懸念があります。 わかりました、それがユーザーから来たWebシナリオで取得する文字列に関する懸念事項であることがわかりました。

では、このシナリオで使用されていない残りのタイプにどのように適用されるのでしょうか。

次のタイプのセットがあります。

1. DoSセーフである必要があるユーザータイプ。 現在、私たちは支援するものを何も提供していません。そのため、人々が正しいことをしていない可能性が高いため、私たちはすでに悪い場所にいます。
2. DoSセーフである必要のないユーザータイプ。 現在、私たちは支援するものを何も提供していません。そのため、人々が正しいことをしていない可能性が高いため、私たちはすでに悪い場所にいます。
3. DoSセーフである必要があるフレームワークタイプ。 現在、それらをDoSセーフにしていますが、APIを介して公開していません。
4. DoSセーフである必要のないフレームワークのタイプミス。 現在、ハッシュを提供していますが、APIを介して公開していません。

基本的に、これらのケースは重要であると考えていますが、「1」または「2」を処理するソリューションをユーザーに実際に提供するには十分ではありません。 「2」の解決策が「1」に適さないのではないかと心配しているので、そもそもそれを提供することすらしません。 そして、「1」の解決策を提供する気さえなければ、私たちは信じられないほど奇妙な立場にいるように感じます。 私たちはDoSingとASPについて心配していますが、実際に人々を助けるために心配していません。 そして、私たちはそれで人々を助けないので、DoS以外のケースでそれを助けるつもりさえありません。

-

これらの2つのケースが重要である場合（私はそれを受け入れても構わないと思っています）、2つのAPIを提供しないのはなぜですか？ それらを文書化します。 彼らが何のためにあるのかを明確にしてください。 人々がそれらを適切に使用するならば、素晴らしい。 人々がそれらを適切に使用しなくても、それでも問題ありません。 結局のところ、彼らはとにかく今日は物事を適切に行っていない可能性が高いので、物事はどのように悪化していますか？

についてどう思いますか

私はどちらの方法でも意見がありません。 顧客が使用できるAPIであり、許容できるパフォーマンスを発揮し、明確なコードを備えたシンプルなAPIを提供するのであれば、それで問題ないと思います。

フィールド/プロパティのセットを順序付けられた方法で結合したいという99％のケースを処理する、単純な静的フォームがあると便利だと思います。 そのようなものをこのタイプにかなり簡単に追加できるようです。

シンプルな静的な形があればいいと思います

同意。

フィールド/プロパティのセットを順序付けられた方法で結合したいという99％のケースを処理する、単純な静的フォームがあると便利だと思います。 そのようなものをこのタイプにかなり簡単に追加できるようです。

同意。

ある種のAPIが実現するのを本当に見たいので、これについては途中でお会いしましょう。 @jkotas不変のインスタンスベースのAPIを追加することに反対していることを私はまだ理解していません。 最初に、32ビットコピーが遅いためだと言いました。次に、可変APIがより簡潔になるためです（これは正しくありません。 h.Combine(a).Combine(b) （不変バージョン）はh.Combine(a); h.Combine(b); （可変バージョン）よりも短いです）バージョン））。

そうは言っても、私は戻って喜んで：

public static class HashCode
{
    public static int Combine<T>(T value1, Tvalue2);
    public static int Combine<T>(T value1, Tvalue2, IEqualityComparer<T> comparer);
    public static int Combine<T>(T value1, Tvalue2, T value3);
    public static int Combine<T>(T value1, Tvalue2, T value3, IEqualityComparer<T> comparer);
    public static int Combine<T>(T value1, Tvalue2, T value3, T value4);
    public static int Combine<T>(T value1, Tvalue2, T value3, T value4, IEqualityComparer<T> comparer);
    // ... All the way until value8
}

これは合理的だと思いますか？

現在、投稿を編集することはできませんが、すべてのメソッドがTを受け入れることができるわけではないことに気付きました。その場合、すべてのintを受け入れる8つのオーバーロードがあり、ユーザーにGetHashCodeを呼び出させることができます。

これらの2つのケースが重要である場合（私はそれを受け入れても構わないと思っています）、2つのAPIを提供しないのはなぜですか？ それらを文書化します。 彼らが何のためにあるのかを明確にしてください。 人々がそれらを適切に使用すれば、素晴らしい。 人々がそれらを適切に使用しなくても、それでも問題ありません。 結局のところ、彼らはとにかく今日は物事を適切に行っていない可能性が高いので、状況はどのように悪化していますか？

彼らがそこにいるとき、人々は物事を適切に使用しないからです。 簡単な例、XSSを見てみましょう。 最初から、Webフォームでさえ出力をHTMLエンコードする機能がありました。 ただし、開発者はリスクを知らず、適切に行う方法も知らず、手遅れになったときにのみアプリが公開され、認証Cookieが解除されました。

人々にセキュリティの選択を与えることは、彼らが彼らを前提としています

1. 問題について知ってください。
2. リスクが何であるかを理解します。
3. それらのリスクを評価できます。
4. 正しいことを簡単に見つけることができます。

これらの仮定は、一般的に大多数の開発者には当てはまりません。彼らは、手遅れになったときにのみ問題を見つけます。 開発者はセキュリティ会議に参加せず、ホワイトペーパーを読んだり、ソリューションを理解したりしません。 そのため、ASP.NET HashDoSシナリオでは、それらを選択しました。これは正しいことであり、最大の影響を与えたため、デフォルトで保護しました。 しかし、それを文字列にのみ適用したため、ユーザー入力からカスタムクラスを構築していた人々は悪い場所に置かれました。 私たちは正しいことをし、今すぐそれらの顧客を保護し、それをデフォルトにして、失敗ではなく成功の落とし穴を持たせる必要があります。 セキュリティのためのAPI設計は、選択ではなく、ユーザーがそれを知っているかどうかに関係なく支援することを目的としている場合があります。

ユーザーはいつでもセキュリティに焦点を当てていないハッシュを作成できます。 したがって、2つのオプションが与えられます

1. デフォルトのハッシュユーティリティはセキュリティに対応していません。 ユーザーはセキュリティを意識したハッシュ関数を作成できます
2. デフォルトのハッシュユーティリティはセキュリティに対応しています。 ユーザーは、セキュリティを意識しないカスタムハッシュ関数を作成できます

次に、2番目の方がおそらく優れています。 そして、提案されていることは、暗号化ハッシュに対するフルのパフォーマンスへの影響はありません。 だからそれは良い妥協点になりますか？

これらのスレッドで実行されている質問の1つは、どのアルゴリズムがすべての人に最適かということです。 完璧なアルゴリズムは1つもないと言っても過言ではありません。 ただし、 @ CyrusNajmabadiが示しているような、一般的な.NET入力のエントロピーが不十分な傾向があるコードやその他の一般的なハッシャーバグ（入力データの損失や簡単なものなど）よりも優れたコードを提供することを

「最良のアルゴリズム」の問題を回避するためのいくつかのオプションを提案したいと思います。

1. 明示的な選択：暗号化されていないハッシュのスイート（たとえば、xxHash、Marvin32、およびSpookyHash）のAPI提案をすぐに送信することを計画しています。 このようなAPIの使用法は、HashCodeまたはHashCodeHelperタイプとは少し異なりますが、説明のために、これらの違いを解決できると仮定します。 GetHashCodeにそのAPIを使用する場合：
   
   
   
   • 生成されたコードは、それが何をしているのかを明示しています。RoslynがMarvin32.Create();生成すると、パワーユーザーはそれが何をすることに決めたかを知ることができ、必要に応じてスイート内の別のアルゴリズムに簡単に変更できます。
   
   
   • これは、変更を壊すことを心配する必要がないことを意味します。 非ランダム化/不十分なエントロピー/遅いアルゴリズムから始める場合は、Roslynを更新するだけで、新しいコードで他の何かを生成し始めることができます。 古いコードは古いハッシュを使用し続け、新しいコードは新しいハッシュを使用します。 開発者（またはRoslynコード修正）は、必要に応じて古いコードを変更できます。
   
   
   • 私が考えることができる最大の欠点は、GetHashCodeに必要な最適化のいくつかが、他のアルゴリズムに悪影響を与える可能性があることです。 たとえば、32ビットの内部状態は不変の構造体でうまく機能しますが、（たとえば）CityHashの256ビットの内部状態はコピーに多くの時間を浪費する可能性があります。
   
   

1. ランダム化：適切にランダム化されたアルゴリズムから始めます（ランダムな初期値で示されたコード@CyrusNajmabadiは、ランダム性を洗い流す可能性があるため、カウントされません）。 これにより、互換性の問題なしに実装を変更できるようになります。 アルゴリズムを変更する場合でも、パフォーマンスの変更に非常に注意を払う必要があります。 ただし、アーキテクチャごと（またはデバイスごと）に選択できるため、これも潜在的なメリットになります。 たとえば、このサイトは、xxHashがx64 Macで最速であるのに対し、SpookyHashはXboxとiPhoneで最速であることを示しています。 ある時点でアルゴリズムを変更する目的でこのルートをたどる場合、64ビット以上の内部状態が存在する場合でも妥当なパフォーマンスを維持するAPIの設計を検討する必要があるかもしれません。

CC @ bartonjs 、 @ terrajobst

@morganbr完璧なアルゴリズムは1に加えて、高度な使用のための一連のアルゴリズムDictionary入れるために、マーヴィンが誰であるかを知る必要はありません。

オブジェクトを辞書に入れるために、マーヴィンが誰であるかを知る必要はありません。

私はあなたがそれを置く方法が好きです。 私はあなたが辞書自体について言及したことも好きです。 IDictionaryは、あらゆる種類の異なる品質を持つ多数の異なるimplを持つことができるものです（多くのプラットフォームのコレクションAPIを参照してください）。 ただし、すべてのカテゴリで優れているとは限りませんが、全体的にまともな仕事をするベースの「辞書」を提供するだけです。

私はそれが人々のトンは、ハッシュライブラリで探しているものだと思います。 たとえそれがすべての目的に完璧でなくても、仕事を成し遂げる何か。

@morganbr人々は単純に、今日行っていることよりも優れたGetHashCodeを作成する方法を望んでいると思います（通常、Web上の何かからコピーした数学演算のいくつかのグラブバッグの組み合わせ）。 うまく機能する基本的な実装を提供できれば、人々は幸せになります。 特定のハッシュ関数が強く必要な場合は、上級ユーザー向けの舞台裏APIを使用できます。

言い換えれば、今日ハッシュコードを書いている人々は、なぜ彼らが不気味な対マーヴィン対つぶやきを欲するのかを知りも気にもしないでしょう。 それらの特定のハッシュコードの1つを特に必要としている人だけが探しに行きます。 しかし、多くの人は「これが私のオブジェクトの状態です。辞書で使用できる高速な分散ハッシュを生成する方法を提供してくれます。これにより、発生した場合にDOSが実行されなくなると思います。信頼できない入力を取得してハッシュし、保存します。」

@CyrusNajmabadi問題は、現在の互換性の概念を将来に拡張すると、このタイプが出荷されると変更できないことがわかることです（アルゴリズムが「すべてのアプリケーションを攻撃可能にする」方法でひどく壊れていることがわかった場合を除く） ）。

とにかく実行ごとに値に依存することができなかったので、それが安定したランダム化された方法として開始された場合、実装を変更するのが簡単になると一度主張することができます。 しかし、数年後、ハッシュバケットと一般的なケースのパフォーマンスのバランスをとるのに、リストを含む構造を作成するアルゴリズムがあることがわかりました。

モーガンの提案では、今日作成するコードは、事実上、永久に同じパフォーマンス特性を持つことになります。 良くなったかもしれないアプリケーションにとって、これは残念なことです。 悪化したであろうアプリケーションにとって、これは素晴らしいことです。 しかし、新しいアルゴリズムが見つかったら、それをチェックインし、Roslynを変更して（そしてReSharperなどへの変更を提案して）​​、SomeThingThatWasConsideredAwesomeIn2018ではなくNewAwesomeThing2019で生成を開始します。

このようなスーパーブラックボックスは、一度しか実行できません。 そして、私たちは永遠にそれに固執しています。 次に、誰かが次の実装を作成します。これは平均パフォーマンスが優れているため、2つのブラックボックスの実装があり、どちらを選択するのかわかりません。 そして...そして....

したがって、確かに、Roslyn / ReSharper / etcがMarvin32、Murmur、FastHash、またはIntPtr.Sizeに基づく組み合わせ/条件付きを使用してGetHashCodeを自動書き込みした理由がわからない場合があります。 しかし、あなたにはそれを調べる力があります。 そして、新しい情報が明らかになったときに、後でタイプを変更する権限があります...しかし、同じままにする権限も与えられています。 （これを書くと悲しいでしょう。3年後、Roslyn / ReSharper / etcは、新しいアルゴリズムの方がはるかに優れているため、明示的に呼び出すことを避けています...通常）。

@bartonjs .Netがブラックボックスアルゴリズムまたはデータ構造を提供するすべての場所とハッシュが異なる点は何ですか？ たとえば、並べ替え（イントロソート）、 Dictionary （配列ベースの個別のチェーン）、 StringBuilder （8kチャンクのリンクリスト）、ほとんどのLINQ。

今日はこれを詳しく見てきました。 この問題に関する遅延と前後の謝罪。

要件

• APIは誰のためのものですか？
  
  
  
  • APIは強力な暗号化ハッシュを生成する
  
  
  • ただし、APIは、フレームワーク自体（BCLやASP.NETなど）で使用できるように十分に優れている必要があります。
  
  
  • ただし、これは、どこでもAPIを使用する必要があるという意味ではありません。 FXの一部で、セキュリティ/ DOSのリスクのため、またはパフォーマンスのためにカスタムのものを使用したい場合は問題ありません。 例外は常に存在します。
  
  
• このハッシュの望ましいプロパティは何ですか？
  
  
  
  • 入力のすべてのビットが使用されます
  
  
  • 結果はよく分散されます
  
  
  • APIは「a」ハッシュコードを提供しますが、特定のハッシュコードアルゴリズムを保証するものではありません。 これにより、後で別のアルゴリズムを使用したり、別のアーキテクチャで別のアルゴリズムを使用したりできます。
  
  
  • APIは、特定のプロセス内で同じ値が同じハッシュコードを生成することを保証します。 同じアプリの異なるインスタンスは、ランダム化のために異なるハッシュコードを生成する可能性があります。 これにより、コンシューマーがハッシュ値を永続化できず、実行間（またはさらに悪いことに、プラットフォームのバージョン）にわたってハッシュ値が安定していることに誤って依存することがなくなります。
  
  

APIシェイプ

`` `C＃
//コアアセンブリに存在します
// .NET Framework：mscorlib
// .NET Core：System.Runtime / System.Private.CoreLib
名前空間システム
{{
public struct HashCode
{{
public static int Combine（T1値1）;
public static int Combine（T1値1、T2値2）;
public static int Combine（T1値1、T2値2、T3値3）;
public static int Combine（T1値1、T2値2、T3値3、T4値4）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5、T6値6）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5、T6値6、T7値7）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5、T6値6、T7値7、T8値8）;

    public void Add<T>(T value);
    public void Add<T>(T value, IEqualityComparer<T> comparer);
    public void Add<T>(T[] value);
    public void Add<T>(T[] value, int index, int length);
    public void Add(byte[] value);
    public void Add(byte[] value, int index, int length);
    public void Add(string value);
    public void Add(string value, StringComparison comparisonType);

    public int ToHashCode();
}

}

Notes:

* We decided to not override `GetHashCode()` to produce the hash code as this would be weird, both naming-wise as well as from a behavioral standpoint (`GetHashCode()` should return the object's hash code, not the one being computed).
* We decided to use `Add` for the builder patter and `Combine` for the static construction
* We decided to use not provide a static initialization method. Instead, `Add` will do this on first use.
* The struct is mutable, which is unfortunate but we feel the best compromise between making `GetHashCode()` very cheap & not cause any allocations while allowing the structure to be bigger than 32-bit so that the hash code algorithm can use more bits during accumulation.
* `Combine` will just call `<value>.GetHashCode()`, so it has the behavior of the value's type `GetHashCode()` implementation
    - For strings that means different casing will produce different hash codes
    - For arrays, that means the hash code doesn't look at the contents but uses reference semantics for the hash code
    - If that behavior is undesired, the developer needs to use the builder-style approach

### Usage

The simple case is when someone just wants to produce a good hash code for a given type, like so:

```C#
public class Customer
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

    public override int GetHashCode() => HashCode.Combine(Id, FirstName, LastName);
}

より複雑なケースは、開発者がハッシュの計算方法を微調整する必要がある場合です。 アイデアは、次のように、呼び出しサイトがオブジェクト/値ではなく、目的のハッシュを渡すというものです。

`` `C＃
パブリックパーシャルクラスカスタマー
{{
public override int GetHashCode（）=>
HashCode.Combine（
Id、
StringComparer.OrdinalIgnoreCase.GetHashCode（FirstName）、
StringComparer.OrdinalIgnoreCase.GetHashCode（LastName）、
）;
}

And lastly, if the developer needs more flexibility, such as producing a hash code for more than eight values, we also provide a builder-style approach:

```C#
public partial class Customer
{
    public override int GetHashCode()
    {
        var hashCode = new HashCode();
        hashCode.Add(Id);
        hashCode.Add(FirstName, StringComparison.OrdinalIgnoreCase);
        hashCode.Add(LastName, StringComparison.OrdinalIgnoreCase);
        return hashCode.ToHashCode();
    }
}

次のステップ

この問題は引き続き解決されます。 APIを実装するには、使用するアルゴリズムを決定する必要があります。

@morganbrは良い候補者のための提案をします。 一般的に言って、ハッシュアルゴリズムを最初から作成するのではなく、プロパティがよく理解されている有名なアルゴリズムを使用します。

ただし、一般的な.NETワークロードの実装を測定し、どのアルゴリズムが良好な結果（スループットと分散）を生成するかを確認する必要があります。 答えはCPUアーキテクチャによって異なる可能性が高いため、測定する際にはこれを考慮する必要があります。

@jamesqo 、あなたはまだこの分野で働くことに興味がありますか？ その場合は、適宜提案を更新してください。

@terrajobst 、 public static int Combine<T1>(T1 value);も必要な場合があります。 少しおかしいように見えることは知っていますが、入力ハッシュスペースが限られているものからビットを拡散する方法を提供します。 たとえば、多くの列挙型には、コードの下位数ビットのみを使用して、可能なハッシュがいくつかあります。 一部のコレクションは、ハッシュがより広いスペースに分散していることを前提に構築されているため、ビットを拡散すると、コレクションがより効率的に機能する場合があります。

public void Add(string value, StrinComparison comparison);

Nit： StringComparisonパラメーターの名前はcomparisonTypeして、他の場所で使用されている名前と一致させる必要があります。それ以外の場合は、 StringComparisonがパラメーターとして使用されます。

アルゴリズムの選択に役立つ基準は次のとおりです。

1. アルゴリズムには優れた雪崩効果がありますか？ つまり、入力のすべてのビットが出力のすべてのビットを反転する可能性が50％ありますか？ このサイトには、いくつかの一般的なアルゴリズムの研究があります。
2. アルゴリズムは小さな入力に対して高速ですか？ HashCode.Combineは通常8以下の整数を処理するため、スループットよりも起動時間が重要になる場合があります。 このサイトには、最初に興味深いデータセットがあります。 これは、アーキテクチャやその他のピボット（OS、AoTとJITなど）ごとに異なる回答が必要になる場合もあります。

私たちが本当に望んでいるのは、C＃で記述された候補者のパフォーマンスの数値です。これにより、候補者の特性が.NETでも維持されると合理的に確信できます。 あなたが候補者を書き、私たちがこれのためにそれを選ばない場合、私が実際に非暗号化ハッシュAPIのAPI提案をまとめるときはいつでも、それはまだ有用な仕事です。

評価する価値があると思う候補者をいくつか示します（ただし、他の候補者を自由に提案してください）。

• Marvin32（ここにはすでにC＃の実装があります）。 String.GetHashCodeには十分な速度であり、HashDoS耐性があると確信しています。
• xxHash32（SMHasherによると最高品質のx86で最速のアルゴリズム）
• FarmHash（ここではx64です。品質の良い指標は見つかりませんでした。C＃で書くのは難しいかもしれませんが）
• xxHash64（32ビットに切り捨て）（これは明確な速度の勝者ではありませんが、すでにxxHash32がある場合は簡単に実行できる可能性があります）
• SpookyHash（より大きなデータセットでうまくいく傾向があります）

恥Addメソッドは戻り値の型はできませんref HashCodeして返すref this彼らは流暢な方法で使用することができるので、

readonly ref返品でこれが可能になりますか？ / cc @jaredpar @VSadov

警告：インターネット上の既存のコードベースからハッシュ実装を選択した場合は、ソースへのリンクを保持し、ライセンスを確認してください（これも行う必要があります）。

ライセンスに互換性がない場合は、アルゴリズムを最初から作成する必要がある場合があります。

Addメソッドを使用するIMOは、非常にまれなはずです。 それは非常に高度なシナリオのためのものであり、「流暢」であることができる必要性は実際にはありません。

すべてのユーザーコードケースの99％の一般的なユースケースでは、 => HashCode.Combine(...)を使用して問題がないはずです。

@morganbr

public static int Combine<T1>(T1 value);も必要な場合があります。 少しおかしいように見えることは知っていますが、入力ハッシュスペースが限られているものからビットを拡散する方法を提供します

わかる。 追加しました。

@justinvp

Nit： StringComparisonパラメーターの名前はcomparisonTypeして、他の場所で使用されている名前と一致させる必要があります。それ以外の場合は、 StringComparisonがパラメーターとして使用されます。

修理済み。

@CyrusNajmabadi

Addメソッドを使用するIMOは、非常に珍しいはずです。 それは非常に高度なシナリオのためのものであり、「流暢」であることができる必要性は実際にはありません。

同意しました。

@benaadams -再：戻って参照thisからAdd -いいえ、 this 、それは右辺値またはTEMPすることができるため、構造体のメソッドに参照によって返すことはできません。

`` `C＃
ref var r =（new T（））。ReturnsRefThis（）;

// rはここでいくつかの変数を参照します。 どれ？ 範囲/寿命はどのくらいですか？
r = SomethingElse（）;
`` `

比較に役立つ場合のために、数年前にJenkinsのlookup3ハッシュ関数（ Cソース）をここのC＃に移植し

私はコレクションについて疑問に思っています：

@terrajobst

c# public void Add<T>(T[] value);

配列にはオーバーロードがありますが、一般的なコレクション（つまり、 IEnumerable<T> ）にはオーバーロードがないのはなぜですか？

また、 HashCode.Combine(array)とhashCode.Add((object)array)が一方向に動作し（参照の同等性を使用）、 hashCode.Add(array)が別の方向に動作する（値のハッシュコードを組み合わせる）ことは混乱しませんか？配列）？

@CyrusNajmabadi

すべてのユーザーコードケースの99％の一般的なユースケースでは、 => HashCode.Combine(...)を使用するだけで問題ないはずです。

目的が実際に99％のユースケースでCombineを使用できるようにすることである場合（たとえば、80％ではない）、 Combine何らかの方法で値に基づくハッシュコレクションをサポートするべきではありませんコレクションに？ たぶんそれを行う別のメソッド（ HashCode拡張メソッドまたは静的メソッドのいずれか）があるはずですか？

Addが強力なシナリオである場合、ユーザーがObject.GetHashCodeとコレクションの個々の要素の組み合わせのどちらかを選択する必要があると想定する必要がありますか？ それが役立つ場合は、配列（および潜在的なIEnumerable）バージョンの名前を変更することを検討できます。 何かのようなもの：
c# public void AddEnumerableHashes<T>(IEnumerable<T> enumerable); public void AddEnumerableHashes<T>(T[] array); public void AddEnumerableHashes<T>(T[] array, int index, int length);
IEqualityComparersによるオーバーロードも必要かどうか疑問に思います。

提案：コレクション初期化構文をサポートするために、ビルダー構造体にIEnumerableを実装させます。

C# return new HashCode { SomeField, OtherField, { SomeString, StringComparer.UTF8 }, { SomeHashSet, HashSet<int>.CreateSetComparer() } }.GetHashCode()

これは、手動でAdd()呼び出すよりもはるかに洗練されており（特に、一時変数は必要ありません）、割り当てはありません。

詳細

@SLaksおそらく、より良い構文がhttps://github.com/dotnet/csharplang/issues/455を待つ可能性があるため（提案にサポートがあると仮定）、 HashCodeは偽のIEnumerableを実装する必要がありません。

GetHashCode（）をオーバーライドしてハッシュコードを生成しないことにしました。これは、名前付けと動作の両方の観点から奇妙なためです（GetHashCode（）は、計算されているものではなく、オブジェクトのハッシュコードを返す必要があります）。

GetHashCodeが計算されたハッシュコードを返さないのは奇妙だと思います。 これは開発者を混乱させるだろうと思います。 たとえば、 @ SLaksは、 ToHashCodeを使用する代わりに、彼の提案ですでにそれを使用しています。

@justinvp GetHashCode()が計算されたハッシュコードを返さない場合は、おそらく[Obsolete]および[EditorBrowsable(Never)]とマークする必要があります。

一方で、計算されたハッシュコードを返すことによる害は見られません。

@terrajobst

GetHashCode()をオーバーライドしてハッシュコードを生成しないことにしました。これは、名前付けと動作の両方の観点から奇妙なためです（ GetHashCode()は、オブジェクトのハッシュコードではなく、オブジェクトのハッシュコードを返す必要があります）計算中）。

はい、 GetHashCode()はオブジェクトのハッシュコードを返す必要がありますが、2つのハッシュコードが異なる必要がある理由はありますか？ 同じ内部状態を持つHashCode 2つのインスタンスは、 GetHashCode()から同じ値を返すため、それでも正しいです。

@terrajobstあなたのコメントを見ました。 返信が遅れたことをお許しください。どこにも行かなかったのは何度も行ったり来たりするだけだと思ったので、通知を調べるのが遅かったです。 そうでないことを見てうれしいです！ ：多田：

これを手に取って、スループット/分布の測定を行うことができてうれしいです（これは、「この領域での作業に関心がある」という意味だと思います）。 ただし、ここにあるすべてのコメントを読み終えるのに少し時間がかかります。

@terrajobst

変更できますか

public void Add<T>(T[] value);
public void Add<T>(T[] value, int index, int length);
public void Add(byte[] value);
public void Add(byte[] value, int index, int length);

に

public void AddRange<T>(T[] values);
public void AddRange<T>(T[] values, int index, int count);
public void AddRange<T>(T[] values, int index, int count, IEqualityComparer<T> comparer);

？ @svickが言及した動作を回避するために、 Add -> AddRange名前を変更しました。 バイト固有の処理が必要な場合は、メソッド内でtypeof(T) == typeof(byte)を使用することに特化できるため、 byteオーバーロードを削除しました。 また、 value -> valuesとlength -> count 。 比較者に過負荷をかけることも理にかなっています。

@terrajobst理由を思い出していただけますか

        public void Add(string value);
        public void Add(string value, StringComparison comparisonType);

私たちが持っているときに必要です

        public void Add<T>(T value);
        public void Add<T>(T value, IEqualityComparer<T> comparer);

？

@svick

@justinvp GetHashCode（）が計算されたハッシュコードを返さない場合は、おそらく[Obsolete]および[EditorBrowsable（Never）]とマークする必要があります。

：+1：

@terrajobst HashCode -> intからの暗黙的な変換に戻ることができるので、 ToHashCodeメソッドはありませんか？ 編集： ToHashCodeは問題ありません。 以下の@CyrusNajmabadiの応答を参照してください。

@jamesqo StringComparisonは列挙型です。
ただし、代わりに同等のStringComparer使用することもできます。

HashCode-> intから暗黙の変換に戻ることができるので、ToHashCodeメソッドはありませんか？

私たちはこれについて話し合い、会議で反対することを決定しました。 問題は、ユーザーが最後の「int」を取得すると、余分な作業が頻繁に行われることです。 つまり、ハッシュコードの内部は多くの場合、ファイナライズステップを実行し、それ自体を新しい状態にリセットする場合があります。 暗黙の変換でそれが起こるのは奇妙なことです。 これを行った場合：

HashCode hc = ...

int i1 = hc;
int i2 = hc;

その後、異なる結果を得ることができます。

そのため、明示的な変換も好きではありません（人々は変換を内部状態の変更とは考えていないため）。

メソッドを使用すると、これが発生していることを明示的に文書化できます。 できるだけ多くのことを伝えるために、名前を付けることもできます。 つまり、「ToHashCodeAndReset」（ただし、これに反対することにしました）。 しかし、少なくともメソッドには、ユーザーがインテリセンスなどで見ることができる明確なドキュメントを含めることができます。 コンバージョンの場合はそうではありません。

typeof（T）== typeof（byte）を使用して特殊化できるため、バイトのオーバーロードを削除しました

IIRCは、JITの観点からこれがうまくいかないことについていくつかの懸念がありました。 しかし、それは非値型の「typeof（）」の場合にのみ当てはまる可能性があります。 jitがvalue-typetypeof（）の場合に効果的に正しいことを行う限り、それは良いことです。

@CyrusNajmabadi intへの変換に状態の変更が含まれる可能性があることに気づいていませんToHashCodeその時です。

暗号の観点について考えている人のために-http：//tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf

@terrajobst 、私のコメント（ここから開始）を読んで、微調整されたAPI形状を承認するかどうかを決定する時間がありましたか？ もしそうなら、私はこれがグラブのためにapi-承認済み/アップとマークされることができると思います、そして私たちはハッシュアルゴリズムの決定を始めることができます。

@blowdart 、あなたが強調したいその特定の部分はありますか？

上記ではあまり明確ではなかったかもしれませんが、HashDoSの侵入について私が知らない暗号化されていないハッシュは、MarvinとSipHashだけです。 つまり、ランダムな値で（たとえば）雑音をシードすることでさえ、壊れてDoSに使用される可能性があります。

なし、私はそれが面白いと思っただけで、このドキュメントには「暗号化アルゴリズムを介して生成されたハッシュコードでは使用しないでください」と書かれているはずだと思います。

決定

• シナリオが不明確なため、すべてのAddRangeメソッドを削除する必要があります。 配列が頻繁に表示される可能性はほとんどありません。 そして、より大きな配列が含まれると、問題は計算をキャッシュする必要があるかどうかです。 呼び出し側でforループを見ると、それについて考える必要があることが明らかになります。
• また、 IEnumerableオーバーロードをAddRangeに追加したくないの
• stringとStringComparisonを必要とするAddへのオーバーロードは必要ないと思います。 はい、 IEqualityComparerを介して呼び出すよりも効率的である可能性がありますが、後で修正できます。
• GetHashCodeをエラーで廃止されたものとしてマークするのは良い考えですが、さらに一歩進んでIntelliSenseから隠します。

これにより、次のことが可能になります。

`` `C＃
//コアアセンブリに存在します
// .NET Framework：mscorlib
// .NET Core：System.Runtime / System.Private.CoreLib
名前空間システム
{{
public struct HashCode
{{
public static int Combine（T1値1）;
public static int Combine（T1値1、T2値2）;
public static int Combine（T1値1、T2値2、T3値3）;
public static int Combine（T1値1、T2値2、T3値3、T4値4）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5、T6値6）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5、T6値6、T7値7）;
public static int Combine（T1値1、T2値2、T3値3、T4値4、T5値5、T6値6、T7値7、T8値8）;

    public void Add<T>(T value);
    public void Add<T>(T value, IEqualityComparer<T> comparer);

    [Obsolete("Use ToHashCode to retrieve the computed hash code.", error: true)]
    [EditorBrowsable(Never)]
    public override int GetHashCode();

    public int ToHashCode();
}

}
`` `

次のステップ：問題はすぐに解決できます-実験としてhttps://github.com/dotnet/corefx/issues/14354#issuecomment-305028686を参照して

複雑さ：大

誰かがそれを拾うことに興味があるなら、私たちにpingしてください。 何人かが一緒に作業する余地さえあるかもしれません。 （ @jamesqoは、問題に最も多く、最も長く投資したため、優先的に選択できます）

@karelz上記のコメントにもかかわらず、私は最良のハッシュアルゴリズムを選択する資格がないと思うので、考えを変えました。 @morganbrにリストされているライブラリのいくつかを調べたところ、実装が非常に複雑であることがわかりました。そのため、自分でテストするためにC＃に簡単に変換することはできません。 私はC ++のバックグラウンドがほとんどないので、ライブラリをインストールしてテストアプリを作成するだけでも苦労します。

しかし、私はこれが永遠に手に入るリストに残ることを望んでいません。 今日から1週間経っても誰も取り上げない場合は、ProgrammersSEまたはRedditに質問を投稿することを検討します。

私はそれをベンチに入れていません（または他の方法で最適化していません）が、これが私の個人的なプロジェクトのいくつかで使用しているMurmur3ハッシュアルゴリズムの基本的な実装です： https ：//gist.github.com/tannergooding/0a12559d1a912068b9aeb4b9586aad7f

ここでの最適な解決策は、入力データのサイズに基づいてハッシュアルゴリズムを動的に変更することだと思います。

例：Mumur3（およびその他）は、大規模なデータセットに対しては非常に高速であり、優れた分散を提供しますが、小規模なデータセットに対しては「パフォーマンスが低下」（分散ではなく速度）になる可能性があります。

次のようなことを行う必要があると思います。全体のバイト数がX未満の場合は、アルゴリズムAを実行します。 それ以外の場合は、アルゴリズムBを実行します。これは（実行ごとに）決定論的ですが、入力データの実際のサイズに基づいて速度と分散を提供できます。

上記のアルゴリズムのいくつかにはSIMD命令用に特別に設計された実装があるため、最もパフォーマンスの高いソリューションには、あるレベルのFCALLが含まれるか（一部のBufferCopy実装で行われるように）、依存関係を取得する必要があることにも注意してください。 System.Numerics.Vector 。

@jamesqo 、私たちは選択のお手伝いをさせて@tannergoodingが指摘しているように、一部のアルゴリズムには特別なコンパイラサポートが必要ですが、理想的にはC＃です）。 前述したように、選択されていない候補を作成した場合は、後で使用する可能性がありますので、作業が無駄になる心配はありません。

さまざまな実装のベンチマークがあることは知っていますが、このAPIと可能性のある入力範囲（1〜10フィールドの構造体など）を使用して比較することが重要だと思います。

@tannergooding 、その種の適応性が最もパフォーマンスが高いかもしれませんが、何回呼び出されるかわからないため、Addメソッドでどのように機能するかわかりません。 Combineでそれを行うことはできますが、それは一連のAdd呼び出しが対応するCombine呼び出しとは異なる結果を生成する可能性があることを意味します。

また、入力の可能性が最も高い範囲が4〜32バイト（ Combine`1 - Combine`8 ）であることを考えると、その範囲でパフォーマンスに大きな変化がないことを願っています。

この種の適応性が最もパフォーマンスが高いかもしれませんが、Addメソッドが呼び出される回数がわからないため、Addメソッドでどのように機能するかわかりません。

私は、APIの形状が汎用ハッシュに非常に適していると個人的には確信していません（ただし、近いです）...

現在、静的構築用のCombineメソッドを公開しています。 これらがすべての入力を組み合わせて最終的なハッシュコードを生成することを意図している場合、名前は「poor」であり、 Computeようなものがより適切かもしれません。

Combineメソッドを公開する場合は、すべての入力を混合するだけで、ユーザーは最後の結合からの出力と合計バイト数を取得するFinalizeメソッドを呼び出す必要があります。組み合わせて、最終的なハッシュコードを生成します（ハッシュコードを最終化することは、ビットがなだれを引き起こす原因であるため重要です）。

ビルダーパターンでは、 Add ToHashCodeメソッドとAddメソッドがバイトを格納し、 ToHashCodeの呼び出しでのみ結合/ファイナライズすることを意図しているかどうか（この場合、正しいアルゴリズムを動的に選択できます）、またはその場で結合することを意図しているので、これが当てはまることは明らかです（そして、実装は結合されたバイトの合計サイズを内部的に追跡する必要があります）。

それほど複雑でない出発点を探している人は、xxHash32を試してください。 それはかなり簡単にC＃に変換される可能性があります（人々はそれをしました）。

まだローカルでテストしていますが、Murmur3のC＃実装で次のスループット率が見られます。

これらは、1〜8入力の静的Combineメソッド用です。

1070.18 mb/s
1511.49 mb/s
1674.89 mb/s
1957.65 mb/s
2083.24 mb/s
2140.94 mb/s
2190.27 mb/s
2245.53 mb/s

私の実装では、入力ごとにGetHashCodeを呼び出す必要があり、計算された値を返す前に確定する必要があると想定しています。

テストが最も簡単なint値を組み合わせました。

スループットを計算するために、10,001回の反復を実行し、最初の反復を「ウォームアップ」の実行として破棄しました。

各反復で、 HashCode.Combineを呼び出す10,000回のサブ反復を実行し、前のサブ反復の結果を次の反復の最初の入力値として渡します。

次に、すべての反復を平均して平均経過時間を取得し、さらにそれをループごとに実行されるサブ反復の数で割って、呼び出しごとの平均時間を取得します。 次に、1秒あたりに実行できる呼び出しの数を計算し、それを組み合わせたバイト数で乗算して、実際のスループットを計算します。

コードをクリーンアップして、少し共有します。

@tannergooding 、それは大きな進歩のように聞こえます。 正しい測定値を取得していることを確認するために、APIの目的は、 HashCode.Combine(a, b)呼び出しが呼び出しと同等であることです。

HashCode hc = new HashCode();
hc.Add(a); // Initializes the hash state, calls a.GetHashCode() and feeds the result into the hash state
hc.Add(b); // Calls b.GetHashCode() and feeds the result into the hash state
return hc.ToHashCode(); // Finalizes the hash state, truncates it to an int, resets the internal state and returns the int

どちらの場合も、データは同じ内部ハッシュ状態に供給され、ハッシュは最後に1回ファイナライズされる必要があります。

👍

それは事実上、私が書いたコードが行っていることです。 唯一の違いは、すべてのコードを効果的にインライン化することです（ new HashCode()を割り当てて、結合されたバイト数を追跡​​する必要はありません。定数であるためです）。

@morganbr。 Murmur3の実装+スループットテスト： https ：//gist.github.com/tannergooding/89bd72f05ab772bfe5ad3a03d6493650

MurmurHash3は、ここで説明されているアルゴリズムに基づいています： https ： ます

xxHash32（BSD-2条項-https：//github.com/Cyan4973/xxHash/blob/dev/xxhash.c）およびSpookyHash（パブリックドメイン-http：//www.burtleburtle.net/bob/hash）での作業/spooky.html）バリアント

@tannergooding繰り返しになりますが、ハッシュの専門家ではありませんが、[記事を読んで] [1]、MurmurはDoS耐性ではないと言っていたので、それを選択する前に指摘しただけです。

@jamesqo 、私は間違っているかもしれませんが、脆弱性がMurmur3ではなくMurmur2に適用されたことはかなり確信しています。

いずれの場合も、C＃のスループット結果を取得できるように、いくつかのアルゴリズムを実装しています。 これらのアルゴリズムの分布やその他のプロパティはかなりよく知られているので、後で最適なものを選択できます😄

おっと、記事へのリンクを忘れました： http ：

@tannergoodingOK 。 公平に聞こえます：+1：

@tannergooding 、私はあなたのMurmur3実装を調べました、そしてそれは一般的に正しく見え、おそらくかなりよく最適化されています。 私が正しく理解していることを確認するために、combinedValueとMurmurの内部状態が両方とも32ビットであるという事実を使用していますか？ これはおそらくこの場合のかなり良い最適化であり、私の以前の混乱のいくつかを説明しています。

それを採用する場合は、いくつかの調整が必要になる可能性があります（ただし、パフォーマンスの測定には大きな違いはありません）。

• 混ぜるそれでもvalue1でCombineValueを呼び出す必要があります
• 最初のCombineValue呼び出しは、ランダムシードを取る必要があります
• ToHashCodeは_bytesCombinedと_combinedValueをリセットする必要があります

その間、私はこのAPIを待ち望んでいますが、 (field1, field2, field3).GetHashCode()介してGetHashCodeを実装することはどれほど悪いことですか？

@ jnm2 、ValueTupleハッシュコードコンバイナーは、入力をハッシュコード内で順番に並べる傾向があります（そして最新のものを破棄します）。 いくつかのフィールドと素数で割るハッシュテーブルの場合、気付かないかもしれません。 多くのフィールドまたは2の累乗で除算するハッシュテーブルの場合、最後に挿入したフィールドのエントロピーが、衝突があるかどうかに最も影響します（たとえば、最後のフィールドがブール値または小さい整数の場合、おそらく多くの衝突が発生しますが、それがGUIDの場合は、おそらく発生しません）。

ValueTupleは、すべて0のフィールドでもうまく機能しません。

ちなみに、私は他の実装での作業をやめなければなりませんでした（優先度の高い作業があります）。 いつ取り戻すことができるかわかりません。

では、それが構造化型には十分でない場合、なぜタプルには十分なのですか？

@ jnm2 、これがこの機能を構築する価値がある理由の1つです。フレームワーク全体で標準以下のハッシュを置き換えることができます。

パフォーマンスと品質の特性を備えたハッシュ関数の大きなテーブル：
https://github.com/leo-yuriev/t1ha

@aresprチームはハッシュ関数のC＃実装を探していると思います。 でも、共有してくれてありがとう。

@tannergoodingまだこの問題を取り戻すことができませんか？ もしそうなら、私たちはハッシュの専門家を探していることをReddit / Twitterに投稿します。

編集： Redditに投稿しました。 https://www.reddit.com/r/csharp/comments/6qsysm/looking_for_hash_expert_to_help_net_core_team/?ref=share&ref_source=link

@jamesqo 、優先度の高いものがいくつかあり、3週間以内にこれに到達できなくなります。

また、現在の測定値は、現在C＃でコーディングできるものによって制限されますが、これが問題になると（https://github.com/dotnet/designs/issues/13）、測定値が多少変化する可能性があります。 ;）

また、現在の測定値は、現在C＃でコーディングできるものによって制限されますが、これが問題になると（dotnet / designs＃13）、測定値が多少変化する可能性があります;）

それは問題ありません。組み込み関数が利用可能になったら、いつでもハッシュアルゴリズムを変更できます。ハッシュコードをカプセル化/ランダム化すると、それが可能になります。 現在の状態のランタイムで最高のパフォーマンスと配信のトレードオフを提供するものを探しています。

@jamesqo 、助けてくれる人を探してくれてありがとう。 ハッシュの専門家ではない誰かがこれに取り組んでくれることを嬉しく思います-他の言語やデザインからいくつかのアルゴリズムをC＃に移植して、パフォーマンス測定を行うことができる誰かが本当に必要です。 候補者を選択したら、専門家が変更に対して行うことを行います。コードの正確性、パフォーマンス、セキュリティなどを確認します。

やあ！ ディスカッションを読み終えたところですが、少なくとも私には、murmur3-32PoCを支持してケースは強力にクローズされているようです。 ところで、これは私にとって非常に良い選択のように思えます。これ以上不必要な作業を行わないことをお勧めします（ただし、 .Add()メンバーを削除することもできます...）。

しかし、誰かがより多くのパフォーマンス作業を続けたいというまれなケースでは、xx32、xx64、hsip13 / 24、seahash、murmur3-x86 / 32のコードを提供できます（そして、上からmarvin32 implを統合しました）、そして（まだ最適化されていない）sip13 / 24、spookyv2。 Cityの一部のバージョンは、必要に応じて移植するのに十分簡単に​​見えます。 その半分放棄されたプロジェクトは、わずかに異なるユースケースを念頭に置いていたため、提案されたAPIにはHashCodeクラスはありません。 しかし、ベンチマークの場合、それはそれほど重要ではありません。

間違いなくない生産対応：コードがコピーパスタなどのブルートフォース、アグレッシブインラインと危険なの癌スプロールの寛大な量を適用します。 エンディアンは存在せず、整列されていない読み取りも存在しません。 ref-impl test-vectorsに対するテストでさえ、婉曲的に「不完全」と言えます。

これが少しでも助けになる場合は、次の2週間で、最もひどい問題を修正し、コードといくつかの予備的な結果を利用できるようにするのに十分な時間を見つける必要があります。

@gimpf

ディスカッションを読み終えたところですが、少なくとも私には、murmur3-32PoCを支持してケースは強力にクローズされているようです。 どのところで私には非常に良い選択のように思えます、そして私はこれ以上不必要な仕事を費やさないことをお勧めします

いいえ、人々はまだMurmur3を支持していません。 パフォーマンスと配信のバランスの観点から、絶対的に最良のアルゴリズムを選択していることを確認したいので、石を放置することはできません。

しかし、誰かがより多くのパフォーマンス作業を続けたいというまれなケースでは、xx32、xx64、hsip13 / 24、seahash、murmur3-x86 / 32のコードを提供できます（そして、上からmarvin32 implを統合しました）、そして（まだ最適化されていない）sip13 / 24、spookyv2。 Cityの一部のバージョンは、必要に応じて移植するのに十分簡単に​​見えます。

はい、お願いします！ テストするために、できるだけ多くのアルゴリズムのコードを収集したいと考えています。 あなたが貢献できるすべての新しいアルゴリズムは価値があります。 Cityアルゴリズムも移植できれば幸いです。

間違いなく本番環境に対応していません。コードは、コピーパスタ、アグレッシブインラインの癌性スプロール現象、安全でないなど、大量のブルートフォースを適用します。 エンディアンは存在せず、整列されていない読み取りも存在しません。 ref-impl test-vectorsに対するテストでさえ、婉曲的に「不完全」と言えます。

それで大丈夫です。 コードを持ち込むだけで、必要に応じて他の誰かがコードを見つけることができます。

これが少しでも助けになる場合は、次の2週間で、最もひどい問題を修正し、コードといくつかの予備的な結果を利用できるようにするのに十分な時間を見つける必要があります。

はい、それは素晴らしいことです！

@jamesqoわかりました。何か見せたいことがあれば、メモを

@gimpfは本当に素晴らしいと思います。進行状況についてお聞かせください（すべてのアルゴリズムを実行できるようになるまで待つ必要はありません！）。 コードが正しい結果を生成し、パフォーマンスが本番環境に対応した実装で見られるものを適切に表現していると確信している限り、本番環境に対応していなくても問題ありません。 候補者を選んだら、高品質の実装を実現するためにあなたと協力することができます。

seahashのエントロピーが他のアルゴリズムとどのように比較されるかについての分析を見たことがありません。 それについて何かアドバイスはありますか？ 興味深いサウンドパフォーマンスのトレードオフがあります...ベクトル化は速く聞こえますが、モジュラー演算は遅く聞こえます。

@morganbrティーザーの準備ができました。

SeaHashについて：いいえ、品質についてはまだわかりません。 パフォーマンスがおもしろい場合は、SMHasherに追加します。 少なくとも作者はそれが良いと主張し（ファイルシステムのチェックサムにそれを使用する）、また混合中にエントロピーが捨てられないと主張します。

ハッシュとベンチマークについて：Project Haschisch.Kastriert 、xx32、xx64、hsip13、hsip24、marvin32、sea、murmur3-32を比較れたwikiページ。

いくつかの重要な警告：

• これは、精度の低い設定での非常に迅速なベンチランでした。
• 実装はまだ実際には行われておらず、一部の候補者はまだ不足しています。 ストリーミングの実装（このようなことは賢明な.Add（）サポートに必要になるでしょう）は実際の最適化を必要としています。
• SeaHashは現在シードを使用していません。

第一印象：

• 大きなメッセージの場合、xx64はリストされている実装の中で最速です（私が理解している限り、サイクルあたり約3.25バイト、またはノートブックでは9.5 GiB / s）
• 短いメッセージの場合、何も素晴らしいことはありませんが、murmur3-32、および（驚くべきことに）seahashには優位性がありますが、後者は、まだシードを使用していないseahashによって説明される可能性があります。
• HashSet<>にアクセスするための「ベンチマーク」は、すべてがほぼ測定誤差の範囲内にあるため、作業が必要です（大きな違いは見ましたが、それでも話す価値はありません）
• ハッシュコードを組み合わせると、murmur-3A PoCはここにあるものよりも約5〜20倍高速になります
• C＃の一部の抽象化は非常に高価です。 そのため、ハッシュアルゴリズムの比較は必要以上に煩わしくなります。

状況が少し改善されたら、もう一度お手紙を差し上げます。

@gimpf 、それは素晴らしいスタートです！ コードと結果を確認しましたが、いくつか質問があります。

1. あなたの結果は、より遅いのMurmur3aを@tannergoodingよりも5倍程度としてSimpleMultiplyAddを示しました。 Murmurにはmultiply + addよりもやるべきことがたくさんあるので、それは奇妙に思えます（ただし、rotateはaddよりも高速な操作であると認めます）。 あなたの実装がそのMurmur実装にない一般的な非効率性を持っている可能性はありますか、それともこれを汎用実装よりも大きな利点があるカスタム実装として読む必要がありますか？
2. 1、2、および4の組み合わせの結果が得られるのは良いことですが、このAPIは最大8になります。それでも結果を得ることができるでしょうか、それとも重複が多すぎるのでしょうか。
3. X64で実行しているのを見たので、これらの結果はX64アルゴリズムの選択に役立つはずですが、他のベンチマークでは、アルゴリズムがX86とX64の間でかなり劇的に異なる可能性があることが示唆されています。 X86の結果も簡単に取得できますか？ （ある時点で、ARMとARM64も入手する必要がありますが、それらは間違いなく待つことができます）

HashSetの結果は特に興味深いものです。 彼らが持ちこたえている場合、それはより速いハッシュ時間よりもより良いエントロピーを好むための可能なケースです。

@morganbr今週末はオンとオフが多かったので、進捗は限られています。

あなたの質問について：

1. あなたの結果は、より遅いのMurmur3aを@tannergoodingよりも5倍程度としてSimpleMultiplyAddを示しました。 それは奇妙に思えます...

私は自分自身を不思議に思っていました。 これはコピー/貼り付けエラーでした。SimpleMultiplyAddは常に4つの値を結合していました...また、一部のステートメントを並べ替えることにより、multiply-addコンバイナーがわずかに高速になりました（スループットが約60％向上）。

あなたの実装がそのMurmur実装にない一般的な非効率性を持っている可能性はありますか、それともこれを汎用実装よりも大きな利点があるカスタム実装として読む必要がありますか？

私はいくつかのことを見逃している可能性がありますが、.NETの場合、汎用実装はこのユースケースでは使用できないようです。 私はすべてのアルゴリズムに対してCombineスタイルのメソッドを作成しましたが、wrtハッシュコードを組み合わせると、汎用メソッドよりもはるかに優れたパフォーマンスを発揮します。

ただし、これらの実装でさえ遅すぎます。 さらなる作業が必要です。 この領域での.NETのパフォーマンスは、私にはまったく不透明です。 ローカル変数のコピーを追加または削除すると、パフォーマンスが2倍簡単に変わる可能性があります。 最適なオプションを選択するために十分に最適化された実装を提供できない可能性があります。

1. 1、2、および4の組み合わせで結果が得られるのは良いことですが、このAPIは最大8つになります。

結合ベンチマークを拡張しました。 その面で驚きはありません。

1. X64で実行しているのを見ました（...）、X86の結果も簡単に取得できますか？

かつてはそうでしたが、その後.NETStandardに移植しました。 今、私は依存関係地獄にいます、そして.NET Core2とCLR64ビットベンチマークだけが機能します。 現在の問題を解決すれば、これは簡単に解決できます。

これでv2.1リリースになると思いますか？

@gimpfしばらく投稿していませんが、実装の進捗状況を更新していますか？ ：スマイリー：

@jamesqo奇妙な結果を引き起こすいくつかのベンチマークを修正し、City32、SpookyV2、Sip13、およびSip24を使用可能なアルゴリズムのリストに追加しました。 Sipsは（xx64のスループットと比較して）期待どおりに高速ですが、CityとSpookyはそうではありません（SeaHashについても同じことが言えます）。

ハッシュコードを組み合わせる場合、Murmur3-32はまだ良い賭けのように見えますが、私はまだより徹底的な比較を実行していません。

別の注意点として、ストリーミングAPI（.Add（））には、候補のリストからいくつかのハッシュアルゴリズムを削除するという不幸な副作用があります。 このようなAPIのパフォーマンスにも疑問があることを考えると、最初から提供するかどうかを再考することをお勧めします。

.Add()部分が回避され、ハッシュコンバイナーがシードを使用していることを考えると、tgのコンバイナーのクリーンアップ、小さなテストスイートの作成、およびそれを1日と呼びます。 週末は数時間しかなく、パフォーマンスの最適化はやや面倒なので、金メッキバージョンを作成すると少し時間がかかる可能性があります...

@gimpf 、それは大きな進歩のように聞こえます。 決定を下して前進するのに十分かどうかを確認できるように、結果テーブルが手元にありますか？

@morganbrベンチマーク結果を更新しました。

今のところ、.NET Core 2での結果は64ビットのみです。そのプラットフォームでは、シードなしのCity64がすべてのサイズで最速です。 シードを組み込んだXX-32はMurmur-3-32と結びついています。 幸いなことに、これらは32ビットプラットフォームで高速であるという評判のある同じアルゴリズムですが、明らかに、それが私の実装にも当てはまることを確認する必要があります。 SeaとSpookyV2が異常に遅いように見えることを除いて、結果は実際のパフォーマンスを代表しているようです。

hash-code-combinersのhash-dos保護が実際にどれだけ必要かを考慮する必要があります。 ハッシュを永続性に明らかに使用できないようにするためだけにシードが必要な場合は、32ビットシードとXORを実行するとcity64が改善されます。 このユーティリティはハッシュを組み合わせるためだけにあります（たとえば、文字列のハッシュコードを置き換えたり、整数配列のドロップインハッシュにすることはできません）ので、それで十分かもしれません。

OTOHが必要だと思う場合、Sip13は通常XX-32（64ビットプラットフォーム）よりも50％未満遅いことがわかりますが、その結果は32ビットアプリでは大幅に異なる可能性があります。

それがcorefxにどれだけ関連しているかはわかりませんが、LegacyJit 32ビット（FW 4.7付き）の結果を追加しました。

結果はばかげて遅いと言いたいです。 ただし、例として、56 MiB / s対319MiB / sでは笑っていません（これはSipであり、左回転の最適化が最も不足しています）。 1月に.NETハッシュアルゴリズムプロジェクトをキャンセルした理由を覚えていると思います...

したがって、RyuJit-32ビットはまだ欠落しており、（うまくいけば）非常に異なる結果が得られますが、LegacyJit-x86の場合、Murmur-3-32が手軽に勝ち、City-32とxx-32のみが近づくことができます。 雑音は、（同じマシン上で）0.6〜2 GB / sではなく0.4〜1.1 GB / s程度でパフォーマンスが低下しますが、少なくとも適切な球場にあります。

今夜、いくつかのボックスでベンチマークを実行し、結果を投稿します（Ryzen、i7、Xeon、A10、i7 Mobile、および他のいくつかのボックスだと思います）。

@ tannergooding @ morganbrいくつかの素晴らしいアップデートといくつかの重要なアップデート。

最初に重要：

• 誤ったハッシュ値を生成していたいくつかの結合実装を修正しました。
• ベンチマークスイートは、定数畳み込みを回避するためにさらに機能するようになりました。 City64は影響を受けやすかった（過去のつぶやき-3-32のように）。 私が今すべての結果を理解しているという意味ではありませんが、それらははるかにもっともらしいです。

いいこと：

• コンバイナーの実装は、xx / cityのやや面倒な手動で展開された実装を含め、1〜8個の引数のオーバーロードすべてで使用できるようになりました。
• テストとベンチマークもそれらをチェックします。 多くのハッシュアルゴリズムには特殊なケースの低バイトメッセージがあるため、これらの測定値が重要になる可能性があります。
• 複数のターゲット（コアとFW）の実行ベンチマークを簡素化しました。

「Empty」（純粋なオーバーヘッド）や「multiply-add」（有名なSO回答の速度最適化バージョン）など、ハッシュコードを組み合わせるためのすべての主要な実装でスイートを実行するには：

bin\Release\net47\Haschisch.Benchmarks.Net47.exe -j:clr_x86 -j:clr_x64_legacy -j:clr_x64 -j:core_x64 -- CombineHashCode --allcategories=prime

（_32ビットコアベンチマークを実行するには、プレリリースのBenchmarkDotNetが必要なようです（または、32ビットのみのセットアップとコアベースのベンチランナーを使用する必要があります）。その後、-j：core_x86を使用して動作するはずです）_

結果：すべてのバグ修正の後、xx32は、モバイルHaswelli7上のWindows10で、「クイック」実行で64ビットRyuJITを使用したすべてのオーバーロードに勝つようです。 Sipsとmarvin32の間では、Sip-1-3が常に勝ちます。 Sip-1-3はxx32よりも約4倍遅く、これもプリミティブな乗算加算コンバイナーよりも約2倍遅くなります。 32ビットコアの結果はまだ欠落していますが、私は多かれ少なかれ、その問題を解決する安定したBenchmarkDotNetリリースを待っています。

（編集）ハッシュセットにアクセスするためのベンチマークのクイックランを追加しました。 これは明らかに、上記のµベンチマークよりも詳細に大きく依存していますが、外観を確認することをお勧めします。

素晴らしいデータをありがとう@gimpf ！ それを決断に変えることができるかどうか見てみましょう。

まず、アルゴリズムを次のように分割します。
Fast + Goodエントロピー（速度順）：

1. xxHash32
2. City64（これは、x86ではおそらく遅いので、x86では別のものを選択する必要があります）
3. Murmur3A

HashDoS耐性：

• Marvin32
• SipHash。 これに傾倒する場合は、マイクロソフトの暗号専門家によるレビューを受けて、調査結果が受け入れられることを確認する必要があります。 また、どのパラメータが十分に安全であるかを把握する必要があります。 この論文は、Sip-2-4とSip-4-8の間のどこかを示唆しています。

競合から（遅い）：

• SpookyV2
• City32
• xxHash64
  * SeaHash（そしてエントロピーに関するデータはありません）

競合から（悪いエントロピー）：

• MultiplyAdd
• HSip

勝者を選ぶ前に、他の人が上記の私のバケツに同意することを確認したいと思います。 それが成り立つ場合は、HashDoSの抵抗に2倍を支払うかどうかを選択してから、速度で進む必要があると思います。

@morganbrあなたのグループ化は問題ないようです。 SipHashラウンドのデータポイントとして、Rustプロジェクトは、DJB付きのsip-hashを作成したJean-PhilippeAumassonに質問しました。 その議論の後、彼らはハッシュテーブルのためにsip-1-3に行くことに決めました。

（ PR rust：＃33940および付随する問題rust：＃29754を参照してください）。

データとコメントに基づいて、すべてのアーキテクチャでxxHash32を使用することを提案したいと思います。 次のステップはそれを実装することです。 @gimpf 、そのためのPRをまとめることに興味がありますか？

HashDoSが心配な方のために、Marvin32を含み、SipHashを含む可能性のある汎用ハッシュAPIの提案をすぐにフォローアップします。 これは、 @ gimpfと@tannergoodingが取り組んできた他の実装にも適した場所になります。

@morganbr時間の許す限りPRをまとめることができます。 また、受け入れを減らさない限り、私も個人的にxx32を好みます。

@gimpf 、あなたの時間はどうですか？ 時間がない場合は、他の誰かが試してみたいかどうかも確認できます。

@morganbr 11月5日までやろうと思っていたのですが、2週間以内に時間を見つけられるのは良さそうです。

@gimpf 、いいですね。 更新していただきありがとうございます！

@ terrajobst-パーティーに少し遅れています（申し訳ありません）が、Addメソッドの戻り値のタイプを変更することはできませんか？

`` `c＃
public HashCode Add（T値）;
public HashCode Add（T値、IEqualityComparer比較者）;

The params code is clearly there for scenarios where you have multiple fields, e.g.

```c#
        public override int GetHashCode() => new HashCode().Add(Name, Surname).ToHashCode();

ただし、無駄の少ない配列割り当てを1つ使用しても、まったく同じことがこのように実現できます。

c# public override int GetHashCode() => new HashCode().Add(Name).Add(Surname).Add(Age).ToHashCode();

タイプを混在させることもできることに注意してください。 これは明らかに、通常のメソッド内で流暢に呼び出さないことで実行できます。 流暢なインターフェースが絶対に必要というわけではないというこの議論を考えると、なぜ無駄なparamsオーバーロードがそもそも存在するのでしょうか。 この提案が悪い提案である場合、 params過負荷はまったく同じ軸に分類されます。 それと、些細でありながら最適なハッシュコードの通常のメソッドを強制することは、多くの儀式のように思えます。

編集： implicit operator intはDRYにも適していますが、厳密には重要ではありません。

@jcdickinson

Addメソッドの戻り値のタイプを変更できませんか？

それについては古い提案ですでに議論しましたが、却下されました。

そもそも無駄なparamsオーバーロードが存在するのはなぜですか？

paramsオーバーロードを追加していませんか？ このWebページの「params」に対してCtrl + Fを実行すると、コメントがその単語がポップアップする唯一の場所であることがわかります。

暗黙の演算子intもDRYに適していますが、厳密には重要ではありません。

それも上記のどこかで議論されたと思います...

@jamesqo説明ありがとう

paramsオーバーロード

私はAddRangeを意味しましたが、これには何の牽引力もないと思います。

@jcdickinson AddRangeは元の提案に含まれていましたが、現在のバージョンには含まれていません。 APIレビューによって拒否されました（@terrajobstによるhttps://github.com/dotnet/corefx/issues/14354#issuecomment-308190321を参照）：

シナリオが不明確なため、すべてのAddRangeメソッドを削除する必要があります。 配列が頻繁に表示される可能性はほとんどありません。 そして、より大きな配列が含まれると、問題は計算をキャッシュする必要があるかどうかです。 呼び出し側でforループを見ると、それについて考える必要があることが明らかになります。

@gimpf私はxxHash32で提案をポリフィルしました。 その実装を自由に入手してください。 実際のxxHash32ベクトルに対するテストがあります。

編集

インターフェースについて。 私はモグラヒルから山を作っていることを十分に承知しています-無視してかまいません。 私は本物に対して現在の提案を使用しています、そしてそれは多くの迷惑な繰り返しです。

私はインターフェースをいじってみましたが、流暢なインターフェースが拒否された理由を理解しました。 かなり遅いです。

BenchmarkDotNet=v0.10.9, OS=Windows 10 Redstone 2 (10.0.15063)
Processor=Intel Core i7-4800MQ CPU 2.70GHz (Haswell), ProcessorCount=8
Frequency=2630626 Hz, Resolution=380.1377 ns, Timer=TSC
.NET Core SDK=2.0.2
  [Host]     : .NET Core 2.0.0 (Framework 4.6.00001.0), 64bit RyuJIT
  DefaultJob : .NET Core 2.0.0 (Framework 4.6.00001.0), 64bit RyuJIT

インライン化されていないメソッドをハッシュコードソースとして使用する。 Addと流暢な拡張メソッドの50回の呼び出し：

| 方法| 平均| エラー| StdDev | スケーリング|
| ------- | ---------：| ---------：| ---------：| -------： |
| 追加| 401.6 ns | 1.262 ns | 1.180 ns | 1.00 |
| タリー| 747.8 ns | 2.329 ns | 2.178 ns | 1.86 |

ただし、次のパターンは機能します。

`` `c＃
public struct HashCode：System.Collections.IEnumerable
{{
[EditorBrowsable（EditorBrowsableState.Never）]
[廃止（ "このメソッドはコレクション初期化構文用に提供されています。"、エラー：true）]
public IEnumerator GetEnumerator（）=>新しいNotImplementedException（）;をスローします。
}

public override int GetHashCode() => new HashCode()
{
    Age, // int
    { Name, StringComparer.Ordinal }, // use Comparer
    Hat // some arbitrary object
}.ToHashCode();

`` `

また、現在の提案と同じパフォーマンス特性を備えています。

| 方法| 平均| エラー| StdDev | スケーリング|
| ------------ | ---------：| ---------：| ---------：| --- ----：|
| 追加| 405.0 ns | 2.130 ns | 1.889 ns | 1.00 |
| イニシャライザー| 400.8 ns | 4.821 ns | 4.274 ns | 0.99 |

残念ながら、コンパイラを満足させるためにIEnumerableを実装する必要があるため、これはややハックです。 そうは言っても、 Obsoleteはforeachでもエラーになります。例外に遭遇するためには、本当に物事を壊したいと思う必要があります。 2つのMSILは基本的に同じです。

@jcdickinson問題をつかんでくれてありがとう。 コラボレーターの招待状をお送りしました。承諾したらお知らせください。この問題をあなたに割り当てることができます（当面は自分に割り当てます）。

ヒント：同意すると、GitHubはリポジトリからのすべての通知（1日あたり500以上）に自動的にサインアップします。これを「監視なし」に変更すると、すべてのメンションと問題の通知が送信されます。購読しました。

@jcdickinson 、私は迷惑な繰り返しを避ける方法に間違いなく興味があります（ただし、初期化構文について人々がどのように感じるかはわかりません）。 流暢さには2つの問題があったことを思い出しているようです。

1. あなたが指摘したパフォーマンスの問題
2. 流暢なメソッドからの戻り値は、構造体のコピーです。 次のようなことをして誤って入力を失ってしまうのは簡単すぎます。

var hc = new HashCode();
var newHc = hc.Add(foo);
hc.Add(bar);
return newHc.ToHashCode();

このスレッドの提案はすでに承認されているので（そして、それをマージする準備が整っているので）、変更がある場合は新しいAPI提案を開始することをお勧めします。

@ karelz @ gimpfはすでにこの問題を事前に思います。 彼は実装に精通しているので、代わりにこの問題を@gimpfに割り当ててください。 （編集： nvm）

@terrajobstこれに対する土壇場のAPIリクエストの一種。 GetHashCode廃止とマークしたので、 HashCodeは、通常は不変/比較可能な構造体であるにもかかわらず、比較することを意図した値ではないことをユーザーに暗黙的に伝えています。 その場合、 Equals廃止とマークする必要がありますか？

[Obsolete("HashCode is a mutable struct and should not be compared with other HashCodes.", error: true)]
[EditorBrowsable(Never)]
// If this is too harsh, base.Equals() is fine as long as the [Obsolete] stays
public override bool Equals(object obj) => throw new NotSupportedException("HashCode is a mutable struct and should not be compared with other HashCodes.");

Span同様のことが行われたと思います。

それが受け入れられれば、私は思う...

1. 廃止されたメッセージでは、 cannot代わりにshould notまたはmay notを使用することを検討します。
2. 例外が残っている場合、メソッドがキャストまたはオープンジェネリックを介して呼び出された場合に備えて、メッセージに同じ文字列を入れます。

@ Joe4evr元気です。 コメントを更新しました。 同じメッセージをGetHashCode例外に含めることも有益な場合があります。

public override int GetHashCode() => throw new NotSupportedException("HashCode is a mutable struct and should not be compared with other HashCodes.");

@morganbrなぜこれを再開したのですか？

CoreFXで公開するためのPRはまだ完了していません。

@gimpfベンチマークしたコードを利用できますか、および/またはSpookilySharpnugetパッケージがどのように公正であるかをすばやく確認できますか。 私は2、3年の停滞の後にそのプロジェクトをほこりで払うことを探しています、そして私はそれがどのように立ち上がるかを見たいと思っています。

@JonHanna彼はここに投稿しました： https ：

@JonHanna 、汎用の非暗号化ハッシュAPIで何が役立つかを考え始めることができるように、テストがどのように行われるかを聞きたいと思います。

@morganbrそのようなAPIについて議論するための適切なフォーラムはどこにありますか？ このようなAPIは、最小公分母だけでなく、優れたAPIでも、より大きな構造体の処理を改善する必要があると思います。 別の問題でよりよく行われるかもしれないすべてを議論する...

@gimpfあなたのために1つ

@ morganbr-このコミットを含むパッケージ名とバージョン番号を取得できますか？

@karelz 、パッケージ/バージョン情報で@smitpatelを助けることができるでしょうか？

.NETCoreのデイリービルドを試してみました-明日まで待ちます。
単純に依存できるパッケージはないと思います。

参加者への質問はこちら。 Roslyn IDEを使用すると、ユーザーはクラス/構造体の一連のフィールド/プロパティに基づいてGetHashCodeimplを生成できます。 理想的には、 https： //github.com/dotnet/corefx/pull/25013で追加された新しいHashCode.Combineを使用でき

最近、私たちが生成するフォームに問題があることがわかりました。 つまり、VBはデフォルトでオーバーフローチェックをオンにしてコンパイルするため、implによってオーバーフローが発生します。 また、VBには、コード領域のオーバーフローチェックを無効にする方法がありません。 アセンブリ全体で完全にオンまたはオフになります。

このため、私たちが提供するimplを、これらの問題に悩まされないフォームに置き換えることができるようにしたいと思います。 理想的には、生成されたフォームは次のプロパティを持ちます。

1. 使用されるフィールド/プロパティごとにGetHashCodeの1行または2行。
2. オーバーフローはありません。
3. 適度に良いハッシュ。 驚くべき結果は期待していません。 しかし、うまくいけば、まともであり、通常a + b + c + dまたはa ^ b ^ c ^ d発生する問題がないことがすでに精査されているものです。
4. コードに追加の依存関係/要件はありません。

たとえば、VBの1つのオプションは、次のようなものを生成することです。

return (a, b, c, d).GetHashCode()

ただし、これはSystem.ValueTupleへの参照があるかどうかに依存します。 理想的には、それがなくても機能するimplを作成できます。

これらの制約を処理できる適切なハッシュアルゴリズムについて知っている人はいますか？ ありがとう！

-

注：既存の出力コードは次のとおりです。

        Dim hashCode = -252780983
        hashCode = hashCode * -1521134295 + i.GetHashCode()
        hashCode = hashCode * -1521134295 + j.GetHashCode()
        Return hashCode

これは明らかにオーバーフローする可能性があります。

そのコードの周りにunchecked { }追加するだけなので、これもC＃の問題ではありません。 そのきめ細かい制御はVBでは不可能です。

これらの制約を処理できる適切なハッシュアルゴリズムについて知っている人はいますか？ ありがとう！

ええと、あなたはTuple.Create(...).GetHashCode()することができます。 明らかに、これには割り当てが発生しますが、例外をスローするよりはましだと思われます。

System.ValueTupleをインストールするようにユーザーに指示できない理由はありますか？ これは組み込みの言語機能なので、System.ValueTupleパッケージは基本的にすべてのプラットフォームと非常に互換性があると思いますよね？

明らかに、これには割り当てが発生しますが、例外をスローするよりはましだと思われます。

はい。 それが割り当てを引き起こさないのは素晴らしいことです。

System.ValueTupleをインストールするようにユーザーに指示できない理由はありますか？

これは、ValueTupleアプローチを生成した場合の動作になります。 ただし、繰り返しになりますが、ユーザーがコードの構造を大幅に変更することなく、ユーザーが現在コードを構造化している方法に適合する優れたものを生成できれば便利です。

VBユーザーはこの問題に合理的な方法で対処する方法を持っている必要があるようです:)しかし、そのようなアプローチは私にはわかりません:)

@CyrusNajmabadi 、ユーザーのコードで独自のハッシュ計算を行う必要がある場合は、テーブルルックアップとXORの組み合わせであるためCRC32が機能する可能性があります（ただし、オーバーフローする可能性のある算術演算は機能しません）。 ただし、いくつかの欠点があります。

1. CRC32には大きなエントロピーはありません（ただし、Roslynが現在放出しているものよりも優れている可能性があります）。
2. ルックアップテーブルを生成するには、コードのどこかに256エントリのルックアップテーブルを配置するか、コードを発行する必要があります。

まだ行っていない場合は、HashCodeタイプを検出し、可能な場合はそれを使用できることを願っています。XXHashの方がはるかに優れているはずだからです。

@morganbrhttps ： //github.com/dotnet/roslyn/pull/24161を参照してください

私たちは以下を行います：

1. 利用可能な場合は、System.HashCodeを使用します。 終わり。
2. それ以外の場合、C＃の場合：
   2a。 チェックモードでない場合：展開されたハッシュを生成します。
   2b。 チェックモードの場合：「unchecked {}」でラップされた展開済みハッシュを生成します。
3. それ以外の場合、VBの場合：
   3b。 チェックモードでない場合：展開されたハッシュを生成します。
   3c。 チェックモードの場合、System.ValueTupleにアクセスできます： Return (a, b, c, ...).GetHashCode()生成します
   3D。 System.ValueTupleにアクセスせずにチェックモードになっている場合。 展開されたハッシュを生成しますが、オーバーフローする可能性が非常に高いコメントをVBに追加します。

本当に残念なのは「3D」です。 基本的に、VBを使用しているが、ValueTupleまたは最近のシステムを使用していない人は、それらのために生成された合理的なハッシュアルゴリズムを取得するために私たちを使用することはできません。

コードのどこかに256エントリのルックアップテーブルを配置する必要があります

これは完全に口に合わないでしょう:)

テーブル生成コードも口に合わないのですか？ 少なくともウィキペディアの例では、コードはそれほど多くありません（ただし、ユーザーのソースのどこかに移動する必要があります）。

Roslynが（ILを使用して）参照するアセンブリから利用できない場合に（はるかに単純な）コンパイラ属性クラス定義を使用してHashCodeソースをプロジェクトに追加することは、どれほどひどいことでしょうか？

Roslynが（はるかに単純な）コンパイラ属性クラス定義で行うように、参照されているアセンブリから利用できない場合に、HashCodeソースをプロジェクトに追加するのはどれほどひどいことでしょうか？

1. HashCodeソースはオーバーフロー動作を必要としませんか？
2. HashCodeソースをざっと読みました。 それは些細なことではありません。 そのすべてのグープをユーザーのプロジェクトに生成することはかなり重いでしょう。

オーバーフロー計算をVBで機能させる良い方法がまったくないことに驚いています:(

したがって、少なくとも、2つの値を一緒にハッシュしている場合でも、次のものを作成する必要があるようです。

`` `c＃
var hc1 =（uint）（value1？.GetHashCode（）?? 0）; //オーバーフローする可能性があります
var hc2 =（uint）（value2？.GetHashCode（）?? 0）; //オーバーフローする可能性があります

        uint hash = MixEmptyState();
        hash += 8; // can overflow

        hash = QueueRound(hash, hc1);
        hash = QueueRound(hash, hc2);

        hash = MixFinal(hash);
        return (int)hash; // can overflow

Note that this code already has 4 lines that can overflow.  It also has two helper functions you need to call (i'm ignoring MixEmptyState as that seems more like a constant).  MixFinal can *definitely* overflow:

```c#
        private static uint MixFinal(uint hash)
        {
            hash ^= hash >> 15;
            hash *= Prime2;
            hash ^= hash >> 13;
            hash *= Prime3;
            hash ^= hash >> 16;
            return hash;
        }

QueueRoundと同様に：

c# private static uint QueueRound(uint hash, uint queuedValue) { hash += queuedValue * Prime3; return Rol(hash, 17) * Prime4; }

だから私はこれがどのように機能するのか正直にわかりません:(

Roslynが（ILを使用して）（多くの場合）行うように、HashCodeソースをプロジェクトに追加するのはどれほどひどいことでしょうか。

これが機能することをどのように想像しますか？ 顧客は何を書き、コンパイラはそれに応じて何をしますか？

また、これらすべてに対処するのは、オーバーフローなしでuintからint32（およびその逆）に変換するパブリックヘルパーが.Netに既に公開されている場合です。

それらは存在しますか？ もしそうなら、私は簡単にVBバージョンを書くことができ、オーバーフローすることなくタイプ間を行き来する必要がある状況にこれらを使用するだけです。

テーブル生成コードも口に合わないのですか？

そう思います。 つまり、これを顧客の観点から考えてください。 彼らは、うまく自己完結し、妥当な結果をもたらすまともなGetHashCodeメソッドを望んでいます。 その機能を実行して、補助的ながらくたでコードを肥大化させることは、かなり不快なことになるでしょう。 また、C＃のエクスペリエンスが問題ないことを考えると、かなり悪いことです。

符号付きと符号なしの64ビット型の組み合わせとの間でキャストすることにより、おおよそ正しいオーバーフロー動作を得ることができる場合があります。 このようなもの（テストされておらず、VBキャスト構文がわかりません）：

Dim hashCode = -252780983
hashCode = (Int32)((Int32)((Unt64)hashCode * -1521134295) + (UInt64)i.GetHashCode())

次のものがオーバーフローしないことをどのように知っていますか？

c# (Int32)((Unt64)hashCode * -1521134295)

それとも、その問題の最終（int32）キャストですか？

オーバーフローチェックされたconv操作を使用することに気づいていませんでした。 キャストする前に32ビットまでマスクできると思います。

(Int32)(((Unt64)hashCode * -1521134295) & 0xFFFFFFFF)

uint32.Maxの値がInt32への変換時にオーバーフローするため、おそらく31ビット:)

それは可能です。 醜い...しかし可能です:)このコードにはたくさんのキャストがあります。

Ok。 私は実行可能な解決策があると思います。 今日生成するアルゴリズムの中核は次のとおりです。

c# hashCode = hashCode * -1521134295 + j.GetHashCode();

64ビットの計算を行っているが、「hashCode」は32ビットに制限されているとしましょう。 その場合、 <largest_32_bit> * -1521134295 + <largest_32_bit>は64ビットをオーバーフローしません。 したがって、常に64ビットで計算を実行してから、32（または32ビット）にクランプダウンして、次のラウンドがオーバーフローしないようにすることができます。

ありがとう！

@ MaStr11 @morganbr @sharwellと誰もがここ。 コードを更新して、VB用に以下を生成しました。

        Dim hashCode As Long = 2118541809
        hashCode = (hashCode * -1521134295 + a.GetHashCode()) And Integer.MaxValue
        hashCode = (hashCode * -1521134295 + b.GetHashCode()) And Integer.MaxValue
        Return CType(hashCode And Integer.MaxValue, Integer)

誰かが私を正気にチェックして、これが理にかなっていて、チェックモードがオンになっていてもオーバーフローしてはならないことを確認できますか？

@CyrusNajmabadi 、オーバーフローしません（Int64.Max = Int32.Max * Int32.Maxであり、定数がそれよりもはるかに小さいため）が、上位ビットをゼロにマスクしているため、31ビットハッシュのみです。 上位ビットをオンのままにしておくと、オーバーフローと見なされますか？

@CyrusNajmabadi hashCodeはLongで、0からInteger.MaxValueます。 なぜ私はこれを手に入れているのですか？

しかし、いいえ、実際にはオーバーフローすることはできません。

ところで、次善のハッシュを追加するよりも、RoslynにNuGetパッケージを追加してもらいたいと思います。

ただし、上位ビットをゼロにマスクしているため、31ビットのハッシュにすぎません。 上位ビットをオンのままにしておくと、オーバーフローと見なされますか？

それは良い点です。 私はuintsを使用していた別のアルゴリズムについて考えていたと思います。 したがって、longからuintに安全に変換するために、符号ビットを含める必要はありませんでした。 ただし、これはすべて符号付きの計算であるため、0xffffffffに対してマスクするだけで、各エントリを追加した後に下位32ビットのみを保持するようにすると問題ないと思います。

最適ではないハッシュを追加するよりも、RoslynにNuGetパッケージを追加してもらいたいです。

ユーザーは、必要に応じてすでにそれを行うことができます。 これは、ユーザーがこれらの依存関係を追加しない、または追加できない場合の対処方法です。 これは、ユーザーに適度に「十分に良い」ハッシュを提供することでもあります。 つまり、人々がよく採用する一般的な「x + y + z」アプローチよりも優れたものです。 すべてのユーザーのハッシュに関して「最適」とは何かについての適切な定義がないため、「最適」であることを意図していません。 ここで採用しているアプローチは、匿名型のコンパイラーによってすでにリリースされているアプローチであることに注意してください。 ユーザーのコードに大量の複雑さを追加することなく、適度に良好な動作を示します。 時間の経過とともに、ますます多くのユーザーが前進できるようになると、そのようなユーザーはゆっくりと消えて、ほとんどの人にとってHashCode.Combineに置き換えられる可能性があります。

だから私はそれで少し働き、私がすべての懸念に対処すると思う次のことを思いついた：

        Dim hashCode As Long = 2118541809
        hashCode = (hashCode * -1521134295 + a.GetHashCode()).GetHashCode()
        hashCode = (hashCode * -1521134295 + b.GetHashCode()).GetHashCode()
        Return CType(hashCode, Integer)

興味深いのは、 (hashCode * -1521134295 + a.GetHashCode())によって生成されたint64値で.GetHashCode()を具体的に呼び出すことです。 この64ビット値で.GetHashCodeを呼び出すと、ニーズに合った2つの優れたプロパティがあります。 まず、hashCodeが正当なint32値のみを格納するようにします（これにより、最終的に返されるキャストを常に安全に実行できます）。 次に、使用しているint64temp値の上位32ビットの貴重な情報が失われないようにします。

@CyrusNajmabadi実際にパッケージをインストールすることを申し出ることは私が求めていたものです。 それをする必要から私を救います。

HashCodeと入力した場合、System.HashCodeがMS nugetパッケージで提供されていると、Roslynがそれを提供します。

存在しないGetHashCodeオーバーロードを生成し、同じ操作でパッケージをインストールする必要があります。

ほとんどのユーザーにとって、これは適切な選択ではないと思います。 依存関係の追加は、ユーザーに強制されるべきではない非常に重い操作です。 ユーザーはそれらの選択を行う適切な時期を決定でき、IDEはそれを尊重します。 これは、これまですべての機能で採用してきたアプローチであり、人々が好むように見える健全なアプローチです。

注：参照を追加するために、このAPIはどのnugetパッケージに含まれていますか？

実装はSystem.Private.CoreLib.dllにあるため、ランタイムパッケージの一部として提供されます。 コントラクトはSystem.Runtime.dllです。

Ok。 その場合、ユーザーがより新しいターゲットフレームワークに移行した場合に、これを取得するように思われます。 そのようなことは、ユーザーのプロジェクトに対して「equals + hashcodeの生成」を実行させるステップではありません。