क्लेंग बनाम जीसीसी - जो बेहतर बायनेरिज़ का उत्पादन करता है? [बन्द है]

238

बंद हो गया । यह सवाल राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

3 साल पहले बंद हुआ ।

इस प्रश्न को सुधारें

मैं वर्तमान में GCC का उपयोग कर रहा हूं, लेकिन मुझे हाल ही में क्लैंग का पता चला है और मैं स्विचिंग को पॉन्डर्ड कर रहा हूं। एक निर्णायक कारक है - बायनेरिज़ की गुणवत्ता (गति, मेमोरी पदचिह्न, विश्वसनीयता) जो इसका उत्पादन करता है - यदि gcc -O3एक बाइनरी का उत्पादन हो सकता है जो 1% तेजी से चलता है या 1% कम मेमोरी लेता है, तो यह एक डील-ब्रेकर है।

क्लैंग जीसीसी की तुलना में बेहतर संकलन गति और कम संकलन-समय स्मृति पदचिह्न का दावा करता है, लेकिन मैं वास्तव में बेंचमार्क / रुचि रखता हूं जिसके परिणामस्वरूप संकलित सॉफ़्टवेयर की तुलना करता हूं - क्या आप मुझे कुछ अनुभव कर सकते हैं या अपने अनुभवों का वर्णन कर सकते हैं?

— एस एफ।
स्रोत

5

अभी भी एक मूल्यवान प्रश्न और प्रतिक्रियाओं की तरह लगता है, और कई रुचि रखते हैं।

— यासेरास्मि

9

@YasserAsmi: और दो मैट्रिक्स - स्मृति पदचिह्न और निष्पादन की गति - मनमानी या "राय" के अधीन हैं। लेकिन ऐसा लगता है कि फिजिक्स की बीमारी यहां फैल गई है और लोगों ने यहां प्रश्न पाठ विवरणों को पढ़े बिना भी बंद करना शुरू कर दिया।

— एसएफ।

12

प्रश्न बेंचमार्क और तुलना के लिए पूछता है, उत्तर दोनों देता है ... तथ्यात्मक तुलना के बजाय यह राय क्यों है?

— oemb1905

2

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

— टिमोथी मकोबू

2

@ टोमज़िक: यदि आप इन कारकों को जानना चाहते हैं, तो अलग-अलग प्रश्न पूछें। यह एक बहुत विशिष्ट और अस्पष्ट है - निष्पादन की गति और स्मृति पदचिह्न के लिए पूछ रहा है। आप अन्य कारकों में दिलचस्पी ले सकते हैं, आपके लिए अच्छा है, इसका मतलब यह नहीं है कि यह प्रश्न अमान्य है, यह सिर्फ आपके व्यक्तिगत हितों को पूरा नहीं करता है। यह ऐसा है जैसे आप एक जावा प्रोग्रामर हैं और हर C # प्रश्न को बंद करना चाहते हैं क्योंकि यह जावा के बारे में बात नहीं करता है।

— एसएफ।

239

यहाँ GCC 4.7.2 और Clang 3.2 के साथ खदान के लिए कुछ अप-टू-डेट संकीर्ण निष्कर्ष हैं।

अद्यतन: जीसीसी 4.8.1 वी क्लैंग 3.3 तुलना नीचे संलग्न है।

अद्यतन: जीसीसी 4.8.2 वी क्लैंग 3.4 की तुलना में संलग्न है।

मैं एक ओएसएस उपकरण रखता हूं जो लिनक्स के लिए जीसीसी और क्लैंग दोनों के साथ बनाया गया है, और विंडोज के लिए माइक्रोसॉफ्ट के कंपाइलर के साथ। उपकरण, कॉइन, C / C ++ स्रोत फ़ाइलों का प्रीप्रोसेसर और एनालाइज़र है, जो इस प्रकार है: पुनरावर्ती-वंश परसिंग और फ़ाइल-हैंडलिंग पर इसकी कम्प्यूटेशनल प्रोफाइल की बड़ी मात्रा। विकास शाखा (जिससे ये परिणाम प्राप्त होते हैं) में वर्तमान में लगभग 90 फाइल में 11K LOC शामिल है। यह कोडित है, अब, C ++ में जो कि बहुरूपता और टेम्पलेट्स में समृद्ध है और अभी भी हैक-सी में एक साथ इतने दूर के अतीत द्वारा कई पैच में निकाल दिया जाता है। चाल सीमांत का स्पष्ट रूप से शोषण नहीं किया जाता है। यह सिंगल-थ्रेडेड है। मैंने इसे अनुकूलित करने के लिए कोई गंभीर प्रयास नहीं किया है, जबकि "वास्तुकला" इतने बड़े पैमाने पर टूडो है।

