C # की तुलना में C ++ कितना तेज है?

Question

या अब यह दूसरा रास्ता है?

मैंने जो सुना है उसमें कुछ ऐसे क्षेत्र हैं जिनमें C # C ++ की तुलना में अधिक तेज़ साबित होता है, लेकिन मैंने कभी भी यह जांचने की हिम्मत नहीं की है।

सोचा था कि आप में से कोई भी इन मतभेदों को विस्तार से बता सकता है या मुझे इस बारे में जानकारी के लिए सही जगह पर इंगित कर सकता है।

Comments

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

— रॉबर्ट हार्वे

यह कैसे भी राय / तर्क के रूप में बंद नहीं है? क्या मैं अभी भी StackOverflow पर नहीं हूँ? (करीबी का सुझाव नहीं, बस जिज्ञासु। मुझे उन सवालों से प्यार है, जो तर्क वितर्क करते हैं)

— बिल के

यह लगभग एक मूक सवाल है, यह देखते हुए कि हम एक ऐसे युग में रहते हैं जिसमें IL को CPP में बदला जा सकता है और वहाँ से अनुकूलित किया जा सकता है: docs.unity3d.com/Manual/IL2CPP.html

— pixelpax

वह भाषा जो श्रेणी सरणी एक्सेस से बाहर की जाँच करती है, वह कभी भी बेहतर नहीं होगी।

— सेवा अलेक्सेयेव

@SevaAlekseyev यह भाषा नहीं है जो यह करता है लेकिन संकलक है। C ++ का एक कारण यह है कि तेज (स्पष्ट लोगों के अलावा) यह है कि C ++ कंपाइलर पिछले 35 वर्षों से है (यदि अधिक नहीं है)। ऐसा कुछ भी नहीं है जो समय के साथ बेहतर होने के लिए सी # संकलक को रोकता है। आपके द्वारा

— ट्रैप

Answer 1

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

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

दूसरी ओर, बिना कुछ किए ही, रनटाइम (.NET CLR या Java VM) के बाद के संस्करणों में व्याख्या की गई भाषाओं में कोड तेज़ हो जाता है। और बहुत सारे उपयोगी अनुकूलन हैं जेआईटी संकलक ऐसा कर सकते हैं जो बिंदुओं वाली भाषाओं में असंभव हैं। इसके अलावा, कुछ का तर्क है कि कचरा संग्रह आमतौर पर मैनुअल मेमोरी प्रबंधन के रूप में तेज या तेज होना चाहिए, और कई मामलों में यह है। आप इसे C ++ या C में आम तौर पर लागू कर सकते हैं और प्राप्त कर सकते हैं, लेकिन यह बहुत अधिक जटिल और त्रुटि प्रवण होने वाला है।

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

ध्यान रखें कि एक सही कार्यक्रम को अनुकूलित करना अपेक्षाकृत आसान है, लेकिन एक अनुकूलित कार्यक्रम को सही करने के लिए बहुत कठिन है।

गति लाभ का वास्तविक प्रतिशत देना असंभव है, यह काफी हद तक आपके कोड पर निर्भर करता है। कई मामलों में, प्रोग्रामिंग भाषा कार्यान्वयन भी अड़चन नहीं है। स्केचिसिज्म के एक बड़े सौदे के साथ http://benchmarkgame.alioth.debian.org/ पर बेंचमार्क लें , क्योंकि ये बड़े पैमाने पर अंकगणित कोड का परीक्षण करते हैं, जो कि आपके कोड के समान नहीं है।

Comments

<बोली> व्याख्या की गई भाषाओं में कोड रनटाइम के बाद के संस्करणों में तेज हो जाता है </ उद्धरण> संकलक के बेहतर संस्करण द्वारा संकलित कोड भी तेज हो जाएगा।

— मार्टिन यॉर्क

वास्तव में कम से कम एक कारण है: जेआईटी को तेज करने की आवश्यकता है, और सी ++ संकलक के लिए उपलब्ध विभिन्न उन्नत अनुकूलन पर समय बिताने का जोखिम नहीं उठा सकता है।

— नेमांजा ट्राइफुनोविक

"लेकिन आमतौर पर अति-अनुकूलन के कारण त्रुटियों की ओर भी जाता है।" [प्रशस्ति पत्र की सख्त जरूरत है]। मैं एक राष्ट्रीय प्रयोगशाला में काम करता हूं, और हम अपने कोड से नरक को अनुकूलित करते हैं। यह आमतौर पर छोटी गाड़ी कोड में परिणाम नहीं करता है।

— टोड गैंबलिन

"एक सही कार्यक्रम को अनुकूलित करना अपेक्षाकृत आसान है, लेकिन एक अनुकूलित कार्यक्रम को ठीक करने के लिए बहुत कठिन है।"

— धीरे

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

— मार्टिन प्रोब्स्ट 12

Answer 2

C # तेज नहीं हो सकता है, लेकिन यह आपको / ME तेज बनाता है। मैं जो करता हूं, उसके लिए यह सबसे महत्वपूर्ण उपाय है। :)

Comments

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

— फालना

1. "C # C ++ की तुलना में बहुत तेज है। 2." यह सच नहीं हो सकता है "1." सुनिश्चित करें कि यह "2." कितना हो सकता है? " 1. "आमतौर पर 3-4 महीने तक"

— दिमित्री एस।

C ++ के लिए जो वास्तव में आपके उपयोग करने वाले पुस्तकालयों पर निर्भर करता है, C # आमतौर पर तेज नहीं है। .NET है, जब आप उत्पादकता की बात कर रहे हैं

— Ion Todirel

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

— चशिर

यह निर्भर करता है कि आप किस चीज के अभ्यस्त हैं। मैं C ++ की तुलना में C # में ज्यादा तेज प्रोग्राम करता हूं। पुस्तकालय ज्ञान उस का एक बड़ा हिस्सा है क्योंकि आप बुनियादी कार्यों के लिए पहिया को फिर से बनाना नहीं चाहते हैं। C / C ++ मुख्य समस्या पॉइंटर प्रबंधन थी जो स्मार्ट पॉइंटर्स के साथ बहुत अधिक हल है। कहा गया है कि C ++ गंभीर में .NET और जावा ऑफ़र के रूप में एक व्यापक पुस्तकालय का अभाव है और यह बड़े पैमाने पर विकास को गति दे सकता है। यह जल्द ही हल होने वाला नहीं है क्योंकि उन एसटीडी लड़के लाइब्रेरी एक्सटेंशन के बजाय टेम्पलेट सुधार पर अपना समय बिताना पसंद करते हैं।

— Gast128

Answer 3

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

Comments

क्या आपको अपने अपमानजनक पाँच संतरे के दावे का समर्थन करने के लिए कोई सबूत मिला है? मेरे सभी प्रयोग अधिकतम रूप से 2 संतरे की ओर इशारा करते हैं, एक 3 आम सुधार के साथ जब टेम्पलेट मेटाप्रोग्रामिंग करते हैं।

— एलेक्स

खमीर पर वह अधिक तेज़ नहीं है, यह अधिक तीव्रता के डी'ओवेरेस के हॉर्स है।

— क्रिस

मेरे अनुभव से यह 5.2 संतरे है। लेकिन यह आपके द्वारा उपयोग किए जाने वाले फल-ओ-मीटर से निर्भर करता है।

— डियो एफ

