मैं "डेवलपर के खराब अनुकूलन अंतर्ज्ञान" से कैसे बचूँ?


22

मैंने एक लेख पर देखा जिसने इस कथन को आगे बढ़ाया:

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

एक डेवलपर इस बुरे अंतर्ज्ञान से कैसे बच सकता है? क्या यह पता लगाने के लिए अच्छे उपकरण हैं कि आपके कोड के किन हिस्सों को वास्तव में अनुकूलन की आवश्यकता है (जावा के लिए)? क्या आप इस विषय पर कुछ लेखों, युक्तियों या अच्छे लेखों के बारे में जानते हैं?


1
यह नीचे आता है "मैं निर्णय लेने के दौरान अंतर्ज्ञान [[निर्णय लेने पर] कैसे बचता हूं?" सरल: आप हार्ड-फैक्ट्स और डेटा के साथ सत्यापन करते हैं। इसलिए, अनुकूलन के मामले में, एक डेवलपर के दृष्टिकोण से: आप बेंचमार्क।
१३:११

जवाबों:


44
  • महंगे तरीकों को पहचानने के लिए एक अच्छे प्रोफाइलर का इस्तेमाल करें।
  • यह दस्तावेज कि हॉट स्पॉट वास्तव में कितना समय लगा।
  • हॉट स्पॉट के तेजी से कार्यान्वयन को लिखें
  • दस्तावेज़ को अब कितने समय लगेंगे, उम्मीद है कि अब उन्हें हॉटस्पॉट नहीं बनाया जाएगा।

अनिवार्य रूप से आपको दूसरों को यह साबित करने में सक्षम होना चाहिए कि समस्या कहां थी, और इस बदलाव ने इसे दूर कर दिया।

मूल संस्करण के तत्काल रोलबैक के लिए - मेरी व्यक्तिगत राय में - एक सुधार साबित करने में सक्षम नहीं होने के नाते ।


51
या इसे और भी सरल रूप से कहें: "खराब अनुकूलन अंतर्ज्ञान से बचने के लिए, अंतर्ज्ञान का उपयोग न करें। उपाय।"

6
इसलिए तुम्हारा जवाब एक है और मेरा सिर्फ एक टिप्पणी है। : पी
१ .

2
@ थोमस, अगर आप पठनीयता और निरंतरता के साथ फील करते हैं, तो आप बिल्कुल प्रदर्शन की समस्याओं को नहीं देख रहे हैं, क्या आप हैं?

3
@ थोमस, मैं असहमत हूं। यहां तक ​​कि कल्पना के भीतर, आपको नए कोड को अच्छी तरह से फिर से लिखना होगा। पुराने कोड के लिए यह आवश्यक नहीं है। वापस लाएं।

2
@ Thorbjørn प्रदर्शन ट्यूनिंग के बाद, आपको नए कोड को अच्छी तरह से फिर से लिखना होगा। यदि आपने कोई दोष प्रस्तुत किया है तो समय या स्मृति बचाना व्यर्थ है।
थॉमस ओवेन्स

10

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

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


VisualVM JRE में नहीं है, केवल JDK में है।

1
@ Thorbjørn रावन एंडरसन ने अच्छी कॉल की। मुझे स्पष्ट करना चाहिए। हालाँकि, यदि आप जावा विकास कर रहे हैं, तो आपके पास आमतौर पर JDK स्थापित होता है (हालाँकि आप OpenJDK या इसी तरह का हो सकता है - मुझे नहीं पता कि वे विजुअलवीएम के साथ आते हैं)।
थॉमस ओवेन्स

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

9

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

एक डेवलपर इस बुरे अंतर्ज्ञान से कैसे बच सकता है?

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

आप खुद को ऐसा करते हुए पाएंगे और पता चलेगा कि आपको ऐसा नहीं करना चाहिए था।
और फिर फिर से।
और फिर।

अर्ली ऑप्टिमाइज़ेशन प्रोग्रामर्स के कैपिटल पापों में से एक है

उपकरण और सामान बाद के अनुकूलन का एक हिस्सा है जो एक स्थापित शिल्प है


प्रारंभिक "दृढ़ कोड" अनुकूलन, सुनिश्चित करने के लिए। चॉज़िंग एल्गोरिदम और / या डेटा संरचनाएं जो आपकी समस्या को फिट करती हैं और (आपके अपेक्षित प्रसंस्करण भार के साथ) अच्छा प्रदर्शन विशेषताओं है कुछ ऐसा है जो आपको कोड लिखना शुरू करने से पहले किया जाना चाहिए।
वेटिन

