একটি অব্যবহৃত সদস্যের পরিবর্তনশীল কী স্মৃতি গ্রহণ করে?

Question 1

কোনও সদস্যের পরিবর্তনশীল আরম্ভ করা এবং রেফারেন্সিং / এটি ব্যবহার না করে রানটাইম চলাকালীন আরও র‌্যাম গ্রহণ করে, বা সংকলকটি কেবল সেই পরিবর্তনশীলটিকে উপেক্ষা করে?

struct Foo {
    int var1;
    int var2;

    Foo() { var1 = 5; std::cout << var1; }
};

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

Question 2

সোনালি সি ++ "হিসাবে-ইফ" নিয়ম ^{1 তে} উল্লেখ করা হয়েছে যে, যদি কোনও প্রোগ্রামের পর্যবেক্ষণযোগ্য আচরণটি অব্যবহৃত ডেটা-সদস্যের অস্তিত্বের উপর নির্ভর করে না, তবে সংকলকটিকে এটিকে অপ্টিমাইজ করার অনুমতি দেওয়া হয়েছে ।

একটি অব্যবহৃত সদস্যের পরিবর্তনশীল কী স্মৃতি গ্রহণ করে?

না (যদি এটি "সত্যই" অব্যবহৃত হয়)।

এখন মনে দুটি প্রশ্ন আসে:

পর্যবেক্ষণযোগ্য আচরণ কখন সদস্যের অস্তিত্বের উপর নির্ভর করবে না?
বাস্তব জীবনের প্রোগ্রামগুলিতে কি এই জাতীয় পরিস্থিতি দেখা দেয়?

একটি উদাহরণ দিয়ে শুরু করা যাক।

উদাহরণ

#include <iostream>

struct Foo1
{ int var1 = 5;           Foo1() { std::cout << var1; } };

struct Foo2
{ int var1 = 5; int var2; Foo2() { std::cout << var1; } };

void f1() { (void) Foo1{}; }
void f2() { (void) Foo2{}; }

আমরা যদি জিসিসি-কে এই অনুবাদ ইউনিটটি সংকলন করতে বলি , তবে এটি আউটপুট দেয়:

f1():
        mov     esi, 5
        mov     edi, OFFSET FLAT:_ZSt4cout
        jmp     std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
f2():
        jmp     f1()

f2এর মতোই f1এবং কোনও আসল ধারণ করার জন্য কোনও স্মৃতি কখনও ব্যবহৃত হয় না Foo2::var2। ( ঝনঝনানি একই রকম কিছু করে )।

আলোচনা

কেউ কেউ বলতে পারেন যে এটি দুটি কারণে পৃথক:

এটি খুব তুচ্ছ উদাহরণ,
কাঠামোটি সম্পূর্ণরূপে অনুকূলিত, এটি গণনা করে না।

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

bool insert(std::set<int>& set, int value)
{
    return set.insert(value).second;
}

এটি কোনও ডেটা-সদস্যের (এখানে std::pair<std::set<int>::iterator, bool>::first) অব্যবহৃত হওয়ার সত্য ঘটনা। কি অনুমান? এটি অপ্টিমাইজ করা হয়েছে ( যদি অ্যাসেম্বলিটি আপনাকে কাঁদিয়ে তোলে তবে ডামি সেট সহ সহজ উদাহরণ ))

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

"তবে, আমি যদি এক্স করি, অব্যবহৃত সদস্যকে অপ্টিমাইজ করা হয়েছে তা আসলে সমস্যা!"

এই উত্তরটি বিতর্ক করার জন্য বেশ কয়েকটি মন্তব্য হয়েছে যা ভুল হতে হবে কারণ কিছু ক্রিয়াকলাপ (পছন্দ assert(sizeof(Foo2) == 2*sizeof(int))) কিছু ভেঙে দেবে।

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

পর্যবেক্ষণযোগ্য আচরণকে প্রভাবিত করে এমন অপারেশনগুলির মধ্যে অন্তর্ভুক্ত রয়েছে তবে সীমাবদ্ধ নয়:

এক ধরণের অবজেক্টের আকার ( sizeof(Foo)) গ্রহণ করে,
"অব্যবহৃত" একজনের পরে ঘোষিত ডেটা সদস্যের ঠিকানা নেওয়া,
যেমন একটি ফাংশন দিয়ে বস্তু অনুলিপি করা memcpy,
অবজেক্টের উপস্থাপনা (যেমন এর সাথে memcmp) পরিচালনা করা,
কোনও বস্তুকে অস্থির হিসাবে যোগ্য করে তোলা ,
ইত্যাদি ।

