আমি যখন আমার কোডটি লিখি তখন কি আমাকে সংকলিত মেশিন কোড সম্পর্কে চিন্তা করা উচিত?

Question

উদাহরণস্বরূপ আমি নিম্নলিখিত কোড পেয়েছি:

auto z = [](int x) -> int {
    if (x > 0) {
        switch (x) {
            case 2: return 5;
            case 3: return 6;
            default: return 1;
            }
        }
    return 0;
    };

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

Comments

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

— rwong

আপনার সম্পাদনা সমালোচনামূলক পথে না থাকলে আপনার অ্যাসেম্বলি কোডটি ডিবাগ করার দরকার নেই। এছাড়াও, "ক্লিন কোড"! = "ভাল পারফরম্যান্স"।

— BЈовић

দয়া করে আপনার ইন্ডেন্টেশন ঠিক করুন। আমি এটি করার চেষ্টা করেছি, তবে মনে হচ্ছে আপনি কেবল সাদা স্থান সম্পাদনা করতে পারবেন না।

— ক্রিস্টোফার হামার্সট্রিম

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

— ক্রিস্টোফার হামারস্ট্রিম

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

— ডিসেম্বর

Answer 1

আমি যখন আমার কোডটি লিখি তখন কি আমাকে সংকলিত মেশিন কোড সম্পর্কে চিন্তা করা উচিত?

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

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

Comments

+1 সংক্ষিপ্ত, যথাযথ এবং যথারীতি যথারীতি প্রতি ডক অনুসারে অনুসরণ করা যায়, আনন্দিত আমরা এখানে আছি glad

— জিমি হোফা

সম্মত, খুব পরিষ্কার উত্তর।

— CND

Answer 2

ল্যাম্বদা এবং ফান্টেক্টর-শ্রেণীর মধ্যে পছন্দ একটি ট্রেড অফ।

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

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

// define the functor method somewhere
struct some_computer_generated_gibberish_0123456789
{
    int operator() (int x) const
    {
        if (x == 2) return 5;
        if (x == 3) return 6;
        return 0;
    }
};

// make a call
some_computer_generated_gibberish_0123456789 an_instance_of_0123456789;
int outputValue = an_instance_of_0123456789(inputValue);

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

int some_computer_generated_gibberish_0123456789_method_more_gibberish(int x)
{
    if (...) return ...;
    return ...;
}

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

নাম-mangling দৃষ্টিভঙ্গি কিছুটা বিস্বাদ, এবং ল্যামডা জন্য ডিবাগার সমর্থন এখনো তার শৈশবাবস্থায় । এটি কেবলমাত্র আশা করা যায় যে সময়ের সাথে সাথে ডিবাগার সমর্থন আরও উন্নত হবে।

বর্তমানে ল্যাম্বডা কোডটি ডিবাগ করার সর্বোত্তম উপায় হ'ল উত্স কোডের স্তরে, যেমন উত্স ফাইলের নাম এবং লাইন নম্বর উল্লেখ করে ব্রেকআপ পয়েন্টগুলি সমর্থন করে এমন একটি ডিবাগার ব্যবহার করা।

Answer 3

@ ডকব্রাউন দ্বারা উত্তর যুক্ত করতে, মনে রাখবেন যে এই দিনগুলিতে সিপিইউ সস্তা তবে শ্রম ব্যয়বহুল।

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

সুতরাং, পারফরম্যান্স সমালোচনামূলক (এবং তারপরেও রক্ষণাবেক্ষণ বিবেচনা করা দরকার) বাদে আপনার কোডটির অন্য কোনও কিছুর উপরে রক্ষণাবেক্ষণ অনুকূল করতে হবে।

Comments

শুধুমাত্র আংশিক সত্য। যদি আপনার কোড O (n ^ 2) (চতুষ্কোণ) চালায় এবং আপনি এটিকে আরও ভাল করে ও (লগ (এন)) (লোগারিথমিক) বলতে পারেন তবে কোড পরিবর্তন করার সাথে হার্ডওয়ারের কোনও কার্যকারিতা বৃদ্ধি পাবে না। মূল পোস্টার দ্বারা নির্দিষ্ট ক্ষেত্রে এটি খুব সম্ভবত।

— gnash117

@ gnash117 - হ্যাঁ, কোডটি যদি বহুবার চালানো হয় তবে আপনি ঠিক বলেছেন; এটি নির্দেশ করার জন্য আপনাকে ধন্যবাদ। এই ধরনের ক্ষেত্রে, কোডটি স্পষ্টভাবে ডকুমেন্ট করা পারফরম্যান্সের উন্নতি করার সময় এটি বজায় রাখে।

— ধানের ল্যান্ডাউ

"শ্রম ব্যয়বহুল" - সঠিক। আপনার গ্রাহকের সময় খুব গুরুত্বপূর্ণ এবং প্রায়শই ব্যয়বহুল।

— সেরেড