अपडेट, स्टैकऑवरफ्लो ने खुद को गड़बड़ कर दिया और टिप्पणियों को अक्षम कर दिया, इस प्रकार कम केले (300 केले से भी बदतर होने चाहिए): meta.stackexchange.com/questions/254534/…

— KeksArmod

Answer 4

मैं इस प्रश्न का उत्तर स्‍वीकृत (और अच्‍छे से उत्‍कृष्‍ट) भाग से असहमत होकर शुरू करने जा रहा हूं:

वास्तव में बहुत सारे कारण हैं कि क्यों JITted कोड धीमे अनुकूलित C ++ (या रनटाइम ओवरहेड के बिना अन्य भाषा) प्रोग्राम की तुलना में धीमा चलेगा :

• रनटाइम में JITting कोड पर खर्च की गई गणना चक्र, प्रोग्राम निष्पादन में उपयोग के लिए अनुपलब्ध है।

• JITter में किसी भी गर्म रास्ते को सीपीयू में निर्देश और डेटा कैश के लिए आपके कोड के साथ प्रतिस्पर्धा करनी होगी। हम जानते हैं कि जब प्रदर्शन पर बात आती है तो कैश हावी होता है और सी ++ जैसी देशी भाषाओं में परिभाषा के अनुसार इस प्रकार का विवाद नहीं होता है।

• एक रन-टाइम अनुकूलक के समय बजट जरूरी है बहुत अधिक की तुलना में विवश एक संकलन समय अनुकूलक के (के रूप में एक और टिप्पणीकार ने बताया)

नीचे पंक्ति: अंततः, आप लगभग निश्चित रूप से C # में एक तेज कार्यान्वयन बनाने में सक्षम होंगे , जितना आप C # में कर सकते हैं ।

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

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

-

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

उन बेंचमार्क के साथ समस्या का एक बड़ा हिस्सा यह है कि आप सी ++ कोड नहीं लिख सकते हैं जैसे कि आप सी # लिख रहे थे और परिणाम प्राप्त करने की उम्मीद करते हैं (उदाहरण: सी ++ में हजारों मेमोरी आवंटन प्रदर्शन कर रहे हैं जो आपको भयानक संख्या देने जा रहे हैं।)

इसके बजाय, मैंने थोड़ा और मुहावरेदार सी ++ कोड लिखा और सी # कोड के खिलाफ तुलना की। C ++ कोड में मैंने जो दो बड़े बदलाव किए थे, वे थे:

1) इस्तेमाल किया वेक्टर :: रिजर्व ()

2) बेहतर कैश इलाके (सन्निहित ब्लॉक) को प्राप्त करने के लिए 2d सरणी को 1d पर समतल कर दिया

C # (.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

रन टाइम (रिलीज़): Init: 124ms, भरें: 165ms

C ++ 14 (Clang v3.8 / C2)

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

रन टाइम (रिलीज़): Init: 398 (s (हाँ, यह माइक्रोसेकंड है), भरें: 152ms

कुल रन समय: C #: 289ms, C ++ 152ms (लगभग 90% तेज)

टिप्पणियों

• C # कार्यान्वयन को एक ही 1d सरणी कार्यान्वयन में बदलने से Init: 40ms, Fill: 171ms, कुल: 211ms ( C ++ अभी भी लगभग 40% तेज ) हो गया।

• C ++ में "तेज" कोड को डिजाइन करना और लिखना बहुत कठिन है, क्योंकि यह किसी भी भाषा में "नियमित" कोड लिखना है।

• यह (शायद) C ++ में खराब प्रदर्शन पाने के लिए आश्चर्यजनक रूप से आसान है; हमने देखा कि अनारक्षित वैक्टर प्रदर्शन के साथ। और इस तरह के बहुत सारे नुकसान हैं।

• जब आप रनटाइम पर चल रहे होते हैं, उस पर विचार करने के दौरान C # का प्रदर्शन अद्भुत होता है। और यह प्रदर्शन तुलनात्मक रूप से आसान है।

• C ++ और C # के प्रदर्शन की तुलना करने वाले अधिक महत्वपूर्ण आंकड़े: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

लब्बोलुआब यह है कि C ++ आपको प्रदर्शन पर अधिक नियंत्रण देता है। क्या आप एक सूचक का उपयोग करना चाहते हैं? संदर्भ? स्टैक मेमोरी? ढेर? गतिशील बहुरूपता या स्थैतिक बहुरूपता (टेम्पलेट्स / CRTP के माध्यम से) के साथ एक व्यवहार्य के क्रम ओवरहेड को खत्म करना? C ++ में आपको ... एर, को प्राप्त करना है इन सभी विकल्पों (और अधिक) को स्वयं बनाने के , आदर्श रूप से ताकि आपका समाधान समस्या से निपटने के लिए सबसे अच्छा पता लगाए।

अपने आप से पूछें कि क्या आप वास्तव में चाहते हैं या उस नियंत्रण की आवश्यकता है, क्योंकि ऊपर दिए गए तुच्छ उदाहरण के लिए भी, आप देख सकते हैं कि हालांकि प्रदर्शन में एक महत्वपूर्ण सुधार है, इसे उपयोग करने के लिए एक गहन निवेश की आवश्यकता है।

Comments

@Quonux टिप्पणी के लिए धन्यवाद। बेशक यह "वास्तविक कार्यक्रम" नहीं है। बेंचमार्क का बिंदु रिफ्लेक्टर था एक C # बेंचमार्क इस पृष्ठ पर कहीं और सबूत के रूप में पेश किया गया था कि JITted कोड किसी भी तरह मूल से तेज है - यह नहीं है, और बेंचमार्क संभवतः नए लोगों को भ्रमित कर रहा था।

— U007D

@Quonux आपको ऐसा क्यों लिखना है? यह आप जैसे लोग हैं जो मुझे स्टैकओवरफ्लो नापसंद करते हैं।

— मार्कस कनप्पन जोहानसन

@MarkusKnappenJohansson मेरा एक बुरा दिन था;), मैं सिर्फ एक इंसान हूँ, मैंने अपना पतन हटा दिया, फिर भी मेरी राय अभी भी लागू होती है। ओह कृपया एसओ को नापसंद न करें क्योंकि कुछ "बेवकूफ" लोग हैं :)। एक अच्छा एक है।

— क्वोंक्स

पूरी तरह से लाभ बेंचमार्क। C ++ संस्करण में आप बस मेमोरी का हिस्सा जमा कर रहे हैं (और फिर यह जानकर कि ऑपरेशन को निष्पादित करने के लिए माइक्रोसेकंड कैसे लेता है)। C # संस्करण में आप 5000 ARRAYS (मेमोरी में तात्कालिक वस्तुएं) बना रहे हैं। C ++ C # की तुलना में तेज़ है ... लेकिन अंतर कहीं 40% के पास है ... अभी यह <10% की सीमा में अधिक है। आपका उदाहरण क्या दिखाता है कि प्रोग्रामर को उनकी पसंद की भाषा (और आपकी प्रोफ़ाइल से यह स्पष्ट है कि आप कैरियर C ++ लोनर हैं) से चिपके रहना चाहिए। C # में आप 2D array कर सकते हैं int[,]... उदाहरण के साथ।

— nikib3ro

