সত্তা / উপাদান উপাদানগুলিতে সত্তাগুলির একযোগে প্রসেসিংয়ের জন্য পঠন / গণনা / লেখার পদক্ষেপগুলি দক্ষতার সাথে আলাদা করা


11

সেটআপ

আমার একটি সত্তা-উপাদান আর্কিটেকচার রয়েছে যেখানে সত্তাগুলির বৈশিষ্ট্যের একটি সেট থাকতে পারে (যা কোনও আচরণের সাথে বিশুদ্ধ ডেটা নয়) এবং সেখানে এমন সিস্টেম রয়েছে যা সত্তার যুক্তি চালায় যা সেই ডেটাতে কাজ করে। মূলতঃ কিছুটা সিউডো-কোডে:

Entity
{
    id;
    map<id_type, Attribute> attributes;
}

System
{
    update();
    vector<Entity> entities;
}

একটি সিস্টেম যা কেবলমাত্র সমস্ত অস্তিত্বের সাথে ধ্রুবক হারে চলে আসে

MovementSystem extends System
{
   update()
   {
      for each entity in entities
        position = entity.attributes["position"];
        position += vec3(1,1,1);
   }
}

মূলত, আমি যথাসম্ভব দক্ষতার সাথে আপডেটের সমান্তরাল করার চেষ্টা করছি। সমান্তরালভাবে পুরো সিস্টেমগুলি চালিয়ে বা এক সিস্টেমের প্রতিটি আপডেট () প্রদানের মাধ্যমে এটি করা যেতে পারে যাতে বিভিন্ন থ্রেড একই সিস্টেমের আপডেট সম্পাদন করতে পারে তবে সেই সিস্টেমের সাথে নিবন্ধিত সংস্থার আলাদা সাবসেটের জন্য।

সমস্যা

প্রদর্শিত মুভিস্টিস্টেমের ক্ষেত্রে, সমান্তরালতা তুচ্ছ tri যেহেতু সত্তাগুলি একে অপরের উপর নির্ভর করে না এবং ভাগ করা ডেটা সংশোধন করে না, আমরা কেবল সমস্ত সত্ত্বাকে সমান্তরালে সরিয়ে নিতে পারি।

যাইহোক, এই সিস্টেমে কখনও কখনও প্রয়োজন হয় যে সত্ত্বাগুলি একে অপরের সাথে (/ থেকে ডেটা পড়তে / লেখার জন্য) যোগাযোগ করে, কখনও কখনও একই সিস্টেমের মধ্যে, তবে প্রায়শই একে অপরের উপর নির্ভরশীল বিভিন্ন সিস্টেমের মধ্যে থাকে।

উদাহরণস্বরূপ, একটি পদার্থবিজ্ঞানের সিস্টেমে কখনও কখনও সত্তা একে অপরের সাথে যোগাযোগ করতে পারে। দুটি বস্তুর সংঘর্ষ হয়, তাদের অবস্থানগুলি, বেগ এবং অন্যান্য বৈশিষ্ট্যগুলি সেগুলি থেকে পড়া হয়, আপডেট করা হয় এবং তারপরে আপডেট হওয়া বৈশিষ্ট্যগুলি উভয় সত্তায় আবার লেখা হয়।

ইঞ্জিনে রেন্ডারিং সিস্টেম সত্তা রেন্ডারিং শুরু করার আগে, অন্যান্য প্রাসঙ্গিক বৈশিষ্ট্যগুলি তাদের হওয়ার দরকার হয় তা নিশ্চিত করার জন্য এটি অন্যান্য সিস্টেমের কার্য সম্পাদনের জন্য অপেক্ষা করতে হবে।

আমরা যদি অন্ধভাবে এটির সাথে সমান্তরাল করার চেষ্টা করি তবে এটি শাস্ত্রীয় বর্ণের অবস্থার দিকে পরিচালিত করবে যেখানে বিভিন্ন সিস্টেম একই সাথে ডেটা পড়তে এবং সংশোধন করতে পারে।

আদর্শভাবে, এমন একটি সমাধান উপস্থিত থাকবে যেখানে সমস্ত সিস্টেম একই সময়ে একই ডেটা পরিবর্তন করে অন্য সিস্টেমগুলির বিষয়ে চিন্তা না করে এবং একই সাথে কার্যকর করার আদেশ এবং সমান্তরালকরণের বিষয়ে প্রোগ্রামার যত্ন না নিয়ে কোনও ইচ্ছার যে কোনও সত্তা থেকে ডেটা পড়তে পারে and এই সিস্টেমগুলি ম্যানুয়ালি (যা কখনও কখনও সম্ভব নাও হতে পারে)।