मैंने क्लैंग को 3.2 से पहले केवल एक प्रयोगात्मक संकलक के रूप में नियोजित किया, क्योंकि इसकी बेहतर संकलन गति और डायग्नोस्टिक्स के बावजूद, इसके C ++ 11 मानक समर्थन ने समकालीन जीसीसी संस्करण को कोन द्वारा प्रयोग किए जाने वाले सम्मानों में पिछड़ दिया। 3.2 के साथ, इस अंतर को बंद कर दिया गया है।

वर्तमान कॉनन विकास प्रक्रियाओं के लिए मेरा लिनक्स टेस्ट हार्नेस, एक फाइल पार्सर टेस्ट-केस के मिश्रण में लगभग 70K स्रोत फाइलें, <1K फाइलों की खपत करने वाली फाइलों और परिदृश्य परीक्षणों की खपत के तनाव परीक्षण। परीक्षण के परिणामों की रिपोर्ट करने के साथ-साथ हार्नेस जमा हो जाता है और उपभोग की गई फ़ाइलों के योग और कॉन में खपत होने वाले रन समय को प्रदर्शित करता है (यह लिनक्स timeकमांड के लिए प्रत्येक कोन कमांड लाइन को पारित करता है और रिपोर्ट किए गए नंबरों को पकड़ता है और जोड़ता है)। इस तथ्य से समय की चापलूसी की जाती है कि जो भी परीक्षण में 0 औसत दर्जे का समय लगेगा, वे सभी 0 तक जोड़ देंगे, लेकिन ऐसे परीक्षणों का योगदान नगण्य है। समय आँकड़े make checkइस तरह से प्रदर्शित होते हैं :

coan_test_timer: info: coan processed 70844 input_files.
coan_test_timer: info: run time in coan: 16.4 secs.
coan_test_timer: info: Average processing time per input file: 0.000231 secs.

मैंने GCC 4.7.2 और Clang 3.2 के बीच परीक्षण हार्नेस प्रदर्शन की तुलना की, सभी चीजों को संकलक के अलावा बराबर किया गया। क्लैंग 3.2 के रूप में, मुझे अब कोड ट्रैक्स के बीच किसी प्रीप्रोसेसर भेदभाव की आवश्यकता नहीं है जिसे जीसीसी संकलित करेगा और क्लैंग विकल्प। मैंने प्रत्येक मामले में समान C ++ लाइब्रेरी (GCC) का निर्माण किया और सभी तुलनाओं को एक ही टर्मिनल सत्र में लगातार चलाया।

मेरी रिलीज़ बिल्ड के लिए डिफ़ॉल्ट अनुकूलन स्तर -O2 है। मैं भी सफलतापूर्वक परीक्षण -O3 पर बनाता है। मैंने प्रत्येक कॉन्फ़िगरेशन का 3 बार बैक-टू-बैक परीक्षण किया और निम्न परिणामों के साथ 3 परिणामों को औसत किया। डेटा-सेल में संख्या ~ 70K इनपुट फ़ाइलों (पढ़ें, पार्स और राइटिंग आउटपुट और डायग्नोस्टिक्स) में से प्रत्येक को संसाधित करने के लिए coan निष्पादक द्वारा खपत माइक्रोसेकंड की औसत संख्या है।

          | -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.7.2 | 231 | 237 |0.97 |
----------|-----|-----|-----|
Clang-3.2 | 234 | 186 |1.25 |
----------|-----|-----|------
GCC/Clang |0.99 | 1.27|

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

-O3 अनुकूलन जीसीसी के लिए मामूली हानिकारक था
-O3 अनुकूलन क्लैंग के लिए महत्वपूर्ण रूप से फायदेमंद था
At-2 अनुकूलन, GCC क्लिंकर की तुलना में सिर्फ एक मूंछ से तेज था
At-3 अनुकूलन, Clang जीसीसी की तुलना में महत्वपूर्ण रूप से तेज था।