¹⁾

[intro.abstract]/1

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

²⁾ একটি দৃsert়তা পাসিং বা ব্যর্থতা মত।

Question 3

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

^{ঠিক আছে, এটি ধ্রুবক ডেটা বিভাগগুলি এবং এ জাতীয় লেখায়।}

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

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

আপনি যেমন বাইরের বিশ্বের সাথে কোনও ফাংশনের ইন্টারঅ্যাকশনগুলি সংকলকটির কাছে আরও জটিল / অস্পষ্ট করে তুলুন (আরও জটিল ডেটা স্ট্রাকচার গ্রহণ / ফিরিয়ে দিন, উদাহরণস্বরূপ std::vector<Foo>, একটি আলাদা সংকলনের ইউনিটে কোনও ফাংশনের সংজ্ঞাটি আড়াল করুন, ইনলাইনিং নিষিদ্ধ / নিষিদ্ধকরণ ইত্যাদি) , এটি আরও বেশি করে হয়ে যায় যে সংকলকটি প্রমাণ করতে পারে না যে অব্যবহৃত সদস্যটির কোনও প্রভাব নেই।

এখানে কোনও কঠোর নিয়ম নেই কারণ এটি সমস্তই সংকলকটি তৈরি করা অপ্টিমাইজেশনের উপর নির্ভর করে, তবে যতক্ষণ না আপনি তুচ্ছ জিনিস করেন (যেমন ওয়াইএসসির উত্তরে দেখানো হয়) সম্ভবত খুব বেশি সম্ভাবনা রয়েছে যে কোনও ওভারহেড উপস্থিত হবে না, যখন জটিল জিনিসগুলি করছেন (যেমন ফিরে আসা) একটি std::vector<Foo>একটি ফাংশন ইনলাইনিং এর জন্য অত্যন্ত বড় থেকে) সম্ভবত ওভারহেড বহন করতে হবে।

বিষয়টি ব্যাখ্যা করার জন্য, এই উদাহরণটি বিবেচনা করুন :

struct Foo {
    int var1 = 3;
    int var2 = 4;
    int var3 = 5;
};

int test()
{
    Foo foo;
    std::array<char, sizeof(Foo)> arr;
    std::memcpy(&arr, &foo, sizeof(Foo));
    return arr[0] + arr[4];
}

আমরা এখানে নন-তুচ্ছ জিনিসগুলি করি ( বাইট উপস্থাপনার থেকে ঠিকানা গ্রহণ করুন, পরিদর্শন করুন এবং বাইটগুলি যুক্ত করুন ) এবং তবুও অপ্টিমাইজার সনাক্ত করতে পারে যে ফলাফলটি এই প্ল্যাটফর্মে সর্বদা একই থাকে:

test(): # @test()
  mov eax, 7
  ret

সদস্যরা কেবল Fooকোনও স্মৃতি দখল Fooকরেনি , এমন কি একটি অস্তিত্বও আসে নি! যদি এমন অন্যান্য ব্যবহার রয়েছে যা অনুকূলিত করা যায় না তবে উদাহরণস্বরূপ sizeof(Foo)ব্যাপারটি হতে পারে - তবে কেবলমাত্র সেই বিভাগের কোডের জন্য! যদি সমস্ত ব্যবহারগুলি var3এটির মতো অনুকূলিত করা যায় তবে উদাহরণস্বরূপ অস্তিত্ব উত্পন্ন কোডটিকে প্রভাবিত করে না। এটি অন্য কোথাও ব্যবহার করা হলেও, test()অপ্টিমাইজড থাকবে!

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

Question 4

সংকলকটি কেবলমাত্র একটি অব্যবহৃত সদস্য পরিবর্তনশীল (বিশেষত একটি সর্বজনীন) অপ্টিমাইজ করবে যদি এটি প্রমাণ করতে পারে যে ভেরিয়েবলটি অপসারণের কোনও পার্শ্ব প্রতিক্রিয়া নেই এবং প্রোগ্রামটির কোনও অংশ Fooএকই হওয়ার আকারের উপর নির্ভর করে না ।

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

Question 5

সাধারণভাবে, আপনাকে ধরে নিতে হবে যে আপনি যা চেয়েছিলেন তা পেয়েছেন, উদাহরণস্বরূপ, "অব্যবহৃত" সদস্যের ভেরিয়েবলগুলি রয়েছে।

