प्रस्ताव: हैश रैंडमाइजेशन सपोर्ट जोड़ें

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

मुझे लगता है कि ओवरलोड Combine(_field1, _field2, _field3, _field4, _field5) की कोई आवश्यकता नहीं है क्योंकि अगला कोड HashCode.Empty.Combine(_field1).Combine(_field2).Combine(_field3).Combine(_field4).Combine(_field5); को कम्बाइन कॉल के बिना इनलाइन अनुकूलित किया जाना चाहिए।

@AlexRadch

प्रस्ताव: संग्रह के लिए समर्थन जोड़ें

हां, यह इस प्रस्ताव के लिए मेरी अंतिम योजना का हिस्सा था। मुझे लगता है कि उन तरीकों को जोड़ने के बारे में जाने से पहले हम एपीआई को कैसे दिखाना चाहते हैं, इस पर ध्यान देना महत्वपूर्ण है।

वह एक अलग एल्गोरिथ्म का उपयोग करना चाहता था, जैसे कि मार्विन 32 हैश जो कोरक्लर में स्ट्रिंग्स के लिए उपयोग किया जाता है। इसके लिए हैशकोड के आकार को 8 बाइट्स तक विस्तारित करने की आवश्यकता होगी।

हैश 32 और हैश 64 प्रकार के बारे में क्या है जो आंतरिक रूप से 4 या 8 बाइट डेटा के लायक स्टोर करेगा? प्रत्येक के पेशेवरों / विपक्षों का दस्तावेजीकरण करें। हैश 64 एक्स के लिए अच्छा है, लेकिन संभावित रूप से धीमा है। हैश 32 तेज है, लेकिन संभावित रूप से वितरित नहीं है (या वास्तव में जो भी ट्रेडऑफ है)।

वह हैश बीज को यादृच्छिक बनाना चाहता था, इसलिए हैश नियतात्मक नहीं होगा।

यह उपयोगी व्यवहार की तरह लगता है। लेकिन मैं देख सकता था कि लोग इसे नियंत्रित करना चाहते हैं। तो शायद हैश बनाने के दो तरीके होने चाहिए, एक जो बीज नहीं लेता (और एक यादृच्छिक बीज का उपयोग करता है) और एक जो बीज प्रदान करने की अनुमति देता है।

नोट: अगर यह Fx में प्रदान किया जा सकता है तो Roslyn को अच्छा लगेगा। हम उपयोगकर्ता के लिए 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; }

यह एक अच्छा अनुभव नहीं है, और यह कई बदसूरत अवधारणाओं को उजागर करता है। हम एक हैश पाकर रोमांचित होंगे। इसके बजाय हम जो भी एपीआई कॉल कर सकते हैं।

धन्यवाद!

मुरमुरहाश के बारे में क्या? यह यथोचित रूप से तेज़ है और इसमें बहुत अच्छे हैशिंग गुण हैं। दो अलग-अलग कार्यान्वयन भी हैं, एक जो 32-बिट हैश को थूकता है और दूसरा जो 128-बिट हैश को थूकता है।

32-बिट और 128-बिट दोनों स्वरूपों के लिए वेक्टरकृत कार्यान्वयन भी है।

@tannergooding MurmurHash इस ब्लॉग पोस्ट की आवाज़ से तेज़, लेकिन सुरक्षित नहीं है।

@jkotas , पिछले साल हमारी चर्चा के बाद से 32-बिट पर> 4-बाइट @CyrusNajmabadi के प्रस्ताव के बारे में क्या सोचते हैं:

हैश 32 और हैश 64 प्रकार के बारे में क्या है जो आंतरिक रूप से 4 या 8 बाइट डेटा के लायक स्टोर करेगा? प्रत्येक के पेशेवरों / विपक्षों का दस्तावेजीकरण करें। हैश 64 एक्स के लिए अच्छा है, लेकिन संभावित रूप से धीमा है। हैश 32 तेज है, लेकिन संभावित रूप से वितरित नहीं है (या वास्तव में जो भी ट्रेडऑफ है)।

मुझे अभी भी लगता है कि यह प्रकार डेवलपर्स को पेश करने के लिए बहुत मूल्यवान होगा और इसे 2.0 में रखना बहुत अच्छा होगा।

@jamesqo , मुझे नहीं लगता कि इस कार्यान्वयन को क्रिप्टोग्राफ़िक रूप से सुरक्षित होने की आवश्यकता है (यह स्पष्ट क्रिप्टोग्राफ़िक रूप से हैशिंग फ़ंक्शंस का उद्देश्य है)।

साथ ही, वह लेख मुरमुर२ पर लागू होता है। Murmur3 एल्गोरिथम में समस्या का समाधान किया गया है।

पिछले साल हमारी चर्चा के बाद से 32-बिट पर> 4-बाइट स्ट्रक्चर के लिए बेहतर कोड बनाने के लिए जेआईटी

मुझे किसी की जानकारी नहीं है।

आप @CyrusNajmabadi के प्रस्ताव के बारे में क्या सोचते हैं

फ्रेमवर्क प्रकार सरल विकल्प होने चाहिए जो 95%+ मामलों के लिए अच्छी तरह से काम करते हैं। वे सबसे तेज़ नहीं हो सकते हैं, लेकिन यह ठीक है। आपको हैश 32 और हैश 64 के बीच चयन करना आसान विकल्प नहीं है।

मेरे साथ ठीक है। लेकिन क्या हमारे पास कम से कम उन ९५% मामलों का पर्याप्त समाधान हो सकता है? अभी कुछ नहीं है...:-/

हैशकोड = हैशकोड * -1521134295 + EqualityComparer.Default.GetHashCode(this.s);

@CyrusNajmabadi आप यहाँ EqualityComparer को क्यों बुला रहे हैं, न कि केवल this.s.GetHashCode ()?

गैर-संरचनाओं के लिए: ताकि हमें शून्य की जांच करने की आवश्यकता न हो।

यह उस चीज़ के करीब है जिसे हम परदे के पीछे के गुमनाम प्रकारों के लिए भी उत्पन्न करते हैं। मैं कोड उत्पन्न करने के लिए ज्ञात गैर-शून्य मानों के मामले को अनुकूलित करता हूं जो उपयोगकर्ताओं के लिए अधिक सुखद होगा। लेकिन इसके लिए सिर्फ बिल्ट इन एपीआई होना अच्छा होगा।

EqualityComparer.Default.GetHashCode पर कॉल शून्य की जांच की तुलना में 10x+ अधिक महंगा है ...।

EqualityComparer.Default.GetHashCode पर कॉल शून्य के लिए चेक की तुलना में 10x + अधिक महंगा है।

एक समस्या की तरह लगता है। अगर केवल अच्छे हैश कोड एपीआई थे तो हम एफएक्स में कॉल कर सकते थे जिसे मैं स्थगित कर सकता था :)

(साथ ही, हमें वह समस्या तब हमारे अनाम प्रकारों में होती है, जैसा कि हम वहां भी उत्पन्न करते हैं)।

सुनिश्चित नहीं है कि हम टुपल्स के लिए क्या करते हैं, लेकिन मुझे लगता है कि यह समान है।

सुनिश्चित नहीं है कि हम टुपल्स के लिए क्या करते हैं, लेकिन मुझे लगता है कि यह समान है।

System.Tuple ऐतिहासिक कारणों से EqualityComparer<Object>.Default के माध्यम से चला जाता है। System.ValueTuple Object.GetHashCode को नल चेक के साथ कॉल करता है - https://github.com/dotnet/coreclr/blob/master/src/mscorlib/shared/System/ValueTuple.cs#L809।

नहीं ओ। ऐसा लगता है कि टुपल सिर्फ "हैश हेल्पर्स" का उपयोग कर सकता है। क्या इसका खुलासा किया जा सकता है ताकि उपयोगकर्ताओं को समान लाभ मिल सके?

महान। मुझे कुछ ऐसा ही करने में खुशी हो रही है। मैंने अपने अनाम प्रकारों से शुरुआत की क्योंकि मुझे लगा कि वे उचित सर्वोत्तम प्रथाएं हैं। यदि नहीं, तो ठीक है। :)

लेकिन इसलिए नहीं कि मैं यहाँ हूँ। मैं यहां कुछ सिस्टम प्राप्त करने के लिए हूं जो वास्तव में हैश को प्रभावी ढंग से जोड़ता है। यदि/कब यह प्रदान किया जा सकता है तो हम यादृच्छिक संख्याओं में हार्डकोडिंग और हैश मानों को स्वयं संयोजित करने के बजाय खुशी से कॉल करने के लिए आगे बढ़ेंगे।

एपीआई आकार क्या होगा जो आपको लगता है कि कंपाइलर जेनरेट कोड के लिए सबसे अच्छा काम करेगा?

वस्तुतः पहले प्रस्तुत किए गए 32 बिट समाधानों में से कोई भी मेरे साथ ठीक रहेगा। हेक, 64 बिट समाधान मेरे साथ ठीक हैं। बस कुछ प्रकार का एपीआई जिसे आप प्राप्त कर सकते हैं, "मैं किसी प्रकार के उचित फैशन में हैश को जोड़ सकता हूं और उचित रूप से वितरित परिणाम उत्पन्न कर सकता हूं"।

मैं इन बयानों को समेट नहीं सकता:

हमारे पास एक अपरिवर्तनीय हैशकोड संरचना थी जो आकार में 4 बाइट्स थी। इसमें एक कॉम्बिनेशन (इंट) विधि थी, जो प्रदान किए गए हैश कोड में डीजेबीएक्स 33 एक्स-जैसे एल्गोरिदम के माध्यम से अपने स्वयं के हैश कोड के साथ मिश्रित होती है, और एक नया हैशकोड लौटाती है।

@jkotas ने नहीं सोचा था कि DJBX33X जैसा एल्गोरिथ्म काफी मजबूत था।

और

फ्रेमवर्क प्रकार सरल विकल्प होने चाहिए जो 95%+ मामलों के लिए अच्छी तरह से काम करते हैं।

क्या हम एक साधारण 32 बिट संचित हैश के साथ नहीं आ सकते हैं जो 95% मामलों के लिए पर्याप्त रूप से काम करता है? ऐसे कौन से मामले हैं जिन्हें यहां ठीक से हैंडल नहीं किया गया है, और हमें क्यों लगता है कि वे 95% मामलों में हैं?

@jkotas , क्या वास्तव में इस प्रकार के लिए प्रदर्शन महत्वपूर्ण है? मुझे लगता है कि हैशटेबल लुकअप जैसी औसत चीजें हैं और इसमें कुछ संरचना प्रतियों की तुलना में अधिक समय लगेगा। यदि यह एक अड़चन बन जाता है, तो क्या एपीआई जारी होने के बाद जेआईटी टीम को 32-बिट संरचना प्रतियों को अनुकूलित करने के लिए कहना उचित होगा, ताकि इस एपीआई को अवरुद्ध करने के बजाय उनके पास कुछ प्रोत्साहन हो, जब कोई भी अनुकूलन पर काम नहीं कर रहा हो प्रतियां?

क्या हम एक साधारण 32 बिट संचित हैश के साथ नहीं आ सकते हैं जो 95% मामलों के लिए पर्याप्त रूप से काम करता है?

स्ट्रिंग्स के लिए डिफ़ॉल्ट 32 बिट संचित हैश द्वारा हमें वास्तव में बुरी तरह से जला दिया गया है, और यही कारण है कि मार्विन हैश .NET कोर में स्ट्रिंग्स के लिए - https://github.com/dotnet/corert/blob/87e58839d6629b5f90777f886a2f52d7a99c076f/src/System.Private.CoreLib/ src/System/Marvin.cs#L25. मुझे नहीं लगता कि हम यहां वही गलती दोहराना चाहते हैं।

@jkotas , क्या वास्तव में इस प्रकार के लिए प्रदर्शन महत्वपूर्ण है?

मुझे नहीं लगता कि प्रदर्शन महत्वपूर्ण है। चूंकि ऐसा लगता है कि यह एपीआई ऑटो-जेनरेटेड कंपाइलर कोड द्वारा उपयोग किया जा रहा है, मुझे लगता है कि हमें छोटे जेनरेट कोड को पसंद करना चाहिए कि यह कैसा दिखता है। गैर-धाराप्रवाह पैटर्न छोटा कोड है।

स्ट्रिंग के लिए 32 बिट संचय हैश डिफ़ॉल्ट रूप से हम वास्तव में बुरी तरह से जला दिए गए हैं

यह 95% मामला नहीं लगता है। हम सामान्य डेवलपर्स के बारे में बात कर रहे हैं जो उन सभी प्रकारों के लिए "काफी अच्छा" हैश चाहते हैं जहां वे आज मैन्युअल रूप से चीजें करते हैं।

चूंकि ऐसा लगता है कि यह एपीआई ऑटो-जेनरेटेड कंपाइलर कोड द्वारा उपयोग किया जा रहा है, मुझे लगता है कि हमें छोटे जेनरेट कोड को पसंद करना चाहिए कि यह कैसा दिखता है। गैर-धाराप्रवाह पैटर्न छोटा कोड है।

यह रोसलिन कंपाइलर द्वारा उपयोग के लिए नहीं है। यह Roslyn IDE द्वारा उपयोग के लिए है जब हम उपयोगकर्ताओं को उनके प्रकार के लिए GetHashCodes उत्पन्न करने में सहायता करते हैं। यह वह कोड है जिसे उपयोगकर्ता देखेगा और उसे बनाए रखना होगा, और कुछ समझदार होना चाहिए जैसे:

```सी#
वापसी हैश। कॉम्बिन (यह। ए?। गेटहैशकोड () ?? 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

हमें लगता है कि यह टुपल्स के लिए काफी अच्छा है। यह मेरे लिए अस्पष्ट है कि इसे उन उपयोगकर्ताओं के लिए उपलब्ध कराने में ऐसी समस्या क्यों होगी जो इसे अपने प्रकार के लिए चाहते हैं।

नोट: हमने इसे रोसलिन में भी करने पर विचार किया है:

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

लेकिन अब आप लोगों को किसी प्रकार का उचित डिफ़ॉल्ट हैशिंग व्यवहार प्राप्त करने के लिए एक (संभावित रूप से बड़ी) संरचना उत्पन्न करने के लिए मजबूर कर रहे हैं।

हम सामान्य डेवलपर्स के बारे में बात कर रहे हैं जो उन सभी प्रकारों के लिए "काफी अच्छा" हैश चाहते हैं जहां वे आज मैन्युअल रूप से चीजें करते हैं।

मूल स्ट्रिंग हैश एक "काफी अच्छा" हैश था जो सामान्य डेवलपर्स के लिए अच्छा काम करता था। लेकिन तब यह पता चला कि ASP.NET वेबसर्वर DoS हमलों के प्रति संवेदनशील थे क्योंकि वे प्राप्त सामग्री को हैशटेबल में संग्रहीत करते हैं। तो "काफी अच्छा" हैश मूल रूप से एक खराब सुरक्षा समस्या में बदल गया।

हमें लगता है कि यह टुपल्स के लिए काफी अच्छा है

जरूरी नहीं। हमने हैशकोड को यादृच्छिक बनाने के लिए टुपल्स के लिए एक बैक स्टॉप उपाय बनाया है जो हमें बाद में एल्गोरिदम को संशोधित करने का विकल्प देता है।

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

यह मुझे उचित लगता है।

मुझे आपका पॉज़िटॉइन नहीं मिला। ऐसा लगता है कि आप दो बातें कह रहे हैं:

मूल स्ट्रिंग हैश एक "काफी अच्छा" हैश था जो सामान्य डेवलपर्स के लिए अच्छा काम करता था। लेकिन तब यह पता चला कि ASP.NET वेबसर्वर DoS हमलों के प्रति संवेदनशील थे क्योंकि वे प्राप्त सामग्री को हैशटेबल में संग्रहीत करते हैं। तो "काफी अच्छा" हैश मूल रूप से एक खराब सुरक्षा समस्या में बदल गया।

ठीक है, अगर ऐसा है, तो चलिए एक हैश कोड प्रदान करते हैं जो उन लोगों के लिए अच्छा है जिन्हें सुरक्षा/DoS चिंता है।

फ्रेमवर्क प्रकार सरल विकल्प होने चाहिए जो 95%+ मामलों के लिए अच्छी तरह से काम करते हैं।

ठीक है, अगर ऐसा है, तो चलिए एक हैश कोड प्रदान करते हैं जो 95% मामलों के लिए पर्याप्त है। जिन लोगों को सुरक्षा/DoS संबंधी चिंता है, वे उस उद्देश्य के लिए प्रलेखित विशेष प्रपत्रों का उपयोग कर सकते हैं।

जरूरी नहीं। हमने हैशकोड को यादृच्छिक बनाने के लिए टुपल्स के लिए एक बैक स्टॉप उपाय बनाया है जो हमें बाद में एल्गोरिदम को संशोधित करने का विकल्प देता है।

ठीक। क्या हम इसे उजागर कर सकते हैं ताकि उपयोगकर्ता उसी तंत्र का उपयोग कर सकें।

--
मैं वास्तव में यहां संघर्ष कर रहा हूं क्योंकि ऐसा लगता है जैसे हम कह रहे हैं "क्योंकि हम एक सार्वभौमिक समाधान नहीं बना सकते हैं, हर किसी को अपना खुद का रोल करना होगा"। ऐसा लगता है कि यह सबसे खराब जगहों में से एक है। क्योंकि निश्चित रूप से हमारे अधिकांश ग्राहक DoS चिंताओं के लिए अपना खुद का 'मार्विन हैश' रोल करने के बारे में नहीं सोच रहे हैं। वे केवल एक अंतिम हैश में फ़ील्ड हैश को जोड़ रहे हैं, ज़ोरिंग कर रहे हैं, या अन्यथा खराब संयोजन कर रहे हैं।

अगर हम 95% मामले की परवाह करते हैं, तो हमें आम तौर पर एक अच्छा पर्याप्त हैश बनाना चाहिए। अगर हम 5% मामले की परवाह करते हैं, तो हम उसके लिए एक विशेष समाधान प्रदान कर सकते हैं।

यह मुझे उचित लगता है।

बढ़िया :) क्या हम तब बेनकाब कर सकते हैं:

```सी#
नेमस्पेस सिस्टम। न्यूमेरिक्स। हैशिंग
{
आंतरिक स्थिर वर्ग हैश हेल्पर्स
{
सार्वजनिक स्थैतिक रीडोनली int RandomSeed = नया रैंडम ()। अगला (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 चिंता है।

ठीक। तो आज आप इस मुद्दे से कैसे निपट रहे हैं कि किसी को हैशकोड के साथ कोई मदद नहीं मिली है, और इस तरह शायद चीजें खराब कर रही हैं? स्पष्ट रूप से यह दुनिया की उस स्थिति के लिए स्वीकार्य है। तो एक उचित हैशिंग सिस्टम प्रदान करने से क्या नुकसान होता है जो आज लोगों की तुलना में बेहतर प्रदर्शन करता है?

क्योंकि हमारे पास इसे साबित करने का कोई तरीका नहीं है, और हमें सावधानी के पक्ष में गलती करनी चाहिए, भले ही इसकी प्रदर्शन लागत हो

यदि आप कुछ प्रदान नहीं करते हैं, तो लोग बुरी तरह से काम करते रहेंगे। "काफी अच्छा" की अस्वीकृति क्योंकि कुछ भी सही नहीं है, इसका मतलब है कि आज हमारे पास खराब स्थिति है।

प्रत्येक ASP.NET ऐप में सुरक्षा/DoS चिंता है।

क्या आप इसे समझा सकते हैं? जैसा कि मैं इसे समझता हूं, यदि आप मनमाना इनपुट स्वीकार कर रहे हैं और फिर इसे कुछ डेटा संरचना में संग्रहीत कर रहे हैं जो खराब प्रदर्शन करता है तो इनपुट को विशेष रूप से तैयार किया जा सकता है, तो आपको एक डीओएस चिंता है। ठीक है, मुझे लगता है कि उपयोगकर्ता से आए वेब परिदृश्यों में स्ट्रिंग्स के साथ यह चिंता का विषय है।

तो यह उन शेष प्रकारों पर कैसे लागू होता है जिनका उपयोग इस परिदृश्य में नहीं किया जा रहा है?

हमारे पास इस प्रकार के सेट हैं:

1. उपयोगकर्ता प्रकार जिन्हें DoS सुरक्षित होने की आवश्यकता है। अभी हम मदद करने के लिए कुछ भी आपूर्ति नहीं करते हैं, इसलिए हम पहले से
2. उपयोगकर्ता प्रकार जिन्हें DoS सुरक्षित होने की आवश्यकता नहीं है। अभी हम मदद करने के लिए कुछ भी आपूर्ति नहीं करते हैं, इसलिए हम पहले से
3. फ्रेमवर्क प्रकार जिन्हें DoS सुरक्षित होने की आवश्यकता है। अभी हमने उन्हें DoS सुरक्षित बना दिया है, लेकिन API के माध्यम से हम एक्सपोज़ नहीं करते हैं।
4. फ्रेमवर्क प्रकार जिन्हें DoS सुरक्षित होने की आवश्यकता नहीं है। अभी हमने उन्हें हैश दिया है, लेकिन एपीआई के माध्यम से हम उजागर नहीं करते हैं।

मूल रूप से, हमें लगता है कि ये मामले महत्वपूर्ण हैं, लेकिन इतना महत्वपूर्ण नहीं है कि वास्तव में उपयोगकर्ताओं को '1' या '2' को संभालने के लिए एक समाधान प्रदान कर सकें। क्योंकि हम चिंतित हैं कि '2' का समाधान '1' के लिए अच्छा नहीं होगा, हम इसे पहले स्थान पर भी प्रदान नहीं करेंगे। और अगर हम '1' के लिए कोई समाधान देने को भी तैयार नहीं हैं तो ऐसा लगता है कि हम अविश्वसनीय रूप से अजीब स्थिति में हैं। हम DoSing और ASP के बारे में चिंतित हैं, लेकिन वास्तव में लोगों की मदद करने के लिए पर्याप्त चिंतित नहीं हैं। और क्योंकि हम इसके साथ लोगों की मदद नहीं करेंगे, हम गैर-DoS मामलों में भी मदद करने को तैयार नहीं हैं।

--

यदि ये दो मामले महत्वपूर्ण हैं (जिन्हें मैं स्वीकार करने को तैयार हूं) तो क्यों न सिर्फ दो एपीआई दें? उन्हें दस्तावेज। उन्हें स्पष्ट करें कि वे किस लिए हैं। अगर लोग उनका सही इस्तेमाल करते हैं, तो बढ़िया । अगर लोग उनका सही इस्तेमाल नहीं करते हैं तो भी ठीक है। आखिरकार, वे आज वैसे भी ठीक से काम नहीं कर रहे हैं, तो चीजें कैसे बदतर हैं?

इस बारे में तुम्हारा क्या विचार है

एक या दूसरे तरीके से मेरी कोई राय नहीं है। यदि यह एक एपीआई है जिसका ग्राहक उपयोग कर सकते हैं जो स्वीकार्य रूप से प्रदर्शन करता है और जो उनके अंत में स्पष्ट कोड के साथ एक साधारण एपीआई प्रदान करता है, तो मुझे लगता है कि यह ठीक है।

मुझे लगता है कि एक साधारण स्थिर रूप होना अच्छा होगा जो एक क्रमबद्ध फैशन में फ़ील्ड/गुणों के एक सेट को गठबंधन करने के 99% मामले को संभालता है। ऐसा लगता है कि इस प्रकार की चीज़ को काफी सरलता से जोड़ा जा सकता है।

मुझे लगता है कि एक साधारण स्थिर रूप होना अच्छा होगा

इस बात से सहमत।

मुझे लगता है कि एक साधारण स्थिर रूप होना अच्छा होगा जो एक क्रमबद्ध फैशन में फ़ील्ड/गुणों के एक सेट को गठबंधन करने के 99% मामले को संभालता है। ऐसा लगता है कि इस प्रकार की चीज़ को काफी सरलता से जोड़ा जा सकता है।

इस बात से सहमत।

मैं इस पर आधे रास्ते में आप दोनों से मिलने को तैयार हूं क्योंकि मैं वास्तव में किसी प्रकार के एपीआई को देखना चाहता हूं। @jkotas मुझे अभी भी समझ में नहीं आया कि आप एक अपरिवर्तनीय उदाहरण-आधारित API जोड़ने का विरोध कर रहे हैं; पहले आपने कहा था कि ऐसा इसलिए था क्योंकि 32-बिट प्रतियां धीमी होंगी, फिर क्योंकि परिवर्तनीय एपीआई अधिक संक्षिप्त होगी (जो सच नहीं है; 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
}

क्या यह उचित लगता है?

मैं अभी अपनी पोस्ट संपादित नहीं कर सकता, लेकिन मुझे अभी एहसास हुआ कि सभी विधियां टी को स्वीकार नहीं कर सकती हैं। उस स्थिति में, हमारे पास केवल 8 ओवरलोड हो सकते हैं जो सभी इनट्स को स्वीकार कर सकते हैं और उपयोगकर्ता को GetHashCode पर कॉल करने के लिए मजबूर कर सकते हैं।

यदि ये दो मामले महत्वपूर्ण हैं (जिन्हें मैं स्वीकार करने को तैयार हूं) तो क्यों न सिर्फ दो एपीआई दें? उन्हें दस्तावेज। उन्हें स्पष्ट करें कि वे किस लिए हैं। अगर लोग उनका सही इस्तेमाल करते हैं, तो बढ़िया। अगर लोग उनका सही इस्तेमाल नहीं करते हैं तो भी ठीक है। आखिरकार, वे वैसे भी आज ठीक से काम नहीं कर रहे हैं, तो चीजें कैसे बदतर हैं?

क्योंकि लोग वहां होने पर चीजों का ठीक से इस्तेमाल नहीं करते हैं। आइए एक साधारण उदाहरण लेते हैं, एक्सएसएस। शुरुआत से ही वेब फॉर्म में भी आउटपुट को HTML एन्कोड करने की क्षमता थी। हालांकि डेवलपर्स को जोखिम नहीं पता था, यह नहीं पता था कि इसे ठीक से कैसे करना है, और केवल तब पता चला जब बहुत देर हो चुकी थी, उनका ऐप प्रकाशित हुआ था, और ओह, अब उनकी ऑथ कुकी हटा दी गई है।

लोगों को सुरक्षा विकल्प देना यह मानता है कि वे

1. जानिए समस्या के बारे में।
2. समझें कि जोखिम क्या हैं।
3. उन जोखिमों का मूल्यांकन कर सकते हैं।
4. करने के लिए सही चीज़ आसानी से खोज सकते हैं।

वे धारणाएं आम तौर पर अधिकांश डेवलपर्स के लिए नहीं होती हैं, वे केवल समस्या के बारे में पता लगाते हैं जब बहुत देर हो चुकी होती है। डेवलपर्स सुरक्षा सम्मेलनों में नहीं जाते हैं, वे श्वेत पत्र नहीं पढ़ते हैं और वे समाधान नहीं समझते हैं। इसलिए ASP.NET HashDoS परिदृश्य में हमने उनके लिए चुनाव किया, हमने उन्हें डिफ़ॉल्ट रूप से संरक्षित किया, क्योंकि यह करना सही था, और इसका सबसे बड़ा प्रभाव था। हालाँकि हमने इसे केवल स्ट्रिंग्स पर लागू किया, और इसने उन लोगों को छोड़ दिया जो उपयोगकर्ता इनपुट से कस्टम कक्षाओं का निर्माण कर रहे थे। हमें सही काम करना चाहिए, और अब उन ग्राहकों की सुरक्षा करने में मदद करनी चाहिए, और इसे डिफ़ॉल्ट बनाना चाहिए, जिसमें सफलता का गड्ढा हो, असफलता नहीं। सुरक्षा के लिए एपीआई डिज़ाइन कभी-कभी पसंद के बारे में नहीं होता है, बल्कि उपयोगकर्ता की मदद करने के बारे में होता है कि वे इसे जानते हैं या नहीं।

एक उपयोगकर्ता हमेशा एक गैर-सुरक्षा केंद्रित हैश बना सकता है; तो दिए गए दो विकल्प

1. डिफ़ॉल्ट हैश उपयोगिता गैर-सुरक्षा जागरूक है; उपयोगकर्ता एक सुरक्षा जागरूक हैश फ़ंक्शन बना सकता है
2. डिफ़ॉल्ट हैश उपयोगिता सुरक्षा जागरूक है; उपयोगकर्ता एक कस्टम गैर-सुरक्षा जागरूक हैश फ़ंक्शन बना सकता है

तब दूसरा शायद बेहतर है; और जो सुझाव दिया गया है उसका क्रिप्टो हैश पर पूर्ण प्रभाव नहीं होगा; तो यह एक अच्छा समझौता करता है?

इन थ्रेड्स में चल रहे प्रश्नों में से एक यह है कि कौन सा एल्गोरिथम सभी के लिए एकदम सही है। मुझे लगता है कि यह कहना सुरक्षित है कि एक भी संपूर्ण एल्गोरिथम नहीं है। हालांकि, मुझे नहीं लगता कि हमें कोड से बेहतर कुछ प्रदान करने से रोकना चाहिए जैसे @CyrusNajmabadi ने दिखाया है, जिसमें सामान्य .NET इनपुट के साथ-साथ अन्य सामान्य हैशर बग्स (जैसे इनपुट डेटा खोना या आसानी से होना) के लिए खराब एन्ट्रॉपी है। रीसेट करने योग्य)।

मैं "सर्वश्रेष्ठ एल्गोरिदम" समस्या को हल करने के लिए कुछ विकल्पों का प्रस्ताव देना चाहता हूं:

1. स्पष्ट विकल्प: मैं गैर-क्रिप्टोग्राफिक हैश (उदाहरण के लिए शायद xxHash, Marvin32, और SpookyHash) के एक सूट के लिए जल्द ही एक एपीआई प्रस्ताव भेजने की योजना बना रहा हूं। इस तरह के एपीआई का हैशकोड या हैशकोड हेल्पर प्रकार से थोड़ा अलग उपयोग होता है, लेकिन चर्चा के लिए, मान लें कि हम उन अंतरों को दूर कर सकते हैं। यदि हम GetHashCode के लिए उस API का उपयोग करते हैं:
   
   
   
   • उत्पन्न कोड स्पष्ट है कि यह क्या कर रहा है - यदि रोसलिन Marvin32.Create(); उत्पन्न करता है, तो यह बिजली उपयोगकर्ताओं को यह जानने देता है कि उसने क्या करने का निर्णय लिया है और वे इसे आसानी से सूट में किसी अन्य एल्गोरिदम में बदल सकते हैं यदि वे चाहें।
   
   
   • इसका मतलब है कि हमें परिवर्तनों को तोड़ने के बारे में चिंता करने की ज़रूरत नहीं है। यदि हम एक गैर-यादृच्छिक/खराब एन्ट्रापी/धीमी एल्गोरिथ्म के साथ शुरू करते हैं, तो हम नए कोड में कुछ और उत्पन्न करना शुरू करने के लिए बस रोसलिन को अपडेट कर सकते हैं। पुराना कोड पुराने हैश का उपयोग करता रहेगा और नया कोड नए हैश का उपयोग करेगा। डेवलपर्स (या रोसलिन कोड फिक्स) यदि चाहें तो पुराने कोड को बदल सकते हैं।
   
   
   • सबसे बड़ा नकारात्मक पहलू जो मैं सोच सकता हूं वह यह है कि GetHashCode के लिए हम जो कुछ अनुकूलन चाहते हैं, वे अन्य एल्गोरिदम के लिए हानिकारक हो सकते हैं। उदाहरण के लिए, जबकि 32-बिट आंतरिक स्थिति अपरिवर्तनीय structs के साथ अच्छी तरह से काम करती है, एक 256-बिट आंतरिक स्थिति (कहना) CityHash कॉपी करने का एक गुच्छा बर्बाद कर सकती है।
   
   

1. रैंडमाइजेशन: एक ठीक से रैंडमाइज्ड एल्गोरिथम के साथ शुरू करें (कोड @CyrusNajmabadi एक यादृच्छिक प्रारंभिक मान के साथ दिखाया गया है, इसकी गणना नहीं की जाती है क्योंकि यह यादृच्छिकता को धोना संभव है)। यह सुनिश्चित करता है कि हम बिना संगतता मुद्दों के कार्यान्वयन को बदल सकते हैं। यदि हम एल्गोरिथम बदलते हैं तो हमें प्रदर्शन परिवर्तनों के बारे में अभी भी बहुत संवेदनशील होने की आवश्यकता होगी। हालाँकि यह एक संभावित उल्टा भी होगा क्योंकि हम प्रति-आर्किटेक्चर (या प्रति-डिवाइस) विकल्प भी बना सकते हैं। उदाहरण के लिए, यह साइट दिखाती है कि xxHash x64 Mac पर सबसे तेज़ है जबकि SpookyHash Xbox और iPhone पर सबसे तेज़ है। यदि हम किसी बिंदु पर एल्गोरिदम को बदलने के इरादे से इस मार्ग से नीचे जाते हैं, तो हमें एक एपीआई डिजाइन करने के बारे में सोचने की आवश्यकता हो सकती है, जिसमें 64+ बिट आंतरिक स्थिति होने पर भी उचित प्रदर्शन हो।

सीसी @bartonjs , @terrajobst

@morganbr एक भी सही एल्गोरिदम नहीं है, लेकिन मुझे लगता है कि कुछ एल्गोरिदम होना, जो ज्यादातर समय काफी अच्छी तरह से काम करता है, एक सरल, समझने में आसान एपीआई का उपयोग करके उजागर किया जा सकता है जो सबसे उपयोगी चीज है। इसके अलावा एल्गोरिदम का एक सूट होना, उन्नत उपयोगों के लिए ठीक है। लेकिन यह एकमात्र विकल्प नहीं होना चाहिए, मुझे यह नहीं सीखना चाहिए कि मार्विन कौन है ताकि मैं अपनी वस्तुओं को Dictionary में डाल सकूं।

मुझे यह जानने की ज़रूरत नहीं है कि मार्विन कौन है ताकि मैं अपनी वस्तुओं को एक शब्दकोश में डाल सकूं।

आप जिस तरह से डालते हैं वह मुझे पसंद है। मुझे यह भी पसंद है कि आपने डिक्शनरी का ही उल्लेख किया है। IDictionary कुछ ऐसा है जिसमें सभी प्रकार के विभिन्न गुणों के साथ कई अलग-अलग इम्प्लांट हो सकते हैं (कई प्लेटफार्मों में संग्रह एपीआई देखें)। हालांकि, हम अभी भी एक आधार 'शब्दकोश' प्रदान करते हैं जो समग्र रूप से एक अच्छा काम करता है, भले ही यह हर श्रेणी में उत्कृष्ट न हो।

मुझे लगता है कि हैशिंग लाइब्रेरी में एक टन लोग यही खोज रहे हैं। कुछ ऐसा जिससे काम हो जाए, भले ही वह हर उद्देश्य के लिए सही न हो।

@morganbr मुझे लगता है कि लोग सरल विशिष्ट हैशिंग कार्यों की तीव्र आवश्यकता है, तो आपके पास उन्नत उपयोगकर्ताओं के लिए एक बैक-द-सीन एपीआई हो सकता है।

दूसरे शब्दों में, आज हैशकोड लिखने वाले लोग यह नहीं जान पाएंगे या परवाह नहीं करेंगे कि वे स्पूकी बनाम मार्विन बनाम मुरमुर क्यों चाहते हैं। केवल कोई व्यक्ति जिसे उन विशिष्ट हैश कोडों में से किसी एक की विशेष आवश्यकता है, वह देखेगा। लेकिन बहुत से लोगों को यह कहने की ज़रूरत है "यहां मेरी वस्तु की स्थिति है, मुझे एक अच्छी तरह से वितरित हैश बनाने का एक तरीका प्रदान करें जो तेज़ है कि मैं फिर शब्दकोशों के साथ उपयोग कर सकता हूं, और जो मुझे लगता है कि अगर मैं होता हूं तो मुझे डॉस होने से रोकता है अविश्वसनीय इनपुट लेने के लिए और इसे हैश करें और इसे स्टोर करें"।

@CyrusNajmabadi समस्या यह है कि यदि हम भविष्य में संगतता की अपनी वर्तमान धारणाओं का विस्तार करते हैं तो हम पाते हैं कि एक बार इस प्रकार के जहाजों को यह कभी भी नहीं बदल सकता है (जब तक कि हम यह नहीं पाते कि एल्गोरिदम बुरी तरह से टूटा हुआ है "यह सभी अनुप्रयोगों को हमला करने योग्य बनाता है" तरीके से )

एक बार यह तर्क दे सकता है कि यदि यह स्थिर-यादृच्छिक तरीके से शुरू होता है तो कार्यान्वयन को बदलना आसान हो जाता है, क्योंकि आप किसी भी तरह से चलाने के लिए मूल्य पर निर्भर नहीं हो सकते। लेकिन अगर कुछ साल बाद हम पाते हैं कि एक एल्गोरिदम है जो बेहतर-इन-द-सामान्य केस प्रदर्शन के साथ हैश बाल्टी के बेहतर संतुलन के रूप में अच्छा-अगर-बेहतर संतुलन प्रदान करता है, लेकिन एक सूची को शामिल करता है \

मॉर्गन के सुझाव के तहत यह है कि आज आप जो कोड लिखते हैं, उसमें हमेशा के लिए समान प्रदर्शन विशेषताएँ प्रभावी रूप से होंगी। जो एप्लिकेशन बेहतर हो सकते थे, उनके लिए यह दुर्भाग्यपूर्ण है। उन अनुप्रयोगों के लिए जो खराब हो गए होंगे, यह शानदार है। लेकिन जब हमें नया एल्गोरिथम मिल जाता है तो हम उसकी जांच करवा लेते हैं, और हम रोजलिन को बदल देते हैं (और ReSharper/आदि में बदलाव का सुझाव देते हैं) ताकि कुछ चीजें NewAwesomeThing2019 के बजाय SomeThingThatWasConsideredAwesomeIn2018 के साथ चीजें उत्पन्न करना शुरू कर सकें।

इस तरह का कोई भी सुपर ब्लैक बॉक्स केवल एक बार ही किया जा सकता है। और फिर हम इसके साथ हमेशा के लिए फंस गए हैं। फिर कोई अगला लिखता है, जिसका औसत प्रदर्शन बेहतर होता है, इसलिए दो ब्लैक बॉक्स कार्यान्वयन हैं जिन्हें आप नहीं जानते कि आप उनके बीच क्यों चुनेंगे। और फिर... और फिर....

तो, निश्चित रूप से, आप नहीं जानते होंगे कि क्यों Roslyn/ReSharper/etc ने आपके लिए Marvin32, या Murmur, या FastHash, या IntPtr.Size पर आधारित संयोजन/सशर्त का उपयोग करके GetHashCode को ऑटो-लिखा। लेकिन आपके पास इसे देखने की शक्ति है। और आपके पास बाद में इसे अपने प्रकारों में बदलने की शक्ति है, क्योंकि नई जानकारी सामने आती है... लेकिन हमने आपको इसे वही रखने की शक्ति भी दी है। (अगर हम इसे लिखते हैं तो यह दुखद होगा, और 3 वर्षों में रोसलिन/रीशेर्पर/आदि स्पष्ट रूप से इसे कॉल करने से बच रहे हैं, क्योंकि नया एल्गोरिदम इतना बेहतर है ... आमतौर पर)।

@bartonjs क्या हैशिंग को उन सभी जगहों से अलग बनाता है जहां .Net आपको ब्लैक बॉक्स एल्गोरिथम या डेटा संरचना प्रदान करता है? उदाहरण के लिए, छँटाई (परिचय), Dictionary (सरणी-आधारित अलग श्रृखंला), StringBuilder (8k विखंडू की लिंक्ड सूची), अधिकांश LINQ।

हमने आज इस पर गहराई से विचार किया है। इस मुद्दे पर देरी और आगे और पीछे के लिए खेद है।

आवश्यकताएं

• एपीआई किसके लिए है?
  
  
  
  • एपीआई को एक मजबूत क्रिप्टोग्राफिक हैश उत्पन्न करने की आवश्यकता नहीं है
  
  
  • लेकिन: एपीआई को पर्याप्त रूप से अच्छा होना चाहिए ताकि हम इसे ढांचे में ही उपयोग कर सकें (उदाहरण के लिए बीसीएल और एएसपी.नेट में)
  
  
  • हालांकि, इसका मतलब यह नहीं है कि हमें हर जगह एपीआई का इस्तेमाल करना होगा। यह ठीक है अगर एफएक्स के कुछ हिस्से हैं जहां हम सुरक्षा/डॉस जोखिमों के लिए या प्रदर्शन के कारण एक कस्टम का उपयोग करना चाहते हैं। अपवाद हमेशा मौजूद रहेंगे ।
  
  
• इस हैश के वांछित गुण क्या हैं?
  
  
  
  • इनपुट में सभी बिट्स का उपयोग किया जाता है
  
  
  • परिणाम अच्छी तरह से वितरित किया गया है
  
  
  • एपीआई "ए" हैश कोड प्रदान करेगा, लेकिन किसी विशेष हैश कोड एल्गोरिदम की गारंटी नहीं देगा। यह हमें बाद में एक अलग एल्गोरिदम का उपयोग करने या विभिन्न आर्किटेक्चर पर विभिन्न एल्गोरिदम का उपयोग करने की अनुमति देता है।
  
  
  • एपीआई गारंटी देगा कि किसी दी गई प्रक्रिया के भीतर समान मान समान हैश कोड प्राप्त करेंगे। रैंडमाइजेशन के कारण एक ही ऐप के अलग-अलग इंस्टेंस अलग-अलग हैश कोड पैदा कर सकते हैं। यह हमें यह सुनिश्चित करने की अनुमति देता है कि उपभोक्ता हैश मूल्यों को जारी नहीं रख सकते हैं और गलती से उन पर रनों (या इससे भी बदतर, प्लेटफॉर्म के संस्करण) के स्थिर होने पर भरोसा करते हैं।
  
  

एपीआई आकार

```सी#
// कोर असेंबली में रहेंगे
// .NET फ्रेमवर्क: mscorlib
// .NET कोर: System.Runtime / System.Private.CoreLib
नेमस्पेस सिस्टम
{
सार्वजनिक संरचना हैशकोड
{
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान १);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4, T5 मान5);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4, T5 मान5, T6 मान 6);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4, T5 मान5, T6 मान6, T7 मान7);
सार्वजनिक स्थैतिक इंट कम्बाइन(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);
}

अधिक जटिल मामला तब होता है जब डेवलपर को हैश की गणना कैसे की जा रही है, इसे ट्विक करने की आवश्यकता होती है। विचार यह है कि कॉल साइट वांछित हैश पास करती है बल्कि वस्तु/मान, जैसे:

```सी#
सार्वजनिक आंशिक वर्ग ग्राहक
{
सार्वजनिक ओवरराइड int GetHashCode () =>
हैशकोड। कॉम्बाइन (
पहचान,
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();
    }
}

अगला कदम

यह मसला अधर में लटका रहेगा। एपीआई को लागू करने के लिए हमें यह तय करना होगा कि किस एल्गोरिदम का उपयोग करना है।

@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 या उससे कम ints को हैंडल करेगा, स्टार्टअप समय थ्रूपुट से अधिक महत्वपूर्ण हो सकता है। इस साइट में शुरू करने के लिए डेटा का एक दिलचस्प सेट है। यह वह जगह भी है जहां हमें विभिन्न आर्किटेक्चर या अन्य पिवोट्स (ओएस, एओटी बनाम जेआईटी, आदि) के लिए अलग-अलग उत्तरों की आवश्यकता हो सकती है।

हम वास्तव में C# में लिखे गए उम्मीदवारों के लिए प्रदर्शन संख्या देखना चाहते हैं ताकि हम यथोचित रूप से आश्वस्त हो सकें कि उनकी विशेषताएं .NET के लिए बनी रहेंगी। यदि आप एक उम्मीदवार लिखते हैं और हम इसे इसके लिए नहीं चुनते हैं, तो यह तब भी उपयोगी काम होगा जब मुझे वास्तव में गैर-क्रिप्टोग्राफिक हैश एपीआई के लिए एपीआई प्रस्ताव एक साथ मिलेगा।

यहाँ कुछ उम्मीदवार हैं जो मुझे लगता है कि मूल्यांकन के लायक हैं (लेकिन दूसरों को प्रस्तावित करने के लिए स्वतंत्र महसूस करें):

• मार्विन 32 (हमारे पास पहले से ही सी # कार्यान्वयन है )। हम जानते हैं कि यह String.GetHashCode के लिए पर्याप्त तेज़ है और हमें विश्वास है कि यह HashDoS प्रतिरोधी है
• xxHash32 ( यहाँ x86 पर एल्गोरिथम पर सबसे तेज़ जिसमें SMHasher के अनुसार उच्च गुणवत्ता है)
• फार्महैश ( यहां x64 पर सबसे तेज। मुझे इसके लिए गुणवत्ता का कोई अच्छा संकेतक नहीं मिला है। हालांकि इसे सी # में लिखना मुश्किल हो सकता है)
• xxHash64 (32 बिट्स तक छोटा) (यह एक स्पष्ट गति विजेता नहीं है, लेकिन अगर हमारे पास पहले से ही xxHash32 है तो यह करना आसान हो सकता है)
• स्पूकीहैश (बड़े डेटा सेट पर अच्छा प्रदर्शन करता है)

शर्म की बात है Add विधियों में ref HashCode का रिटर्न प्रकार नहीं हो सकता है और ref this कर सकते हैं ताकि उनका उपयोग धाराप्रवाह तरीके से किया जा सके,

क्या readonly ref रिटर्न इसकी अनुमति देगा? /सीसी @jaredpar @VSadov

चेतावनी: यदि कोई इंटरनेट पर कहीं मौजूदा कोड बेस से हैश कार्यान्वयन चुनता है, तो कृपया स्रोत का लिंक रखें और लाइसेंस की जांच करें (हमें इसे भी करना होगा)।

यदि लाइसेंस संगत नहीं है, तो हमें नए सिरे से एल्गोरिथम लिखने की आवश्यकता हो सकती है।

आईएमओ, ऐड विधियों का उपयोग करना बेहद असामान्य होना चाहिए। यह बहुत उन्नत परिदृश्यों के लिए होगा, और 'धाराप्रवाह' होने में सक्षम होने की आवश्यकता वास्तव में नहीं होगी।

सभी उपयोगकर्ता कोड मामलों के 99% के लिए सामान्य उपयोग के मामलों के लिए, किसी को => HashCode.Combine(...) और ठीक होने में सक्षम होना चाहिए।

@morganbr

हम public static int Combine<T1>(T1 value); भी चाह सकते हैं। मुझे पता है कि यह थोड़ा अजीब लग रहा है, लेकिन यह सीमित इनपुट हैश स्पेस के साथ कुछ से बिट्स को फैलाने का एक तरीका प्रदान करेगा

सही बात। मैंने इसे जोड़ा है।

@justinvp

Nit: StringComparison पैरामीटर को comparisonType नाम दिया जाना चाहिए ताकि हर जगह इस्तेमाल किए गए नामकरण से मेल खाने के लिए StringComparison पैरामीटर के रूप में उपयोग किया जा सके।

फिक्स्ड।

@CyrusNajmabadi

आईएमओ, Add विधियों का उपयोग करना बेहद असामान्य होना चाहिए। यह बहुत उन्नत परिदृश्यों के लिए होगा, और 'धाराप्रवाह' होने में सक्षम होने की आवश्यकता वास्तव में नहीं होगी।

माना।

@benaadams - पुन: रेफरी this से Add लौटा रहा है - नहीं, this संरचना विधियों में रेफरी द्वारा वापस नहीं किया जा सकता है क्योंकि यह एक rValue या एक अस्थायी हो सकता है।

```सी#
रेफरी वर आर = (नया टी ())। रिटर्न्सरेफ यह ();

// r यहाँ कुछ चर को संदर्भित करता है। कौनसा? दायरा/जीवनकाल क्या है?
आर = कुछ और ();
```

यदि यह तुलनात्मक उद्देश्यों के लिए उपयोगी है, तो कुछ साल पहले मैंने जेनकिंस लुकअप 3 हैश फ़ंक्शन ( सी स्रोत ) को सी # यहां पोर्ट किया था।

मैं संग्रह के बारे में सोच रहा हूँ:

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

यदि जोड़ें एक शक्ति परिदृश्य है, तो क्या हमें यह मान लेना चाहिए कि उपयोगकर्ता को 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() को ऑब्जेक्ट का हैश कोड वापस करना चाहिए, लेकिन क्या कोई कारण है कि दो हैश कोड अलग होने चाहिए? यह अभी भी सही है, क्योंकि के दो उदाहरणों HashCode एक ही आंतरिक स्थिति के साथ से समान परिणाम प्रदान करेंगे 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 का नाम बदल दिया। मैंने byte ओवरलोड को हटा दिया क्योंकि अगर हमें बाइट-विशिष्ट कुछ भी करने की ज़रूरत है तो हम विधि के अंदर typeof(T) == typeof(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 यदि

:+1:

@terrajobst क्या हम HashCode -> int से एक अंतर्निहित रूपांतरण करने के लिए वापस जा सकते हैं, इसलिए कोई ToHashCode विधि नहीं है? संपादित करें: ToHashCode ठीक है। नीचे देखें @CyrusNajmabadi की प्रतिक्रिया।

@jamesqo StringComparison एक एनम है।
हालांकि, लोग इसके बजाय समतुल्य StringComparer उपयोग कर सकते हैं।

क्या हम हैशकोड -> int से एक अंतर्निहित रूपांतरण करने के लिए वापस जा सकते हैं, इसलिए कोई ToHashCode विधि नहीं है?

हमने इस पर चर्चा की और बैठक में इसके खिलाफ फैसला किया। मुद्दा यह है कि जब उपयोगकर्ता को अंतिम 'इंट' मिलता है तो अतिरिक्त काम अक्सर किया जाता है। यानी हैशकोड के आंतरिक भाग अक्सर अंतिम रूप देने का कदम उठाते हैं, और खुद को एक नई स्थिति में रीसेट कर सकते हैं। एक निहित रूपांतरण के साथ ऐसा होना अजीब होगा। यदि आपने ऐसा किया है:

HashCode hc = ...

int i1 = hc;
int i2 = hc;

तब आप अलग-अलग परिणाम प्राप्त कर सकते थे।

इस कारण से, हमें स्पष्ट रूपांतरण भी पसंद नहीं है (क्योंकि लोग रूपांतरणों को आंतरिक स्थिति बदलने के रूप में नहीं समझते हैं)।

एक विधि के साथ हम स्पष्ट रूप से दस्तावेज कर सकते हैं कि यह हो रहा है। हम इसे अधिक से अधिक संप्रेषित करने के लिए संभावित रूप से नाम भी दे सकते हैं। यानी "ToHashCodeAndReset" (हालांकि हमने इसके खिलाफ फैसला किया)। लेकिन कम से कम विधि में स्पष्ट दस्तावेज हो सकते हैं कि एचटीई उपयोगकर्ता इंटेलिजेंस जैसी चीजों में देख सकता है। वास्तव में रूपांतरण के मामले में ऐसा नहीं है।

मैंने बाइट ओवरलोड को हटा दिया क्योंकि हम typeof(T) == typeof(byte) का उपयोग करने में विशेषज्ञ हो सकते हैं

आईआईआरसी जेआईटी के नजरिए से इसके ठीक नहीं होने के बारे में कुछ चिंता थी। लेकिन यह केवल गैर-मूल्य-प्रकार "टाइपोफ़ ()" मामलों के लिए हो सकता है। जब तक जिट मूल्य-प्रकार टाइपोफ़ () मामलों के लिए प्रभावी ढंग से सही काम करेगा, तब तक यह अच्छा होना चाहिए।

@CyrusNajmabadi मैं इस बात से अनजान था कि int रूपांतरण में परिवर्तनशील स्थिति शामिल हो सकती है। ToHashCode यह तब है।

क्रिप्टो परिप्रेक्ष्य के बारे में सोचने वालों के लिए - http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf

@terrajobst , क्या आपके पास मेरी टिप्पणियों को पढ़ने का समय है ( यहां से शुरू करके) और तय करें कि क्या आप संशोधित एपीआई आकार को स्वीकार करते हैं? यदि ऐसा है, तो मुझे लगता है कि इसे पकड़ने के लिए एपीआई-अनुमोदित/अप चिह्नित किया जा सकता है और हम हैश एल्गोरिदम पर निर्णय लेना शुरू कर सकते हैं।

@blowdart , इसका कोई विशेष भाग जिसे आप हाइलाइट करना चाहते हैं?

मैं ऊपर इसके बारे में बहुत स्पष्ट नहीं हो सकता था, लेकिन केवल गैर-क्रिप्टोग्राफिक हैश जो मुझे हैशडॉस ब्रेक के बारे में नहीं पता है, वे मार्विन और सिपहाश हैं। यही है, यहां तक ​​​​कि एक यादृच्छिक मूल्य के साथ बड़बड़ाहट (कहते हैं) को अभी भी तोड़ा जा सकता है और एक DoS के लिए उपयोग किया

कोई नहीं, मैंने अभी इसे दिलचस्प पाया है, और मैं सोच रहा हूं कि इसके लिए दस्तावेज़ों को "क्रिप्टोग्राफ़िक एल्गोरिदम के माध्यम से जेनरेट किए गए हैश कोड पर उपयोग के लिए नहीं" कहना चाहिए।

फैसले

• हमें सभी AddRange विधियों को हटा देना चाहिए क्योंकि परिदृश्य अस्पष्ट है। ऐरे कुछ हद तक अक्सर दिखने की संभावना नहीं है। और एक बार बड़े सरणी शामिल हो जाने के बाद, सवाल यह है कि क्या गणना को कैश किया जाना चाहिए। कॉलिंग साइड पर लूप के लिए देखने से यह स्पष्ट हो जाता है कि आपको इसके बारे में सोचने की जरूरत है।
• हम IEnumerable ओवरलोड को AddRange भी नहीं जोड़ना चाहते क्योंकि वे आवंटित किए जाएंगे।
• हमें नहीं लगता कि हमें Add अधिभार की आवश्यकता है जो string और StringComparison लेता है। हां, वे IEqualityComparer माध्यम से कॉल करने की तुलना में अधिक कुशल हैं, लेकिन हम इसे बाद में ठीक कर सकते हैं।
• हमें लगता है कि GetHashCode को त्रुटि के साथ अप्रचलित के रूप में चिह्नित करना एक अच्छा विचार है, लेकिन हम एक कदम और आगे बढ़ेंगे और IntelliSense से भी छिप जाएंगे।

यह हमें छोड़ देता है:

```सी#
// कोर असेंबली में रहेंगे
// .NET फ्रेमवर्क: mscorlib
// .NET कोर: System.Runtime / System.Private.CoreLib
नेमस्पेस सिस्टम
{
सार्वजनिक संरचना हैशकोड
{
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान १);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4, T5 मान5);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4, T5 मान5, T6 मान 6);
सार्वजनिक स्थैतिक इंट कम्बाइन(T1 मान1, T2 मान2, T3 मान3, T4 मान4, T5 मान5, T6 मान6, T7 मान7);
सार्वजनिक स्थैतिक इंट कम्बाइन(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 देखें, ताकि हम तय कर सकें कि कौन सा एल्गोरिदम लेना है (थ्रूपुट और वितरण माप के आधार पर, प्रति सीपीयू आर्किटेक्चर के अलग-अलग उत्तर)।

जटिलता: बड़ा

अगर कोई इसे लेने में दिलचस्पी रखता है, तो कृपया हमें पिंग करें। इसमें एक साथ काम करने वाले कई लोगों के लिए भी जगह हो सकती है। ( @jamesqo आपके पास प्राथमिकता का विकल्प है क्योंकि आपने इस मुद्दे में सबसे अधिक और सबसे लंबा निवेश किया है)

@karelz ऊपर मेरी टिप्पणी के बावजूद, मैंने अपना विचार बदल दिया है क्योंकि मुझे नहीं लगता कि मेरे पास सर्वश्रेष्ठ हैश एल्गोरिदम चुनने की योग्यता है। मैंने सूचीबद्ध कुछ पुस्तकालयों @morganbr में देखा और महसूस किया कि कार्यान्वयन काफी जटिल है , इसलिए मैं इसे अपने लिए परीक्षण करने के लिए आसानी से सी # में अनुवाद नहीं कर सकता। मेरे पास सी ++ में बहुत कम पृष्ठभूमि है, इसलिए मुझे पुस्तकालय स्थापित करने और एक परीक्षण ऐप लिखने में भी मुश्किल होगी।

मैं नहीं चाहता कि यह हमेशा के लिए अप-फॉर-ग्रैब्स सूची में बना रहे, हालांकि। अगर आज से एक सप्ताह तक कोई नहीं लेता है, तो मैं प्रोग्रामर एसई या रेडिट पर एक प्रश्न पोस्ट करने पर विचार करूंगा।

मैंने इसका खंडन नहीं किया है (या अन्यथा इसे अनुकूलित किया है), लेकिन यहाँ Murmur3 हैश एल्गोरिथ्म का एक बुनियादी कार्यान्वयन है जिसका उपयोग मैं अपनी कई व्यक्तिगत परियोजनाओं में करता हूँ: https://gist.github.com/tannergooding/0a12559d1a912068b9aeb4b9586aad7f

मुझे लगता है कि यहां सबसे इष्टतम समाधान इनपुट डेटा के आकार के आधार पर हैशिंग एल्गोरिदम को गतिशील रूप से बदलना होगा।

उदाहरण: Mumur3 (और अन्य) डेटा के बड़े सेट के लिए बहुत तेज़ हैं और महान वितरण प्रदान करते हैं, लेकिन वे डेटा के छोटे सेट के लिए 'खराब' (गति के अनुसार, वितरण के अनुसार नहीं) प्रदर्शन कर सकते हैं।

मुझे लगता है कि हमें कुछ ऐसा करना चाहिए: यदि समग्र बाइट गिनती एक्स से कम है, तो एल्गोरिदम ए करें; अन्यथा, एल्गोरिथम बी करें। यह अभी भी नियतात्मक (प्रति रन) होगा, लेकिन हमें इनपुट डेटा के वास्तविक आकार के आधार पर गति और वितरण प्रदान करने की अनुमति देगा।

यह शायद यह भी ध्यान देने योग्य है कि उल्लिखित कई एल्गोरिदम में विशेष रूप से SIMD निर्देशों के लिए डिज़ाइन किए गए कार्यान्वयन हैं, इसलिए सबसे अधिक प्रदर्शन करने वाले समाधान में कुछ स्तर पर FCALL शामिल होने की संभावना है (जैसे कि कुछ बफ़रकॉपी कार्यान्वयन के साथ किया जाता है) या इसमें निर्भरता लेना शामिल हो सकता है System.Numerics.Vector ।

@jamesqo , हमें चुनाव करने में मदद करने में खुशी हो रही है; उम्मीदवार कार्यान्वयन के लिए प्रदर्शन डेटा के साथ हमें सबसे अधिक सहायता की आवश्यकता है (आदर्श रूप से सी #, हालांकि @tannergooding बताते हैं, कुछ एल्गोरिदम को विशेष कंपाइलर समर्थन की आवश्यकता होती है)। जैसा कि मैंने ऊपर उल्लेख किया है, यदि आप एक ऐसे उम्मीदवार का निर्माण करते हैं जिसे चुना नहीं गया है, तो हम शायद बाद में इसका उपयोग करेंगे, इसलिए काम बर्बाद होने की चिंता न करें।

मुझे पता है कि विभिन्न कार्यान्वयन के लिए बेंचमार्क हैं, लेकिन मुझे लगता है कि इस एपीआई और इनपुट की संभावित सीमा (उदाहरण के लिए 1-10 फ़ील्ड वाले स्ट्रक्चर) का उपयोग करके तुलना करना महत्वपूर्ण है।

@tannergooding , उस तरह की अनुकूलन क्षमता सबसे अधिक प्रदर्शन करने वाली हो सकती है, लेकिन मुझे नहीं लगता कि यह ऐड विधि के साथ कैसे काम करेगा क्योंकि यह नहीं जानता कि इसे कितनी बार कॉल किया जाएगा। जबकि हम इसे कम्बाइन के साथ कर सकते हैं, इसका मतलब यह होगा कि ऐड कॉल्स की एक श्रृंखला संबंधित कंबाइन कॉल की तुलना में एक अलग परिणाम उत्पन्न कर सकती है।

साथ ही, यह देखते हुए कि इनपुट की सबसे संभावित सीमा 4-32 बाइट्स ( Combine`1 - Combine`8 ) है, उम्मीद है कि उस सीमा पर बड़े प्रदर्शन परिवर्तन नहीं होंगे।

उस तरह की अनुकूलन क्षमता सबसे अधिक प्रदर्शन करने वाली हो सकती है, लेकिन मैं यह नहीं देखता कि यह ऐड विधि के साथ कैसे काम करेगा क्योंकि यह नहीं जानता कि इसे कितनी बार कॉल किया जाएगा।

मैं व्यक्तिगत रूप से आश्वस्त नहीं हूं कि एपीआई आकार सामान्य उद्देश्य हैशिंग के लिए बिल्कुल सही है (हालांकि यह करीब है) ...

वर्तमान में हम स्थैतिक निर्माण के लिए Combine विधियों को उजागर कर रहे हैं। यदि ये सभी इनपुट को संयोजित करने और एक अंतिम हैश कोड तैयार करने के लिए हैं, तो नाम 'खराब' है और Compute जैसा कुछ अधिक उपयुक्त हो सकता है।

यदि हम Combine विधियों को उजागर कर रहे हैं, तो उन्हें केवल सभी इनपुट को मिलाना चाहिए और उपयोगकर्ताओं को Finalize विधि को कॉल करने की आवश्यकता होनी चाहिए जो अंतिम संयोजन के साथ-साथ बाइट्स की कुल संख्या से आउटपुट लेती है एक अंतिम हैश कोड बनाने के लिए संयुक्त (हैश कोड को अंतिम रूप देना महत्वपूर्ण है क्योंकि यह बिट्स हिमस्खलन का कारण बनता है)।

बिल्डर पैटर्न के लिए, हम एक Add और ToHashCode पद्धति को उजागर कर रहे हैं। यह स्पष्ट नहीं है कि Add विधि बाइट्स को स्टोर करने के लिए है और केवल ToHashCode पर कॉल को संयोजित/अंतिम रूप देने के लिए है (जिस स्थिति में हम गतिशील रूप से सही एल्गोरिदम चुन सकते हैं) या यदि वे हैं फ्लाई पर संयुक्त होने का मतलब है, यह स्पष्ट होना चाहिए कि यह मामला है (और कार्यान्वयन आंतरिक रूप से बाइट्स के कुल आकार को संयुक्त रूप से ट्रैक करना चाहिए)।

कम जटिल शुरुआती बिंदु की तलाश करने वाले किसी भी व्यक्ति के लिए, xxHash32 आज़माएं। यह बहुत आसानी से सी # में अनुवाद करने की संभावना है ( लोगों ने इसे किया है )।

अभी भी स्थानीय रूप से परीक्षण कर रहा हूं, लेकिन मैं अपने सी # मुरमुर 3 के कार्यान्वयन के लिए निम्नलिखित थ्रूपुट दरें देख रहा हूं।

ये 1-8 इनपुट के लिए स्थिर कंबाइन विधियों के लिए हैं:

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 पुनरावृत्तियों को चलाया, पहले पुनरावृत्ति को 'वार्मअप' रन के रूप में फेंक दिया।

प्रत्येक पुनरावृत्ति में, मैं 10,000 उप-पुनरावृत्तियों को चलाता हूं जहां मैं HashCode.Combine कॉल करता हूं, पिछले उप-पुनरावृत्ति के परिणाम को अगले पुनरावृत्ति में पहले इनपुट मान के रूप में पास करता हूं।

मैं तब औसत बीता हुआ समय प्राप्त करने के लिए सभी पुनरावृत्तियों को औसत करता हूं, आगे विभाजित करता हूं कि प्रति कॉल औसत समय प्राप्त करने के लिए प्रति लूप चलाने वाले उप-पुनरावृत्तियों की संख्या से। फिर मैं प्रति सेकंड कॉल की संख्या की गणना करता हूं और वास्तविक थ्रूपुट की गणना करने के लिए संयुक्त बाइट्स की संख्या से गुणा करता हूं।

कोड को साफ करेंगे और इसे थोड़ा सा साझा करेंगे।

@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

दोनों ही मामलों में, डेटा को एक ही आंतरिक हैश स्थिति में फीड किया जाना चाहिए और हैश को अंत में एक बार अंतिम रूप दिया जाना चाहिए।

मैं

मैंने जो कोड लिखा है वह प्रभावी रूप से कर रहा है। केवल अंतर यह है कि मैं सभी कोड को प्रभावी ढंग से इनलाइन करता हूं ( new HashCode() आवंटित करने की कोई आवश्यकता नहीं है और यह स्थिर होने के बाद से संयुक्त बाइट्स की संख्या को ट्रैक करता है)।

@morganbr. मुरमुर3 के लिए कार्यान्वयन + थ्रूपुट परीक्षण: https://gist.github.com/tannergooding/89bd72f05ab772bfe5ad3a03d6493650

MurmurHash3 यहां वर्णित एल्गोरिदम पर आधारित है: https://github.com/aappleby/smhasher/wiki/MurmurHash3 , रेपो का कहना है कि यह एमआईटी है

xxHash32 (BSD-2 क्लॉज - https://github.com/Cyan4973/xxHash/blob/dev/xxhash.c) और SpookyHash (पब्लिक डोमेन - http://www.burtleburtle.net/bob/hash) पर काम करना /spooky.html) वेरिएंट

@tannergooding फिर से, हैश विशेषज्ञ नहीं, लेकिन मुझे याद आया [एक लेख पढ़ना] [१] जिसमें कहा गया था कि मुरमुर डीओएस-प्रतिरोधी नहीं था, इसलिए इसे चुनने से पहले इसे इंगित करें।

@jamesqo , मैं गलत हो सकता हूं, लेकिन मुझे पूरा यकीन है कि भेद्यता मुरमुर 2 पर लागू होती है न कि मुरमुर 3 पर।

किसी भी मामले में, मैं कई एल्गोरिदम लागू कर रहा हूं ताकि हम सी # के लिए थ्रूपुट परिणाम प्राप्त कर सकें। इन एल्गोरिदम के वितरण और अन्य गुण काफी प्रसिद्ध हैं इसलिए हम चुन सकते हैं और चुन सकते हैं कि बाद में सबसे अच्छा कौन सा है

ओह, लेख को लिंक करना भूल गए: http://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/।

@tannergooding ठीक है। उचित लगता है: +1:

@tannergooding , मैंने आपके मुरमुर 3 कार्यान्वयन पर एक नज़र डाली और यह आम तौर पर सही और शायद बहुत अच्छी तरह अनुकूलित दिखता है। यह सुनिश्चित करने के लिए कि मैं सही ढंग से समझता हूं, क्या आप इस तथ्य का उपयोग कर रहे हैं कि संयुक्त वैल्यू और मुरमुर की आंतरिक स्थिति दोनों 32 बिट हैं? यह शायद इस मामले के लिए एक बहुत अच्छा अनुकूलन है और मेरे पहले के कुछ भ्रम की व्याख्या करता है।

अगर हम इसे अपनाना चाहते हैं, तो इसे कुछ बदलावों की आवश्यकता हो सकती है (हालांकि वे शायद पूर्ण माप में कोई बड़ा अंतर नहीं डालेंगे):

• जोड़नाअभी भी कंबाइनवैल्यू को वैल्यू 1 पर कॉल करना चाहिए
• पहले कंबाइनवैल्यू कॉल को एक यादृच्छिक बीज लेना चाहिए
• ToHashCode को _bytesCombined और _combinedValue रीसेट करना चाहिए

इस बीच, जबकि मैं इस एपीआई के लिए तरस रहा हूं, मेरे लिए (field1, field2, field3).GetHashCode() माध्यम से GetHashCode को लागू करना कितना बुरा है?

@ jnm2 , ValueTuple हैश कोड कॉम्बिनर आपके इनपुट को हैश कोड में क्रम में रखता है (और कम से कम हाल के लोगों को छोड़ दें)। कुछ फ़ील्ड और एक हैश तालिका के लिए जो एक अभाज्य संख्या से विभाजित होती है, आप शायद ध्यान न दें। बहुत सारे फ़ील्ड या एक हैश तालिका के लिए जो दो की शक्ति से विभाजित होती है, आपके द्वारा सम्मिलित किए गए अंतिम फ़ील्ड की एन्ट्रॉपी का इस बात पर सबसे अधिक प्रभाव पड़ेगा कि क्या आपके पास टकराव है (उदाहरण के लिए यदि आपका अंतिम फ़ील्ड बूल या छोटा इंट है, तो आप 'शायद बहुत सारे टकराव होंगे, अगर यह एक गाइड है, तो आप शायद नहीं करेंगे)।

ValueTuple उन फ़ील्ड के साथ भी अच्छी तरह से काम नहीं करता है जो सभी 0 हैं।

एक तरफ ध्यान दें, मुझे अन्य कार्यान्वयन (उच्च प्राथमिकता वाले काम) पर काम करना बंद करना पड़ा। मुझे यकीन नहीं है कि मैं इसे कब वापस ले पाऊंगा।

तो अगर यह संरचित प्रकार के लिए पर्याप्त नहीं है, तो यह टुपल के लिए पर्याप्त क्यों है?

@ jnm2 , यह एक कारण है कि यह सुविधा निर्माण के लायक है - इसलिए हम पूरे ढांचे में घटिया हैश को बदल सकते हैं।

प्रदर्शन और गुणवत्ता विशेषता के साथ हैश फ़ंक्शन की बड़ी तालिका:
https://github.com/leo-yuriev/t1ha

@arespr मुझे लगता है कि टीम हैश फ़ंक्शंस के सी # कार्यान्वयन की तलाश में है। हालांकि साझा करने के लिए धन्यवाद।

@tannergooding क्या आप अभी भी इस मुद्दे को वापस लेने में असमर्थ हैं? यदि ऐसा है तो मैं Reddit/Twitter पर पोस्ट करूंगा कि हम एक हैश विशेषज्ञ की तलाश कर रहे हैं।

संपादित करें: रेडिट पर एक पोस्ट बनाया। https://www.reddit.com/r/csharp/comments/6qsysm/looking_for_hash_expert_to_help_net_core_team/?ref=share&ref_source=link

@jamesqo , मेरी प्लेट में कुछ उच्च प्राथमिकता वाली चीजें हैं और अगले 3 सप्ताह के भीतर इसे प्राप्त करने में सक्षम नहीं होंगे।

साथ ही, वर्तमान माप सीमित होंगे जो हम वर्तमान में सी # में कोड कर सकते हैं, हालांकि, अगर यह एक चीज बन जाती है (https://github.com/dotnet/designs/issues/13), तो माप कुछ हद तक बदल जाएगा ;)

साथ ही, वर्तमान माप सीमित होंगे जो हम वर्तमान में सी # में कोड कर सकते हैं, हालांकि, अगर यह एक चीज बन जाती है (डॉटनेट/डिजाइन # 13), तो माप कुछ हद तक बदल जाएगा;)

यह ठीक है-- एक बार इंट्रिनिक्स उपलब्ध हो जाने पर हम हैश एल्गोरिथम को हमेशा बदल सकते हैं, हैश कोड को इनकैपुलेटिंग/यादृच्छिक बनाना हमें ऐसा करने में सक्षम बनाता है। हम केवल कुछ ऐसा ढूंढ रहे हैं जो अपनी वर्तमान स्थिति में रनटाइम के लिए सर्वोत्तम प्रदर्शन/वितरण ट्रेडऑफ़ प्रदान करता हो।

@jamesqo , मदद करने के लिए लोगों की तलाश के लिए धन्यवाद। हमें किसी ऐसे व्यक्ति के लिए खुशी होगी जो इस पर भी हैश विशेषज्ञ काम नहीं कर रहा है - हमें वास्तव में किसी ऐसे व्यक्ति की आवश्यकता है जो कुछ एल्गोरिदम को अन्य भाषाओं या डिज़ाइनों से सी # में पोर्ट कर सके और फिर प्रदर्शन माप कर सके। एक बार जब हम उम्मीदवार चुन लेते हैं, तो हमारे विशेषज्ञ वही करेंगे जो हम किसी भी बदलाव पर करते हैं -- शुद्धता, प्रदर्शन, सुरक्षा आदि के लिए कोड की समीक्षा करें।

नमस्ते! मैंने अभी चर्चा के माध्यम से पढ़ा है, और कम से कम मुझे ऐसा लगता है कि मामला murmur3-32 PoC के पक्ष में दृढ़ता से बंद हो गया है। कौन सा BTW मेरे लिए एक बहुत अच्छा विकल्प लगता है, और मैं किसी और अनावश्यक काम को खर्च नहीं करने की सलाह दूंगा (लेकिन शायद .Add() सदस्यों को भी छोड़ दें ...)

लेकिन संभावना नहीं है कि कोई व्यक्ति अधिक प्रदर्शन कार्य जारी रखना चाहता है, मैं xx32, xx64, hsip13/24, सीहैश, murmur3-x86/32 (और मैंने ऊपर से marvin32 impl को एकीकृत किया) के लिए कुछ कोड प्रदान कर सकता है, और (अभी तक) अडॉप्टिमाइज्ड) सिप13/24, स्पूकीव2. जरूरत पड़ने पर शहर के कुछ संस्करण बंदरगाह के लिए काफी आसान लगते हैं। उस आधे-छोड़े गए प्रोजेक्ट के दिमाग में थोड़ा अलग उपयोग-मामला था, इसलिए प्रस्तावित एपीआई के साथ कोई हैशकोड क्लास नहीं है; लेकिन बेंचमार्किंग के लिए यह ज्यादा मायने नहीं रखना चाहिए।

निश्चित रूप से उत्पादन के लिए तैयार नहीं: कोड कॉपी-पास्ता, आक्रामक-इनलाइन के कैंसरयुक्त फैलाव और असुरक्षित जैसे क्रूर-बल की उदार मात्रा को लागू करता है; अंतहीनता मौजूद नहीं है, न ही असंरेखित पढ़ता है। यहां तक ​​​​कि रेफ-इम्प्ल टेस्ट-वैक्टर के खिलाफ परीक्षण भी व्यंजनापूर्ण रूप से "अपूर्ण" बोल रहे हैं।

अगर यह किसी भी तरह की मदद है, तो मुझे अगले दो हफ्तों के दौरान सबसे गंभीर मुद्दों को ठीक करने के लिए पर्याप्त समय मिलना चाहिए, और कोड और कुछ प्रारंभिक परिणाम उपलब्ध कराने चाहिए।

@gimpf

मैंने अभी चर्चा के माध्यम से पढ़ा है, और कम से कम मुझे ऐसा लगता है कि मामला murmur3-32 PoC के पक्ष में दृढ़ता से बंद हो गया है। कौन सा BTW मेरे लिए एक बहुत अच्छा विकल्प लगता है, और मैं अनुशंसा करता हूं कि कोई और अनावश्यक काम खर्च न करें

नहीं, लोग अभी तक Murmur3 का पक्ष नहीं ले रहे हैं। हम यह सुनिश्चित करना चाहते हैं कि हम प्रदर्शन/वितरण के बीच संतुलन के मामले में पूर्ण सर्वश्रेष्ठ एल्गोरिदम चुन रहे हैं, इसलिए हम कोई कसर नहीं छोड़ सकते हैं।

लेकिन संभावना नहीं है कि कोई व्यक्ति अधिक प्रदर्शन कार्य जारी रखना चाहता है, मैं xx32, xx64, hsip13/24, सीहैश, murmur3-x86/32 (और मैंने ऊपर से marvin32 impl को एकीकृत किया) के लिए कुछ कोड प्रदान कर सकता है, और (अभी तक) अडॉप्टिमाइज्ड) सिप13/24, स्पूकीव2. जरूरत पड़ने पर शहर के कुछ संस्करण बंदरगाह के लिए काफी आसान लगते हैं।

जी बोलिये! हम परीक्षण करने के लिए अधिक से अधिक एल्गोरिदम के लिए कोड एकत्र करना चाहते हैं। आपके द्वारा योगदान किया जा सकने वाला प्रत्येक नया एल्गोरिथम मूल्यवान है। यदि आप सिटी एल्गोरिदम को भी पोर्ट कर सकते हैं तो इसकी बहुत सराहना की जाएगी।

निश्चित रूप से उत्पादन के लिए तैयार नहीं: कोड कॉपी-पास्ता, आक्रामक-इनलाइन के कैंसरयुक्त फैलाव और असुरक्षित जैसे क्रूर-बल की उदार मात्रा को लागू करता है; अंतहीनता मौजूद नहीं है, न ही असंरेखित पढ़ता है। यहां तक ​​​​कि रेफ-इम्प्ल टेस्ट-वैक्टर के खिलाफ परीक्षण भी व्यंजनापूर्ण रूप से "अपूर्ण" बोल रहे हैं।

ठीक है। बस कोड अंदर लाएं, और जरूरत पड़ने पर कोई और इसे ढूंढ सकता है।

अगर यह किसी भी तरह की मदद है, तो मुझे अगले दो हफ्तों के दौरान सबसे गंभीर मुद्दों को ठीक करने के लिए पर्याप्त समय मिलना चाहिए, और कोड और कुछ प्रारंभिक परिणाम उपलब्ध कराने चाहिए।

हाँ यह बहुत अच्छा होगा!

@jamesqo ठीक है, मेरे पास दिखाने के लिए कुछ होने के बाद मैं एक नोट छोड़ दूंगा।

@gimpf जो वास्तव में बहुत अच्छा लगता है और जैसे ही आप जाते हैं हमें आपकी प्रगति के बारे में सुनना अच्छा लगेगा (जब तक आप प्रत्येक एल्गोरिदम के माध्यम से काम नहीं कर लेते तब तक प्रतीक्षा करने की आवश्यकता नहीं है!)। उत्पादन के लिए तैयार नहीं होना तब तक ठीक है जब तक आप मानते हैं कि कोड सही परिणाम देता है और प्रदर्शन एक उत्पादन-तैयार कार्यान्वयन में जो हम देखेंगे उसका एक अच्छा प्रतिनिधित्व है। एक बार जब हम उम्मीदवार चुन लेते हैं, तो हम उच्च गुणवत्ता वाले कार्यान्वयन प्राप्त करने के लिए आपके साथ काम कर सकते हैं।

मैंने विश्लेषण नहीं देखा है कि सीहाश की एन्ट्रॉपी अन्य एल्गोरिदम की तुलना कैसे करती है। क्या आपके पास उस पर कोई संकेत है? इसमें दिलचस्प लगने वाले पूर्ण ट्रेडऑफ़ हैं ... वेक्टरकरण तेज़ लगता है, लेकिन मॉड्यूलर अंकगणित धीमा लगता है।

@morganbr मेरे पास एक टीज़र तैयार है।

SeaHash के बारे में : नहीं, मुझे अभी तक गुणवत्ता के बारे में पता नहीं है; यदि प्रदर्शन दिलचस्प है, तो मैं इसे SMHasher में जोड़ दूंगा। कम से कम लेखक का दावा है कि यह अच्छा है (फाइल सिस्टम में चेकसम के लिए इसका उपयोग करना), और यह भी दावा करता है कि मिश्रण के दौरान कोई एंट्रॉपी फेंक दिया नहीं जाता है।

हैश और बेंचमार्क के बारे में : प्रोजेक्ट Haschisch.Kastriert , विकी पेज जिसमें पहले बेंचमार्किंग परिणाम xx32, xx64, hsip13, hsip24, marvin32, sea और murmur3-32 की तुलना करते हैं।

कुछ महत्वपूर्ण चेतावनी:

• यह कम सटीकता सेटिंग्स के साथ चलने वाली एक बहुत तेज़ बेंच थी।
• कार्यान्वयन वास्तव में अभी तक नहीं किया गया है, और कुछ दावेदार अभी भी गायब हैं। स्ट्रीमिंग कार्यान्वयन (ऐसी बात एक समझदार .Add() समर्थन के लिए आवश्यक हो जाएगी) को वास्तविक अनुकूलन की आवश्यकता होती है।
• SeaHash वर्तमान में एक बीज का उपयोग नहीं कर रहा है।

पहली मुलाकात का प्रभाव:

• बड़े संदेशों के लिए, xx64 सूचीबद्ध कार्यान्वयनों में सबसे तेज़ है (लगभग 3.25 बाइट्स प्रति चक्र, जहाँ तक मैं समझता हूँ, या मेरी नोटबुक पर 9.5 GiB/s)
• छोटे संदेशों के लिए, कुछ भी अच्छा नहीं है, लेकिन murmur3-32, और (आश्चर्यजनक रूप से) सीहाश का किनारा है, लेकिन बाद में सीहाश द्वारा अभी तक बीज का उपयोग नहीं करने की संभावना है।
• HashSet<> तक पहुँचने के लिए "बेंचमार्क" को काम करने की ज़रूरत है, क्योंकि सब कुछ लगभग माप त्रुटि के भीतर है (मैंने बड़े अंतर देखे हैं, लेकिन अभी भी बात करने लायक नहीं है)
• हैश-कोड को मिलाते समय, बड़बड़ाहट -3 ए पीओसी लगभग 5 से 20 गुना तेज होता है, जो हमारे यहां है
• सी # में कुछ सार तत्व बहुत महंगे हैं; जो हैश-एल्गोरिदम की तुलना आवश्यकता से अधिक कष्टप्रद बनाता है।

स्थिति में थोड़ा सुधार होने के बाद मैं आपको फिर से लिखूंगा।

@gimpf , यह एक शानदार शुरुआत है! मैंने कोड और परिणामों पर एक नज़र डाली और मेरे कुछ प्रश्न हैं।

1. आपका परिणाम @tannergooding के Murmur3a की तुलना में धीमी 5x के बारे में के रूप में SimpleMultiplyAdd दिखा। यह अजीब लगता है क्योंकि मुरमुर के पास गुणा + जोड़ने की तुलना में अधिक काम है (हालांकि मैं मानता हूं कि घुमाना जोड़ने से तेज ऑपरेशन है)। क्या यह संभव है कि आपके कार्यान्वयन में एक सामान्य अक्षमता है जो उस मुरमुर कार्यान्वयन में नहीं है या क्या मुझे इसे कस्टम कार्यान्वयन के रूप में पढ़ना चाहिए जो सामान्य उद्देश्य वाले लोगों पर एक बड़ा लाभ रखते हैं?
2. 1, 2, और 4 संयोजनों के लिए परिणाम होना अच्छा है, लेकिन यह एपीआई 8 तक जाता है। क्या इसके लिए भी परिणाम प्राप्त करना संभव होगा या इससे बहुत अधिक दोहराव होता है?
3. मैंने देखा कि आप X64 पर चलते हैं, इसलिए इन परिणामों से हमें अपना X64 एल्गोरिथम चुनने में मदद मिलेगी, लेकिन अन्य बेंचमार्क बताते हैं कि एल्गोरिदम X86 और X64 के बीच काफी नाटकीय रूप से भिन्न हो सकते हैं। क्या आपके लिए भी X86 परिणाम प्राप्त करना आसान है? (किसी बिंदु पर, हमें एआरएम और एआरएम 64 भी प्राप्त करने की आवश्यकता होगी, लेकिन वे निश्चित रूप से प्रतीक्षा कर सकते हैं)

आपके हैशसेट परिणाम विशेष रूप से दिलचस्प हैं। यदि वे पकड़ते हैं, तो तेज हैश समय पर बेहतर एन्ट्रॉपी पसंद करने का यह एक संभावित मामला है।

@morganbr यह सप्ताहांत अधिक चालू था, इसलिए प्रगति सीमित है।

आपके प्रश्नों के बारे में:

1. आपका परिणाम @tannergooding के Murmur3a की तुलना में धीमी 5x के बारे में के रूप में SimpleMultiplyAdd दिखा। यह अजीब लगता है ...

मैं खुद सोच रहा था। यह एक कॉपी/पेस्ट त्रुटि थी, SimpleMultiplyAdd हमेशा चार मानों का संयोजन कर रहा था...

क्या यह संभव है कि आपके कार्यान्वयन में एक सामान्य अक्षमता है जो उस मुरमुर कार्यान्वयन में नहीं है या क्या मुझे इसे कस्टम कार्यान्वयन के रूप में पढ़ना चाहिए जो सामान्य उद्देश्य वाले लोगों पर एक बड़ा लाभ रखते हैं?

मुझे कुछ चीजें याद आती हैं, लेकिन ऐसा लगता है कि .NET के लिए सामान्य-उद्देश्य कार्यान्वयन इस उपयोग-मामले के लिए उपयोग योग्य नहीं हैं। मैंने सभी एल्गोरिदम के लिए कंबाइन-स्टाइल विधियों को लिखा है, और wrt हैश-कोड सामान्य उद्देश्य वाले से बेहतर _much_ बेहतर प्रदर्शन करता है।

हालाँकि, वे कार्यान्वयन भी बहुत धीमे हैं; आगे काम करने की जरूरत है। इस क्षेत्र में .NET का प्रदर्शन मेरे लिए बिल्कुल अपारदर्शी है; स्थानीय चर की एक प्रति जोड़ने या हटाने से दो के कारक द्वारा प्रदर्शन को आसानी से बदल दिया जा सकता है। मैं संभवतः ऐसे कार्यान्वयन प्रदान नहीं कर पाऊंगा जो सर्वोत्तम विकल्प चुनने के उद्देश्य से पर्याप्त रूप से अनुकूलित हैं।

1. १, २, और ४ संयोजनों के लिए परिणाम होना अच्छा है, लेकिन यह एपीआई ८ तक जाता है।

मैंने कंबाइन-बेंचमार्क बढ़ा दिए हैं। उस मोर्चे पर कोई आश्चर्य नहीं।

1. मैंने देखा कि आप X64 (...) पर चल रहे हैं, क्या आपके लिए भी X86 परिणाम प्राप्त करना आसान है?

यह एक बार था, लेकिन फिर मैंने .NET मानक को पोर्ट किया। अब मैं निर्भरता-नरक में हूं, और केवल .NET Core 2 और CLR 64bit बेंचमार्क काम करते हैं। एक बार जब मैं मौजूदा मुद्दों को हल कर लेता हूं तो इसे आसानी से हल किया जा सकता है।

क्या आपको लगता है कि यह इसे v2.1 रिलीज़ में बनाएगा?

@gimpf आपने

@jamesqo मैंने कुछ बेंचमार्क तय किए हैं जो अजीब परिणाम देते हैं, और उपलब्ध एल्गोरिदम की सूची में City32, SpookyV2, Sip13 और Sip24 को जोड़ा है। घूंट अपेक्षा के अनुरूप तेज़ हैं (xx64 के थ्रूपुट के सापेक्ष), सिटी और स्पूकी नहीं हैं (सीहैश के लिए अभी भी यही सच है)।

हैश-कोड के संयोजन के लिए, Murmur3-32 अभी भी एक अच्छी शर्त की तरह दिखता है, लेकिन मुझे अभी तक अधिक विस्तृत तुलना नहीं करनी है।

एक अन्य नोट पर, स्ट्रीमिंग एपीआई (.Add ()) में उम्मीदवारों की सूची से कुछ हैश एल्गोरिदम को हटाने का दुर्भाग्यपूर्ण दुष्प्रभाव है। यह देखते हुए कि इस तरह के एपीआई का प्रदर्शन भी संदिग्ध है, हो सकता है कि आप फिर से विचार करना चाहें कि इसे शुरुआत से पेश करना है या नहीं।

यदि .Add() भाग से बचा जा सकता है, और यह देखते हुए कि हैश-कॉम्बिनर एक बीज का उपयोग कर रहा है, मुझे नहीं लगता कि tg के कॉम्बिनर को साफ करने, एक छोटा परीक्षण-सूट बनाने में कोई नुकसान होगा, और अंत करना। चूंकि मेरे पास हर सप्ताहांत में केवल कुछ घंटे होते हैं, और प्रदर्शन-अनुकूलन कुछ कठिन होता है, इसलिए सोना चढ़ाया हुआ संस्करण थोड़ा सा खींच सकता है ...

@gimpf , यह बहुत अच्छी प्रगति की तरह लगता है। क्या आपके पास परिणाम तालिका आसान है ताकि हम देख सकें कि निर्णय लेने और आगे बढ़ने के लिए पर्याप्त है या नहीं?

@morganbr मैंने अपने बेंचमार्किंग परिणाम अपडेट कर

अभी के लिए मेरे पास .NET Core 2 पर केवल 64 बिट परिणाम हैं। उस प्लेटफ़ॉर्म के लिए, City64 w/o बीज सभी आकारों में सबसे तेज़ है। बीज को मिलाकर XX-32 को मुरमुर-3-32 से बांध दिया जाता है। सौभाग्य से ये वही एल्गोरिदम हैं जिनकी प्रतिष्ठा 32 बिट प्लेटफॉर्म के लिए तेज़ होने की है, लेकिन स्पष्ट रूप से हमें यह सत्यापित करने की आवश्यकता है कि यह मेरे कार्यान्वयन के लिए भी सही है। परिणाम वास्तविक दुनिया के प्रदर्शन के प्रतिनिधि प्रतीत होते हैं, सिवाय इसके कि Sea और SpookyV2 असामान्य रूप से धीमे लगते हैं।

आपको यह विचार करने की आवश्यकता होगी कि हैश-कोड-कॉम्बिनर्स के लिए आपको वास्तव में हैश-डॉस सुरक्षा की कितनी आवश्यकता है। यदि हैश को दृढ़ता के लिए स्पष्ट रूप से अनुपयोगी बनाने के लिए सीडिंग की आवश्यकता है, तो 32 बिट बीज के साथ XOR'd एक बार शहर 64 में सुधार होगा। चूंकि यह उपयोगिता केवल हैश के संयोजन के लिए है (और उदाहरण के लिए स्ट्रिंग के लिए हैश-कोड को प्रतिस्थापित नहीं करती है, या पूर्णांक सरणी आदि के लिए ड्रॉप-इन हैशर हो), यह काफी अच्छा हो सकता है।

यदि OTOH आपको लगता है कि आपको इसकी आवश्यकता है, तो आपको यह देखकर खुशी होगी कि Sip13 आमतौर पर XX-32 (64 बिट प्लेटफॉर्म पर) की तुलना में 50% धीमा है, लेकिन 32 बिट ऐप्स के लिए यह परिणाम काफी भिन्न होगा।

पता नहीं यह corefx के लिए कितना प्रासंगिक है, लेकिन मैंने LegacyJit 32bit (w/FW 4.7) परिणाम जोड़े हैं।

मैं कहना चाहता हूं कि परिणाम अजीब तरह से धीमे हैं। हालांकि, उदाहरण के तौर पर, 56 एमआईबी/एस बनाम 319 एमआईबी/एस पर मैं हंस नहीं रहा हूं (वह सिप है, इसमें रोटेट-लेफ्ट ऑप्टिमाइज़ेशन सबसे ज्यादा गुम है)। मुझे लगता है कि मुझे याद है कि मैंने जनवरी में अपना .NET हैश-एल्गोरिदम प्रोजेक्ट क्यों रद्द कर दिया था ...

तो, RyuJit-32bit अभी भी गायब है, और (उम्मीद है) बहुत अलग परिणाम देगा, लेकिन LegacyJit-x86 के लिए, Murmur-3-32 आसानी से जीत जाता है, और केवल City-32 और xx-32 ही करीब आ सकते हैं। मुरमुर का अभी भी 0.6 से 2 जीबी/एस (उसी मशीन पर) के बजाय केवल 0.4 से 1.1 जीबी/एस पर खराब प्रदर्शन है, लेकिन कम से कम यह सही बॉलपार्क में है।

मैं आज रात अपने कुछ बॉक्स पर बेंचमार्क चलाने जा रहा हूं और परिणाम पोस्ट करूंगा (Ryzen, i7, Xeon, A10, i7 Mobile, और मुझे लगता है कि कुछ अन्य)।

@tannergooding @morganbr कुछ अच्छे और कुछ महत्वपूर्ण अपडेट।

पहले महत्वपूर्ण:

• मैंने कुछ संयोजन-कार्यान्वयन तय किए जो गलत हैश मान उत्पन्न कर रहे थे।
• निरंतर तह से बचने के लिए बेंचमार्क सूट अब अधिक मेहनत करता है। City64 अतिसंवेदनशील था (जैसा कि अतीत में बड़बड़ाहट-3-32 था)। इसका मतलब यह नहीं है कि मैं अब हर परिणाम को समझता हूं, लेकिन वे बहुत अधिक प्रशंसनीय हैं।

सुकून भरी बातें:

• कॉम्बिनर कार्यान्वयन अब सभी 1 से 8 तर्क अधिभार के लिए उपलब्ध हैं, जिसमें xx/शहर के लिए कुछ अधिक बोझिल मैन्युअल रूप से अनियंत्रित कार्यान्वयन शामिल हैं।
• टेस्ट और बेंचमार्क उन्हें भी चेक करते हैं। चूंकि कई हैश एल्गोरिदम में विशेष-आवरण वाले निम्न-बाइट संदेश होते हैं, इसलिए वे माप रुचि के हो सकते हैं।
• अनेक लक्ष्यों (कोर बनाम परिवार कल्याण) के लिए सरलीकृत रनिंग बेंचमार्क।

"खाली" (शुद्ध ओवरहेड) और "गुणा-जोड़" (प्रसिद्ध 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 बिट कोर बेंचमार्क चलाने के लिए आसानी से प्रीरिलीज बेंचमार्क डॉटनेट (या शायद 32 बिट-केवल सेट-अप प्लस कोर आधारित बेंच-रनर का उपयोग करने की आवश्यकता होती है) की आवश्यकता होती है। फिर इसे -j: core_x86, उम्मीद के मुताबिक काम करना चाहिए)_

परिणाम : सभी बग फिक्सिंग के बाद, xx32 मोबाइल हैसवेल i7 पर विंडोज 10 पर "त्वरित" रन में, सभी ओवरलोड w/64 बिट RyuJIT के लिए जीतता प्रतीत होता है। सिप और मार्विन32 के बीच, सिप-1-3 हमेशा जीतता है। सिप-1-3 xx32 की तुलना में लगभग 4 गुना धीमा है, जो फिर से एक आदिम मल्टीप्ल-ऐड कॉम्बिनर की तुलना में लगभग 2 गुना धीमा है। 32 बिट कोर परिणाम अभी भी गायब हैं, लेकिन मैं कमोबेश एक स्थिर बेंचमार्कडॉटनेट रिलीज की प्रतीक्षा कर रहा हूं जो मेरे लिए उस मुद्दे को हल करेगा।

(संपादित करें) मैंने हैश-सेट तक पहुंचने के लिए बेंचमार्क का त्वरित रन जोड़ा है। यह स्पष्ट रूप से ऊपर दिए गए μ-बेंचमार्क की तुलना में विवरण पर बहुत अधिक निर्भर है, लेकिन आप इसे एक नज़र देना चाह सकते हैं।

शानदार डेटा के लिए एक बार फिर @gimpf धन्यवाद! देखते हैं कि क्या हम इसे निर्णय में बदल सकते हैं।

शुरू करने के लिए, मैं एल्गोरिदम को इस तरह विभाजित करूंगा:
तेज + अच्छी एन्ट्रापी (गति द्वारा क्रमबद्ध):

1. xxHash32
2. City64 (यह शायद x86 पर धीमा होगा, इसलिए हमें शायद x86 के लिए कुछ और चुनना होगा)
3. मुरमुर3ए

हैशडॉस प्रतिरोधी:

• मार्विन32
• सिपहैश। यदि हम इस ओर झुकते हैं, तो हमें शोध परिणामों की स्वीकार्यता की पुष्टि करने के लिए Microsoft के क्रिप्टो विशेषज्ञों द्वारा इसकी समीक्षा करने की आवश्यकता होगी। हमें यह भी पता लगाना होगा कि कौन से पैरामीटर पर्याप्त सुरक्षित हैं। पेपर सिप-2-4 और सिप-4-8 के बीच कहीं सुझाता है।

विवाद से बाहर (धीमा):

• डरावनाV2
• सिटी32
• xxHash64
  *SeaHash (और हमारे पास एन्ट्रापी पर डेटा नहीं है)

विवाद से बाहर (खराब एन्ट्रापी):

• गुणा जोड़ें
• एचएसआईपी

इससे पहले कि हम एक विजेता चुनें, मैं यह सुनिश्चित करना चाहता हूं कि अन्य लोग मेरे ऊपर दिए गए बकेटिंग से सहमत हों। अगर ऐसा होता है, तो मुझे लगता है कि हमें सिर्फ यह चुनने की जरूरत है कि क्या हैशडॉस प्रतिरोध के लिए 2x का भुगतान करना है और फिर गति से जाना है।

@morganbr आपका समूह ठीक लगता है। SipHash राउंड में डेटा-पॉइंट के रूप में, Rust प्रोजेक्ट ने जीन-फिलिप ऑमासन से पूछा, जिन्होंने सिप-हैश w/DJB लिखा था। उस चर्चा के बाद उन्होंने हैश-टेबल के लिए सिप-1-3 के लिए जाने का फैसला किया।

(देखें पीआर रस्ट:#33940 और साथ में जारी रस्ट:#29754 )।

डेटा और टिप्पणियों के आधार पर, मैं प्रस्ताव करना चाहता हूं कि हम सभी आर्किटेक्चर पर xxHash32 का उपयोग करें। अगला कदम इसे लागू करना है। @gimpf , क्या आप इसके लिए एक पीआर को एक साथ रखने में रुचि रखते हैं?

हैशडॉस के बारे में चिंतित लोगों के लिए, मैं जल्द ही एक सामान्य-उद्देश्य वाले हैशिंग एपीआई के प्रस्ताव के साथ अनुवर्ती कार्रवाई करूंगा जिसमें मार्विन 32 शामिल होना चाहिए और इसमें सिपहैश शामिल हो सकता है। यह अन्य कार्यान्वयनों के लिए भी एक उपयुक्त स्थान होगा @gimpf और @tannergooding ने काम किया है।

@morganbr मैं समय की अनुमति के अनुसार पीआर को एक साथ रख सकता हूं। साथ ही, मैं व्यक्तिगत रूप से xx32 को भी पसंद करूंगा, जब तक कि यह स्वीकृति को कम नहीं करता है।

@gimpf , आपका समय कैसा चल रहा है? यदि आपके पास वास्तव में समय नहीं है, तो हम यह भी देख सकते हैं कि क्या कोई और इसे आज़माना चाहेगा।

@morganbr मैंने इसे 5 नवंबर तक करने की योजना बनाई थी, और यह अभी भी अच्छा लग रहा है कि मुझे अगले दो हफ्तों में समय मिल जाएगा।

@gimpf , बहुत अच्छा लगता है। अद्यतन के लिए धन्यवाद!

@terrajobst - मुझे पार्टी में थोड़ी देर हो गई है (क्षमा करें), लेकिन क्या हम ऐड विधि के रिटर्न प्रकार को नहीं बदल सकते हैं?

```सी#
सार्वजनिक हैशकोड जोड़ें(टी मान);
सार्वजनिक हैशकोड जोड़ें(टी मान, 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

क्या हम ऐड मेथड का रिटर्न टाइप नहीं बदल सकते?

हमने पहले ही पुराने प्रस्ताव में इस पर चर्चा की थी, और इसे खारिज कर दिया गया था।

शुरू करने के लिए बेकार पैरा अधिभार क्यों मौजूद है?

हम कोई पैरा ओवरलोड नहीं जोड़ रहे हैं? इस वेबपेज पर "पैराम्स" के लिए एक Ctrl+F करें, और आप देखेंगे कि आपकी टिप्पणी ही एकमात्र ऐसी जगह है जहां वह शब्द पॉप अप होता है।

एक निहित ऑपरेटर int भी DRY के लिए अच्छा होगा, लेकिन बिल्कुल महत्वपूर्ण नहीं।

मेरा मानना ​​है कि इस पर भी कहीं ऊपर चर्चा की गई थी...

@jamesqo स्पष्टीकरण के लिए धन्यवाद।

पैरा ओवरलोड

मेरा मतलब था AddRange , लेकिन मुझे लगता है कि मुझे इस पर कोई कर्षण नहीं होगा।

@jcdickinson AddRange मूल प्रस्ताव में था, लेकिन यह वर्तमान संस्करण में नहीं है। इसे एपीआई समीक्षा द्वारा अस्वीकार कर दिया गया था (देखें https://github.com/dotnet/corefx/issues/14354#issuecomment-308190321 @terrajobst द्वारा):

हमें सभी AddRange विधियों को हटा देना चाहिए क्योंकि परिदृश्य अस्पष्ट है। Arrays कुछ हद तक बहुत बार दिखने की संभावना नहीं है। और एक बार बड़े सरणी शामिल हो जाने के बाद, सवाल यह है कि क्या गणना को कैश किया जाना चाहिए। कॉलिंग साइड पर लूप के लिए देखने से यह स्पष्ट हो जाता है कि आपको इसके बारे में सोचने की जरूरत है।

@gimpf मैं साथ प्रस्ताव को पॉलीफिल्ड करता हूं । उस कार्यान्वयन को पकड़ने के लिए स्वतंत्र महसूस करें। इसमें वास्तविक 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

हैश कोड स्रोत के रूप में गैर-इनलाइन विधि का उपयोग करना; एक धाराप्रवाह विस्तार विधि बनाम जोड़ें के ५० आह्वान:

| विधि | मतलब | त्रुटि | एसटीडीदेव | छोटा |
|---------- |-----------:|-----------:|---------:|-------: |
| जोड़ें | 401.6 एनएस | १.२६२ एनएस | १.१८० एनएस | 1.00 |
| टैली | ७४७.८ एनएस | २.३२९ एनएस | २.१७८ एनएस | 1.86 |

हालांकि, निम्न पैटर्न काम करता है:

```सी#
सार्वजनिक संरचना हैशकोड: System.Collections.IEnumerable
{
[EditorBrowsable(EditorBrowsableState.Never)]
[अप्रचलित ("यह विधि संग्रह प्रारंभकर्ता वाक्यविन्यास के लिए प्रदान की गई है।", त्रुटि: सत्य)]
सार्वजनिक IEnumerator GetEnumerator () => नया NotImplementedException () फेंकें;
}

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

```

इसमें वर्तमान प्रस्ताव के समान प्रदर्शन विशेषताएं भी हैं:

| विधि | मतलब | त्रुटि | एसटीडीदेव | छोटा |
|--------------- |-----------:|-----------:|---------:|--- ----:|
| जोड़ें | ४०५.० एनएस | २.१३० एनएस | १.८८९ एनएस | 1.00 |
| प्रारंभकर्ता | 400.8 एनएस | ४.८२१ एनएस | ४.२७४ एनएस | 0.99 |

अफसोस की बात है कि यह कुछ हद तक एक हैक है, क्योंकि IEnumerable को कंपाइलर को खुश रखने के लिए लागू किया जाना है। ऐसा कहा जा रहा है, Obsolete foreach पर भी त्रुटि होगी - अपवाद में भाग लेने के लिए आपको वास्तव में चीजों को तोड़ना होगा। दोनों में MSIL अनिवार्य रूप से समान है।

@jcdickinson इस मुद्दे को

प्रो-टिप: एक बार जब आप स्वीकार कर लेते हैं, तो GitHub आपको रेपो (500+ प्रति दिन) से सभी सूचनाओं के लिए स्वचालित रूप से साइन अप कर देगा, मैं इसे केवल "नॉट वॉचिंग" में बदलने की सलाह दूंगा जो आपको मुद्दों के लिए आपके सभी उल्लेख और सूचनाएं भेजेगा। आपने सदस्यता ली।

@jcdickinson , मैं निश्चित रूप से कष्टप्रद पुनरावृत्ति से बचने के तरीकों में दिलचस्पी रखता हूं (हालांकि मुझे नहीं पता कि लोग प्रारंभकर्ता वाक्यविन्यास के बारे में कैसा महसूस करेंगे)। मुझे याद आ रहा है कि धाराप्रवाह के साथ दो समस्याएं थीं:

1. आपके द्वारा नोट किया गया संपूर्ण मुद्दा
2. धाराप्रवाह तरीकों से वापसी मूल्य संरचना की एक प्रति है। यह बहुत आसान है कि गलती से इनपुट खो देने जैसी चीज़ें कर रहे हैं:

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

चूंकि इस थ्रेड पर प्रस्ताव पहले से ही स्वीकृत है (और आप इसे विलय करने के अपने रास्ते पर हैं), मैं किसी भी बदलाव के लिए एक नया एपीआई प्रस्ताव शुरू करने का सुझाव दूंगा।

@karelz मेरा मानना ​​​​है कि @gimpf ने पहले ही इस मुद्दे को पकड़ लिया है। चूंकि वह कार्यान्वयन से अधिक परिचित है, कृपया इस मुद्दे को इसके बजाय सौंपें । ( संपादित करें: एनवीएम)

@terrajobst इसके लिए एक प्रकार का अंतिम-मिनट API अनुरोध। चूंकि हमने GetHashCode अप्रचलित के रूप में चिह्नित किया है, HashCode s ऐसे मान नहीं हैं जिनकी तुलना की जानी चाहिए, भले ही वे ऐसी संरचनाएँ हों जो आम तौर पर अपरिवर्तनीय/तुलनीय हों। उस स्थिति में, क्या हमें 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. मैं अप्रचलित संदेश में should not , या may not बजाय cannot का उपयोग करने पर विचार करूंगा।
2. बशर्ते अपवाद रहता है, मैं उसी स्ट्रिंग को अपने संदेश में डालूंगा, बस अगर विधि को कास्ट या ओपन जेनेरिक के माध्यम से बुलाया जाता है।

@ Joe4evr मेरे साथ ठीक है; मैंने टिप्पणी अपडेट कर दी है। उसी संदेश को GetHashCode अपवाद में भी शामिल करना फायदेमंद हो सकता है, फिर:

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

@morganbr आपने इसे फिर से क्यों

कोरएफएक्स में इसे उजागर करने के लिए पीआर अभी तक नहीं चला है।

@gimpf क्या आपके पास वह कोड है जिसे आपने बेंचमार्क किया है और/या आप जल्दी से देख पाएंगे कि SpookilySharp nuget पैकेज कैसे मेल खाता है। मैं कुछ साल के ठहराव के बाद उस परियोजना को धूल चटाना चाहता हूं और मैं यह देखने के लिए उत्सुक हूं कि यह कैसे खड़ा होता है।

@JonHanna उन्होंने इसे यहाँ पोस्ट किया: https://github.com/gimpf/Haschisch.Kastriert

@ जोनहन्ना , मुझे यह

@morganbr ऐसे एपीआई पर चर्चा करने के लिए उपयुक्त मंच कहां होगा? मुझे उम्मीद है कि इस तरह के एपीआई में केवल सबसे कम आम भाजक से अधिक होगा, और शायद एक अच्छे एपीआई को बड़े स्ट्रक्चर के बेहतर जेआईटी wrt हैंडलिंग की भी आवश्यकता होगी। उन सभी पर चर्चा करना जो एक अलग मुद्दे में बेहतर तरीके से किया जा सकता है...

@gimpf ने आपके लिए एक खोला। डॉटनेट/कोरएफएक्स#25666

@morganbr - क्या हम पैकेज का नाम और संस्करण संख्या प्राप्त कर सकते हैं जिसमें यह प्रतिबद्धता शामिल होगी?

@karelz , क्या आप पैकेज/संस्करण जानकारी के साथ @smitpatel की मदद करने में सक्षम हो सकते हैं?

मैं .NET कोर के दैनिक निर्माण की कोशिश करूंगा - मैं कल तक इंतजार करूंगा।
मुझे नहीं लगता कि ऐसा कोई पैकेज है जिस पर आप आसानी से निर्भरता ले सकते हैं।

यहां प्रतिभागियों के लिए प्रश्न। Roslyn IDE उपयोगकर्ताओं को उनके वर्ग/संरचना में फ़ील्ड/गुणों के एक सेट के आधार पर GetHashCode impl उत्पन्न करने की अनुमति देता है। आदर्श रूप से, लोग https://github.com/dotnet/corefx/pull/25013 में जोड़े गए नए HashCode.Combine का उपयोग कर सकते हैं। हालांकि, कुछ उपयोगकर्ताओं के पास उस कोड तक पहुंच नहीं होगी। इसलिए, हम अभी भी एक GetHashCode जेनरेट करने में सक्षम होना चाहते हैं जो उनके लिए काम करेगा।

हाल ही में, यह हमारे ध्यान में आया कि हम जो प्रपत्र तैयार करते हैं वह समस्याग्रस्त है। अर्थात्, क्योंकि VB डिफ़ॉल्ट रूप से ओवरफ्लो चेक के साथ संकलित करता है, और हमारा इम्प्लांट ओवरफ्लो का कारण बनेगा। साथ ही, वीबी के पास कोड के क्षेत्र के लिए अतिप्रवाह जांच को अक्षम करने का कोई तरीका नहीं है। यह या तो पूरी असेंबली के लिए चालू या बंद है।

इस वजह से, मुझे हमारे द्वारा प्रदान किए गए इंप्लांट को एक ऐसे फॉर्म के साथ बदलने में सक्षम होना अच्छा लगेगा जो इन समस्याओं से ग्रस्त नहीं है। आदर्श रूप से, जेनरेट किए गए फॉर्म में निम्नलिखित गुण होंगे:

1. GetHashCode में एक/दो पंक्तियाँ प्रति फ़ील्ड/प्रॉपर्टी का उपयोग किया जाता है।
2. कोई अतिप्रवाह नहीं।
3. उचित रूप से अच्छा हैशिंग। हम आश्चर्यजनक परिणामों की उम्मीद नहीं कर रहे हैं। लेकिन ऐसा कुछ जिसकी उम्मीद पहले से ही सभ्य होने के लिए की जा चुकी है, और ऐसी समस्याएं नहीं हैं जो आपको आमतौर पर a + b + c + d या a ^ b ^ c ^ d साथ मिलती हैं।
4. कोड पर कोई अतिरिक्त निर्भरता/आवश्यकताएं नहीं।

उदाहरण के लिए, वीबी के लिए एक विकल्प कुछ ऐसा उत्पन्न करना होगा:

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

लेकिन यह तब System.ValueTuple के संदर्भ पर निर्भर करता है। आदर्श रूप से, हमारे पास एक इम्प्लांट हो सकता है जो उसके अभाव में भी काम करता है।

क्या किसी को सभ्य हैशिंग एल्गोरिदम के बारे में पता है जो इन बाधाओं के साथ काम कर सकता है? धन्यवाद!

--

नोट: हमारा मौजूदा उत्सर्जित कोड है:

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

यह स्पष्ट रूप से अतिप्रवाह हो सकता है।

यह सी # के लिए भी कोई समस्या नहीं है क्योंकि हम उस कोड के आसपास केवल unchecked { } जोड़ सकते हैं। वीबी में वह सुक्ष्म नियंत्रण संभव नहीं है।

क्या किसी को सभ्य हैशिंग एल्गोरिदम के बारे में पता है जो इन बाधाओं के साथ काम कर सकता है? धन्यवाद!

ठीक है, आप Tuple.Create(...).GetHashCode() । जाहिर है कि आवंटन होता है, लेकिन यह अपवाद फेंकने से बेहतर लगता है।

क्या कोई कारण है कि आप उपयोगकर्ता को System.ValueTuple इंस्टॉल करने के लिए नहीं कह सकते हैं? चूंकि यह एक अंतर्निहित भाषा सुविधा है, मुझे यकीन है कि System.ValueTuple पैकेज मूल रूप से सभी प्लेटफार्मों के साथ बहुत संगत है, है ना?

जाहिर है कि आवंटन होता है, लेकिन यह अपवाद फेंकने से बेहतर लगता है।

हां। यह अच्छा होगा कि यह आवंटन का कारण न बने।

क्या कोई कारण है कि आप उपयोगकर्ता को System.ValueTuple स्थापित करने के लिए नहीं कह सकते हैं?

यदि हम ValueTuple दृष्टिकोण उत्पन्न करते हैं तो यह व्यवहार होगा। हालांकि, फिर से, यह अच्छा होगा यदि हम केवल कुछ अच्छा उत्पन्न कर सकें जो उस तरह से फिट बैठता है जिस तरह से उपयोगकर्ता ने वर्तमान में अपने कोड को संरचित किया है, उन्हें अपनी संरचना को भारी तरीके से बदलने के बिना।

ऐसा लगता है कि वीबी उपयोगकर्ताओं के पास इस समस्या को उचित तरीके से हल करने का एक तरीका होना चाहिए :) लेकिन ऐसा दृष्टिकोण मुझे दूर कर रहा है :)

@CyrusNajmabadi , यदि आपको वास्तव में उपयोगकर्ता के कोड में अपनी हैश गणना करने की ज़रूरत है, तो सीआरसी 32 काम कर सकता है क्योंकि यह टेबल लुकअप और एक्सओआर का संयोजन है (लेकिन अंकगणित नहीं जो अतिप्रवाह हो सकता है)। हालांकि कुछ कमियां हैं:

1. CRC32 में महान एन्ट्रापी नहीं है (लेकिन यह अभी भी रोसलिन द्वारा उत्सर्जित की तुलना में बेहतर है)।
2. लुकअप टेबल जेनरेट करने के लिए आपको कोड में कहीं 256 एंट्री लुकअप टेबल डालना होगा या कोड को एमिट करना होगा।

यदि आप इसे पहले से नहीं कर रहे हैं, तो मुझे आशा है कि आप हैशकोड प्रकार का पता लगा सकते हैं और जब संभव हो तो इसका उपयोग कर सकते हैं क्योंकि XXHash बहुत बेहतर होना चाहिए।

@morganbr देखें https://github.com/dotnet/roslyn/pull/24161

हम निम्नलिखित करते हैं:

1. यदि उपलब्ध हो तो System.HashCode का प्रयोग करें। किया हुआ।
2. अन्यथा, यदि सी # में:
   2ए. यदि चेक-मोड में नहीं है: अनियंत्रित हैश उत्पन्न करें।
   2बी. यदि चेक-मोड में: 'अनचेक {}' में लिपटे, अनियंत्रित हैश उत्पन्न करें।
3. अन्यथा, अगर वीबी में:
   3बी. यदि चेक-मोड में नहीं है: अनियंत्रित हैश उत्पन्न करें।
   3सी. यदि चेक-मोड में है, लेकिन सिस्टम तक पहुंच है। ValueTuple: Return (a, b, c, ...).GetHashCode() जेनरेट करें
   3डी. अगर System.ValueTuple तक पहुंच के बिना चेक-मोड में है। अनियंत्रित हैश उत्पन्न करें, लेकिन वीबी में एक टिप्पणी जोड़ें कि अतिप्रवाह बहुत संभव है।

यह '3डी' है जो वास्तव में दुर्भाग्यपूर्ण है। मूल रूप से, कोई व्यक्ति जो VB का उपयोग कर रहा है, लेकिन ValueTuple या हाल के सिस्टम का उपयोग नहीं कर रहा है, वह हमारे लिए उचित हैश एल्गोरिथम उत्पन्न करने के लिए हमारा उपयोग नहीं कर पाएगा।

आपको कोड में कहीं 256 प्रविष्टि लुकअप तालिका डालनी होगी

यह पूरी तरह से अप्रिय होगा :)

क्या टेबल-जेनरेशन कोड भी स्वादिष्ट नहीं है? कम से कम विकिपीडिया के उदाहरण के अनुसार , यह ज्यादा कोड नहीं है (लेकिन इसे अभी भी उपयोगकर्ता के स्रोत में कहीं जाना है)।

प्रोजेक्ट में हैशकोड स्रोत को जोड़ना कितना भयानक होगा जैसे रोसलिन (आईएल के साथ) (बहुत सरल) कंपाइलर विशेषता वर्ग परिभाषाओं के साथ जब वे किसी संदर्भित असेंबली के माध्यम से उपलब्ध नहीं होते हैं?

प्रोजेक्ट में हैशकोड स्रोत को जोड़ना कितना भयानक होगा जैसे रोसलिन (बहुत सरल) कंपाइलर विशेषता वर्ग परिभाषाओं के साथ करता है जब वे किसी संदर्भित असेंबली के माध्यम से उपलब्ध नहीं होते हैं?

1. क्या हैशकोड स्रोत को अतिप्रवाह व्यवहार की आवश्यकता नहीं है?
2. मैंने हैशकोड स्रोत को स्किम किया है। यह गैर तुच्छ है। उपयोगकर्ता की परियोजना में उस सभी गड़बड़ी को उत्पन्न करना काफी भारी होगा।

मुझे आश्चर्य है कि वीबी में काम करने के लिए अतिप्रवाह गणित प्राप्त करने का कोई अच्छा तरीका नहीं है :(

तो, कम से कम, भले ही हम दो मानों को एक साथ जोड़ रहे हों, ऐसा लगता है कि हमें बनाना होगा:

```सी#
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;
        }

क्यूराउंड के रूप में:

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

तो मैं ईमानदारी से नहीं देखता कि यह कैसे काम करेगा :(

प्रोजेक्ट में हैशकोड स्रोत को जोड़ना कितना भयानक होगा जैसे रोसलिन (आईएल के साथ) (बहुत कुछ) के साथ करता है

आप इस काम की कल्पना कैसे करते हैं? ग्राहक क्या लिखेंगे, और प्रतिक्रिया में संकलक क्या करेंगे?

इसके अलावा, कुछ ऐसा जो इन सभी को संबोधित करेगा यदि .Net में पहले से ही सतह एपीआई पर सार्वजनिक सहायक हैं जो बिना अतिप्रवाह के uint से int32 (और इसके विपरीत) में परिवर्तित हो जाते हैं।

क्या वे मौजूद हैं? यदि ऐसा है, तो मैं आसानी से वीबी संस्करण लिख सकता हूं, बस इनका उपयोग उन परिस्थितियों के लिए कर सकता हूं जहां हमें बिना अतिप्रवाह के प्रकारों के बीच जाने की आवश्यकता होती है।

क्या टेबल-जेनरेशन कोड भी स्वादिष्ट नहीं है?

मुझे ऐसा लगता होगा। मेरा मतलब है, इस बारे में ग्राहक के नजरिए से सोचें। वे सिर्फ एक सभ्य GetHashCode विधि चाहते हैं जो अच्छी तरह से निहित है और उचित परिणाम देता है। उस सुविधा के जाने और उनके कोड को सहायक बकवास के साथ ब्लोट करना बहुत अप्रिय होने वाला है। यह भी बहुत बुरा है कि सी # अनुभव ठीक रहेगा।

हो सकता है कि आप हस्ताक्षरित और अहस्ताक्षरित 64-बिट प्रकारों के कुछ संयोजन से कास्ट करके लगभग सही ओवरफ़्लो व्यवहार प्राप्त करने में सक्षम हों। ऐसा कुछ (अवांछित और मुझे वीबी कास्टिंग सिंटैक्स नहीं पता):

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

आप कैसे जानते हैं कि निम्नलिखित अतिप्रवाह नहीं है?

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

या उस मामले के लिए अंतिम (int32) डाली?

मुझे नहीं पता था कि यह अतिप्रवाह-जांच किए गए रूपांतरण संचालन का उपयोग करेगा। मुझे लगता है कि कास्टिंग से पहले आप इसे 32 बिट तक मुखौटा कर सकते हैं:

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

संभावित रूप से 31 बिट्स, uint32 के मान के रूप में। मैक्स भी इंट 32 में रूपांतरण पर बह जाएगा :)

यह संभव है। बदसूरत... लेकिन संभव है :) इस कोड में बहुत सारी कास्ट होनी चाहिए।

ठीक। मुझे लगता है कि मेरे पास एक व्यावहारिक समाधान है। आज हम जो एल्गोरिथम उत्पन्न कर रहे हैं उसका मूल है:

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

मान लीजिए कि हम 64 बिट गणित कर रहे हैं, लेकिन "हैशकोड" को 32 बिट्स तक सीमित कर दिया गया है। तब <largest_32_bit> * -1521134295 + <largest_32_bit> 64 बिट अतिप्रवाह नहीं होगा। तो हम हमेशा 64 बिट्स में गणित कर सकते हैं, फिर 32 (या 32 बिट) तक क्लैंप कर सकते हैं ताकि यह सुनिश्चित हो सके कि अगला राउंड ओवरफ्लो नहीं होगा।

धन्यवाद!

@MaStr11 @morganbr @sharwell और यहां सभी। मैंने वीबी के लिए निम्नलिखित उत्पन्न करने के लिए अपना कोड अपडेट कर लिया है:

        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 तक कहीं भी हो सकता है। मुझे यह क्यों मिल रहा है?

लेकिन नहीं, यह वास्तव में अतिप्रवाह नहीं हो सकता।

बीटीडब्ल्यू- मैं रोसलिन को एक उप-इष्टतम हैश जोड़ने के बजाय एक NuGet पैकेज जोड़ना चाहता हूं।

लेकिन आप उच्च बिट को शून्य पर मास्क कर रहे हैं, इसलिए यह केवल 31-बिट हैश है। क्या उच्च बिट को अतिप्रवाह माना जाता है?

ये एक अच्छा बिंदु है। मुझे लगता है कि मैं एक और एल्गोरिदम के बारे में सोच रहा था जो यूंट का उपयोग कर रहा था। तो लंबे समय से यूंट में सुरक्षित रूप से कनवर्ट करने के लिए, मुझे साइन बिट शामिल नहीं करने की आवश्यकता है। हालाँकि, जैसा कि यह सब हस्ताक्षरित गणित है, मुझे लगता है कि 0xffffffff के खिलाफ सिर्फ मुखौटा करना ठीक होगा, यह सुनिश्चित करना कि हम प्रत्येक प्रविष्टि को जोड़ने के बाद केवल नीचे 32 बिट रखें।

मैं इसके बजाय रोसलिन को एक उप-इष्टतम हैश जोड़ने के बजाय एक NuGet पैकेज जोड़ना चाहता हूं।

यूजर्स चाहें तो पहले से ही ऐसा कर सकते हैं। यह इस बारे में है कि क्या करना है जब उपयोगकर्ता उन निर्भरताओं को नहीं जोड़ सकते हैं या नहीं कर सकते हैं। यह उपयोगकर्ताओं के लिए एक उचित 'काफी अच्छा' हैश प्रदान करने के बारे में भी है। यानी आम "x + y + z" दृष्टिकोण से बेहतर कुछ जो लोग अक्सर लेते हैं। यह 'इष्टतम' होने का इरादा नहीं है क्योंकि जब सभी उपयोगकर्ताओं के लिए हैशिंग की बात आती है तो 'इष्टतम' क्या है इसकी कोई अच्छी परिभाषा नहीं है। ध्यान दें कि हम यहां जिस दृष्टिकोण को ले रहे हैं वह पहले से ही अज्ञात प्रकारों के लिए संकलक द्वारा उत्सर्जित है। यह उपयोगकर्ता के कोड में एक टन जटिलता नहीं जोड़ते हुए यथोचित रूप से अच्छा व्यवहार प्रदर्शित करता है। समय के साथ, जैसे-जैसे अधिक से अधिक उपयोगकर्ता आगे बढ़ने में सक्षम होते हैं, वैसे-वैसे धीरे-धीरे गायब हो सकते हैं और अधिकांश लोगों के लिए हैशकोड के साथ प्रतिस्थापित किया जा सकता है।

इसलिए मैंने इस पर थोड़ा काम किया और निम्नलिखित के साथ आया जो मुझे लगता है कि सभी चिंताओं का समाधान करता है:

        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 को कॉल करना हमारी आवश्यकताओं के लिए दो अच्छे गुण हैं। सबसे पहले, यह सुनिश्चित करता है कि हैशकोड केवल इसमें एक कानूनी int32 मान संग्रहीत करता है (जो अंतिम रिटर्निंग कास्ट को प्रदर्शन करने के लिए हमेशा सुरक्षित बनाता है)। दूसरा, यह सुनिश्चित करता है कि हम जिस int64 अस्थायी मान के साथ काम कर रहे हैं, उसके ऊपरी 32 बिट में कोई भी मूल्यवान जानकारी न खोएं।

@CyrusNajmabadi वास्तव में पैकेज स्थापित करने की पेशकश कर रहा था जिसके बारे में मैं पूछ रहा था। मुझे करने से बचाता है।

यदि आप HashCode टाइप करते हैं, तो यदि System.HashCode MS nuget पैकेज में दिया गया है, तो Roslyn इसे पेश करेगा।

मैं चाहता हूं कि यह गैर-मौजूद GetHashCode अधिभार उत्पन्न करे और उसी ऑपरेशन में पैकेज स्थापित करे।

मुझे नहीं लगता कि यह अधिकांश उपयोगकर्ताओं के लिए उपयुक्त विकल्प है। निर्भरता जोड़ना एक बहुत ही भारी ऑपरेशन है जिसमें उपयोगकर्ताओं को मजबूर नहीं किया जाना चाहिए। उपयोगकर्ता उन विकल्पों को चुनने का सही समय तय कर सकते हैं, और आईडीई इसका सम्मान करेगा। अब तक हमने अपनी सभी सुविधाओं के साथ यही तरीका अपनाया है, और यह एक स्वस्थ तरीका है जिसे लोग पसंद करते हैं।

नोट: हमारे लिए संदर्भ जोड़ने के लिए इस एपीआई को भी किस नगेट पैकेज में शामिल किया जा रहा है?

कार्यान्वयन System.Private.CoreLib.dll में है, इसलिए यह रनटाइम पैकेज के हिस्से के रूप में आएगा। अनुबंध System.Runtime.dll है।

ठीक। यदि ऐसा है, तो ऐसा लगता है कि उपयोगकर्ता को यह तब मिलेगा जब वे हाल के लक्ष्य ढांचे में जाते हैं। उस तरह की चीज बिल्कुल एक कदम नहीं है, मेरे पास उपयोगकर्ता की परियोजना के लिए "बराबर + हैशकोड उत्पन्न करें" होगा।