Runtime: 제안: 좋은 해시 코드를 더 쉽게 생성할 수 있도록 System.HashCode를 추가합니다.

에 만든 2016년 12월 09일 · 182코멘트 · 출처: dotnet/runtime

업데이트 6/16/17: 자원 봉사자를 찾고 있습니다

API 모양이 완성되었습니다. 그러나 우리는 여전히 구현에 사용할 후보 목록 중에서 가장 좋은 해시 알고리즘을 결정하고 있으며 각 알고리즘의 처리량/분포를 측정하는 데 도움을 줄 사람이 필요합니다. 해당 역할을 수행하고 싶다면 아래에 댓글을 남겨주세요.

업데이트 6/13/17: 제안 수락!

https://github.com/dotnet/corefx/issues/14354#issuecomment -308190321에서 @terrajobst 가 승인한 API는 다음과 같습니다.

// Will live in the core assembly
// .NET Framework : mscorlib
// .NET Core      : System.Runtime / System.Private.CoreLib
namespace System
{
    public struct HashCode
    {
        public static int Combine<T1>(T1 value1);
        public static int Combine<T1, T2>(T1 value1, T2 value2);
        public static int Combine<T1, T2, T3>(T1 value1, T2 value2, T3 value3);
        public static int Combine<T1, T2, T3, T4>(T1 value1, T2 value2, T3 value3, T4 value4);
        public static int Combine<T1, T2, T3, T4, T5>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5);
        public static int Combine<T1, T2, T3, T4, T5, T6>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5, T6 value6);
        public static int Combine<T1, T2, T3, T4, T5, T6, T7>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5, T6 value6, T7 value7);
        public static int Combine<T1, T2, T3, T4, T5, T6, T7, T8>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5, T6 value6, T7 value7, T8 value8);

        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();
    }
}

이 제안의 원본은 다음과 같습니다.

이론적 해석

좋은 해시 코드를 생성하기 위해 추악한 마법 상수를 사용하거나 코드를 비틀지 않아도 됩니다. 다음과 같이 나쁘지만 간결한 GetHashCode 구현을 작성하는 것이 덜 유혹적이어야 합니다.

class Person
{
    public override int GetHashCode() => FirstName.GetHashCode() + LastName.GetHashCode();
}

제안

해시 코드 생성을 캡슐화하고 개발자가 복잡한 세부 사항에 혼동되지 않도록 HashCode 유형을 추가해야 합니다. 다음은 https://github.com/dotnet/corefx/issues/14354#issuecomment -305019329를 기반으로 하는 내 제안이며 약간의 수정이 필요합니다.

// Will live in the core assembly
// .NET Framework : mscorlib
// .NET Core      : System.Runtime / System.Private.CoreLib
namespace System
{
    public struct HashCode
    {
        public static int Combine<T1>(T1 value1);
        public static int Combine<T1, T2>(T1 value1, T2 value2);
        public static int Combine<T1, T2, T3>(T1 value1, T2 value2, T3 value3);
        public static int Combine<T1, T2, T3, T4>(T1 value1, T2 value2, T3 value3, T4 value4);
        public static int Combine<T1, T2, T3, T4, T5>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5);
        public static int Combine<T1, T2, T3, T4, T5, T6>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5, T6 value6);
        public static int Combine<T1, T2, T3, T4, T5, T6, T7>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5, T6 value6, T7 value7);
        public static int Combine<T1, T2, T3, T4, T5, T6, T7, T8>(T1 value1, T2 value2, T3 value3, T4 value4, T5 value5, T6 value6, T7 value7, T8 value8);

        public void Add<T>(T value);
        public void Add<T>(T value, IEqualityComparer<T> comparer);
        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);

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

        public int ToHashCode();
    }
}

비고

이 API의 목표는 https://github.com/dotnet/corefx/issues/14354#issuecomment -305019329에서 @terrajobst 의 의견을 참조하십시오 . 그의 말은 모두 유효하다. 그러나 저는 특히 다음을 지적하고 싶습니다.

API 는 강력한 암호화 해시를 생성
API는 "a" 해시 코드를 제공하지만 특정 해시 코드 알고리즘을 보장하지는 않습니다. 이를 통해 나중에 다른 알고리즘을 사용하거나 다른 아키텍처에서 다른 알고리즘을 사용할 수 있습니다.
API는 주어진 프로세스 내에서 동일한 값이 동일한 해시 코드를 생성하도록 보장합니다. 동일한 앱의 다른 인스턴스는 무작위화로 인해 다른 해시 코드를 생성할 수 있습니다. 이를 통해 소비자가 해시 값을 유지하고 실수로 실행(또는 더 나쁜 경우 플랫폼 버전)에서 안정적인 것에 의존하지 않도록 할 수 있습니다.

api-approved area-System.Numerics up-for-grabs

출처

jamesqo

👍27 🎉3 ❤1 😄1

가장 유용한 댓글

결정

시나리오가 불분명하기 때문에 모든 AddRange 메소드를 제거해야 합니다. 배열은 매우 자주 나타날 가능성이 다소 낮습니다. 그리고 일단 더 큰 배열이 관련되면 문제는 계산을 캐시해야 하는지 여부입니다. 호출 측에서 for 루프를 보면 그것에 대해 생각할 필요가 있음을 분명히 알 수 있습니다.
또한 할당될 것이기 때문에 IEnumerable 오버로드를 AddRange 에 추가하고 싶지 않습니다.
string 와 StringComparison 가 걸리는 string Add 대한 오버로드가 필요하지 않다고 생각합니다. 예, IEqualityComparer 통해 호출하는 것보다 더 효율적일 수 있지만 나중에 수정할 수 있습니다.
GetHashCode 를 오류와 함께 사용되지 않는 것으로 표시하는 것은 좋은 생각이지만 한 단계 더 나아가 IntelliSense에서 숨길 수도 있습니다.

이것은 우리에게 다음을 남깁니다.

```C#
// 코어 어셈블리에 있을 것입니다.
// .NET 프레임워크: mscorlib
// .NET 코어 : System.Runtime / System.Private.CoreLib
네임스페이스 시스템
{
공개 구조체 해시 코드
{
public static int 결합(T1 값1);
public static int 결합(T1 값1, T2 값2);
public static int 결합(T1 값1, T2 값2, T3 값3);
public static int 결합(T1 값1, T2 값2, T3 값3, T4 값4);
public static int 결합(T1 값1, T2 값2, T3 값3, T4 값4, T5 값5);
public static int 결합(T1 값1, T2 값2, T3 값3, T4 값4, T5 값5, T6 값6);
public static int 결합(T1 값1, T2 값2, T3 값3, T4 값4, T5 값5, T6 값6, T7 값7);
public static int 결합(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();
}

}
```

terrajobst 에 2017년 06월 13일

🎉7 ❤4 👍2

모든 182 댓글

제안: 해시 무작위화 지원 추가

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

T 또는 Type type 는 동일한 유형에 대해 동일한 무작위 해시를 얻는 데 필요합니다.

AlexRadch 에 2016년 12월 09일

제안: 컬렉션 지원 추가

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);

AlexRadch 에 2016년 12월 09일

🎉1 👍1

다음 코드 HashCode.Empty.Combine(_field1).Combine(_field2).Combine(_field3).Combine(_field4).Combine(_field5); 는 Combine 호출 없이 인라인 최적화되어야 하기 때문에 Combine(_field1, _field2, _field3, _field4, _field5) 오버로드가 필요하지 않다고 생각합니다.

AlexRadch 에 2016년 12월 09일

@AlexRadch

제안: 컬렉션 지원 추가

예, 그것은 이 제안에 대한 나의 최종 계획의 일부였습니다. 하지만 이러한 메서드를 추가하기 전에 API가 어떻게 생겼는지에 초점을 맞추는 것이 중요하다고 생각합니다.

jamesqo 에 2016년 12월 09일

그는 coreclr의 문자열에 사용되는 Marvin32 해시와 같은 다른 알고리즘을 사용하기를 원했습니다. 이를 위해서는 HashCode의 크기를 8바이트로 확장해야 합니다.

내부적으로 4바이트 또는 8바이트 가치의 데이터를 저장하는 Hash32 및 Hash64 유형을 사용하는 것은 어떻습니까? 각각의 장단점을 문서화하십시오. Hash64는 X에 적합하지만 잠재적으로 느립니다. Hash32는 더 빠르지만 잠재적으로 분산되지 않을 수 있습니다(또는 실제로 트레이드오프가 무엇이든).

그는 해시 시드를 무작위로 지정하기를 원했기 때문에 해시가 결정적이지 않았습니다.

이것은 유용한 동작처럼 보입니다. 그러나 나는 이것을 통제하려는 사람들을 볼 수 있었습니다. 따라서 아마도 Hash를 생성하는 두 가지 방법이 있어야 합니다. 하나는 시드를 사용하지 않고(그리고 임의의 시드를 사용함) 시드를 제공하도록 허용하는 것입니다.

CyrusNajmabadi 에 2017년 03월 09일

참고: 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.Whatever API가 있으면 기쁠 것입니다.

감사 해요!

CyrusNajmabadi 에 2017년 03월 09일

MurmurHash는 어떻습니까? 그것은 합리적으로 빠르며 매우 좋은 해싱 속성을 가지고 있습니다. 또한 32비트 해시를 내보내는 구현과 128비트 해시를 내보내는 구현의 두 가지 구현이 있습니다.

tannergooding 에 2017년 03월 09일

32비트 및 128비트 형식 모두에 대한 벡터화된 구현도 있습니다.

tannergooding 에 2017년 03월 09일

@tannergooding MurmurHash는 이 블로그 게시물 의 소리에서 볼 때 빠르지만 안전하지 않습니다.

jamesqo 에 2017년 04월 20일

@jkotas , 작년에 우리가 논의한 이후로 32비트에서 >4바이트 구조체에 대해 더 나은 코드를 생성하는 것과 관련하여 JIT에서 작업이 있었습니까? 또한 @CyrusNajmabadi 의 제안에 대해 어떻게 생각

내부적으로 4바이트 또는 8바이트 가치의 데이터를 저장하는 Hash32 및 Hash64 유형을 사용하는 것은 어떻습니까? 각각의 장단점을 문서화하십시오. Hash64는 X에 적합하지만 잠재적으로 느립니다. Hash32는 더 빠르지만 잠재적으로 분산되지 않을 수 있습니다(또는 실제로 트레이드오프가 무엇이든).

나는 여전히 이 유형이 개발자에게 제공하기에 매우 가치가 있고 2.0에 포함하는 것이 좋을 것이라고 생각합니다.

jamesqo 에 2017년 04월 20일

@jamesqo , 나는 이 구현이 암호학적으로 안전할 필요가 있다고 생각하지 않습니다(즉, 명시적 암호학적 해싱 기능의 목적).

또한 해당 기사는 Murmur2에 적용됩니다. Murmur3 알고리즘에서 문제가 해결되었습니다.

tannergooding 에 2017년 04월 20일

작년 논의 이후 32비트에서 >4바이트 구조체에 대한 더 나은 코드 생성에 관한 JIT

나는 아무것도 모른다.

@CyrusNajmabadi 의 제안에 대해 어떻게 생각

프레임워크 유형은 95% 이상의 경우에 잘 작동하는 간단한 선택이어야 합니다. 가장 빠른 것은 아니지만 괜찮습니다. Hash32와 Hash64 중 하나를 선택하라는 것은 간단한 선택이 아닙니다.

jkotas 에 2017년 04월 20일

괜찮습니다. 그러나 우리는 적어도 그 95%의 경우에 대해 충분히 좋은 솔루션을 가질 수 있습니까? 지금은 아무것도 없습니다... :-/

CyrusNajmabadi 에 2017년 04월 20일

해시코드 = 해시코드 * -1521134295 + EqualityComparer.Default.GetHashCode(this.s);

@CyrusNajmabadi 왜 this.s.GetHashCode()가 아니라 EqualityComparer를 여기에서 호출합니까?

jkotas 에 2017년 04월 20일

구조체가 아닌 경우: null을 확인할 필요가 없도록 합니다.

이는 배후에서 익명 유형에 대해서도 생성하는 것과 유사합니다. 사용자에게 더 만족스러운 코드를 생성하기 위해 알려진 null이 아닌 값의 경우를 최적화합니다. 하지만 이를 위한 API가 내장되어 있으면 좋을 것입니다.

CyrusNajmabadi 에 2017년 04월 20일

EqualityComparer.Default.GetHashCode에 대한 호출은 null 검사보다 10배 이상 더 비쌉니다... .

jkotas 에 2017년 04월 20일

EqualityComparer.Default.GetHashCode에 대한 호출은 null 검사보다 10배 이상 더 비쌉니다.

문제처럼 들립니다. 좋은 해시 코드 API만 있다면 내가 맡을 수 있는 Fx를 호출할 수 있습니다. :)

(또한 우리는 익명 유형에서 그 문제를 가지고 있습니다. 그것이 우리가 거기에서도 생성하는 것이기 때문입니다).

우리가 튜플에 대해 무엇을 하는지 확실하지 않지만 비슷하다고 생각합니다.

CyrusNajmabadi 에 2017년 04월 20일

우리가 튜플에 대해 무엇을 하는지 확실하지 않지만 비슷하다고 생각합니다.

System.Tuple 는 역사적인 이유로 EqualityComparer<Object>.Default 를 통과합니다. System.ValueTuple 는 null 검사로 Object.GetHashCode를 호출합니다( https://github.com/dotnet/coreclr/blob/master/src/mscorlib/shared/System/ValueTuple.cs#L809).

jkotas 에 2017년 04월 20일

안 돼. 튜플이 "HashHelpers"를 사용할 수 있는 것 같습니다. 사용자가 동일한 혜택을 받을 수 있도록 노출될 수 있습니까?

CyrusNajmabadi 에 2017년 04월 20일

엄청난. 비슷한 일을 하게 되어 기쁩니다. 나는 우리의 익명 유형이 합리적인 모범 사례라고 생각했기 때문에 익명 유형에서 시작했습니다. 그렇지 않다면 괜찮습니다. :)

하지만 그것이 내가 여기 있는 이유가 아닙니다. 저는 실제로 해시를 효과적으로 결합하는 시스템을 얻기 위해 왔습니다. 그것이 제공될 수 있다면 우리는 난수를 하드코딩하고 해시 값을 직접 결합하는 대신 기꺼이 호출할 것입니다.

