garbage collection - कचरा कलेक्टर के बिना डी प्रोग्रामिंग




garbage-collection d (4)

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

यहां से एक प्रश्न के मुताबिक मेरी अपनी सामान्य परीक्षाएं बताती हैं कि जीसी बहुत धीमी गति से है सीधा सी ++ की तुलना में 10 गुना से अधिक धीमी गति से (जाहिर है, यह परीक्षण सीधे वास्तविक दुनिया में परिवर्तित नहीं करता है, लेकिन प्रदर्शन हिट चरम है और वास्तविक दुनिया को धीमा कर देगी जो ऐसा ही व्यवहार करती है (बहुत छोटी वस्तुओं को जल्दी से आवंटित करते हैं)

मैं एक वास्तविक समय कम विलंबता ऑडियो अनुप्रयोग लिखने में देख रहा हूं और यह संभव है कि जीसी एप्लिकेशन के प्रदर्शन को बर्बाद कर देगा, जिससे यह लगभग बेकार हो जाएगा। एक मायने में, अगर इसमें कोई समस्या है तो यह वास्तविक समय ऑडियो पहलू को नष्ट कर देगा, जो कि ग्राफिक्स के विपरीत, बहुत अधिक फ्रेम दर (44000 + vs 30-60) पर चलता है। (इसकी कम विलंबता के कारण यह एक मानक ऑडियो प्लेयर से ज्यादा महत्वपूर्ण है जो महत्वपूर्ण मात्रा में डेटा बफर कर सकता है)

जीसी को अक्षम करने से परिणामों को सी + + कोड के लगभग 20% के भीतर सुधार हुआ। यह महत्वपूर्ण है मैं विश्लेषण के अंत में कोड दे दूँगा।

मेरे प्रश्न हैं:

  1. एक मानक स्मार्ट पॉइंटर्स कार्यान्वयन के साथ डी'स जीसी को बदलने में कितना मुश्किल है ताकि जीसी पर निर्भर पुस्तकालयों का उपयोग किया जा सके। अगर मैं जीसी को पूरी तरह से निकालता हूं तो मुझे बहुत काम करना पड़ेगा, क्योंकि सी के सी तुलना में डी के पास पहले से ही सीमित पुस्तकालय हैं।
  2. क्या जीसी होता है। केवल अस्थायी रूप से कचरा संग्रहण को रोकने के लिए (जीसी थ्रेड को चलने से रोकना) और जीसी को बंद कर दिया जाता है। जहां यह छोड़ा गया था वहां वापस लेने में सक्षम करें। इसलिए मैं विलंबता के मुद्दे को रोकने के लिए जीसी से उच्च सीपीयू उपयोग क्षणों में चलने से संभावित रूप से अक्षम कर सकता हूं।
  3. जीसी को लगातार उपयोग न करने के लिए एक पैटर्न लागू करने का कोई तरीका क्या है? (यह इसलिए है क्योंकि मैंने डी में प्रोग्रामिंग नहीं की है और जब मैं अपने चश्मा लिखना शुरू कर देता हूं जो जीसी का उपयोग नहीं करते हैं, तो मैं यह सुनिश्चित करना चाहूंगा कि मैं अपनी सफाई को लागू करने के लिए न भूलूं
  4. क्या डीसी आसानी से डीसी में बदल सकता है? (ऐसा नहीं है कि मैं चाहता हूँ, लेकिन जीसी के एक दिन के विभिन्न तरीकों के साथ खेलने के लिए मजेदार हो सकता है ... यह 1 जैसा है)

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

मुझे स्मृति की कमी के बारे में ज्यादा चिंता नहीं है मैं गति पर स्मृति "अपशिष्ट" को पसंद करता हूं (एक बिंदु तक, बिल्कुल)। सबसे पहले और विलंबता के मुद्दे हैं

मैंने जो पढ़ा है, उससे कम से कम, सी / सी ++ के मार्ग पर जा सकते हैं, जब तक मैं जीसी पर निर्भर किसी भी पुस्तकालय या भाषा निर्माण का उपयोग नहीं करता। समस्या यह है, मैं उन लोगों को नहीं जानता जो करते हैं मैंने स्ट्रिंग, नई आदि को देखा है, लेकिन इसका मतलब यह है कि मैं जीआर को सक्षम नहीं करने के लिए स्ट्रिंग में निर्माण का उपयोग नहीं कर सकता हूँ?

मैंने कुछ बग रिपोर्टों में पढ़ा है कि जीसी वास्तव में छोटी गाड़ी हो सकती है और वह इसकी प्रदर्शन समस्याओं को समझा सकता है?

इसके अलावा, डी थोड़ा और अधिक स्मृति का उपयोग करता है, वास्तव में, डी C ++ प्रोग्राम से पहले स्मृति से बाहर चलाता है। मुझे लगता है कि इस मामले में लगभग 15% अधिक या अधिक है। मुझे लगता है कि जीसी के लिए है

मुझे एहसास है कि निम्न कोड आपके औसत कार्यक्रम का प्रतिनिधि नहीं है लेकिन यह क्या कहता है कि जब कार्यक्रम बहुत सारे ऑब्जेक्ट्स को शुरु कर रहे हैं (कहते हैं, स्टार्टअप पर) वे बहुत धीमी हो जाएंगे (10 बार एक बड़ा कारक होगा) जीसी में स्टार्टअप पर "पॉज़ेड" हो सकता है, तो यह जरूरी नहीं कि कोई समस्या हो।

क्या वास्तव में अच्छा होगा अगर मैं किसी तरह किसी भी तरह से संकलक को स्वचालित रूप से एक स्थानीय ऑब्जेक्ट जीसी कर सकता हूँ अगर मैं इसे विशेष रूप से डीलोकेट नहीं करता यह लगभग दोनों दुनिया का सबसे अच्छा दे

जैसे,

{
    Foo f = new Foo();
    ....
    dispose f; // Causes f to be disposed of immediately and treats f outside the GC
               // If left out then f is passed to the GC.
               // I suppose this might actually end up creating two kinds of Foo 
               // behind the scenes. 

    Foo g = new manualGC!Foo();   // Maybe something like this will keep GC's hands off 
                                  // g and allow it to be manually disposed of.
}

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

कोड:

module main;
import std.stdio, std.conv, core.memory;
import core.stdc.time;

class Foo{
    int x;
    this(int _x){x=_x;}
}

void main(string args[]) 
{

    clock_t start, end;
    double cpu_time_used;


    //GC.disable();
    start = clock();

    //int n = to!int(args[1]);
    int n = 10000000;
    Foo[] m = new Foo[n];

    foreach(i; 0..n)
    //for(int i = 0; i<n; i++)
    {
        m[i] = new Foo(i);
    }

    end = clock();
    cpu_time_used = (end - start);
    cpu_time_used = cpu_time_used / 1000.0;
    writeln(cpu_time_used);
    getchar();
}

सी ++ कोड

#include <cstdlib>
#include <iostream>
#include <time.h>
#include <math.h>
#include <stdio.h>

using namespace std;
class Foo{
public:
    int x;
    Foo(int _x);

};

Foo::Foo(int _x){
    x = _x;
}

int main(int argc, char** argv) {

    int n = 120000000;
    clock_t start, end;
    double cpu_time_used;




    start = clock();

    Foo** gx = new Foo*[n];
    for(int i=0;i<n;i++){
        gx[i] = new Foo(i);
    }


    end = clock();
    cpu_time_used = (end - start);
    cpu_time_used = cpu_time_used / 1000.0;
    cout << cpu_time_used;

    std::cin.get();
    return 0;
}

डी एस जीसी बस के रूप में अन्य के रूप में परिष्कृत नहीं है जावा की तरह यह ओपन-सोर्स है इसलिए कोई भी इसे सुधारने का प्रयास कर सकता है।

सीडीजीसी नामक एक प्रयोगात्मक समवर्ती जीसी है और ग्लोबल लॉक को हटाने के लिए मौजूदा जीएसओसी प्रोजेक्ट है: http://www.google-melange.com/gsoc/project/google/gsoc2012/avtuunainen/17001

बेहतर अनुकूलित कोड प्राप्त करने के लिए संकलन के लिए एलडीसी या जीडीसी का उपयोग करना सुनिश्चित करें।

XomB प्रोजेक्ट भी एक कस्टम रनटाइम का उपयोग करता है लेकिन यह डी संस्करण 1 है जो मुझे लगता है। http://wiki.xomb.org/index.php?title=Main_Page


मेरा सुझाव है कि आप इस लेख को पढ़ें: http://3d.benjamin-thaut.de/?p=20 वहां आपको मानक लाइब्रेरी का एक संस्करण मिलेगा जो स्वयं की स्मृति प्रबंधन करता है और पूरी तरह से कूड़ा संग्रह से बचा जाता है।


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

और वैसे, यह उतनी धीमे नहीं है जितना कि आप उल्लेख करते हैं। और GC.disable () वास्तव में इसे अक्षम नहीं करता।


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





d