Xxhash: أضف تجزئة مواء في المعايير

يعتمد meow_hash كليًا على وجود تعليمات AES المسرَّعة بالأجهزة.

أظن أنه لن يتم تجميعه حتى في غياب هذه التعليمات ، حيث أن الكود قصير جدًا ، ولا أرى أي مسار رمز احتياطي للبرنامج. إلى جانب ذلك ، فإن جميع تعليمات AES التي يمكنني قراءتها تستخدم تقنية Intel مضمنة مباشرة ، لذا فهي ليست محمولة عبر الهندسة ، بغض النظر عن إمكانيات الأجهزة.

إنه ليس بالضرورة شيئًا "سيئًا": بعد كل شيء ، فإنهم يحصلون على سرعة كبيرة لإدخال طويل في المقابل.

لكن النقطة الأساسية هي: بالاعتماد على مجموعة تعليمات الأجهزة المتخصصة هذه ، تكون إمكانية النقل خارج قائمة الميزات.

كأثر جانبي ، لن يتم تشغيله حتى على النظام الأساسي المستخدم لمعايير xxHash.

ربما ينبغي أن أقضي بعض الوقت في توثيق هذا.

لم يعد هذا صحيحًا ، يجب عليك إعادة النظر في هذا.

نعم ، عند قراءة الإعلانات ، تحسن مواء كثيرًا في بعض المراجعات.
حتى أنها تعلن التوافق مع ARM.

سأحتاج إلى بعض الوقت لإلقاء نظرة أعمق عليها.

لقد قمت للتو بإلقاء نظرة خاطفة ، ولم أتمكن من العثور على مسار النسخ الاحتياطي للبرنامج. ربما كان هناك وقد فاتني ذلك للتو.
أيضًا ، لا أعرف حتى الآن ما إذا كانت وحدات أجهزة AES المختلفة مضمونة لإنتاج نفس قيمة التجزئة تمامًا ، أو إذا كان هناك المزيد لها (مثل المعلمات الإضافية التي قد يتم ضبطها مسبقًا بشكل مختلف وتتطلب تعليمات خاصة بالماكينة لتكون موحدة). يعد حساب التجزئة واستهلاكها محليًا أمرًا واحدًا ، وفي هذه الحالة لا يهم التمثيل الدقيق. إنها طريقة أخرى لكتابة / إجراء تسلسل للقيمة وتتوقع قراءتها / إعادة إنتاجها بالضبط على أي نظام آخر. هذا الجزء من قابلية التشغيل البيني أكثر صعوبة بعض الشيء.
لكن مرة أخرى ، ربما يكون هناك ، وأنا فقط بحاجة لبعض الوقت للنظر في الأمر.

للإشارة ، هذا مقابل أحدث إصدار لدي ، 2.0 جيجاهرتز Core i7 Gen 2 (Sandy Bridge)

كلانج 7.0.1.0
الأعلام: -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 وتنفيذ C:

./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)

لم يعد هذا صحيحًا ، يجب عليك إعادة النظر في هذا

... aaand في مواء 0.5 هذا صحيح مرة أخرى ؛ في أحدث إصدار لديهم مرة أخرى مسار رمز x64 AES فقط :)

لذا ، نعم ، Meow Hash خاص نوعًا ما بـ x86_64 و Nehalem + ، أو يجب عليه التبديل إلى إصدار احتياطي بطيء.

وفي الوقت نفسه ، يحتوي XXH3 على مسارات رموز موجهة لجميع x86_64 (بما في ذلك Core 2 والأصدقاء) ، و Pentium 4+ (وهو مطلوب لنظام التشغيل Windows 7+) ، و ARMv7-A w / NEON (متاح على معظم أجهزة Android وجميع أجهزة iOS باستثناء iPhone الأصلي ) ، ARM64 (جميع أجهزة iPhone و Android الحديثة) ، VSX POWER9 (العديد من الخوادم وأجهزة الكمبيوتر العملاقة لديها هذه ، لكنها سوق متخصصة) ، وإذا لم يكن ذلك كافيًا ، فحتى الإصدار القياسي لا يزال سريعًا جدًا حتى على 32 بت الأهداف ، نظرًا لأن لديهم مُضاعِفًا لائقًا.

