🙋🏿 ♊️ 🆗 दो बाइट सरणियों की तुलना करने के 5 तरीके। तुलनात्मक परीक्षण 🤟🏻 🌂 👆🏿

मेरे सॉफ़्टवेयर की रूपरेखा के परिणामस्वरूप, मैंने निष्कर्ष निकाला कि बफर तुलना फ़ंक्शन को अनुकूलित करना आवश्यक था।
क्योंकि चूंकि सीएलआर स्मृति के दो टुकड़ों की तुलना करने के लिए एक मानक तरीका प्रदान नहीं करता है, इसलिए फ़ंक्शन को स्वतंत्र रूप से व्हीप्ड किया गया था (यदि केवल यह काम किया है)।
".Net में बाइट एरियर्स से तुलना करने का सबसे अच्छा तरीका" वाक्यांश को गुगली करते हुए, मैं भ्रमित था: अधिकांश मामलों में, लोगों ने LINQ या Enumerable.SequenceEqual () का उपयोग करने का सुझाव दिया, जो लगभग एक ही बात है। StackOverflow पर भी, यह सबसे लोकप्रिय उत्तर था। यानी फार्म का भयावह रूप से लोकप्रिय भ्रम:

"कंपाइलर रन-टाइम वातावरण आपके लूप को अनुकूलित करेगा ताकि आपको प्रदर्शन के बारे में चिंता करने की आवश्यकता न हो।"

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

प्रागितिहास

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

मैंने क्या और क्या परीक्षण किया है

मुख्य बात है

कोड .net 4.0 क्लाइंट प्रोफाइल के लिए सभी नवीनतम अपडेट के साथ विंडोज 7 x64 मशीन पर संकलित और चलाया गया था, अर्थात। Microsoft विज़ुअल स्टडीशन 2010 डिफ़ॉल्ट सेटिंग्स के साथ, और केवल x86 कॉन्फ़िगरेशन के लिए, अर्थात्। यह 32 बिट कोड है। सबसे पहले, क्योंकि मेरे पास आने वाले अधिकांश कोड 32-बिट सिस्टम के लिए लिखे गए हैं। दूसरे, मेरा मानना है कि .Net इस विन्यास में महत्वपूर्ण है। विशेष रूप से, क्योंकि मौजूदा घटकों की एक बड़ी मात्रा 32-बिट के लिए लिखी गई है, और कोई भी उन्हें फिर से नहीं लिखेगा, लेकिन आपको उनके साथ बातचीत करने की आवश्यकता है, अर्थात्। वे अंतिम आवेदन के विन्यास का निर्धारण करेंगे। दूसरे, बहुत कम संख्या में अनुप्रयोगों को वास्तव में 64 बिट्स की आवश्यकता होती है - आवश्यक बिट गहराई मुख्य रूप से मेमोरी आवश्यकताओं और लक्ष्य प्लेटफ़ॉर्म द्वारा निर्धारित की जाती है। आधुनिक 64-बिट x86- संगत प्रोसेसर हार्डवेयर [32] [2] में 32-बिट कार्यों का समर्थन करते हैं। यह तर्कसंगत है कि विंडोज x64 32-बिट कोड को सीधे [3] निष्पादित करके इस सुविधा का उपयोग करता है। प्रारंभिक रूप से 32-बिट एप्लिकेशन को 64 बिट्स में संकलित करना इसके लिए आवश्यक मेमोरी को गुणा करता है और इसके प्रदर्शन को कम करता है, क्योंकि कंपाइलर विकल्प प्रोसेसर टीएलबी आकार, पहले स्तर के कैश को भी नहीं बदलते हैं, और पॉइंटर का आकार दोगुना हो जाता है, जिसमें बदले में आवश्यक डेटा संरेखण सीमा भी होती है। परिवर्तन [4]।

डेटा का आकार

मेरे मूल कार्य में, आकार के 16 बाइट और आकार के बाइट सरणियों की तुलना 1 से 4 * 1024 बाइट से करना आवश्यक था। 16 बाइट्स MD5 का आकार है, 4 Kb विंडोज में एक मानक मेमोरी पेज का आकार है, इसलिए इसे I / O बफर के लिए चुना गया था।
हालांकि, मैंने 1 बाइट से 1/2 मेगाबाइट तक के ब्लॉक पर तुलना का परीक्षण किया, साधारण कारण के लिए कि हैश न केवल आकार में 16 बाइट्स हैं, बल्कि 4 भी हैं, और यहां तक कि 2 बाइट्स (CRC16, CRC32), और मेमोरी पेज केवल 4 हैं किलोबाइट, लेकिन 2 एमबी [2] और 4 एमबी भी। 1/2 एमबी ब्लॉकों पर दिखाए गए परिणाम बड़े ब्लॉकों के साथ काम करने के बारे में एक निष्कर्ष निकालने के लिए पर्याप्त थे, इसके अलावा, मेरा समय असीमित नहीं है (यह परीक्षण के दौरान कंप्यूटर को छूने के लिए बेहतर नहीं है ताकि वर्णित प्रक्रिया से समय न निकालें)।

पहले रनों के परिणामों के आधार पर, मैंने परीक्षण डेटा के 25 विभिन्न आकारों पर विधियों की तुलना करना पर्याप्त पाया। ऐसा करने के लिए, मैंने परीक्षण चक्र का निर्माण किया ताकि पहले परीक्षण सेट में 1-बाइट सरणियाँ शामिल हों, और प्रत्येक अगले चरण में परीक्षण सरणियों का आकार एक ही कारक से गुणा किया गया था।

पैरामीटर कोड में स्थिरांक द्वारा निर्धारित किए गए थे:

private const int CountArrays = 128; //    private const int StartArraySize = 1; //    private const int MaxArraySize = 512 * 1024; //    private const int StepsCount = 25; //  private const int MeasurementsCount = 10; //

मुख्य परीक्षण चक्र इस तरह से देखा गया:

  double sizeMultiplier = 1; DoInvestigationStep(sizeMultiplier); const int MaxMultiplier = MaxArraySize / StartArraySize; var stepMmltiplier = Math.Pow( MaxMultiplier, 1 / (double)StepsCount ); for (var step = 1; step <= StepsCount; step++) { sizeMultiplier = Math.Pow(stepMmltiplier, (double) step); DoInvestigationStep(sizeMultiplier); }

प्रत्येक चरण पर सरणी के आकार की गणना इस तरह की गई थी:

  var arraySize = (int) (StartArraySize * p_SizeMultiplier);

परीक्षण किए गए तरीके

System.Collections.IStructuralEquatable इंटरफ़ेस का उपयोग करना

यह C # के लिए एक अपेक्षाकृत नई विधि है, यह केवल .NET 4 में दिखाई दिया, इसलिए यह मेरे लिए विशेष रुचि का था: यह उत्सुक था कि यह कितना धीमा है।

  private static bool ByteArrayCompareWithIStructuralEquatable(byte[] p_BytesLeft, byte[] p_BytesRight) { IStructuralEquatable eqa1 = p_BytesLeft; return eqa1.Equals(p_BytesRight, StructuralComparisons.StructuralEqualityComparer); }

LINQ, या बल्कि Enumerable.SequenceEqual ()

यह सबसे सरल तरीकों में से एक है, जिसे लागू करना सबसे आसान है। यह सबसे लोकप्रिय तरीका भी है।

  private static bool ByteArrayCompareWithSequenceEqual(byte[] p_BytesLeft, byte[] p_BytesRight) { return p_BytesLeft.SequenceEqual(p_BytesRight); }

PTvoke, CRT मेम्कम्प () फ़ंक्शन के लिए