उन निष्कर्षों के कुछ ही समय बाद दुर्घटना के कारण दो संकलकों की एक और दिलचस्प तुलना सामने आई। Coan उदारतापूर्वक स्मार्ट पॉइंटर्स को नियोजित करता है और इस तरह के एक फ़ाइल हैंडलिंग में भारी व्यायाम किया जाता है। यह विशेष रूप से स्मार्ट-पॉइंटर प्रकार कंपाइलर-विभेदन के लिए पूर्व रिलीज़ में टाइप किए गए थे, std::unique_ptr<X>यदि कॉन्फ़िगर कंपाइलर के पास इसके उपयोग के लिए पर्याप्त रूप से परिपक्व समर्थन था, और अन्यथा ए std::shared_ptr<X>। पूर्वाग्रह std::unique_ptrमूर्खतापूर्ण था, क्योंकि ये संकेत वास्तव में आसपास स्थानांतरित किए गए थे, लेकिन एक बिंदु पर std::unique_ptrप्रतिस्थापित करने के लिए फिटर विकल्प की तरह देखा गया std::auto_ptrजब सी ++ 11 वेरिएंट मेरे लिए उपन्यास थे।

क्लैंग 3.2 को आगे std::shared_ptr<X>बढ़ाने के लिए प्रायोगिक बिल्डरों के पाठ्यक्रम में इस और इसी तरह की भिन्नता की निरंतर आवश्यकता है, मैंने अनजाने में निर्मित किया था जब मैंने निर्माण करने का इरादा किया std::unique_ptr<X>था, और यह देखने के लिए आश्चर्यचकित था कि परिणामी निष्पादन योग्य, डिफ़ॉल्ट -O2 अनुकूलन के साथ, सबसे तेज था देखा है, कभी-कभी 184 मिसे प्राप्त कर रहा है। इनपुट फ़ाइल के अनुसार। इस स्रोत कोड में एक परिवर्तन के साथ, इसी परिणाम ये थे;

          | -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.7.2 | 234 | 234 |1.00 |
----------|-----|-----|-----|
Clang-3.2 | 188 | 187 |1.00 |
----------|-----|-----|------
GCC/Clang |1.24 |1.25 |

यहाँ ध्यान देने योग्य बातें हैं:

न तो कंपाइलर अब -ओ 3 ऑप्टिमाइज़ेशन से लाभान्वित होते हैं।
क्लैंग जीसीसी को अनुकूलन के प्रत्येक स्तर पर उतना ही महत्वपूर्ण बनाता है।
जीसीसी का प्रदर्शन केवल स्मार्ट-पॉइंटर प्रकार परिवर्तन से मामूली प्रभावित होता है।
क्लैंग का -O2 प्रदर्शन स्मार्ट-पॉइंटर प्रकार परिवर्तन से महत्वपूर्ण रूप से प्रभावित होता है।

स्मार्ट-पॉइंटर प्रकार परिवर्तन से पहले और बाद में, क्लॉन्ग-ओ 3 ऑप्टिमाइज़ेशन में काफी तेजी से कोऑन एक्ज़ीक्यूटेबल बनाने में सक्षम है, और यह ओ-ओ 2 और -ओ 3 में समान रूप से तेज़ निष्पादन योग्य बना सकता है जब पॉइंटर-टाइप सबसे अच्छा हो std::shared_ptr<X>- काम के लिए।

एक स्पष्ट सवाल है कि मैं इस पर टिप्पणी करने के लिए सक्षम नहीं हूं, इसलिए क्लैंग को मेरे आवेदन में 25% -O2 गति-अप का पता लगाने में सक्षम होना चाहिए जब एक भारी उपयोग किए जाने वाले स्मार्ट-पॉइंटर-प्रकार को अद्वितीय से साझा किया जाता है, जबकि जीसीसी उदासीन है उसी बदलाव के लिए। और न ही मुझे पता है कि मुझे इस खोज को खुश करना चाहिए या बू करना चाहिए कि क्लैंग -ओ 2 अनुकूलन मेरे स्मार्ट-पॉइंटर विकल्पों के ज्ञान के लिए इतनी बड़ी संवेदनशीलता को परेशान करता है।

अद्यतन: जीसीसी 4.8.1 वी क्लैंग 3.3

अब इसी परिणाम हैं:

          | -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.8.1 | 442 | 443 |1.00 |
----------|-----|-----|-----|
Clang-3.3 | 374 | 370 |1.01 |
----------|-----|-----|------
GCC/Clang |1.18 |1.20 |

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