CyrusNajmabadi 에 2017년 04월 20일

컴파일러가 생성한 코드에 가장 적합하다고 생각하는 API 형태는 무엇입니까?

jkotas 에 2017년 04월 20일

말 그대로 이전에 제시된 32비트 솔루션 중 어느 것이든 저에게는 괜찮을 것입니다. 젠장, 64비트 솔루션은 괜찮습니다. "나는 일종의 합리적인 방식으로 해시를 결합하고 합리적으로 분포된 결과를 생성할 수 있습니다"라고 말하는 일종의 API입니다.

CyrusNajmabadi 에 2017년 04월 20일

나는 다음 진술을 조화시킬 수 없습니다.

크기가 4바이트인 변경할 수 없는 HashCode 구조체가 있습니다. 여기에는 DJBX33X와 같은 알고리즘을 통해 제공된 해시 코드와 자체 해시 코드를 혼합하여 새로운 HashCode를 반환하는 Combine(int) 메서드가 있습니다.

@jkotas 는 DJBX33X와 같은 알고리즘이 충분히 강력하다고 생각하지 않았습니다.

그리고

프레임워크 유형은 95% 이상의 경우에 잘 작동하는 간단한 선택이어야 합니다.

95%의 경우에 충분히 잘 작동하는 간단한 32비트 누적 해시를 생각해낼 수 없습니까? 여기서 잘 처리되지 않는 경우는 무엇이며, 95%의 경우라고 생각하는 이유는 무엇입니까?

CyrusNajmabadi 에 2017년 04월 20일

@jkotas , 성능이 이 유형에 정말 중요합니까? 나는 해시 테이블 조회와 같은 평균 것들에 생각 이 몇 구조체 복사보다 훨씬 더 많은 시간이 걸릴 것입니다. 병목 현상으로 판명되면 아무도 최적화 작업을 하지 않을 때 이 API를 차단하는 것보다 API가 릴리스된 후 32비트 구조체 복사본을 최적화하도록 JIT 팀에 요청하는 것이 합리적입니까? 사본?

jamesqo 에 2017년 04월 20일

95%의 경우에 충분히 잘 작동하는 간단한 32비트 누적 해시를 생각해낼 수 없습니까?

우리는 기본적으로 문자열에 대한 32비트 누적 해시를 심하게 태워 왔으며 이것이 .NET Core의 문자열에 대한 Marvin 해시 - https://github.com/dotnet/corert/blob/87e58839d6629b5f90777f886a2f52d7a99c076f/s src/System/Marvin.cs#L25. 나는 우리가 여기서 같은 실수를 반복하고 싶지 않다고 생각합니다.

@jkotas , 성능이 이 유형에 정말 중요합니까?

성능이 중요하다고 생각하지 않습니다. 이 API가 자동 생성 컴파일러 코드에서 사용될 것 같기 때문에 보이는 것보다 생성된 더 작은 코드를 선호해야 한다고 생각합니다. 유창하지 않은 패턴은 더 작은 코드입니다.

jkotas 에 2017년 04월 20일

우리는 기본적으로 문자열에 대한 32비트 누적 해시로 인해 심하게 화상을 입었습니다.

95%의 경우는 아닌 것 같습니다. 우리는 오늘날 수동으로 작업을 수행하는 모든 유형에 대해 "충분히 좋은" 해시를 원하는 일반 개발자에 대해 이야기하고 있습니다.

이 API가 자동 생성 컴파일러 코드에서 사용될 것 같기 때문에 보이는 것보다 생성된 더 작은 코드를 선호해야 한다고 생각합니다. 유창하지 않은 패턴은 더 작은 코드입니다.

이것은 Roslyn 컴파일러에서 사용하지 않습니다. 이것은 사용자가 해당 유형에 대해 GetHashCode를 생성하도록 도울 때 Roslyn IDE에서 사용하기 위한 것입니다. 이것은 사용자가 보고 유지해야 하는 코드이며 다음과 같이 합리적입니다.

```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;

CyrusNajmabadi 에 2017년 04월 20일

내 말은, 우리는 이미 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();

하지만 지금 당신은 사람들이 일종의 합리적인 기본 해싱 동작을 얻기 위해 (잠재적으로 큰) 구조체를 생성하도록 강요하고 있습니다.

CyrusNajmabadi 에 2017년 04월 20일

우리는 오늘날 수동으로 작업을 수행하는 모든 유형에 대해 "충분히 좋은" 해시를 원하는 일반 개발자에 대해 이야기하고 있습니다.

원래 문자열 해시는 일반 개발자에게 잘 작동하는 "충분히 좋은" 해시였습니다. 그러나 ASP.NET 웹 서버는 수신된 내용을 해시 테이블에 저장하는 경향이 있기 때문에 DoS 공격에 취약하다는 것이 발견되었습니다. 따라서 "충분히 좋은" 해시는 기본적으로 나쁜 보안 문제로 바뀌었습니다.

우리는 그것이 튜플에 충분하다고 생각합니다.

반드시 아닙니다. 나중에 알고리즘을 수정할 수 있는 옵션을 제공하는 해시 코드를 무작위로 만들기 위해 튜플에 대한 백스톱 조치를 만들었습니다.

jkotas 에 2017년 04월 20일

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

이것은 나에게 합리적으로 보입니다.

jkotas 에 2017년 04월 20일

나는 당신의 위치를 이해하지 못합니다. 두 가지를 말씀하시는 것 같습니다.

원래 문자열 해시는 일반 개발자에게 잘 작동하는 "충분히 좋은" 해시였습니다. 그러나 ASP.NET 웹 서버는 수신된 내용을 해시 테이블에 저장하는 경향이 있기 때문에 DoS 공격에 취약하다는 것이 발견되었습니다. 따라서 "충분히 좋은" 해시는 기본적으로 나쁜 보안 문제로 바뀌었습니다.

알겠습니다. 그렇다면 보안/DoS 문제가 있는 사람들에게 좋은 해시 코드를 제공하겠습니다.

프레임워크 유형은 95% 이상의 경우에 잘 작동하는 간단한 선택이어야 합니다.

자, 그렇다면 95%의 경우에 충분한 해시 코드를 제공하겠습니다. 보안/DoS 문제가 있는 사람은 해당 목적으로 문서화된 특수 양식을 사용할 수 있습니다.

반드시 아닙니다. 나중에 알고리즘을 수정할 수 있는 옵션을 제공하는 해시 코드를 무작위로 만들기 위해 튜플에 대한 백스톱 조치를 만들었습니다.

확인. 사용자 가 동일한 메커니즘을 사용할 수 있도록 노출할 수 있습니까?

--
"보편적인 솔루션을 만들 수 없기 때문에 모두가 스스로 해결해야 한다"고 말하는 것처럼 들리기 때문에 저는 여기서 정말 어려움을 겪고 있습니다. 그것은 최악의 장소 중 하나인 것 같습니다. 확실히 대부분의 고객은 DoS 문제에 대해 자체 '마빈 해시'를 롤링하는 것에 대해 생각하지 않기 때문입니다. 그들은 단지 하나의 최종 해시로 필드 해시를 추가, xoring 또는 잘못 결합했을 뿐입니다.

95%의 경우에 관심이 있다면 일반적으로 좋은 enogh 해시를 만들어야 합니다. 5%의 경우를 생각한다면 그에 대한 특화된 솔루션을 제공할 수 있습니다.

CyrusNajmabadi 에 2017년 04월 20일

👍6

이것은 나에게 합리적으로 보입니다.

좋습니다 :) 그런 다음 노출할 수 있습니까?

```c#
네임스페이스 System.Numerics.Hashing
{
내부 정적 클래스 HashHelpers
{
공개 정적 읽기 전용 int RandomSeed = 새로운 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);

이것은 대다수의 경우에 실제로 "충분히 좋은" 이점이 있는 동시에 사람들을 무작위 값으로 초기화하는 좋은 경로로 안내하여 무작위가 아닌 해시에 의존하지 않도록 합니다.

CyrusNajmabadi 에 2017년 04월 20일

보안/DoS 문제가 있는 사람은 해당 목적으로 문서화된 특수 양식을 사용할 수 있습니다.

모든 ASP.NET 앱에는 보안/DoS 문제가 있습니다.

jkotas 에 2017년 04월 20일

좋습니다 :) 그런 다음 노출할 수 있습니까?

이것은 내가 합리적으로 말한 것과 다릅니다.

https://github.com/aspnet/Common/blob/dev/shared/Microsoft.Extensions.HashCodeCombiner.Sources/HashCodeCombiner.cs 에 대해 어떻게 생각

jkotas 에 2017년 04월 20일

@jkotas 들었습니다 :p

따라서 여기서 문제는 개발자가 DoS 공격에 취약한 시점을 모른다는 것입니다. DoS 공격에 대한 문제가 아니기 때문에 Marvin32를 사용하도록 문자열을 전환한 것입니다.

'95%의 경우는 중요하지 않다'는 식으로 말해서는 안 된다. 증명할 방법이 없고 성능 대가를 치르더라도 주의를 기울여야 하기 때문이다. 그것에서 벗어나려면 해시 코드 구현에 "이것으로 충분해 보입니다"라고 결정하는 것이 아니라 Crypto Board 검토가 필요합니다.

blowdart 에 2017년 04월 20일

👍1

모든 ASP.NET 앱에는 보안/DoS 문제가 있습니다.

확인. 그래서 오늘날 아무도 해시코드에 대한 도움을 받지 못하여 일을 제대로 하지 못하는 문제를 어떻게 처리하고 있습니까? 분명히 그 세계의 상태를 갖는 것이 용인되었습니다. 그렇다면 오늘날 사람들이 손으로 굴리는 것보다 더 나은 성능을 보이는 합리적인 해싱 시스템을 제공하면 어떤 피해를 입게 될까요?

입증할 방법이 없고 성능 비용이 있더라도 주의를 기울여야 하기 때문입니다.

당신이 무언가를 제공하지 않으면 사람들은 계속해서 나쁜 일을 할 것입니다. 완벽한 것이 없기 때문에 "충분히 좋은 것"을 거부하는 것은 오늘날 우리가 가진 열악한 현상을 의미합니다.

모든 ASP.NET 앱에는 보안/DoS 문제가 있습니다.

이것을 설명할 수 있습니까? 내가 알기로는 임의의 입력을 수락한 다음 입력을 특수하게 조작할 수 있는 경우 성능이 떨어지는 일부 데이터 구조에 저장하는 경우 DoS 문제가 있습니다. 좋아, 나는 그것이 사용자로부터 온 웹 시나리오에서 얻는 문자열에 대한 우려를 이해합니다.

그렇다면 이 시나리오에서 사용되지 않는 나머지 유형에는 어떻게 적용됩니까?

다음 유형 세트가 있습니다.

DoS 안전해야 하는 사용자 유형. 지금 우리는 도울 수 있는 것이 아무것도 없습니다. 그래서 사람들이 옳은 일을 하지 않을 가능성이 있기 때문에 우리는 이미 좋지 않은 상황에 처해 있습니다.
DoS 안전이 필요하지 않은 사용자 유형. 지금 우리는 도울 수 있는 것이 아무것도 없습니다. 그래서 사람들이 옳은 일을 하지 않을 가능성이 있기 때문에 우리는 이미 좋지 않은 상황에 처해 있습니다.
DoS 안전해야 하는 프레임워크 유형. 지금은 DoS를 안전하게 만들었지만 API를 통해 노출하지 않습니다.
DoS 안전하지 않아도 되는 프레임워크 유형. 지금은 해시를 제공했지만 API를 통해 노출하지 않습니다.

기본적으로 우리는 이러한 경우가 중요하다고 생각하지만 실제로 사용자에게 '1' 또는 '2'를 처리하는 솔루션을 제공할 만큼 중요하지 않습니다. 우리는 '2'에 대한 솔루션이 '1'에 좋지 않을 것이라고 걱정하기 때문에 애초에 제공조차 하지 않을 것입니다. 그리고 우리가 '1'에 대한 해결책조차 제시하지 않는다면 우리는 믿을 수 없을 정도로 이상한 위치에 있는 것처럼 느껴집니다. 우리는 DoSing과 ASP에 대해 걱정하고 있지만 실제로 사람들을 도울 만큼 걱정하지 않습니다. 그리고 우리는 그 문제로 사람들을 돕지 않을 것이기 때문에 DoS가 아닌 경우에는 기꺼이 도와줄 생각도 없습니다.

이 두 가지 경우가 중요하다면(저는 기꺼이 수락할 수 있습니다) 두 개의 API를 제공하지 않는 이유는 무엇입니까? 문서화하십시오. 무엇을 위한 것인지 명확히 하십시오. 사람들이 올바르게 사용하면 좋습니다 . 사람들이 그것을 제대로 사용하지 않는다면 그것은 여전히 괜찮습니다. 결국, 그들은 어쨌든 오늘날 제대로 일을 하지 않을 가능성이 높으므로 어떻게 상황이 더 나빠질 수 있습니까?

CyrusNajmabadi 에 2017년 04월 20일

👍4

당신은 무엇을 생각합니까

나는 어떤 식 으로든 의견이 없습니다. 고객이 사용할 수 있는 API로 허용 가능한 성능과 명확한 코드가 포함된 간단한 API를 제공하는 API라면 괜찮습니다.

정렬된 방식으로 필드/속성 집합을 결합하려는 경우의 99%를 처리하는 간단한 정적 형식이 있으면 좋을 것 같습니다. 이 유형에 그런 것을 상당히 간단하게 추가할 수 있을 것 같습니다.

CyrusNajmabadi 에 2017년 04월 20일

심플한 스태틱 형태가 있으면 좋을 것 같아요

동의하다.

jkotas 에 2017년 04월 20일

정렬된 방식으로 필드/속성 집합을 결합하려는 경우의 99%를 처리하는 간단한 정적 형식이 있으면 좋을 것 같습니다. 이 유형에 그런 것을 상당히 간단하게 추가할 수 있을 것 같습니다.

동의하다.

일종의 API가 구현되는 것을 정말로 보고 싶기 때문에 이 문제의 중간에서 두 분을 모두 만나고 싶습니다. @jkotas 나는 당신이 불변의 인스턴스 기반 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
}

