ডেটা ওরিয়েন্টেড ডিজাইন - 1-2 টিরও বেশি কাঠামো "সদস্য" এর সাথে অবৈধ?

Question

ডেটা ওরিয়েন্টেড ডিজাইনের সাধারণ উদাহরণটি বল কাঠামোর সাথে:

struct Ball
{
  float Radius;
  float XYZ[3];
};

এবং তারপরে তারা কিছু অ্যালগরিদম তৈরি করে যা std::vector<Ball>ভেক্টরকে পুনরাবৃত্তি করে ।

তারপরে তারা আপনাকে একই জিনিস দেয় তবে ডেটা ওরিয়েন্টেড ডিজাইনে প্রয়োগ করা হয়:

struct Balls
{
  std::vector<float> Radiuses;
  std::vector<XYZ[3]> XYZs;
};

কোনটি ভাল এবং সব কিছু যদি আপনি প্রথমে ট্রাডের সমস্ত রেডিওগুলি পুনরাবৃত্তি করতে যাচ্ছেন, তারপরে সমস্ত পজিশন এবং আরও। তবে, আপনি কীভাবে বলগুলিকে ভেক্টরে সরিয়ে ফেলবেন? মূল সংস্করণে, আপনি একটি আছে std::vector<Ball> BallsAll, আপনি ঠিক কোন স্থানান্তর করতে পারেন BallsAll[x]কোন BallsAll[y]।

তবে ডেটা ওরিয়েন্টেড সংস্করণে এটি করার জন্য, আপনাকে অবশ্যই প্রতিটি সম্পত্তি (বল - ব্যাসার্ধ এবং অবস্থানের ক্ষেত্রে 2 বার) এর জন্য একই জিনিস করতে হবে। আপনার আরও অনেক সম্পত্তি থাকলে এটি আরও খারাপ হয়। আপনাকে প্রতিটি "বল" এর জন্য একটি সূচক রাখতে হবে এবং আপনি যখন এটিকে চারপাশে সরিয়ে নেওয়ার চেষ্টা করবেন তখন আপনাকে বৈশিষ্ট্যের প্রতিটি ভেক্টরে নড়াচড়া করতে হবে।

এটি কি ডেটা ওরিয়েন্টেড ডিজাইনের কোনও কার্যকারিতা উপকারকে হত্যা করে না?

Answer 1

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

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

তবে, ডিওডি-র দ্বিতীয় দিক রয়েছে। আপনি কেবল আপনার মেমরি লেআউটটি 90 turning ঘুরিয়ে দিয়ে এবং এর ফলে সংকলিত ত্রুটিগুলি সংশোধন করার জন্য সর্বনিম্ন চেষ্টা করে সমস্ত ক্যাশে এবং প্রতিষ্ঠানের সুবিধা পান না। এই ব্যানার অধীনে অন্যান্য সাধারণ কৌশল শেখানো হয়। উদাহরণস্বরূপ "অস্তিত্ব ভিত্তিক প্রক্রিয়াজাতকরণ": আপনি ঘন ঘন বলগুলি নিষ্ক্রিয় করেন এবং সেগুলি পুনরায় সক্রিয় করেন, বল অবজেক্টে একটি পতাকা যুক্ত করবেন না এবং আপডেট লুপটি মিথ্যাতে সেট করা পতাকা সহ বলগুলিকে উপেক্ষা করবেন না। বলটিকে একটি "সক্রিয়" সংগ্রহ থেকে একটি "নিষ্ক্রিয়" সংগ্রহের দিকে সরান, এবং আপডেট লুপটি কেবল "সক্রিয়" সংগ্রহটি পরীক্ষা করে make

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

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

সুতরাং সবকিছুতে অন্ধভাবে SoA নিক্ষেপ করার পরিবর্তে আপনার ডেটা এবং আপনি কীভাবে এটি প্রক্রিয়াভুক্ত করবেন সে সম্পর্কে ভাবেন । যদি আপনি দেখতে পান যে আপনি এক লুপে অবস্থান এবং বেগগুলি প্রক্রিয়া করছেন, তবে মেসগুলি দিয়ে যান এবং তারপরে হিটপয়েন্টগুলি আপডেট করুন, আপনার স্মৃতি বিন্যাসটিকে এই তিনটি ভাগে ভাগ করার চেষ্টা করুন। যদি আপনি দেখতে পান যে আপনি বিচ্ছিন্ন অবস্থানে অবস্থিত x, y, z উপাদানগুলি অ্যাক্সেস করেছেন তবে আপনার অবস্থান ভেক্টরগুলিকে একটি SoA এ পরিণত করতে পারেন। যদি আপনি নিজেকে দরকারী উপায়ে কিছু করার পরিবর্তে ডেটা পরিবর্তন করে দেখেন তবে সম্ভবত এটিকে বদলে যাওয়া বন্ধ করুন।