একটি মৌলিক প্রয়োগে, কেবলমাত্র সমস্ত ডেটা পাঠানো এবং সমালোচনামূলক বিভাগগুলিতে (মুটেক্সগুলি দিয়ে তাদের রক্ষা করা) রেখে এই অর্জন করা যায়। তবে এটি প্রচুর পরিমাণ রানটাইম ওভারহেডকে প্ররোচিত করে এবং সম্ভবত সম্পাদন সংবেদনশীল অ্যাপ্লিকেশনগুলির জন্য উপযুক্ত নয়।

সমাধান?

আমার চিন্তাভাবনায়, একটি সম্ভাব্য সমাধান হ'ল এমন একটি ব্যবস্থা হবে যেখানে ডেটা পড়া / আপডেট করা এবং লেখার ব্যবস্থা আলাদা করা হয়, যাতে একটি ব্যয়বহুল পর্যায়ে সিস্টেমগুলি কেবলমাত্র ডেটা পড়ে এবং তাদের গণনা করার জন্য যা প্রয়োজন তা গণনা করে, কোনওভাবে ফলাফলকে ক্যাশে করে এবং তারপরে সমস্ত লিখুন পরিবর্তিত তথ্য পৃথক লিখন পাসে লক্ষ্য সত্তা ফিরে। সমস্ত সিস্টেম রাষ্ট্রের যে ডাটাতে ফ্রেমের শুরুতে ছিল তার উপর কাজ করবে এবং তারপরে ফ্রেমের সমাপ্তির আগে যখন সমস্ত সিস্টেম আপডেট করা শেষ করে, তখন সিরিয়ালযুক্ত রাইটিং পাস হয় যেখানে সমস্ত ভিন্ন থেকে ক্যাশে ফলাফল আসে happens সিস্টেমগুলির মাধ্যমে পুনরাবৃত্তি করা হয় এবং লক্ষ্য সত্ত্বায় ফিরে লেখা হয়।

এটি (সম্ভবত ভুল?) ধারণার উপর ভিত্তি করে তৈরি করা হয়েছে যে সহজ সমান্তরাল জয়ের ফলে ফলাফলের ক্যাচিং এবং লেখার পাসের ব্যয় (রানটাইম পারফরম্যান্সের পাশাপাশি একটি কোড ওভারহেড উভয়ই) ছাড়িয়ে যাওয়ার পক্ষে যথেষ্ট বড় হতে পারে।

প্রশ্নটি

অনুকূল কর্মক্ষমতা অর্জনের জন্য এই জাতীয় ব্যবস্থা কীভাবে প্রয়োগ করা যেতে পারে? এই জাতীয় ব্যবস্থার বাস্তবায়ন বিশদগুলি কী কী এবং কোনও সত্তা-উপাদান সিস্টেমের পূর্বশর্তগুলি কী কী এই সমাধানটি ব্যবহার করতে চায়?

উত্তর:


1

----- (সংশোধিত প্রশ্নের ভিত্তিতে)

প্রথম পয়েন্ট: যেহেতু আপনি আপনার মুক্তির বিল্ড রান রানটাইমের প্রোফাইল দেওয়ার কথা উল্লেখ করেন নি এবং একটি নির্দিষ্ট প্রয়োজনীয়তার সন্ধান পেয়েছি আমি আপনাকে সেই ASAP করার পরামর্শ দিই। আপনার প্রোফাইলটি দেখতে কেমন, আপনি খারাপ মেমোরি বিন্যাসের সাহায্যে ক্যাশে ছোঁড়াচ্ছেন, এটির একটি মূল 100% রয়েছে, আপনার ECS বনাম আপনার ইঞ্জিনের প্রসেস প্রক্রিয়াকরণে কতটা আপেক্ষিক সময় ব্যয় করা হয় ইত্যাদি ...

কোনও সত্তা থেকে পড়ুন এবং কিছু গণনা করুন ... এবং কোনও মধ্যবর্তী স্টোরেজ অঞ্চলে কোথাও ফলাফল ধরে রেখেছেন? আমি ভাবি না যে আপনি যেভাবে পড়বেন + গণনা + স্টোরটি আপনি ভাবেন সেভাবে আলাদা করতে পারবেন এবং এই মধ্যবর্তী স্টোরটি খাঁটি ওভারহেড ছাড়া অন্য কিছু হতে পারে বলে আশা করতে পারেন।

