आमतौर पर कुशल होने के लिए अंतर्निहित हार्डवेयर के साथ कार्यात्मक प्रतिमान भी भिन्न नहीं है?

Question

SO के एक प्रश्न से प्रेरित: /programming/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell

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

थीसिस:

कार्यात्मक प्रतिमान का तात्पर्य अपरिवर्तनीयता और स्टेटलेसनेस (?) से है, लेकिन जिस हार्डवेयर पर हम कार्यात्मक प्रोग्राम चलाते हैं, वह स्टेटफुल फिनोमेट ऑटोमेटा है। Ful प्योर फंक्शनल ’प्रोग्राम का ful स्टेटफुल हार्डवेयर’ रिप्रेजेंटेशन का अनुवाद प्रोग्रामर के लिए थोड़ा नियंत्रण छोड़ देता है, ओवरहेड (?) लाता है और हार्डवेयर क्षमताओं (?) के उपयोग को सीमित करता है।

क्या मैं प्रश्नवाचक कथन में सही या गलत हूँ?

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

संपादित करें: जैसा कि मैंने पहले ही कुछ टिप्पणियों के जवाब में कहा है, सवाल कार्यान्वयन प्रदर्शन और विवरण के बारे में नहीं है। यह प्रिंसिपल ओवरहेड की मौजूदगी या अनुपस्थिति के बारे में है , जो स्टेटफुल ऑटोमेटा पर एफपी चला रहा हो सकता है।

Comments

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

— सीए मैक्कैन

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

— जेरेमी

@camccann, @ जेरेमी: सी # और जावा, उदाहरण के लिए, आभासी मशीनों का उपयोग करें। कोई फर्क नहीं पड़ता कि यह कितना इष्टतम है, कोई फर्क नहीं पड़ता कि उत्पादन के लिए C # और जावा प्रोग्राम कितने कुशल हैं, अक्षमता का एक प्रमुख स्रोत है, और यह वीएम है। सवाल कार्यान्वयन प्रदर्शन के बारे में नहीं है, लेकिन running FP on stateful automata।

— दाखलता

मेरा सवाल यहाँ देखें- प्रोग्रामर.स्टैकएक्सचेंज.

— गुलशन

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

— सीए मैककैन

Answer 1

अपरिवर्तनीयता में भारी गलतफहमी है।

अपरिवर्तनीयता शब्दार्थ की एक विशेषता है, लेकिन यह कार्यान्वयन में अपरिवर्तनीयता नहीं है।

एक सरल उदाहरण आलस्य का कार्यान्वयन है।

जब कम्प्यूटेशंस आलसी होते हैं, तो एक अभिव्यक्ति का परिणाम वैचारिक रूप से एक मूल्य होता है, लेकिन अंतर्निहित कार्यान्वयन एक ऐसा हिस्सा है जिसमें मूल्यांकन करने के लिए तर्क होते हैं और मूल्य बनाने के लिए एक फ़ंक्शन होता है, साथ ही मूल्य को संग्रहीत करने के लिए एक स्लॉट भी होता है।

पहली बार जब आप मूल्य के लिए (भाषा में) पूछेंगे, तो गणना वास्तव में की जाएगी, इसका परिणाम मूल्यांकन किया गया है, और मूल्य आपको वापस (या एक हैंडल) दिया गया है।

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

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

अब, यह सच है कि व्यावहारिक रूप से कार्यात्मक भाषाएँ C ++ जितनी तेज़ नहीं हैं, उदाहरण के लिए। हालांकि, Go(जो अभी भी बहुत प्रचार है) हास्केल या लिस्प की तुलना में धीमा है, और इसलिए सी # मोनो ( स्रोत ) है।

जब आप देखते हैं कि अविश्वसनीय C ++ या C आपको उन प्रदर्शनों को प्राप्त करने के लिए कैसे हो सकते हैं, तो आप थोड़ा जाने देना चाह सकते हैं।

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

मज़ा: रेग्युलर एक्सप्रेशंस पर एक प्ले या कैसे एक हास्केल टीम ने एक नियमित अभिव्यक्ति मिलानकर्ता बनाया re2जो कई स्थितियों में Google से सी लाइब्रेरी को आउटपरफॉर्म करता है।

Comments

ध्वनि आशावादी :)

— लताओं

Answer 2

कार्यात्मक प्रतिमान एक संकीर्ण दायरे में बात को विभाजित करने के लिए उपयोगी है। यह वास्तव में एक अच्छी बात है कि कंप्यूटर कैसे विकसित होता है।

मल्टीकोर सीपीयू में साझा संसाधनों से निपटने में बड़ी समस्याएं हैं और सिंक्रनाइज़ेशन लागत वास्तव में अतिरंजित हैं। कार्यात्मक प्रतिमान उन कार्यक्रमों को व्यक्त करने के लिए एक प्राकृतिक तरीका देता है जिनमें समस्याएँ नहीं होती हैं। यह समानता के लिए वास्तव में अच्छा है।

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

इसके अलावा, आप आसानी से कंप्यूटर के ढेर में एक स्टैक कर सकते हैं, और यहां तक ​​कि लिंक किए गए सूचियों का उपयोग करके एक निरंतर भी। यह कई प्रोग्राम भाषाओं में स्टैक ट्रेस जनरेट करने के लिए किया जाता है। तो यह कोई मुद्दा नहीं है।

ठीक है, फंक्शनल प्रोग्रामिंग का अर्थ है कुछ सीमाएँ। लेकिन यह आधुनिक गणना में हमारे पास आने वाली समस्याओं को व्यक्त करने का स्वाभाविक तरीका भी है, जो कि प्रतिमानों को संभालने में बेहद कठिन हैं। स्केलेबिलिटी उनमें से एक है, और यह एक वास्तविक सौदा बन रहा है।

हर कोई जो पहले से ही एक जटिल समानांतर प्रणाली से निपटता है, वह जानता है कि मैं किस बारे में बात कर रहा हूं।

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

Answer 3

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

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

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

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

Answer 4

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

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

Comments

मुद्दे आवश्यकताओं के सापेक्ष हैं ... प्रदर्शन-महत्वपूर्ण क्षेत्रों के बारे में क्या? उच्च समानता वहां मूल्यवान है, लेकिन समग्र स्कोर क्या है?

— दाखलता

@vines: मैंने प्रदर्शन-महत्वपूर्ण एप्लिकेशन के लिए या तो भाषा का उपयोग नहीं किया है, इसलिए मैं वास्तव में उससे बात नहीं कर सकता।

— लैरी कोलमैन

कोई साइड इफेक्ट के साथ बहुत मज़ा नहीं है, क्योंकि आप परिणाम को कहीं भी नहीं बचा पाएंगे।

@ Thorbjørn Ravn Andersen: ... एक तरह से इसे कॉलर को वापस करने के अलावा, जिसकी अनुमति है।

— दाखलता