MPI C ++ इंटरफ़ेस से उपयोगकर्ताओं को क्या सुविधाएँ चाहिए?


28

MPI मानक के 3.0 संस्करण ने औपचारिक रूप से C ++ इंटरफ़ेस को हटा दिया (यह पहले पदावनत किया गया था)। हालांकि कार्यान्वयन अभी भी इसका समर्थन कर सकते हैं, लेकिन MPI-3 में जो सुविधाएँ नई हैं, उनमें MP ++ मानक में परिभाषित C ++ इंटरफ़ेस नहीं है। अधिक जानकारी के लिए http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ देखें ।

MPI से C ++ इंटरफ़ेस को हटाने की प्रेरणा यह थी कि C इंटरफ़ेस पर इसका कोई महत्वपूर्ण मूल्य नहीं था। "S / _ / :: / g" के अलावा बहुत कम अंतर थे और कई विशेषताएं जो C ++ उपयोगकर्ता के आदी हैं, उन्हें नियोजित नहीं किया गया था (उदाहरण के लिए टेम्पलेट्स के माध्यम से स्वचालित प्रकार का निर्धारण)।

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

और हाँ, मैं Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ) से परिचित हूं, लेकिन यह केवल MPI-1 सुविधाओं का समर्थन करता है और क्रमांकन मॉडल होगा आरएमए के लिए समर्थन करना बेहद मुश्किल है।

MPI का एक C ++ इंटरफ़ेस जो मुझे पसंद है वह है एलिमेंटल ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ) ताकि शायद लोग कुछ प्रो और कॉन प्रदान कर सकें। दृष्टिकोण। विशेष रूप से, मुझे लगता है कि MpiMap एक आवश्यक समस्या हल करता है।


मुझे नहीं लगता कि यह इस तरह के सवाल के लिए उपयुक्त जगह है।
जैक पॉल्सन

क्या आप उसके लिए कुछ कारण बता सकते हैं? इस साइट पर एमपीआई के कई प्रश्न मुझे सुझाव देते हैं कि यहां के लोग इस प्रश्न का उत्तर देने के लिए तैयार हैं। इसके अलावा, प्रति मिनट 0.2 अपवोट्स अन्य लोगों को आपके आकलन से असहमत होने का सुझाव देते हैं। किसी भी स्थिति में, यदि आप वर्तमान स्थान को पसंद नहीं करते हैं, तो इसे पोस्ट करने के लिए वैकल्पिक स्थान का सुझाव देना अधिक सहायक होगा।
जेफ

प्रश्न एक मूल्यवान है, और मुझे लगता है कि यह व्यापक कम्प्यूटेशनल विज्ञान मेलिंग सूचियों पर कुछ मूल्यवान प्रतिक्रियाएं प्राप्त कर सकता है, अगर यह वहां गुंजाइश है। (शायद एनए-डाइजेस्ट, सियाम-सीएसई, या जी + पर एक सार्वजनिक पोस्ट भी?) यह सवाल एक स्टैक एक्सचेंज साइट के लिए एक अच्छा फिट नहीं हो सकता है क्योंकि यह व्यक्तिपरक है (देखें scicomp.stackexchange.com/help/lont-ask ) । जब तक उत्तर ठोस हैं और विशिष्ट उपयोग के मामलों (महत्वपूर्ण दोहराव या ओवरलैप के बिना) पर ध्यान केंद्रित करते हैं, मुझे लगता है कि यह खुले रखने के लायक है।
ज्योफ ऑक्सीबेरी

@ जेफ: यह प्रश्न मेरे लिए एक सर्वेक्षण की तरह आता है। मैं इस बात पर विवाद नहीं करता कि यह मूल्यवान है, लेकिन मुझे नहीं लगता कि कोई एक स्वीकृत जवाब है। क्या ऐसा सवाल MPI मंच के लिए सामान्य होगा?
जैक पॉल्सन