এছাড়াও, যেহেতু আপনি নিয়মিত প্রক্রিয়াকরণ করছেন মূল নিয়মটি আপনি অনুসরণ করতে চান তা হ'ল সিপিইউ কোর প্রতি এক থ্রেড। আমি মনে করি আপনি এটি ভুল স্তরের দিকে দেখছেন দেখছেন, পৃথক সত্ত্বা নয় পুরো সিস্টেমগুলির দিকে তাকানোর চেষ্টা করুন।

আপনার সিস্টেমের মধ্যে একটি নির্ভরতা গ্রাফ তৈরি করুন, সিস্টেমটি পূর্ববর্তী সিস্টেমের কাজগুলির ফলাফলগুলির কী প্রয়োজন। আপনার যদি সেই নির্ভরতা গাছটি হয়ে যায় তবে আপনি সহজেই কোনও থ্রেডে প্রক্রিয়া করার জন্য সত্তা পূর্ণ পূর্ণ সিস্টেমগুলি প্রেরণ করতে পারেন ।

সুতরাং আসুন আমরা বলি যে আপনার নির্ভরতা গাছটি ব্র্যাম্বল এবং ভালুকের ফাঁদগুলির মোড়ক, এটি একটি ডিজাইনের সমস্যা তবে আমাদের যা আছে তা নিয়ে আমাদের কাজ করতে হবে। এখানে সর্বোত্তম ক্ষেত্রেটি হ'ল প্রতিটি সিস্টেমে প্রতিটি সত্তা সেই ব্যবস্থার অভ্যন্তরে অন্য কোনও ফলাফলের উপর নির্ভর করে না। এই সিস্টেমটির মালিকানাধীন দুটি কোর এবং 200 টি সত্তার উদাহরণ হিসাবে আপনি এখানে সহজেই দুটি থ্রেডগুলিতে 0-99 এবং 100-199 টি থ্রেডে প্রসেসিংকে সহজেই বিভক্ত করেন।

উভয় ক্ষেত্রেই, প্রতিটি পর্যায়ে আপনাকে পরবর্তী পর্যায়ে নির্ভর করে এমন ফলাফলের জন্য অপেক্ষা করতে হবে। তবে এটি ঠিক আছে কারণ বাল্কে দশটি বৃহত ডাটা প্রক্রিয়াকরণের ফলাফলের জন্য অপেক্ষা করা ছোট ব্লকের জন্য এক হাজার বার সিঙ্ক্রোনাইজ করার চেয়ে অনেক বেশি উন্নত।

নির্ভরতা গ্রাফ তৈরির পেছনের ধারণাটি ছিল স্বয়ংক্রিয়ভাবে "অন্যান্য সিস্টেমকে সমান্তরালভাবে চালানোর জন্য সন্ধান এবং সংশ্লেষকরণ" এর আপাতদৃষ্টিতে অসম্ভব কাজটিকে তুচ্ছ করা। যদি এই ধরনের গ্রাফটি পূর্ববর্তী ফলাফলগুলির জন্য ধ্রুবক অপেক্ষা করে অবরুদ্ধ হওয়ার লক্ষণগুলি দেখায় তবে একটি পঠন + সংশোধন এবং বিলম্বিত লেখার তৈরি কেবল ব্লকেজকে সরিয়ে দেয় এবং প্রক্রিয়াকরণের ক্রমিক প্রকৃতিটি সরিয়ে দেয় না।

এবং সিরিয়াল প্রক্রিয়াজাতকরণ কেবল প্রতিটি সিকোয়েন্স পয়েন্টের মধ্যে সমান্তরাল রূপান্তরিত হতে পারে তবে সামগ্রিকভাবে নয়। তবে আপনি এটি বুঝতে পারেন কারণ এটি আপনার সমস্যার মূল বিষয়। এমনকি যদি আপনি এমন ডেটা থেকে পড়ে থাকেন যা এখনও লেখা হয়নি যা আপনার এখনও সেই ক্যাশেটি উপলব্ধ হওয়ার জন্য অপেক্ষা করতে হবে।