Answer 2

ডেটা ওরিয়েন্টেড মাইন্ডসেট

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

এটি যথাযথভাবে উপযুক্ত হলে সম্ভবত এসএএর প্রতিনিধিত্ব করতে পারে:

struct BallSoa
{
   vector<float> x;        // size n
   vector<float> y;        // size n
   vector<float> z;        // size n
   vector<float> r;        // size n
};

... এটি প্রায়শই উল্লম্ব লুপী যুক্তিগুলির জন্য উপযুক্ত যা কোনও গোলক কেন্দ্রের ভেক্টর উপাদানগুলি এবং একসাথে ব্যাসার্ধের প্রক্রিয়া করে না (চারটি ক্ষেত্র একযোগে গরম হয় না), তবে পরিবর্তে একবারে (ব্যাসার্ধের মধ্য দিয়ে একটি লুপ, অন্য 3 টি লুপ) গোলক কেন্দ্রগুলির পৃথক উপাদানগুলির মাধ্যমে)।

অন্যান্য ক্ষেত্রে ক্ষেত্রগুলি ঘন ঘন একসাথে অ্যাক্সেস করা থাকলে (যদি আপনার লুপী যুক্তিটি পৃথকভাবে বলের পরিবর্তে বলের সমস্ত ক্ষেত্রের মধ্য দিয়ে ঘুরতে থাকে) এবং / অথবা যদি কোনও বলের এলোমেলো অ্যাক্সেস প্রয়োজন হয় তবে এওএস ব্যবহার করা আরও উপযুক্ত হবে:

struct BallAoS
{
    float x;
    float y;
    float z;
    float r;
};
vector<BallAoS> balls;        // size n

... অন্যান্য ক্ষেত্রে এটি একটি হাইব্রিড ব্যবহার করা উপযুক্ত হতে পারে যা উভয় সুবিধার ভারসাম্য বজায় রাখে:

struct BallAoSoA
{
    float x[8];
    float y[8];
    float z[8];
    float r[8];
};
vector<BallAoSoA> balls;      // size n/8

... আপনি আরও একটি বলের ক্ষেত্রটিকে ক্যাশে লাইন / পৃষ্ঠায় ফিট করতে অর্ধ-ফ্লোটগুলি ব্যবহার করে একটি বলের আকার অর্ধেক সঙ্কুচিত করতে পারেন।

struct BallAoSoA16
{
    Float16 x2[16];
    Float16 y2[16];
    Float16 z2[16];
    Float16 r2[16];
};
vector<BallAoSoA16> balls;    // size n/16

... সম্ভবত এমনকি ব্যাসার্ধটি প্রায় গোলাকেন্দ্র হিসাবে প্রায় অ্যাক্সেস করা হয় না (সম্ভবত আপনার কোডবেস প্রায়শই পয়েন্টগুলির মতো আচরণ করে এবং কেবল বিরল ক্ষেত্র হিসাবে খুব কমই দেখা যায়)। সেক্ষেত্রে আপনি সম্ভবত একটি গরম / ঠান্ডা ফিল্ড বিভাজন কৌশল প্রয়োগ করতে পারেন।

struct BallAoSoA16Hot
{
    Float16 x2[16];
    Float16 y2[16];
    Float16 z2[16];
};
vector<BallAoSoA16Hot> balls;     // size n/16: hot fields
vector<Float16> ball_radiuses;    // size n: cold fields

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

এটি মেমোরি অ্যাক্সেসের ধরণগুলি এবং তার সাথে থাকা লেআউটগুলিতে স্পটলাইট রাখে যা এটিকে স্বাভাবিকের চেয়ে উল্লেখযোগ্যভাবে দৃ stronger় উদ্বেগ তৈরি করে। এক অর্থে এটি কিছুটা বিমূর্ততা ছিন্ন করতে পারে। আমি এই মানসিকতাকে আরও প্রয়োগ করে খুঁজে পেয়েছি যে আমি আর std::dequeএর অ্যালগোরিদমিক প্রয়োজনীয়তার দিক থেকে দেখতে পাচ্ছি না যতটা এটির সংযুক্ত কাঠের ব্লক প্রতিনিধিত্ব এবং মেমোরি স্তরে এর এলোমেলোভাবে অ্যাক্সেস কীভাবে কাজ করে। এটি কিছুটা বাস্তবায়নের বিশদগুলিতে ফোকাস দিচ্ছে, তবে বাস্তবায়ন বিশদ যা স্কেলিবিলিটি বর্ণনা করার কারণে অ্যালগোরিদমিক জটিলতার সাথে পারফরম্যান্সে ঠিক তত বেশি প্রভাব ফেলবে।