मैं जो बता सकता हूं, आपके सी ++ उदाहरण में कोड का शाब्दिक रूप से समय से पहले मेमोरी आवंटित करना है। PROPER C # कार्यान्वयन केवल 'सूची <डबल> arrs = नई सूची <डबल> (ROWS * COLS)' लिखेगा, जो 1 आयामी प्रारूप में 2 आयामी सरणी को अनुक्रमित करने के लिए आवश्यक मेमोरी आवंटित करता है (उदाहरण के लिए, आपने C ++ में क्या किया था)। 2-आयामी सरणी आवंटित करने और मैन्युअल रूप से इसे समतल करने के लिए बिल्कुल कोई कारण नहीं है - आपके पूर्व-परीक्षण में पुनरावृत्तियों की भारी मात्रा चमकदार प्रदर्शन का कारण है। मैं कल्पना करता हूं कि ओवरहेड अभी भी सी # में अधिक होगा, लेकिन काफी मात्रा में नहीं।

— JDSweetBeat

Answer 5

मेरे अनुभव में (और मैंने दोनों भाषाओं के साथ बहुत काम किया है), C # की तुलना में C # की मुख्य समस्या उच्च मेमोरी खपत है, और मुझे इसे नियंत्रित करने का एक अच्छा तरीका नहीं मिला है। यह मेमोरी खपत थी जो अंततः .NET सॉफ्टवेयर को धीमा कर देती थी।

एक अन्य कारक यह है कि JIT संकलक उन्नत अनुकूलन करने के लिए बहुत अधिक समय नहीं दे सकता है, क्योंकि यह रनटाइम पर चलता है, और अंतिम उपयोगकर्ता इसे नोटिस करेगा यदि इसमें बहुत अधिक समय लगता है। दूसरी ओर, C ++ कंपाइलर के पास हर समय संकलन समय पर अनुकूलन करने की आवश्यकता होती है। यह कारक मेमोरी खपत, आईएमएचओ की तुलना में बहुत कम महत्वपूर्ण है।

Comments

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

— बोगाटियर

@IngeHenriksen: मैं डिस्पोज़ पैटर्न से अच्छी तरह से वाकिफ हूं, लेकिन यह प्रबंधित मेमोरी के साथ बिल्कुल भी मदद नहीं करता है।

— नेमेनजा ट्रिफ़ुनोविक

@ IngeHenriksen इसे निपटाना केवल यह सुनिश्चित करता है कि डिस्पोज़ विधि को बुलाया गया है। निपटान कभी भी एकत्र की गई स्मृति को मुक्त नहीं करता है। डिस्पोज़ विधि केवल फ़ाइल हैंडल जैसे अप्रबंधित संसाधनों की सफाई के लिए है और इसका स्मृति प्रबंधन से कोई लेना-देना नहीं है।

— doug65536

@NemanjaTrifunovic: "JIT संकलक उन्नत अनुकूलन करने के लिए बहुत अधिक समय नहीं दे सकता है"। क्या आप कुछ ऑप्टिमाइज़ेशन का हवाला दे सकते हैं जो जेआईटी द्वारा नहीं किए गए हैं क्योंकि वे बहुत लंबा समय लेंगे?

— जॉन हैरोप

@ user3800527: भले ही रैम जोड़ना हमेशा संभव था (और यह नहीं है - प्रत्येक एमएस ऑफिस उपयोगकर्ता के लिए रैम जोड़ने की कल्पना करें) जो समस्या को हल नहीं करेगा। मेमोरी पदानुक्रमिक है और एक C # प्रोग्राम में C ++ एक की तुलना में कई अधिक कैश मिस होगा।

— निमन्जा ट्रिफ़ुनोविक

Answer 6

एक विशेष परिदृश्य जहां C ++ में अभी भी ऊपरी हाथ है (और आने वाले वर्षों के लिए), पॉलिमॉर्फिक निर्णय संकलन समय पर पूर्व निर्धारित किया जा सकता है।

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

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

ऐसे मामलों में (और वास्तव में, वे अक्सर विशेष समस्या डोमेन तक ही सीमित रहते हैं), C ++ C # और तुलनीय भाषाओं के खिलाफ जीतता है।

Comments

दरअसल, डायनेमिक डिस्पैच से बचने के लिए जावा वीएम (और शायद .NET) काफी लंबाई तक जाते हैं। मूल रूप से, अगर बहुरूपताओं से बचने का कोई तरीका है, तो आप सुनिश्चित कर सकते हैं कि आपका वीएम ऐसा करेगा।

— मार्टिन प्रोब्स्ट सिप

+1: मुझे हमेशा अपने C # सहयोगियों को यह समझाने में परेशानी होती है जो थोड़ा C ++ जानते हैं जो उन्हें महत्व की सराहना करने में सक्षम बनाता है। आप इसे अच्छी तरह से समझाया है।

— रोमन स्टार्कोव

@ क्रेटी: आप उच्च प्रदर्शन कंप्यूटिंग अनुप्रयोगों के बिना अपनी शर्त बना रहे हैं। मौसम की भविष्यवाणी, जैव सूचना विज्ञान और संख्यात्मक सिमुलेशन पर विचार करें। इन क्षेत्रों में C ++ का प्रदर्शन नेतृत्व सिकुड़ता नहीं है , क्योंकि कोई भी अन्य कोड उच्च अमूर्त के समान स्तर पर तुलनीय प्रदर्शन प्राप्त नहीं कर सकता है।

— कोनराड रुडोल्फ

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

— कोनराड रुडोल्फ

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

— कोनराड रुडोल्फ

Answer 7

सी ++ (या उस मामले के लिए सी) आपको अपने डेटा संरचनाओं पर ठीक-ठीक नियंत्रण देता है। यदि आप बिट-ट्वीडल करना चाहते हैं तो आपके पास वह विकल्प है। बड़े प्रबंधित जावा या .NET एप्लिकेशन (OWB, विजुअल स्टूडियो 2005 ) जो जावा / .NET लाइब्रेरी के आंतरिक डेटा संरचनाओं का उपयोग करते हैं, वे अपने साथ सामान ले जाते हैं। मैंने देखा है कि OWB डिज़ाइनर सेशन 400 MB से अधिक RAM और BIDS का उपयोग करके क्यूब या ETL डिज़ाइन के साथ MB के 100 में मिल रहा है।

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

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

Answer 8

ग्राफिक्स के लिए मानक C # ग्राफिक्स वर्ग CDI / C ++ के माध्यम से एक्सेस किए गए GDI की तुलना में धीमा है। मुझे पता है कि इसका प्रति सेगमेंट के साथ भाषा से कोई लेना-देना नहीं है, कुल .NET प्लेटफ़ॉर्म के साथ अधिक, लेकिन ग्राफिक्स वही है जो डेवलपर को GDI प्रतिस्थापन के रूप में पेश किया जाता है, और इसका प्रदर्शन इतना बुरा है कि मैं ग्राफिक्स करने की हिम्मत भी नहीं करूंगा इसके साथ।

हमारे पास एक सरल बेंचमार्क है जिसका उपयोग हम यह देखने के लिए करते हैं कि ग्राफिक्स लाइब्रेरी कितनी तेज़ है, और वह बस एक विंडो में यादृच्छिक रेखाएँ खींच रही है। C ++ / GDI अभी भी 10000 लाइनों के साथ तेज़ है, जबकि C # / ग्राफ़िक्स को वास्तविक समय में 1000 करने में कठिनाई होती है।