এই ধরণের প্রতিবন্ধকতাগুলির সাথে যদি সমান্তরাল আর্কিটেকচার তৈরি করা সহজ বা এমনকি সম্ভব হত তবে কম্পিউটার বিজ্ঞান ব্লেচলে পার্কের পর থেকে সমস্যার সাথে লড়াই করতে পারত না।

একমাত্র আসল সমাধান হ'ল এই সমস্ত নির্ভরতা হ্রাস করা যাতে সিক্যুয়েন্স পয়েন্টগুলি যথাসম্ভব বিরল প্রয়োজন হয়। এর মধ্যে সাব- ডিভিডিং সিস্টেমগুলি ক্রমানুসারে প্রক্রিয়াকরণ পদক্ষেপগুলিতে জড়িত থাকতে পারে যেখানে প্রতিটি সাবসিস্টেমের অভ্যন্তরে, থ্রেডের সাথে সমান্তরাল হয়ে যাওয়া তুচ্ছ হয়ে যায়।

সেরা আমি এই সমস্যার জন্য পেরেছি এবং এটি সুপারিশ করার চেয়ে সত্য আর কিছুই নয় যে যদি আপনার মাথাটি কোনও ইটের দেয়ালে আঘাত করা ব্যথা হয় তবে এটি ছোট ইটের দেয়ালগুলিতে ভেঙে দেওয়া উচিত যাতে আপনি কেবল আপনার পাঁজরে আঘাত করছেন।


আমি আপনাকে বলার জন্য দুঃখিত, কিন্তু এই উত্তরটি একরকম অনুফলজনক বলে মনে হচ্ছে। আপনি কেবল আমাকে বলছেন যে আমি যা খুঁজছি তার অস্তিত্ব নেই, যা যৌক্তিকরূপে ভুল বলে মনে হচ্ছে (কমপক্ষে নীতিগতভাবে) এবং কারণ আমি এর আগেও বেশ কয়েকটি জায়গায় লোককে এই জাতীয় সিস্টেমে অলৌকিকভাবে দেখেছি (কেউ কখনও পর্যাপ্ত পরিমাণে দেয় না) বিশদ, যদিও, যা এই প্রশ্ন জিজ্ঞাসা করার জন্য প্রধান প্রেরণা)। যদিও, এটি সম্ভবত আমার মূল প্রশ্নে আমি যথেষ্ট পরিমাণে বিশদ ছিল না যে কারণে আমি এটি ব্যাপকভাবে আপডেট করেছি (এবং আমার মন যদি কোনও কিছুতে হোঁচট খায় তবে আমি তা আপডেট করে যাব)।
ট্র্যাভিসজি

এছাড়াও কোনও অপরাধের উদ্দেশ্যে নয়: পি
ট্র্যাভিসজি

@ ট্রাভিসজি প্রায়শই এমন সিস্টেম রয়েছে যা প্যাট্রিকের নির্দেশিত হিসাবে অন্যান্য সিস্টেমে নির্ভর করে। যুক্তিযুক্ত পদক্ষেপের অংশ হিসাবে ফ্রেম বিলম্ব এড়াতে বা একাধিক আপডেট পাস এড়ানোর জন্য, গৃহীত সমাধানটি আপডেট পর্বকে সিরিয়ালাইজ করা, যেখানে সম্ভব সমান্তরালভাবে সাবসিস্টেমগুলি চালানো, ছোট ছোট আপডেটের সাথে ব্যাচিংয়ের সময় সমস্ত নির্ভরতা সহ সাবসিস্ট্রিগুলি সিরিয়ালকরণ করা হয় each একটি প্যারালাল_ফোর () ধারণাটি ব্যবহার করে সাবসিস্টেম। এটি সাবসিস্টেম আপডেট পাসের যে কোনও সংমিশ্রণের জন্য আদর্শ এবং সবচেয়ে নমনীয় for
নারোস

0

