रिलीज मूल्यों में अलग-अलग व्यवहार करने वाले फ्लोट मान

Question

मेरा एप्लिकेशन रिलीज मोड और डीबग मोड में संकलित करते समय विभिन्न फ़्लोटिंग पॉइंट मान उत्पन्न कर रहा है। मुझे पता चला कि एकमात्र कारण यह है कि मैं एक बाइनरी ट्रेस लॉग सहेजता हूं और रिलीज बिल्ड से एक डीबग बिल्ड से बहुत दूर है, ऐसा लगता है कि 32 बिट फ्लोट वैल्यू के नीचे दो बिट्स 1/2 के बारे में अलग हैं मामलों में से।

क्या आप इस "अंतर" को बग होने पर विचार करेंगे या इस प्रकार के अंतर की अपेक्षा की जाएगी। क्या यह एक कंपाइलर बग या एक आंतरिक पुस्तकालय बग होगा।

उदाहरण के लिए:

LEFTPOS and SPACING are defined floating point values. 
float def_x; 
int xpos; 

def_x = LEFTPOS + (xpos * (SPACING/2)); 

मुद्दा X360 संकलक के संबंध में है।

Answer 1

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

Answer 2

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

Answer 3

मैंने सह-कार्यकर्ता को एक कंपाइलर स्विच खोजने में मदद की जो रिलीज बनाम डीबग बिल्ड में अलग था जो उसके मतभेद पैदा कर रहा था।

/fp (Specify Floating-Point Behavior) पर एक नज़र डालें।

Answer 4

कोई बग नहीं। इस प्रकार का अंतर होने की उम्मीद है।

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

Answer 5

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

तो, मैं कहूंगा कि अधिकतर यह एक बग नहीं है। यदि आप इसके बारे में वास्तव में चिंतित हैं, तो डीबग मोड में अनुकूलन चालू करने का प्रयास करें।

Answer 6

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

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

मुझे नहीं पता कि यह X360 पर भी होता है या नहीं।

Answer 7

अन्य लोगों की तरह, फ़्लोटिंग पॉइंट रजिस्टरों के पास फ्लोट की तुलना में अधिक सटीकता है, इसलिए अंतिम परिणाम की सटीकता रजिस्टर आवंटन पर निर्भर करती है।

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

Answer 8

विभिन्न फ़्लोटिंग-पॉइंट मोड के अलावा अन्य ने इंगित किया है, एसएसई या समान वेक्टर ऑप्टिमाइज़ेशन रिलीज के लिए चालू हो सकते हैं। मानक रजिस्टरों से वेक्टर रजिस्टरों तक फ़्लोटिंग-पॉइंट अंकगणित को परिवर्तित करने से आपके परिणामों की निचली बिट्स पर असर पड़ सकता है, क्योंकि वेक्टर रजिस्ट्रार मानक फ़्लोटिंग-पॉइंट रजिस्टरों की तुलना में आमतौर पर अधिक संकीर्ण (कम बिट्स) होंगे।

Answer 9

यदि आप एक कंपाइलर स्विच सेट करते हैं जो कंपाइलर को फ़्लोटिंग-पॉइंट ऑपरेशंस को पुन: व्यवस्थित करने की अनुमति देता है, - उदा।/fp: तेज़ - तो जाहिर है कि यह एक बग नहीं है।

यदि आपने ऐसा कोई स्विच सेट नहीं किया है, तो यह एक बग है - सी और सी ++ मानक कंपेलरों को आपकी अनुमति के बिना संचालन को पुन: व्यवस्थित करने की अनुमति नहीं देते हैं।