प्रोग्रामिंग के किन क्षेत्रों में एल्गोरिथ्म रन टाइम वास्तव में एक महत्वपूर्ण मुद्दा है?

Question

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

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

Comments

LMAX व्यवधान में आपकी रुचि हो सकती है: infoq.com/pretations/LMAX

"एल्गोरिथम ट्रेडिंग" एक बुरा उदाहरण है। एल्गोरिदम अक्सर तुच्छ होते हैं; समग्र कम विलंबता प्रदर्शन चालाक एल्गोरिथ्म डिजाइन की तुलना में समर्पित संसाधनों का एक मामला है।

— S.Lott

डेटा के आकार में वृद्धि के साथ जटिलता हमेशा हार्डवेयर संसाधनों से अधिक महत्वपूर्ण होती है। एक O(n*log(n))एल्गोरिथ्म 30 साल पुराने कंप्यूटर पर O(n!)या O(n*n)आज के सबसे महंगे हार्डवेयर की तुलना में तेजी से खत्म हो जाएगा यदि nपर्याप्त बड़ा हो।

— १

आप इसे इस तरह से सोच सकते हैं कि हार्डवेयर की अक्षमता पर O(c * f(n))जहां निरंतरता cआधारित है। आपके पास 1000 गुना तेज प्रणाली हो सकती है, जैसा nकि अनंत तक जाता है, यह कम और कम मायने रखेगा। मैं किसी भी दिन के O(10000 * log(n))बजाय O(n)अगर मुझे संदेह है कि nबड़ा हो सकता है तो मैं चुनूंगा ।

— १

आप क्यों प्रदर्शन के मामले

— थोरोट

Answer 1

गति हमेशा मांग में है। मुझे लगता है कि आप सही हैं। यहां कुछ उदाहरण दिए गए थे कि स्वच्छ एल्गोरिदम मांग में हैं:

1. क्रिप्टोग्राफी

2. बड़े डेटाबेस खोज रहे हैं

3. छँटाई और विलय

4. वाइल्डकार्ड सहित पाठ खोज (गैर-अनुक्रमित)

5. गहन गणनाओं के साथ गणित की समस्याएं

6. सिमुलेशन

7. डेटा खनन अनुप्रयोग

8. एनीमेशन

9. ऐ

10. कंप्यूटर दृष्टी

Comments

मैं इस "जीवन-महत्वपूर्ण" एप्लिकेशन को चिकित्सा उपकरण जैसे जोड़ना चाहूंगा।

— स्टुअर्टमक्लर्क

@stuartmclark, आप काफी सही हैं। मैं स्वचालित नियंत्रण प्रणाली और नेविगेशन सिस्टम का उल्लेख करना भी भूल गया!

— NoChance

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

— 13:19

@ S.Lott, गति अत्यंत प्रासंगिक है। एक क्रिप्टो एल्गोरिदम अच्छी तरह से पर्याप्त रूप से अनुकूलित नहीं होने पर प्रति सेकंड हजारों एसएसएल अनुरोधों की सेवा देने वाली एक वेब साइट चोक हो जाएगी। कुछ भी हार्डवेयर त्वरण का उपयोग कर रहे हैं।

— एसके-तर्क

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

— S.Lott

Answer 2

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

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

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

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

Answer 3

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

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

अधिक उपलब्ध संसाधनों के साथ, इसे बाद में अधिक डेटा को क्रंच करने की आवश्यकता हो सकती है। आज आपको 100,000 लाइनों के साथ 10MB लॉग फ़ाइल का विश्लेषण करने की आवश्यकता है। एक साल में आपके पास 1,000,000,000 लाइनों वाली 100GB लॉग फाइल हो सकती है। यदि डेटा की मात्रा संसाधन शक्तियों की तुलना में तेज़ी से बढ़ती है, तो आप बाद में समस्याओं में भाग लेते हैं।

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

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

Answer 4

कुछ साल पहले मुझे एक एल्गोरिथ्म लिखना था जो टेस्ट ट्यूबों nको दो अलग-अलग विभाजनों में रैक पर व्यवस्थित करता था : यानी ट्यूबों का एक सबसेट 'चुना' गया था और बाकी 'नॉट-चुने हुए' थे और अंतिम परिणाम यह होगा कि कोई रैक नहीं इस पर एक 'चुना' और 'नहीं-चुना हुआ' दोनों ट्यूब होगा (कुछ अतिरिक्त आवश्यकताएं थीं जैसे कि संपीड़न)। प्रत्येक रैक में अधिकतम 100 ट्यूब होते थे।

एल्गोरिथ्म का उपयोग फार्मास्यूटिकल प्रयोगशाला में ट्यूब सॉर्टिंग रोबोट को चलाने के लिए किया जाना था।

