आभासी मशीन पर अधिक CPU कोर धीमा संकलन समय क्यों होगा?

Question

[# 2 संपादित करें] अगर VMWare से कोई भी मुझे VMWare फ्यूजन की एक प्रति के साथ मार सकता है, तो मैं एक VirtualBox बनाम VMWare तुलना के समान ही करने के लिए खुश हूं। किसी तरह मुझे संदेह है कि VMWare हाइपरविजर हाइपरथ्रेडिंग के लिए बेहतर ट्यून होगा (मेरा उत्तर भी देखें)

मुझे कुछ उत्सुक दिखाई दे रहा है। जैसे ही मैं अपने विंडोज 7 x64 वर्चुअल मशीन पर कोर की संख्या बढ़ाता हूं, समग्र संकलन का समय घटने के बजाय बढ़ता जाता है। संकलन आमतौर पर समानांतर प्रसंस्करण के लिए बहुत अच्छी तरह से अनुकूल है जैसा कि मध्य भाग (पोस्ट डिपेंडेंसी मैपिंग) में आप बस अपने प्रत्येक .c / .cpp / .cs / जो भी फ़ाइल में लिंकर के लिए आंशिक ऑब्जेक्ट बनाने के लिए एक कंपाइलर उदाहरण को कॉल कर सकते हैं। ऊपर। इसलिए मैंने कल्पना की होगी कि संकलन वास्तव में # कोर के साथ बहुत अच्छा होगा।

लेकिन मैं जो देख रहा हूं वह है:

• 8 कोर: 1.89 सेकंड
• 4 कोर: 1.33 सेकंड
• 2 कोर: 1.24 सेकंड
• 1 कोर: 1.15 सेकंड

क्या यह केवल एक विशेष विक्रेता के हाइपरविजर कार्यान्वयन (टाइप 2: मेरे मामले में वर्चुअलबॉक्स) या हाइपरवाइजर कार्यान्वयन को और अधिक सरल बनाने के लिए अधिक वीएम भर में कुछ अधिक व्यापक है? इतने सारे कारकों के साथ, मैं इस व्यवहार के लिए और इसके विपरीत दोनों तर्क करने में सक्षम हो सकता हूं - इसलिए यदि कोई मुझसे अधिक इस बारे में जानता है, तो मैं आपके उत्तर को पढ़ने के लिए उत्सुक हूं।

धन्यवाद सिड

[ संपादित करें: टिप्पणियों को संबोधित करना ]

@MartinBeckett: कोल्ड कंपाइल को छोड़ दिया गया।

@MonsterTruck: सीधे संकलन करने के लिए एक ओपनसोर्स प्रोजेक्ट नहीं मिल सका। बहुत अच्छा होगा, लेकिन अभी मेरे देव env को खराब नहीं कर सकते।

@Mr Lister, @philosodad: VirtualBox का उपयोग करते हुए, 8 hw थ्रेड्स हैं, इसलिए इम्यूलेशन के बिना 1: 1 मैपिंग होनी चाहिए

@Thorbjorn: मेरे पास VM के लिए 6.5GB और एक छोटा-सा VS2012 प्रोजेक्ट है - यह काफी संभावना नहीं है कि मैं पेज फाइल को ट्रैश / आउट कर रहा हूं।

@ सभी: यदि कोई किसी खुले स्रोत VS2010 / VS2012 परियोजना की ओर इशारा कर सकता है, तो यह मेरे (स्वामित्व) VS2012 परियोजना से बेहतर सामुदायिक संदर्भ हो सकता है। Orchard और DNN VS2012 में संकलित करने के लिए पर्यावरण की जरूरत है। मैं वास्तव में यह देखना चाहूंगा कि क्या VMWare Fusion के साथ भी कोई इसे देखता है (VMWare बनाम वर्चुअलबॉक्स कम्पार्टमेंटलाइज़ेशन के लिए)

परीक्षण विवरण:

• हार्डवेयर: मैकबुक प्रो रेटिना
  • सीपीयू: कोर i7 @ 2.3Ghz (क्वाड कोर, हाइपर थ्रेडेड = विंडोज़ कार्य प्रबंधक में 8 कोर)
  • मेमोरी: 16 जीबी
  • डिस्क: 256GB SSD
• होस्ट ओएस: मैक ओएस एक्स 10.8
• VM प्रकार: VirtualBox 4.1.18 (टाइप 2 हाइपरविजर)
• अतिथि OS: विंडोज 7 x64 SP1
• कंपाइलर: VS2012 3 सी # एज़्योर परियोजनाओं के साथ एक समाधान का संकलन
  • 'VSCommands' नामक VS2012 प्लगइन द्वारा संकलित बार माप
  • सभी परीक्षण 5 बार चलते हैं, पहले 2 रन छूटे, अंतिम 3 औसत

Comments

संभवतः फ़ाइल I / O इसे गुणकों कार्यों के साथ धीमा कर रही है और डिस्क तक वर्चुअलाइज्ड ड्राइव पर जा रही है

— मार्टिन बेकेट

मैं इसे अपनी मशीन पर पुन: पेश करना चाहता हूं। क्या आप कहीं एक नमूना परियोजना अपलोड कर सकते हैं? मुझे शक है कि वर्चुअल मशीन यहाँ ट्रिक्स खेल रही है। मूल रूप से विंडोज (बूटकैम्प) को बूट करने की कोशिश करें और देखें कि क्या आप एक ही व्यवहार का निरीक्षण करते हैं - मुझे संदेह है कि आप करेंगे।

— अपूर्व खुरसिया १५'१२

हम यहां क्या संकलित कर रहे हैं? समय के बहुत सारे एक काम को समानांतर करने का ओवरहेड भुगतान नहीं करता है जब तक कि आप कुछ पैमाने पर हिट नहीं करते हैं। देखें कि अपाचे या रैवेंडब कैसे संकलित करता है।

— व्याट बार्नेट

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

जावा i3 पर संकलित करने के लिए Maven 3.x का उपयोग करने से पहले जावा के साथ एक ही बात हुई है। इसे "4" करने के लिए डिफ़ॉल्ट रूप से थ्रेडिंग बहुत धीमी थी, 50% धीमी के पास, यह स्पष्ट रूप से बताने के बजाय केवल 2 कोर का उपयोग करने के लिए। मुझे लगता है कि इसका हाइपर-थ्रेडिंग संदर्भ स्विचिंग और ओवरलैपिंग I / O के साथ कुछ करना है।

Answer 1

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

यह उस नए प्रयोग पर आधारित है जिसे मैंने प्रश्न (और मेरी व्यक्तिगत जिज्ञासा) पर टिप्पणी के आधार पर किया था। मैंने एक बड़ी वीएस परियोजना का उपयोग किया - उम्ब्राको सीएमएस के स्रोत कोड चूंकि यह बड़ा है, खुला है और एक सीधे समाधान फ़ाइल को लोड कर सकता है और पुनर्निर्माण कर सकता है (संकेत: umbraco_675b272bb0a3\src\umbraco.slnवीएस2010 / वीएस2012 में लोड )।

अब, मैं जो देखता हूं वह वही है जो मैं उम्मीद करता हूं, यानी कंपाइल अप स्केल !! खैर, जब से मैं पाता हूँ:

टेकअवे:

• वर्चुअलबॉक्स प्रक्रिया के भीतर एक नया वीएम कोर एक नया ओएस एक्स थ्रेड में परिणाम करता है
• उम्मीद के अनुसार संकलन समय पैमाने (संकलन काफी लंबे हैं)
• 8 वीएम कोर पर, कोर इम्यूलेशन वर्चुअलबॉक्स के भीतर किकिंग कर सकता है क्योंकि पेनल्टी बड़ी है (50% हिट)
• उपरोक्त संभावना है क्योंकि OS X 4 हाइपर थ्रेडेड कोर (8 h / w थ्रेड) को 8 कोर के रूप में वर्चुअलबॉक्स में प्रस्तुत करने में असमर्थ है

उस आखिरी बिंदु ने मुझे 'गतिविधि मॉनिटर' (सीपीयू इतिहास) के माध्यम से सीपीयू के इतिहास की निगरानी करने का कारण बनाया और मुझे जो मिला था

टेकअवे:

• एक वीएम कोर में, गतिविधि 4 HW कोर के पार हो रही है। मूल स्तर पर समान रूप से गर्मी वितरित करने के लिए समझ में आता है।

• यहां तक ​​कि 4 वर्चुअल कोर (और 27 वर्चुअलबॉक्स OS X थ्रेड्स या ~ 800 OS X थ्रेड समग्र) में, यहां तक ​​कि केवल HW थ्रेड्स (0,2,4,6) विषम HW थ्रेड्स (1,3,5,7) में लगभग संतृप्त होते हैं लगभग 0% पर हैं। अधिक संभावना है कि शेड्यूलर HW कोर और HW थ्रेड्स के संदर्भ में काम करता है इसलिए मैं अनुमान लगाता हूं कि शायद OSX 64 बिट कर्नेल / अनुसूचक हाइपर थ्रेडेड CPU के लिए अनुकूलित नहीं है? या 8VM कोर सेटअप को देखते हुए, शायद यह एक उच्च% CPU उपयोग पर उनका उपयोग करना शुरू कर देता है? कुछ मज़ेदार है ... एक अच्छी तरह से, कुछ डार्विन डेवलपर्स के लिए एक अलग सवाल है ...

[संपादित करें]: मैं VMWare फ्यूजन में एक ही कोशिश करना पसंद करूंगा। संभावना है कि यह यह बुरा नहीं होगा। मुझे आश्चर्य है कि अगर वे इसे एक वाणिज्यिक उत्पाद के रूप में प्रदर्शित करते हैं ...

पाद:

यदि चित्र कभी गायब हो जाते हैं, तो संकलन समय सारणी है (पाठ, बदसूरत!)

Cores in    Avg compile      Host/OSX    Host/OSX CPU
   VM         times (sec)   Threads      consumption
    1           11.83            24        105-115%
    2           10.04            25        140-190%
    4            9.59            27        180-270%
    8           14.18            31        240-430%

Comments

मुझे संदेह है कि 4 और 8 के बीच की गिरावट वीएम का एक संयोजन है जिसे एचटी के लिए अनुकूलित नहीं किया जा सकता है, और एचटी किसी भी तरह से दो कोर के बराबर नहीं है ( सबसे अच्छा 30% प्रदर्शन में वृद्धि, आमतौर पर बहुत कम)।

— डैनियल बी

@ डैनियलबी: 4 => 8 कोर पर, मुद्दा यह नहीं है कि यह केवल एक मात्र 30% बढ़ावा (बनाम 100%) है जैसा आपने सुझाव दिया - यह है कि प्रदर्शन वास्तव में -50% है। यदि हार्डवेयर थ्रेड पूरी तरह से 'डेड / बेकार' थे और काम को अन्य कोर में डायवर्ट किया जा रहा था, तो प्रदर्शन डेल्टा 0. होगा। इसलिए मैं यह कहना चाहूंगा कि यह वर्चुअलबॉक्स टाइप 2 हाइपरवाइजर पर डिजाइन है। मुझे आश्चर्य है कि कैसे VMWare फ्यूजन है ...

— दीपस्पेस101101

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

— gbjbaanb

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

— डैनियल बी

Answer 2

ऐसा होने का केवल एक संभावित कारण है, जो यह है कि आपका ओवरहेड आपके लाभ से अधिक है।

हो सकता है कि आप वास्तविक कोर या यहां तक ​​कि प्रक्रियाओं या यहां तक ​​कि मेजबान मशीन से थ्रेड असाइन करने के बजाय कई कोर का अनुकरण कर रहे हों। यह मेरे लिए बहुत संभावना है, और जाहिर है कि आपको नकारात्मक गति प्रदान करने जा रहा है।

दूसरी संभावना यह है कि प्रक्रिया स्वयं अच्छी तरह से समानांतर नहीं होती है, और यहां तक ​​कि इसे समानांतर करने का प्रयास आपको संचार ओवरहेड में अधिक खर्च कर रहा है जितना आप प्राप्त कर रहे हैं।

Comments

your overhead is exceeding your gains: सच है, लेकिन यह बहुत ज्यादा सब कुछ कवर करता है बिना यह जाने कि वास्तव में यह क्या कारण है :) ... मैं वर्चुअलबॉक्स का उपयोग कर रहा हूं और भौतिक कोर है, इसलिए मान लिया गया कि अनुकरण के बिना 1: 1 होना चाहिए। मैं एक बड़े खुले स्रोत VS2012 की खोज करने जा रहा हूं ताकि अन्य लोग भी इसका संदर्भ ले सकें ...

— brb

@ इस उत्तर के अनुसार superuser.com/a/297727 वर्चुअलबॉक्स VM को होस्ट कोर का उचित उपयोग करना चाहिए। लेकिन मैं अभी भी जाँच करूँगा कि मेजबान पर क्या हो रहा है, यह सुनिश्चित करने के लिए कि अपेक्षित व्यवहार हो रहा है।

— फिलोसोडैड

Answer 3

तुम अकेले नही हो ...

जावा i3 पर संकलित करने के लिए Maven 3.x का उपयोग करने से पहले जावा के साथ एक ही बात हुई है। इसे "4" करने के लिए डिफ़ॉल्ट रूप से थ्रेडिंग बहुत धीमी थी, 50% धीमी के पास, यह स्पष्ट रूप से बताने के बजाय केवल 2 कोर का उपयोग करने के लिए।

मुझे लगता है कि इसका हाइपर-थ्रेडिंग संदर्भ स्विचिंग और ओवरलैपिंग I / O के साथ कुछ करना है।

यह समझ में आता है जब आप इसके बारे में सोचना शुरू करते हैं। आप साबित कर सकते हैं कि एक अच्छे सिस्टम वाइड प्रोफाइलिंग टूल के साथ परिणामों के पतन का क्या कारण है।