2013-02-13 39 views
8

मैं डेटा को फिंगरप्रिंट करने और हैश द्वारा इसकी पहचान करने के लिए डेटा के सेट के लिए हैश प्रदान कर रहा हूं - यह SHA1 और MD5 जैसे तेज़ हैंश के लिए मुख्य उपयोग केस है।.NET प्रबंधित संस्करण की तुलना में विंडोज पर देशी क्रिप्टोग्राफिक हैंश के मूल कार्यान्वयन कितनी तेजी से है?

नेट में, इनमें से कुछ हैंश (मूल रूप से एसएचए वेरिएंट) के मूल या प्रबंधित कार्यान्वयन के साथ जाने का विकल्प है। मैं एक एमडी 5 प्रबंधित कार्यान्वयन की तलाश में हूं, और नेट फ्रेमवर्क में ऐसा प्रतीत नहीं होता है, लेकिन आश्चर्य हुआ कि लपेटा गया मूल सीएसपी वैसे भी तेज है, और अगर मुझे केवल इस सामग्री का उपयोग करना चाहिए कि कोई पेर्फ नहीं होगा इसका उपयोग करने में समस्याएं। Why is there no managed MD5 implementation in the .NET framework? का शीर्ष उत्तर इंगित करता है कि एक तेज़ प्रदर्शन ऐसा कारण हो सकता है कि एक प्रबंधित संस्करण मौजूद नहीं है।

क्या यह सच है, और यदि हां, तो देशी सीएसपी कितनी तेजी से है?

+0

MD5 के एमएस कार्यान्वयन बेकार है, कम से कम छोटी स्ट्रिंग के लिए। मुझे ओपनएसएसएल को पी/आविष्कार करके ~ 10 गुणा तेज गति मिली। – CodesInChaos

+0

मुझे यह सुनकर खुशी हुई, क्योंकि मुझे ओपनएसएसएल कार्यान्वयन का परीक्षण करने में रूचि थी। – codekaizen

+0

छोटे विज्ञापन: यदि आप टक्कर प्रतिरोधी चाहते हैं (न तो MD5 और न ही SHA-1 है) फ़ाइलों की पहचान करने के लिए तेज़ हैश-फ़ंक्शन, तो आप Blake2 पर विचार कर सकते हैं। यह उस परिदृश्य के लिए बनाया गया था। लेकिन आपको अधिकतम प्रदर्शन के लिए मूल पुस्तकालय की आवश्यकता होगी। – CodesInChaos

उत्तर

17

दुर्भाग्य से, एमडी 5 - MD5CryptoServiceProvider के लिए लिपटे देशी सीएसपी - एक शुद्ध प्रबंधित कार्यान्वयन से काफी धीमी है। यह एक कठोर दृष्टिकोण है जो मानता है कि देशी कोड प्रबंधित कोड से स्पष्ट रूप से तेज़ है: कई मामलों में विपरीत सत्य है। यह मामला है, कम से कम सिर-टू-हेड मापन में।

translated reference MD5 implementation by David Anson का उपयोग करके, मैंने quick performance test (source) का निर्माण किया जिसका उद्देश्य दो कार्यान्वयन के बीच प्रदर्शन में किसी भी बड़े अंतर को मापना है। छोटे डेटा एरे के लिए अंतर लगभग 16kb पर अपेक्षित नगण्य है, मूल कार्यान्वयन संभावित रूप से महत्वपूर्ण देरी दिखाने के लिए शुरू होता है - मिलीसेकंड के क्रम पर। यह बहुत अधिक प्रतीत नहीं होता है, लेकिन यह शुद्ध प्रबंधित कार्यान्वयन की तुलना में तीव्रता के आदेश धीमा है। इस अंतर को डेटा के आकार के आकार के रूप में बनाए रखा जाता है, और सबसे बड़े परीक्षण डेटा सरणी - ~ 250 एमबी - सीपीयू समय में अंतर लगभग 8.5 सेकंड था। इस बात को ध्यान में रखते हुए कि इस तरह का हैश अक्सर बहुत बड़ी फाइलों को फिंगरप्रिंट करने के लिए प्रयोग किया जाता है, यह अतिरिक्त देरी आई/ओ से अक्सर बड़ी देरी के खिलाफ भी ध्यान देने योग्य हो जाएगी।