আমি এই সমস্যার একটি আকর্ষণীয় সমাধান শুনেছি: ধারণাটি হ'ল সত্তা ডেটার 2 কপি থাকবে (অপব্যয়, আমি জানি)। একটি অনুলিপি বর্তমান কপি হবে এবং অন্যটি অতীতের অনুলিপি হবে। বর্তমান অনুলিপিটি কেবল কঠোরভাবে লেখা হয়, এবং অতীত অনুলিপিটি কেবল কঠোরভাবে পঠিত হয়। আমি ধরে নিচ্ছি যে সিস্টেমগুলি একই ডেটা উপাদানগুলিতে লিখতে চায় না, তবে যদি এটি না হয় তবে সেই সিস্টেমগুলি একই থ্রেডে থাকা উচিত। প্রতিটি থ্রেডের উপাত্তের পারস্পরিক একচেটিয়া বিভাগের বর্তমান অনুলিপিগুলিতে লেখার অ্যাক্সেস থাকবে এবং প্রতিটি থ্রেডের সমস্ত অতীতের সমস্ত অনুলিপিগুলিতে পড়ার অ্যাক্সেস থাকবে এবং এভাবে বিহীন অনুলিপিগুলিতে ডেটা ব্যবহার করে বর্তমান কপিগুলি আপডেট না করে আপডেট করতে পারবেন লকিং। প্রতিটি ফ্রেমের মধ্যে, বর্তমান অনুলিপিটি অতীতের অনুলিপি হয়ে যায়, তবে আপনি ভূমিকাগুলির অদলবদল পরিচালনা করতে চান।

এই পদ্ধতিটি বর্ণের পরিস্থিতিও সরিয়ে দেয় কারণ সমস্ত সিস্টেমগুলি একটি বাসি রাজ্যের সাথে কাজ করবে যা সিস্টেমটি প্রক্রিয়া করার আগে / পরে পরিবর্তন হবে না।


এটাই জন কারম্যাকের হিপ কপি ট্রিক, তাই না? আমি এটি সম্পর্কে অবাক হয়েছি, তবে এখনও এটির একই সমস্যা রয়েছে যা একাধিক থ্রেড একই আউটপুট অবস্থানে লিখতে পারে। আপনি যদি সবকিছু "সিঙ্গল-পাস" রাখেন তবে এটি সম্ভবত একটি ভাল সমাধান, তবে আমি নিশ্চিত না যে এটি কতটা সম্ভব।
ট্র্যাভিসজি

স্ক্রিন ডিসপ্লে ল্যাটেন্সিতে ইনপুটটি জিইউআই প্রতিক্রিয়া সহ 1 ফ্রেমের সময় বাড়িয়ে তুলবে। যা আরটিএসের মতো অ্যাকশন / টাইমিং গেমস বা ভারী জিইউআই ম্যানিপুলেশনগুলির জন্য গুরুত্বপূর্ণ। যদিও আমি এটি একটি সৃজনশীল ধারণা হিসাবে পছন্দ করি।
প্যাট্রিক হিউজেস

আমি এই সম্পর্কে একটি বন্ধুর কাছ থেকে শুনেছিলাম, এবং জানি না এটি একটি কারম্যাক কৌশল। কীভাবে রেন্ডারিং করা হয় তার উপর নির্ভর করে উপাদানগুলির রেন্ডারিং পিছনে একটি ফ্রেম থাকতে পারে। আপনি এটি আপডেট পর্বের জন্য ব্যবহার করতে পারেন, তারপরে সবকিছু অন-টু ডেট হয়ে যাওয়ার পরে বর্তমান কপি থেকে রেন্ডার করুন।
জন ম্যাকডোনাল্ড

0

