मुझे बताया गया कि नए कंप्यूटरों पर, कुछ प्रतिगमन परीक्षण धीमे हो गए। एक सामान्य बात, ऐसा होता है। विंडोज में कहीं गलत कॉन्फ़िगरेशन या BIOS में सबसे इष्टतम मान नहीं। लेकिन इस बार हम उसी "नॉक डाउन" सेटिंग को खोजने का प्रबंधन नहीं कर सके। चूंकि परिवर्तन महत्वपूर्ण है: 9 बनाम 19 सेकंड (चार्ट पर, नीला पुराना लोहा है और नारंगी नया है), मुझे गहरा खोदना पड़ा।

एक ही ओएस, एक ही हार्डवेयर, अलग प्रोसेसर: 2 गुना धीमा

9.1 से 19.6 सेकंड के प्रदर्शन में गिरावट को निश्चित रूप से महत्वपूर्ण कहा जा सकता है। हमने परीक्षण किए गए कार्यक्रमों, विंडोज और BIOS सेटिंग्स के संस्करणों में बदलाव के साथ अतिरिक्त जांच की। लेकिन नहीं, परिणाम नहीं बदला है। एकमात्र अंतर केवल विभिन्न प्रोसेसर पर दिखाई दिया। नीचे नवीनतम CPU पर परिणाम है।



और यहाँ एक है जो तुलना के लिए उपयोग किया जाता है।



Xeon Gold, स्काईलेक नामक एक अलग वास्तुकला पर चलता है, जो 2017 के मध्य से नए इंटेल प्रोसेसर के लिए सामान्य है। यदि आप नवीनतम हार्डवेयर खरीदते हैं, तो आपको Skylake आर्किटेक्चर के साथ एक प्रोसेसर मिलेगा। ये अच्छी कार हैं, लेकिन, जैसा कि परीक्षणों से पता चला है, नवीनता और गति एक ही बात नहीं है।

यदि और कुछ नहीं मदद करता है, तो आपको इन-डीप रिसर्च के लिए प्रोफाइलर का उपयोग करने की आवश्यकता है। आइए पुराने और नए उपकरणों का परीक्षण करें और कुछ ऐसा प्राप्त करें:



विंडोज परफॉरमेंस एनालाइज़र (WPA) का टैब तालिका में ट्रेस 2 (11 s) और ट्रेस 1 (19%) के बीच के अंतर को दर्शाता है। तालिका में एक नकारात्मक अंतर एक धीमी परीक्षण में सीपीयू की खपत में वृद्धि से मेल खाती है। यदि आप CPU खपत में सबसे महत्वपूर्ण अंतर देखते हैं, तो हम AwareLock :: Contention , JIT_MonEnterWorker_InlineGetThread_GetThread_PatchLabel और ThreadN.S.SWWit देखेंगे । सब कुछ सीपीयू में "कताई" इंगित करता है [कताई - एक ताला, लगभग प्राप्त करने के लिए एक चक्रीय प्रयास। प्रति।], जब थ्रेड्स ब्लॉकिंग के लिए लड़ते हैं। लेकिन यह एक गलत निशान है, क्योंकि उत्पादकता में गिरावट का मुख्य कारण कताई नहीं है। तालों के लिए बढ़ी हुई प्रतिस्पर्धा का मतलब है कि हमारे सॉफ़्टवेयर में कुछ धीमा हो गया है और उसने ताला लगा रखा है, जिसके परिणामस्वरूप सीपीयू में वृद्धि हुई है। मैंने लॉक समय और अन्य प्रमुख संकेतक, जैसे डिस्क प्रदर्शन की जांच की, लेकिन मुझे ऐसा कुछ भी सार्थक नहीं मिला जो प्रदर्शन में गिरावट को समझा सके। हालांकि यह तर्कसंगत नहीं है, लेकिन मैं विभिन्न तरीकों से सीपीयू पर लोड बढ़ाने के लिए लौट आया।

यह जानना दिलचस्प होगा कि प्रोसेसर कहाँ अटक जाता है। WPA में फ़ाइल # और पंक्ति # कॉलम है, लेकिन वे केवल निजी वर्णों के साथ काम करते हैं, जो हमारे पास नहीं है, क्योंकि यह .NET फ्रेमवर्क कोड है। अगली सबसे अच्छी चीज जो हम कर सकते हैं वह dll पता प्राप्त कर सकता है जहां Image RVA नामक निर्देश स्थित है। यदि आप इस dll को डिबगर में लोड करते हैं और करते हैं

u xxx.dll+ImageRVA

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



हम विभिन्न विंडबग विधियों का उपयोग करके इस पते की जांच करेंगे:

0:000> u clr.dll+0x19566B-10
clr!AwareLock::Contention+0x135:
00007ff8`0535565b f00f4cc6 lock cmovl eax,esi
00007ff8`0535565f 2bf0 sub esi,eax
00007ff8`05355661 eb01 jmp clr!AwareLock::Contention+0x13f (00007ff8`05355664)
00007ff8`05355663 cc int 3
00007ff8`05355664 83e801 sub eax,1
00007ff8`05355667 7405 je clr!AwareLock::Contention+0x144 (00007ff8`0535566e)
00007ff8`05355669 f390 pause
00007ff8`0535566b ebf7 jmp clr!AwareLock::Contention+0x13f (00007ff8`05355664)

और विभिन्न JIT विधियों के साथ:

0:000> u clr.dll+0x2801-10
clr!JIT_MonEnterWorker_InlineGetThread_GetThread_PatchLabel+0x124:
00007ff8`051c27f1 5e pop rsi
00007ff8`051c27f2 c3 ret
00007ff8`051c27f3 833d0679930001 cmp dword ptr [clr!g_SystemInfo+0x20 (00007ff8`05afa100)],1
00007ff8`051c27fa 7e1b jle clr!JIT_MonEnterWorker_InlineGetThread_GetThread_PatchLabel+0x14a (00007ff8`051c2817)
00007ff8`051c27fc 418bc2 mov eax,r10d
00007ff8`051c27ff f390 pause
00007ff8`051c2801 83e801 sub eax,1
00007ff8`051c2804 75f9 jne clr!JIT_MonEnterWorker_InlineGetThread_GetThread_PatchLabel+0x132 (00007ff8`051c27ff)

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

यदि समस्या का दस्तावेजीकरण किया जाता है, तो यह एक विशेषता बन जाती है।

सीपीयू	नैनोसेकंड में रोकें
Xeon E5 1620v3 3.5 GHz	4
Xeon® गोल्ड 6126 @ 2.60 गीगाहर्ट्ज़	43

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



नहीं, यह कोई गलती नहीं है, यह एक प्रलेखित कार्य है। यहां तक ​​कि एक पेज भी है जो लगभग सभी प्रोसेसर निर्देशों के निष्पादन समय का संकेत देता है।

• सैंडी पुल 11
• आइवी ब्राइडेज 10
• हसवेल ९
• ब्रॉडवेल 9
• स्काईलेक 141

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

इसका मतलब है कि यदि आप अंतिम हार्डवेयर पर .NET पर अत्यधिक बहु-थ्रेडेड एप्लिकेशन चलाते हैं, तो वे बहुत धीमी गति से काम कर सकते हैं। किसी ने पहले ही इस पर ध्यान दिया और अगस्त 2017 में एक बग दर्ज किया । समस्या .NET कोर 2.1 और .NET फ्रेमवर्क 4.8 पूर्वावलोकन में तय की गई थी।

इंटेल स्काईलेक और बाद में माइक्रोआर्किटेक्चर पर बेहतर प्रदर्शन के लिए कई सिंक्रोनाइज़ेशन प्राइमेटिव्स में सुधारित स्पिन-प्रतीक्षा। [495945, mscorlib.dll, बग]

लेकिन जब से .NET 4.8 की रिलीज़ से एक साल पहले से ही है, मैंने फ़िक्सेस को वापस करने के लिए कहा ताकि .NET 4.7.2 नए प्रोसेसर के साथ सामान्य गति पर लौटे। चूंकि .NET के कई हिस्सों में पारस्परिक रूप से अनन्य ताले (स्पिनलॉक) हैं, इसलिए आपको थ्रेड.स्पिनवेट और अन्य कताई विधियों को काम करते समय बढ़े हुए सीपीयू लोड को ट्रैक करना चाहिए।



उदाहरण के लिए, Task.Result आंतरिक रूप से कताई का उपयोग करता है, इसलिए मैं सीपीयू लोड में उल्लेखनीय वृद्धि और अन्य परीक्षणों में कम प्रदर्शन की आशा करता हूं।

कितना बुरा है?

मैंने .NET कोर कोड को देखा कि कब तक प्रोसेसर घूमता रहेगा अगर "महंगे" संदर्भ स्विच के भुगतान के लिए WaitForSingleObject को कॉल करने से पहले लॉक जारी नहीं किया जाता है। यदि कोई थ्रेड एक ही कर्नेल ऑब्जेक्ट की अपेक्षा करता है तो एक संदर्भ स्विच कहीं एक माइक्रोसेकंड या बहुत अधिक लेता है।

.NET लॉक, कोर की संख्या से अधिकतम कताई अवधि को गुणा करता है, अगर हम निरपेक्ष मामले को लेते हैं जहां प्रत्येक कोर पर धागा एक ही लॉक की अपेक्षा करता है और कर्नेल कॉल के लिए भुगतान करने से पहले सभी के लिए कताई लंबे समय तक जारी रहती है। .NET में कताई 50-पॉज़ कॉल के चक्र के साथ शुरू होने पर एक घातीय उम्र बढ़ने के एल्गोरिथ्म का उपयोग करता है, जहां प्रत्येक पुनरावृत्ति के लिए स्पिन की संख्या तिगुनी हो जाती है जब तक कि अगले स्पिन काउंटर उनकी अधिकतम अवधि से अधिक न हो जाए। मैंने विभिन्न प्रोसेसर और कोर की एक अलग संख्या के लिए प्रति प्रोसेसर कताई की कुल अवधि की गणना की:



नीचे .NET लॉकिंग में सरलीकृत कताई कोड है:

 /// <summary> /// This is how .NET is spinning during lock contention minus the Lock taking/SwitchToThread/Sleep calls /// </summary> /// <param name="nCores"></param> void Spin(int nCores) { const int dwRepetitions = 10; const int dwInitialDuration = 0x32; const int dwBackOffFactor = 3; int dwMaximumDuration = 20 * 1000 * nCores; for (int i = 0; i < dwRepetitions; i++) { int duration = dwInitialDuration; do { for (int k = 0; k < duration; k++) { Call_PAUSE(); } duration *= dwBackOffFactor; } while (duration < dwMaximumDuration); } } 

पहले, कताई का समय मिलीसेकंड अंतराल (24 कोर के लिए 19 एमएस) में था, जो कि पहले से ही उपरोक्त संदर्भ स्विचिंग समय की तुलना में बहुत अधिक है, जो कि तीव्रता का एक क्रम है। लेकिन स्काईलेक प्रोसेसर में, प्रोसेसर के लिए कुल कताई समय 246 एमएस तक 24-बिट या 48-कोर मशीन पर फट जाता है, बस इसलिए कि ठहराव निर्देश 14 बार धीमा हो गया। क्या वास्तव में ऐसा है? मैंने सीपीयू पर समग्र कताई की जांच करने के लिए एक छोटा परीक्षक लिखा था - और गणना की गई संख्या उम्मीदों के अनुरूप है। यहां 24-कोर सीपीयू पर 48 धागे हैं जो एक लॉक की प्रतीक्षा कर रहे हैं, जिसे मैंने मॉनीटर कहा है।



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

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



उदाहरण के लिए, अगर पांचवें स्पिन की शुरुआत में लॉक सिग्नल की उपलब्धता होती है, तो आप इसे केवल राउंड के अंत में ले सकते हैं। अंतिम दौर की स्पिन अवधि की गणना करके, हम अपने प्रवाह के लिए सबसे खराब स्थिति का अनुमान लगा सकते हैं:



कताई समाप्त होने तक प्रतीक्षा के कई मिलीसेकंड। क्या यह वास्तविक समस्या है?

मैंने एक साधारण परीक्षण एप्लिकेशन बनाया जो उपभोक्ता निर्माताओं की एक कतार को लागू करता है, जहां वर्कफ़्लो प्रत्येक कार्य आइटम को 10 एमएस के लिए निष्पादित करता है, और उपभोक्ता को अगले कार्य आइटम से पहले 1-9 एमएस की देरी होती है। यह प्रभाव देखने के लिए पर्याप्त है:



हम 1-2 ms की देरी के लिए देखते हैं कुल अवधि 2.2-2.3 s है, जबकि अन्य मामलों में काम तेजी से 1.2 s तक है। यह दर्शाता है कि सीपीयू पर अत्यधिक कताई केवल थ्रेडेड अनुप्रयोगों में एक कॉस्मेटिक समस्या नहीं है। यह वास्तव में निर्माता-उपभोक्ता के सरल सूत्रण को परेशान करता है, जिसमें केवल दो धागे शामिल हैं। ऊपर दिए गए रन के लिए, ETW डेटा खुद के लिए बोलता है: यह कताई में वृद्धि है जो मनाया देरी का कारण बनता है:



यदि आप ध्यान से "ब्रेक" वाले अनुभाग को देखते हैं, तो हम 11 एमएस को लाल क्षेत्र में कताई करते देखेंगे, हालांकि कार्यकर्ता (हल्का नीला) ने अपना काम पूरा कर लिया है और बहुत समय पहले ताला दिया है।



एक त्वरित गैर-अपक्षयी मामला बहुत बेहतर दिखता है, यहां केवल 1 एमएस को ब्लॉक करने के लिए कताई पर खर्च किया जाता है।



मैं परीक्षण आवेदन SkylakeXPause का इस्तेमाल किया। ज़िप संग्रह में .NET कोर और .NET 4.5 के लिए स्रोत कोड और बायनेरीज़ हैं। तुलना के लिए, मैंने .NET 4.8 पूर्वावलोकन फिक्स और .NET कोर 2.0 के साथ स्थापित किया, जो अभी भी पुराने व्यवहार को लागू करता है। आवेदन .NET मानक 2.0 और .NET 4.5 के लिए डिज़ाइन किया गया है, जो exe और dll दोनों का निर्माण करता है। अब आप कुछ भी ठीक करने की आवश्यकता के बिना पुराने और नए कताई व्यवहार की जांच कर सकते हैं, यह बहुत सुविधाजनक है।

 readonly object _LockObject = new object(); int WorkItems; int CompletedWorkItems; Barrier SyncPoint; void RunSlowTest() { const int processingTimeinMs = 10; const int WorkItemsToSend = 100; Console.WriteLine($"Worker thread works {processingTimeinMs} ms for {WorkItemsToSend} times"); // Test one sender one receiver thread with different timings when the sender wakes up again // to send the next work item // synchronize worker and sender. Ensure that worker starts first double[] sendDelayTimes = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; foreach (var sendDelay in sendDelayTimes) { SyncPoint = new Barrier(2); // one sender one receiver var sw = Stopwatch.StartNew(); Parallel.Invoke(() => Sender(workItems: WorkItemsToSend, delayInMs: sendDelay), () => Worker(maxWorkItemsToWork: WorkItemsToSend, workItemProcessTimeInMs: processingTimeinMs)); sw.Stop(); Console.WriteLine($"Send Delay: {sendDelay:F1} ms Work completed in {sw.Elapsed.TotalSeconds:F3} s"); Thread.Sleep(100); // show some gap in ETW data so we can differentiate the test runs } } /// <summary> /// Simulate a worker thread which consumes CPU which is triggered by the Sender thread /// </summary> void Worker(int maxWorkItemsToWork, double workItemProcessTimeInMs) { SyncPoint.SignalAndWait(); while (CompletedWorkItems != maxWorkItemsToWork) { lock (_LockObject) { if (WorkItems == 0) { Monitor.Wait(_LockObject); // wait for work } for (int i = 0; i < WorkItems; i++) { CompletedWorkItems++; SimulateWork(workItemProcessTimeInMs); // consume CPU under this lock } WorkItems = 0; } } } /// <summary> /// Insert work for the Worker thread under a lock and wake up the worker thread n times /// </summary> void Sender(int workItems, double delayInMs) { CompletedWorkItems = 0; // delete previous work SyncPoint.SignalAndWait(); for (int i = 0; i < workItems; i++) { lock (_LockObject) { WorkItems++; Monitor.PulseAll(_LockObject); } SimulateWork(delayInMs); } } 

निष्कर्ष

यह एक .NET समस्या नहीं है। ठहराव कथन का उपयोग करने वाले सभी स्पिनलॉक कार्यान्वयन प्रभावित होते हैं। मैंने जल्दी से विंडोज सर्वर 2016 के कोर की जांच की, लेकिन सतह पर ऐसी कोई समस्या नहीं है। ऐसा लगता है कि इंटेल काफी दयालु था - और संकेत दिया कि कताई के दृष्टिकोण में कुछ बदलाव की आवश्यकता है।

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

यदि आप .NET कोर 2.0 या डेस्कटॉप .NET फ्रेमवर्क के साथ काम कर रहे हैं, जो 2017 के मध्य से जारी किए गए नवीनतम प्रोसेसर पर है, तो प्रदर्शन में गिरावट के साथ समस्याओं के मामले में, आपको निश्चित रूप से अपने अनुप्रयोगों की जांच एक प्रोफाइलर से करनी चाहिए - और .NET कोर में अपग्रेड करें और, उम्मीद है, जल्द ही .NET डेस्कटॉप मेरा परीक्षण आवेदन आपको किसी समस्या की उपस्थिति या अनुपस्थिति के बारे में बताएगा।

D:\SkylakeXPause\bin\Release\netcoreapp2.0>dotnet SkylakeXPause.dll -check
Did call pause 1,000,000 in 3.5990 ms, Processors: 8
No SkylakeX problem detected

या

D:\SkylakeXPause\SkylakeXPause\bin\Release\net45>SkylakeXPause.exe -check
Did call pause 1,000,000 in 3.6195 ms, Processors: 8
No SkylakeX problem detected

यदि आप .NET फ्रेमवर्क पर उचित अपडेट के बिना और स्काईलेक प्रोसेसर पर काम कर रहे हैं, तो उपकरण एक समस्या की रिपोर्ट करेगा।

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