Xxhash: बेंचमार्क में म्याऊ हैश जोड़ें

meow_hash पूरी तरह से हार्डवेयर-त्वरित एईएस निर्देशों की उपस्थिति पर निर्भर करता है।

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

यह जरूरी नहीं कि "बुरी" चीज हो: आखिरकार, उन्हें बदले में लंबे इनपुट के लिए बहुत अच्छी गति मिलती है।

लेकिन मुख्य बिंदु यह है: ऐसे विशेष हार्डवेयर निर्देश सेट पर निर्भरता के साथ, सुवाह्यता सुविधा सूची से बाहर है।

साइड-इफ़ेक्ट के रूप में, यह xxHash बेंचमार्क के लिए उपयोग किए जाने वाले प्लेटफ़ॉर्म पर भी नहीं चलेगा।

शायद मुझे इसे दस्तावेज करने में कुछ समय बिताना चाहिए।

यह अब सच नहीं है आपको इसे फिर से देखना चाहिए।

हाँ, घोषणाओं को पढ़कर, म्याऊ ने कुछ संशोधनों में बहुत सुधार किया है।
यह एआरएम के साथ संगतता की भी घोषणा करता है।

मुझे इसमें गहराई से देखने के लिए कुछ समय चाहिए।

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

संदर्भ के लिए, यह मेरे नवीनतम संस्करण, 2.0 GHz Core i7 Gen 2 (सैंडी ब्रिज) के विरुद्ध है।

बजना 7.0.1
झंडे: -O3 -march=native

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54765 it/s ( 5348.2 MB/s)
XXH32 unaligned     :     102400 ->    53782 it/s ( 5252.1 MB/s)
XXH64               :     102400 ->   104882 it/s (10242.4 MB/s)
XXH64 unaligned     :     102400 ->   105935 it/s (10345.2 MB/s)
XXH32a              :     102400 ->    78027 it/s ( 7619.8 MB/s)
XXH32a unaligned    :     102400 ->    75624 it/s ( 7385.2 MB/s)
XXH64a              :     102400 ->    77204 it/s ( 7539.5 MB/s)
XXH64a unaligned    :     102400 ->    76209 it/s ( 7442.3 MB/s)
XXH auto            :     102400 ->   105179 it/s (10271.4 MB/s)
XXH auto unaligned  :     102400 ->   101546 it/s ( 9916.6 MB/s)
XXH32 auto          :     102400 ->   107646 it/s (10512.3 MB/s)
XXH32 auto unaligne :     102400 ->   104364 it/s (10191.8 MB/s)
XXH64 auto          :     102400 ->   107443 it/s (10492.4 MB/s)
XXH64 auto unaligne :     102400 ->   105843 it/s (10336.3 MB/s)
meow auto           :     102400 ->   214435 it/s (20940.9 MB/s)
meow auto unaligned :     102400 ->   213289 it/s (20829.0 MB/s)

-march=penryn -mno-sse4.2 -mno-avx और सी कार्यान्वयन के साथ:

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54106 it/s ( 5283.8 MB/s)
XXH32 unaligned     :     102400 ->    53303 it/s ( 5205.4 MB/s)
XXH64               :     102400 ->   107245 it/s (10473.1 MB/s)
XXH64 unaligned     :     102400 ->   107774 it/s (10524.8 MB/s)
XXH32a              :     102400 ->    78394 it/s ( 7655.6 MB/s)
XXH32a unaligned    :     102400 ->    79666 it/s ( 7779.9 MB/s)
XXH64a              :     102400 ->    78907 it/s ( 7705.7 MB/s)
XXH64a unaligned    :     102400 ->    78179 it/s ( 7634.6 MB/s)
XXH auto            :     102400 ->   108878 it/s (10632.6 MB/s)
XXH auto unaligned  :     102400 ->   105124 it/s (10266.0 MB/s)
XXH32 auto          :     102400 ->   105819 it/s (10333.9 MB/s)
XXH32 auto unaligne :     102400 ->   103970 it/s (10153.3 MB/s)
XXH64 auto          :     102400 ->   110021 it/s (10744.2 MB/s)
XXH64 auto unaligne :     102400 ->   107109 it/s (10459.9 MB/s)
meow auto           :     102400 ->    15962 it/s ( 1558.8 MB/s)
meow auto unaligned :     102400 ->    16022 it/s ( 1564.6 MB/s)

यह अब सच नहीं है आपको इसे फिर से देखना चाहिए

...आऔर म्याऊ 0.5 में यह फिर से सच है; नवीनतम संस्करण में उनके पास फिर से केवल x64 एईएस कोड पथ है :)

तो हाँ, मेव हैश x86_64 और नेहलेम + के लिए थोड़े विशिष्ट है, या इसे धीमी गति से फॉलबैक संस्करण पर स्विच करना होगा।

इस बीच, XXH3 ने सभी x86_64 (कोर 2 और दोस्तों सहित), पेंटियम 4+ (जो कि विंडोज 7+ के लिए आवश्यक है), ARMv7-A w/NEON (मूल iPhone को छोड़कर अधिकांश Android और सभी iOS उपकरणों पर उपलब्ध) के लिए कोड पथ को वेक्टरकृत किया है। ), ARM64 (सभी हाल के iPhone और Android), VSX POWER9 (कई सर्वर और सुपर कंप्यूटर में ये हैं, लेकिन यह एक विशिष्ट बाजार है), और यदि वह पर्याप्त नहीं था, तो भी स्केलर संस्करण 32-बिट पर भी बहुत तेज़ है लक्ष्य, बशर्ते उनके पास एक अच्छा गुणक हो।

मैं कुछ और बेंचमार्क परिणाम इकट्ठा करना शुरू कर रहा हूं, क्योंकि वर्षों से इस तरह के कई अनुरोध थे।
इसके साथ शुरू, जो एक बार-बार अनुरोध किया गया है।

meowHash वास्तव में बहुत तेज है, बड़े डेटा (~100 KB) के लिए लगभग XXH3 के समान गति स्कोर कर रहा है, इसलिए XXH128 से थोड़ा तेज है।
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

कहा जा रहा है, meowHash वास्तव में बड़े डेटा के लिए डिज़ाइन किया गया है। जब _छोटे_ डेटा की बात आती है, तो प्रदर्शन तुलनीय नहीं होता है, क्योंकि एल्गोरिथम के लिए एक बड़ी निश्चित लागत की आवश्यकता होती है, जो कि छोटे डेटा पर खराब रूप से परिशोधित होती है।

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

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

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

"कच्चे" बेंचमार्क डेटा वाला एक पैराग्राफ जोड़ना, जबकि सराहनीय है, एक खराब विकल्प है।

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

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

मैं सोच रहा था कि क्या रेखांकन का प्रतिनिधित्व करने का एक बेहतर तरीका होगा। तैयार स्क्रीनशॉट की तुलना में कुछ अधिक गतिशील, उपयोगकर्ता को यह चुनने की अनुमति देता है कि कौन से दावेदार दिखाई देने चाहिए।

म्याऊ हैश तुलना में जोड़ा गया:
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

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