@JackPoulson मैं यह नहीं जानना चाहता कि कार्यान्वयनकर्ता क्या सोचते हैं कि यह सही उत्तर है; मैं जानना चाहता हूं कि कम्प्यूटेशनल वैज्ञानिकों को क्या चाहिए। इस संबंध में, इस प्रश्न के वस्तुनिष्ठ उत्तर हैं। एक सही उत्तर नहीं है, लेकिन इसका मतलब यह नहीं है कि यह एक व्यक्तिपरक स्थिति है।
जेफ

जवाबों:


17

मुझे पहले उत्तर दें कि मुझे क्यों लगता है कि MP ++ में C ++ इंटरफेस आम तौर पर सफल नहीं हुए हैं, इस मुद्दे के बारे में एक लंबे समय के लिए सोचा है जब यह तय करने की कोशिश की जा रही है कि क्या हमें एमपीआई के मानक सी बाइंडिंग का उपयोग करना चाहिए या उच्च स्तर पर किसी चीज का निर्माण करना चाहिए। :

जब आप वास्तविक दुनिया के MPI कोड (कहते हैं, PETSc, या मेरे मामले में डील। II) को देखते हैं, तो कोई पाता है कि शायद आश्चर्यजनक रूप से, MPI कॉल की संख्या वास्तव में बहुत बड़ी नहीं है। उदाहरण के लिए, deal.II की 500k लाइनों में, केवल ~ 100 MPI कॉल हैं। इसका एक परिणाम यह है कि एमपीआई सी बाइंडिंग जैसे निचले स्तर के इंटरफेस का उपयोग करने में शामिल दर्द बहुत बड़ा नहीं है। इसके विपरीत, कोई उच्च स्तरीय इंटरफेस का उपयोग करके यह सब हासिल नहीं करेगा।

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

इसलिए मुझे लगता है कि यह सब एमपीआई को सी ++ इंटरफेस की वर्तमान फसल के खिलाफ साजिश है: पुराने एमपीआई सी ++ बाइंडिंग ने कोई लाभ नहीं दिया, और बाहरी पैकेजों को वास्तविक दुनिया के साथ कठिनाइयों का सामना करना पड़ा।

इस सभी ने कहा, यहां मुझे लगता है कि हत्यारे की विशेषताएं मैं एक उच्च-स्तरीय इंटरफ़ेस से लेना चाहूंगा:

  • यह सामान्य होना चाहिए। वैरिएबल के डेटा प्रकार को निर्दिष्ट करना निश्चित रूप से C ++ की तरह नहीं है। बेशक, यह भी त्रुटियों की ओर जाता है। एलिमेंटल का MpiMap वर्ग पहले से ही एक अच्छा पहला कदम होगा (हालांकि मैं यह नहीं जान सकता कि MpiMap::typeचर स्थिर स्थैतिक क्यों नहीं है, ताकि इसे एक वस्तु बनाए बिना पहुँचा जा सके)।

  • इसमें मनमाने ढंग से डेटा टाइप करने की सुविधा होनी चाहिए।

  • ऑपरेशंस जिसमें एक MPI_Opतर्क की आवश्यकता होती है (उदाहरण के लिए, कटौती) को C ++ के std::functionइंटरफ़ेस के साथ अच्छी तरह से एकीकृत किया जाना चाहिए , ताकि किसी कार्य को पंजीकृत करने के बजाय केवल फ़ंक्शन पॉइंटर (या लैम्ब्डा!) पास करना आसान हो।

बढ़ावा :: mpi वास्तव में इन सभी को संतुष्ट करता है। मुझे लगता है कि अगर यह हेडर-ओनली लाइब्रेरी होता, तो यह व्यवहार में बहुत अधिक लोकप्रिय होता। अगर यह पोस्ट-एमपीआई 1.0 कार्यों का समर्थन करता है, तो यह भी मदद करेगा, लेकिन चलो ईमानदार रहें: यह उस समय के अधिकांश को कवर करता है जिसकी हमें सबसे अधिक आवश्यकता होती है।


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

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

