🏿 👎🏼 👨🏻‍⚖️ एंड्रॉइड डिवाइसों पर ज़ामरीन (मोनोड्रॉइड) और जावा (डेल्विकवीएम) के प्रदर्शन की तुलना 👨🏼‍🎓 🕘 🦗

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

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

सत्यापन पद्धति

प्रदर्शन परीक्षण के लिए जावा-कार्यान्वित और आमतौर पर मान्यता प्राप्त विधि की आवश्यकता होती है जिसे C # में लागू करने की आवश्यकता होगी। मैंने सर्वप्रथम जाने-माने LINPACK प्रदर्शन परीक्षण का उपयोग करने का निर्णय लिया, क्योंकि इसका स्रोत कोड खुला है और C # संस्करण को लागू करना आसान होगा, और दूसरी बात, जावा में लिखित Android के लिए LINPACK का एक तैयार-निर्मित Android संस्करण है।

LINPACK प्रदर्शन परीक्षण एक फ्लोटिंग पॉइंट कंप्यूटिंग सिस्टम की गति का मूल्यांकन करके प्रदर्शन का मूल्यांकन करने की एक विधि है। बेंचमार्क जैक डोंगरा द्वारा बनाया गया था और यह मापता है कि एलयू अपघटन विधि का उपयोग करके आयाम एन एक्स एन के घने एसएलएयू एक्स = बी के समाधान के लिए कंप्यूटर कितनी जल्दी खोजता है। मुख्य तत्व ( विवरण ) के चयन के साथ गॉस विधि द्वारा समाधान प्राप्त किया गया था, जिसमें 2/3 * एन ³ + 2 * एन ² फ्लोटिंग-पॉइंट ऑपरेशन किए जाते हैं। परिणाम फ्लोटिंग-पॉइंट ऑपरेशंस प्रति सेकंड (MFLOP / s, अक्सर बस FLOPS) में परिभाषित किया गया है। लिनेप फोरट्रान लीनियर कम्प्यूटिंग लाइब्रेरी के लिए प्रलेखन में स्वयं प्रदर्शन परीक्षण का वर्णन किया गया था और तब से, इसके रूपों का उपयोग किया गया है, उदाहरण के लिए, TOP500 सुपर कंप्यूटरों को रैंक करने के लिए।

कार्यान्वयन

काफी सरल कार्य के बावजूद, मैंने इसे क्रॉस-प्लेटफ़ॉर्म विकास के लिए मेरी दिशानिर्देश के अनुसार लागू करने का निर्णय लिया।

पहले चरण में, हम एक क्रॉस-प्लेटफॉर्म समाधान का निर्माण करते हैं:

फिर, MVP डिज़ाइन पैटर्न के अनुसार, प्रस्तुतकर्ता और दृश्य बनाएं

हम परीक्षण लिखते हैं और परीक्षण के माध्यम से प्रस्तुतकर्ता को लागू करते हैं। इसके लिए, मैं NUnit और NSubstitute का उपयोग करता हूं। NUnit का वर्णन करने में कोई विशेष अर्थ नहीं है, मेरी राय में बस अधिक सुविधाजनक परीक्षण ढांचा नहीं है। NSubstitute इंटरफेस के आधार पर स्टब्स बनाने के लिए एक अत्यंत सुविधाजनक फ्रेमवर्क है। फ्रेमवर्क NuGet के माध्यम से स्थापित किए गए हैं।

गोदी से NSubstitute का उपयोग करने का एक छोटा सा उदाहरण

// Let's say we have a basic calculator interface: public interface ICalculator { int Add(int a, int b); string Mode { get; set; } event Action PoweringUp; } // We can ask NSubstitute to create a substitute instance for this type. We could ask for a stub, mock, fake, spy, test double etc., but why bother when we just want to substitute an instance we have some control over? _calculator = Substitute.For<ICalculator>(); // Now we can tell our substitute to return a value for a call: _calculator.Add(1, 2).Returns(3); Assert.That(_calculator.Add(1, 2), Is.EqualTo(3)); // We can check that our substitute received a call, and did not receive others: _calculator.Add(1, 2); _calculator.Received().Add(1, 2); _calculator.DidNotReceive().Add(5, 7); // If our Received() assertion fails, NSubstitute tries to give us some help as to what the problem might be: NSubstitute.Exceptions.ReceivedCallsException : Expected to receive a call matching: Add(1, 2) Actually received no matching calls. Received 2 non-matching calls (non-matching arguments indicated with '*' characters): Add(1, *5*) Add(*4*, *7*) // We can also work with properties using the Returns syntax we use for methods, or just stick with plain old property setters (for read/write properties): _calculator.Mode.Returns("DEC"); Assert.That(_calculator.Mode, Is.EqualTo("DEC")); _calculator.Mode = "HEX"; Assert.That(_calculator.Mode, Is.EqualTo("HEX"));

