2013-03-04 8 views
18

के साथ संकलन समय को गति दें मैं अपनी सी ++ परियोजनाओं के संकलन-समय को तेज़ करने की कोशिश करना चाहता हूं। उनके पास कोड की लगभग 3 एम लाइनें हैं।एसएसडी

बेशक, मुझे हर परियोजना को हमेशा संकलित करने की आवश्यकता नहीं है, लेकिन कभी-कभी अन्य स्रोतों द्वारा संशोधित स्रोत फाइलें होती हैं, और मुझे उन सभी को पुन: संकलित करने की आवश्यकता होती है (उदाहरण के लिए, जब कोई ASN.1 स्रोत फ़ाइल अपडेट करता है) ।

मैंने माप लिया है कि एक मध्य-परियोजना (जिसमें सभी स्रोत फ़ाइलों को शामिल नहीं किया गया है) को संकलित करने में लगभग तीन मिनट लगते हैं। मुझे पता है कि बहुत ज्यादा नहीं है, लेकिन कभी कभी यह एक संकलन के लिए इंतज़ार कर वास्तव में उबाऊ है ..

मैं एक एसएसडी (एक पुराने OCZ उपगम्यता 3 60   जीबी) है कि, बेंचमार्क के लिए स्रोत कोड को स्थानांतरित करने की कोशिश की है, यह से है एचडीडी से 5 से 60 गुना तेज (विशेष रूप से यादृच्छिक पढ़ने/लिखने में)। वैसे भी, संकलन-समय लगभग एक ही है (शायद 2-3 सेकंड तेज, लेकिन यह एक मौका होना चाहिए)।

शायद विजुअल स्टूडियो बिन को एसएसडी में ले जाने से प्रदर्शन में अतिरिक्त वृद्धि होगी?

बस प्रश्न को पूरा करने के लिए: मेरे पास W3520 Xeon @ 2.67 गीगाहर्ट्ज और 12   जीबी डीडीआर 3 ईसीसी है।

+1