이것이 합리적으로 보입니까?

jamesqo 에 2017년 04월 20일

지금은 내 게시물을 편집할 수 없지만 모든 메서드가 T를 수락할 수 없다는 것을 깨달았습니다. 이 경우 모든 int를 수락하고 사용자가 GetHashCode를 호출하도록 하는 8개의 오버로드만 가질 수 있습니다.

jamesqo 에 2017년 04월 20일

이 두 가지 경우가 중요하다면(저는 기꺼이 수락할 수 있습니다) 두 개의 API를 제공하지 않는 이유는 무엇입니까? 문서화하십시오. 무엇을 위한 것인지 명확히 하십시오. 사람들이 올바르게 사용하면 좋습니다. 사람들이 그것을 제대로 사용하지 않는다면 그것은 여전히 괜찮습니다. 결국, 그들은 어쨌든 오늘 일을 제대로 하지 않을 가능성이 높으니 어떻게 상황이 더 나빠질까요?

사람들은 그곳에 있을 때 물건을 제대로 사용하지 않기 때문입니다. 간단한 예를 들어 보겠습니다. XSS. 처음부터 웹 양식에도 HTML 인코딩 출력 기능이 있었습니다. 그러나 개발자는 위험을 알지 못했고 올바르게 수행하는 방법을 몰랐고 너무 늦었을 때 앱이 게시되었으며 웁스, 이제 인증 쿠키가 해제되었습니다.

사람들에게 보안 선택권을 주는 것은 그들이

문제에 대해 알고 있습니다.
위험이 무엇인지 이해하십시오.
이러한 위험을 평가할 수 있습니다.
해야 할 일을 쉽게 찾을 수 있습니다.

이러한 가정은 일반적으로 대다수의 개발자에게 적용되지 않으며 너무 늦었을 때만 문제를 찾습니다. 개발자는 보안 회의에 가지 않고 백서를 읽지 않으며 솔루션을 이해하지 못합니다. 그래서 ASP.NET HashDoS 시나리오에서 우리는 그들을 위해 선택했고, 기본적으로 보호했습니다. 그것이 옳은 일이었고 가장 큰 영향을 미쳤기 때문입니다. 그러나 우리는 그것을 문자열에만 적용했고, 이는 사용자 입력으로 커스텀 클래스를 생성하는 사람들을 나쁜 위치에 남겨두었습니다. 우리는 옳은 일을 해야 하고, 지금 그 고객을 보호하도록 돕고, 실패가 아닌 성공의 구덩이를 가지고 기본으로 설정해야 합니다. 보안을 위한 API 설계는 때때로 선택이 아니라 사용자가 알든 모르든 사용자를 돕는 것입니다.

blowdart 에 2017년 04월 20일

👍4

사용자는 항상 보안에 중점을 두지 않은 해시를 만들 수 있습니다. 그래서 두 가지 옵션이 주어졌을 때

기본 해시 유틸리티는 보안을 인식하지 않습니다. 사용자는 보안 인식 해시 함수를 만들 수 있습니다.
기본 해시 유틸리티는 보안을 인식합니다. 사용자는 사용자 지정 비보안 인식 해시 함수를 만들 수 있습니다.

그렇다면 두 번째가 더 나을 것입니다. 제안된 것은 전체 암호화 해시의 성능에 영향을 미치지 않습니다. 그래서 그것은 좋은 타협을 만드는가?

benaadams 에 2017년 05월 02일

이 스레드에서 실행 중인 질문 중 하나는 어떤 알고리즘이 모든 사람에게 완벽한가 하는 것입니다. 완벽한 알고리즘은 없다고 말하는 것이 안전하다고 생각합니다. 그러나 @CyrusNajmabadi 가 보여준 것과 같은 코드보다 더 나은 것을 제공하는 것을 막을 수는 없다고 생각합니다. 이 코드는 일반적인 .NET 입력 및 기타 일반적인 해셔 버그(예: 입력 데이터 손실 또는 쉽게 재설정 가능).

"최상의 알고리즘" 문제를 해결하기 위해 몇 가지 옵션을 제안하고 싶습니다.

명시적 선택: 비암호화 해시 모음(예: xxHash, Marvin32 및 SpookyHash)에 대한 API 제안을 곧 보낼 계획입니다. 이러한 API는 HashCode 또는 HashCodeHelper 유형과 사용법이 약간 다르지만 논의를 위해 이러한 차이점을 해결할 수 있다고 가정합니다. GetHashCode에 해당 API를 사용하는 경우:
- 생성된 코드는 수행 중인 작업에 대해 명시적입니다. Roslyn이 Marvin32.Create(); 생성하면 고급 사용자에게 무엇을 하기로 결정했는지 알릴 수 있으며 원하는 경우 제품군의 다른 알고리즘으로 쉽게 변경할 수 있습니다.
- 변경 사항을 깨는 것에 대해 걱정할 필요가 없다는 의미입니다. 비무작위화/빈약한 엔트로피/느린 알고리즘으로 시작하는 경우 Roslyn을 업데이트하여 새 코드에서 다른 것을 생성하기 시작하면 됩니다. 이전 코드는 이전 해시를 계속 사용하고 새 코드는 새 해시를 사용합니다. 개발자(또는 Roslyn 코드 수정)는 원하는 경우 이전 코드를 변경할 수 있습니다.
- 내가 생각할 수 있는 가장 큰 단점은 GetHashCode에 대해 원하는 일부 최적화가 다른 알고리즘에 해로울 수 있다는 것입니다. 예를 들어, 32비트 내부 상태는 불변 구조체와 잘 작동하지만 (예를 들어) CityHash의 256비트 내부 상태는 복사하는 데 많은 시간을 낭비할 수 있습니다.

무작위화: 적절하게 무작위화된 알고리즘으로 시작합니다( @CyrusNajmabadi 가 무작위 초기 값으로 표시한 코드는 무작위성을 제거할 수 있기 때문에 계산되지 않습니다). 이렇게 하면 호환성 문제 없이 구현을 변경할 수 있습니다. 알고리즘을 변경하더라도 성능 변화에 대해 매우 민감해야 합니다. 그러나 아키텍처당(또는 장치당) 선택을 할 수 있기 때문에 이는 잠재적인 장점이기도 합니다. 예를 들어 이 사이트 는 xxHash가 x64 Mac에서 가장 빠른 반면 SpookyHash는 Xbox 및 iPhone에서 가장 빠릅니다. 어느 시점에서 알고리즘을 변경할 의도로 이 경로를 따라간다면 64비트 이상의 내부 상태가 있는 경우 여전히 합리적인 성능을 갖는 API를 설계하는 것에 대해 생각할 필요가 있습니다.

CC @bartonjs , @terrajobst

morganbr 에 2017년 05월 06일

👍2

@morganbr 하나의 완벽한 알고리즘은 없지만 대부분의 경우 꽤 잘 작동하는 일부 알고리즘을 간단하고 이해하기 쉬운 API를 사용하여 노출하는 것이 가장 유용한 작업이라고 생각합니다. 고급 용도의 경우 그 외에도 알고리즘 모음을 갖는 것이 좋습니다. 하지만 이것이 유일한 선택은 아니어서 Dictionary 에 내 물건을 넣을 수 있도록 Marvin이 누군지 알 필요가 없습니다.

svick 에 2017년 05월 07일

👍3 😄1

내 물건을 사전에 넣을 수 있도록 Marvin이 누구인지 배울 필요가 없습니다.

나는 당신이 그것을 넣는 방식을 좋아합니다. 나는 또한 당신이 사전 자체를 언급하는 것을 좋아합니다. IDictionary는 모든 종류의 다른 품질을 가진 수많은 다른 impls를 가질 수 있는 것입니다(많은 플랫폼의 컬렉션 API 참조). 그러나 우리는 여전히 모든 범주에서 탁월하지는 않더라도 전반적으로 괜찮은 작업을 수행하는 기본 '사전'을 제공합니다.

나는 사람들의 톤이 해싱 도서관에서 무엇을 찾고 그의를 생각한다. 모든 목적에 완벽하지는 않더라도 작업을 완료하는 것.

CyrusNajmabadi 에 2017년 05월 07일

👍3

@morganbr 내 생각에 사람들은 현재 하고 있는 것보다 더 나은 GetHashCode를 작성하는 방법을 원한다고 생각합니다(일반적으로 웹에서 복사한 수학 연산의 일부 잡기 조합). 그 룬에 대한 기본적인 암시만 제공할 수 있다면 사람들은 행복할 것입니다. 그런 다음 특정 해싱 기능이 매우 필요한 경우 고급 사용자를 위한 비하인드 API를 사용할 수 있습니다.

다시 말해, 오늘날 해시코드를 작성하는 사람들은 Spooky vs Marvin vs Murmur를 원하는 이유를 알지 못하거나 신경 쓰지 않을 것입니다. 특정 해시 코드 중 하나가 특별히 필요한 사람만 검색할 것입니다. 그러나 많은 사람들은 "여기 내 개체의 상태가 있습니다. 사전과 함께 사용할 수 있는 빠르고 잘 분산된 해시를 생성할 수 있는 방법을 제공하세요. 신뢰할 수 없는 입력을 받아 해시하고 저장합니다."

CyrusNajmabadi 에 2017년 05월 07일

👍3 ❤1

@CyrusNajmabadi 문제는 호환성에 대한 현재 개념을 미래로 확장하면 이 유형이

Once는 안정적인 무작위 방식으로 시작하면 실행에서 실행으로 값에 의존할 수 없기 때문에 구현을 변경하기 쉬워진다고 주장할 수 있습니다. 그러나 몇 년 후 우리는 해시 버킷의 균형을 유지하면서 일반적으로 더 나은 성능을 제공하지만 List\

Morgan의 제안에 따르면 오늘 작성하는 코드는 사실상 영원히 동일한 성능 특성을 가질 것입니다. 더 나아질 수 있었던 응용 프로그램의 경우 이것은 불행한 일입니다. 더 나빠졌을 응용 프로그램의 경우 이것은 환상적입니다. 그러나 새 알고리즘을 찾으면 체크인하고 Roslyn을 변경하고(ReSharper/etc로 변경 제안) SomeThingThatWasConsideredAwesomeIn2018 대신 NewAwesomeThing2019로 생성을 시작합니다.

이와 같은 슈퍼 블랙박스는 단 한 번만 가능합니다. 그런 다음 우리는 영원히 붙어 있습니다. 그런 다음 누군가가 더 나은 평균 성능을 가진 다음 것을 작성합니다. 그래서 당신이 그들 사이에서 선택해야 하는 이유를 모르는 두 개의 블랙박스 구현이 있습니다. 그리고 나서... 그리고 나서... .

따라서 Roslyn/ReSharper/etc가 Marvin32, Murmur, FastHash 또는 IntPtr.Size 기반 조합/조건을 사용하여 GetHashCode를 자동으로 작성한 이유를 모를 수도 있습니다. 하지만 당신은 그것을 들여다볼 수 있는 힘이 있습니다. 그리고 새로운 정보가 공개되면 나중에 유형을 변경할 수 있는 권한이 있습니다. 하지만 우리는 또한 그대로 유지할 수 있는 권한도 주었습니다. (만약 우리가 이것을 작성한다면 슬픈 일이 될 것입니다. 그리고 3년 안에 Roslyn/ReSharper/etc는 명시적으로 그것을 호출하는 것을 피하게 될 것입니다. 왜냐하면 새로운 알고리즘이 훨씬 더 낫기 때문입니다... 일반적으로).

bartonjs 에 2017년 05월 08일

👎1

@bartonjs .Net이 블랙박스 알고리즘이나 데이터 구조를 제공하는 모든 곳에서 해싱이 다른 점은 무엇입니까? 예를 들어 정렬(introsort), Dictionary (배열 기반 개별 연결), StringBuilder (8k 청크의 연결 목록), 대부분의 LINQ.

svick 에 2017년 05월 08일

오늘은 이에 대해 자세히 살펴보았습니다. 이 문제에 대해 앞뒤로 지연된 점 사과드립니다.

요구 사항

누구를 위한 API입니까?
- API 는 강력한 암호화 해시를 생성
- 하지만: API는 프레임워크 자체(예: BCL 및 ASP.NET)에서 사용할 수 있도록 충분히 우수해야 합니다.
- 그러나 이것이 우리가 모든 곳에서 API를 사용해야 한다는 것을 의미하지는 않습니다. 보안/DOS 위험을 위해 또는 성능 때문에 사용자 지정 하나를 사용하려는 FX의 일부가 있어도 괜찮습니다. 예외는 항상 존재합니다 .
이 해시의 원하는 속성은 무엇입니까?
- 입력의 모든 비트가 사용됩니다.
- 결과가 잘 분배됨
- API는 "a" 해시 코드를 제공하지만 특정 해시 코드 알고리즘을 보장하지는 않습니다. 이를 통해 나중에 다른 알고리즘을 사용하거나 다른 아키텍처에서 다른 알고리즘을 사용할 수 있습니다.
- API는 주어진 프로세스 내에서 동일한 값이 동일한 해시 코드를 생성하도록 보장합니다. 동일한 앱의 다른 인스턴스는 무작위화로 인해 다른 해시 코드를 생성할 수 있습니다. 이를 통해 소비자가 해시 값을 유지하고 실수로 실행(또는 더 나쁜 경우 플랫폼 버전)에서 안정적인 것에 의존하지 않도록 할 수 있습니다.

API 모양

    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#
공개 부분 클래스 고객
{
공개 재정의 int GetHashCode() =>
HashCode.Combine(
ID,
StringComparer.OrdinalIgnoreCase.GetHashCode(이름),
StringComparer.OrdinalIgnoreCase.GetHashCode(성),
);
}

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 에 2017년 05월 30일

👍8 🎉4

@terrajobst , 우리는 public static int Combine<T1>(T1 value); 도 원할 수 있습니다. 나는 그것이 조금 재미있어 보인다는 것을 알고 있지만 제한된 입력 해시 공간을 가진 무언가로부터 비트를 확산시키는 방법을 제공할 것입니다. 예를 들어, 많은 열거형에는 코드의 맨 아래 몇 비트만 사용하는 몇 가지 가능한 해시만 있습니다. 일부 컬렉션은 해시가 더 넓은 공간에 퍼져 있다는 가정 하에 구축되므로 비트를 분산하면 컬렉션이 보다 효율적으로 작동하는 데 도움이 될 수 있습니다.