नोट के बिंदु अब उपन्यास नहीं हैं:

GCC, -O3 अनुकूलन के प्रति उदासीन है
-ओ 3 ऑप्टिमाइज़ेशन से क्लैंग को बहुत मामूली लाभ होता है
क्लेंग जीसीसी के अनुकूलन के प्रत्येक स्तर पर समान रूप से महत्वपूर्ण मार्जिन से धड़कता है।

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

अद्यतन: जीसीसी 4.8.2 वी क्लैंग 3.4

मैंने GCC 4.8.1 v क्लैंग 3.3 के लिए अपडेट को यह कहते हुए समाप्त कर दिया कि मैं आगे के अपडेट के लिए एक ही कॉइन स्नैपशॉट से चिपका रहूंगा। लेकिन मैंने इसके बजाय उस स्नैपशॉट (रेव। 301) पर परीक्षण करने का फैसला किया और नवीनतम विकास स्नैपशॉट पर मेरे पास है कि उसका सुइट सूट (रेव। 619) से गुजरता है। यह परिणामों को थोड़ा देशांतर देता है, और मेरा एक और मकसद था:

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

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

यहाँ अब नवीनतम दो संकलक 'Rev.301 के निर्माण के लिए परिचित समय मैट्रिक्स है:

coan - rev.301 परिणाम

          | -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.8.2 | 428 | 428 |1.00 |
----------|-----|-----|-----|
Clang-3.4 | 390 | 365 |1.07 |
----------|-----|-----|------
GCC/Clang | 1.1 | 1.17|

यहां कहानी केवल GCC-4.8.1 और क्लैंग-3.3 से मामूली रूप से बदली गई है। जीसीसी का प्रदर्शन एक बेहतर प्रदर्शन है। क्लैंग एक ट्रिफ़ल बदतर है। इसके लिए शोर अच्छा हो सकता है। क्लैंग अभी भी आगे आया है -O2और -O3मार्जिन है कि ज्यादातर अनुप्रयोगों में कोई फर्क नहीं पड़ता, लेकिन काफी कुछ के लिए मायने रखता है।

और यहाँ रेव के लिए मैट्रिक्स है। 619।

coan - rev.619 परिणाम

          | -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.8.2 | 210 | 208 |1.01 |
----------|-----|-----|-----|
Clang-3.4 | 252 | 250 |1.01 |
----------|-----|-----|------
GCC/Clang |0.83 | 0.83|

301 और 619 के आंकड़ों को एक साथ लेते हुए, कई बिंदुओं पर बात होती है।

मैं तेजी से कोड लिखने का लक्ष्य बना रहा था, और दोनों संकलक जोर-शोर से मेरे प्रयासों को पूरा करते हैं। परंतु:
जीसीसी उन प्रयासों को क्लैंग की तुलना में कहीं अधिक उदारता से दोहराता है। पर -O2 अनुकूलन बजना के 619 निर्माण 46% अपने 301 निर्माण की तुलना में तेजी है: पर -O3बजना के सुधार 31% है। अच्छा है, लेकिन प्रत्येक अनुकूलन स्तर पर जीसीसी का 619 बिल्ड अपने 301 के मुकाबले दोगुना से अधिक है।
जीसीसी से अधिक क्लेंग की पूर्व श्रेष्ठता को उलट देता है। और प्रत्येक अनुकूलन स्तर पर GCC अब Clang को 17% से हरा देती है।
301 बिल्ड में क्लैंग की क्षमता -O3अनुकूलन से जीसीसी की तुलना में अधिक लाभ उठाने के लिए 619 बिल्ड में चली गई है। न तो कंपाइलर से सार्थक लाभ होता है -O3।

मैं भाग्य के इस उलटफेर से काफी हैरान था कि मुझे शक था कि मैंने गलती से क्लैंग 3.4 का सुस्त निर्माण किया होगा (क्योंकि मैंने इसे स्रोत से बनाया है)। इसलिए मैंने अपने डिस्ट्रो के स्टॉक क्लैंग 3.3 के साथ 619 टेस्ट को फिर से चलाया। परिणाम व्यावहारिक रूप से 3.4 के लिए समान थे।

यू-टर्न की प्रतिक्रिया के रूप में: यहां के नंबरों पर, क्लैंग ने जीसीसी की तुलना में मेरे सी ++ कोड से बाहर गति पर बहुत बेहतर काम किया है जब मैं इसे कोई मदद नहीं दे रहा था। जब मैंने मदद करने का मन बनाया, तो जीसीसी ने क्लैंग की तुलना में बहुत बेहतर काम किया।