आपको [इस] में रुचि हो सकती है (http://www.joelonsoftware.com/items/2009/03/27.html)। जोएल ने निष्कर्ष निकाला कि यह वास्तव में मदद नहीं करता था। – BoBTFish

+2

हेडर फ़ाइलों से कार्यान्वयन फ़ाइलों में शामिल करने वालों के लिए अप्रासंगिक सब कुछ ले जाएं। अपने कोड में # अंतर्निहित निर्देशों को कम करें, खासकर हेडर फ़ाइलों में न्यूनतम आवश्यक के लिए। यह आमतौर पर परिमाण के क्रम से अधिक स्पेगेटी परियोजना निर्माण के समय को गति देता है। –

+2

@BoBTFish: किसी को यह ध्यान रखना चाहिए कि यह लेख कुछ हद तक पुराना है (एसएसडी आजकल 3 पीढ़ियों के इस्तेमाल से परे हैं) और स्पष्ट रूप से, बहुत हास्यास्पद समग्र भी। यह लड़का $$$ खर्च करता है क्योंकि 30 सेकंड पुनर्निर्माण समय "बहुत धीमा" होता है, फिर एक एसएसडी को बुजुर्ग नोटबुक में रखता है ताकि बहुमूल्य देव समय बर्बाद करने से बचें (और इसे दो दिन बर्बाद कर दें) और चमत्कार करें कि पूरी तरह से सीपीयू-बाध्य संकलन क्यों उस बुजुर्ग नोटबुक को कोई तेज़ नहीं मिलता है। इसे गंभीरता से लेने में कुछ मुश्किल है। – Damon

उत्तर

7

सी ++ संकलन/लिंकिंग प्रसंस्करण गति से सीमित है, न कि एचडीडी I/O। यही कारण है कि आप संकलन गति में कोई वृद्धि नहीं देख रहे हैं। (एसएसडी के लिए संकलक/लिंकर बाइनरी चलती कुछ भी नहीं होगा। जब आप एक बड़ा परियोजना, संकलक/संयोजक और आवश्यक पुस्तकालय संकलन स्मृति में एक बार पढ़ सकते हैं और वहाँ रहना कर रहे हैं।)

मैं कुछ मामूली speedups देखा है सी परियोजनाओं को संकलित करते समय कार्यशील निर्देशिका को एसएसडी या रैमडिस्क में ले जाने से (जो सी ++ परियोजनाओं से बहुत कम समय ले रहा है जो टेम्पलेट्स का भारी उपयोग करते हैं), लेकिन इसे इसके लायक बनाने के लिए पर्याप्त नहीं है।

+5

प्रसंस्करण गति अनुकूलन के साथ बहुत कुछ मायने रखती है (सीए 10% अंतर), लेकिन एक गैर-अनुकूलित बिल्ड पर, एसएसडी वास्तव में हार्ड डिस्क की तुलना में मेरे लिए लगभग 3-4 गुना तेज है। बेशक temp फ़ाइल निर्देशिका जहां कंपाइलर इंटरमीडिएट फाइलें रखता है एसएसडी पर भी होना चाहिए। और फिर, डिस्क निश्चित रूप से ट्रिम का समर्थन करनी चाहिए, या यह एक बहुत छोटी यात्रा है। – Damon

+2

यह सब आपके निर्माण पर्यावरण और अन्य सेटअप पर निर्भर करता है। जैसे मेरे मुख्य संकलन सर्वर पर, मेरे पास 96 जीबीबी रैम और 16 कोर हैं। एचडीडी धीमी है, लेकिन यह वास्तव में कोई फर्क नहीं पड़ता कि सबकुछ रैम में कैश किया गया है। मेरे डेस्कटॉप पर (जहां मैं कभी-कभी संकलित करता हूं) मेरे पास केवल 8 गीगा रैम है, और 6 कोर हैं। समान समानांतर निर्माण करने के लिए बहुत तेज हो सकता है, क्योंकि समानांतर में चल रहे 6 कंपाइलर एसएसडी गति अंतर के लिए पर्याप्त स्मृति को बहुत ध्यान में रखते हैं। – PlasmaHH

+0

@PlasmaHH शायद आपको टिप्पणी के बजाए यह एक उत्तर देना चाहिए, इस प्रश्न से एक से अधिक पीओवी होने से लाभ होगा। – us2012

24

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

मेरे डेस्कटॉप पर (जहां मैं कभी-कभी संकलित करता हूं) मेरे पास केवल 8   रैम का गिब और छह कोर हैं। समान समानांतर निर्माण करने के लिए बहुत तेज हो सकता है, क्योंकि समानांतर में चल रहे छह कंपाइलर एसएसडी गति अंतर के लिए पर्याप्त स्मृति को बहुत ध्यान में रखते हैं।

कई चीजें हैं जो निर्माण समय को प्रभावित करती हैं, जिसमें सीपीयू से I/O "बाध्यता" का अनुपात शामिल है। मेरे अनुभव में (GCC लिनक्स पर) इसमें शामिल हैं:

  • कोड की जटिलता। मेटामैटप्लेट्स के बहुत सारे इसे अधिक CPU समय का उपयोग करते हैं, अधिक सी-जैसे कोड उत्पन्न ऑब्जेक्ट्स के I/O (अधिक) प्रभावशाली
  • अस्थायी फ़ाइलों के लिए कंपाइलर सेटिंग्स, जैसे -pipe जीसीसी के लिए बना सकता है।
  • अनुकूलन का उपयोग किया जा रहा है। आमतौर पर, अधिक ऑप्टिमाइज़ेशन, जितना अधिक सीपीयू काम पर हावी होता है।
  • समानांतर बनाता है। एक समय में एक ही फाइल को संकलित करने से शायद किसी भी सीमा तक सबसे धीमी हार्डडिस्क प्राप्त करने के लिए पर्याप्त I/O उत्पन्न नहीं होगा। एक बार में आठ कोर (या अधिक) के साथ संकलन हालांकि हो सकता है।
  • ओएस/फाइल सिस्टम का उपयोग किया जा रहा है। ऐसा लगता है कि अतीत में कुछ फाइल सिस्टम समानांतर में बनाए गए कई फाइलों के लिए एक्सेस पैटर्न पर दबाए गए हैं, अनिवार्य रूप से अंतर्निहित हार्डवेयर की बजाय फाइल सिस्टम कोड में I/O बाधा डालना।
  • बफरिंग के लिए उपलब्ध रैम। अधिक आक्रामक रूप से एक ओएस आपके आई/ओ को बफर कर सकता है, एचडीडी की गति कम महत्वपूर्ण होती है। यही कारण है कि कभी-कभी make -j6 पर्याप्त निष्क्रिय कोर होने के बावजूद make -j4 से धीमा हो सकता है।

यह कम करने के लिए: यह करने के लिए पर्याप्त बातों पर निर्भर करता है किसी भी "हाँ, यह तुम्हारी मदद करेगा" या शुद्ध अटकलें "नहीं, यह आप नहीं में मदद मिलेगी", इसलिए यदि आप संभावना है इसे आज़माने के लिए , कर दो। लेकिन उस पर बहुत अधिक समय नहीं बिताएं, हर घंटे जब आप अपने संकलन के समय को आधे में कटौती करने का प्रयास करते हैं, तो अनुमान लगाने का प्रयास करें कि आप कितनी बार (या आपके सहकर्मियों के पास कोई है) परियोजना का पुनर्निर्माण कर सकता है, और यह कैसे संबंधित है संभव समय बचाया।

+0

+1, महान विवरण! '-pipe' के लिए – us2012

+2

+1: सबसे अच्छा अनुकूलन भी मेरे द्वारा पाइप के लिए –

+0

+1 को काटना है। मैंने पहले उस विकल्प का उपयोग किया था, लेकिन किसी भी तरह से यह अस्तित्व में भूल गया था। –

4

मैंने पाया कि सी ++ की लगभग 1 मिलियन लाइनों की एक परियोजना को संकलित करना जब कोड एसएसडी पर था (आठ-कोर Core i7, 12   जीबी रैम वाला सिस्टम)। असल में, हमारे पास सबसे अच्छा संभव प्रदर्शन सिस्टम के लिए एक एसएसडी और स्रोत के लिए दूसरा था - यह नहीं था कि निर्माण बहुत तेज था, लेकिन ओएस बहुत अधिक प्रतिक्रियाशील था जबकि एक बड़ा निर्माण चल रहा था।

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

  • मेनू उपकरणविकल्पपरियोजनाओं और समाधान → समानांतर परियोजना की अधिकतम संख्या → सी बनाता
  • प्रोजेक्ट के गुण ++/जनरलमल्टी प्रोसेसर संकलन

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

-2

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

हालांकि, प्रारंभिक विफलताओं के बाद, मुझे लगभग छह गुणा संकलन को तेज करने में सफलता मिली।

संकलन गति को बढ़ाने के लिए निम्नलिखित कदम उठाए गए थे।

  1. बंद कर दिया हाइबरनेशन: "powercfg बंद -h" कमांड प्रॉम्प्ट में

  2. बंद 800 मिनट/1024 अधिकतम करने के लिए सी ड्राइव पर ड्राइव अनुक्रमण दिया

  3. सिकुड़ पेज फ़ाइल (इसे शुरू में था 80 9 2 के सिस्टम प्रबंधित आकार पर सेट करें)।

+0

क्या सिस्टम? 32-बिट विंडोज़? विंडोज विस्टा 32-बिट? –

0

एक बात का उल्लेख नहीं किया है कि जब ccache और एक उच्च समानांतर निर्माण का उपयोग कर, आप एक एसएसडी का उपयोग करने के लाभ देखेंगे।

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