morganbr 에 2017년 05월 31일

👍4

public void Add(string value, StrinComparison comparison);

Nit: StringComparison 매개변수는 StringComparison 가 매개변수로 사용되는 다른 모든 곳에서 사용되는 이름과 일치하도록 comparisonType 로 이름을 지정해야 합니다.

justinvp 에 2017년 05월 31일

👍1

알고리즘을 선택하는 데 도움이 되는 기준은 다음과 같습니다.

알고리즘에 좋은 눈사태 효과가 있습니까? 즉, 입력의 모든 비트가 출력의 모든 비트를 뒤집을 확률이 50%입니까? 이 사이트 에는 몇 가지 인기 있는 알고리즘에 대한 연구가 있습니다.
작은 입력에 대해 알고리즘이 빠릅니까? HashCode.Combine은 일반적으로 8개 이하의 정수를 처리하므로 시작 시간이 처리량보다 더 중요할 수 있습니다. 이 사이트 에는 흥미로운 데이터 세트가 있습니다. 이것은 또한 서로 다른 아키텍처 또는 기타 피벗(OS, AoT 대 JIT 등)에 대해 서로 다른 답변이 필요할 수 있는 곳입니다.

우리가 정말로 보고 싶은 것은 C#으로 작성된 후보자의 성능 수치이므로 그들의 특성이 .NET에서 유지될 것이라고 합리적으로 확신할 수 있습니다. 당신이 후보를 작성하고 우리가 이것을 위해 그것을 선택하지 않는다면, 내가 실제로 비암호화 해시 API에 대한 API 제안을 함께 얻을 때마다 여전히 유용한 작업이 될 것입니다.

다음은 평가할 가치가 있다고 생각되는 몇 가지 후보자입니다(그러나 다른 사람을 자유롭게 제안할 수 있음).

