C ++ को संकलित करने के लिए मुझे लिनक्स के रूप में तेजी से चलने के लिए विंडोज कैसे मिलेगा?

142

मुझे पता है कि यह इतना प्रोग्रामिंग सवाल नहीं है, लेकिन यह प्रासंगिक है।

मैं काफी बड़े क्रॉस प्लेटफॉर्म प्रोजेक्ट पर काम करता हूं । Windows पर मैं VC ++ 2008 का उपयोग करता हूं। लिनक्स पर मैं gcc का उपयोग करता हूं। परियोजना में लगभग 40k फाइलें हैं। एक ही प्रोजेक्ट को संकलित और लिंक करने में लिनक्स की तुलना में विंडोज 10x से 40x धीमा है। मैं कैसे इसे ठीक कर सकता हूं?

एक एकल परिवर्तन वृद्धिशील लिनक्स पर 20 सेकंड और विंडोज पर 3 मिनट का निर्माण करता है। क्यों? मैं लिनक्स में 'गोल्ड' लिंकर भी स्थापित कर सकता हूं और उस समय को 7 सेकंड तक प्राप्त कर सकता हूं।

इसी तरह git विंडोज की तुलना में लिनक्स पर 10x से 40x तेज है।

Git के मामले में यह संभव है कि git इष्टतम तरीके से Windows का उपयोग नहीं कर रहा है लेकिन VC ++? आपको लगता है कि Microsoft अपने स्वयं के डेवलपर्स को यथासंभव उत्पादक बनाना चाहेगा और तेजी से संकलन उस ओर एक लंबा रास्ता तय करेगा। शायद वे डेवलपर्स को सी # में प्रोत्साहित करने की कोशिश कर रहे हैं?

सरल परीक्षण के रूप में, बहुत सारे सबफ़ोल्डर के साथ एक फ़ोल्डर ढूंढें और एक सरल करें

dir /s > c:\list.txt

विंडोज पर। इसे दो बार करें और दूसरा रन करें इसलिए यह कैश से चलता है। फ़ाइलों को लिनक्स पर कॉपी करें और दूसरे रन के बराबर 2 रन और समय करें।

ls -R > /tmp/list.txt

मेरे पास ठीक उसी स्पेक्स के साथ 2 वर्कस्टेशन हैं। HP Z600s 12gig के साथ RAM, 8 कोर 3.0ghz पर। ~ 400k फ़ाइलों के साथ एक फ़ोल्डर पर विंडोज 40 सेकंड लेता है, लिनक्स <1 सेकंड लेता है।

क्या एक रजिस्ट्री सेटिंग है जो मैं विंडोज को गति देने के लिए सेट कर सकता हूं? क्या देता है?

कुछ छोटे प्रासंगिक लिंक, संकलन समय के लिए प्रासंगिक, जरूरी नहीं कि मैं / ओ।

जाहिरा तौर पर विंडोज 10 (विंडोज 7 में नहीं) में एक समस्या है कि एक प्रक्रिया को बंद करने से एक वैश्विक लॉक होता है । जब कई कोर के साथ संकलित किया जाता है और इसलिए कई प्रक्रियाएं इस मुद्दे को हिट करती हैं।
/analyseविकल्प पर प्रतिकूल पर्फ़ प्रभावित कर सकते हैं, क्योंकि यह एक वेब ब्राउज़र को लोड करता है । (यहां प्रासंगिक नहीं है, लेकिन यह जानना अच्छा है)

— GMAN
स्रोत

5

मुझे पता नहीं क्यों, लेकिन यह विंडोज और लिनक्स के प्रदर्शन विशेषताओं में एक ज्ञात अंतर है, लिनक्स एक निर्देशिका में फ़ाइलों के भार से निपटने में खिड़कियों की तुलना में बेहतर है, संभवतः यह NTFS बनाम ext4 / जो भी हो? यह भी हो सकता है कि लिनक्स के डेंट्री कैश के बराबर विंडोज उतना अच्छा नहीं है।

— स्पडोरी86

73

इसे बंद क्यों किया गया? "रचनात्मक नहीं हो रहा है" ?? मुझे यह डेवलपर्स के लिए काफी प्रासंगिक लगता है।

— Nils

3

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

— हालिल Halzgür

2