لقد بدأت في جمع المزيد من النتائج المعيارية ، حيث كان هناك العديد من الطلبات من هذا النوع على مر السنين.
بدءًا من هذا ، والذي كان طلبًا متكررًا.

meowHash سريع جدًا بالفعل ، حيث سجل نفس السرعة تقريبًا مثل XXH3 للبيانات الكبيرة (حوالي 100 كيلوبايت) ، وبالتالي أسرع قليلاً من XXH128 .
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

ومع ذلك ، فإن meowHash مصمم حقًا للبيانات الكبيرة. عندما يتعلق الأمر بالبيانات _الصغيرة_ ، لا يمكن مقارنة الأداء ، حيث تتطلب الخوارزمية تكلفة ثابتة كبيرة ، والتي يتم استهلاكها بشكل سيئ على البيانات الصغيرة.

أحد التطورات المقلقة هو وجود تناقض في "كيفية تمثيل النتائج وتفسيرها".
بالنسبة للبيانات الكبيرة ، الأمر بسيط نوعًا ما ، يمكن أن يكون الجدول المصنف كافيًا ، مما يعطي فكرة فورية عن الترتيب.
بالنسبة للبيانات الصغيرة ، يبدو الأمر أكثر تعقيدًا.
حتى الآن ، استخدمت الرسوم البيانية ، حيث قدمت نتيجة السرعة وفقًا للأطوال والسيناريوهات المختلفة. بحكم عرض المزيد من المعلومات ، يصعب تفسيرها بالضرورة.

نتيجة لذلك ، ليس من الواضح ما إذا كان القارئ ، بعد العثور على رقم الأداء الأول في الجدول العلوي البارز ، سيهتم بالبحث أدناه للحصول على رسوم بيانية إضافية ، وبالتالي توجيه اختياره مع احتمال فقدان معلومات مهمة لحالة استخدامه.

قضية أخرى تتعلق بالرسوم البيانية نفسها. يمكن تمديد الجدول المصنف بسهولة نسبيًا. هناك حدود بالتأكيد ، ولكن بشكل عام ، فإن إضافة متنافس يضيف سطرًا فقط.
ومع ذلك ، في الرسم البياني ، يتم تمثيل كل متنافس بخط. تميل الخطوط إلى التداخل. لا يوجد سوى العديد من الألوان للاختيار من بينها وما إلى ذلك. وبسرعة كبيرة ، إذا كان عدد المنافسين الممثلين كبيرًا ، فهذه مجرد فوضى كبيرة.
لذلك ، إذا كان أداء البيانات الصغيرة يحتاج إلى رسم بياني ، فإنه يحد بشدة من عدد المتنافسين الذين يمكن تمثيلهم.

إضافة فقرة تحتوي على بيانات معيارية "أولية" ، رغم أنها تستحق الثناء ، فهي بديل رديء.

لذلك ، كنت أفكر في "تلخيص" نتيجة اختبار البيانات الصغيرة ، وإنشاء "رقم أداء" يمكن استخدامه في جدول مصنف ، لإعطاء تلميح على الأقل للأداء العام على البيانات الصغيرة. لا يزال يتعين على القراء المهتمين البحث عن معلومات أكثر دقة (الرسوم البيانية) ، ولكن على الأقل ، يمكن نقل فكرة أن بعض الخوارزميات أكثر ملاءمة للبيانات الصغيرة من غيرها بطريقة بسيطة نسبيًا.

لا تزال هناك مشكلة مفادها أن الرسوم البيانية لا يمكن أن تمثل سوى عدد محدود من المتنافسين ، وربما لا يكون العنصر الذي يريد القارئ مراقبته جزءًا من القائمة المحددة (حتى عند توفر البيانات الأولية).

كنت أتساءل عما إذا كانت هناك طريقة أفضل لتمثيل الرسوم البيانية. شيء أكثر ديناميكية من لقطة شاشة معدة ، مما يسمح للمستخدم بتحديد المتنافسين الذين يجب أن يكونوا مرئيين.

تمت إضافة تجزئة مواء في المقارنة:
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

إضافة إدخال إلى الجدول أمر جيد.
لكن ما زلت بحاجة إلى طريقة أفضل لرسم الرسوم البيانية لعدد كبير من المرشحين.