2016-03-07 14 views
9

मैंने देखा कि क्यूटी निर्माता रिलीज़ संस्करण के लिए डिफ़ॉल्ट अनुकूलन स्तर -O2 है। मैं सोच रहा था: -O3 क्यों नहीं? मैंने यहां स्टैक ओवरफ़्लो पर पढ़ा है कि यह खतरनाक हो सकता है या "बग एक्सपोज़िंग" हो सकता है, लेकिन उन अनुकूलन ध्वज क्या हैं जिन्हें सहायक से अधिक जोखिम भरा माना जाता है और क्यों?-O3 (अनुकूलन स्तर 3) के साथ क्या गलत है?

अनुकूलन स्तर 3 झंडे (पर जीसीसी):

  • -fgcse-after-reload
  • -finline-functions
  • -fipa-cp-clone
  • -fpredictive-commoning
  • -ftree-vectorize
  • -funswitch-loops
+1

यह ओ 2 का उपयोग करने वाले हर किसी की तरह है, इसलिए यह बेहतर परीक्षण किया जाता है। कोई विशिष्ट चीज नहीं है, जो O3 कोड को बग्गी होने के कारण संकलित करती है। यह चीजों की तरह है कि ज्यादातर चीजें ओ 2 पर टेस्ट होती हैं, इसलिए O2 ऑप्टिमाइज़ेशन का उपयोग करते समय आपको बग मिल जाएगा। ओ 3 को बग उत्पन्न नहीं करना चाहिए (धारणा के साथ, कि कंपाइलर में कोई बग नहीं है) – DawidPi

+2

@DawidPi, अगर ऐसा होता है, तो ओ 3 सामान्य रूप से बेहतर या बराबर प्रदर्शन प्रदान करने वाले स्तर का उपयोग क्यों नहीं करेगा? मुझे लगता है कि हम इस सवाल से कुछ सीखेंगे। अगर कोई और पहले वहां नहीं जाता है, तो मैं इसमें कुछ शोध करूंगा। – merlin2011

+1

http://stackoverflow.com/questions/5637828/why-would-one-ever-want-to-compile-with-o2-instead-of-o3 इसके बारे में कुछ है – DawidPi

उत्तर

4

कंपाइलर कीड़े के अलावा, यह शायद एक मिथक है। यह -Ofast विकल्प जोखिम भरा है, क्योंकि वह यह भी गारंटी नहीं देता है कि मानक-अनुपालन कार्यक्रम तोड़ नहीं जाएंगे।

बस एक व्यावहारिक उदाहरण के रूप में, यहाँ पुस्तकालयों में से एक त्वरित खोज, कोई विशेष क्रम में, एंड्रॉयड ओपन सोर्स प्रोजेक्ट (AOSP) — अंदर जो शायद एक "वास्तविक उत्पादन codebase" — कि -O3 का उपयोग के लिए पर्याप्त है:

cblas, अधिभारित, libmpeg2, libavc, lvvm: MCJIT, jpeg, zlib, lz4, regex-re2, libpng, libutf, (और अधिक)

अन्य कोड AOSP में बस के लिए अनुकूलित करने की कोशिश करता है आकार (अभी भी, एंड्रॉइड), इसलिए यह स्पष्ट रूप सेका उपयोग करता है। लेकिन उस कोड में से अधिकांश अभी भी इन सभी पुस्तकालयों का उपयोग करता है — जिसके लिए प्रदर्शन आकार से बड़ा विचार है। ध्यान दें, कि सहीता शायद openssh की पसंद के लिए एक बड़ी समस्या है, जिसे ऊपर वर्णित किया गया है।

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

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

2

टिप्पणी में उत्कृष्ट लिंक का एक सारांश: स्तरों -O2 अक्सर उच्च अनुकूलन से अधिक पसंद किया जाता है की वजह से:

  • छोटे कोड आकार (अक्सर क्योंकि शाखा भविष्यवाणी के लिए प्रोसेसर कैश के बेहतर प्रदर्शन के बराबर)
  • उत्पन्न
  • कम संकलन समय
  • बग (आपके कोड में) जो उच्च अनुकूलन स्तर में प्रकट होने के लिए अधिक प्रवण हैं।

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

ऑप्टिमाइज़ेशन स्तरों के बीच गति अंतर के बारे में: सनसीसी के लिए प्रलेखन कुछ ऐसा पढ़ता है "-ओ 4 सामान्य रूप से -O3 और -O3 से अधिक तेज़ है -ओ 2 से अधिक तेज़ है। लेकिन कभी-कभी -O2 अन्य सभी को धड़कता है।" मेरे अनुभव से, -O2 अक्सर कभी-कभी तेज़ नहीं होता था।

+0

लेकिन जब आप बग के बारे में बात कर रहे हैं, तो स्तरों के बीच क्या अंतर है? क्या यह कहीं भी जीसीसी डॉक्स कहता है कि "ऑप्टिमाइज़ेशन जो बग्गी होने की अधिक संभावना रखते हैं, वे उच्च संख्यात्मक स्तर पर जाते हैं?" –

+0

@YamMarcovic नहीं, बिल्कुल नहीं। ऑप्टिमाइज़र बग (जो इच्छित व्यवहार के अलावा अन्य कारण हैं) कंपाइलर बग हैं और स्तर के बावजूद तय किए जाने चाहिए। अपरिभाषित व्यवहार या '--ffast-Math' के साथ स्रोत कोड ... ये कोई कंपाइलर बग नहीं हैं। –

संबंधित मुद्दे