@Vatine हाँ, वहाँ गया है। नहीं, बस नहीं। हाथ में समस्या के अपने मन-नक्शा फिट बैठता है जो करो। यह सबसे अच्छा प्रदर्शन करने वाला एल्गोरिथ्म हो सकता है , और मैं चाहता हूँ कि, यह नहीं है।
जेडजेआर

यह मुझे YAGNI सिद्धांत के रूप में लगता है - आपको इसकी आवश्यकता नहीं है!
एल युसुबोव

7

इन उपकरणों को प्रोफाइलर कहा जाता है । आप उन्हें वास्तव में मापने के लिए उपयोग कर सकते हैं कि आपके कार्यक्रम का कौन सा हिस्सा निष्पादित करने के लिए सबसे अधिक समय लेता है, इसलिए आपके ट्यूनिंग प्रयासों पर ध्यान केंद्रित करने के लिए कहां।

परिवर्तनों के बाद फिर से मापना भी उतना ही महत्वपूर्ण है , यह सत्यापित करने के लिए कि आपके परिवर्तनों का इच्छित प्रभाव है।


5

यह भी देखें कि आपका प्रोग्राम कितनी मेमोरी का उपयोग करता है, न कि इसकी गति या रनटाइम का।

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

मैंने जावा वेब एप्लिकेशन देखे हैं जो इतने लीक थे कि वे अपने सर्वर को स्वैप स्थान से बाहर चला देंगे!

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


1

मेरा उपाय दो प्रश्नों के स्पष्ट उत्तर प्राप्त करके शुरू करना है:

  1. प्रदर्शन को कैसे मापें (उदाहरण के लिए डेटा लोड समय को मापें )
  2. लक्ष्य मान क्या है (उदा। 3 सेकंड में डेटा लोड या 95% आत्मविश्वास के साथ कम )

बाघ टीम के लोगों से चाल के बारे में जानें जिन्हें एक बार हमारे उत्पाद की टूटी हुई रिलीज को बचाने के लिए आमंत्रित किया गया था। यह रिलीज प्रदर्शन के कारणों से टूट गई थी, इससे कंपनी ढीले रणनीतिक ग्राहक बन सकते थे जो बाघों की भागीदारी (बहुत महंगा बीडब्ल्यूटी) को न्यायोचित ठहराते थे । मुझे परियोजना विवरण को स्पष्ट करने के लिए उन्हें सौंपा गया था; प्रदर्शन के बारे में थोड़ा या दो सीखने के अवसर के रूप में भी इसका उपयोग किया।


1

मैंने पाया है कि समय से पहले अनुकूलन के लिए सबसे अच्छा एंटीडोट यह विधि है

एक बार जब आप इसका उपयोग कुछ कोड को गति देने के लिए करते हैं (जैसा कि इस उदाहरण में ), तो यह अपने आप में एक लत बन जाता है, और आप समझते हैं कि प्रदर्शन ट्यूनिंग का पहला सिद्धांत कोड कोडिंग नहीं है, यह समस्या ढूंढ रहा है

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


1
और दुर्भाग्य से, आप केवल 200 पाउंड वापस अपने परिवार में ले जा सकते हैं, ताकि पूरे दिन गिलहरी को गोली न मारें।
जॉर्डन

1

पुराना सवाल है, लेकिन मैं इस जवाब की पेशकश करूंगा जो दूसरों से काफी अलग है।

प्रदर्शन लाभ के बड़े अवसर समानांतर प्रसंस्करण से आते हैं। कई धागों का लाभ उठाने के लिए अपने कोड को डिज़ाइन करने का प्रयास करें। (भले ही, सादगी के लिए, आप संस्करण 1 में ऐसा नहीं करते हैं)। थोड़ा अनुमान या अंतर्ज्ञान आवश्यक है।

कुछ भी समय से पहले अनुकूलन है, और आपके अंतर्ज्ञान की आवश्यकता होती है, जो अक्सर गलत होता है।


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

0

समय के साथ आपका अंतर्ज्ञान सुधर सकता है । मुझे लगता है कि, शायद थोड़ा विवादास्पद है, लेकिन VTune और CodeAnalyst और अब CodeXL का उपयोग करने के कई वर्षों में, मैं कहूंगा कि मैं अपने अंतर्ज्ञान में पहले से कहीं अधिक सटीक हूं जहां हॉटस्पॉट होंगे, कम से कम बिंदु जहां मैं अब पूरी तरह से ऑफ-गार्ड पकड़ा नहीं हूं जब मैं कुछ कोड को प्रोफाइल करता हूं। इसका मतलब यह नहीं है कि मैं आँख बंद करके चीजों को अनुकूलित करने का प्रयास करता हूं।

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

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

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

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

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


0

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

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

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

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

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

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