क्या एंड्रॉइड ऐप की व्याख्या के बाद से आईओएस ऐप एंड्रॉइड ऐप से तेज हैं?

Question

संकलित के बजाय Android एप्लिकेशन की व्याख्या की जाती है। क्या यह उन्हें रनटाइम पर iOS ऐप से धीमा बनाता है?

Comments

यह एक अच्छा सवाल नहीं है क्योंकि एंड्रॉइड ऐप्स की व्याख्या नहीं की जाती है, जैसे कि सही उत्तर वास्तव में इंगित करता है।

— Aaronaught

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

— सेलाली अडोबोर

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

— केशलम

JIT कंपाइलर JVM की अवधारणा से बिल्कुल भी बंधे नहीं हैं। ऐसे JVM हैं जो JIT कंपाइलर, यहां तक ​​कि वाणिज्यिक का उपयोग नहीं करते हैं। आईबीएम के जेवीएम के कुछ रूपांतर एआईटी संकलन के लिए डिफ़ॉल्ट रूप से जेआईटी को डिफ़ॉल्ट रूप से सक्षम नहीं करते हैं। इसके अलावा, छोटे नोट, "इन दिनों जावा में प्रमुख अनुप्रयोग" शायद डेढ़ दशक पहले थोड़ा अधिक उपयुक्त थे (आईबीएम 1997 से पहले जावा को जोड़ रहा था)

— सेलाली एडोबोर

सवाल कुछ भ्रामक है। एक "देशी" आईओएस ऐप ऑब्जेक्टिव-सी (या स्विफ्ट) में लिखा और संकलित किया गया है, जबकि एक "मानक" एंड्रॉइड ऐप जावा में लिखा गया है और बाइटकोड के लिए संकलित है। देखिए @ DanHulme का जवाब। लेकिन उदाहरण के लिए PhoneGap / कॉर्डोवा का उपयोग करके HTML और JavaScript में किसी भी प्लेटफ़ॉर्म के लिए एप्लिकेशन लिखना संभव है। एक HTML ऐप को आमतौर पर एक ही प्लेटफॉर्म पर एक देशी ऐप की तुलना में अधिक धीरे-धीरे चलाने के लिए माना जाता है। इसलिए यदि "अन्य" प्लेटफॉर्म के लिए एक समान ऐप शायद धीमा है, क्योंकि यह विभिन्न प्रौद्योगिकी का उपयोग करके बनाया गया है।

— डेविड

Answer 1

जावा की व्याख्या Android पर नहीं की गई है। एंड्रॉइड ऐप डेवलपर द्वारा बायटेकोड पर संकलित किए जाते हैं । बायटेकोड कार्यक्रम का एक कॉम्पैक्ट प्रतिनिधित्व है: प्रोग्रामर द्वारा लिखे गए स्रोत कोड से छोटा है, लेकिन सीपीयू द्वारा अभी भी सीधे निष्पादन योग्य नहीं है। कुछ अनुकूलन, जैसे कि मृत कोड को हटाना, इस स्तर पर बनाया जा सकता है।

जब आप ऐप को किसी डिवाइस पर लोड करते हैं, तो Dalvik JVM मूल निष्पादन योग्य कोड के लिए बायटेकोड को संकलित करता है, जैसे कि यह चलने वाला है। यह सिर्फ-इन-टाइम संकलन है। कार्यक्रम के संकलित होने का इंतजार करने के दौरान यह थोड़ा धीमा हो जाता है, लेकिन उसके बाद कोई प्रदर्शन ओवरहेड नहीं होता है, क्योंकि कोड को मूल निष्पादन योग्य कोड के लिए संकलित किया गया है।

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

Dalvik JIT संकलन की कमियों को कम करने के लिए Dalvik कैश और अन्य तकनीकों का उपयोग करता है । Android L के लिए नया JVM और बाद में, ART, JIT को पूरी तरह से एक आगे के कंपाइलर के साथ बदल देता है । जब एप्लिकेशन इंस्टॉल हो जाता है, तो यह एप्लिकेशन को इंस्टॉल किए बिना देरी के JIT के अधिकांश लाभ प्राप्त करने के लिए, मूल निष्पादन योग्य कोड को बायटेकोड को संकलित करता है।

यह मत भूलो कि Android ऐप्स पूरी तरह जावा से युक्त नहीं हैं। डेवलपर्स के पास NDK के सभी या अपने ऐप्स का कुछ भाग C या C ++ में लिखने के लिए है, विशेष रूप से गेम के लिए ऐप के प्रदर्शन-महत्वपूर्ण भागों के लिए। OpenGL और Renderscript जैसे विशेष प्रयोजन के इंटरफेस प्रोग्रामर कुछ प्रकार की गणना के लिए GPU और SIMD कोप्रोसेसर जैसे विशेष हार्डवेयर का लाभ उठाते हैं।

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

Comments

महान विवरण के लिए +1। मैं वास्तव में इस तरह के उत्तर की प्रतीक्षा कर रहा था।

— मणि

पीसी पर थक पुराने ".NET / Java बनाम C ++ प्रदर्शन" से बहुत अलग नहीं है, वास्तव में। यह सेब और संतरे है।