मैं उस सिद्धांत को एक सिद्धांत में नहीं बढ़ाता, लेकिन मैं यह सबक लेता हूं कि "कौन सा संकलक बेहतर बायनेरिज़ का उत्पादन करता है?" यह एक प्रश्न है कि, भले ही आप परीक्षण सूट को निर्दिष्ट करते हैं, जिसका उत्तर सापेक्ष होगा, फिर भी केवल बायनेरिज़ के समय का स्पष्ट-कट मामला नहीं है।

क्या आपका बेहतर द्विआधारी सबसे तेज द्विआधारी है, या यह वह है जो सस्ते से तैयार किए गए कोड के लिए सबसे अच्छा मुआवजा देता है? या महंगे गढ़े हुए कोड के लिए सबसे अच्छा क्षतिपूर्ति करता है जो स्थिरता को प्राथमिकता देता है और गति पर पुन: उपयोग करता है? यह बाइनरी के निर्माण के लिए आपके उद्देश्यों की प्रकृति और सापेक्ष वजन पर निर्भर करता है, और उन बाधाओं के तहत जिनके तहत आप ऐसा करते हैं।

और किसी भी मामले में, यदि आप "सर्वश्रेष्ठ" बायनेरिज़ के निर्माण के बारे में गहराई से ध्यान रखते हैं, तो आपने बेहतर तरीके से जांचा था कि संकलकों के क्रमिक पुनरावृत्तियों ने आपके कोड के क्रमिक पुनरावृत्तियों पर "सर्वश्रेष्ठ" के अपने विचार को कैसे पहुंचाया।

— माइक किंगान
स्रोत

9

क्लैंग तेजी से क्यों है? उदाहरण के लिए, इंटेल कंपाइलर ने इंटेल चिप्स की विशेषता का उपयोग किया। एक लाभ प्राप्त करने के लिए क्लैंग का उपयोग क्या है? क्या कोड को फिर से लिखा जा सकता है ताकि gcc का प्रदर्शन समान हो?

— kirill_igum

27

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

— माइक राजा

3

kcachegrindउन कार्यों को इंगित करने के लिए उपयोग करना संभव है जहां उत्पन्न निष्पादन निष्पादन में भिन्न होते हैं।

4

-1: यह एक उत्तर की तुलना में एक उपन्यास (या ब्लॉग पोस्ट) का अधिक है।

— जॉन सॉन्डर्स

60

@ जॉनसनर्स: एक व्यक्ति के लिए जो एक विस्तृत, गहन उत्तर है, दूसरे के लिए उनके ध्यान देने योग्य उपन्यास है। मुझे बताओ कि इन दो लोगों को क्या अलग करता है।

— एसएफ।

48

Phoronix ने इस बारे में कुछ बेंचमार्क किए , लेकिन यह कुछ महीने पहले से Clang / LLVM के स्नैपशॉट संस्करण के बारे में है। परिणाम यह है कि चीजें अधिक-या-कम एक धक्का थीं; सभी मामलों में न तो जीसीसी और न ही क्लैंग निश्चित रूप से बेहतर है।

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

मुझे लगता है कि क्लैंग की तेज संकलन गति मूल डेवलपर्स के लिए अच्छी होगी, और तब जब आप दुनिया में कोड को बाहर धकेलते हैं, लिनक्स डिस्ट्रो / बीएसडी / आदि। एंड-यूजर्स तेजी से बायनेरिज़ के लिए जीसीसी का उपयोग करेंगे।

— Nietzche-jou
स्रोत

2

बस आज मैं क्लैंग संकलन गति पर कुछ बेंचमार्क चलाता हूं और यह शुद्ध सी के लिए बहुत निराशाजनक है। 270 केएलओसी क्लैंग के साथ 35 सी फ़ाइलों को संकलित करना केवल 25% तेज था। जब मैं देखता हूं कि लिनेक्स में कितनी तेजी से टिल्क है तो यह एक नए लिखित संकलक के लिए एक बुरा परिणाम है। ऑप्टिमाइज़ेशन -ओ 2 / -ओ 3 का उपयोग करते समय यह बेहतर हो जाता है लेकिन जब से वे रिलीज के लिए उपयोग किए जाते हैं कंपाइलर प्रदर्शन इस मामले में मायने नहीं रखता है।