আমি জানি 3 টি সফ্টওয়্যার ডিজাইন ডেটার সমান্তরাল প্রক্রিয়াকরণ পরিচালনা করে:

  1. ধারাবাহিকভাবে ডেটা প্রক্রিয়া করুন : একাধিক থ্রেড ব্যবহার করে আমরা ডেটা প্রসেস করতে চাইলে এটি আরও বিরক্তিকর হতে পারে। যাইহোক, বেশিরভাগ পরিস্থিতিতে কেবল কাজ শেষ হওয়ার জন্য একাধিক থ্রেডের প্রয়োজন হয় যখন অন্যান্য থ্রেড অপেক্ষা করে বা দীর্ঘ চলমান অপারেশন করে। সর্বাধিক সাধারণ ব্যবহার হ'ল ইউআই থ্রেড যা একক থ্রেডে ইউজার ইন্টারফেস আপডেট করে, অন্য থ্রেডগুলি পটভূমিতে চলতে পারে তবে সরাসরি ইউআই উপাদানগুলিতে অ্যাক্সেসের অনুমতি দেওয়া হয় না। পটভূমি থ্রেডগুলি থেকে ফলাফলগুলি পাস করার জন্য, কাজের সারিগুলি ব্যবহৃত হবে যা পরবর্তী যুক্তিসঙ্গত সুযোগে একক থ্রেড দ্বারা প্রক্রিয়া করা হবে।
  2. ডেটা অ্যাক্সেসকে সিঙ্ক্রোনাইজ করুন: একই ডেটা অ্যাক্সেস করে একাধিক থ্রেড পরিচালনা করার পক্ষে এটি সর্বাধিক সাধারণ উপায়। বেশিরভাগ প্রোগ্রামিং ভাষা ক্লাস এবং সরঞ্জামগুলিতে তৈরি করে এমন বিভাগগুলিকে লক করার জন্য যেখানে একসাথে একাধিক থ্রেড দ্বারা ডেটা পড়ে এবং / অথবা লিখিত হয়। তবে অপারেশন অবরুদ্ধ না করার বিষয়ে সাবধানতা অবলম্বন করা উচিত। অন্যদিকে, রিয়েল-টাইম অ্যাপ্লিকেশনগুলিতে এই পদ্ধতির অনেক বেশি ওভারহেড ব্যয় হয়।
  3. সাম্প্রতিক পরিবর্তনগুলি কেবল তখনই হ্যান্ডেল করুন : সংঘর্ষ খুব কম ঘটলে এই আশাবাদী পন্থাটি করা যেতে পারে। যদি কোনও একাধিক অ্যাক্সেস না থাকে তবে ডেটাটি পড়া এবং সংশোধন করা হবে, তবে এমন একটি ব্যবস্থা রয়েছে যা ডেটা একসাথে আপডেট করার সময় সনাক্ত করে। যদি এটি হয়, একক গণনা সবেমাত্র সাফল্য না হওয়া পর্যন্ত আবার কার্যকর করা হবে।

সত্তা সিস্টেমে ব্যবহৃত প্রতিটি পদ্ধতির জন্য এখানে কিছু উদাহরণ রয়েছে:

  1. একটি মনে দেয় CollisionSystemযে সার্চ Positionএবং RigidBodyউপাদান এবং একটি আপডেট করা উচিত VelocityVelocityসরাসরি কারসাজির পরিবর্তে উইলের CollisionSystemপরিবর্তে একটি CollisionEventএর কাজের সারিটিতে একটি রাখবে EventSystem। এই ইভেন্টটির পরে অন্যান্য আপডেটগুলির সাথে ক্রমানুসারে প্রক্রিয়া করা হবে Velocity
  2. একটি EntitySystemউপাদানগুলির একটি সেট নির্ধারণ করে যা এটি পড়তে এবং লিখতে প্রয়োজন। প্রত্যেকের জন্য Entityএটি প্রতিটি উপাদান যা এটি পড়তে চায় তার জন্য একটি পঠিত লক এবং আপডেট করতে ইচ্ছুক প্রতিটি উপাদানগুলির একটি লিখিত লক অর্জন করবে। এটির মতো, EntitySystemআপডেট ক্রিয়াকলাপগুলি সিঙ্ক্রোনাইজ হওয়ার সময় প্রত্যেকে একই সাথে উপাদানগুলি পড়তে সক্ষম হবে।
  3. উদাহরণ গ্রহণ MovementSystem, Positionউপাদান অপরিবর্তনীয় এবং ধারণ করে রিভিশন সংখ্যা। MovementSystemSavely সার্চ Positionএবং Velocityউপাদান এবং নতুন নির্ণয় Position, পঠিত বৃদ্ধিশীল সংস্করণ নম্বর এবং হালনাগাদ চেষ্টা Positionঅংশটি। সমকালীন পরিবর্তনের ক্ষেত্রে, কাঠামোটি আপডেটের দিকে এটি সূচিত করে এবং এটি Entityদ্বারা আপডেট হওয়া সংস্থাগুলির তালিকায় ফিরে আসবে MovementSystem

সিস্টেম, সত্তা এবং আপডেট অন্তরগুলির উপর নির্ভর করে প্রতিটি পন্থা ভাল বা খারাপ হতে পারে। কোনও সত্তা সিস্টেমের কাঠামো ব্যবহারকারীকে কার্যকারিতাটি সরিয়ে দেওয়ার জন্য এই বিকল্পগুলির মধ্যে চয়ন করতে দেয়।

আমি আশা করি আলোচনায় আমি কিছু ধারণা যুক্ত করতে পারলাম এবং এ সম্পর্কে কিছু খবর থাকলে দয়া করে আমাকে জানান।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.