यह स्पष्ट रूप से स्पष्ट नहीं है कि देरी कहाँ से आती है, क्योंकि शुद्ध देशी परीक्षण नहीं किया गया था (एक जो सीएसपी के लपेटने और प्रबंधित कोड में खपत के साथ बांटता है), लेकिन ग्राफ के लगभग समान आकार को देखते हुए लॉग स्केल, ऐसा प्रतीत होता है कि प्रबंधित और देशी कार्यान्वयन में एक ही आंतरिक प्रदर्शन होता है, लेकिन मूल कोड प्रदर्शन रनटाइम पर देशी और प्रबंधित कोड के बीच इंटरऑप की लागत के कारण प्रदर्शन में "स्थानांतरित" हो जाता है। यह performance difference between wrapped native CSPs and pure managed implementations has also been reproduced and documented by other investigators

इस विशेष मामले में "उत्तर कार्यान्वयन कितना तेज़ है" सवाल का जवाब देने के अलावा, मुझे उम्मीद है कि यह सबूत prompt more reflection and investigation पर कार्य करता है जब देशी बनाम प्रबंधित का सवाल उठता है, लंबे समय तक खड़े और हानिकारक प्रतिक्रिया को तोड़ता है इसी तरह के प्रश्न हैं कि देशी कोड हमेशा तेज होता है, और इस प्रकार, किसी भी तरह, बेहतर। थोक डेटा हैशिंग के इस प्रदर्शन-संवेदनशील डोमेन में भी प्रबंधित कोड स्पष्ट रूप से बहुत तेज़ है।

MD5 Hash Computation Time MD5 Hash Computation Time (Logarithmic)

+0

'" स्थानांतरित "डाउन' लेकिन लॉगरिदमिक स्पेस में जो निरंतर कारक गति अंतर से मेल खाता है। तो यह शायद एक बुरा मूल कार्यान्वयन है।यदि सही देशी किया जाता है तो बड़े डेटा पर प्रबंधित मापनीय को हराया जाना चाहिए। – usr

+1

हां, यह वह बिंदु था जिसे मैंने बनाया था: "ऐसा लगता है कि प्रबंधित और देशी कार्यान्वयन में एक ही आंतरिक प्रदर्शन होता है"। लेकिन देशी कोड का प्रदर्शन अधिक क्यों होगा? यदि आप जिटर आउटपुट को जीते हैं और जीसी संग्रह से बचते हैं, तो आप उसी प्रदर्शन के बारे में जानेंगे जब तक कि आप विशेष रूप से हार्डवेयर निर्देश/रजिस्ट्रार को लक्षित नहीं करते हैं जो सीएलआर जिटर नहीं करता है। प्रबंधित कोड जादू कारणों से धीमा नहीं है, विशिष्ट चीजें हैं जो इसे धीमा करती हैं जिन्हें perf संवेदनशील कोड से बचा जा सकता है। – codekaizen

+1

खैर, मैं इस बात से असहमत हूं कि प्रबंधित और मूल के पास एक ही अंतर्निहित perf है और डेटा इसके लिए सबूत है। डेटा उच्च डेटा आकारों पर * PInvoke ओवरहेड के खिलाफ सबूत * है क्योंकि PInvoke कॉल की आवृत्ति शून्य से संपर्क करनी चाहिए। .NET JIT सामान्य रूप से काफी खराब है। एक अच्छा सी संकलक इसे आसानी से बाहर कर सकते हैं। मैंने प्रबंधित कोड जेन की विस्तार से जांच की है और यह कई मामलों में निराश है। एक व्यावहारिक उदाहरण के रूप में प्रबंधित जेआईटी ने हाल ही में रोटेशन निर्देशों के लिए समर्थन प्राप्त किया (यह अभी तक जारी नहीं हुआ है)। – usr