हाय वोल्फगैंग, आप सही हैं कि MpiMap अधिक सुंदर होगा यदि यह एक स्थिर कास्ट सदस्य चर का उपयोग करता है। मैंने कार्यान्वयन को पुनर्गठित किया है: github.com/poulson/Elemental/commit/…
जैक पॉल्सन

हाँ, बहुत अच्छा है :-)
वोल्फगैंग बंगर्थ जूथ

+1 के बारे में नहीं कई mpi कॉल @ वोल्फगैंगबैंगर्थ। मौलिक रूप से बोलें तो, एमपीआई की गणना तेजी से करने वाली है, आप एमपीआई कॉल को कम से कम करना चाहते हैं क्योंकि वे आपको खर्च करते हैं!
चार्ल्स

6

गेंद लुढ़कने के लिए, यहाँ मेरी दो ज़रूरतें हैं:

  • इंटरफ़ेस निरर्थक या अनावश्यक तर्कों को समाप्त करने में सक्षम होना चाहिए, जैसे MPI_IN_PLACE।
  • इंटरफ़ेस को ऑटो-अंतर्निहित डेटाटाइप्स एला एलिमेंटल के MpiMap का पता लगाना चाहिए।
  • यदि / जब भी संभव हो, कक्षाओं के लिए उपयोगकर्ता-परिभाषित डेटाटिप्स का निर्माण किया जाना चाहिए।

5

वरीयता की कोई विशेष क्रम में मेरी सूची। इंटरफ़ेस चाहिए:

  • केवल हेडर हो, बिना किसी निर्भरता के लेकिन <mpi.h>, और मानक पुस्तकालय,
  • सामान्य और एक्स्टेंसिबल हो,
  • केवल गैर-अवरुद्ध होना (यदि आप ब्लॉक करना चाहते हैं, तो स्पष्ट रूप से ब्लॉक करें, डिफ़ॉल्ट रूप से नहीं),
  • नॉन-ब्लॉकिंग ऑपरेशंस की निरंतरता-आधारित चैनिंग की अनुमति दें,
  • एक्स्टेंसिबल और कुशल क्रमांकन का समर्थन करें (Boost.Fusion की तरह, जैसे कि यह RMA के साथ काम करता है),
  • शून्य अमूर्त दंड (यानी कम से कम सी इंटरफेस के रूप में तेजी से हो),
  • सुरक्षित रहें (एक गैर-तैयार भविष्य का विनाशकर्ता कहा जाता है? -> std :: terminate!)
  • DEBUGजोर के टन के साथ एक मजबूत मोड है,
  • सब कुछ के लिए अत्यंत प्रकार-सुरक्षित (कोई और अधिक इन्ट्स / शून्य * नहीं, मैं चाहता हूं कि टैग टाइप हों!)।
  • यह लैम्ब्डा के साथ काम करना चाहिए (जैसे सभी कम + लैम्ब्डा),
  • त्रुटि-रिपोर्टिंग और त्रुटि-हैंडलिंग तंत्र के रूप में लगातार अपवादों का उपयोग करें (कोई और त्रुटि कोड नहीं! कोई अधिक फ़ंक्शन आउटपुट तर्क नहीं!)।
  • MPI-IO को Boost.AFIO की शैली में एक गैर-अवरुद्ध I / O इंटरफ़ेस की पेशकश करनी चाहिए।
  • और बस अच्छे आधुनिक C ++ इंटरफ़ेस डिज़ाइन प्रथाओं का पालन करें (नियमित प्रकारों को परिभाषित करें, गैर-सदस्य गैर-मित्र फ़ंक्शंस, चाल शब्दार्थों के साथ अच्छी तरह से खेलें, रेंज ऑपरेशन, समर्थन ...)