অকাল অপটিমাইজেশন

ডেটা-ওরিয়েন্টেড ডিজাইনের প্রচুর মূল লক্ষ্যটি প্রদর্শিত হবে, অন্তত এক নজরে, বিপজ্জনকভাবে অকাল অপটিমাইজেশনের কাছাকাছি। অভিজ্ঞতা প্রায়শই আমাদের শেখায় যে এই জাতীয় মাইক্রো-অপ্টিমাইজেশানগুলি হিন্দ্দৃষ্টিতে সর্বোত্তমভাবে প্রয়োগ করা হয় এবং একটি প্রোফাইলার হাতে রয়েছে।

তবুও সম্ভবত ডেটা-ওরিয়েন্টেড ডিজাইনের কাছ থেকে নেওয়া শক্তিশালী বার্তা হ'ল এই জাতীয়করণের জন্য জায়গা ছেড়ে যাওয়া। ডেটা-ভিত্তিক মানসিকতা এটিকে সহায়তা করতে পারে:

_{ডেটা-ওরিয়েন্টেড ডিজাইন আরও কার্যকর উপস্থাপনাগুলি অন্বেষণ করতে শ্বাস প্রশ্বাসের ঘর ছেড়ে যেতে পারে। এটি একসাথে মেমরি বিন্যাসের নিখুঁততা অর্জন সম্পর্কে নয়, ক্রমবর্ধমান-অনুকূল উপস্থাপনার অনুমতি দেওয়ার জন্য যথাযথ বিবেচনা করা আগে থেকেই করা more}

গ্রানুলার অবজেক্ট-ওরিয়েন্টেড ডিজাইন

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