हमारे मामले में, पहले सेटअप विधि बनाएँ

 [TestFixtureSetUp] public void Setup() { view = Substitute.For<ILinpackView>(); presenter = new LinpackPresenter(view); }

और हम एक साधारण परीक्षण करते हैं, स्वाभाविक रूप से अतुल्यकालिक रूप से

  [Test] public void CalculateAsyncTest() { presenter.CalculateAsync().Wait(); Assert.That(view.Mflops, Is.EqualTo(130.0).Within(5).Percent); }

तृतीय-पक्ष सॉफ़्टवेयर के साथ, मुझे पता चला कि मेरे पीसी का प्रदर्शन लगभग 130 MFLOPS / s है, इसलिए हम इसे एक त्रुटि जोड़कर अपेक्षित मानों में लिखेंगे।

विधि के अंदर, मैं एक अतुल्यकालिक टास्क बनाता हूं और व्यू को पॉप्युलेट करता हूं। सब कुछ सरल और स्पष्ट है।

 public Task CalculateAsync() { Linpack l = new Linpack(); return Task.Factory.StartNew(() => l.RunBenchmark()) .ContinueWith(t => { _view.Mflops = l.MFlops; _view.NormRes = l.ResIDN; _view.Precision = l.Eps; _view.Time = l.Time.ToString(); } ); }

कार्यक्रम वास्तव में लागू किया गया है, अब तक प्लेटफ़ॉर्म-विशिष्ट कोड की कोई पंक्ति नहीं लिखी गई है। अब एक Android प्रोजेक्ट बनाएं:

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

अब यह केवल रिलीज को संकलित करने के लिए बनी हुई है, इसे स्टूडियो में लागू किए गए विज़ार्ड के साथ साइन करें और कंसोल यूटिलिटी adb.exe का उपयोग करके उपकरणों पर स्थापित करें

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

हो गया!

परिणाम

मेरे पास दो परीक्षण उपकरण हैं, Android 2.3 (Qualcomm QSD8250, 1000 MHz, 512 RAM) के साथ HTC इच्छा और Android 4.0.4 के साथ फ्लाई IQ443 (MediaTek MT6577, 1000 MHz, 512 RAM)

यहाँ उनके परिणाम हैं:
एचटीसी डिजायर:

IQ443 फ्लाई करें:

और सुंदर ग्राफिक्स

निष्कर्ष

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

संयोग से, यह प्रोजेक्ट रिलीज़ बिल्ड के लिए आकार अंतर दिखाता है। परीक्षण के जावा संस्करण का वजन केवल 280KB है, जबकि मोनोडायर संस्करण का वजन लगभग 2.3 एमबी प्रति प्रोसेसर प्रकार (आर्मेबी और आर्मेबी-वी 7) है, अर्थात। कुल मिलाकर 4.6 एमबी , जो, हालांकि, आधुनिक नेटवर्क की स्थितियों में मुझे विशेष रूप से महत्वपूर्ण नहीं लगता है। यदि यह एपीके का आकार आपको अस्वीकार्य लगता है, तो आप अलग से आर्मेबी और आर्मेबी-वी 7 के लिए पैकेजों को संकलित और वितरित कर सकते हैं, क्योंकि Google Play आपको विभिन्न प्लेटफार्मों के लिए अलग-अलग एपीके डाउनलोड करने की अनुमति देता है।

आवेदन का स्रोत कोड यहाँ है।

PS मैं उपकरणों पर आंकड़े एकत्र करना चाहूंगा। इसलिए यदि किसी के पास Android है और 10 मिनट का खाली समय है, तो आप बहुत आभारी होंगे यदि आप Android के लिए LINPACK और नए बनाए गए MonoLINPACK का उपयोग करके अपने डिवाइस के प्रदर्शन को मापते हैं और यहां परिणाम लिखते हैं (यदि आपके पास मल्टी-कोर प्रोसेसर है, तो तुरंत Android के लिए LINPACK में एकाधिक थ्रेड चुनें)

पीपीएस आईओएस के लिए एक समान परीक्षा होगी

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

एंड्रॉइड डिवाइसों पर ज़ामरीन (मोनोड्रॉइड) और जावा (डेल्विकवीएम) के प्रदर्शन की तुलना

सत्यापन पद्धति

कार्यान्वयन

परिणाम

निष्कर्ष

More articles: