क्या इंटेल कंपाइलर वास्तव में Microsoft से बेहतर हैं? [बन्द है]


56

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

आपके अनुभव से, यदि लाइसेंस लागत कोई फर्क नहीं पड़ता, तो कौन सा विक्रेता विजेता है?

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

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

और इसी तरह। लेकिन किसी को कुछ जवाब पता है।


17
Intel Compilers के पास बहुत कुशल संख्यात्मक कोड को प्रोडक्ट करने के लिए एक प्रतिष्ठा है।
quant_dev

2
@ हाँक: यदि क्वांट_देव उस लिंक को वापस करने के लिए कुछ लिंक प्रदान कर सकता है, तो हाँ यह होना चाहिए!
FrustratedWithFormsDesigner

2
@RocketSurgeon: आपके कथन से हर कोई सहमत नहीं होगा। वास्तव में, एरिक रेमंड Microsoft के लिए एक बहुत ही मजबूत मामला बनाता है, जिसने कुछ दशकों तक अपने व्यवसाय प्रथाओं के साथ कंप्यूटिंग की प्रगति को पकड़ रखा है।
मेसन व्हीलर

2
@RocketSurgeon ओपन सोर्स का पैसे से कोई लेना-देना नहीं है।
१३:१३ पर काओ

1
Microsoft संकलक बहुत अच्छा कोड उत्पन्न करता है। असेंबली के मैनुअल निरीक्षण में शायद ही कभी कोई मूर्खतापूर्ण निर्देश अनुक्रम पाया जाता है। वास्तव में, मैं प्रभावित हुआ कि अनुकूलन कितना गहरा है, यह कैश लाइन की सीमाओं को पार करने के निर्देशों को भी रोकता है।
doug65536 1

जवाबों:


57

चेतावनी: स्वयं के अनुभव के आधार पर उत्तर - YMMV

यदि कोड वास्तव में कम्प्यूटेशनल रूप से महंगा है, तो हां, निश्चित रूप से । मैंने पूर्व Microsoft C ++ कंपाइलर (अब Intel Studio यदि मुझे सही से याद है) बनाम मानक Microsoft Visual C ++ कंपाइलर के साथ 20x बार सुधार देखा है । यह सच है कि कोड एकदम सही था और जिसने एक भूमिका निभाई हो सकती है (वास्तव में इसलिए हमने इंटेल कंपाइलर का उपयोग करके परेशान किया, यह विशालकाय कोडबेस को रिफैक्ट करने की तुलना में आसान था), सीपीयू भी कोड को चलाने के लिए उपयोग किया गया था एक Intel Core 2 क्वाड, जो इस तरह की चीज के लिए एकदम सही सीपीयू है, लेकिन परिणाम चौंकाने वाले थे। कंपाइलर में कोड को ऑप्टिमाइज़ करने के तरीके, असंख्य एसएसपी क्षमताओं के संदर्भ में एक विशेष सीपीयू को लक्षित करने के तरीके शामिल हैं । यह वास्तव में शर्मिंदा करता है -O2/ -O3भाग जाता है। और वह थाप्रोफाइलर का उपयोग करने से पहले

ध्यान दें, हालांकि, वास्तव में आक्रामक अनुकूलन को चालू करने से संकलन को कुछ समय लगेगा, एक बड़ी परियोजना के लिए दो घंटे बिल्कुल भी असंभव नहीं है। इसके अलावा, उच्च स्तर के अनुकूलन के साथ, स्वयं को प्रकट करने के लिए कोड में त्रुटि का एक उच्च मौका है (इसे जीसीसी के साथ -O3भी देखा जा सकता है )। जिस प्रोजेक्ट को आप अच्छी तरह से जानते हैं, यह एक प्लस हो सकता है, क्योंकि आप पहले से पकड़े गए किसी भी अंतिम बग को नहीं खोज पाएंगे और ठीक कर सकते हैं, लेकिन जब बालों वाली गंदगी का संकलन होता है, तो आप बस अपनी उंगलियों को पार करते हैं और x86 देवताओं से प्रार्थना करते हैं।

एएमडी मशीनों पर प्रदर्शन के बारे में कुछ: यह इंटेल सीपीयू के रूप में रूप में अच्छा नहीं है, लेकिन यह अभी भी जिस तरह से (फिर से, मेरे अनुभव से) एमएस सी ++ संकलक की तुलना में बेहतर। कारण यह है कि आप SSE2 समर्थन (उदाहरण के लिए) के साथ एक सामान्य CPU को भी लक्षित कर सकते हैं । तब SSE2 के साथ AMD CPU में अधिक भेदभाव नहीं किया जाएगा। इंटेल सीपीयू पर इंटेल कंपाइलर वास्तव में शो चोरी करता है, हालांकि। हालांकि यह सभी डबल इंद्रधनुष और चमकदार गेंदे नहीं हैं। गैर-जेनुइनल सीपीयू पर बायनेरिज़ न चलने के बारे में कुछ भारी आरोप लगाए गए हैं और (यह एक माना जाता है) अन्य विक्रेताओं द्वारा सीपीयू पर कृत्रिम रूप से प्रेरित अवर प्रदर्शन। यह भी ध्यान दें कि यह कम से कम 3 साल पहले की जानकारी है और इसकी वैधता अब तक अज्ञात है, लेकिन नए उत्पाद विवरणों से बायनेरिज़ को एक कार्टे ब्लैंच मिलता है जो धीमी गति से चलने के लिए होता है क्योंकि इंटेल गैर-इंटेल सीपीयू पर फिट होता है।

मुझे नहीं पता कि यह इंटेल के बारे में क्या है और वे इतने अच्छे संख्यात्मक गणना उपकरण क्यों बनाते हैं, लेकिन इस पर भी एक नज़र डालें: http://julialang.org/ । एक तुलना है और यदि आप अंतिम पंक्ति को देखते हैं, तो MATLAB सी कोड और जूलिया दोनों को हराकर चमकता है , जो मुझे मारता है कि लेखकों को लगता है कि इसका कारण इंटेल की मैथ कर्नेल लाइब्रेरी है

मुझे लगता है कि यह इंटेल कंपाइलर टूलकिट के लिए एक विज्ञापन की तरह लगता है, लेकिन मेरे अनुभव में यह वास्तव में अच्छी तरह से काम करता था, और यहां तक ​​कि सरल तर्क यह भी बताता है कि सीपीयू बनाने वालों को सबसे अच्छा पता होना चाहिए कि उनके लिए कैसे प्रोग्राम करना है। IMO, Intel C ++ कंपाइलर प्रदर्शन के हर अंतिम बिट को संभव बनाता है।


@ K.Steff क्या आपने पूरे प्रोग्राम ऑप्ट और प्रोफ़ाइल निर्देशित ऑप्टिमाइज़ेशन के साथ इस बनाम एमएस कंपाइलर की तुलना की।
रियून

2
इंटेल को यह बताने के लिए मजबूर किया गया था कि सीपीयू इंटेल द्वारा निर्मित नहीं किए जाने पर उनके संकलक जानबूझकर रनटाइम पर अनप्टीमाइज्ड कोड पाथ का उपयोग करते हैं। FTC से इंटेल मुश्किल में पड़ गया । आप मुझे ICC का उपयोग करने के लिए भुगतान नहीं कर सकते। मैं 10 फुट के ध्रुव के साथ उस विरोधी प्रतिस्पर्धात्मक टुकड़े को नहीं छू पाऊंगा।
doug65536

@ doug65536 जो प्रश्न पूछा गया है, "क्या इंटेल कंपाइलर्स वास्तव में बेहतर हैं", "क्या हार्डवेयर बाजार में इंटेल एक एकाधिकार नहीं है जो सॉफ्टवेयर में आगे बढ़ने के लिए इस एकाधिकार का दुरुपयोग करता है"। मैं यह नहीं कह रहा हूं कि आपकी टिप्पणी अपमानजनक है, लेकिन मेरे लिए विचारधारा का इस चर्चा में कोई स्थान नहीं है। उपयोग करें या न करें - आपका कॉल, लेकिन यह इस तथ्य को नहीं बदलेगा कि आईसीसी इंटेल सीपीयू के लिए बायनेरिज़ बनाने में बहुत अच्छा है।
केटफ

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

35

Intel Compiler के पास बहुत ही कुशल संख्यात्मक कोड के उत्पादन की एक प्रतिष्ठा है:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

कृपया ध्यान दें कि मैं दावा नहीं करते कि यह है वहाँ बाहर सबसे तेजी से संकलक, लेकिन यह निश्चित दक्षता के लिए एक बहुत अच्छी प्रतिष्ठा प्राप्त। ध्यान दें कि विंडोज के लिए "आधिकारिक" LAPACK बायनेरी के लेखक उन्हें बनाने के लिए इंटेल फोरट्रान कंपाइलर का उपयोग करते हैं: http://icl.cs.utk.edu/lapack-for-windows/ और उन्हें दक्षता के बारे में एक या दो बातें पता होनी चाहिए।


2
इतना ही नहीं कि यह प्रतिष्ठा है, यह करने के लिए रहता है। यदि आप CRUD एप्लिकेशन लिखने के लिए इसका उपयोग कर रहे हैं, तो यह आवश्यक नहीं है, लेकिन जब क्रंचिंग नंबर आता है तो C, C ++ और FORTRAN उत्पाद बिल्कुल कच्चे हो जाते हैं।
Blrfl 17