_{অবজেক্ট-ওরিয়েন্টেড ডিজাইনের সমস্যাটি হ'ল এটি আমাদের প্রায়শই খুব দানাদার স্তরে ইন্টারফেসগুলি মডেল করতে প্ররোচিত করে, আমাদের সমান্তরাল বাল্ক মানসিকতার পরিবর্তে স্কেলার, এক-সময়ে-সময়ে মানসিকতার সাথে আটকে রাখে।}

অতিরঞ্জিত উদাহরণ হিসাবে, ভাবুন কোনও চিত্রের একক পিক্সেলের জন্য কোনও অবজেক্ট-ওরিয়েন্টেড ডিজাইন মানসিকতা প্রয়োগ করা হয়েছে।

class Pixel
{
public:
    // Pixel operations to blend, multiply, add, blur, etc.

private:
    Image* image;          // back pointer to access adjacent pixels
    unsigned char rgba[4];
};

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

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

এখন এই ব্যাক পয়েন্টার ব্যতীত C ++ প্রসঙ্গে তাত্ক্ষণিকভাবে ওভারহেড অর্থে কোনও শ্রেণীর সাথে কিছুই নেই। অপ্টিমাইজ করা সি ++ সংকলকগুলি আমাদের নির্মিত সমস্ত কাঠামো গ্রহণ করে এবং এটিকে স্মিথেনেন্সে নামিয়ে দেওয়ার ক্ষেত্রে দুর্দান্ত।

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

সমাধান: গ্রানুলার পিক্সেলের অবজেক্ট-ভিত্তিক কাঠামোটি বিলুপ্ত করুন এবং মোটা স্তরের পিক্সেলের (চিত্রের স্তরের) সাথে লেনদেন করার জন্য আপনার ইন্টারফেসগুলির মডেলিং শুরু করুন ing

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

একটি মোটা স্তরে ডিজাইন করা

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

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

ডেটা-ওরিয়েন্টেড ডিজাইনটি প্রায়শই বিপুল পরিমাণে মডেলিংয়ের ডেটা তৈরির জন্য ডেটা কোলেসিংয়ের ধারণা দিয়ে শুরু হয়। অনুরূপ মানসিকতা ইন্টারফেস ডিজাইনের প্রতিধ্বনি করে যা এর সাথে থাকে।

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

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

Answer 3

আপনি যা বর্ণনা করেছেন তা হ'ল একটি বাস্তবায়ন সমস্যা। ওও ডিজাইন বাস্তবায়নের সাথে স্পষ্টভাবে উদ্বিগ্ন নয় ।

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

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

অন্যান্য কৌশল দ্বারা উপাদানগুলির কার্যকর সংযোজন / অপসারণ সাধন করা যেতে পারে:

• উপাদানগুলি স্থানান্তর না করে মুছে ফেলা সারিগুলির একটি বিটম্যাপ বজায় রাখুন। কাঠামোটি খুব বিরল হয়ে গেলে কম্প্যাক্ট করুন।
• বি-গাছের মতো কাঠামোর মধ্যে যথাযথ আকারের অংশগুলিতে সারিগুলি সজ্জিত করুন যাতে স্বেচ্ছাসেবক অবস্থানগুলিতে সন্নিবেশ বা অপসারণ পুরো কাঠামোটি পরিবর্তন করার প্রয়োজন হয় না।

ক্লায়েন্ট কোডে বল অবজেক্টের একটি ক্রম, বল অবজেক্টের একটি পরিবর্তনীয় ধারক, রেডির ক্রম, একটি এনএক্স 3 ম্যাট্রিক্স ইত্যাদি দেখা যাবে; এগুলি জটিল (তবে দক্ষ) কাঠামোরগুলির কুৎসিত বিবরণের সাথে উদ্বিগ্ন হওয়ার দরকার নেই। অবজেক্ট বিমূর্তি এটি আপনাকে কিনে।

Comments

+1 এওএস সংস্থাটি একটি দুর্দান্ত সত্তা-ভিত্তিক এপিআই-তে পুরোপুরি সংশোধনযোগ্য, যদিও আপনি যদি ছদ্ম-পয়েন্টারের মাধ্যমে সুসংগত সত্তাকে জাল না করতে চান তবে স্বীকার করা এটি ( ball->do_something();বনাম ball_table.do_something(ball)) ব্যবহার করা কৃপণ হয়ে ওঠে (&ball_table, index)।

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

— 16807

Answer 4

সংক্ষিপ্ত উত্তর: আপনি সম্পূর্ণরূপে সঠিক এবং এই জাতীয় নিবন্ধগুলি এই পয়েন্টটি পুরোপুরি অনুপস্থিত।

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

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

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

Comments

ডিওডির অর্থ সর্বদা স্ট্রাকচার-অফ-অ্যারের (SoA) বিন্যাস নয়। এটি সাধারণ, কারণ এটি প্রায়শই অ্যাক্সেস প্যাটার্নের সাথে মেলে তবে যখন অন্য লেআউটটি আরও ভাল কাজ করে, তখন তা ব্যবহার করুন। ডিওডি হ'ল ডেটা ছড়িয়ে দেওয়ার নির্দিষ্ট পদ্ধতির চেয়ে অনেক বেশি সাধারণ (এবং ফুজিয়ার)। এছাড়াও, আপনি যে নিবন্ধটি উল্লেখ করেছেন এটি সর্বোত্তম উত্স থেকে দূরে এবং এর ত্রুটি রয়েছে, এটি SoA লেআউটগুলির বিজ্ঞাপন দেয় না । "এ" গুলি এবং "বি" গুলি পুরোপুরি বৈশিষ্ট্যযুক্ত হতে পারে Ballপাশাপাশি তারা স্বতন্ত্র floatএস বা vec3এস হতে পারে (যা তারা নিজেরাই SoA- রূপান্তরের বিষয় হতে পারে)।

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

@ ডেলান: আপনার মন্তব্যের জন্য ধন্যবাদ, আপনি সম্ভবত সঠিক যে আমার "ডিওডি" এর পরিবর্তে "সোয়া" শব্দটি ব্যবহার করা উচিত ছিল। আমি আমার উত্তর অনুসারে সম্পাদনা করেছি।

— ডক ব্রাউন 16

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

এবং এই github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md যা SoA থেকে / এওএস এর উদাহরণ থেকে স্বয়ংক্রিয়ভাবে রূপান্তর করেছে: reddit.com/r/rust/comments/2t6xqz/… এবং তারপরে এই আছে: খবর। ycombinator.com/item?id=10235766

— জেরি যেরেমিয়া