— लोथार

7

@mcandre शायद नीत्शे-जौ को क्लैंग के साथ संकलित किया गया था, जबकि आप जीसीसी के साथ संकलित थे।

— मतीन उलहाक

18

तथ्य यह है कि क्लैंग कोड तेजी से संकलन करता है, परिणामस्वरूप बाइनरी की गति के रूप में महत्वपूर्ण नहीं हो सकता है। हालाँकि, यहाँ बेंचमार्क की एक श्रृंखला है ।

— mcandre
स्रोत

12

वास्तव में यह करता है। विकास के दौरान संकलन समय (और संकलन के कारण संसाधनों की खपत) द्विआधारी प्रदर्शन की तुलना में बहुत अधिक अड़चन है। आखिरकार, हम इस स्तर पर डिबग मोड में संकलित करते हैं। यह केवल तभी होता है जब आप परीक्षण मोड में आते हैं और शिप करते हैं जिसे आप रिलीज़ मोड पर स्विच करते हैं और जितनी जल्दी हो सके बाइनरी प्राप्त करने का प्रयास करते हैं।

— मैथ्यू एम।

3

@ मैथ्यू एम: मैं कसम खाता हूं कि जवाब "हो सकता है ..", जैसे कि वह एक संभावित चिंता ला रहा था। मुझे लगता है कि शायद यह ध्यान देने योग्य था क्योंकि यह ओपी से संबंधित था।

— जेएम बेकर

सहमत हैं, हालांकि यहां सभी अच्छे बिंदु हैं। बल्कि मैं एक दूसरे या तीसरे RAID 0 ड्राइव, एक एसएसडी, या अधिक और तेजी से रैम में फेंक दूंगा और सबसे अच्छा .exe प्रदर्शन प्राप्त कर सकता हूं - बशर्ते कि वे उपाय आपको समता या नज़दीकी तक पहुंचा सकें। यह कभी-कभी एक से अधिक संकलक के साथ विकसित करने में सहायक होता है। यह आपको गैर-पोर्टेबल सुविधाओं से अवगत करा सकता है, और उन त्रुटियों को पकड़ सकता है जो अन्यथा अनिर्धारित हो जाती हैं, या व्यर्थ समय बर्बाद करने के लिए नेतृत्व करने की कोशिश करते हुए एक बेहतर संकलक को चेतावनी / गलत हो सकता है।

मैंने आज कुछ तंग प्रदर्शन क्रिटिकल पूर्णांक कोड की तुलना करने की कोशिश की जो मैंने लिखा था और जीसीसी दोनों -O2 और -O3 का उपयोग करके बहुत तेज़ी से (22S क्लैंग-एलएलवी 25 एस) चला। कंपाइलर स्विच (जीसीसी या क्लैंग) का उपयोग करने के बारे में सोचें, जो गैर-मानक सुविधाओं और स्थिर चेतावनियों को कवर करता है। अपने स्वयं के बड़े प्रोजेक्ट में, दूसरे पीपीएल के कोड को संकलित नहीं कर रहे हैं, आप अपने बिल्ड सिस्टम में कुछ गलत कर रहे हैं यदि संकलन समय लिंक समय पर हावी है। Ccache.samba.org जैसे उपकरण हैं जो यदि आप अक्सर साफ करते हैं तो मदद करते हैं। बदलते कंपाइलरों के साथ एक और मुद्दा, परीक्षण / सत्यापन में हर समय किया जाने वाला निवेश है जिसे फेंक दिया जाता है।

— Rob11311

code.google.com/p/distcc एक अन्य परियोजना है जो बल्क कंपाइल समय को गति दे सकती है, यदि डेटा संरचना में बदलाव के कारण या सत्यापन / सत्यापन उद्देश्यों के लिए पूरी लाइब्रेरी को फिर से तैयार करने की आवश्यकता है

— Rob11311

11

परिणामी बाइनरी की गति के संदर्भ में जीसीसी 4.8 और क्लैंग 3.3 के बीच बहुत कम अंतर है। ज्यादातर मामलों में दोनों कंपाइलरों द्वारा उत्पन्न कोड समान रूप से कार्य करता है। इन दोनों में से कोई भी कंपाइलर दूसरे पर हावी नहीं है।

बेंचमार्क बताता है कि जीसीसी और क्लैंग के बीच एक महत्वपूर्ण प्रदर्शन अंतराल है।