27

Intel C ++ में कोड जनरेटर के अलावा gcc पर कुछ फायदे हैं। ये दोनों स्टेम (बड़े पैमाने पर) इस तथ्य से हैं कि यह ईडीजी फ्रंट-एंड पर आधारित है । बेहतर या बदतर के लिए, ये दोनों (धीरे-धीरे) मिट रहे हैं, इसलिए फायदे लगभग उतने महान नहीं हैं जितने कि वे एक बार थे।

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

दूसरा, यह है कि EDG फ्रंट एंड के बारे में अच्छी तरह से असाधारण भाषा के अनुरूप के लिए जाना जाता है क्योंकि इंटेल कोड जनरेटर फास्ट कोड के उत्पादन के लिए है। लगभग किसी भी उचित उपाय से, EDG फ्रंट-एंड किसी भी अन्य संकलक की तुलना में C ++ 98, 03, या (वर्तमान संस्करणों में) C ++ 0x के साथ बेहतर अनुरूपता प्रदान करता है।

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


14

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

डीएलएल को कॉम्बिनेटरिक्स और टोपोलॉजी घटकों के साथ कुछ बहुत मुश्किल समस्याओं की गणना करनी है, जो तकनीकी रूप से एनपी-हार्ड कठिनाई वर्ग में हैं यदि हमने उन्हें "सही" किया, लेकिन हम एनपी प्रदर्शन से बचने के लिए विभिन्न उत्तराधिकारियों का उपयोग करते हैं। फिर भी, संख्या में कमी का एक बहुत कुछ चल रहा है। और हमारे द्वारा चलाए गए परीक्षणों के लिए, वीएस कंपाइलर और इंटेल कंपाइलर के बीच का अंतर या तो एप्सिलॉन के भीतर था, या इंटेल कंपाइलर काफ़ी धीमा था, आम तौर पर 20% के पड़ोस में। और यह इस तरह से बना रहा कि कोई फर्क नहीं पड़ता कि इंटेल कंपाइलर को तेजी से कोड का उत्पादन करने की कोशिश करने के लिए उसने संकलन सेटिंग्स में क्या बदलाव किए। इसलिए हमने इसे बंद नहीं किया।

यह केवल एक वास्तविक दुनिया का उदाहरण है। आपकी माइलेज भिन्न हो सकती है।


क्या आप मान लेंगे कि सीपीयू का विवरण बेंचमार्क पर चलता है?
ओक

22
जब मैंने आपका पहला पैराग्राफ पढ़ा, तो मुझे लगा कि आप कह रहे हैं कि गति परीक्षण के परिणामों ने उसे अच्छे तरीके से आश्चर्यचकित कर दिया । जाहिरा तौर पर यह गलत है, दूसरे पैराग्राफ को पढ़ने के बाद। यकीन नहीं होता कि पहले पढ़ने पर मुझे क्या गुमराह किया गया; करीब से निरीक्षण करने पर, आप वास्तव में किसी भी सकारात्मक शब्द का उपयोग नहीं करते हैं जो मुझे उस धारणा के साथ छोड़ सकता है। बस मैंने सोचा था कि अगर कोई और भी यही गलती करता है और मैं वास्तव में यहाँ कह रहा हूँ तो उलझन में है।
कोड़ी ग्रे

2
क्या आप परीक्षण के लिए AMD प्रोसेसर का उपयोग कर रहे थे? मुझे लगता है कि यह प्रासंगिक जानकारी है (चाहे संकलक ने उद्देश्य पर बुरा प्रदर्शन किया हो या अगर यह तब भी कुछ नहीं कर सकता था जब यह अपना सर्वश्रेष्ठ प्रदर्शन कर रहा था)।
मोनिका

3
यह एक Intel Core i7 प्रोसेसर है।
मेसन व्हीलर

लघु संस्करण: VS2010 की तुलना में इंटेल धीमा था। मैं के रूप में अच्छी तरह से काम करने की कोशिश नहीं की यह काफी समय पहले काफी सी + + crunching डेटा की एक कोडबेस पर। मैंने बहुत सारी अलग-अलग सेटिंग्स की कोशिश की। पहले से मौजूद प्रदर्शन परीक्षणों के साथ कुछ व्यक्तिगत एल्गोरिदम काफ़ी तेज़ी से हुए, लेकिन सबसे ज़्यादा धीमी गति से। कुल मिलाकर किसी भी उच्च स्तरीय ऑपरेशन जो मैंने सॉफ्टवेयर के साथ किया था वह लगातार और औसत रूप से धीमा था। मैंने इंटेल के संकलक के 2013 और 2010 संस्करणों के साथ भी यह कोशिश की, 2010 उत्पादों को बेहतर कोड के साथ-साथ अधिक स्थिर होने के लिए लगता है। मेरे अधिकांश परीक्षण प्री-एवीएक्स आई 7 पर थे, लेकिन कुछ पुराने कोर 2 पर थे।
रिच