Comments

आपके जवाब से मैं सिहर गया। क्या आपने असुरक्षित कोड और लॉकबिट्स के साथ एक ही बेंचमार्क का परीक्षण किया है, और अपने आप को यादृच्छिक रेखाएं खींच रहे हैं? अब यह देखना दिलचस्प होगा।

— 23

@Pedery नहीं मैं नहीं है। सबसे बुनियादी तरीकों से सिर्फ GDI और .NET.Graphics का उपयोग करना। "यादृच्छिक रेखाएँ अपने आप खींचना" से आपका क्या अभिप्राय है?

— QBziZ

फिर आपको C # कितना तेज़ हो सकता है, इसके लिए अधिक यथार्थवादी मीट्रिक प्राप्त करने के लिए परीक्षण करने पर विचार करना चाहिए। यहाँ तकनीक का एक अच्छा अवलोकन है: bobpowell.net/lockingbits.htm

— Pedery

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

— QBziZ

ठीक है, मुझे सिर्फ एक मामूली विचार है कि बूँद का पता लगाना क्या है, लेकिन सिर्फ एक समय बताते हुए यह सब कुछ साबित नहीं करता है। क्या आपने C ++ में एक लिखा है? जावास्क्रिप्ट में? और सी # में उन लोगों की तुलना में? और इसके अलावा, मुझे नहीं लगता कि बूँद का पता लगाने के लिए कई ग्राफिक्स आदिम का उपयोग किया जाता है। गलत होने पर मुझे सही करें, लेकिन मुझे लगता है कि यह सांख्यिकीय एल्गोरिदम पिक्सेल पर संचालन कर रहा है।

— QBziZ

Answer 9

कचरा संग्रह मुख्य कारण है जावा # CANNOT का उपयोग वास्तविक समय प्रणालियों के लिए किया जाता है।

1. जीसी कब होगा?

2. कितनी देर लगेगी?

यह गैर-निर्धारक है।

Comments

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

— ज़ैन लिंक्स

यदि आप ध्यान दें तो बहुत सारे वास्तविक समय जीसी कार्यान्वयन हैं। (जीसी एक ऐसा क्षेत्र है जो अनुसंधान पत्रों के साथ बह रहा है )

— अराफंगियन

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

— जॉन हेरोप

यह एक बकवास तर्क है, विंडोज (और लिनक्स) रियल टाइम ओएस नहीं हैं। आपका C ++ कोड किसी भी समय 18 एमएस स्लॉट्स के लिए स्वैप किया जा सकता है।

— हेनक होल्टरमैन

@HenkHolterman True, लेकिन आप हमेशा असेंबली में एक बूट-लोडर लिख सकते हैं, अपने अनुप्रयोग के लिए कर्नेल बूटस्ट्रैप में बाँध लें और अपने C ++ एप्लिकेशन को सीधे हार्डवेयर के विरुद्ध निष्पादित करें (RT btw में)। आप C # में ऐसा नहीं कर सकते हैं और मैंने C # में केवल पूर्व-संकलित असेंबली की नकल देखी है और C कोड का एक टन का उपयोग किया है, जो C # का उपयोग करने के लिए इसे कम-बिंदु बनाता है। यह सब पढ़ना थोड़े मज़ेदार है, क्योंकि .NET फ्रेमवर्क के बिना C # वास्तव में बेकार है।

— zackery.fix

Answer 10

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

Comments

C ++ में, आपके पास विभिन्न आवंटन विधियों का उपयोग करने का विकल्प है, इसलिए C # में मेमोरी कैसे आवंटित की गई (AOT?) के आधार पर, यह C ++ में उसी तरह (लेकिन बहुत तेजी से) किया जा सकता है।

— zackery.fix

@ zackery.fix .NET को ढेर आवंटन में एक दिलचस्प बढ़त है, क्योंकि इसे केवल एक नई वस्तु आवंटित करने के लिए एक संकेतक को स्थानांतरित करना है। यह केवल कॉम्पैक्ट कचरा कलेक्टर के कारण संभव है। बेशक आप सी ++ में एक ही काम कर सकते हैं, लेकिन सी ++ ऐसा नहीं करता है। यह हास्यास्पद है कि आप "C # कह सकते हैं, लेकिन ऐसा नहीं है, इसलिए यह कचरा है" और "C ++ नहीं करता है" कहने के लिए एक ही तर्क का उपयोग करते हैं, लेकिन यह भयानक है, इसलिए :)

— Luaan

Answer 11

हमेशा की तरह, यह आवेदन पर निर्भर करता है। ऐसे मामले हैं जहां C # शायद लापरवाही से धीमा है, और अन्य मामले जहां C ++ 5 या 10 गुना तेज है, खासकर उन मामलों में जहां ऑपरेशन आसानी से SIMD'd किए जा सकते हैं।

Comments

वीएम के लिए सबसे अच्छा मामला उत्पन्न कोड का रन-टाइम संकलन होगा (उदाहरण के लिए रन टाइम में पढ़ने के लिए एक नियमित अभिव्यक्ति से मेल खाने के लिए) क्योंकि स्टेटिक रूप से संकलित वेनिला सी ++ प्रोग्राम केवल व्याख्या का उपयोग कर सकते हैं क्योंकि उनके पास एक जेआईटी कंपाइलर नहीं है

— जॉन हैरोप।

भविष्य से ध्यान दें: .NET में लगभग 2014 से SIMD और दोस्तों के लिए समर्थन है, हालांकि इसका व्यापक रूप से उपयोग नहीं किया जाता है।

— लुआं

Answer 12

मुझे पता है कि यह वह नहीं है जो आप पूछ रहे थे, लेकिन C # अक्सर C ++ की तुलना में लिखने में तेज होता है, जो एक व्यावसायिक सेटिंग में एक बड़ा बोनस है।

Comments

मैं कहता हूँ कि यह ज्यादातर समय जल्दी है :)

— ट्रैप

Answer 13

C / C ++ उन कार्यक्रमों में बहुत बेहतर प्रदर्शन कर सकता है, जहाँ या तो बड़े सरणियाँ हैं या सरणियों (किसी भी आकार के) पर भारी लूपिंग / चलना है। यही कारण है कि ग्राफिक्स आमतौर पर C / C ++ में बहुत तेजी से होते हैं, क्योंकि भारी सरणी ऑपरेशन लगभग सभी ग्राफिक्स ऑपरेशन करते हैं। सभी सुरक्षा जाँचों के कारण सरणी अनुक्रमण संचालन में .NET बहुत ही धीमी गति से होता है, और यह बहु-आयामी सरणियों के लिए विशेष रूप से सच है (और, हाँ, आयताकार C # सरणियाँ दांतेदार C # सरणियों से भी धीमी हैं)।

C / C ++ का बोनस सबसे अधिक स्पष्ट है यदि आप सीधे पॉइंटर्स से चिपकते हैं और बूस्ट, std::vectorऔर अन्य उच्च-स्तरीय कंटेनरों से बचते हैं , साथ ही साथ inlineहर छोटे कार्य को भी संभव करते हैं। जब भी संभव हो पुराने स्कूल के सरणियों का उपयोग करें। हां, आपको उच्च-स्तरीय कंटेनरों से बचने के लिए जावा या सी # में किए गए समान काम को पूरा करने के लिए कोड की अधिक लाइनों की आवश्यकता होगी। यदि आपको गतिशील रूप से आकार की सरणी की आवश्यकता है, तो आपको अपने विवरण को new T[]इसी delete[]कथन (या उपयोग) के साथ याद रखना होगाstd::unique_ptr) - अतिरिक्त गति के लिए मूल्य यह है कि आपको अधिक सावधानी से कोड करना चाहिए। लेकिन बदले में, आप अपने आप को प्रबंधित मेमोरी / कचरा संग्रहकर्ता के ओवरहेड से छुटकारा दिलाते हैं, जो आसानी से जावा और .NET दोनों में भारी वस्तु-उन्मुख कार्यक्रमों के निष्पादन का समय 20% या उससे अधिक हो सकता है, साथ ही साथ बड़े पैमाने पर प्रबंधित भी। स्मृति सरणी अनुक्रमण लागत। C ++ ऐप्स कुछ विशिष्ट मामलों में कुछ निफ्टी कंपाइलर स्विच से भी लाभ उठा सकते हैं।

मैं सी, सी ++, जावा और सी # में एक विशेषज्ञ प्रोग्रामर हूं। मेरे पास हाल ही में 3 भाषाओं में सटीक एल्गोरिथम कार्यक्रम को लागू करने का दुर्लभ अवसर था। कार्यक्रम में बहुत सारे गणित और बहुआयामी सरणी संचालन थे। मैंने सभी 3 भाषाओं में इसका भारी अनुकूलन किया। परिणाम सामान्य रूप से कम कठोर तुलनाओं में मुझे दिखाई देते हैं: जावा सी # की तुलना में लगभग 1.3 गुना तेज था (ज्यादातर जेवीएम सीएलआर से अधिक अनुकूलित हैं), और सी ++ कच्चा सूचक संस्करण सी # की तुलना में लगभग 2.1x तेज आया। ध्यान दें कि C # प्रोग्राम ने केवल सुरक्षित कोड का उपयोग किया है - यह मेरी राय है कि आप unsafeकीवर्ड का उपयोग करने से पहले इसे C ++ में भी कोड कर सकते हैं।

किसी को भी लगता है कि मेरे पास C # के खिलाफ कुछ है, मैं यह कहकर बंद कर दूंगा कि C # शायद मेरी पसंदीदा भाषा है। यह अब तक का सामना करना पड़ा सबसे तार्किक, सहज और तेजी से विकास की भाषा है। मैं अपने सभी प्रोटोटाइप C # में करता हूं। C # भाषा के जावा पर कई छोटे, सूक्ष्म फायदे हैं (हाँ, मुझे पता है कि Microsoft को देर से और यकीनन जावा की नकल करके खेल में जावा की कमियों को ठीक करने का मौका मिला था)। जावा के Calendarवर्ग के लिए कोई टोस्ट ? यदि Microsoft कभी CLR और .NET JITTER को अनुकूलित करने के लिए वास्तविक प्रयास करता है, तो C # गंभीरता से ले सकता है। मुझे ईमानदारी से आश्चर्य है कि वे पहले से ही नहीं हैं - उन्होंने सी # भाषा में बहुत सारी चीजें ठीक से कीं, क्यों नहीं इसका पालन भारी-भरकम कॉम्पिटिशन यूटिलिटीज के साथ किया गया? शायद अगर हम सब भीख माँगते हैं।

Comments

"आपको बस अपनी जोड़ी new T[]को एक संगत के साथ याद रखना होगा delete[]" - नहीं आप नहीं। नहीं है std::unique_ptrक्या करना है कि आप के लिए।

— इमलाई

यह मानते हुए कि आपने ग्राफिक्स में कुछ लिखा क्यों # में सुरक्षित कोड लिखा है, क्या आपने असुरक्षित कोड का उपयोग करने और फिर से तुलना करने पर विचार किया है?

— user3800527 6

Answer 14

> मैंने जो सुना है उससे ...

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

आप यह कैसे तय करने जा रहे हैं कि लोग जो बातें यहाँ कहते हैं, वे मूल रूप से सुनी-सुनाई बातों से कम या ज्यादा विश्वसनीय हैं?

इसका एक तरीका सबूत माँगना होगा ।

जब कोई दावा करता है कि "कुछ ऐसे क्षेत्र हैं जिनमें C # C ++ की तुलना में अधिक तेज़ साबित होता है" तो उनसे पूछें कि वे ऐसा क्यों कहते हैं , उन्हें आपको माप दिखाने के लिए कहें, उन्हें आपसे कार्यक्रम दिखाने के लिए कहें। कभी-कभी उन्होंने बस गलती की होगी। कभी-कभी आपको पता चलेगा कि वे कुछ साझा करने के बजाय केवल एक राय व्यक्त कर रहे हैं जो वे सच होने के लिए दिखा सकते हैं।

अक्सर सूचना और राय को लोगों में मिलाया जाएगा जो दावा करते हैं, और आपको कोशिश करनी होगी और यह पता लगाना होगा कि कौन सा है। उदाहरण के लिए, इस मंच के उत्तरों से:

• " संदेह के एक बड़े सौदे के साथ http://shootout.alioth.debian.org/ पर मानदंड लें , क्योंकि ये बड़े पैमाने पर अंकगणित कोड का परीक्षण करते हैं, जो संभवतः आपके कोड के समान नहीं है।"

  अपने आप से पूछें कि क्या आप वास्तव में समझते हैं कि "ये काफी हद तक अंकगणित कोड का अर्थ क्या है " , और फिर अपने आप से पूछें कि क्या लेखक ने वास्तव में आपको दिखाया है कि उसका दावा सही है।

• "यह एक बेकार परीक्षा है, क्योंकि यह वास्तव में इस बात पर निर्भर करता है कि व्यक्तिगत कार्यक्रमों को कितनी अच्छी तरह से अनुकूलित किया गया है; मैंने उनमें से कुछ को 4-6 गुना या उससे अधिक गति देने में कामयाब रहा है, जिससे यह स्पष्ट हो जाता है कि अयोग्य कार्यक्रमों की तुलना नहीं है मूर्ख। "

  अपने आप से पूछें कि क्या लेखक ने वास्तव में आपको दिखाया है कि वह "उनमें से कुछ को 4-6 बार या अधिक गति से प्रबंधित करने में कामयाब रहा है" - यह एक आसान दावा है!

Comments

मैं आपके साथ अधिक सहमत नहीं हो सका और यही कारण है कि मैंने इस मंच में पूछा ... आखिरकार, जवाब कहीं होना चाहिए, क्या वे नहीं हैं? :)

— ट्रेप

हाँ। उत्तर है, यह निर्भर करता है।"।

— user49117

Answer 15

C ++ पर Intel TBB और OpenMP का उपयोग करते समय 'शर्मनाक समानांतर' समस्याओं के लिए, मैंने C # और TPL के साथ की गई समान (शुद्ध गणित) समस्याओं की तुलना में लगभग 10x प्रदर्शन वृद्धि देखी है। SIMD एक ऐसा क्षेत्र है जहां C # प्रतिस्पर्धा नहीं कर सकता है, लेकिन मुझे यह भी आभास हो गया कि TPL का एक बड़ा ओवरहेड है।