सैद्धांतिक रूप से, यह सबसे तेज़ तरीका होना चाहिए, लेकिन यह पता चला कि यह हमेशा ऐसा नहीं होता है: मंच के साथ बातचीत का ओवरहेड काफी समय तक खाता है, और कुछ मामलों में यह विधि अपना आकर्षण खो देती है।
यहां मैं इसे उस रूप में लाता हूं जहां मैंने इसे एसओ पर पाया था। यह इस रूप में था कि मैंने इसका परीक्षण किया।
PInvoke.net पर यह थोड़ा अलग दिखता है।

  [DllImport("msvcrt.dll", CallingConvention = CallingConvention.Cdecl)] private static extern int memcmp(byte[] p_BytesLeft, byte[] p_BytesRight, long p_Count); private static bool ByteArrayCompareWithPInvoke(byte[] p_BytesLeft, byte[] p_BytesRight) { // Validate buffers are the same length. // This also ensures that the count does not exceed the length of either buffer. return p_BytesLeft.Length == p_BytesRight.Length && memcmp(p_BytesLeft, p_BytesRight, p_BytesLeft.Length) == 0; }

माथे पर। यानी एक (;;) लूप में बाइट्स की प्रत्यक्ष तुलना

यह दो सरणियों की तुलना करने का सबसे स्पष्ट तरीका है, यही वजह है कि यह ब्याज की है।
प्रारंभ में, विधि बहुत तेज़ नहीं लगती थी, लेकिन यह पता चला कि कई स्थितियों के लिए यह काफी स्वीकार्य है।

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

  private static bool ByteArrayCompareWithSimplest(byte[] p_BytesLeft, byte[] p_BytesRight) { if (p_BytesLeft.Length != p_BytesRight.Length) return false; var length = p_BytesLeft.Length; for (int i = 0; i < length; i++) { if (p_BytesLeft[i] != p_BytesRight[i]) return false; } return true; }

Hafor Stefanson से अनुकूलित असुरक्षित विधि

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

  // Copyright (c) 2008-2013 Hafthor Stefansson // Distributed under the MIT/X11 software license // Ref: http://www.opensource.org/licenses/mit-license.php. private static unsafe bool UnsafeCompare(byte[] a1, byte[] a2) { if (a1 == null || a2 == null || a1.Length != a2.Length) return false; fixed (byte* p1 = a1, p2 = a2) { byte* x1 = p1, x2 = p2; int l = a1.Length; for (int i = 0; i < l / 8; i++, x1 += 8, x2 += 8) if (*((long*) x1) != *((long*) x2)) return false; if ((l & 4) != 0) { if (*((int*) x1) != *((int*) x2)) return false; x1 += 4; x2 += 4; } if ((l & 2) != 0) { if (*((short*) x1) != *((short*) x2)) return false; x1 += 2; x2 += 2; } if ((l & 1) != 0) if (*((byte*) x1) != *((byte*) x2)) return false; return true; } }

परीक्षण पद्धति

परीक्षण सेट

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

एक परीक्षण सेट के रूप में, एक "दांतेदार" सरणी का चयन किया गया था (मूल दस्तावेज में - "द जग्ड एरे")। उदाहरण के लिए, कई विकल्प थे, List<byte[]> और LinkedList<byte[]> , लेकिन विकल्प तत्व के उपयोग के समय के अनुरूप नहीं थे, हालांकि .NET में सरणी यहां चमक नहीं है: सीएलआर किसी भी मामले में सूचकांक की सीमाओं से परे जाने के लिए सूचकांक की जांच करता है। , भले ही यह शून्य आधार वाला एक सरणी है।

टेस्ट डेटा इस तरह से उत्पन्न किया गया था कि सभी सरणियाँ अलग थीं, और सरणी का अलग तत्व बिल्कुल बीच में था।

डेटा जनरेशन टेस्ट करें

  private static void PrepareTestData(int p_ArraySize) { for (int i = 0; i < CountArrays; i++) { var byteArray = new byte[p_ArraySize]; byteArray[p_ArraySize / 2] = (byte) (i & 0x000000ff); s_arrays[i] = byteArray; } }

तुलना करना

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

  for (int i = 0; i < CountArrays; i++) for (int j = 0; j < CountArrays; j++) Compare( s_arrays[i], s_arrays[j] );

हालांकि, एक "लेकिन" है: यदि आप किसी भी तरह से "गणना" के परिणाम का उपयोग नहीं करते हैं, तो सीएलआर को "गणना" न करने का हर अधिकार है। जब मैं C ++ के साथ प्रयोग कर रहा था, तो मैं इससे पहले आया था। "-O3" अनुकूलन चालू होने के कारण, किसी भी चीज़ को मापना बहुत मुश्किल था, क्योंकि समय के बाद यह शून्य हो गया। इसलिए, इस तरह के परिदृश्य को शुरू से ही बाहर करने का निर्णय लिया गया था, ताकि तुलनात्मक कार्य का परिणाम "संचित" हो और वापस आए, और उच्चतम स्तर पर विश्लेषण किया गया।

परिणाम की अनदेखी किए बिना तुलना

  var result = true; for (int i = 0; i < CountArrays; i++) for (int j = 0; j < CountArrays; j++) { var tmp = Compare( s_arrays[i], s_arrays[j] ); result = result && tmp; } return result;

तुलना परिणाम का विश्लेषण

  var stubLocalVar = p_omparisonMethod(); if (stubLocalVar) throw new InvalidOperationException();

चूंकि 5 तुलना विधियां हैं, और उपरोक्त टेम्पलेट आम है, इसलिए सामान्य, "टेम्पलेट" विधि निर्धारित करना तर्कसंगत है, और तुलना विधि इसे पास करना है। इस तरह से:

गलत फ़ंक्शन कॉल विधि

  private static bool CompareArraysWithExternalMethod(Func<byte[], byte[], bool> p_Method) { var result = true; for (int i = 0; i < CountArrays; i++) for (int j = 0; j < CountArrays; j++) { var tmp = p_Method( s_arrays[i], s_arrays[j] ); result = result && tmp; } return result; }

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

  private static bool CompareArraysWithUnsafeMethod(); private static bool CompareArraysWithSimplestMethod(); private static bool CompareArraysWithSequenceEqualMethod(); private static bool CompareArraysWithPInvokeMethod(); private static bool CompareArraysWithIStructuralEquatableMethod();

हालांकि, एक स्तर अधिक है, मैं पहले से ही टेम्पलेट विधि लागू कर सकता हूं।

नीचे दिए गए कोड से पता चलता है कि MeasComparisonTime () फ़ंक्शन, जो तुलना विधि के निष्पादन समय को मापता है, एक पैरामीटर के रूप में फंक के प्रतिनिधि को लेता है। यह उसका रनटाइम है जिसे मापा जाता है।

विधि मापन कार्य

  private static long GetMinimalMesuredValue(int p_MeasurementNumber, long p_PreviousValue, long p_MeasuredValue) { var result = p_MeasurementNumber == 0 ? p_MeasuredValue : Math.Min(p_PreviousValue, p_MeasuredValue); return result; } private static long MeasureComparisonTime(Func<bool> p_Method, long p_PreviousTime, int p_MeasurementNumber) { GC.Collect(); GC.Collect(); s_stopwatch.Start(); var stubLocalVar = p_Method(); s_stopwatch.Stop(); if (stubLocalVar) throw new InvalidOperationException(); var result = GetMinimalMesuredValue(p_MeasurementNumber, p_PreviousTime, s_stopwatch.ElapsedTicks); s_stopwatch.Reset(); return result; }

माप प्रक्रिया

समय को एक मानक स्टॉपवॉच ( वर्ग System.Diagnostics.Stopwatch ) का उपयोग करके मापा गया था, जो QueryPerformanceCounter () पर आधारित है। स्वाभाविक रूप से, उनकी दिलचस्पी मिलीसेकंड में नहीं थी, लेकिन टिक्स में: छोटे सरणियों के मामले में, मिलीसेकंड में सभी माप शून्य होंगे। आरडीटीसीटी [6] पर आधारित अपनी खुद की "साइकिल" का उपयोग करने का एक विचार था, लेकिन, सबसे पहले, पहले कुछ रन से पता चला कि सटीकता वर्तमान तकनीक के लिए पर्याप्त थी, और दूसरी बात, ProcessThread.ProctorAffinity का उपयोग करने की आवश्यकता के बारे में एक चेतावनी, जो इसमें दिखाई दी। प्रलेखन के हाल के संस्करणों का सुझाव है कि इस वर्ग का आधार उपरोक्त प्रोसेसर क्लॉक काउंटर है। सभी माप 10 बार दोहराए गए थे, और सबसे अच्छा समय लिया गया था। संख्या 10 को प्रयोगात्मक रूप से चुना गया था, क्योंकि न्यूनतम समय के साथ काफी सटीक परिणाम दिए गए थे।

सभी माप लेने का कार्य

  private static MeasurementsResults DoMeasurements() { MeasurementsResults result; result.SimplestTime = 0; result.SequenceEqualTime = 0; result.PInvokeTime = 0; result.IStructuralEquatableTime = 0; result.UnsafeTime = 0; for (int measurementNumber = 0; measurementNumber < MeasurementsCount; measurementNumber++) { Console.WriteLine("   {0}", measurementNumber); result.SimplestTime = MeasureComparisonTime(CompareArraysWithSimplestMethod, result.SimplestTime, measurementNumber); result.SequenceEqualTime = MeasureComparisonTime(CompareArraysWithSequenceEqualMethod, result.SequenceEqualTime, measurementNumber); result.PInvokeTime = MeasureComparisonTime(CompareArraysWithPInvokeMethod, result.PInvokeTime, measurementNumber); result.IStructuralEquatableTime = MeasureComparisonTime(CompareArraysWithIStructuralEquatableMethod, result.IStructuralEquatableTime, measurementNumber); result.UnsafeTime = MeasureComparisonTime(CompareArraysWithUnsafeMethod, result.UnsafeTime, measurementNumber); } return result; }

माप के परिणाम और पहले निष्कर्ष

प्रयोग शुरू करने से पहले, मुझे कुछ अंदाजा था कि कौन सा तरीका विजेता बनेगा और कौन सा बाहरी व्यक्ति होगा, लेकिन परिणाम शायद ही मुझे मिले। मेरी भविष्यवाणियाँ पूरी तरह से सही नहीं थीं।

सबसे अच्छा समय (tics)	सरणी आकार (बाइट्स)	असुरक्षित	माथा	PInvoke	SequenceEqual	IStructuralEquatable
276	1	1.7	1	6	10.5	55
276	1	1.7	1	6.3	10.1	55.7
325	2	1.3	1	5.3	11	95.2
374	4	1.1	1	4.8	11.4	121.3
413	8	1	1.3	5	14.1	181.2
412	13	1	1.7	4.7	17.5	252.5
490	23	1	2.3	3.7	22.1	364.8
554	39	1	3.4	3.5	30.1	535.9
691	67	1	4.3	2.9	39.1	727.5
887	114	1	5.6	2.4	50.3	964.1
1212	194	1	4.6	2.1	61.5	1190.9
1875	328	1	4.8	1.8	65.8	1295.8
2897	556	1	5	1.6	71.5	1416.9
4565	942	1	5.3	1.4	76.3	1521.1
7711	1595	1	5.2	1.3	76.2	1521.2
12,482	2702	1	5.4	1.3	79.4	1593.6
20692	4576	1	5.5	1.2	81.2	1626.2
34,369	7750	1	5.6	1.2	82.8	1657.1
58048	13124	1	5.6	1.2	82.9	1661.9
97,511	22226	1	5.6	1.2	83.6	1677.3
173,805	37640	1	5.4	1.1	79.5	1585.7
295,989	63,743	1	5.3	1.1	79.3	1574.9
588,797	107,949	1	4.6	1.1	67.5	1340.9
1010768	182,811	1	4.6	1.1	67	1340.4
1705668	309,590	1	4.6	1.1	67.3	1334.1
2885452	524,287	1	4.6	1.1	67.3	1329.1

परिणाम इस प्रकार थे:
पहला: CRT फ़ंक्शन को बस अच्छी तरह से अनुकूलित किया जाना है, और मैंने गणना की कि एक निश्चित चरण (परीक्षण सरणी का आकार) पर इसकी गति प्लेटफ़ॉर्म कॉल के ओवरहेड को अवरुद्ध करेगी, लेकिन ऐसा नहीं हुआ। बाद में, मैंने बहुत बड़े सरणियों के साथ परीक्षण दोहराया, लेकिन 1.5 मेगाबाइट पर भी असुरक्षित कोड तेजी से निकला।

दूसरा: मैंने अनुमान लगाया कि IStructuralEquatable धीमी हो जाएगी, लेकिन संख्याओं ने मुझे मारा: मुझे निश्चित रूप से इसकी उम्मीद नहीं थी।

डायजेस्सेम्बलिंग और व्यक्तिगत कार्यों का विश्लेषण

बड़े सरणियों पर असुरक्षित और सरलतम के बीच इस तरह का एक गंभीर अंतर (मुझे "लाभ" से दो से तीन गुना अधिक की उम्मीद है) यह बताता है कि नेट में सरणी तत्वों के छोरों और पहुंच के अनुकूलन के साथ, सब कुछ उतना आसान नहीं है जितना कि .Net विज्ञापनदाताओं का कहना है। तदनुसार, मैंने खुद को JIT'er के काम के परिणामों को देखने की खुशी से इनकार नहीं किया, अर्थात्। सीधे उत्पन्न मशीन कोड।

तुलनाअरेसविथस्मिथप्लेस्टमेथोड () फ़ंक्शन का विश्लेषण

ऐसा करने के लिए, थ्रेड। स्लीप (60 * 1000) विधि की शुरुआत में डाला गया था; रिलीज़ बिल्ड लॉन्च करने के बाद, मैंने ओलडिब्यूग प्रक्रिया को उठाया। सीएलआर अनुकूलन को किसी भी तरह से कम नहीं करने के लिए इस तरह के एक मुश्किल कदम की आवश्यकता थी - तस्वीर को देखने के लिए जैसा वह है।

तीर के साथ डिबगर विंडो काँट

Ntdll.NtDelayExecution () और SleepEx () से कॉल स्टैक नीचे जाने पर, मैंने अपना कार्य पाया और, सावधानीपूर्वक अध्ययन के बाद, एक बार फिर अप्रिय रूप से आश्चर्यचकित हो गया। मुझे यहाँ क्या पसंद नहीं था:

एक एकल RngChkFail चेक (एक बार में पूरे लूप के लिए) के बजाय, CLR यह जाँच प्रत्येक इंडेक्स के लिए करता है !!!
चक्र उस रूप में बना रहा जिसमें मैंने इसे लिखा था: संकलक ने इसे "तैनात" नहीं किया था।
इसलिए, तुलना बाइट से बनी रही, हालांकि CLR इसे अनुकूलित करने में काफी सक्षम था, उदाहरण के लिए, 4 बाइट (रजिस्टर आकार) की तुलना करके।
एकल उपसंहार के साथ एकल वापसी के बजाय और स्टैक को साफ़ करने के लिए, सीएलआर ने उन्हें तीन बार कॉपी किया, जिससे कोड "सूजन" बना। वास्तव में, मशीन कोड C # कोड को लगभग एक से एक दोहराता है। इस संबंध में, सवाल उठता है: क्या उसने कोड को बिल्कुल अनुकूलित किया था? क्या वह जानता है कि यह कैसे करना है?
संभवतः पिछले पैराग्राफ (सूजन कोड) के लिए धन्यवाद, फ़ंक्शन इनबिल्ड नहीं था।

UnsafeCompare () फ़ंक्शन विश्लेषण

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

प्रविष्टि थ्रेड। सो ()

  private static bool CompareArraysWithUnsafeMethod() { var result = true; for (int i = 0; i < CountArrays; i++) for (int j = 0; j < CountArrays; j++) { Thread.Sleep( 60 * 1000 ); var tmp = UnsafeCompare(s_arrays[i], s_arrays[j]);

इस फ़ंक्शन का पहला आधा हिस्सा भी ब्याज का है, अर्थात्। जब तक UnsafeCompare () कहा जाता है। यह, पहले की तरह, यह दर्शाता है कि सरणी के एक तत्व तक किसी भी पहुंच के कारण सूचकांक को सरणी की सीमाओं के भीतर घटना के लिए जाँच की जा सकती है। मैंने लिस्टिंग में इस पर जोर दिया।

सीपीयू डिस्कस की तुलनाएयर्रेज़विथयूंसफेम मेथोड

 ;Address Hex dump Command Comments 001B0B88 55 push ebp ;   001B0B89 8BEC mov ebp, esp 001B0B8B 57 push edi 001B0B8C 56 push esi 001B0B8D 53 push ebx 001B0B8E BF 01000000 mov edi, 1 ; result = true; 001B0B93 33DB xor ebx, ebx ; for (int i = 0; 001B0B95 33F6 xor esi, esi ; for (int j = 0; 001B0B97 B9 60EA0000 mov ecx, 0EA60 ; Thread.Sleep( 60 * 1000 ); 001B0B9C E8 0CFBC161 call clr.ThreadNative::Sleep 001B0BA1 8B15 A8337A03 mov edx, [s_arrays] ; EDX <-- s_arrays 001B0BA7 3B5A 04 cmp ebx, [edx+4] ; Compare(s_arrays.Length,  ) (1) !!! 001B0BAA 73 31 jae short stub_CLR.JIT_RngChkFail 001B0BAC 8B4C9A 0C mov ecx, [ebx*4+edx+0C] ; ECX <-- s_arrays[i] 001B0BB0 3B72 04 cmp esi, [edx+4] ; Compare(s_arrays.Length,  ) (2) !!! 001B0BB3 73 28 jae short stub_CLR.JIT_RngChkFail 001B0BB5 8B54B2 0C mov edx, [esi*4+edx+0C] ; EDX <-- s_arrays[j] 001B0BB9 FF15 F0381400 call near UnsafeCompare

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

UnsafeCompare ()। ParametersChecking

 ;a1 ========> ECX ;a2 ========> EDX ;Address Hex dump Command Comments 001B0BF8 55 push ebp ;   001B0BF9 8BEC mov ebp, esp 001B0BFB 57 push edi ;     , , ,  001B0BFC 56 push esi ;     001B0BFD 53 push ebx ; 001B0BFE 83EC 0C sub esp, 0C ;       3*sizeof(DWORD), ..  3  001B0C01 33C0 xor eax, eax ; (!) 001B0C03 8945 F0 mov [ebp-10], eax ; var1 <-- 0 (!) 001B0C06 8945 EC mov [ebp-14], eax ; var2 <-- 0 (!) 001B0C09 85C9 test ecx, ecx ; Compare(a1, null) 001B0C0B 74 0C je short return1 001B0C0D 85D2 test edx, edx ; Compare(a2, null) 001B0C0F 74 08 je short return1 001B0C11 8B41 04 mov eax, [ecx+4] ; eax <-- a1.Length 001B0C14 3B42 04 cmp eax, [edx+4] ; Compare(eax, a2.Length) 001B0C17 74 0A je short argsIsValid return1: 001B0C19 33C0 xor eax, eax ; result <-- 0 001B0C1B 8D65 F4 lea esp, [ebp-0C] 001B0C1E 5B pop ebx 001B0C1F 5E pop esi 001B0C20 5F pop edi 001B0C21 5D pop ebp 001B0C22 C3 ret argsIsValid: ;

फास्टकॉल कॉलिंग कन्वेंशन के अनुसार, जो .NET फ्रेमवर्क [7] [8] का अनुसरण करता है, पहला और दूसरा पैरामीटर ईएक्सएक्स और एडीएक्स रजिस्टर में हैं, बाएं से दाएं क्रम में। उपरोक्त सूची में, इनपुट मापदंडों की एक क्रमिक जांच स्पष्ट रूप से दिखाई देती है, यह लगभग स्पष्ट रूप से C # में कोड से मेल खाती है

  if (a1 == null || a2 == null || a1.Length != a2.Length) return false;

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

  private static unsafe int func1(byte[] param1) { fixed (byte* p = param1) { return *p; } }

सबसे सरल असुरक्षित फ़ंक्शन का प्लाज्मा

 ;param1 ========> ECX Address Hex dump Command Comments $ ==> 55 push ebp ;   $+1 8BEC mov ebp, esp $+3 50 push eax ; (!) $+4 33C0 xor eax, eax ; (!) $+6 8945 FC mov [ebp-4], eax ; var1 <-- 0 (!) $+9 85C9 test ecx, ecx ; Compare(param1, null) $+B 74 06 je short param_is_null $+D 8379 04 00 cmp dword ptr [ecx+4], 0 ; Compare(param1.Length, 0) $+11 75 07 jne short not_zero_len param_is_null: $+13 33D2 xor edx, edx $+15 8955 FC mov [ebp-4], edx ; var1 <-- 0 $+18 EB 0C jmp short ret_1 not_zero_len: $+1A 8379 04 00 cmp dword ptr [ecx+4], 0 $+1E 76 10 jbe short call.JIT_RngChkFail $+20 8D49 08 lea ecx, [ecx+8] ; ecx <-- param1.BufferPointer $+23 894D FC mov [ebp-4], ecx ; var1 <-- ecx ret_1: $+26 8B45 FC mov eax, [ebp-4] ; eax <-- var1 $+29 0FB600 movzx eax, byte ptr [eax] ; eax <-- *eax $+2C 8BE5 mov esp, ebp ;   $+2E 5D pop ebp $+2F C3 ret call.JIT_RngChkFail: $+30 E8 B3BDC861 call clr.JIT_RngChkFail $+35 CC int3

उपरोक्त सूची से, यह स्पष्ट हो जाता है कि जेआईटी संकलन के परिणामस्वरूप, सामान्य प्रयोजन के रजिस्टरों की उपलब्धता की परवाह किए बिना, निश्चित क्लॉज में चर को आवश्यक रूप से स्टैक पर धकेल दिया जाता है। यह इस तथ्य से स्पष्ट रूप से देखा जाता है कि ईएक्सएक्स रजिस्टर को स्टैक पर सहेजा गया था, भविष्य में उपयोग नहीं किया गया था और इसलिए, संचालन के लिए स्वतंत्र और सुलभ था (फ़ंक्शन की शुरुआत से 0x26 को ऑफसेट करने के लिए), लेकिन अस्थायी डेटा को संग्रहीत करने के लिए ऑफ़सेट वेरिएबल स्टैक चर का उपयोग किया गया था [ ebp-4] (इसे var1 कहते हैं)। चर को तुरंत शून्य से आरंभीकृत किया जाता है, इस तथ्य के बावजूद कि इस मूल्य का उपयोग नहीं किया जाता है, लेकिन बस ओवरराइट किया जाता है। उदाहरण के लिए, ऑफसेट 0x15 पर, शून्य को फिर से var1 में दर्ज किया जाता है, इस तथ्य के बावजूद कि उस क्षण तक शून्य पहले ही वहां संग्रहीत था।

इस प्रकार, यह स्पष्ट हो जाता है कि UnsafeCompare.CPU Disasm.ParametersChecking लिस्टिंग में हाइलाइट की गई लाइनें बहुत ज्यादा मायने नहीं रखती हैं, यह संकलन का केवल एक साइड इफेक्ट है। इसके अलावा, उपरोक्त लिस्टिंग से, यह स्पष्ट हो जाता है कि सरणी को तीन चरणों में निश्चित अभिव्यक्ति में चेक किया गया है: पहला, सरणी शून्य के लिए जाँच की जाती है, फिर इसकी लंबाई शून्य की समानता के लिए जाँच की जाती है (jne कमांड केवल ZF का विश्लेषण करती है), और उसके बाद केवल शून्य और नकारात्मक मानों की समानता के लिए ( jbe ZF और CF दोनों की जाँच करता है)। मेरे दृष्टिकोण से, यह बहुत अजीब है कि पिछले दो कार्यों को एक में संयोजित नहीं किया गया था, और इससे भी अधिक अजीब बात यह है कि सीएमपी कमांड को दो बार निष्पादित किया जाता है, क्योंकि सशर्त कूद झंडे को रीसेट नहीं करता है। अन्य बातों के अलावा, मैं आप में से उन लोगों के लिए ईमानदारी से आभारी हूं, जिन्होंने इस लाइन को पढ़ा, क्योंकि इसका मतलब है कि मैंने व्यर्थ में कोशिश नहीं की, और कोडांतरक लिस्टिंग में मेरी खुदाई व्यर्थ नहीं थी।

प्रयोग आगे कोड विश्लेषण को सरल करता है।

तुलनाअधिग्रह की स्थिर धारा

 argsIsValid: 001B0C23 8379 04 00 cmp dword ptr [ecx+4], 0 ; Compare(a1.Length, 0)       001B0C27 75 07 jne short a1Len_NonZero ;   001B0C29 33C0 xor eax, eax 001B0C2B 8945 F0 mov [ebp-10], eax ; var1 <-- 0 001B0C2E EB 10 jmp short a1Len_Zero a1Len_NonZero: 001B0C30 8379 04 00 cmp dword ptr [ecx+4], 0 ; Compare(a1.Length, 0)  ()     001B0C34 0F86 B5000000 jbe call.JIT_RngChkFail ;     001B0C3A 8D41 08 lea eax, [ecx+8] ; eax <-- a1.BufferPointer 001B0C3D 8945 F0 mov [ebp-10], eax ; var1 <-- eax a1Len_Zero: 001B0C40 837A 04 00 cmp dword ptr [edx+4], 0 ; Compare(a2.Length, 0)       001B0C44 75 07 jne short a2Len_NonZero ;   001B0C46 33D2 xor edx, edx 001B0C48 8955 EC mov [ebp-14], edx ; var2 <-- 0 001B0C4B EB 10 jmp short part3 a2Len_NonZero: 001B0C4D 837A 04 00 cmp dword ptr [edx+4], 0 ; Compare(a2.Length, 0)  ()     001B0C51 0F86 98000000 jbe call.JIT_RngChkFail ;     001B0C57 8D52 08 lea edx, [edx+8] ; edx <-- a2.BufferPointer 001B0C5A 8955 EC mov [ebp-14], edx ; var2 <-- edx

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

 part3: ; ECX <======= a1 ; EDX <======= a2.BufferPointer ; var1 <======= a1.BufferPointer ; var2 <======= a2.BufferPointer 001B0C5D 8B45 F0 mov eax, [ebp-10] ; eax <-- var1 001B0C60 8BF0 mov esi, eax ; esi <-- eax 001B0C62 8B45 EC mov eax, [ebp-14] ; eax <-- var2 001B0C65 8BF8 mov edi, eax ; edi <-- eax 001B0C67 8B41 04 mov eax, [ecx+4] ; eax <-- a1.Length 001B0C6A 8945 E8 mov [ebp-18], eax ; var3 <-- eax

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

8 बाइट लूप

 001B0C6D 33C9 xor ecx, ecx ;   <-- 0 001B0C6F 8BD8 mov ebx, eax ; ebx <-- a1.Length 001B0C71 85DB test ebx, ebx 001B0C73 79 03 jns short ebx_greaterZero 001B0C75 83C3 07 add ebx, 7 ;  ,  7 ebx_greaterZero: 001B0C78 C1FB 03 sar ebx, 3 ; ebx <-- a1.Length / 8 001B0C7B 85DB test ebx, ebx 001B0C7D 7E 1D jle short fourBytesComparing for8_body: 001B0C7F 8B06 mov eax, [esi] 001B0C81 8B56 04 mov edx, [esi+4] 001B0C84 3B57 04 cmp edx, [edi+4] 001B0C87 75 04 jne short setResult_jumpReturn 001B0C89 3B07 cmp eax, [edi] 001B0C8B 74 04 je short for8_increment setResult_jumpReturn: 001B0C8D 33C0 xor eax, eax ; result <-- 0 001B0C8F EB 56 jmp short return2 ; goto return for8_increment: 001B0C91 41 inc ecx 001B0C92 83C6 08 add esi, 8 001B0C95 83C7 08 add edi, 8 for8_expression: 001B0C98 3BD9 cmp ebx, ecx 001B0C9A ^ 7F E3 jg short for8_body

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

यह हड़ताली है कि संकलक ने CMPSD स्ट्रिंग निर्देश का उपयोग यहां नहीं किया है, अर्थात्, इसका "संक्षिप्त" रूप, जो उचित झंडे की स्थापना करते हुए esi और edi पते पर रखे DWORD ब्लॉक की तुलना करता है। इस स्थिति में, मशीन कोड का आकार कई गुना छोटा होगा: यहाँ पर mov कमांड 2 और 3 बाइट्स आकार में है, cmp कमांड 2 और 3 बाइट्स आकार में है, और प्रत्येक CMPSD कमांड का आकार (संक्षिप्त रूप में) केवल 1 बाइट होगा, अर्थात । दो टीमों के लिए केवल 2 बाइट्स। इससे पता चलता है कि JIT कंपाइलर कोड को ऑप्टिमाइज़ नहीं करना चाहता है।

उपरोक्त लिस्टिंग से, यह स्पष्ट है कि कमांड के एक जोड़े, जिनमें से पहला ईआरएक्स को अग्रेषित कर रहा है, एक पैटर्न है जो कंपाइलर सख्ती से पालन करता है।

यदि ऐसी मात्रा बनी रहती है, तो DWORD आकार के ब्लॉक की तुलना करने का प्रयास किया जाता है:

 fourBytesComparing: 001B0C9C F745 E8 0400000 test dword ptr [ebp-18], 00000004 ; ZF <-- (var3 & 4) == 0 001B0CA3 74 10 je short length_lowerThenFour 001B0CA5 8B06 mov eax, [esi] 001B0CA7 3B07 cmp eax, [edi] 001B0CA9 74 04 je short dwords_equals ;   ,     001B0CAB 33C0 xor eax, eax 001B0CAD EB 38 jmp short return2 dwords_equals: 001B0CAF 83C6 04 add esi, 4 001B0CB2 83C7 04 add edi, 4

यदि इस तरह की मात्रा बनी रहती है, तो WORD आकार के साथ ब्लॉक की तुलना करने का प्रयास किया जाता है:

 length_lowerThenFour: 001B0CB5 F745 E8 0200000 test dword ptr [ebp-18], 00000002 ; ZF <-- (var3 & 2) == 0 001B0CBC 74 10 je short length_lowerThenTwo 001B0CBE 0FBF06 movsx eax, word ptr [esi] 001B0CC1 66:3B07 cmp ax, [edi] 001B0CC4 74 04 je short words_equals ;   ,     001B0CC6 33C0 xor eax, eax 001B0CC8 EB 1D jmp short return2 words_equals: 001B0CCA 46 inc esi 001B0CCB 46 inc esi 001B0CCC 47 inc edi 001B0CCD 47 inc edi

यदि इस तरह की मात्रा बनी रहती है तो BYTE आकार के ब्लॉक की तुलना करने का प्रयास किया जाता है:

 length_lowerThenTwo: 001B0CCE F745 E8 0100000 test dword ptr [ebp-18], 00000001 ; ZF <-- (var3 & 1) == 0 001B0CD5 74 0B je short 001B0CE2 001B0CD7 0FB606 movzx eax, byte ptr [esi] 001B0CDA 3A07 cmp al, [edi] 001B0CDC 74 04 je short 001B0CE2 ;   ,     001B0CDE 33C0 xor eax, eax 001B0CE0 EB 05 jmp short return2 001B0CE2 B8 01000000 mov eax, 1

परिणाम लौटाना और एक अपवाद फेंकना:

 return2: 001B0CE7 8D65 F4 lea esp, [ebp-0C] 001B0CEA 5B pop ebx 001B0CEB 5E pop esi 001B0CEC 5F pop edi 001B0CED 5D pop ebp 001B0CEE C3 ret JIT_RngChkFail: 001B0CEF E8 C4B1DB61 call clr.JIT_RngChkFail 001B0CF4 CC int3

मेमकैंप () फ़ंक्शन का सीआरटी विश्लेषण

यह फ़ंक्शन भी दिलचस्प है क्योंकि यह न केवल दो बफ़र्स की तुलना करता है, बल्कि उनके बीच के संबंध का भी पता लगाता है, जिसका अर्थ है कि यह उन लोगों की तुलना में अधिक जटिल है जिन्हें पहले माना जाता था।

डिबगर द्वारा हुक किए जाने के बाद, मुझे पता चला कि C: \ Windows \ SysWOW64 \ msvcrt.dll संस्करण 7.0.7601.17744 को आधार पते 0x76C20000 में प्रोसेस मेमोरी में लोड किया गया था।

डीबगर जानकारी Windows

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

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

अजीब निर्देश:

 76C37975 . 8BFF mov edi, edi ; <--(!)    INT msvcrt.memcmp(buf1,buf2,count) 76C37977 . 55 push ebp 76C37978 . 8BEC mov ebp, esp

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

यह एक हॉट-पैच पॉइंट है।
एमओवी ईडीआई, ईडीआई निर्देश एक दो-बाइट एनओपी है, जो एक कूद निर्देश में पैच करने के लिए बस पर्याप्त जगह है ताकि फ़ंक्शन को मक्खी पर अपडेट किया जा सके। आशय यह है कि MOV EDI, EDI निर्देश को दो बाइट JMP $ -5 निर्देश के साथ बदल दिया जाएगा, जो फ़ंक्शन के शुरू होने से तुरंत पहले आने वाले पांच बाइट्स पैच स्पेस को पुनः निर्देशित करता है। फुल जंप इंस्ट्रक्शन के लिए पांच बाइट्स पर्याप्त हैं, जो एड्रेस स्पेस में कहीं और स्थापित रिप्लेसमेंट फंक्शन को कंट्रोल भेज सकता है।
blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214405.aspx

लंबी छलांग और एक बहुत बड़ा स्विच

 Address Hex dump Command Comments 75A9797C . 8B7D 10 mov edi, [ebp+10] ; edi <-- length 75A9797F . 8BC7 mov eax, edi 75A97981 . 83E8 00 sub eax, 0 ; 75A97984 . 0F84 E7070100 je msvcrt.zeroResult_GoReturn ; (length == 0)=> {result <-- 0, goto return;} (!)      ;    ;    75A979BC . 83FF 1F cmp edi, 1F ; Switch (cases 1..1F, 32. exits) 75A979BF . 77 5B ja short msvcrt.75A97A1C 75A979C1 . FF24BD 1F8AA975 jmp near [edi*4+msvcrt.75A98A1F] ; (!)       (!)      ;    ;    75A98A1F . 1C7AA975 dd msvcrt.75A97A1C ; (00)   ,  jump     75A98A23 . E88AA975 dd msvcrt.75A98AE8 ; (01) 75A98A27 . CA8AA975 dd msvcrt.75A98ACA ; (02) 75A98A2B . 8C8BA975 dd msvcrt.75A98B8C ; (03) 75A98A2F . 0A7AA975 dd msvcrt.75A97A0A ; (04) 75A98A33 . 088FA975 dd msvcrt.75A98F08 ; (05) 75A98A37 . B88AA975 dd msvcrt.75A98AB8 ; (06) 75A98A3B . 758BA975 dd msvcrt.75A98B75 ; (07) 75A98A3F . F479A975 dd msvcrt.75A979F4 ; (08) 75A98A43 . 238FA975 dd msvcrt.75A98F23 ; (09) 75A98A47 . 9F8AA975 dd msvcrt.75A98A9F ; (0A) 75A98A4B . A18BA975 dd msvcrt.75A98BA1 ; (0B) 75A98A4F . DE79A975 dd msvcrt.75A979DE ; (0C) 75A98A53 . 3A8FA975 dd msvcrt.75A98F3A ; (0D) 75A98A57 . FD8AA975 dd msvcrt.75A98AFD ; (0E) 75A98A5B . ED8EA975 dd msvcrt.75A98EED ; (0F) 75A98A5F . C879A975 dd msvcrt.75A979C8 ; (10) 75A98A63 . 518FA975 dd msvcrt.75A98F51 ; (11) 75A98A67 . BA8EA975 dd msvcrt.75A98EBA ; (12) 75A98A6B . 6A98A975 dd msvcrt.75A9986A ; (13) 75A98A6F . 8990A975 dd msvcrt.75A99089 ; (14) 75A98A73 . CD98A975 dd msvcrt.75A998CD ; (15) 75A98A77 . D58EA975 dd msvcrt.75A98ED5 ; (16) 75A98A7B . 8598A975 dd msvcrt.75A99885 ; (17) 75A98A7F . 1899A975 dd msvcrt.75A99918 ; (18) 75A98A83 . E898A975 dd msvcrt.75A998E8 ; (19) 75A98A87 . 698FA975 dd msvcrt.75A98F69 ; (1A) 75A98A8B . 9D98A975 dd msvcrt.75A9989D ; (1B) 75A98A8F . 3399A975 dd msvcrt.75A99933 ; (1C) 75A98A93 . 0099A975 dd msvcrt.75A99900 ; (1D) 75A98A97 . 848FA975 dd msvcrt.75A98F84 ; (1E) 75A98A9B . B598A975 dd msvcrt.75A998B5 ; (1F)

पूरे समारोह के विश्लेषण की बड़ी जटिलता के कारण, इसे पूरी तरह से अलग नहीं करने का निर्णय लिया गया था, इसके अलावा, केवल दो चीजें रुचि के थीं:

(overhead) «» (PInvoke)
.

फ़ंक्शन को कॉल करने के ओवरहेड का अनुमान लगाने के लिए, प्रबंधित कोड से फ़ंक्शन की शुरुआत में ही कोड का पता लगाने का निर्णय लिया गया था। ऐसा करने के लिए, फ़ंक्शन की शुरुआत में एक ब्रेकपॉइंट सेट किया गया था, और थ्रेड.सलीप () से लौटने के बाद, ट्रेसिंग शुरू हुई। हालांकि, पहले ट्रेस प्रयास का परिणाम असफल रहा: ट्रेस लॉग बहुत बड़ा (लगभग 100 हजार लाइनें) निकला, जिसने संभवतः इंगित किया कि DllMain () को निष्पादित किया गया था, इस बात की भी संभावना थी कि कुछ CLR कोड कैप्चर किए गए थे, शायद JIT कंपाइलर कोड। वास्तव में वहाँ क्या किया गया था, मुझे पता नहीं शुरू हुआ: यह दिलचस्पी का नहीं था, क्योंकि इस तरह के एक प्रारंभ कोड को केवल एक बार निष्पादित किया जाता है और लगभग समग्र तस्वीर को प्रभावित नहीं करता है। इस कोड को बाहर करने के लिए, मैंने Thread.Sleep () और फिर से ट्रेस करने से पहले memcmp () में एक और कॉल सम्मिलित की।नतीजतन, मुझे सौ से अधिक लाइनें मिल गईं।

ट्रेस लॉग विंडो

ट्रेस लॉग का हिस्सा:

 main 00480AEA call 0031C19C ESP=0016F368 ;    main clr.628C3B5F call near [eax+14] ESP=0016F248 ; (1) ;    main 00480B87 mov eax, [ebp-1C] EAX=00313880 main 00480B8A mov eax, [eax+14] EAX=0031391C main 00480B8D mov ecx, [eax] ECX=75A97975 ; (2) main 00480B8F push dword ptr [ebp+0C] ESP=0016F328 main 00480B92 push dword ptr [ebp+8] ESP=0016F324 main 00480B95 push edi ESP=0016F320 main 00480B96 push dword ptr [ebp-10] ESP=0016F31C main 00480B99 mov dword ptr [ebp-2C], 0 main 00480BA0 mov [ebp-28], esp main 00480BA3 mov dword ptr [ebp-24], 480BB0 main 00480BAA mov byte ptr [ebx+8], 0 main 00480BAE call ecx ESP=0016F318 ; (3) main msvcrt.memcmp mov edi, edi -------- Logging stopped

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

मुख्य फ़ंक्शन कोड का मूल्यांकन

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

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

संशोधित सरणी तुलना समारोह

  private static bool CompareArraysWithPInvokeMethod() { var result = true; for (int i = CountArrays - 1; i >= 0; i--) //    for (int j = 0; j < CountArrays; j++) { var tmp = ByteArrayCompareWithPInvoke(s_arrays[i], s_arrays[j]); result = result && tmp; } return result; }

पहला निशान (सबसे अच्छा मामला)

 main msvcrt.memcmp mov edi, edi main msvcrt.75A97977 push ebp ESP=0041EC74 main msvcrt.75A97978 mov ebp, esp EBP=0041EC74 main msvcrt.75A9797A push esi ESP=0041EC70 main msvcrt.75A9797B push edi ESP=0041EC6C main msvcrt.75A9797C mov edi, [ebp+10] EDI=00080000 ; edi <-- count main msvcrt.75A9797F mov eax, edi EAX=00080000 ; eax <-- edi main msvcrt.75A97981 sub eax, 0 ; if (eax == 0) {result <-- 0; return;} main msvcrt.75A97984 je msvcrt.zeroResult_GoReturn main msvcrt.75A9798A dec eax EAX=0007FFFF main msvcrt.75A9798B je msvcrt.75A98C10 main msvcrt.75A97991 dec eax EAX=0007FFFE main msvcrt.75A97992 je msvcrt.75A9E610 main msvcrt.75A97998 dec eax EAX=0007FFFD main msvcrt.75A97999 je msvcrt.75A9E5DF main msvcrt.75A9799F dec eax EAX=0007FFFC main msvcrt.75A979A0 je msvcrt.75A98BD2 main msvcrt.75A979A6 mov ecx, [ebp+0C] ECX=034C53B8 ; ecx <-- buf1 main msvcrt.75A979A9 mov eax, [ebp+8] EAX=05C41038 ; eax <-- buf2 main msvcrt.75A979AC push ebx ESP=0041EC68 main msvcrt.75A979AD push 20 ESP=0041EC64 ;        main msvcrt.75A979AF pop edx EDX=00000020, ESP=0041EC68 ;--------------------------------   main msvcrt.75A979B0 cmp edi, edx main msvcrt.75A979B2 jae msvcrt.75A993A7 main msvcrt.75A993A7 mov esi, [eax] ESI=4241403F main msvcrt.75A993A9 cmp esi, [ecx] main msvcrt.75A993AB jne msvcrt.75AA80E7 ;   main msvcrt.75AA80E7 movzx esi, byte ptr [eax] ESI=0000003F main msvcrt.75AA80EA movzx ebx, byte ptr [ecx] EBX=00000001 main msvcrt.75AA80ED sub esi, ebx ESI=0000003E ;      DWORD' main msvcrt.75AA80EF jne msvcrt.75AA8178 main msvcrt.75AA8178 xor ebx, ebx EBX=00000000 ;     ebx main msvcrt.75AA817A test esi, esi main msvcrt.75AA817C setg bl EBX=00000001 main msvcrt.75AA817F lea ebx, [ebx+ebx-1] main msvcrt.75AA8183 mov esi, ebx ESI=00000001 main msvcrt.75AA8185 test esi, esi main msvcrt.75AA8187 jne msvcrt.75A98AB1 main msvcrt.75A98AB1 mov eax, esi EAX=00000001 main msvcrt.75A98AB3 jmp msvcrt.75A97A1E main msvcrt.75A97A1E pop ebx EBX=00852AE0, ESP=0041EC6C main msvcrt.return1 pop edi ESP=0041EC70, EDI=034C53B8 main msvcrt.75A97A20 pop esi ESP=0041EC74, ESI=034C53B0 main msvcrt.75A97A21 pop ebp ESP=0041EC78, EBP=0041ECC4 main msvcrt.75A97A22 ret ESP=0041EC7C

पहली चीज जो आपकी नजर को यहां पकड़ती है, वह है विशेष मामलों की हैंडलिंग, यानी। ऐसे मामले जहां पैरामीटर गिनती [0..4] के भीतर है, काफी असामान्य बना है। कोई केवल अनुमान लगा सकता है कि क्या यह स्विच क्लॉज़ को संकलित करने का परिणाम है या क्या वास्तव में एक स्थानीय चर वहाँ स्थापित किया गया था, जिसे चेक के प्रत्येक चरण में घटाया गया था। हालाँकि, डीबगिंग जानकारी का दावा है कि यह अभी भी एक स्विच था। अनुकूलन के दृष्टिकोण से, यह काफी उचित कार्रवाई है, क्योंकि लूप आरंभीकरण नहीं किया जाता है।

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

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

अनुक्रमिक डबल शब्द बाइट तुलना

 ;Address Hex dump Command Comments 75AA80E7 > 0FB630 movzx esi, byte ptr [eax] 75AA80EA . 0FB619 movzx ebx, byte ptr [ecx] 75AA80ED . 2BF3 sub esi, ebx ;      DWORD' 75AA80EF .- 0F85 83000000 jne msvcrt.75AA8178 ;       ebx 75AA80F5 > 0FB670 01 movzx esi, byte ptr [eax+1] 75AA80F9 . 0FB659 01 movzx ebx, byte ptr [ecx+1] 75AA80FD . 2BF3 sub esi, ebx 75AA80FF .- 0F84 1EF9FEFF je msvcrt.75A97A23 ;    75A97A23 > 0FB670 02 movzx esi, byte ptr [eax+2] 75A97A27 . 0FB659 02 movzx ebx, byte ptr [ecx+2] 75A97A2B . 2BF3 sub esi, ebx 75A97A2D .- 74 15 je short msvcrt.75A97A44 ;    75A97A44 > 0FB670 03 movzx esi, byte ptr [eax+3] 75A97A48 . 0FB659 03 movzx ebx, byte ptr [ecx+3] 75A97A4C . 2BF3 sub esi, ebx 75A97A4E .- 0F84 5F190000 je msvcrt.75A993B3 ;  -   75A97A54 . 33DB xor ebx, ebx ;     ebx 75A97A56 . 85F6 test esi, esi 75A97A58 . 0F9FC3 setg bl 75A97A5B . 8D5C1B FF lea ebx, [ebx+ebx-1] 75A97A5F . 8BF3 mov esi, ebx 75A97A61 .- E9 4D190000 jmp msvcrt.75A993B3 ;    75A993B1 . |33F6 xor esi, esi 75A993B3 > |85F6 test esi, esi 75A993B5 .-|0F85 F6F6FFFF jne msvcrt.75A98AB1

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

पहले दूसरे ट्रेस के लॉग को देखें: लूप के एक पुनरावृत्ति में 8 दोहरे शब्दों की तुलना की जाती है, और यह अच्छा है: यह स्पष्ट है कि लूप का विस्तार होता है, और दूसरी ओर, प्रत्येक तुलना के बाद, ठीक उसी बेकार कोड को दर्ज किया जाता है: 0: esi रजिस्टर में दर्ज किया जाता है और esi रजिस्टर की सामग्री का विश्लेषण किया जाता है। । मुझे इस बारे में कोई धारणा नहीं है कि यह क्यों किया गया था, लेकिन इस बारे में एक धारणा है कि यह कैसे हो सकता है: सबसे पहले, यह कुछ मैक्रो के परिणाम के समान है जो कोडांतरक कोड का गठन किया, और दूसरी बात, ऐसा लगता है Microsoft C कंपाइलर उतना अच्छा नहीं है जितना मैंने इसके बारे में पहले सोचा था।

दूसरा निशान (केवल लूप)

 ;--------------------------------   main msvcrt.75A979B0 cmp edi, edx main msvcrt.75A979B2 jae msvcrt.75A993A7 main msvcrt.75A993A7 mov esi, [eax] ESI=00000000 main msvcrt.75A993A9 cmp esi, [ecx] main msvcrt.75A993AB jne msvcrt.75AA80E7 main msvcrt.75A993B1 xor esi, esi main msvcrt.75A993B3 test esi, esi main msvcrt.75A993B5 jne msvcrt.75A98AB1 main msvcrt.75A993BB mov esi, [eax+4] main msvcrt.75A993BE cmp esi, [ecx+4] main msvcrt.75A993C1 jne msvcrt.75AA811F main msvcrt.75A993C7 xor esi, esi main msvcrt.75A993C9 test esi, esi main msvcrt.75A?993CB jne msvcrt.75A98AB1 main msvcrt.75A993D1 mov esi, [eax+8] main msvcrt.75A993D4 cmp esi, [ecx+8] main msvcrt.75A993D7 jne msvcrt.75A97A9A main msvcrt.75A993DD xor esi, esi main msvcrt.75A993DF test esi, esi main msvcrt.75A993E1 jne msvcrt.75A98AB1 main msvcrt.75A993E7 mov esi, [eax+0C] main msvcrt.75A993EA cmp esi, [ecx+0C] main msvcrt.75A993ED jne msvcrt.75A97B1F main msvcrt.75A993F3 xor esi, esi main msvcrt.75A993F5 test esi, esi main msvcrt.75A993F7 jne msvcrt.75A98AB1 main msvcrt.75A993FD mov esi, [eax+10] main msvcrt.75A99400 cmp esi, [ecx+10] main msvcrt.75A99403 jne msvcrt.75A97BA4 main msvcrt.75A99409 xor esi, esi main msvcrt.75A9940B test esi, esi main msvcrt.75A9940D jne msvcrt.75A98AB1 main msvcrt.75A99413 mov esi, [eax+14] main msvcrt.75A99416 cmp esi, [ecx+14] main msvcrt.75A99419 jne msvcrt.75A97C29 main msvcrt.75A9941F xor esi, esi main msvcrt.75A99421 test esi, esi main msvcrt.75A99423 jne msvcrt.75A98AB1 main msvcrt.75A99429 mov esi, [eax+18] main msvcrt.75A9942C cmp esi, [ecx+18] main msvcrt.75A9942F jne msvcrt.75AA1172 main msvcrt.75A99435 xor esi, esi main msvcrt.75A99437 test esi, esi main msvcrt.75A99439 jne msvcrt.75A98AB1 main msvcrt.75A9943F mov esi, [eax+1C] main msvcrt.75A99442 cmp esi, [ecx+1C] main msvcrt.75A99445 jne msvcrt.75A97CFC main msvcrt.75A9944B xor esi, esi main msvcrt.75A9944D test esi, esi main msvcrt.75A9944F jne msvcrt.75A98AB1 main msvcrt.75A99455 add eax, edx EAX=031353B8 main msvcrt.75A99457 add ecx, edx ECX=031353B8 main msvcrt.75A99459 sub edi, edx EDI=0007FFE0 main msvcrt.75A9945B jmp msvcrt.75A979B0

यह उल्लेखनीय है कि परीक्षण डेटा के बड़े संस्करणों पर, इस कोड ने परिणाम का उपयोग किया ~ असुरक्षित का उपयोग करते हुए कोड की तुलना में 10% बदतर। यह स्पष्ट है कि डेटा सरणियों की तुलना करते समय अधिकांश समय मेमोरी से रीड ऑपरेशंस लेता है, जो प्रोसेसर कैश की तुलना में बहुत धीमा है और, विशेष रूप से, रजिस्टर। लेकिन ऐसा गंभीर अंतर, जो केवल प्रोसेसर रजिस्टरों के साथ संचालन द्वारा दिया गया था, यह बताता है कि संकलक अनुकूलन अत्यंत महत्वपूर्ण हैं। मैं यह सुझाव देने के लिए उद्यम करूंगा कि कमजोर प्रोसेसर पर परीक्षण, उदाहरण के लिए, कम घड़ी की गति वाले प्रोसेसर पर, बहुत अधिक महत्वपूर्ण अंतर देगा।

निष्कर्ष

यदि आपको जल्दी से छोटे (7 बाइट्स और कम) सरणियों की तुलना करने की आवश्यकता है, तो हम सबसे स्पष्ट तरीका लेते हैं (बाइट की तुलना लूप में), बड़े वाले असुरक्षित हैं, और बाकी सब चालाक है।
.Net CLR . , JIT- , , CLR «» . . JIT- , . — C++- Intel, , (AMD Intel) .
C-RunTime , , C- – MS VC. « » (http://rsdn.ru/article/optimization/optimization.xml): « , , ».

Intel® 64 and IA-32 Architectures Software Developer Manuals .CHAPTER 2. Intel ® 64 Architecture
AMD64 Architecture Programmer's Manual Volume 1 : Application Programming CHAPTER 1 Long Mode
Intel® 64 and IA-32 Architectures Optimization Reference Manual . CHAPTER 3. Alignment
Windows Internals, Sixth Edition, Part 1, CHAPTER 5 Processes, Threads, and Jobs
Windows Internals, Sixth Edition, Part 2, CHAPTER 10. Memory Management
Intel® 64 and IA-32 Architectures Software Developer Manuals. CHAPTER 17. TIME-STAMP COUNTER
MSDN Magazine 2005, May: Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects
Joe Duffy, Professional .NET Framework 2.0 (Programmer to Programmer). Chapter 3: Inside the CLR, Just-In-Time (JIT) Compilation

21.03.2014 4:37

, «CRL».
( ), MSDN.
.

पिछली बार मैंने टिप्पणियों में गलत स्रोत पोस्ट किए थे। तथ्य यह है कि प्रयोगों की प्रक्रिया में, जिनके बारे में मुझे पता नहीं था, या भाग में लिखा गया था, स्रोत कोड लेख से परिणाम प्राप्त करने के लिए उपयुक्त नहीं थे। उदाहरण के लिए:

विधि के लिए कुछ कॉल पर टिप्पणी की गई थी DoMeasurements()। result.SequenceEqualTime = result.IStructuralEquatableTime = result.PInvokeTime;
विधि PrepareTestData(int p_ArraySize)उत्पन्न सरणियाँ जो पहले बाइट से भिन्न होती हैं।
स्थिरांक इसलिए सेट किए गए थे कि सरणी का प्रारंभिक आकार 512 * 1024 था, और सरणी केवल 64 थी।
विधि को CompareArraysWithPInvokeMethod()भी संशोधित किया गया है ताकि विभिन्न सरणियों की तुलना पहले की जाए। हालांकि, यह, सैद्धांतिक रूप से, अंतिम डेटा पर अधिक प्रभाव नहीं होना चाहिए।

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

25 मार्च 2014 को सुबह 6:37 बजे तक अपडेट करें।

लोकप्रिय मांग से, मैंने शोध किया RtlCompareMemory()।

फ़ंक्शन कोड का अध्ययन करने से पहले, मैंने पहले फ़ंक्शन के लिए SuppressUnmanagedCodeSecurity विशेषता सेट करके इसका परीक्षण किया memcmp()और यह RtlCompareMemory()
उत्सुक है कि सिस्टम फ़ंक्शन, जिसे उपयोगकर्ता-मोड और कर्नेल-मोड दोनों से कॉल किया जा सकता है, सीआरटी सेट से फ़ंक्शन की तुलना में धीमा हो गया।

यदि स्मृति के दोनों ब्लॉक निवासी हैं, तो RtlCompareMemory के कॉलर किसी भी IRQL पर चल सकते हैं।

बिल्ली के तहत परिणाम

     Unsafe MemCMP RtlCompareMemory   1 279 1 : 001,7 1 : 003,2 1 : 008,8 1 : 001,0 1 278 1 : 001,8 1 : 003,2 1 : 008,9 1 : 001,0 2 325 1 : 001,3 1 : 002,9 1 : 006,1 1 : 001,0 4 374 1 : 001,1 1 : 002,6 1 : 009,0 1 : 001,0 7 422 1 : 001,0 1 : 002,5 1 : 007,0 1 : 001,1 12 426 1 : 001,0 1 : 002,5 1 : 006,9 1 : 001,7 19 490 1 : 001,0 1 : 002,2 1 : 006,0 1 : 001,9 32 560 1 : 001,0 1 : 002,0 1 : 005,3 1 : 002,7 54 622 1 : 001,0 1 : 002,0 1 : 005,4 1 : 003,8 89 802 1 : 001,0 1 : 001,7 1 : 004,3 1 : 004,7 147 1092 1 : 001,0 1 : 001,5 1 : 003,7 1 : 004,0 242 1571 1 : 001,0 1 : 001,4 1 : 003,0 1 : 004,2 398 2328 1 : 001,0 1 : 001,4 1 : 002,7 1 : 004,5 657 3664 1 : 001,0 1 : 001,2 1 : 002,2 1 : 004,6 1082 5519 1 : 001,0 1 : 001,2 1 : 002,1 1 : 005,0 1782 8554 1 : 001,0 1 : 001,2 1 : 002,1 1 : 005,3 2936 13520 1 : 001,0 1 : 001,2 1 : 002,0 1 : 005,5 4837 21771 1 : 001,0 1 : 001,2 1 : 002,0 1 : 005,6 7967 35464 1 : 001,0 1 : 001,2 1 : 001,9 1 : 005,7 13124 58073 1 : 001,0 1 : 001,2 1 : 001,9 1 : 005,7 21618 96457 1 : 001,0 1 : 001,2 1 : 001,9 1 : 005,7 35610 167952 1 : 001,0 1 : 001,1 1 : 001,8 1 : 005,4 58656 285282 1 : 001,0 1 : 001,1 1 : 001,8 1 : 005,3 96617 534712 1 : 001,0 1 : 001,1 1 : 001,6 1 : 004,7 159146 924569 1 : 001,0 1 : 001,1 1 : 001,6 1 : 004,5 262143 1520968 1 : 001,0 1 : 001,1 1 : 001,6 1 : 004,5

डीबगर विंडो के साथ स्क्रीनशॉट में, लाइब्रेरी संस्करण

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

 repe cmpsd ;    ecx  DWORD';

जावा में निम्नानुसार प्रतिनिधित्व किया जा सकता है:

  while ( ( 0 != ecx ) & ( 0 == Compare( (DWORD) RAM[esi], (DWORD) RAM[edi] ) ) ) { --ecx; edi += 4; esi += 4; }

लगभग उसी तरह जब आप शब्दों और बाइट्स के संरेखण की कल्पना कर सकते हैं।

कट के तहत टिप्पणियों के साथ प्लाज्मा

  push esi ;      push edi cld ; DF <-- 0 mov esi, [esp+0C] ; esi <-- Source1 mov edi, [esp+10] ; edi <-- Source2 mov ecx, [esp+14] ; ecx <-- SIZE_T shr ecx, 2 ; ecx <-- (ecx >> 2) (    4) jz short smaller_4 ; repe cmpsd ;    ecx  DWORD'; jne short not_zero ; if ( !ZF ) goto not_zero; smaller_4: mov ecx, [esp+14] ; ecx <-- SIZE_T and ecx, 00000003 ; ecx &= 3 jz short return_SIZE_T ; if ( ZF ) goto return_SIZE_T; repe cmpsb ;     jne short found_difference return_SIZE_T: mov eax, [esp+14] ; eax <-- SIZE_T pop edi ;    pop esi ret 0C ; return eax not_zero: sub esi, 4 ; esi -= 4 sub edi, 4 ; edi -= 4 mov ecx, 4 ; ecx -= 4 repe cmpsb ;     found_difference: dec esi ; --esi sub esi, [esp+0C] ; esi <-- (esi - Source1) mov eax, esi ; eax <-- esi pop edi ;    pop esi ret 0C ; return eax

दो बाइट सरणियों की तुलना करने के 5 तरीके। तुलनात्मक परीक्षण