प्रोग्राम का प्रदर्शन कंपाइलर की पसंद से प्रभावित होता है। यदि कोई डेवलपर या डेवलपर्स का समूह विशेष रूप से जीसीसी का उपयोग कर रहा है, तो कार्यक्रम को क्लैंग के साथ जीसीसी के साथ थोड़ा तेज चलने की उम्मीद की जा सकती है, और इसके विपरीत।

डेवलपर के दृष्टिकोण से, GCC 4.8+ और clang 3.3 के बीच एक उल्लेखनीय अंतर यह है कि GCC के पास -Ogकमांड लाइन विकल्प है। यह विकल्प ऐसे अनुकूलन को सक्षम करता है जो डिबगिंग में हस्तक्षेप नहीं करते हैं, इसलिए उदाहरण के लिए सटीक स्टैक के निशान प्राप्त करना हमेशा संभव होता है। क्लैंग में इस विकल्प की अनुपस्थिति क्लैंग को कुछ डेवलपर्स के लिए अनुकूलन कंपाइलर के रूप में उपयोग करने के लिए कठिन बनाती है।

हाल ही में, (3.3 और 4.8) मैं संकलन समय के बीच बहुत अंतर नहीं देख रहा हूं। ("मेरे" कार्यक्रमों में 10 सेकंड और 30 सेकंड के बीच संकलन समय के साथ)।

— alfC

9

इसे निर्धारित करने का एकमात्र तरीका यह प्रयास करना है। एफडब्ल्यूआईडब्ल्यू मैंने नियमित रूप से जीसी 4.2 (एक्स 86-64 कोड के लिए काफी एसएसई के साथ) की तुलना में एप्पल के एलएलवीएम जीसी 4.2 का उपयोग करते हुए कुछ बहुत अच्छे सुधार देखे हैं, लेकिन विभिन्न कोड आधारों के लिए वाईएमएमवी। मान लें कि आप x86 / x86-64 के साथ काम कर रहे हैं और आप वास्तव में पिछले कुछ प्रतिशत के बारे में परवाह करते हैं, तो आपको इंटेल के ICC को भी आज़माना चाहिए, क्योंकि यह अक्सर gcc को हरा सकता है - आप Intel.com से 30 दिनों का मूल्यांकन लाइसेंस प्राप्त कर सकते हैं और कोशिश करो।

— पॉल आर
स्रोत

8

एक अजीब अंतर है जो मैंने gcc 5.2.1 पर नोट किया है और 3.6.2 क्लैंग है कि यदि आपके पास एक महत्वपूर्ण लूप है जैसे:

for (;;) {
    if (!visited) {
        ....
    }
    node++;
    if (!*node) break;
  }

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

मुझे कोई पता नहीं है अगर अनियंत्रित अंतर एक सामान्य प्रवृत्ति है या सिर्फ कुछ ऐसा है जो मेरे परिदृश्य के लिए विशिष्ट था।

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

परिणाम हैं (सेकंड में संख्या):

+---------------------+-----+-----+
|Type                 |GCC  |Clang|
+---------------------+-----+-----+
|Copying GC           |22.46|22.55|
|Copying GC, optimized|22.01|20.22|
|Mark & Sweep         | 8.72| 8.38|
|Ref Counting/Cycles  |15.14|14.49|
|Ref Counting/Plain   | 9.94| 9.32|
+---------------------+-----+-----+

यह सभी शुद्ध सी कोड है और मैं सी ++ कोड को संकलित करते समय या तो संकलक प्रदर्शन के बारे में कोई दावा नहीं करता हूं।

उबंटू 15.10, x86.64 पर, और एक एएमडी फेनोम (टीएम) II X6 1090T प्रोसेसर।

— ब्योर्न लिंडक्विस्ट
स्रोत

4

असल में, इसका जवाब है: यह निर्भर करता है। विभिन्न प्रकार के अनुप्रयोगों पर ध्यान केंद्रित करने वाले कई बेंचमार्क हैं।

मेरे ऐप पर मेरा बेंचमार्क है: gcc> icc> clang।

दुर्लभ IO हैं, लेकिन कई सीपीयू फ्लोट और डेटा संरचना संचालन हैं।

संकलित झंडे है -all -g -DNDEBUG -O3।

https://github.com/zhangyafeikimi/ml-pack/blob/master/gbdt/profile/benchmark

— किमि
स्रोत