Marvin32( 여기에 이미 C# 구현이
xxHash32 (가장 빠른 x86에서 알고리즘에 여기 SMHasher에 따라 최고의 품질을 가지고)
FarmHash(x64 에서 가장 빠름. 품질에 대한 좋은 지표를 찾지 못했습니다. C#으로 작성하기 어려울 수 있음)
xxHash64(32비트로 잘림) (이것은 확실한 속도 승자는 아니지만 이미 xxHash32가 있는 경우 쉽게 할 수 있음)
SpookyHash(더 큰 데이터 세트에서 잘 작동하는 경향이 있음)

morganbr 에 2017년 05월 31일

Add 메서드는 ref HashCode 의 반환 유형을 가질 수 없고 유창하게 사용할 수 있도록 ref this 반환합니다.

readonly ref 반환이 이를 허용합니까? /cc @jaredpar @VSadov

benaadams 에 2017년 05월 31일

경고: 누군가 인터넷 어딘가에 있는 기존 코드 기반에서 해시 구현을 선택하는 경우 소스에 대한 링크를 유지하고 라이선스를 확인하십시오(저희도 그렇게 해야 합니다).

라이센스가 호환되지 않으면 알고리즘을 처음부터 작성해야 할 수도 있습니다.

karelz 에 2017년 05월 31일

Add 메서드를 사용하는 IMO는 매우 드문 일입니다. 매우 고급 시나리오를 위한 것이며 '유창한' 능력이 필요하지 않습니다.

모든 사용자 코드 사례의 99%에 대한 일반적인 사용 사례의 경우 => HashCode.Combine(...) 사용할 수 있어야 하고 괜찮습니다.

CyrusNajmabadi 에 2017년 05월 31일

👍3

@morganbr

public static int Combine<T1>(T1 value); 도 원할 수 있습니다. 나는 그것이 약간 재미있어 보인다는 것을 알고 있지만 제한된 입력 해시 공간을 가진 무언가에서 비트를 확산시키는 방법을 제공할 것입니다

이해해. 나는 그것을 추가했다.

@justinvp

Nit: StringComparison 매개변수는 StringComparison 가 매개변수로 사용되는 다른 모든 곳에서 사용되는 이름과 일치하도록 comparisonType 로 이름을 지정해야 합니다.

결정된.

terrajobst 에 2017년 05월 31일

@CyrusNajmabadi

IMO에서 Add 방법을 사용하는 것은 극히 드문 일입니다. 매우 고급 시나리오를 위한 것이며 '유창한' 능력이 필요하지 않습니다.

동의.

terrajobst 에 2017년 05월 31일

@benaadams - 재 : 심판 반환 this 에서 Add - 아니, this 그것이를 rvalue 또는 임시 될 수 있기 때문에 구조체 방법에 심판에 의해 반환 할 수 없습니다.

```C#
참조 var r = (새로운 T()).ReturnsRefThis();

// r은 여기에서 어떤 변수를 참조합니다. 어느 것? 범위/수명이란 무엇입니까?
r = SomethingElse();
```

VSadov 에 2017년 05월 31일

비교 목적으로 유용한 경우 몇 년 전에 Jenkins lookup3 해시 함수( C 소스 )를 여기 에서 C#으로 이식했습니다.

bgrainger 에 2017년 06월 01일

👍2

컬렉션에 대해 궁금합니다.

@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%(예: 80%가 아님)에서 Combine 를 사용할 수 있는 것이라면 Combine 가 값을 기반으로 해싱 컬렉션을 지원해서는 안 됩니다. 컬렉션에서? 아마도 이를 수행하는 별도의 메서드가 있어야 합니다( HashCode 의 확장 메서드 또는 정적 메서드)?

svick 에 2017년 06월 01일

추가가 강력한 시나리오인 경우 사용자가 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에도 오버로드가 필요한지 궁금합니다.

morganbr 에 2017년 06월 02일

제안: 빌더 구조체가 IEnumerable 를 구현하여 컬렉션 이니셜라이저 구문을 지원하도록 합니다.

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

이것은 Add() 를 직접 호출하는 것보다 훨씬 더 우아하고(특히 임시 변수가 필요하지 않음) 여전히 할당이 없습니다.

자세한 내용은

SLaks 에 2017년 06월 02일

@SLaks 어쩌면 더 좋은 구문이 https://github.com/dotnet/csharplang/issues/455를 기다릴 수 있으므로(제안이 지원된다고 가정) HashCode 가 가짜 IEnumerable 을 구현할 필요가 없을 것입니다.

svick 에 2017년 06월 02일

우리는 GetHashCode()를 재정의하여 해시 코드를 생성하지 않기로 결정했습니다. 이는 명명 방식과 동작 관점 모두에서 이상할 것이기 때문입니다(GetHashCode()는 계산 대상이 아닌 객체의 해시 코드를 반환해야 함).

GetHashCode 가 계산된 해시 코드를 반환하지 않는다는 것이 이상합니다. 이것은 개발자들을 혼란스럽게 할 것이라고 생각합니다. 예를 들어 @SLaks는 이미 ToHashCode 를 사용하는 대신 제안서에서 이를 사용했습니다.

justinvp 에 2017년 06월 02일

@justinvp GetHashCode() 이 계산된 해시 코드를 반환하지 않을 경우 [Obsolete] 및 [EditorBrowsable(Never)] 합니다.

반면에 계산된 해시 코드를 반환하는 데에는 해가 되지 않습니다.

@terrajobst

우리는 해시 코드를 생성하기 위해 GetHashCode() 를 재정의하지 않기로 결정했습니다. 이는 명명 방식과 행동 관점 모두에서 이상할 것입니다( GetHashCode() 는 객체의 해시 코드를 반환해야 합니다. 계산 중).

예, GetHashCode() 는 개체의 해시 코드를 반환해야 하지만 두 해시 코드가 달라야 하는 이유가 있습니까? 의 두 인스턴스 이후 여전히 맞습니다 HashCode 같은 내부 상태가에서 같은 값을 반환합니다 GetHashCode() .

svick 에 2017년 06월 02일

@terrajobst 방금 귀하의 의견을 보았습니다. 답장이 늦어진 점을 용서해 주시고, 아무데도 가지 않는 것이 더 왔다 갔다 할 뿐이라고 생각해서 알림을 확인하는 것이 더뎠습니다. 그렇지 않아 다행입니다! :따다:

저는 이것을 선택하고 처리량/분포 측정을 수행하게 되어 기쁩니다(이것이 "이 영역에 대한 작업에 관심이 있음"을 의미한다고 가정합니다). 하지만 여기에 있는 모든 댓글을 모두 읽을 수 있도록 잠시 시간을 주세요.

jamesqo 에 2017년 06월 04일

@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 . 비교자 오버로드가 있는 것도 의미가 있습니다.

jamesqo 에 2017년 06월 04일

@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);

jamesqo 에 2017년 06월 04일

@svic

@justinvp GetHashCode()가 계산된 해시 코드를 반환하지 않을 경우 [Obsolete] 및 [EditorBrowsable(Never)]로 표시되어야 합니다.

:+1:

@terrajobst HashCode -> int 에서 ToHashCode 메서드가 없는 암시적 변환으로 돌아갈 수 있습니까? 편집: ToHashCode 괜찮습니다. 아래 @CyrusNajmabadi 의 응답을 참조하십시오.

jamesqo 에 2017년 06월 04일

@jamesqo StringComparison 는 열거형입니다.
그러나 사람들은 대신 이에 상응하는 StringComparer 를 사용할 수 있습니다.

SLaks 에 2017년 06월 04일

👍1

HashCode -> int에서 암시적 변환으로 돌아가서 ToHashCode 메서드가 없을 수 있습니까?

우리는 이에 대해 논의했고 회의에서 반대하기로 결정했습니다. 문제는 사용자가 최종 'int'를 얻을 때 추가 작업이 자주 수행된다는 것입니다. 즉, 해시코드의 내부는 종종 마무리 단계를 수행하고 자체를 새로운 상태로 재설정할 수 있습니다. 암시적 변환으로 그런 일이 발생하면 이상할 것입니다. 이 작업을 수행한 경우:

HashCode hc = ...

int i1 = hc;
int i2 = hc;

그러면 다른 결과를 얻을 수 있습니다.

그런 이유로 우리는 명시적 변환도 좋아하지 않습니다(사람들은 변환을 내부 상태를 변경하는 것으로 생각하지 않기 때문입니다).

메소드를 사용하면 이것이 발생하고 있음을 명시적으로 문서화할 수 있습니다. 우리는 잠재적으로 많은 것을 전달하기 위해 이름을 지정할 수도 있습니다. 즉, "ToHashCodeAndReset"(우리는 그것에 대해 결정했지만). 그러나 최소한 이 방법은 사용자가 Intellisense와 같은 항목에서 볼 수 있는 명확한 문서를 가질 수 있습니다. 전환의 경우는 그렇지 않습니다.

CyrusNajmabadi 에 2017년 06월 04일

typeof(T) == typeof(byte) 사용을 전문화할 수 있으므로 바이트 오버로드를 제거했습니다.

IIRC는 이것이 JIT 관점에서 옳지 않다는 것에 대한 약간의 우려가 있었습니다. 그러나 이는 값 유형이 아닌 "typeof()" 경우에만 해당되었을 수 있습니다. jit이 value-type typeof() 경우에 대해 효과적으로 올바른 일을 하는 한 그것은 좋을 것입니다.

CyrusNajmabadi 에 2017년 06월 04일

👍1

@CyrusNajmabadi int 로의 변환에 상태 변경이 포함될 수 있다는 것을 몰랐습니다. ToHashCode 그럼.

jamesqo 에 2017년 06월 04일

암호화 관점에 대해 생각하는 사람들 - http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf

blowdart 에 2017년 06월 07일

@terrajobst , 내 의견( 여기 부터 시작)을 읽고 조정된 API 모양을 승인할지 여부를 결정할 시간이 있었습니까? 그렇다면 이것이 api-approved/up for grabs로 표시될 수 있고 해시 알고리즘 결정을 시작할 수 있다고 생각합니다.

jamesqo 에 2017년 06월 07일

@blowdart , 강조하고 싶은 특정 부분이 있습니까?

위에서 그것에 대해 너무 명시적이지 않았을 수도 있지만 HashDoS 침입에 대해 내가 모르는 유일한 비암호화 해시는 Marvin과 SipHash입니다. 즉, 임의의 값으로 Murmur를 시딩(말하자면)하더라도 여전히 깨져서 DoS에 사용할

morganbr 에 2017년 06월 09일

없음, 방금 흥미롭게 보았고 이에 대한 문서는 "암호화 알고리즘을 통해 생성된 해시 코드에는 사용하지 않음"이라고 나와 있어야 한다고 생각합니다.

blowdart 에 2017년 06월 09일

결정

시나리오가 불분명하기 때문에 모든 AddRange 메소드를 제거해야 합니다. 배열은 매우 자주 나타날 가능성이 다소 낮습니다. 그리고 일단 더 큰 배열이 관련되면 문제는 계산을 캐시해야 하는지 여부입니다. 호출 측에서 for 루프를 보면 그것에 대해 생각할 필요가 있음을 분명히 알 수 있습니다.
또한 할당될 것이기 때문에 IEnumerable 오버로드를 AddRange 에 추가하고 싶지 않습니다.
string 와 StringComparison 가 걸리는 string Add 대한 오버로드가 필요하지 않다고 생각합니다. 예, IEqualityComparer 통해 호출하는 것보다 더 효율적일 수 있지만 나중에 수정할 수 있습니다.
GetHashCode 를 오류와 함께 사용되지 않는 것으로 표시하는 것은 좋은 생각이지만 한 단계 더 나아가 IntelliSense에서 숨길 수도 있습니다.

이것은 우리에게 다음을 남깁니다.

    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();
}

}
```

terrajobst 에 2017년 06월 13일

🎉7 ❤4 👍2

다음 단계: 문제는 해결 해야 합니다. 여러 후보 알고리즘 을 실험으로 사용 https://github.com/dotnet/corefx/issues/14354#issuecomment -305028686 목록을 참조

복잡성: 큼

누군가 그것을 데리러 관심이 있다면, 저희에게 ping을 보내주십시오. 여러 사람이 함께 작업할 수 있는 공간도 있을 수 있습니다. ( @jamesqo 당신은 이슈에 가장 많은 시간을 투자한 만큼 우선순위가 있습니다.)

karelz 에 2017년 06월 13일

@karelz 위의 의견에도 불구하고 최고의 해시 알고리즘을 선택할 자격이 없다고 생각하기 때문에 마음이 바뀌었습니다. @morganbr이 나열된 라이브러리 중 일부를 살펴보고 구현이 매우 복잡 하다는 것을 깨달았습니다. 그래서 직접 테스트하기 위해 이를 C#으로 쉽게 변환할 수 없습니다. 저는 C++에 대한 배경 지식이 거의 없기 때문에 라이브러리를 설치하고 테스트 앱을 작성하는 것만으로도 어려움을 겪을 것입니다.

그러나 이것이 최신 목록에 영원히 남아 있기를 원하지 않습니다. 오늘부터 일주일 동안 아무도 해결하지 않으면 Programmers SE 또는 Reddit에 질문을 게시하는 것을 고려할 것입니다.

jamesqo 에 2017년 06월 16일

👍1

나는 그것을 벤치마킹하지 않았지만 (또는 다른 방식으로 그것을 최적화하지는 않았지만) 다음은 여러 개인 프로젝트에서 사용하는 Murmur3 해시 알고리즘의 기본 구현입니다. https://gist.github.com/tannergooding/0a12559d1a912068b9aeb4b9586aad7f

tannergooding 에 2017년 06월 16일

여기에서 가장 최적의 솔루션은 입력 데이터의 크기에 따라 해싱 알고리즘을 동적으로 변경하는 것입니다.

예: Mumur3(및 기타)는 대규모 데이터 집합에 대해 매우 빠르고 훌륭한 분포를 제공하지만 더 작은 데이터 집합에 대해서는 '저조한'(배포 방식이 아니라 속도 측면에서) 수행할 수 있습니다.

다음과 같이 해야 한다고 생각합니다. 전체 바이트 수가 X보다 작으면 알고리즘 A를 수행합니다. 그렇지 않으면 알고리즘 B를 수행하십시오. 이것은 여전히 결정론적이지만(실행당) 입력 데이터의 실제 크기를 기반으로 속도와 분포를 제공할 수 있습니다.

tannergooding 에 2017년 06월 16일

언급된 알고리즘 중 일부는 SIMD 명령어를 위해 특별히 설계된 구현을 가지고 있으므로 가장 성능이 좋은 솔루션은 일부 수준에서 FCALL을 포함할 가능성이 높거나(예: 일부 BufferCopy 구현에서 수행됨) 종속성을 취하는 것을 포함할 수 있습니다. System.Numerics.Vector

tannergooding 에 2017년 06월 16일

@jamesqo , 선택에 도움을 드리겠습니다. 가장 도움이 필요한 것은 후보 구현을 위한 성능 데이터입니다( @tannergooding이 지적했듯이 일부 알고리즘에는 특별한 컴파일러 지원이 필요하지만 이상적으로는 C#). 위에서 언급했듯이 선택되지 않은 후보자를 빌드하면 나중에 사용할 수 있으므로 작업이 낭비되는 것에 대해 걱정하지 마십시오.

다양한 구현을 위한 벤치마크가 있다는 것을 알고 있지만 이 API와 가능한 입력 범위(예: 1-10 필드가 있는 구조체)를 사용하여 비교하는 것이 중요하다고 생각합니다.

morganbr 에 2017년 06월 17일

@tannergooding , 그런 종류의 적응성이 가장 성능이 좋을 수 있지만 얼마나 많이 호출될지 모르기 때문에 Add 메서드와 함께 작동하는지 알 수 없습니다. Combine으로 할 수 있지만, 이는 일련의 Add 호출이 해당 Combine 호출과 다른 결과를 생성할 수 있음을 의미합니다.

또한 가장 가능성이 높은 입력 범위가 4-32바이트( Combine`1 - Combine`8 )인 경우 해당 범위에서 큰 성능 변화가 없기를 바랍니다.

morganbr 에 2017년 06월 17일

그런 종류의 적응성이 가장 성능이 좋을 수 있지만 얼마나 많이 호출될지 모르기 때문에 Add 메서드와 함께 작동하는 방법을 알 수 없습니다.

나는 개인적으로 API 모양이 범용 해싱에 매우 적합하다고 확신하지 않습니다(그러나 가깝습니다)...

현재 우리는 정적 생성을 위한 Combine 메소드를 공개하고 있습니다. 이것이 모든 입력을 결합하고 최종 해시 코드를 생성하기 위한 것이라면 이름은 'poor'이고 Compute 와 같은 것이 더 적절할 수 있습니다.

Combine 메소드를 노출하는 경우 모든 입력을 혼합해야 하며 사용자는 Finalize 메소드를 호출해야 합니다. 이 메소드는 마지막 결합의 출력과 총 바이트 수를 취해야 합니다. 결합하여 최종 해시 코드를 생성합니다(해시 코드를 완성하는 것은 비트를 눈사태로 만드는 원인이 되기 때문에 중요합니다).

빌더 패턴의 경우 Add 및 ToHashCode 메서드를 노출합니다. Add 메서드가 바이트를 저장하고 ToHashCode 에 대한 호출에서만 결합/종료하기 위한 것인지(이 경우 올바른 알고리즘을 동적으로 선택할 수 있음) 즉석에서 결합해야 하는 경우에는 이러한 경우가 분명해야 합니다(그리고 구현은 결합된 바이트의 총 크기를 내부적으로 추적해야 함).

tannergooding 에 2017년 06월 17일

덜 복잡한 시작점을 찾는 사람은 xxHash32를 사용해 보십시오. 그것은 C#으로 꽤 쉽게 번역될 것입니다( 사람들이 해냈습니다 ).

morganbr 에 2017년 06월 17일

여전히 로컬에서 테스트하고 있지만 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개의 하위 반복을 실행하고 다음 반복의 첫 번째 입력 값으로 이전 하위 반복의 결과를 전달합니다.

그런 다음 평균 경과 시간을 얻기 위해 모든 반복의 평균을 구하고, 이를 루프당 실행되는 하위 반복 수로 더 나누어 호출당 평균 시간을 구합니다. 그런 다음 초당 수행할 수 있는 호출 수를 계산하고 여기에 실제 처리량을 계산하기 위해 결합된 바이트 수를 곱합니다.

코드를 정리하고 잠시 후에 공유합니다.

tannergooding 에 2017년 06월 17일

@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

두 경우 모두 데이터는 동일한 내부 해시 상태로 공급되어야 하며 해시는 마지막에 한 번 종료되어야 합니다.

morganbr 에 2017년 06월 17일

👍

그것이 내가 작성한 코드가 하는 일입니다. 유일한 차이점은 모든 코드를 효과적으로 인라인한다는 것입니다( new HashCode() 를 할당하고 상수이기 때문에 결합된 바이트 수를 추적할 필요가 없습니다).

tannergooding 에 2017년 06월 17일

@morganbr. Murmur3에 대한 구현 + 처리량 테스트: https://gist.github.com/tannergooding/89bd72f05ab772bfe5ad3a03d6493650

tannergooding 에 2017년 06월 17일

MurmurHash3는 여기에 설명된 알고리즘을 기반으로 합니다. https://github.com/aappleby/smhasher/wiki/MurmurHash3 , repo는 MIT라고 말합니다.

xxHash32(BSD-2 조항 -- https://github.com/Cyan4973/xxHash/blob/dev/xxhash.c) 및 SpookyHash(공개 도메인 -- http://www.burtleburtle.net/bob/hash) 작업 /spooky.html) 변형

tannergooding 에 2017년 06월 17일

@tannergooding 다시 말하지만, 해시 전문가는 아니지만 Murmur가 DoS에 저항하지 않는다고 말한 [기사 읽기][1]를 기억하므로 선택하기 전에 이를 지적했습니다.

jamesqo 에 2017년 06월 17일

@jamesqo , 내가 틀릴 수도 있지만 Murmur3이 아닌 Murmur2에 취약점이 적용되었다고 확신합니다.

두 경우 모두 C#에 대한 처리량 결과를 얻을 수 있도록 여러 알고리즘을 구현하고 있습니다. 이러한 알고리즘의 분포 및 기타 속성은 상당히 잘 알려져 있으므로 나중에 어떤 것이 가장 좋은지 고를 수 있습니다 😄

tannergooding 에 2017년 06월 17일

이런, 기사 링크를 잊었습니다: http://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/.

@tannergooding 알겠습니다. 공정한 소리 :+1:

jamesqo 에 2017년 06월 17일

@tannergooding , Murmur3 구현을 살펴보았는데 일반적으로 옳고 최적화된 것 같습니다. 내가 올바르게 이해했는지 확인하기 위해 CombinedValue와 Murmur의 내부 상태가 모두 32비트라는 사실을 사용하고 있습니까? 이것은 아마도 이 경우에 대해 꽤 좋은 최적화일 것이며 내가 이전에 혼동했던 일부를 설명합니다.

우리가 그것을 채택하려면 몇 가지 조정이 필요할 수 있습니다 (아마도 성능 측정에 큰 차이는 없을 것입니다).

결합하다여전히 value1에서 CombineValue를 호출해야 합니다.
첫 번째 CombineValue 호출은 임의의 시드를 가져와야 합니다.
ToHashCode는 _bytesCombined 및 _combinedValue를 재설정해야 합니다.

morganbr 에 2017년 06월 21일

그동안 내가 이 API를 갈망하면서 (field1, field2, field3).GetHashCode() 를 통해 GetHashCode를 구현하는 것이 얼마나 나빴습니까?

jnm2 에 2017년 06월 29일

@jnm2 , ValueTuple 해시 코드 결합기는 해시 코드에서 입력을 순서대로 입력하는 경향이 있습니다(가장 최근에 나온 것은 버립니다). 소수로 나누는 몇 개의 필드와 해시 테이블의 경우 눈치채지 못할 수도 있습니다. 많은 필드 또는 2의 거듭제곱으로 나누는 해시 테이블의 경우 삽입한 마지막 필드의 엔트로피가 충돌 여부에 가장 큰 영향을 미칩니다(예: 마지막 필드가 bool 또는 작은 int인 경우 guid라면 아마도 충돌이 많이 일어날 것입니다.

morganbr 에 2017년 06월 29일

ValueTuple은 모두 0인 필드에서도 잘 작동하지 않습니다.

tannergooding 에 2017년 06월 29일

👍1

참고로 저는 다른 구현 작업을 중단해야 했습니다(우선 순위가 더 높은 작업이 있음). 언제 다시 가져올 수 있을지 미지수입니다.

tannergooding 에 2017년 06월 29일

따라서 구조화된 유형에 대해 충분하지 않은 경우 튜플에 대해 충분한 이유는 무엇입니까?

jnm2 에 2017년 06월 29일

@jnm2 , 이것이 이 기능이 구축할 가치가 있는 한 가지 이유입니다. 따라서 프레임워크 전체에서 표준 이하의 해시를 교체할 수 있습니다.

morganbr 에 2017년 06월 30일

👍1

성능 및 품질 특성이 있는 대규모 해시 함수 테이블:
https://github.com/leo-yuriev/t1ha

mariuszkochanowski 에 2017년 07월 31일

@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 에 2017년 08월 01일

@jamesqo , 내 접시에 몇 가지 더 높은 우선 순위가 있으며 앞으로 3주 이내에 이 작업을 수행할 수 없습니다.

tannergooding 에 2017년 08월 01일

또한 현재 측정값은 현재 C#에서 코딩할 수 있는 항목으로 제한되지만, 이것이 실제로 적용되는 경우(https://github.com/dotnet/designs/issues/13), 측정값이 다소 변경될 수 있습니다. ;)

tannergooding 에 2017년 08월 01일

또한 현재 측정값은 현재 C#에서 코딩할 수 있는 항목에 따라 제한됩니다. 그러나 이것이 일이 되면(dotnet/designs#13) 측정값이 다소 변경될 수 있습니다.)

괜찮습니다. 내장 함수를 사용할 수 있게 되면 해시 알고리즘을 항상 변경할 수 있습니다. 해시 코드를 캡슐화/무작위화하면 그렇게 할 수 있습니다. 우리는 현재 상태에서 런타임에 대해 최고의 성능/배포 트레이드오프를 제공하는 것을 찾고 있습니다.

jamesqo 에 2017년 08월 01일

👍1

@jamesqo , 도와줄 사람들을 찾아주셔서 감사합니다. 해시 전문가가 아닌 사람도 이 작업을 하게 되어 기쁩니다. 다른 언어나 디자인에서 일부 알고리즘을 C#으로 이식한 다음 성능 측정을 수행할 수 있는 사람이 정말 필요합니다. 후보를 선택하면 전문가가 변경 사항에 대해 수행할 것입니다. 코드의 정확성, 성능, 보안 등을 검토합니다.

morganbr 에 2017년 08월 02일

안녕하세요! 나는 방금 토론을 읽었고 적어도 나에게는 murmur3-32 PoC에 찬성하여 사건이 강력하게 종결된 것 같습니다. 어떤 BTW가 나에게 매우 좋은 선택으로 보이며 더 이상 불필요한 작업을 지출하지 않는 것이 좋습니다(하지만 .Add() 회원을 삭제할 수도 있습니다...).

그러나 누군가가 더 많은 성능 작업을 계속하기를 원하는 경우에는 xx32, xx64, hsip13/24, seahash, murmur3-x86/32에 대한 일부 코드를 제공할 수 있습니다. 최적화되지 않음) sip13/24, spookyv2. City의 일부 버전은 필요할 경우 이식하기에 충분히 쉬워 보입니다. 그 반쯤 버려진 프로젝트는 약간 다른 사용 사례를 염두에 두었기 때문에 제안된 API에는 HashCode 클래스가 없습니다. 그러나 벤치마킹을 위해서는 그다지 중요하지 않습니다.

Definitly하지 생산 준비 : 코드를 복사 파스타, 공격적인 인라인 및 안전의 암 스프롤과 같은 무차별의 관대 한 금액을 적용; 엔디안은 존재하지 않으며 정렬되지 않은 읽기도 없습니다. ref-impl 테스트 벡터에 대한 테스트조차도 완곡하게 "불완전"합니다.

이것이 조금이라도 도움이 된다면 앞으로 2주 동안 가장 심각한 문제를 수정하고 코드와 일부 예비 결과를 사용할 수 있는 충분한 시간을 확보해야 합니다.

gimpf 에 2017년 08월 15일

👍1

@김프

나는 방금 토론을 읽었고 적어도 나에게는 murmur3-32 PoC에 찬성하여 사건이 강력하게 종결된 것 같습니다. 어떤 BTW가 나에게 매우 좋은 선택으로 보이며 더 이상 불필요한 작업을 지출하지 않는 것이 좋습니다.

아니요, 사람들은 아직 Murmur3를 선호하지 않습니다. 우리는 성능/배포 간의 균형 측면에서 절대적으로 최고의 알고리즘을 선택하고 있는지 확인하고 싶습니다.

그러나 누군가가 더 많은 성능 작업을 계속하기를 원하는 경우에는 xx32, xx64, hsip13/24, seahash, murmur3-x86/32에 대한 일부 코드를 제공할 수 있습니다. 최적화되지 않음) sip13/24, spookyv2. City의 일부 버전은 필요할 경우 이식하기에 충분히 쉬워 보입니다.

예, 부탁합니다! 우리는 테스트할 가능한 많은 알고리즘에 대한 코드를 수집하고자 합니다. 당신이 기여할 수 있는 모든 새로운 알고리즘은 가치가 있습니다. City 알고리즘도 이식할 수 있다면 대단히 감사하겠습니다.

확실히 프로덕션 준비가 되지 않았습니다. 코드는 복사 파스타, 공격적인 인라인 및 안전하지 않은 암의 확산과 같은 엄청난 양의 무차별 대입을 적용합니다. 엔디안은 존재하지 않으며 정렬되지 않은 읽기도 없습니다. ref-impl 테스트 벡터에 대한 테스트조차도 완곡하게 "불완전"합니다.

괜찮아. 코드를 가져오기만 하면 필요한 경우 다른 사람이 찾을 수 있습니다.

이것이 조금이라도 도움이 된다면 앞으로 2주 동안 가장 심각한 문제를 수정하고 코드와 일부 예비 결과를 사용할 수 있는 충분한 시간을 확보해야 합니다.

그래 그게 좋겠다!

jamesqo 에 2017년 08월 15일

@jamesqo 알겠습니다 . 보여드릴 것이 있으면 메모해

gimpf 에 2017년 08월 15일

👍1

@gimpf 정말 훌륭하게 들리고 진행 상황에 대해 듣고 싶습니다(모든 알고리즘을 완료할 때까지 기다릴 필요가 없습니다!). 코드가 올바른 결과를 생성하고 성능이 프로덕션 준비 구현에서 볼 수 있는 것을 잘 표현한다고 믿는 한 프로덕션 준비가 되지 않아도 괜찮습니다. 후보자를 선택하면 고품질 구현을 위해 귀하와 협력할 수 있습니다.

seahash의 엔트로피가 다른 알고리즘과 어떻게 비교되는지에 대한 분석을 본 적이 없습니다. 그것에 대한 포인터가 있습니까? 흥미로운 성능 절충안이 있습니다... 벡터화는 빠르게 들리지만 모듈식 산술은 느리게 들립니다.

morganbr 에 2017년 08월 16일

@morganbr 티저 준비했습니다.

SeaHash 소개 : 아니요, 품질에 대해서는 아직 모릅니다. 성능이 흥미로운 경우 SMHasher에 추가합니다. 적어도 저자는 그것이 좋다고 주장하고(파일 시스템의 체크섬에 사용), 또한 믹싱 중에 엔트로피가 버려지지 않는다고 주장합니다.

해시 및 벤치마크 정보 : 프로젝트 Haschisch.Kastriert , xx32, xx64, hsip13, hsip24, marvin32, sea 및 murmur3-32를 비교 한 첫 번째 벤치마킹 결과가 있는 위키 페이지.

몇 가지 중요한 주의 사항:

이것은 낮은 정확도 설정으로 매우 빠른 벤치 런이었습니다.
구현이 아직 완료되지 않았으며 일부 경쟁자가 여전히 누락되었습니다. 스트리밍 구현(이와 같은 것은 합리적인 .Add() 지원에 필요함)은 실제 최적화가 필요합니다.
SeaHash는 현재 시드를 사용하지 않습니다.

첫인상:

대용량 메시지의 경우 xx64가 나열된 구현 중 가장 빠릅니다(내가 이해하는 한 주기당 약 3.25바이트 또는 노트북의 경우 9.5GiB/s)
짧은 메시지의 경우 아무 것도 훌륭하지 않지만 murmur3-32 및 (놀랍게도) seahash가 유리하지만 후자는 아직 씨를 사용하지 않는 seahash로 설명될 가능성이 높습니다.
HashSet<> 에 액세스하기 위한 "벤치마크"는 작업이 필요합니다. 모든 것이 거의 측정 오류 내에 있기 때문입니다(더 큰 차이를 보았지만 여전히 이야기할 가치가 없음)
해시 코드를 결합할 때 murmur-3A PoC는 여기에 있는 것보다 약 5~20배 빠릅니다.
C#의 일부 추상화는 매우 비쌉니다. 이는 해시 알고리즘을 비교하는 것을 필요 이상으로 성가시게 만듭니다.

상황이 조금 나아지면 다시 글을 쓰겠습니다.

gimpf 에 2017년 08월 20일

@gimpf , 환상적인 시작입니다! 코드와 결과를 살펴보고 몇 가지 질문이 있습니다.

결과는 SimpleMultiplyAdd가 @tannergooding 의 Murmur3a보다 약 5배 느린 것으로 표시됩니다. Murmur가 곱하기+더하기보다 해야 할 일이 더 많기 때문에 이상해 보입니다(물론 회전이 더하기보다 더 빠른 작업이라는 점은 인정하겠습니다). 귀하의 구현에 Murmur 구현에 없는 일반적인 비효율성이 있을 수 있습니까? 아니면 이것을 범용 구현보다 큰 이점이 있는 사용자 정의 구현으로 읽어야 합니까?
1, 2, 4 조합에 대한 결과가 있으면 좋지만 이 API는 최대 8까지 올라갑니다. 그 결과도 얻을 수 있습니까? 아니면 중복이 너무 많이 발생합니까?
나는 당신이 X64에서 실행하는 것을 보았으므로 이 결과는 우리의 X64 알고리즘을 선택하는 데 도움이 될 것이지만 다른 벤치마크에서는 알고리즘이 X86과 X64 사이에서 상당히 다를 수 있음을 시사합니다. X86 결과도 쉽게 얻을 수 있습니까? (언젠가는 ARM과 ARM64도 필요하겠지만, 확실히 기다릴 수 있습니다)

HashSet 결과는 특히 흥미롭습니다. 그들이 유지한다면 더 빠른 해시 시간보다 더 나은 엔트로피를 선호하는 가능한 경우입니다.

morganbr 에 2017년 08월 22일

@morganbr 이번 주말은 더 많이

귀하의 질문에 대해:

결과는 SimpleMultiplyAdd가 @tannergooding 의 Murmur3a보다 약 5배 느린 것으로 표시됩니다. 이상해 보이는데...

나는 나 자신이 궁금했다. 그것은 복사/붙여넣기 오류였습니다. SimpleMultiplyAdd는 항상 4개의 값을 결합했습니다... 또한 일부 명령문을 재정렬함으로써 곱하기-더하기 결합기가 약간 더 빨라졌습니다(~60% 더 높은 처리량).

귀하의 구현에 Murmur 구현에 없는 일반적인 비효율성이 있을 수 있습니까? 아니면 이것을 범용 구현보다 큰 이점이 있는 사용자 정의 구현으로 읽어야 합니까?

몇 가지를 놓칠 수 있지만 .NET의 경우 이 사용 사례에는 범용 구현을 사용할 수 없는 것 같습니다. 나는 모든 알고리즘에 대해 Combine 스타일 메소드를 작성했으며 대부분의 wrt 해시 코드 결합이 범용 메소드보다 _훨씬_ 더 잘 수행됩니다.

그러나 이러한 구현조차도 여전히 너무 느립니다. 추가 작업이 필요합니다. 이 영역의 .NET 성능은 나에게 절대적으로 불투명합니다. 로컬 변수의 복사본을 추가하거나 제거하면 성능이 2배 정도 쉽게 변경될 수 있습니다. 최상의 옵션을 선택하기 위해 충분히 잘 최적화된 구현을 제공할 수 없을 것입니다.

1, 2, 4 조합에 대한 결과가 있으면 좋지만 이 API는 8까지 올라갑니다.

결합 벤치마크를 확장했습니다. 그 전면에 놀라움이 없습니다.

X64(...)에서 실행한 것을 보았는데, X86 결과도 쉽게 얻을 수 있나요?

예전에는 그랬지만 .NET Standard로 이식했습니다. 이제 저는 종속성 지옥에 있으며 .NET Core 2 및 CLR 64비트 벤치마크만 작동합니다. 이것은 현재 문제를 해결하면 충분히 쉽게 해결할 수 있습니다.

gimpf 에 2017년 08월 28일

👍1

이것이 v2.1 릴리스에서 가능하다고 생각하십니까?

shaggygi 에 2017년 09월 14일

👍1

@gimpf 한동안 게시물을 올리지 않으셨습니다. 구현에 대한 진행 상황 업데이트가 있습니까? : 스마일 :

jamesqo 에 2017년 09월 14일

@jamesqo 이상한 결과를 초래하는 벤치마크를 수정하고 사용 가능한 알고리즘 목록에 City32, SpookyV2, Sip13 및 Sip24를 추가했습니다. Sip은 예상대로 빠르며(xx64의 처리량에 비해) City와 Spooky는 그렇지 않습니다(SeaHash의 경우에도 동일).

해시 코드를 결합하는 경우 Murmur3-32가 여전히 좋은 선택처럼 보이지만 아직 더 철저한 비교를 실행하지 못했습니다.

또 다른 참고 사항으로 스트리밍 API(.Add())는 후보 목록에서 일부 해시 알고리즘을 제거하는 불행한 부작용이 있습니다. 그러한 API의 성능도 의심스럽다는 점을 감안할 때 처음부터 제공할지 여부를 다시 생각해보는 것이 좋습니다.

.Add() 부분을 피하고 해시 결합기가 시드를 사용하는 경우 tg의 결합기를 정리하고 작은 테스트 스위트를 생성하고 을 그만하기로하다. 주말마다 몇 시간 밖에 안 하고 성능 최적화가 다소 지루하기 때문에 금도금 버전을 만드는 것은 약간 지루할 수 있습니다 ...

gimpf 에 2017년 09월 14일

@gimpf , 대단한 진전처럼 들립니다. 결정을 내리고 앞으로 나아갈 만큼 충분한지 확인할 수 있도록 결과 테이블이 있습니까?

morganbr 에 2017년 09월 14일

@morganbr 벤치마킹 결과를 업데이트했습니다.

지금은 .NET Core 2에서 64비트 결과만 얻었습니다. 해당 플랫폼의 경우 City64 w/o seed가 모든 크기에서 가장 빠릅니다. 종자를 통합하여 XX-32는 Murmur-3-32와 연결됩니다. 운 좋게도 이것들은 32비트 플랫폼에서 빠른 것으로 평판이 좋은 동일한 알고리즘이지만 분명히 우리는 그것이 제 구현에도 적용되는지 확인해야 합니다. Sea와 SpookyV2가 비정상적으로 느린 것을 제외하고 결과는 실제 성능을 나타내는 것 같습니다.

해시 코드 결합기에 대한 해시 도스 보호가 얼마나 필요한지 고려해야 합니다. 시드가 해시를 지속성을 위해 분명히 사용할 수 없도록 만드는 데만 필요한 경우 32비트 시드로 XOR하면 city64가 개선될 것입니다. 이 유틸리티는 해시를 결합하기 위해서만 존재하므로(예를 들어 문자열의 해시 코드를 대체하거나 정수 배열 등의 드롭인 해시가 되지 않음) 충분할 수 있습니다.

OTOH가 필요하다고 생각한다면 Sip13이 일반적으로 XX-32(64비트 플랫폼에서)보다 50% 미만 느리다는 것을 알게 되어 기쁩니다. 그러나 그 결과는 32비트 앱에서 크게 다를 수 있습니다.

gimpf 에 2017년 09월 18일

👍2 🎉1

corefx와 얼마나 관련이 있는지 모르지만 LegacyJit 32비트(w/FW 4.7) 결과를 추가했습니다.

결과가 터무니없이 느리다고 말하고 싶습니다. 그러나 예를 들어, 56 MiB/s 대 319 MiB/s에서 나는 웃지 않습니다(즉, Sip, 왼쪽 회전 최적화가 가장 누락됨). 1월에 .NET 해시 알고리즘 프로젝트를 취소한 이유를 기억합니다...

따라서 RyuJit-32bit는 여전히 누락되었으며 (바라건대) 매우 다른 결과를 제공할 것이지만 LegacyJit-x86의 경우 Murmur-3-32가 쉽게 승리하고 City-32와 xx-32만 근접할 수 있습니다. Murmur는 여전히 0.6~2GB/s가 아닌 약 0.4~1.1GB/s로 성능이 좋지 않지만(동일한 시스템에서), 적어도 적절한 수준에 있습니다.

gimpf 에 2017년 09월 19일

오늘 밤 몇 대의 제품에 대해 벤치마크를 실행하고 결과를 게시할 예정입니다(Ryzen, i7, Xeon, A10, i7 Mobile 및 기타 몇 가지).

tannergooding 에 2017년 09월 19일

👍1

@tannergooding @morganbr 몇 가지 훌륭하고 중요한 업데이트입니다.

중요한 첫 번째:

잘못된 해시 값을 생성하는 일부 결합 구현을 수정했습니다.
이제 벤치마크 제품군은 지속적인 접기를 피하기 위해 더 열심히 작동합니다. City64는 취약했습니다(과거의 murmur-3-32처럼). 내가 지금 모든 결과를 이해한다는 의미는 아니지만 훨씬 더 그럴듯합니다.

좋은 것들:

결합기 구현은 이제 xx/city에 대한 다소 번거로운 수동 언롤 구현을 포함하여 모든 1-8 인수 오버로드에 사용할 수 있습니다.
테스트와 벤치마크도 이를 확인합니다. 많은 해시 알고리즘에는 특수한 경우의 로우 바이트 메시지가 있기 때문에 이러한 측정이 중요할 수 있습니다.
여러 대상에 대한 실행 벤치마크를 간소화했습니다(Core vs. 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을 사용하여 작동해야 합니다.

결과 : 모든 버그 수정 후 "빠른" 실행에서 모바일 Haswell i7의 Windows 10에서 xx32가 64비트 RyuJIT를 포함하는 모든 오버로드에 대해 승리한 것 같습니다. Sips와 marvin32 사이에서 Sip-1-3이 항상 이깁니다. Sip-1-3은 xx32보다 약 4배 느리며, 이는 다시 기본 곱셈-덧셈 결합기보다 약 2배 느립니다. 32비트 코어 결과는 여전히 누락되었지만 해당 문제를 해결해 줄 안정적인 BenchmarkDotNet 릴리스를 어느 정도 기다리고 있습니다.

(편집) 방금 해시 세트에 액세스하기 위한 벤치마크 의 빠른 실행을 추가했습니다. 이것은 분명히 위의 µ-벤치마크보다 세부 사항에 훨씬 더 의존하지만 한 번 살펴보고 싶을 수도 있습니다.

gimpf 에 2017년 09월 25일

환상적인 데이터에 대해 @gimpf 에게 다시 한 번 감사드립니다! 우리가 그것을 결정으로 바꿀 수 있는지 봅시다.

우선 알고리즘을 다음과 같이 나눕니다.
Fast+Good 엔트로피(속도순):

xxHash32
City64(x86에서는 느릴 수 있으므로 x86에서는 다른 것을 선택해야 할 것입니다.)
머머3A

HashDoS 내성:

마빈32
십해시. 이 쪽으로 기울면 연구 결과가 수용 가능한지 확인하기 위해 Microsoft의 암호화 전문가에게 검토를 받아야 합니다. 우리는 또한 어떤 매개변수가 충분히 안전한지 알아내야 합니다. 논문 은 Sip-2-4와 Sip-4-8 사이의 어딘가를 제안합니다.

경합 없음(느림):

으스스한 V2
시티32
xxHash64
*SeaHash(엔트로피에 대한 데이터가 없음)

경합 없음(나쁜 엔트로피):

곱하기 더하기
HSip

우승자를 선택하기 전에 다른 사람들이 위의 버킷에 동의하는지 확인하고 싶습니다. 그것이 유지된다면 우리는 HashDoS 저항에 대해 2배를 지불할지 여부를 선택한 다음 속도에 따라 가야한다고 생각합니다.

morganbr 에 2017년 09월 28일

👍1

@morganbr 그룹화가 잘 된 것 같습니다. SipHash 라운드의 데이터 포인트로서 Rust 프로젝트는 sip-hash w/DJB를 작성한 Jean-Philippe Aumasson 에게 질문했습니다. 그 논의 후에 그들은 해시 테이블에 대해 sip-1-3을 사용하기로 결정했습니다.

( PR rust:#33940 및 함께 제공되는 문제 rust:#29754 참조 ).

gimpf 에 2017년 09월 28일

데이터와 의견을 바탕으로 모든 아키텍처에서 xxHash32 를 사용할 것을 제안하고 싶습니다. 다음 단계는 구현하는 것입니다. @gimpf , 이에 대한 PR을 구성하는 데 관심이 있습니까?

HashDoS에 대해 우려하는 분들을 위해 Marvin32를 포함해야 하고 SipHash를 포함할 수 있는 범용 해싱 API에 대한 제안을 곧 이어갈 것입니다. 그것은 또한 @gimpf 와 @tannergooding 이 작업한 다른 구현을 위한 적절한 장소가 될 것입니다.

morganbr 에 2017년 10월 04일

@morganbr 시간이 허락하는 한 PR을 할 수 있습니다. 또한 개인적으로 xx32도 수용을 줄이지 않는 한 선호합니다.

gimpf 에 2017년 10월 06일

@gimpf , 시간이 어떻게

morganbr 에 2017년 10월 20일

@morganbr 11월 5일까지 하기로 계획했는데 앞으로 2주 안에 시간을 찾을 수 있어 여전히 좋아 보입니다.

gimpf 에 2017년 10월 20일

@gimpf , 잘 들립니다. 업데이트해주셔서 감사합니다!

morganbr 에 2017년 10월 21일

@terrajobst - 파티에 좀 늦었지만(죄송합니다.) Add 메서드의 반환 유형을 변경할 수 없나요?

```c#
공개 해시코드 추가(T 값);
공개 해시코드 추가(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();

그러나 하나의 덜 낭비적인 배열 할당에도 불구하고 다음과 같이 정확히 동일한 결과를 얻을 수 있습니다.

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

유형을 혼합할 수도 있습니다. 이것은 분명히 일반 메서드 내에서 유창하게 호출 하지 않음 으로써 수행될 수 있습니다. 유창한 인터페이스가 절대적으로 필요하지 않다는 이 주장을 감안할 때 처음에는 낭비적인 params 오버로드가 존재하는 이유는 무엇입니까? 이 제안이 잘못된 제안이라면 params 오버로드는 동일한 축으로 떨어집니다. 그리고 사소하지만 최적의 해시코드에 대한 정규적인 방법을 강요하는 것은 많은 의식처럼 보입니다.

편집: implicit operator int 는 DRY에도 좋지만 정확히 중요하지는 않습니다.

jcdickinson 에 2017년 10월 31일

@jcdickinson

Add 메서드의 반환 유형을 변경할 수 없습니까?

우리는 이미 이전 제안에서 논의했지만 거부되었습니다.

낭비적인 params 과부하가 처음에 존재하는 이유는 무엇입니까?

params 오버로드를 추가하지 않습니까? 이 웹 페이지에서 "params"에 대해 Ctrl+F를 수행하면 해당 단어가 표시되는 유일한 위치에 귀하의 댓글이 있음을 알 수 있습니다.

암시적 연산자 int도 DRY에 적합하지만 정확히 중요하지는 않습니다.

위의 어딘가에서 논의 된 것 같습니다 ...

jamesqo 에 2017년 10월 31일

@jamesqo 설명 감사합니다.

매개변수 오버로드

나는 AddRange 의미했지만, 나는 이것에 대해 어떤 견인력도 없을 것이라고 생각합니다.

jcdickinson 에 2017년 10월 31일

@jcdickinson AddRange 은 원래 제안서에 있었지만 현재 버전에는 없습니다. API 검토에서 거부되었습니다(@terrajobst의 https://github.com/dotnet/corefx/issues/14354#issuecomment-308190321 참조).

시나리오가 불분명하기 때문에 모든 AddRange 메소드를 제거해야 합니다. 배열은 매우 자주 표시될 가능성이 다소 낮습니다. 그리고 일단 더 큰 배열이 관련되면 문제는 계산을 캐시해야 하는지 여부입니다. 호출 측에서 for 루프를 보면 그것에 대해 생각할 필요가 있음을 분명히 알 수 있습니다.

svick 에 2017년 10월 31일

@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회 호출과 유창한 확장 방법:

| 방법 | 평균 | 오류 | 표준 개발 | 스케일 |
|--------- |---------:|---------:|---------:|---------: |
| 추가 | 401.6ns | 1.262ns | 1.180ns | 1.00 |
| 탈리 | 747.8ns | 2.329ns | 2.178ns | 1.86 |

그러나 다음 패턴이 작동합니다.

```c#
공개 구조체 HashCode : System.Collections.IEnumerable
{
[EditorBrowsable(EditorBrowsableState.Never)]
[Obsolete("이 메서드는 컬렉션 이니셜라이저 구문에 제공됩니다.", 오류: true)]
public IEnumerator GetEnumerator() => 새로운 NotImplementedException() 던지기;
}

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

```

또한 현재 제안과 동일한 성능 특성을 가지고 있습니다.

| 방법 | 평균 | 오류 | 표준 개발 | 스케일 |
|------------ |---------:|---------:|---------:|--- ----:|
| 추가 | 405.0ns | 2.130ns | 1.889ns | 1.00 |
| 초기화 | 400.8ns | 4.821ns | 4.274ns | 0.99 |

슬프게도 IEnumerable 는 컴파일러를 만족스럽게 유지하기 위해 구현되어야 하기 때문에 다소 해킹입니다. 즉, Obsolete 는 foreach 에서도 오류가 발생합니다. 예외가 발생하려면 실제로 문제를 해결해야 합니다. 둘의 MSIL은 본질적으로 동일합니다.

jcdickinson 에 2017년 10월 31일

👍2

@jcdickinson 문제를 잡아주셔서 감사합니다. Collaborator 초대를 보냈습니다. 수락할 때 알려주십시오. 그러면 이 문제를 귀하에게 할당할 수 있습니다(그 동안 나 자신에게 할당).

전문가 팁: 수락하면 GitHub에서 저장소의 모든 알림(하루 500개 이상)에 대해 자동으로 등록합니다. 문제에 대한 모든 멘션 및 알림을 보내는 "Not Watching"으로 변경하는 것이 좋습니다. 구독했습니다.

karelz 에 2017년 11월 02일

@jcdickinson , 나는 성가신 반복을 피하는 방법에 확실히 관심이 있습니다(초기화 구문에 대해 사람들이 어떻게 느낄지는 모르지만). 나는 유창함에 두 가지 문제가 있었다는 것을 기억하는 것 같습니다.

언급한 성능 문제
Fluent 메서드의 반환 값은 구조체의 복사본입니다. 다음과 같은 일을 하다가 실수로 입력을 잃는 것은 너무 쉽습니다.

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

이 스레드의 제안은 이미 승인되었으며(그리고 병합하는 데 순조롭습니다), 변경 사항에 대해 새 API 제안을 시작하는 것이 좋습니다.

morganbr 에 2017년 11월 03일

@karelz 나는 @gimpf가 이미 이 문제를 미리 @gimpf에 대신 할당하십시오. ( 편집: nvm)

jamesqo 에 2017년 11월 03일

@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 로 수행되었다고 생각합니다.

jamesqo 에 2017년 11월 06일

그게 받아들여진다면...

Obsolete 메시지에서 cannot 대신 should not 또는 may not 사용하는 것이 좋습니다.
예외가 유지되는 경우 메서드가 캐스트 또는 개방형 제네릭을 통해 호출되는 경우를 대비하여 메시지에 동일한 문자열을 넣습니다.

Joe4evr 에 2017년 11월 06일

@Joe4evr 저와 잘 GetHashCode 예외에도 동일한 메시지를 포함하는 것이 도움이 될 수 있습니다.

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

jamesqo 에 2017년 11월 06일

@morganbr 왜 이것을 다시

jamesqo 에 2017년 11월 16일

CoreFX에 노출시키기 위한 PR은 아직 진행되지 않았습니다.

jkotas 에 2017년 11월 16일

@gimpf 벤치마킹한 코드를 사용할 수 있습니까? 또는 SpookilySharp nuget 패키지가 어떻게 작동하는지 빠르게 확인할 수 있습니까? 나는 2년의 침체 이후에 그 프로젝트의 먼지를 털어내려 하고 있고 그것이 어떻게 서 있는지 궁금합니다.

JonHanna 에 2017년 11월 29일

@JonHanna 그는 여기에 게시했습니다: https://github.com/gimpf/Haschisch.Kastriert

jamesqo 에 2017년 11월 29일

👍2

@JonHanna , 범용 비암호화 해싱 API에서 무엇이 유용한지 생각할 수 있도록 테스트가 어떻게 진행되는지 듣고 싶습니다.

morganbr 에 2017년 11월 29일

@morganbr 그러한 API를 논의할 적절한 포럼은 어디인가요? 나는 그러한 API가 가장 낮은 공통 분모 이상으로 구성될 것으로 예상하며, 아마도 좋은 API는 더 큰 구조체의 향상된 JIT wrt 처리도 필요로 할 것입니다. 별도의 문제에서 더 잘 수행할 수 있는 모든 것에 대해 논의...

gimpf 에 2017년 12월 03일

@gimpf 당신을 위해 하나를 열었습니다. 닷넷/corefx#25666

jamesqo 에 2017년 12월 03일

@morganbr - 이 커밋을 포함할 패키지 이름 및 버전 번호를 얻을 수 있습니까?

smitpatel 에 2017년 12월 13일

@karelz , 패키지/버전 정보로 @smitpatel 을 도울 수 있습니까?

morganbr 에 2017년 12월 14일

나는 .NET Core의 매일 빌드를 시도할 것입니다 - 나는 내일까지 기다릴 것입니다.
나는 당신이 단순히 의존할 수 있는 패키지가 없다고 생각합니다.

karelz 에 2017년 12월 14일

👍1

여기 참가자들에게 질문합니다. Roslyn IDE를 사용하면 클래스/구조체의 필드/속성 집합을 기반으로 GetHashCode impl을 생성할 수 있습니다. 이상적으로 사람들은 https://github.com/dotnet/corefx/pull/25013 에 추가된 새로운 HashCode.Combine을 사용할 수 있습니다. 그러나 일부 사용자는 해당 코드에 액세스할 수 없습니다. 따라서 우리는 여전히 그들에게 작동할 GetHashCode를 생성할 수 있기를 원합니다.

최근에 우리가 생성하는 형식이 문제가 있다는 사실이 알려졌습니다. 즉, VB는 기본적으로 오버플로 검사를 사용하여 컴파일하고 impl은 오버플로를 발생시킵니다. 또한 VB는 코드 영역에 대한 오버플로 검사를 비활성화할 방법이 없습니다. 전체 어셈블리에 대해 완전히 켜져 있거나 꺼져 있습니다.

이 때문에 우리가 제공하는 impl을 이러한 문제를 겪지 않는 형식으로 대체할 수 있기를 바랍니다. 이상적으로 생성된 양식에는 다음과 같은 속성이 있습니다.

사용된 필드/속성당 GetHashCode의 한 줄/두 줄.
넘치지 않습니다.
합리적으로 좋은 해싱. 우리는 놀라운 결과를 기대하지 않습니다. 그러나 이미 괜찮은 것으로 검증되었으며 a + b + c + d 또는 a ^ b ^ c ^ d 일반적으로 발생하는 문제가 없기를 바랍니다.
코드에 대한 추가 종속성/요구 사항이 없습니다.

예를 들어, VB에 대한 한 가지 옵션은 다음과 같은 것을 생성하는 것입니다.

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에서는 세밀한 제어가 불가능합니다.

CyrusNajmabadi 에 2018년 01월 15일

누구든지 이러한 제약 조건과 함께 작동할 수 있는 적절한 해싱 알고리즘에 대해 알고 있습니까? 감사 해요!

Tuple.Create(...).GetHashCode() 있습니다. 분명히 할당이 발생하지만 예외를 던지는 것보다 나은 것 같습니다.

사용자에게 System.ValueTuple 를 설치하라고 말할 수 없는 이유가 있습니까? 내장 언어 기능이기 때문에 System.ValueTuple 패키지는 기본적으로 모든 플랫폼과 매우 호환됩니다.

jamesqo 에 2018년 01월 15일

분명히 할당이 발생하지만 예외를 던지는 것보다 나은 것 같습니다.

예. 할당을 일으키지 않는 것이 좋습니다.

사용자에게 System.ValueTuple을 설치하라고 말할 수 없는 이유가 있습니까?

ValueTuple 접근 방식을 생성하면 이는 동작이 됩니다. 그러나 다시 말하지만, 사용자가 구조를 크게 변경하지 않고 현재 코드를 구조화한 방식에 맞는 좋은 것을 생성할 수 있다면 좋을 것입니다.

VB 사용자는 이 문제를 합리적인 방식으로 해결할 수 있는 방법이 있어야 하는 것 같습니다. :) 하지만 그러한 접근 방식은 저를 피하고 있습니다. :)