9

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

आपको क्या लगता है कि बॉस ने कहा कि जब हमने कंपाइलर खरीदने के लिए फंड मांगा तो ……।

हालाँकि - यह बहुत भाग्यशाली और दुर्लभ बढ़त मामला था - इंटेल कंपाइलर से 10% तेज कोड आउटपुट ने हमें प्रदर्शन के सही पक्ष पर वापस धकेल दिया। यदि हम पहले से ही दाईं ओर थे, या 10% से अधिक थे, तो इससे कोई फर्क नहीं पड़ता था। अगर हमारे पास इंजीनियर होते तो शायद हम कोड को अनुकूलित कर सकते थे और हार्डवेयर स्पिन को बचा सकते थे और इंटेल कंपाइलर की जरूरत नहीं थी, लेकिन जोखिम अधिक था और इंटेल कंपाइलर इंजीनियरिंग समय की तुलना में सस्ता काम करता था।

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


5

मुझे केवल तीन फायदे मिले हैं:

  1. यह अन्य संकलक की तुलना में बहुत जल्द नए इंटेल सीपीयू की सुविधाओं के लिए समर्थन करता है।

  2. यह एक महान अतिरिक्त संकलक है जो चेतावनी जारी करता है और उन समस्याओं को पकड़ता है जो अन्य संकलक याद करते हैं। जीसीसी आईसीसी नहीं, और इसके विपरीत कुछ चीजें पकड़ता है। विजुअल स्टूडियो आईसीसी नहीं करता है, और इसके विपरीत कुछ चीजें पकड़ता है।

  3. यह किसी भी अन्य संकलक की तुलना में ऑटो-समानांतर लूप (कई थ्रेड पर स्वचालित रूप से वितरित करना) का बेहतर काम करता है। इससे बहुत अधिक कोड लाभ नहीं होता है, लेकिन जब आपके पास ऐसा कोड होता है, तो यह अंतर का एक हिस्सा बना सकता है।


3

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

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

वही बांह संकलक (बांह से, बुद्धि नहीं) के लिए भी जाता है, यदि आपकी बांह पर रिलीज करना, आपके लिए वेक्टर बनाने में बहुत अच्छा काम करता है।


+1। इंटेल में एआरएम कंपाइलर है? Unbeleivable!

1
नहीं, इंटेल का कोई एआरएम कंपाइलर नहीं है। एआरएम में एक एआरएम कंपाइलर है, जो एक शानदार काम करता है।
शहीद

2
"EDIT: आर्म में आर्म कंपाइलर नहीं होता है।" क्या यह वास्तव में तुम्हारा मतलब है?
लुइसुबल 21

0

इस बेंचमार्क पृष्ठ की जाँच करें। संक्षेप में, बुद्धि जीतती है।

लेकिन मार्जिन इतना बड़ा नहीं हो सकता है: यदि आप 32 बिट के लिए संकलन करते हैं, और आपकी बिल्ड सिस्टम कैंट सपोर्ट प्रोफाइल निर्देशित ऑप्टिमाइज़ेशन, लाभ 10% के ऑर्डर का है। क्या इस तरह का सुधार परेशानी और लंबे समय के संकलन के लायक है?


URL लिंक मृत प्रतीत होता है।
कंटैंगो

0

यह कहा गया है कि इंटेल ने एंड्रॉइड ओएस के लिए इंटेल सी ++ कंपाइलर v13.0 जारी किया है, विशेष रूप से Google के मोबाइल प्लेटफॉर्म के लिए डिज़ाइन किए गए एक अनुकूलन सी / सी ++ कंपाइलर देने का पहला प्रयास है।

डेवलपर Intel * Atom ™ प्रोसेसर सहित इंटेल प्रोसेसर पर आधारित एंड्रॉइड डिवाइसों के लिए ऐप बनाने के लिए लिनक्स * आधारित सिस्टम पर कंपाइलर का उपयोग कर सकते हैं। इंटेल कंपाइलर GNU C ++ और एंड्रॉइड नेटिव डेवलपमेंट किट (NDK) में डेवलपर टूल के साथ संगत है। आप कंपाइलर का उपयोग सिर्फ किसी भी विकास मशीन पर नहीं कर सकते हैं। न तो विंडोज और न ही ओएस एक्स का समर्थन किया जाता है; उपकरण केवल Ubuntu 10.04 या 11.04 के साथ उपयोग के लिए प्रमाणित हैं

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.