@ Halil promptedzgür: ठीक है, आपकी टिप्पणी ने मुझे संशोधन इतिहास को देखने के लिए प्रेरित किया - मूल प्रश्न शीर्षक कुछ ऐसा ही पूछ रहा था । यह बहुत अच्छी तरह से कारण हो सकता है (मैंने वोट करने के लिए बंद नहीं किया था), क्योंकि मूल शीर्षक से किसी ने स्पष्ट रूप से नाराज होकर एक पोस्ट किया था और हंगामा करना शुरू कर दिया था, जो तब हटा दिया गया था, जिससे इस प्रश्न को बंद कर दिया गया। शीर्षक तब से संपादित किया गया है, इसलिए मुझे लगता है कि हम जाने के लिए अच्छे हैं। फिर से खोल दी। ध्यान रखें कि आपको अभी भी प्रश्न पर चर्चा नहीं करने की कोशिश करनी चाहिए ... क्योंकि ओपी उत्तर की तलाश में है, उत्तर प्रदान करें, और कुछ नहीं।

— BoltClock

2

यह किसी के साथ @ रेमंड-चेन झंकार की तरह किसी को देखने के लिए भयानक होगा - अगर प्रश्न तकनीकी रहता है और इस मुद्दे को पुन: पेश करने के लिए पर्याप्त डेटा / तथ्य प्रदान करता है।

— बेंजामिन पॉडज़ुन

32

जब तक एक हार्डकोर विंडोज सिस्टम हैकर साथ नहीं आता, तब तक आपको पार्टिसिपेंट कमेंट्स (जो मैं नहीं करूंगा) और सट्टा (जो मैं कोशिश करने जा रहा हूं) से ज्यादा नहीं होने वाला।

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

— नौफ़ल इब्राहिम
स्रोत

क्या आप # 2 पर थोड़ा विस्तार कर सकते हैं? यह काफी आश्चर्यजनक है - क्या यह इसलिए है क्योंकि कर्नेल रैम डिस्क या कुछ पर डेटा कैश नहीं करता है?

— user541686

2

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

— नौफाल इब्राहिम

1

"जब तक [एक विशिष्ट विषय पर एक विशेषज्ञ] साथ नहीं आता है, तो आप पक्षपातपूर्ण टिप्पणियों से अधिक नहीं लेंगे ... और अटकलें": यह किसी भी अन्य प्रश्न से अलग कैसे है?

— डॉल्फ नोव

1

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

— नौफल इब्राहिम

# 1 में लिंक अब सक्रिय नहीं है।

— अल्कमास

28

कुछ विचार:

8.3 नामों को अक्षम करें। यह बड़ी संख्या में फ़ाइलों और फ़ोल्डरों की अपेक्षाकृत कम संख्या के साथ ड्राइव का एक बड़ा कारक हो सकता है:fsutil behavior set disable8dot3 1
अधिक फ़ोल्डरों का उपयोग करें। मेरे अनुभव में, NTFS प्रति फ़ोल्डर लगभग 1000 से अधिक फ़ाइलों के साथ धीमा करना शुरू कर देता है।
MSBuild के साथ समानांतर बिल्ड सक्षम करें; बस "/ m" स्विच जोड़ें, और यह स्वचालित रूप से CPU कोर प्रति MSBuild की एक प्रति शुरू करेगा।
अपनी फ़ाइलों को SSD पर रखें - यादृच्छिक I / O के लिए बेहद मदद करता है।
यदि आपकी औसत फ़ाइल का आकार 4KB से बहुत अधिक है, तो फ़ाइल सिस्टम को एक बड़े क्लस्टर आकार के साथ पुनर्निर्माण करने पर विचार करें जो आपकी फ़ाइल आकार से लगभग मेल खाता हो।
सुनिश्चित करें कि फ़ाइलों को डीफ़्रैग्मेन्ट किया गया है। खंडित फ़ाइलें बहुत सारे डिस्क खोज का कारण बनती हैं, जिससे आपको थ्रूपुट में 40+ का कारक मिल सकता है। Sysinternals, या अंतर्निहित Windows डीफ़्रेग्मेंटर से "contig" उपयोगिता का उपयोग करें।
यदि आपकी औसत फ़ाइल का आकार छोटा है, और आपके द्वारा किया गया विभाजन अपेक्षाकृत पूर्ण है, तो संभव है कि आप खंडित MFT के साथ चल रहे हों, जो प्रदर्शन के लिए बुरा है। इसके अलावा, 1K से छोटी फाइलें सीधे एमएफटी में संग्रहीत की जाती हैं। ऊपर उल्लिखित "संदर्भ" उपयोगिता मदद कर सकती है, या आपको एमएफटी आकार बढ़ाने की आवश्यकता हो सकती है। निम्न आदेश इसे दोगुना करेगा, वॉल्यूम के 25% तक:fsutil behavior set mftzone 2 संख्या को 12.5% वेतन वृद्धि से आकार बढ़ाने के लिए अंतिम संख्या 3 या 4 में बदलें। कमांड चलाने के बाद, रिबूट करें और फिर फाइल सिस्टम बनाएं।
अंतिम पहुँच समय अक्षम करें: fsutil behavior set disablelastaccess 1
अनुक्रमण सेवा को अक्षम करें
अपने एंटी-वायरस और एंटी-स्पाइवेयर सॉफ़्टवेयर को अक्षम करें, या कम से कम प्रासंगिक फ़ोल्डरों को अनदेखा करने के लिए सेट करें।
अपनी फ़ाइलों को OS और पेजिंग फ़ाइल से अलग भौतिक ड्राइव पर रखें। एक अलग भौतिक ड्राइव का उपयोग करके विंडोज दोनों ड्राइवों के समानांतर I / Os का उपयोग करने की अनुमति देता है।
अपने संकलक झंडे पर एक नज़र है। विंडोज सी ++ संकलक के पास विकल्पों में से एक टन है; सुनिश्चित करें कि आप केवल उन लोगों का उपयोग कर रहे हैं जिनकी आपको वास्तव में आवश्यकता है।
पेड-पूल बफ़र्स के लिए OS का उपयोग करने वाली मेमोरी की मात्रा बढ़ाने की कोशिश करें (सुनिश्चित करें कि आपके पास पहले पर्याप्त रैम है): fsutil behavior set memoryusage 2
यह सुनिश्चित करने के लिए कि आप कभी-कभार डिस्क त्रुटियों का सामना नहीं कर रहे हैं, Windows त्रुटि लॉग की जाँच करें।
भौतिक डिस्क संबंधित प्रदर्शन काउंटर पर एक नज़र डालें कि आपके डिस्क कितने व्यस्त हैं। उच्च कतार की लंबाई या स्थानांतरण के प्रति लंबे समय तक खराब संकेत हैं।
कच्चे हस्तांतरण के समय के संदर्भ में डिस्क विभाजन का पहला 30% शेष डिस्क की तुलना में बहुत तेज है। संकीर्ण विभाजन भी कम से कम समय की तलाश में मदद करते हैं।
क्या आप RAID का उपयोग कर रहे हैं? यदि ऐसा है, तो आपको RAID प्रकार की अपनी पसंद को अनुकूलित करने की आवश्यकता हो सकती है (RAID-5 संकलन के लिए भारी-भरकम संचालन के लिए खराब है)
ऐसी किसी भी सेवा को अक्षम करें जिसकी आपको आवश्यकता नहीं है
डीफ़्रैग्मेंट फ़ोल्डर: सभी फ़ाइलों को किसी अन्य ड्राइव पर कॉपी करें (बस फाइलें), मूल फ़ाइलों को हटाएं, सभी फ़ोल्डरों को किसी अन्य ड्राइव पर कॉपी करें (बस खाली फ़ोल्डर्स), फिर मूल फ़ोल्डरों को हटाएं, मूल ड्राइव को डीफ़्रैग्मेंट करें, फ़ोल्डर संरचना को पहले कॉपी करें , फिर फ़ाइलों की प्रतिलिपि बनाएँ। जब विंडोज़ एक समय में बड़े फ़ोल्डर एक फ़ाइल बनाता है, तो फ़ोल्डर समाप्त हो जाते हैं और धीमा हो जाता है। ("contig" यहाँ भी मदद करनी चाहिए)
यदि आप I / O बाध्य हैं और CPU चक्रों को छोड़ना चाहते हैं, तो डिस्क कंप्रेशन को चालू करें। यह सीपीयू में कुछ लागत के साथ अत्यधिक संकुचित फ़ाइलों (जैसे स्रोत कोड) के लिए कुछ महत्वपूर्ण स्पीडअप प्रदान कर सकता है।