जब मूल विनिर्देश मुझे दिया गया था तो मुझे लगभग 2000 ट्यूबों को सॉर्ट करने के लिए गणना समय के 1 मिनट के क्षेत्र में आवंटित किया गया था क्योंकि हमने सोचा था कि प्रयोज्य वार जो बहुत दर्दनाक नहीं था। एक आवश्यकता यह थी कि सभी संभावित संयोजनों पर चालों की संख्या न्यूनतम हो क्योंकि रोबोट स्वयं धीमा था ।

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

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

Comments

अच्छा उदाहरण! लगता है कि आप एक मूलांक के समान कुछ किया था?

— बैरी ब्राउन

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

Answer 5

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

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

Comments

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

— user1118321

Answer 6

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

Answer 7

एल्गोरिथ्म दक्षता आजकल एक प्रमुख चिंता का विषय नहीं है क्योंकि हम कुशल एल्गोरिदम का उपयोग कर रहे हैं। यदि आपने O (n!) एल्गोरिथ्म का उपयोग किया है, तो यह किसी भी तरह के हार्डवेयर पर धीमा होगा।

Comments

यह एक दिलचस्प बात है। "यह एक मुद्दा नहीं है, क्योंकि यह बिना कहे जाना चाहिए" के बजाय "यह एक मुद्दा है, लेकिन एक महत्वपूर्ण नहीं है"।

— 13:11 बजे लेफ्टरेंबाउट

Answer 8

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

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

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

Answer 9

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

Answer 10

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

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

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

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

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

Answer 11

मैं एक बार एक समस्या में भाग गया था जहां एक एल्गोरिथ्म आमतौर पर ओ (एन) में चलता था, लेकिन दुर्लभ और बेहद असंभावित परिस्थितियों में ओ (एन ^ 3) समय की आवश्यकता होगी - "दुर्लभ" परिस्थितियां एक निर्देशिका थीं जिसमें नाम मान्य थे। एक ऑपरेटिंग सिस्टम लेकिन दूसरे में नहीं।

कोई भी कभी समस्याओं में नहीं भागा। तब एक ग्राहक ने फ़ाइलों को नाम देने के लिए एक रणनीति का उपयोग किया जो व्यवस्थित रूप से O (n ^ 3) मामले में चलेगी, और कुछ 100 फाइलों के साथ सिस्टम एक आभासी ठहराव के लिए आया था। परिणाम यह था कि एल्गोरिथ्म को बदलना पड़ा।

Answer 12

तीन और जिनका उल्लेख नहीं किया गया है:

1) कई वास्तविक समय रणनीति खेल। उन लोगों को देखें जिनके पास इकाइयाँ हैं जो एक स्थिति साझा नहीं कर सकते हैं। जब यूनिट्स का एक बड़ा समूह प्रतिबंधित भूभाग से होकर गुजरता है, तो पाथफाइंडिंग का क्या होता है। मुझे अभी तक किसी भी तरह की पर्याप्त समस्या के बिना एक गेम का सामना करना पड़ा है क्योंकि बस पर्याप्त सीपीयू शक्ति उपलब्ध नहीं है।

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

3) चीजें जो रियल टाइम में बड़ी मात्रा में डेटा पर काम करना चाहिए। एक डीवीडी पर विचार करें: आपको आमतौर पर 4.7gb में 2 घंटे का वीडियो मिलता है। समान रिज़ॉल्यूशन पर एक सामान्य वीडियो फ़ाइल पर विचार करें: वीडियो के वे 2 घंटे आम ​​तौर पर 1 जीबी के अंतर्गत आएंगे। इसका कारण यह है कि जब डीवीडी कल्पना रखी गई थी, तो आप एक उचित-मूल्य वाली डीवीडी प्लेयर नहीं बना सकते थे जो कि अधिक आधुनिक प्रारूपों को काफी तेजी से डिकोड कर सके।

Answer 13

खैर, कोई भी एप्लिकेशन जो आमतौर पर सुपर कंप्यूटर ( सबसे बड़ी मशीनों की सूची ) पर चलता है , वह योग्य है। ये विविध हैं, लेकिन उनमें से एक बड़ा उपवर्ग भौतिकी सिमुलेशन है:

• भौतिकी सिमुलेशन:
  • मौसम पूर्वानुमान
  • जलवायु सिमुलेशन
  • विस्फोट सितारों आदि के सिमुलेशन।
  • विस्फोट के नुक्कड़ों का अनुकरण
  • कारों / विमानों / ट्रेनों आदि के वायुगतिकीय सिमुलेशन
  • ...
• रेडियो टेलीस्कोप डेटा से छवियों की गणना
• जैविक अनुप्रयोग:
  • डीएनए अनुक्रम के साथ सामान (मैं वास्तव में उन में नहीं हूँ)
  • प्रोटीन तह जैसे जैव रासायनिक सामान
  • जानकारी को संसाधित करने के लिए तंत्रिका कोशिकाएं एक साथ कैसे काम करती हैं इसका अनुकरण
  • पारिस्थितिक तंत्र जैसी अन्य जटिल अंत: क्रियाओं का अनुकरण
  • ...
• ...

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

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