कार्यात्मक प्रोग्रामिंग और मल्टीकोर आर्किटेक्चर

Question

मैंने कहीं पढ़ा है कि कार्यात्मक प्रोग्रामिंग कंप्यूटिंग में बहु-कोर प्रवृत्ति का लाभ लेने के लिए उपयुक्त है। मुझे वास्तव में विचार नहीं मिला। क्या यह लैम्ब्डा कैलकुस और वॉन न्यूमैन आर्किटेक्चर से संबंधित है?

Answer 1

कार्यात्मक प्रोग्रामिंग साइड इफेक्ट्स को कम या समाप्त करता है और इस प्रकार वितरित प्रोग्रामिंग के लिए बेहतर अनुकूल है। यानी मल्टीकोर प्रसंस्करण।

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

Answer 2

मूल तर्क यह है कि सी/सी ++/आदि जैसी भाषाओं को स्वचालित रूप से समानांतर करना मुश्किल है क्योंकि फ़ंक्शन वैश्विक चर सेट कर सकते हैं। पर विचार करें दो फ़ंक्शन को कॉल:

a = foo(b, c); 
d = bar(e, f); 

हालांकि foo और बार आम है और एक में कोई तर्क अन्य की वापसी कोड पर निर्भर नहीं करता है, वे फिर भी निर्भरता हो सकता है क्योंकि foo एक वैश्विक चर (या दूसरे पक्ष सेट कर सकते हैं प्रभाव) कौन सा बार पर निर्भर करता है।

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

Answer 3

किसी भी तकनीकी/वैज्ञानिक शर्तों को छोड़ना कारण है क्योंकि कार्यात्मक प्रोग्राम डेटा साझा नहीं करता है। डेटा की प्रतिलिपि बनाई जाती है और कार्यों के बीच स्थानांतरित की जाती है, इस प्रकार आवेदन में कोई साझा डेटा नहीं है।

और साझा डेटा मल्टीथ्रेडिंग के साथ आधा सिरदर्द का कारण बनता है।

Answer 4

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

किसी सर्वर या पीसी में बहु-यू सर्वर और बहु-कोर CPU के बीच का अंतर एक ही बस पर होने वाली गति बचत है, जो कोर को बेहतर और तेज़ संचार की अनुमति देता है।

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

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

Answer 5

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

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

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

Answer 6

जब कोई साइड इफेक्ट नहीं होता है तो मूल्यांकन का आदेश कोई फर्क नहीं पड़ता। समानांतर में अभिव्यक्तियों का मूल्यांकन करना संभव है।

Answer 7

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

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

Answer 8

जो आर्मस्ट्रांग द्वारा Programming Erlang: Software for a Concurrent World पुस्तक (Erlang के निर्माता) मल्टीकोर (/ मल्टीप्रोसेसर) सिस्टम के लिए Erlang का उपयोग करने के बारे में काफी कुछ बोलती है। विकिपीडिया लेख के अनुसार:

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

Answer 9

मैंने कहीं पढ़ा है कि कार्यात्मक प्रोग्रामिंग कंप्यूटिंग में मल्टी कोर प्रवृत्ति का लाभ लेने के लिए उपयुक्त है ... मैं वास्तव में विचार नहीं मिला। क्या यह लैम्ब्डा कैलकुस और वॉन न्यूमैन आर्किटेक्चर से संबंधित है?

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

• The absolute performance of purely functional data structures is poor:

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

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

• शुद्ध रूप से कार्यात्मक प्रोग्रामिंग प्रदर्शन अप्रत्याशित प्रस्तुत करता है। तो वास्तविक शुद्ध रूप से कार्यात्मक कार्यक्रम अक्सर प्रदर्शन गिरावट देखते हैं जब समांतरता होती है क्योंकि ग्रैन्युलरिटी प्रभावी ढंग से यादृच्छिक होती है।

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

हालांकि, प्रथम श्रेणी के कार्यों के उपयोग पर जोर देने वाली शैली के रूप में कार्यात्मक प्रोग्रामिंग की अधिक सामान्य परिभाषा वास्तव में मल्टीकोर प्रोग्रामिंग के संदर्भ में बहुत उपयोगी साबित होती है क्योंकि यह प्रतिमान समानांतर कार्यक्रमों के फैक्टरिंग के लिए आदर्श है। उदाहरण के लिए, System.Threading.Tasks नाम से नया उच्च-आदेश Parallel.For फ़ंक्शन देखें .NET 4.