— RickNZ
स्रोत

1

अगर आपने ये सभी काम किए, तो भी आप लिनक्स परफॉमेंस के करीब नहीं आएंगे। एक कोशिश के नीचे परीक्षण दें और यदि आप असहमत हैं तो अपना समय पोस्ट करें।

— b7kich 20

6

हमें एक बेहतर बेंचमार्क चाहिए। किसी फ़ोल्डर को एन्यूमरेट करने में लगने वाले समय को मापना बहुत उपयोगी नहीं है, IMO। NTFS एकल-फ़ाइल लुकअप समय के लिए अनुकूलित है, btree संरचना के साथ। लिनक्स में (पिछली बार मैंने देखा था), एक ऐप एक पूरे फ़ोल्डर को एक सिस्टम कॉल के साथ पढ़ सकता है, और परिणामी संरचना के माध्यम से पूरी तरह से उपयोगकर्ता कोड में पुनरावृति कर सकता है; Windows को प्रत्येक फ़ाइल के लिए एक अलग sys कॉल की आवश्यकता होती है। किसी भी तरह से,

— कंपाइलरों

3

फिर आप जो वर्णन कर रहे हैं वह समस्या ठीक है। एक अलग बेंचमार्क चुनने से समस्या हल नहीं होती - आप बस दूर देख रहे हैं।

— b7kich

2

सवाल संकलन समय के अनुकूलन के बारे में था। फोल्डर एन्यूमरेशन बार विंडोज पर संकलन समय पर हावी नहीं होता है, यहां तक कि एक फ़ोल्डर में हजारों फाइलों के साथ।

— रिकएनजेड

1

ऊपर सुझाए गए कुछ परिवर्तनों को करने के बाद, क्रोमियम के पेड़ के लिए "ls -R" का दूसरा रन मेरे लिए 4.3 सेकंड (बनाम ओपी में 40 सेकंड) लेता है। "dir / s" में लगभग एक सेकंड लगता है। SSD पर स्विच करने से केवल एन्यूमरेशन के लिए मदद नहीं मिली, लेकिन मुझे संदेह है कि यह कंपाइल के लिए मदद करेगा।

— रिकएनजेड

25

NTFS फ़ाइल एक्सेस टाइम को हर बार बचाता है। आप इसे अक्षम करने का प्रयास कर सकते हैं: "fsutil व्यवहार सेट अक्षमता 1" (पुनरारंभ)

— Agent_L
स्रोत

6

परीक्षण है कि पिछले 36 से नीचे 4 सेकंड मुंडा। अभी भी मेरे लिनक्स VM पर .6 सेकंड की तुलना में घृणित

— b7kich

21

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

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

— समुदाय
स्रोत

17

मुझे व्यक्तिगत रूप से लिनक्स पर विंडोज़ वर्चुअल मशीन चलाते हुए पाया गया कि विंडोज़ में आईओ की सुस्ती का एक बड़ा सौदा निकालने में कामयाब रहे, संभावना है क्योंकि लिनक्स vm बहुत सारे कैशिंग कर रहा था कि विंडोज स्वयं नहीं था।

यह करते हुए कि मैं एक बड़े (250Kloc) C ++ प्रोजेक्ट के संकलित समय को तेज करने में सक्षम था, मैं 15 मिनट से लेकर लगभग 6 मिनट तक कुछ काम कर रहा था।

— bfrog
स्रोत

गंभीरता से? आपका मतलब है कि मुझे देव वी के रूप में वीएम का उपयोग करने के लिए एक परीक्षण देना चाहिए? अजीब लगता है ... आप किस वीएम का उपयोग करते हैं?

— मार्टिन बुका वेसर

8

मैंने उबंटू 11.04 वीएम के साथ ऊपर के परिदृश्य का परीक्षण किया जो कि मेरी विंडोज़ 7 वर्कस्टेशन के अंदर चल रहा है। 0.6 सेकंड के लिए लिनक्स वीएम, मेरी खिड़कियों के लिए 36 सेकंड वर्कस्टेशन

— b7kich

2

यदि आप वर्चुअलबॉक्स का उपयोग करते हैं और एक साझा ड्राइव सेट करते हैं तो आप अनिवार्य रूप से मुफ्त में अपने संकलन को गति दे सकते हैं।

— orlp

यहाँ शब्दांकन बहुत ही भ्रमित करने वाला है, लेकिन मुझे लगता है कि इसका मतलब है विंडोज़-होस्टेड वीएम रनिंग लिनक्स, न कि विंडोज़-रनिंग वीएम जो कि लिनक्स पर होस्ट किया गया है ... जो कि दिलचस्प है, लेकिन मेरा पहला - शाब्दिक - इसको पढ़ने से पता चलता है कि विंडोज़ में चलना एक वीएम लिनक्स पर होस्ट विंडोज देशी रूप चलाने की तुलना में तेज गति के लिए नेतृत्व किया संकलित करने के लिए - और कि है होगा वास्तव में कुछ किया गया।

— अंडरस्कोर_ड

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

— प्रो। फाल्कन

17

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

यह भी है कि आप एक तेज लिनक्स C ++ संकलन श्रृंखला कैसे बनाएंगे, लेकिन यह लिनक्स में कम महत्वपूर्ण है क्योंकि फ़ाइल सिस्टम आपके लिए पहले से ही बहुत कुछ कर रहा है।

इसका कारण यूनिक्स संस्कृति के कारण है: ऐतिहासिक रूप से फ़ाइल सिस्टम प्रदर्शन विंडोज की तुलना में यूनिक्स दुनिया में बहुत अधिक प्राथमिकता रहा है। यह कहने के लिए नहीं कि यह विंडोज में प्राथमिकता नहीं है, बस यूनिक्स में यह एक उच्च प्राथमिकता रही है।

स्रोत कोड तक पहुंच।

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

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

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

यूनिक्स एप्लिकेशन कई छोटी फाइलों से निपटने की प्रवृत्ति रखते हैं। एक सॉफ्टवेयर विकास पर्यावरण के बारे में सोचें: कई छोटे स्रोत फाइलें, प्रत्येक का अपना उद्देश्य है। अंतिम चरण (लिंकिंग) एक बड़ी फ़ाइल बनाता है लेकिन यह एक छोटा प्रतिशत है।

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

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

विंडोज बेंचमार्किंग और ऑप्टिमाइज़ेशन का इतिहास इस बात पर रहा है कि कोई कितनी तेजी से लंबी फाइलों को पढ़ या लिख सकता है। वही अनुकूलित हो जाता है।

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

यूनिक्स सर्वर रूम में शुरू हुआ: कोई यूजर इंटरफेस नहीं। उपयोगकर्ताओं को केवल एक चीज दिखाई देती है गति। इसलिए, गति एक प्राथमिकता है।

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

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

इसके अलावा, जैसा कि यूनिक्स खुला स्रोत है (यहां तक कि जब यह नहीं था, सभी के पास स्रोत तक पहुंच थी) कोई भी ऊब पीएचडी छात्र कोड पढ़ सकता है और इसे बेहतर बनाकर प्रसिद्ध हो सकता है। विंडोज में ऐसा नहीं होता है (एमएस के पास एक प्रोग्राम है जो शिक्षाविदों को विंडोज स्रोत कोड तक पहुंच देता है, यह शायद ही कभी इसका फायदा उठाया जाता है)। यूनिक्स-संबंधित प्रदर्शन पत्रों के इस चयन को देखें : http://www.eecs.harvard.edu/margo/papers/ या Osterhaus, हेनरी स्पेंसर, या अन्य द्वारा पत्रों के इतिहास को देखें। यूनिक्स इतिहास में सबसे बड़ी (और देखने में सबसे सुखद) एक बहस, ओस्टरहाउस और सेल्ज़र के बीच आगे और पीछे थी http://www.eecs.harvard.edu/margo/papers/usenix95-lfs-supplement/rebuttal। एचटीएमएल आप विंडोज की दुनिया में उस तरह की चीज नहीं देखते हैं। आप विक्रेताओं को एक-दूसरे को एक-अप करते हुए देख सकते हैं, लेकिन लगता है कि यह बहुत ही हाल ही में हुआ है क्योंकि नवाचार सभी मानकों के स्तर पर लगता है।

मैं इसे कैसे देखता हूं।