अतिरिक्त सुविधाएं:

  • मुझे MPI वातावरण के निष्पादक को चुनने की अनुमति दें, अर्थात, यह कौन सा थ्रेड पूल उपयोग करता है। अभी आपके पास OpenMP, MPI, CUDA, और TBB के मिश्रण के साथ अनुप्रयोग हो सकते हैं ... सभी एक ही समय में, जहां प्रत्येक रन-टाइम को लगता है कि यह पर्यावरण का मालिक है और इस प्रकार हर बार जब वे महसूस करते हैं तो ऑपरेटिंग सिस्टम थ्रेड्स के लिए पूछते हैं यह। गंभीरता से?

  • STL (और बूस्ट) नामकरण सम्मेलन का उपयोग करें। क्यूं कर? हर C ++ प्रोग्रामर इसे जानता है।

मैं इस तरह कोड लिखना चाहता हूं:

auto buffer = some_t{no_ranks};
auto future = gather(comm, root(comm), my_offsets, buffer)
              .then([&](){
                /* when the gather is finished, this lambda will 
                   execute at the root node, and perform an expensive operation
                   there asynchronously (compute data required for load 
                   redistribution) whose result is broadcasted to the rest 
                   of the communicator */
                return broadcast(comm, root(comm), buffer);
              }).then([&]() {
                /* when broadcast is finished, this lambda executes 
                   on all processes in the communicator, performing an expensive
                   operation asynchronously (redistribute the load, 
                   maybe using non-blocking point-to-point communication) */
                 return do_something_with(buffer);
              }).then([&](auto result) {
                 /* finally perform a reduction on the result to check
                    everything went fine */
                 return all_reduce(comm, root(comm), result, 
                                  [](auto acc, auto v) { return acc && v; }); 
              }).then([&](auto result) {
                  /* check the result at every process */
                  if (result) { return; /* we are done */ }
                  else {
                    root_only([](){ write_some_error_log(); });
                    throw some_exception;
                  }
              });

/* Here nothing has happened yet! */

/* ... lots and lots of unrelated code that can execute concurrently 
   and overlaps with communication ... */

/* When we now call future.get() we will block 
   on the whole chain (which might have finished by then!).
*/

future.get();

सोचें कि MPI_C के उपयोग से यह सभी ऑपरेशन कैसे चेन कर सकते हैं request। यदि आप बिना ब्लॉक किए अपनी श्रृंखला को आगे बढ़ा सकते हैं तो आपको कई सारे असंबंधित कोड के माध्यम से कई (या हर एक) मध्यवर्ती कदम पर परीक्षण करना होगा ।


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

थ्रेड्स और रनटाइम वातावरण के लिए, MPI आंतरिक रूप से या तो कोई थ्रेड्स या OS थ्रेड्स (POSIX, Windows या Solaris, OS पर निर्भर करता है) का उपयोग करता है। मुझे यकीन नहीं है कि मैं यहां की आवश्यकता को समझता हूं।
जेफ़

समस्या यह है कि MPI ऑपरेटिंग सिस्टम से थ्रेड्स का अनुरोध कर सकती है। मेरे आवेदन में एक थ्रेड पूल है और मैं चाहूंगा कि MPI अपने थ्रेड पूल से उन थ्रेड्स का अनुरोध करे। यह वर्तमान में संभव नहीं है (और आम तौर पर एक मुद्दा नहीं है), जब तक कि आपके पास ओपनएमपी, टीबीबी और एमपीआई का उपयोग करने वाला कोई एप्लिकेशन न हो, प्रत्येक अपने स्वयं के थ्रेड पूल के साथ, प्रत्येक 4x नंबर कोर के साथ।
gnzlbg

1
MPI, लेकिन आम तौर पर आंतरिक रूप से OS थ्रेड्स का उपयोग नहीं करता है। प्रत्येक मामले में जिसके साथ मैं परिचित हूं (MPICH (2), MVAPICH2, OpenMPI, CrayMPI), केवल रनटाइम विकल्प उपयोगकर्ता द्वारा प्रदान किया जाता है, ऐसा होने का कारण बनता है, अर्थात डिफ़ॉल्ट यह नहीं है। ब्लू जीन / क्यू एमपीआई एक अपवाद है लेकिन इस रूप में इस चर्चा के लिए प्रासंगिक नहीं है।
जेफ