CyrusNajmabadi 에 2018년 01월 15일

@CyrusNajmabadi , 사용자 코드에서 자체 해시 계산을 수행해야 하는 경우 CRC32가 테이블 조회와 XOR의 조합이기 때문에 작동할 수 있습니다(그러나 오버플로할 수 있는 산술은 아님). 그러나 몇 가지 단점이 있습니다.

CRC32는 엔트로피가 크지 않습니다(하지만 Roslyn이 지금 방출하는 것보다 여전히 더 나은 것 같습니다).
256 항목 조회 테이블을 코드 어딘가에 넣거나 조회 테이블을 생성하기 위해 코드를 방출해야 합니다.

아직 하고 있지 않다면 XXHash가 훨씬 더 나을 것이기 때문에 HashCode 유형을 감지하고 가능하면 이를 사용할 수 있기를 바랍니다.

morganbr 에 2018년 01월 16일

@morganbr 참조 https://github.com/dotnet/roslyn/pull/24161

우리는 다음을 수행합니다.

사용 가능한 경우 System.HashCode를 사용합니다. 완료.
그렇지 않고 C#의 경우:
2a. 체크 모드가 아닌 경우: 풀린 해시를 생성합니다.
2b. 체크 모드인 경우: 'unchecked{}'로 래핑된 롤링되지 않은 해시를 생성합니다.
그렇지 않고 VB에 있는 경우:
3b. 체크 모드가 아닌 경우: 풀린 해시를 생성합니다.
3c. 체크 모드에 있지만 System.ValueTuple에 대한 액세스 권한이 있는 경우: Return (a, b, c, ...).GetHashCode() 생성
3d. System.ValueTuple에 대한 액세스 권한이 없는 체크 모드인 경우. 풀린 해시를 생성하지만 오버플로 가능성이 매우 높은 주석을 VB에 추가합니다.