उस ने कहा, मैं केवल C ++ का उपयोग प्रदर्शन-महत्वपूर्ण कार्यों के लिए करता हूं, जहां मुझे पता है कि मैं गुणा करने और जल्दी परिणाम प्राप्त करने में सक्षम होगा। बाकी सब चीज़ों के लिए, C # (और कभी-कभी F #) ठीक है।

Answer 16

यह वास्तविक निश्चित उत्तरों के बिना एक अत्यंत अस्पष्ट प्रश्न है।

उदाहरण के लिए; मैं बजाय C # की तुलना में C ++ में बनाए गए 3D गेम खेलता हूं, क्योंकि प्रदर्शन निश्चित रूप से बहुत बेहतर है। (और मैं एक्सएनए, आदि को जानता हूं, लेकिन यह वास्तविक चीज के पास कोई रास्ता नहीं है)।

दूसरी ओर, जैसा कि पहले उल्लेख किया गया है; आपको एक ऐसी भाषा विकसित करनी चाहिए जो आपको वह काम करने की अनुमति दे जो आप जल्दी चाहते हैं, और फिर यदि आवश्यक हो तो अनुकूलन करें।

Comments

क्या आप कुछ उदाहरण बता सकते हैं? C # में लिखे गए खेल जो आपको धीमी गति से मिले

— कार्ल

यहां तक ​​कि इंस्टॉलेशन के साथ आने वाले उदाहरण एप्लिकेशन को धीमा महसूस हुआ।

— डेविड द मैन

कचरा कलेक्टर सी # के साथ गेम बनाने में एक बड़ी देनदारी है, क्योंकि यह किसी भी समय किक कर सकता है, जिससे प्रमुख रुकावट हो सकती है। स्पष्ट स्मृति प्रबंधन खेल के विकास के लिए आसान हो रहा है।

— पोस्टफुटुरिस्ट

अधिकांश आधुनिक गेम GPU-limited हैं। ऐसे खेलों के लिए यह कोई फर्क नहीं पड़ता कि तर्क (सीपीयू पर निष्पादित) 10% धीमा है, वे अभी भी सीपीयू द्वारा सीमित हैं, सीपीयू द्वारा नहीं। कचरा संग्रहकर्ता एक वास्तविक समस्या है, जिससे यदि स्मृति आबंटनों को अच्छी तरह से ट्यून नहीं किया जाता है, तो रैंडम शॉर्ट फ्रीज़ हो जाते हैं।

— माइकल एन्टिन

@ पॉस्टफुटुरिस्ट: पीसी पर यह सच नहीं है; कचरा इकट्ठा करने वाला ऐसा अच्छा काम करता है, जिसमें मुझे कभी भी कोई परेशानी नहीं हुई। हालांकि, XBox 360 और Zune / विंडोज -7 फोन पर, कचरा कलेक्टर नहीं है लगभग पीसी पर के रूप में स्मार्ट के रूप में; मैंने कभी भी नहीं लिखा है, लेकिन जिन लोगों ने मुझे बताया है कि कचरा कलेक्टर एक बहुत बड़ी समस्या है।

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

Answer 17

.NET भाषाएँ C ++ कोड जितनी तेज़ या इससे भी तेज़ हो सकती हैं, लेकिन C ++ कोड में अधिक स्थिर प्रवाह होगा क्योंकि .NET रनटाइम को GC के लिए रोकना पड़ता है , भले ही वह अपने पॉज़ के बारे में बहुत चालाक हो।

इसलिए यदि आपके पास कुछ कोड है जो बिना किसी ठहराव के लगातार तेजी से चलना है, तो .NET विलंबता का परिचय देगा कुछ बिंदु पर , भले ही आप रनटाइम GC के साथ बहुत सावधान रहें।

Comments

-1: यह वास्तव में एक मिथक है। सबसे पहले, मुहावरेदार सी ++ की विलंबता वास्तव में भयानक और अक्सर .NET की तुलना में बहुत खराब होती है क्योंकि RAII विनाशकारी के हिमस्खलन का कारण बनता है जब बड़ी डेटा संरचनाएं दायरे से बाहर हो जाती हैं, जबकि आधुनिक जीसी वृद्धिशील हैं और .NET का समवर्ती है। दूसरे, आप वास्तव में जीसी पॉज़ को पूरी तरह से हटा सकते हैं। आवंटन न करके।

— जॉन हैरोप

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

— फ्लोरियन डॉयोन

यह काफी सच है, यह .net 4 तक नहीं था कि GC को वृद्धिशील बनाया गया था। हमारे पास एक बड़ा C # ऐप है जो GC के लिए एक समय में सेकंड के लिए रुकता है। प्रदर्शन महत्वपूर्ण ऐप्स के लिए यह एक हत्यारा है।

— जस्टिन

एक कारण है कि प्रोग्राम जो हार्डवेयर पुश करने के लिए C ++ का उपयोग करते हैं। जब आपको इसकी आवश्यकता होती है तो आपके पास अधिक महीन ट्यून नियंत्रण होता है। प्रदर्शन केवल कुंजी है जब आप सिस्टम को धक्का दे रहे हैं, अन्यथा समय बचाने के लिए C # या Java का उपयोग करें।

— वोरोनोई पोपटो

यदि आप कैश व्यवहार का प्रबंधन नहीं कर सकते हैं, तो आप अनुकूलित c ++ कोड को हरा नहीं सकते हैं। L1 से मुख्य मेमोरी तक कैश मिस आपके ऑपरेशन को 100 गुना धीमा कर सकता है।

— DAG

Answer 18

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

मुझे संदेह है कि यह .NET या किसी भी JRE द्वारा किया गया है, लेकिन जब मैं विश्वविद्यालय में था, तो इस पर वापस शोध किया जा रहा था, इसलिए यह सोचना अनुचित नहीं है कि इस प्रकार की चीजें कुछ समय में वास्तविक दुनिया में अपना रास्ता तलाश सकती हैं। ।

Answer 19

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

Answer 20

मैंने vectorC ++ और C # समकक्ष में परीक्षण किया है -List और सरल 2d सरणियों ।

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

मैं Intel Core2Duo P8600@2.4GHz, C # - .NET 4.0 का उपयोग कर रहा हूं।

मुझे पता है कि वेक्टर कार्यान्वयन सी # सूची से अलग है, लेकिन मैं सिर्फ उन संग्रह का परीक्षण करना चाहता था जो मैं अपनी वस्तुओं को संग्रहीत करने के लिए उपयोग करूंगा (और इंडेक्स एक्सेसर का उपयोग करने में सक्षम हूं)।

बेशक आपको मेमोरी साफ़ करने की ज़रूरत है (चलो हर उपयोग के लिए कहें new), लेकिन मैं कोड को सरल रखना चाहता था।

सी ++ वेक्टर परीक्षण :

static void TestVector()
{
    clock_t start,finish;
    start=clock();
    vector<vector<double>> myList=vector<vector<double>>();
    int i=0;
    for( i=0; i<500; i++)
    {
        myList.push_back(vector<double>());
        for(int j=0;j<50000;j++)
            myList[i].push_back(j+i);
    }
    finish=clock();
    cout<<(finish-start)<<endl;
    cout<<(double(finish - start)/CLOCKS_PER_SEC);
}

C # सूची परीक्षण:

private static void TestVector()
{

    DateTime t1 = System.DateTime.Now;
    List<List<double>> myList = new List<List<double>>();
    int i = 0;
    for (i = 0; i < 500; i++)
    {
        myList.Add(new List<double>());
        for (int j = 0; j < 50000; j++)
            myList[i].Add(j *i);
    }
    DateTime t2 = System.DateTime.Now;
    Console.WriteLine(t2 - t1);
}

सी ++ - सरणी:

static void TestArray()
{
    cout << "Normal array test:" << endl;
    const int rows = 5000;
    const int columns = 9000;
    clock_t start, finish;

    start = clock();
    double** arr = new double*[rows];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    finish = clock();

    cout << (finish - start) << endl;

    start = clock();
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    finish = clock();

    cout << (finish - start) << endl;
}

सी # - सरणी:

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

}

समय: (रिलीज / डिबग)

सी ++

• 600/606 एमएस सरणी init,
• 200/270 एमएस सरणी भरें,
• 1sec / 13sec वेक्टर इनिट और भरें।

(हां, 13 सेकंड, मुझे हमेशा डिबग मोड में सूची / वैक्टर के साथ समस्याएं हैं।)

सी#:

• 20/20 एमएस सरणी init,
• 403/440 एमएस सरणी भरें,
• 710/742 एमएस सूची init और भरें।

Comments

मैं इंडेक्स एक्सेसर को std :: सूची में देखना पसंद करूंगा। वैसे भी, यह सूची, रिलीज मोड के साथ 37 सेकंड लेता है। डिबगिंग के बिना रिलीज़: 3 एस सूची, 0,3 एस वेक्टर। शायद dereferencing मुद्दा या sth। नमूना: nopaste.pl/12fb

— वरी

अधिक सटीक माप के लिए आपको उपयोग नहीं करना चाहिए System.DateTime.Now, बल्कि स्टॉपवॉच वर्ग।

— सैम

जिस कारण से आपको C ++ में वेक्टर के लिए इतनी धीमी गति से भरने का समय मिल रहा है, क्या आप push_back का उपयोग कर रहे हैं। इस विधि या ऑपरेटर [] का उपयोग करने की तुलना में धीमी होने के लिए कई पदों पर दिखाया गया है। उन तरीकों में से किसी एक का उपयोग करने के लिए आपको आकार बदलने या आरक्षित पद्धति का उपयोग करने की आवश्यकता है। इसके अतिरिक्त, आपके आरंभीकरण का कारण c ++ वेक्टर केस के लिए इतना लंबा समय ले रहा है कि आप अपने c ++ वेक्टर को इनिशियलाइज़ करने के लिए एक कॉपी या असाइनमेंट ऑपरेटर [जो इस मामले में निश्चित नहीं है) को मजबूर कर रहे हैं। C ++ में सरणी के लिए एक एल्गोरिथ्म है जो 5001 के बजाय 2 नई कॉल का उपयोग करता है और साथ ही तेजी से पुनरावृत्ति करता है।

— ज़चारी क्रूस

मुझे लगता है कि आपने उचित तरीके से c ++ नहीं किया। बस एक नज़र और इतने सारे मुद्दे मिल गए। ईजी वेक्टर <वेक्टर <डबल> myList = वेक्टर <वेक्टर <डबल >> ()

— डीएजी

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

— U007D 20

Answer 21

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

तो यह सैद्धांतिक रूप से संभव है (अन्य जीसी भाषाओं के लिए भी)।

मैं वास्तव में सबसे अनुप्रयोगों के लिए C # के साथ मेटाप्रोग्रामिंग का उपयोग करने में सक्षम नहीं होने के चरम नुकसान को नहीं देखता , क्योंकि अधिकांश प्रोग्रामर वैसे भी इसका उपयोग नहीं करते हैं।

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

Comments

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

— क्लीयर

देवताओं के प्यार के लिए, यह 8 साल पुराना है, OMFGz

— Quonux

बेझिझक जवाब देने के लिए और अधिक बेहतर देने के लिए

— बेझिझक

Answer 22

मुझे लगता है कि C # तेजी से चलने वाले एप्लिकेशन में लिखे गए हैं, साथ ही साथ और भी C ++ लिखित ऐप्स हैं जो तेजी से चल रहे हैं (अच्छी तरह से C ++ सिर्फ पुराने ... और UNIX भी लें ...)
- प्रश्न वास्तव में है - वह चीज क्या है, उपयोगकर्ता और डेवलपर्स के बारे में शिकायत कर रहे हैं ...
ठीक है, IMHO, C # के मामले में हमारे पास बहुत आराम यूआई है, पुस्तकालयों का बहुत अच्छा पदानुक्रम, और सीएलआई का संपूर्ण इंटरफ़ेस सिस्टम। C ++ के मामले में हमारे पास टेम्प्लेट, ATL, COM, MFC और पहले से ही लिखित और रनिंग कोड जैसे OpenGL, DirectX इत्यादि के पूरे शेबंग हैं ... डेवलपर्स C # के मामले में जीसी कॉल को अनिश्चित रूप से बढ़ाकर शिकायत करते हैं (मतलब प्रोग्राम तेजी से चलता है, और) एक सेकंड में - बैंग (यह अटक गया है)।
C # में कोड लिखना बहुत ही सरल और तेज़ है (यह भी भूल जाना कि त्रुटियों की संभावना बढ़ जाती है। C ++ के मामले में, डेवलपर्स मेमोरी लीक की शिकायत करते हैं, - इसका अर्थ है क्रश, डीएलएल के बीच कॉल, साथ ही साथ "डीएलएल नरक" - समस्या) नए लोगों द्वारा समर्थन और प्रतिस्थापन पुस्तकालयों ...
मुझे लगता है कि प्रोग्रामिंग भाषा में आपके पास अधिक कौशल होगा, अधिक गुणवत्ता (और गति) आपके सॉफ़्टवेयर की विशेषता होगी।

Answer 23

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

Comments

नॉट कोडेड माइनक्राफ्ट को उस डेटा की मात्रा को देखते हुए बहुत तेज़ होना चाहिए, जिसमें वह हेरफेर कर रहा है। इसके अलावा, उन्होंने इसे ज्यादातर अकेले-कम समय की तुलना में कम-से-कम कोडित किया, कुछ ऐसा जो C ++ में लगभग असंभव होता। मैं हालांकि अनुकूलन तकनीकों से सहमत हूं - अगर आपके पास खर्च करने के लिए अतिरिक्त 10x देव समय है तो आपका कोड दो बार तेजी से चलता है, शायद यह इसके लायक है।

— बिल के

Answer 24

यदि मैं गलत नहीं हूँ, तो C # टेम्प्लेट रनटाइम पर निर्धारित किए जाते हैं। यह C ++ के संकलित समय टेम्पलेट्स की तुलना में धीमा होना चाहिए।

और जब आप इतने सारे अन्य लोगों द्वारा उल्लेखित अन्य सभी संकलन-समय के अनुकूलन में लेते हैं, साथ ही साथ सुरक्षा की कमी है, जो वास्तव में अधिक गति का मतलब है ...

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

फैसले:

• सी #: तेज़ विकास, धीमी गति से चलना

• C ++: धीमी गति से विकास, तेजी से चलता है।

Answer 25

यह वास्तव में इस बात पर निर्भर करता है कि आप अपने कोड में क्या हासिल करना चाहते हैं। मैंने सुना है कि यह शहरी किंवदंती का सामान है कि VB.NET, C # और प्रबंधित C ++ के बीच कोई प्रदर्शन अंतर है। हालाँकि, मैंने पाया है कि कम से कम स्ट्रिंग तुलना में, प्रबंधित C ++ ने C # की पैंट को हरा दिया, जो बदले में पैंट को VB.NET से दूर कर देता है।