अद्यतन: यदि आप नए संकलक श्रृंखलाओं को देखते हैं जो Microsoft से बाहर आ रहे हैं, तो आप बहुत आशावादी होंगे क्योंकि वे जो कुछ भी कर रहे हैं, वह पूरे टूलकिन को रैम में रखना और कम काम को दोहराना आसान बनाता है। बहुत प्रभावशाली सामान।

— TomOnTime
स्रोत

6

यह कहना कि इसका कारण "सांस्कृतिक है, तकनीकी नहीं" वास्तव में इस सवाल का जवाब नहीं है। जाहिर है, एक या एक से अधिक अंतर्निहित तकनीकी कारण हैं कि कुछ ऑपरेशन विंडोज पर लिनक्स की तुलना में धीमा क्यों हैं। अब, सांस्कृतिक मुद्दे बता सकते हैं कि लोगों ने तकनीकी निर्णय क्यों लिए जो उन्होंने किए; लेकिन यह एक तकनीकी प्रश्नोत्तर साइट है। उत्तर में तकनीकी कारणों को शामिल किया जाना चाहिए कि क्यों एक प्रणाली दूसरे की तुलना में धीमी है (और स्थिति को सुधारने के लिए क्या किया जा सकता है), संस्कृति के बारे में अकल्पनीय अनुमान नहीं।

— ब्रायन कैंपबेल

यह बहुत सारी तकनीकी जानकारी नहीं है। ज्यादातर परिस्थितिजन्य। मुझे लगता है कि हम वास्तविक तकनीकी जानकारी प्राप्त करने का एकमात्र तरीका दो संकलक, निर्माण प्रणाली, इत्यादि के बीच के

— अंतरों को देखते हुए हैं

विंडोज एप्लिकेशन एक बड़ी फ़ाइल को खोलने के लिए करते हैं, इसे लंबे समय तक खुला रखते हैं - बहुत सारे यूनिक्स ऐप ऐसा करते हैं। सर्वर, मेरे

— एमाक्स

मुझे नहीं लगता कि Emacs लंबे समय तक फाइलें खोलते हैं चाहे वह बड़ी हो या छोटी। यह निश्चित रूप से फ़ाइल के बीच में नहीं लिखता है, इसे डेटाबेस की तरह अपडेट करना होगा।

— टॉमऑनटाइम

... और सर्वर भी ऐसा नहीं करते हैं। * निक्स सिस्टम पर उनकी विशेषताएं आमतौर पर बहुत सारे छोटे मॉड्यूलों में विभाजित होती हैं, जिसमें सर्वर कोर अनिवार्य रूप से एक खाली शेल होता है।

— स्पेक्ट्रा

7

इंक्रीमेंटल लिंकिंग

यदि VC 2008 समाधान को .lib आउटपुट के साथ कई प्रोजेक्ट्स के रूप में सेट किया गया है, तो आपको "लाइब्रेरी डिपेंडेंसी इनपुट्स का उपयोग करें" सेट करने की आवश्यकता है; यह लिंकर को .lib के बजाय .obj फ़ाइलों के विरुद्ध सीधे लिंक बनाता है। (और वास्तव में यह आकस्मिक रूप से लिंक बनाता है।)

निर्देशिका ट्रैवर्सल प्रदर्शन

मूल मशीन पर रेंगने वाली निर्देशिका की तुलना किसी अन्य मशीन पर उसी फ़ाइलों के साथ नव निर्मित निर्देशिका को क्रॉल करने के साथ करना थोड़ा अनुचित है। यदि आप एक समकक्ष परीक्षण चाहते हैं, तो आपको संभवतः स्रोत मशीन पर निर्देशिका की एक और प्रतिलिपि बनाना चाहिए। (यह अभी भी धीमा हो सकता है, लेकिन यह किसी भी संख्या में चीजों के कारण हो सकता है: डिस्क विखंडन, लघु फ़ाइल नाम, पृष्ठभूमि सेवाएं, आदि) हालांकि मुझे लगता है कि dir /sवास्तविक मुद्दों को मापने की तुलना में आउटपुट लिखने के लिए अधिक करने के लिए पूर्ण मुद्दे हैं ट्रैवर्सल प्रदर्शन। यहां तक कि dir /s /b > nulएक विशाल निर्देशिका के साथ मेरी मशीन पर धीमा है।

— एमएसएन
स्रोत

6