'3d'는 정말 안타까운 일입니다. 기본적으로 VB를 사용하지만 ValueTuple 또는 최신 시스템을 사용하지 않는 사람은 우리를 사용하여 합리적인 해시 알고리즘을 생성할 수 없습니다.

코드 어딘가에 256 항목 조회 테이블을 넣어야 합니다.

이것은 완전히 맛이 없을 것입니다 :)

CyrusNajmabadi 에 2018년 01월 16일

테이블 생성 코드도 불쾌한가요? 적어도 Wikipedia의 예 를 보면 코드가 많지 않습니다(그러나 여전히 사용자 소스의 어딘가에 있어야 함).

morganbr 에 2018년 01월 16일

참조된 어셈블리를 통해 사용할 수 없을 때 (훨씬 더 간단한) 컴파일러 속성 클래스 정의를 사용하여 Roslyn이 (IL과 함께) HashCode 소스를 프로젝트에 추가하는 것이 얼마나 끔찍할까요?

jnm2 에 2018년 01월 16일

👍1

참조된 어셈블리를 통해 사용할 수 없을 때 Roslyn이 (훨씬 더 간단한) 컴파일러 속성 클래스 정의로 하는 것처럼 HashCode 소스를 프로젝트에 추가하는 것이 얼마나 끔찍할까요?