मैंने भाषाओं के बीच एल्गोरिथम जटिलता में किसी भी तुलनात्मक तुलना नहीं की है। मैं भी प्रत्येक भाषा में डिफ़ॉल्ट सेटिंग्स का उपयोग कर रहा हूं। VB.NET में, मैं चर की घोषणा की आवश्यकता के लिए सेटिंग्स का उपयोग कर रहा हूं, आदि। यहां मैं प्रबंधित C ++ का उपयोग कर रहा कोड है: (जैसा कि आप देख सकते हैं, यह कोड काफी सरल है)। मैं .NET Studio.2 के साथ Visual Studio 2013 में अन्य भाषाओं में समान चला रहा हूँ।

#include "stdafx.h"

using namespace System;
using namespace System::Diagnostics;

bool EqualMe(String^ first, String^ second)
{
    return first->Equals(second);
}
int main(array<String ^> ^args)
{
    Stopwatch^ sw = gcnew Stopwatch();
    sw->Start();
    for (int i = 0; i < 100000; i++)
    {
        EqualMe(L"one", L"two");
    }
    sw->Stop();
    Console::WriteLine(sw->ElapsedTicks);
    return 0;
}

Answer 26

प्रदर्शन पहलू पर C # और C ++ के बीच कुछ प्रमुख अंतर हैं:

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

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

Answer 27

> आखिर, जवाब कहीं तो होना ही है न? :)

उम्म, नहीं।

जैसा कि कई उत्तरों में उल्लेख किया गया है, प्रश्न को उन तरीकों से निर्दिष्ट किया गया है जो उत्तर में प्रश्न आमंत्रित करते हैं, उत्तर नहीं। सिर्फ एक ही रास्ता लेने के लिए:

• यह प्रश्न भाषा के कार्यान्वयन के साथ भाषा को बताता है - यह C प्रोग्राम इस C # प्रोग्राम की तुलना में 2,194 गुना धीमा और 1.17 गुना तेज है - हमें आपसे यह पूछना होगा: कौन सी भाषा कार्यान्वयन?

और फिर कौन से कार्यक्रम? कौन सी मशीन? कौन सा ओएस? कौन सा डेटा सेट करें?

Comments

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

— मुझे स्टीव

@ कोल्लमवेव: मुझे पता है कि आपका क्या मतलब है, लेकिन आपके आखिरी वाक्य को चाक बोर्ड पर नाखून से किसी भी प्रोग्रामर की तरह बजना चाहिए।

— राउटर वैन निफ्टरिक

यह प्रश्न का उत्तर देने के लिए प्रकट नहीं होता है, और टिप्पणी या शेख़ी के रूप में अधिक पढ़ता है।

— तस

Answer 28

इससे प्रेरित होकर, मैंने अधिकांश कार्यक्रमों में आवश्यक 60 प्रतिशत सामान्य निर्देशों के साथ एक त्वरित परीक्षण किया।

यहाँ C # कोड है:

for (int i=0; i<1000; i++)
{
    StreamReader str = new StreamReader("file.csv");
    StreamWriter stw = new StreamWriter("examp.csv");
    string strL = "";
    while((strL = str.ReadLine()) != null)
    {
        ArrayList al = new ArrayList();
        string[] strline = strL.Split(',');
        al.AddRange(strline);
        foreach(string str1 in strline)
        {
            stw.Write(str1 + ",");
        }
        stw.Write("\n");
    }
    str.Close();
    stw.Close();
}

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

यहाँ c ++ कोड है:

for (int i = 0; i<1000; i++)
{
    std::fstream file("file.csv", ios::in);
    if (!file.is_open())
    {
        std::cout << "File not found!\n";
        return 1;
    }

    ofstream myfile;
    myfile.open ("example.txt");
    std::string csvLine;

    while (std::getline(file, csvLine))
    {
        std::istringstream csvStream(csvLine);
        std::vector csvColumn;
        std::string csvElement;

        while( std::getline(csvStream, csvElement, ‘,’) )
        {
            csvColumn.push_back(csvElement);
        }

        for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
        {
            myfile << *j << ", ";
        }

        csvColumn.clear();
        csvElement.clear();
        csvLine.clear();
        myfile << "\n";
    }
    myfile.close();
    file.close();
}

मेरे द्वारा उपयोग किए जाने वाले इनपुट फ़ाइल का आकार 40 KB था।

और यहाँ परिणाम है -

• 9 सेकंड में C ++ कोड चला।
• सी # कोड: 4 सेकंड !!!

ओह, लेकिन यह लिनक्स पर था ... सी # के साथ मोनो पर चल रहा है ... और जी ++ के साथ सी ++।

ठीक है, यह वही है जो मुझे विंडोज पर मिला है - विजुअल स्टूडियो 2003 :

• 9 सेकंड में C # कोड चला।
• सी ++ कोड - भयानक 370 सेकंड !!!

Comments

आप वहां विभिन्न डेटा संरचनाओं और लाइब्रेरी कोड का उपयोग कर रहे हैं, हालांकि "370 सेकंड" कुछ भयानक संकेत देता है - आप इसे डिबगर में नहीं चला रहे हैं किसी भी मौका से आप हैं? मुझे संदेह है कि जिस CSV लाइब्रेरी का आप उपयोग कर रहे हैं, उसका प्रदर्शन उस भाषा के प्रदर्शन से अधिक दिलचस्प है जिसका आप उपयोग कर रहे हैं। मैं उस संदर्भ में एक वेक्टर के उपयोग पर सवाल उठाऊंगा, और आपने क्या अनुकूलन किए। इसके अतिरिक्त, यह व्यापक रूप से ज्ञात है कि iostreams (विशेष रूप से, "myfile << * j <<", ";") कम से कम कुछ सामान्य कार्यान्वयन के लिए, फ़ाइल में लिखने के अन्य तरीकों की तुलना में बहुत धीमा है।

— अराफांगियन

अंत में, आप C ++ संस्करण में अधिक काम कर रहे हैं। (आप csvColumn, csvElement और csvLines को क्यों साफ़ कर रहे हैं?)

— अराफंगियन

लूप का हर पुनरावृत्ति एक std :: istream और एक std :: वेक्टर और एक std :: string को नष्ट और पुनर्निर्माण करने वाला है। जबकि शरीर हर पुनरावृत्ति के दायरे से बाहर चला जाता है, जबकि उस दायरे के अंदर वे सभी चर हर पुनरावृत्ति पर विनाश और निर्माण करने जा रहे हैं।

— doug65536

आपके c ++ कोड को पढ़ने के नज़रिए से आप एक फ़ाइल से दूसरी फ़ाइल में कॉपी करने का प्रयास कर रहे हैं। फ़ाइल स्ट्रीम, स्ट्रिंग्स, वैक्टर और स्ट्रिंग स्ट्रीम के बीच जटिल इंटरैक्शन का उपयोग करने के बजाय, आप इनपुट फ़ाइल स्ट्रीम को आउटपुट फ़ाइल स्ट्रीम में कॉपी कर सकते हैं। इससे बहुत समय और स्मृति बच जाती।

— ज़ाचरी क्रुस

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

— user3800527 6