धन्यवाद @ जेफ़! क्या आप इस बात पर विस्तृत जानकारी दे सकते हैं कि MPI एक सिंगल थ्रेड का उपयोग करते समय कई गैर-अवरोधक कॉल को कैसे संभालता है? क्या यह कोरटाइन्स / हरे धागे / रेशों का उपयोग करता है?
gnzlbg

2

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

केवल चीजें जो मुझे वास्तव में सी-स्टाइल एमपीआई के साथ परेशान करती हैं, वे कस्टम डेटाैटिप्स हैं और कुछ हद तक, कस्टम संचालन (क्योंकि मैं उन्हें कम बार उपयोग करता हूं)। कस्टम डेटाटाइप्स के लिए, मैं कहूंगा कि एक अच्छा C ++ इंटरफ़ेस को इस से निपटने के सामान्य और कुशल तरीके का समर्थन करने में सक्षम होना चाहिए, जो कि संभवत: क्रमांकन के माध्यम से होगा। यह निश्चित रूप से मार्ग है boost.mpi, जो अगर आप सावधान हैं , तो एक बड़ा समय बचाने वाला है।

boost.mpiअतिरिक्त निर्भरता रखने के लिए (विशेष रूप से boost.serializationजो कि केवल हेडर-ओनली नहीं है), मैं हाल ही में एक हेडर-केवल C ++ क्रमांकन पुस्तकालय में आया हूं जिसे अनाज कहा जाता है जो आशाजनक लगता है; यह एक सी + + 11 संकलक संकलक की आवश्यकता है। यह देखने के लायक हो सकता है और इसका उपयोग कुछ इसी तरह के आधार पर कर सकता है boost.mpi


ध्यान दें कि मैं आवश्यक रूप से एमपीआई मानक में डालने के लिए कुछ नहीं देख रहा था। मैं इस बात से पूरी तरह सहमत हूं कि एमपीआई को लगभग हमेशा "कुछ उच्च-स्तरीय कोड द्वारा लपेटा जाना चाहिए", इसलिए मुझे आश्चर्य होता है कि उच्च-स्तरीय कोड क्या दिखता है? मौलिक में एक अच्छा दृष्टिकोण है, लेकिन क्या यह सभी मामलों के लिए सबसे अच्छा है? अगर कोई MPI के लिए C ++ इंटरफ़ेस चाहता है जो बहुत बड़ी संख्या में लोगों को खुश करने की कोशिश करता है, तो यह कैसा दिखेगा?
जेफ

@Jeff। मेरे लिए: 1. मुझे आसानी से कस्टम डेटा प्रकार भेजने में सक्षम होना पसंद है। 2. मैं आसानी से कस्टम संचालन के साथ कटौती करने में सक्षम होना पसंद करता हूं। इसके अलावा, मुझे लगता है कि 1 मैं 1 से अधिक महत्वपूर्ण / उपयोगी
बोलता हूं

मैं यह नहीं देखता कि कैसे C ++ जादुई wrt (2) कुछ भी करता है। आप यहाँ क्या कल्पना करते हैं?
जेफ

@ जेफ़ मैं कुछ चीजों के बारे में सोच रहा था कि thrustयह कटौती के लिए कैसे होती है: docs.thrust.googlecode.com/hg/group__reductions.html
GradGuy

-1

गीथब प्रोजेक्ट ईजीलैम्बडा एमपीआई को C ++ 14 के साथ एक उच्च स्तरीय इंटरफ़ेस प्रदान करता है।

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

प्रदर्शन और कोड की लाइनों पर प्रारंभिक बेंचमार्क ने आशाजनक परिणाम दिखाए हैं।