যেহেতু আপনার উদাহরণে উভয় সদস্যই publicতাই সংকলকটি জানতে পারে না যে কিছু কোড (বিশেষত অন্যান্য অনুবাদ ইউনিটগুলি = অন্যান্য * .cpp ফাইলগুলি, যা পৃথকভাবে সংকলিত হয়েছে এবং তারপরে সংযুক্ত রয়েছে) "অব্যবহৃত" সদস্যকে অ্যাক্সেস করবে কিনা।

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

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

এবং যতক্ষণ না আপনি ভাষার গণ্ডির মধ্যে রয়েছেন, ততক্ষণ আপনি পর্যবেক্ষণ করতে পারবেন না যে কোনও বিলোপ ঘটে। ফোন sizeof(Foo)দিলে পাবেন 2*sizeof(int)। আপনি যদি একটি অ্যারে তৈরি করেন Fooতবে পর পর দুটি দুটি অবজেক্টের সূচনার মধ্যে দূরত্ব Fooসর্বদা থাকেsizeof(Foo) বাইট হয়।

আপনার ধরণটি একটি স্ট্যান্ডার্ড লেআউট প্রকার , যার অর্থ আপনি সংকলন-সময় গণিত অফসেট (সিএফ। offsetofম্যাক্রো) এর ভিত্তিতে সদস্যদের উপর অ্যাক্সেস করতে পারেন । তাছাড়া, আপনি একটি অ্যারের সম্মুখের বাইট-বাই-বাইট কপি দ্বারা বস্তুর উপস্থাপনা পরিদর্শন করতে charব্যবহার std::memcpy। এই সমস্ত ক্ষেত্রে, দ্বিতীয় সদস্য সেখানে উপস্থিত থাকতে পারে।

Question 6

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

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

জেআইটি সংকলক সহ সি # / জাভা হিসাবে পরিচালিত ভাষার জন্য সংকলক নিরাপদে এলিড করতে সক্ষম হতে পারে var2 কারণ এটি ব্যবহার করা হচ্ছে কিনা তা অবিকল ট্র্যাক করতে পারে এবং এটি পরিচালনা করা কোডে পালিয়ে যায় কিনা। পরিচালিত ভাষাগুলিতে কাঠামোর দৈহিক আকার প্রোগ্রামারের কাছে রিপোর্ট করা আকারের থেকে আলাদা হতে পারে।

বছর 2019 সি / সি ++ সংকলকগুলি var2স্ট্রাক্ট থেকে এলিড করতে পারবেন না যদি না পুরো স্ট্রাক্ট ভেরিয়েবলটি এলিডে করা হয়। var2কাঠামো থেকে এলিজেনের আকর্ষণীয় ক্ষেত্রেগুলির জন্য উত্তরটি হ'ল: না No.

ভবিষ্যতে কিছু সি / সি ++ সংকলক var2কাঠামো থেকে এলিড করতে সক্ষম হবেন এবং সংকলকগুলির চারপাশে নির্মিত বাস্তুসংস্থানগুলি কম্পাইলারগুলির দ্বারা উত্পাদিত এলিজান তথ্য প্রক্রিয়াটির সাথে খাপ খাইয়ে নিতে হবে।

Question 7

এটি আপনার সংকলক এবং এর অপ্টিমাইজেশন স্তরের উপর নির্ভরশীল।

জিসিসি-তে, আপনি নির্দিষ্ট করে থাকলে -O, এটি নীচের অপ্টিমাইজেশন পতাকাগুলি চালু করবে :

-fauto-inc-dec 
-fbranch-count-reg 
-fcombine-stack-adjustments 
-fcompare-elim 
-fcprop-registers 
-fdce
-fdefer-pop
...

-fdceঘোরা ডেড কোড দূরীকরণ ।

আপনি __attribute__((used))স্থিতিশীল স্টোরেজ সহ একটি অব্যবহৃত ভেরিয়েবলকে সরিয়ে জিসিসি প্রতিরোধ করতে ব্যবহার করতে পারেন :

স্ট্যাটিক স্টোরেজ সহ একটি ভেরিয়েবলের সাথে সংযুক্ত এই অ্যাট্রিবিউটটির অর্থ হ'ল ভেরিয়েবলটি রেফারেন্সযুক্ত না থাকলেও ভেরিয়েবলটি নির্গত করতে হবে।

যখন কোনও সি ++ শ্রেণির টেমপ্লেটের স্থিতিশীল ডেটা সদস্যের জন্য প্রয়োগ করা হয়, তখন গুণাবলীর অর্থ হ'ল সদস্যটি তত্ক্ষণিত হয় যদি শ্রেণি নিজেই ইনস্ট্যান্ট হয়।