मुझे पूरा यकीन है कि यह फाइल सिस्टम से संबंधित है। मैं लिनक्स और विंडोज के लिए एक क्रॉस-प्लेटफॉर्म प्रोजेक्ट पर काम करता हूं, जहां प्लेटफ़ॉर्म-डिपेंडेंट कोड बिल्कुल जरूरी है, सिवाय इसके सभी कोड कॉमन हैं। हम मर्क्यूरियल का उपयोग करते हैं, git का नहीं, इसलिए git का "Linuxness" लागू नहीं होता है। केंद्रीय रिपॉजिटरी से परिवर्तनों में खींचना लिनक्स की तुलना में विंडोज पर हमेशा के लिए ले जाता है, लेकिन मुझे यह कहना होगा कि हमारी विंडोज 7 मशीनें विंडोज एक्सपी वाले की तुलना में बहुत बेहतर करती हैं। उसके बाद कोड को संकलन करना VS 2008 पर और भी बुरा है। यह सिर्फ hg नहीं है; CMake विंडोज पर भी बहुत धीमी गति से चलता है, और ये दोनों उपकरण फ़ाइल सिस्टम का उपयोग किसी और चीज़ से अधिक करते हैं।

समस्या इतनी बुरी है कि हमारे अधिकांश डेवलपर्स जो कि विंडोज के वातावरण में काम करते हैं, वे अब वृद्धिशील निर्माण करने से भी परेशान नहीं होते हैं - वे पाते हैं कि इसके बजाय एक एकता निर्माण करना तेज है।

संयोग से, यदि आप विंडोज में संकलन गति को नाटकीय रूप से कम करना चाहते हैं, तो मैं उपरोक्त एकता निर्माण का सुझाव दूंगा। यह निर्माण प्रणाली में सही ढंग से लागू करने के लिए एक दर्द है (मैंने इसे सीएमके में हमारी टीम के लिए किया था), लेकिन एक बार हमारे सतत एकीकरण सर्वरों के लिए चीजों को स्वचालित रूप से गति प्रदान करता है। आपकी निर्माण प्रणाली कितनी बायनेरिज़ से बाहर निकल रही है, इसके आधार पर, आप परिमाण सुधार के 1 से 2 ऑर्डर प्राप्त कर सकते हैं। आपकी माइलेज भिन्न हो सकती है। हमारे मामले में मुझे लगता है कि लिनक्स ने तीन गुना और विंडोज एक को 10 के कारक के रूप में बनाया है, लेकिन हमारे पास बहुत सारे साझा पुस्तकालय और निष्पादन योग्य हैं (जो एक एकता के निर्माण के फायदे को कम करता है)।

— Vesटीला नेव्स
स्रोत

5

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

मैंने अभी लिनक्स और विंडोज के लिए सामान्य (GNU) मेकफाइल्स का उपयोग करते हुए एक क्रॉस प्लेटफ़ॉर्म प्रोजेक्ट के कुछ मेकफ़ाइल्स तय किए हैं। मेक sh.exeरेसिपी की प्रत्येक पंक्ति के लिए एक प्रक्रिया शुरू कर रहा है, जिसके कारण विंडोज और लिनक्स के बीच अंतर दिखाई देता है!

जीएनयू के अनुसार प्रलेखन बनाओ

.ONESHELL:

समस्या को हल करना चाहिए, लेकिन यह सुविधा (वर्तमान में) विंडोज मेक के लिए समर्थित नहीं है। तो एकल तार्किक लाइनों पर होने वाले व्यंजनों को फिर से लिखना (जैसे जोड़कर; वर्तमान संपादक लाइनों के अंत में? या \ _) बहुत अच्छा काम किया!

— V15I0N
स्रोत

4

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

मैंने निर्देशिका ट्रैवर्सल परीक्षण चलाए और परिणाम रिपोर्ट किए गए संकलन समय के बहुत करीब हैं, यह सुझाव देते हुए कि सीपीयू प्रसंस्करण समय या कंपाइलर / लिंकर एल्गोरिदम के साथ इसका कोई लेना-देना नहीं है।

क्रोमियम डायरेक्टरी ट्री को पीछे छोड़ते हुए जैसा कि ऊपर सुझाया गया है:

एनटीएफएस पर विंडोज होम प्रीमियम 7 (8 जीबी राम): 32 सेकंड
Ubuntu 11.04 लिनक्स (2GB Ram) NTFS पर: 10 सेकंड
Ubuntu 11.04 Linux (2GB Ram) ext4: 0.6 सेकंड पर

परीक्षणों के लिए मैंने क्रोमियम स्रोतों को खींचा (दोनों जीत / लिनेक्स के तहत)

git clone http://github.com/chromium/chromium.git 
cd chromium
git checkout remotes/origin/trunk

मेरे द्वारा चलाए गए समय को मापने के लिए

ls -lR > ../list.txt ; time ls -lR > ../list.txt # bash
dir -Recurse > ../list.txt ; (measure-command { dir -Recurse > ../list.txt }).TotalSeconds  #Powershell

मैंने एक्सेस टाइमस्टैम्प, मेरे वायरस स्कैनर को बंद कर दिया और विंडोज़ (> 2 जीबी रैम) के तहत कैश मैनेजर सेटिंग्स को बढ़ा दिया - सभी बिना किसी सुधार के। इस तथ्य का तथ्य यह है कि आउट ऑफ द बॉक्स लिनक्स एक चौथाई रैम के साथ विंडोज की तुलना में 50 गुना बेहतर प्रदर्शन करता है।

जो कोई भी गलत संख्या चाहता है, उसके लिए - जो भी कारण हो - कृपया इसे आजमाएं और अपने निष्कर्षों को पोस्ट करें।

— b7kich
स्रोत

1

विंडोज के लिए मेरे जवाब में कुछ ट्यूनिंग करने के बाद, क्रोमियम पेड़ पर ऊपर "ls -lR" टेस्ट चलाने में 19.4 सेकंड लगे। अगर मैं इसके बजाय "ls -UR" का उपयोग करता हूं (जिसे फ़ाइल आँकड़े नहीं मिलते हैं), समय 4.3 सेकंड तक गिरता है। पेड़ को SSD में ले जाने से कुछ भी गति नहीं हुई, क्योंकि पहले रन के बाद OS द्वारा फ़ाइल डेटा कैश हो जाता है।

— रिकनाज

साझा करने के लिए धन्यवाद! विंडोज 7 'आउट-ऑफ-द-बॉक्स' परिदृश्य की तुलना में एक ठोस कारक 10 सुधार के बावजूद, यह अभी भी लिनक्स या ext4 से भी बदतर 10 का कारक है।

— b7kich

मुझे लगा कि ओपी की बात विंडोज के प्रदर्शन को बेहतर बनाने के लिए थी, है ना? इसके अलावा, जैसा कि मैंने ऊपर पोस्ट किया था, "dir / s" लगभग एक सेकंड में चलता है।

— रिकएनजेड

3

Nmake के बजाय jom का उपयोग करने का प्रयास करें

इसे यहां लाओ: https://github.com/qt-labs/jom

तथ्य यह है कि एनएमके आपके कोर में से केवल एक का उपयोग कर रहा है, जोम एनएमके का एक क्लोन है जो मल्टीकोर प्रोसेसर का उपयोग करता है।

GNU, -j ऑप्शन के लिए आउट-ऑफ-द-बॉक्स धन्यवाद करते हैं, जो कि इसकी गति बनाम Microsoft nakake का कारण हो सकता है।

jom विभिन्न प्रोसेसर / कोर पर समानांतर भिन्न मेक कमांड में निष्पादित करके काम करता है। अपने आप को अंतर महसूस करने की कोशिश करो!

— OpenNingia
स्रोत

1

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

इससे पहले कि मुझे एक बड़ा सिरदर्द हो गया क्योंकि बिल्ड स्पीड 10 के कारक से कम हो गई और जब मैंने समानांतर में वीपीएन कनेक्शन खोला। इस मामले में ये सभी DNS लुकअप वीपीएन के माध्यम से चले गए।

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

— V15I0N
स्रोत

0

मैं हाल ही में विंडोज पर लगभग 10% तक संकलन को गति देने के लिए एक अन्य तरीके से संग्रह कर सकता हूं, जिसमें गनु का उपयोग करके विन-बैश के संस्करण के साथ mingw bash.exe को बदल दिया जाएगा।

(इंटरैक्टिव एडिटिंग के बारे में विन-बैश बहुत आरामदायक नहीं है।)

— V15I0N
स्रोत