इस एसओआर सॉल्वर की गति इनपुट पर निर्भर क्यों करती है?

Question

मेरे other question से संबंधित, अब मैंने एसओआर (लगातार ओवर-रिलीक्सेशन) विधि का उपयोग करने के लिए स्पैर मैट्रिक्स सॉल्वर को संशोधित किया है। कोड इस प्रकार अब है:

void SORSolver::step() { 
    float const omega = 1.0f; 
    float const 
     *b = &d_b(1, 1), 
     *w = &d_w(1, 1), *e = &d_e(1, 1), *s = &d_s(1, 1), *n = &d_n(1, 1), 
     *xw = &d_x(0, 1), *xe = &d_x(2, 1), *xs = &d_x(1, 0), *xn = &d_x(1, 2); 
    float *xc = &d_x(1, 1); 
    for (size_t y = 1; y < d_ny - 1; ++y) { 
     for (size_t x = 1; x < d_nx - 1; ++x) { 
      float diff = *b 
       - *xc 
       - *e * *xe 
       - *s * *xs - *n * *xn 
       - *w * *xw; 
      *xc += omega * diff; 
      ++b; 
      ++w; ++e; ++s; ++n; 
      ++xw; ++xe; ++xs; ++xn; 
      ++xc; 
     } 
     b += 2; 
     w += 2; e += 2; s += 2; n += 2; 
     xw += 2; xe += 2; xs += 2; xn += 2; 
     xc += 2; 
    } 
} 

अब अजीब बात है: अगर मैं omega (छूट कारक) में वृद्धि, निष्पादन की गति विभिन्न सरणियों के अंदर मूल्यों पर नाटकीय रूप से निर्भर करने के लिए शुरू होता है!

omega = 1.0f के लिए, निष्पादन समय कम या ज्यादा स्थिर है। omega = 1.8 के लिए, पहली बार, यह आमतौर पर step() 10 बार निष्पादित करने के लिए 5 मिलीसेकंड ले जाएगा, लेकिन यह धीरे-धीरे सिमुलेशन के दौरान लगभग 100 एमएस तक बढ़ जाएगा। अगर मैं omega = 1.0001f सेट करता हूं, तो मुझे निष्पादन समय में तदनुसार मामूली वृद्धि दिखाई देती है; उच्च omega चला जाता है, सिमुलेशन के दौरान तेज़ निष्पादन समय बढ़ जाएगा।

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

यह यूएसंटू पर जी ++ के साथ-साथ 64-बिट विंडोज 7 पर पुन: उत्पन्न होता है जब वीएस -2008 के साथ 32-बिट्स के लिए संकलन करते हैं।

मैंने सुना है कि NaN और Inf मूल्य फ़्लोटिंग पॉइंट गणनाओं के लिए धीमे हो सकते हैं, लेकिन कोई NaNs या Infs मौजूद नहीं हैं। क्या यह संभव है कि फ्लोट कंप्यूटेशंस की गति इनपुट नंबरों के मूल्यों पर निर्भर करती है?

Answer 1

आपके अंतिम प्रश्न का संक्षिप्त उत्तर "हां" है - denormalized (शून्य के बहुत करीब) संख्याओं को विशेष हैंडलिंग की आवश्यकता होती है और बहुत धीमी हो सकती है। मेरा अनुमान है कि वे सिमुलेशन में रेंग रहे हैं जैसे समय चल रहा है। इस संबंधित एसओ पोस्ट को देखें: Floating Point Math Execution Time

शून्य पर फ्लश करने के लिए फ्लोटिंग-पॉइंट नियंत्रण सेट करना सिमुलेशन गुणवत्ता पर नगण्य इम्पैक्ट के साथ चीजों का ख्याल रखना चाहिए।

Answer 2

celion's answer सही साबित होता है। पोस्ट वह के लिए लिंक पर फ्लश-टू-जीरो denormalized मूल्यों की बारी करने के कहते हैं:

#include <float.h> 
_controlfp(_MCW_DN, _DN_FLUSH); 

बहरहाल, यह विंडोज ही है। लिनक्स पर जीसीसी का उपयोग करना, मैं इनलाइन विधानसभा का एक एहसास के साथ ऐसा ही किया था:

int mxcsr; 
__asm__("stmxcsr %0" : "=m"(mxcsr) : :); 
mxcsr |= (1 << 15); // set bit 15: flush-to-zero mode 
__asm__("ldmxcsr %0" : : "m"(mxcsr) :); 

यह मेरी पहली 86 विधानसभा कभी तो यह शायद सुधार किया जा सकता। लेकिन यह मेरे लिए चाल है।