यहाँ छवि विवरण दर्ज करें

निम्नलिखित सुविधाओं और इंटरफ़ेस का संक्षिप्त विवरण है जो इसे प्रदान करता है।

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

मुझे आशा है कि यहां अधिक विवरण और उदाहरण कोड जोड़ने के बजाय लिंक देना ठीक है।

डिस्क्लेमर: मैं पुस्तकालय का लेखक हूं। मेरा मानना ​​है कि मैं easyLambda के वर्तमान इंटरफ़ेस पर एक रचनात्मक प्रतिक्रिया प्राप्त करने की उम्मीद में कोई नुकसान नहीं कर रहा हूं जो कि easyLambda और इसी तरह के लक्ष्यों का पीछा करने वाले किसी भी अन्य प्रोजेक्ट के लिए फायदेमंद हो सकता है।


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

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

@UtkarshBhardwaj: कुछ टिप्पणियां: (1) एक लाइब्रेरी लिखने के लिए धन्यवाद जो C ++ को MPI के साथ जोड़ता है। यह एक महत्वपूर्ण उपक्रम है और लगता है कि आपने इसमें बहुत काम किया है। (2) डॉक्स (फिर से, अच्छी नौकरी) के लिए जल्दी से मना करना, जो खड़ा है वह इस्तेमाल की जाने वाली विधि कमांड की लंबी श्रृंखला है, जो स्टाइलिस्टली लगता है ... डीबग करने के लिए दर्दनाक है, भले ही आप उन्हें अच्छी तरह से स्वरूपित कर रहे हैं। (3) अमूर्त एक कार्यात्मक प्रतिमान मानते हैं, जो मानचित्र-कम करने जैसे कार्यों के लिए उपयोगी दिखता है, लेकिन जैसा कि कोई व्यक्ति जो MPI में प्रोग्राम करता है, मैं अपने एल्गोरिदम को फिर से काम नहीं करना चाहता हूं और उन इंटरफेस से बहुत दूर जाना चाहता हूं जिन्हें मैं जानता हूं।
ज्योफ ऑक्सीबेरी

(4) मैं संचारकों को उदाहरण में कहीं भी नहीं देखता, जो मुझे संदेह है कि आप हर चीज के लिए MPI_COMM_WORLD का उपयोग कर रहे हैं, और अपने पुस्तकालय की क्षमता को सीमित करते हैं। (५) एब्सट्रैक्ट एमपीआई एब्स्ट्रैक्ट पर बनते हैं और एक अलग बैकेंड हो सकते हैं। (६) (३) - (५) के आधार पर, मुझे नहीं लगता कि यह पुस्तकालय एक MPI इंटरफ़ेस है, और मेरा मानना ​​है कि यह टिप्पणी एक परिणाम के रूप में विषय है।
ज्योफ ऑक्सबेरी

@ बहुमूल्य प्रतिक्रिया के लिए धन्यवाद धन्यवाद, बहुत सराहना की। विशिष्ट बिंदुओं का उत्तर दें: 2) कभी-कभी शाइनिंग को एक्सप्रेशनब्यूलर कहा जाता है । यह कार्यात्मक शैली में रचना को व्यक्त करने का एक सामान्य तरीका है। इस शैली में ईज़ल में लिखना आवश्यक नहीं है। व्यक्तिगत इकाइयों को पहले लिखना और फिर उन्हें लिखना संभव है, [उदाहरण] ( goo.gl/YzaL0k ) की जांच करें। 3) मुझे पता है कि नियंत्रण-प्रवाह और डेटाफ्लो और कार्यात्मक के लिए जरूरी है। प्रत्येक के पास पेशेवरों और विपक्ष हैं। हालांकि, मेरा मानना ​​है कि इसकी वास्तविक प्रभावकारिता को जानने के लिए उत्तरार्द्ध की अधिक खोजबीन की जानी चाहिए।
उत्कर्ष भारद्वाज
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.