HashCode 소스에 오버플로 동작이 필요하지 않습니까?
HashCode 소스를 훑어보았습니다. 그것은 아닌 사소한입니다. 사용자의 프로젝트에 모든 잡동사니를 생성하는 것은 꽤 무거울 것입니다.

VB에서 오버플로 수학이 작동하도록 하는 좋은 방법이 없다는 사실에 놀랐습니다.

CyrusNajmabadi 에 2018년 01월 16일

따라서 최소한 두 값을 함께 해싱하더라도 다음을 생성해야 할 것 같습니다.

```c#
var hc1 = (단위)(값1?.GetHashCode() ?? 0); // 오버플로 가능
var hc2 = (단위)(값2?.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; }

그래서 나는 이것이 어떻게 작동하는지 솔직히 알지 못합니다 :(

CyrusNajmabadi 에 2018년 01월 16일

Roslyn이 (IL과 함께) (많은) 프로젝트에 HashCode 소스를 추가하는 것이 얼마나 끔찍한 일입니까

이 작업을 어떻게 예상하십니까? 고객은 무엇을 작성하고 컴파일러는 이에 대한 응답으로 무엇을 합니까?

CyrusNajmabadi 에 2018년 01월 16일

또한 이 모든 문제를 해결할 수 있는 것은 .Net이 오버플로 없이 uint에서 int32로(또는 그 반대로) 변환하는 표면 API에 이미 노출된 공개 도우미가 있는 경우입니다.

그것들이 존재합니까? 그렇다면 오버플로 없이 유형 사이를 이동해야 하는 상황에 이를 사용하여 VB 버전을 쉽게 작성할 수 있습니다.

CyrusNajmabadi 에 2018년 01월 17일

테이블 생성 코드도 불쾌한가요?

나는 그렇게 생각합니다. 제 말은, 이것을 고객의 관점에서 생각하십시오. 그들은 단지 훌륭하게 자체 포함되고 합리적인 결과를 제공하는 괜찮은 GetHashCode 메소드를 원합니다. 그 기능을 사용하고 보조 쓰레기로 코드를 부풀리는 것은 꽤 불쾌할 것입니다. C# 경험이 괜찮을 것이라는 점을 감안할 때 또한 꽤 나쁩니다.

CyrusNajmabadi 에 2018년 01월 17일

서명된 64비트 유형과 서명되지 않은 64비트 유형의 일부 조합으로 또는 그로부터 캐스팅하여 대략적으로 올바른 오버플로 동작을 얻을 수 있습니다. 이와 같은 것(테스트되지 않았으며 VB 캐스팅 구문을 모릅니다):

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

morganbr 에 2018년 01월 17일

다음이 오버플로되지 않는다는 것을 어떻게 알 수 있습니까?

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

또는 그 문제에 대한 최종 (int32) 캐스트?

CyrusNajmabadi 에 2018년 01월 17일

오버플로 확인 변환 작업을 사용할 줄은 몰랐습니다. 캐스팅하기 전에 32비트로 마스킹할 수 있다고 생각합니다.

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

morganbr 에 2018년 01월 17일

uint32.Max 값도 Int32로 변환할 때 오버플로되므로 아마도 31비트일 것입니다. :)

가능합니다. 추악하지만 가능합니다 :) 이 코드에는 많은 캐스트가 있습니다.

CyrusNajmabadi 에 2018년 01월 17일

확인. 실행 가능한 솔루션이 있다고 생각합니다. 오늘날 우리가 생성하는 알고리즘의 핵심은 다음과 같습니다.

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

64비트 수학을 수행하고 있지만 "hashCode"가 32비트로 제한되어 있다고 가정해 보겠습니다. 그러면 <largest_32_bit> * -1521134295 + <largest_32_bit> 는 64비트를 오버플로하지 않습니다. 따라서 우리는 항상 64비트로 계산을 수행한 다음 32비트(또는 32비트)로 제한하여 다음 라운드가 오버플로되지 않도록 할 수 있습니다.

CyrusNajmabadi 에 2018년 01월 17일

감사 해요!

CyrusNajmabadi 에 2018년 01월 17일

@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 에 2018년 01월 17일

@CyrusNajmabadi , 오버플로되지는 않지만(Int64.Max = Int32.Max*Int32.Max이고 상수가 그보다 훨씬 작기 때문에) 상위 비트를 0으로 마스킹하므로 31비트 해시일 뿐입니다. 상위 비트를 켜진 상태로 두는 것이 오버플로로 간주됩니까?

morganbr 에 2018년 01월 17일

@CyrusNajmabadi hashCode A는 Long 로 어디서든 0에서 할 수 Integer.MaxValue . 왜 내가 이것을 받고 있습니까?

그러나 아니요, 실제로 넘칠 수는 없습니다.

jnm2 에 2018년 01월 17일

Btw- 차선책 해시를 추가하는 것보다 Roslyn이 NuGet 패키지를 추가하도록 하고 싶습니다.

jnm2 에 2018년 01월 17일

그러나 상위 비트를 0으로 마스킹하므로 31비트 해시일 뿐입니다. 상위 비트를 켜진 상태로 두는 것이 오버플로로 간주됩니까?

그건 좋은 지적이야. 나는 단위를 사용하는 다른 알고리즘에 대해 생각하고 있다고 생각합니다. 따라서 long에서 uint로 안전하게 변환하려면 부호 비트를 포함하지 않아야 했습니다. 그러나 이것은 모두 부호 있는 수학이므로 각 항목을 추가한 후 하위 32비트만 유지하도록 0xffffffff에 대해 마스크하는 것이 좋을 것이라고 생각합니다.

CyrusNajmabadi 에 2018년 01월 17일

차선책 해시를 추가하는 것보다 Roslyn이 NuGet 패키지를 추가하도록 하고 싶습니다.

사용자가 원하는 경우 이미 그렇게 할 수 있습니다. 이것은 사용자가 이러한 종속성을 추가하지 않거나 추가할 수 없는 경우 수행할 작업에 대한 것입니다. 이것은 또한 사용자에게 합리적으로 '충분히 좋은' 해시를 제공하는 것에 관한 것입니다. 즉, 사람들이 자주 취하는 일반적인 "x + y + z" 접근 방식보다 더 나은 것입니다. 모든 사용자에 대한 해싱과 관련하여 '최적'이 무엇인지에 대한 좋은 정의가 없기 때문에 '최적'으로 의도되지 않았습니다. 여기서 우리가 취하고 있는 접근 방식은 익명 유형에 대해 컴파일러에서 이미 내보낸 접근 방식입니다. 사용자 코드에 많은 복잡성을 추가하지 않으면서 상당히 좋은 동작을 보여줍니다. 시간이 지남에 따라 점점 더 많은 사용자가 앞으로 나아갈 수 있게 되면서 서서히 사라지고 대부분의 사람들에게 HashCode.Combine으로 대체될 수 있습니다.

CyrusNajmabadi 에 2018년 01월 17일

그래서 나는 약간의 작업을 했고 모든 문제를 해결할 수 있다고 생각하는 다음을 생각해 냈습니다.

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

흥미로운이 작품은 특히 호출 .GetHashCode() 에 의해 생성 된 Int64 값에 (hashCode * -1521134295 + a.GetHashCode()) . 이 64비트 값에 대해 .GetHashCode를 호출하면 우리의 요구에 맞는 두 가지 좋은 속성이 있습니다. 첫째, hashCode가 합법적인 int32 값만 저장하도록 합니다(최종 반환 캐스트를 항상 안전하게 수행할 수 있도록 함). 둘째, 작업 중인 int64 임시 값의 상위 32비트에서 중요한 정보를 잃지 않도록 합니다.

CyrusNajmabadi 에 2018년 01월 17일

👍1

@CyrusNajmabadi 실제로 패키지 설치를 제안하는 것이 제가 질문한 것입니다. 내가 해야 하는 일에서 구해줍니다.

jnm2 에 2018년 01월 17일

HashCode를 입력하면 MS nuget 패키지에 System.HashCode가 제공되면 Roslyn이 제공합니다.

CyrusNajmabadi 에 2018년 01월 17일

존재하지 않는 GetHashCode 오버로드를 생성하고 동일한 작업으로 패키지를 설치하기를 원합니다.

jnm2 에 2018년 01월 17일

대부분의 사용자에게 적절한 선택이 아니라고 생각합니다. 종속성을 추가하는 것은 사용자가 강제로 수행해서는 안 되는 매우 무거운 작업입니다. 사용자는 이러한 선택을 할 적절한 시기를 결정할 수 있으며 IDE는 이를 존중합니다. 그것이 우리가 지금까지 모든 기능에 대해 취한 접근 방식이었고 사람들이 좋아하는 건강한 방식이었습니다.

CyrusNajmabadi 에 2018년 01월 17일

참고: 참조를 추가하기 위해 이 API가 포함된 nuget 패키지는 무엇입니까?

CyrusNajmabadi 에 2018년 01월 17일

구현은 System.Private.CoreLib.dll에 있으므로 런타임 패키지의 일부로 제공됩니다. 계약은 System.Runtime.dll입니다.

morganbr 에 2018년 01월 17일

확인. 이 경우 사용자가 최신 대상 프레임워크로 이동할 때 이 메시지를 받는 것처럼 들립니다. 그런 종류의 일은 내가 사용자의 프로젝트에 "Equals+hashcode 생성"을 수행하도록 하는 단계가 아닙니다.

CyrusNajmabadi 에 2018년 01월 17일

👍1

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Runtime: 제안: 좋은 해시 코드를 더 쉽게 생성할 수 있도록 System.HashCode를 추가합니다.

업데이트 6/16/17: 자원 봉사자를 찾고 있습니다

업데이트 6/13/17: 제안 수락!

이론적 해석

제안

비고

가장 유용한 댓글

모든 182 댓글

요구 사항

API 모양

다음 단계

편집하다

관련 문제