— Aaronaught

@ArmonSafai काफी।

— दान हुल्मे

@MTilsted: ऐसा इसलिए है की तरह सच है, लेकिन यह लगभग सब कुछ है, तो आप क्या बात कर रहे हैं के बारे में होने की संभावना बहुत ही पहली बार किसी एप्लिकेशन को चलाने के क्या होगा संचित करता है।

— आर्यन

यहाँ दलविक मुख्य समस्या "सामान्य" जेवीएम के रूप में है। रजिस्टर-आधारित होने के बीच, हॉटस्पॉट की तरह स्टैक के विरोध के कारण (एआरएम प्रोसेसर की प्रकृति के कारण बनाम उन हॉटस्पॉट को [जैसे IA32] लक्षित कर रहे थे), यह Zygote का उपयोग है, और odex फ़ाइलों की अवधारणा (अर्थात संपूर्ण विचार) नहीं [कमोबेश] क्लास फाइल से क्लास लोडर तक सीधे जाना), दलविक को एक सामान्य जेवीएम के रूप में मानने से कुछ गलतफहमी पैदा होती है। खासकर जब से हॉटस्पॉट के कार्यान्वयन के कई विवरण गलती से सामान्य रूप से जेवीएम से जुड़े हैं (जैसे कि यह जेआईटी कंपाइलर है)।

— सेलाली अडोबोर

Answer 2

चूंकि यह एक व्यापक प्रश्न है, यहाँ एक व्यापक उत्तर है।

"क्या एंड्रॉइड ऐप की व्याख्या करने के बाद भी आईओएस ऐप एंड्रॉइड ऐप से तेज हैं?"

सबसे पहले iOS ऐप एंड्रॉइड ऐप से "तेज" नहीं हैं।

दूसरे, इस मुद्दे के बारे में "एंड्रॉइड ऐप की व्याख्या की जाती है।" यह कुछ ऐसा है जो आप कंप्यूटिंग के बारे में कहेंगे, जैसे "15 साल पहले": जैसा कि आप ऊपर चर्चा से देख सकते हैं, आज स्थिति बहुत अधिक जटिल है; पूरी तरह से नई तकनीकें सामने आई हैं। अवधारणा "संकलित की तुलना में तेज है!" प्रासंगिक तुलना थी, आप जानते हैं, 20 साल पहले मशीन कोड के लिए पर्ल; चीजें इतनी बढ़ गई हैं कि आज "आईओएस वी एंड्रॉइड" पर वास्तव में मुद्दा स्पष्ट रूप से लागू नहीं किया जा सकता है।

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

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

आपके प्रश्न का बहुत ही संक्षिप्त उत्तर है "संकलित वी। व्याख्या" मूल रूप से एक आउट-ऑफ-डेट चर्चा बिंदु है जिसे आप जानते हैं?

(इसके अलावा, मैं विशेष रूप से एक iPhone की तुलना में एक नोट 3 "धीमी" नहीं ढूंढता हूं। इसके अलावा, इसमें से कुछ शुद्ध आर्टिफैक्ट है - सस्ते एंड्रॉइड फोन मौजूद हैं: बस कम प्रदर्शन वाले आईफ़ोन नहीं बने हैं, इसलिए कुछ लोग गलत हो सकते हैं इस से विचार।)

Answer 3

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

हालांकि, जावा (एंड्रॉइड की प्रोग्रामिंग भाषा) की व्याख्या नहीं की गई है लेकिन जेआईटी संकलित है। इसका मतलब है कि एंड्रॉइड प्रोग्राम आपको चलाने से ठीक पहले संकलित करते हैं, जो कि iOS 'ऑब्जेक्टिव सी के समान प्रदर्शन देता है।

हाल ही में, एंड्रॉइड के एआरटी फ्रेमवर्क ऐप को प्री-कंपाइल करते हैं, इसलिए उन्हें उसी तरह से चलाया जाता है जैसे आईओएस ऐप। दूसरे शब्दों में, एंड्रॉइड का अगला संस्करण संभवतः iOS के समान तेज़ होगा।

अद्यतन करें

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

Comments

आपका क्या मतलब है "एक बार बेतरतीब ढंग से निष्पादन के अनुक्रम को बदल सकते हैं? और वे कैसे अधिक शक्तिशाली और गतिशील हैं? यह भी नहीं कह रहे हैं कि वे धीमी गति से हैं, बस इतना है कि वे धीमी गति से, यहां तक ​​कि थोड़ा

— Armon Safai

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

— डैन हुल्मे

Microsoft .NET को IL कोड के लिए संकलित किया जाता है, जिसकी व्याख्या भी उसी तरह की जाती है जैसे कि java को bytecode के लिए संकलित किया जाता है।

— एसेन स्कोव पेडरसन

इस उत्तर में बहुत सी जानकारी वास्तव में प्रासंगिक या तकनीकी रूप से सही नहीं है। मैं ईमानदारी से इस उत्तर को पूरी तरह से तकनीकी सटीकता के लिए संशोधित करने का सुझाव देता हूं।

— अजा

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

— एल्डररैथिस