কেন এত বেশি বিকাশকারী বিশ্বাস করেন যে কর্মক্ষমতা, পাঠযোগ্যতা এবং রক্ষণাবেক্ষণের সহাবস্থান থাকতে পারে না?


34

এই প্রশ্নের প্রতিক্রিয়া জানাতে গিয়ে আমি ভাবতে শুরু করেছিলাম যে এতগুলি বিকাশকারী কেন বিশ্বাস করেন যে একটি ভাল ডিজাইনের পারফরম্যান্সের জন্য অ্যাকাউন্ট করা উচিত নয় কারণ এটি করার ফলে পাঠযোগ্যতা এবং / অথবা রক্ষণাবেক্ষণের উপর প্রভাব পড়বে।

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

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


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

7
মু। আপনার বক্তব্যকে সমর্থন করে আপনার শুরু করা উচিত যা অনেক বিকাশকারী জোর দিয়েছিলেন যে দক্ষতা অদম্যতার দিকে পরিচালিত করে।
পিটার টেলর

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

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

2
প্রশ্নের জন্য -1। আমি যখন এটি পড়ি তখন আমি ভেবেছিলাম যে এটিই খড়ের একমাত্র সত্য উত্তরটি উড়িয়ে দিতে পারে: "কারণ তারা অজগর ব্যবহার করে না।"
ইনগো

উত্তর:


38

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

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


8
"যখন কেউ এ জাতীয় মতামতকে মোকাবিলা করার চেষ্টা করে, তখন অন্যটিতে চূড়ান্তভাবে দেখা - বা অন্যটি চূড়ান্তভাবে দেখতে সহজ হয়" আমি লোকদের সাথে সমস্ত সময় সমস্যাগুলি ভেবে ভেবে বিপরীত দৃষ্টিভঙ্গি রাখি যখন আমি কেবল পেশাদারদের সাথে সামঞ্জস্য করছি কনস শুধু প্রোগ্রামিংয়ে নয়, সব কিছুতেই in
২:20

1
আমি এ নিয়ে আলোচনা করা সবার পক্ষে এতটাই অসুস্থ যে আমি রেগে গিয়ে চরমপন্থা গ্রহণ করি ..
থমাস বোনিিনি

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

আমার উত্তর ... সবচেয়ে ডেভেলপারদের তাদের কাজ এ খারাপ হয়
TheCatWhisperer

38

আপনার বিকাশকারী উচ্চতর পারফরম্যান্স কোডে কাজ করে এমন পক্ষের পক্ষ থেকে আপনার প্রশ্নটি আসছে, ডিজাইনে বিবেচনা করার জন্য বেশ কয়েকটি বিষয় রয়েছে।

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

এটি সঠিকভাবে পান, এটিকে সুন্দর করুন, দ্রুত পান। সেই জন্য.


আমি থাম্বের নিয়ম পছন্দ করি: 'এটিকে সুন্দর করুন, এটি দ্রুত পান। সেই জন্য'. আমি এটি ব্যবহার শুরু করতে যাচ্ছি।
মার্টিন ইয়র্ক

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

@ কিথবি - আপনি ভাল বক্তব্য রেখেছেন, আমি এটি আমার উত্তরে যুক্ত করব।
জোরিস টিমারম্যানস

+1: "এটি সঠিকভাবে পান, এটি সুন্দর করুন, দ্রুত পান that ক্রমে" " খুব সুন্দর সংক্ষিপ্তসার, যার সাথে আমি 90% সম্মত। আমি কখনও কখনও এটি সুন্দর (এবং আরও বোধগম্য) হয়ে গেলে আমি কেবলমাত্র কিছু নির্দিষ্ট বাগগুলি ঠিক করতে পারি (এটি সঠিক হয়ে উঠুন)।
জর্জিও

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

16

আমি যদি গ্রিনজিটের সুন্দর চিত্রটি "ধার" করতে পারি এবং একটি ছোট সংযোজন করতে পারি:

|
P
E
R
F
O  *               X <- a program as first written
R   * 
M    *
A      *
N        *
C          *  *   *  *  *
E
|
O -- R E A D A B I L I T Y --

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

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


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

2
"বেশিরভাগ প্রোগ্রামের সমস্ত মাত্রায় উন্নতির জন্য প্রচুর জায়গা রয়েছে for"
স্টিভেন

5

স্পষ্টতই যেহেতু উচ্চ সম্পাদনকারী সফ্টওয়্যার উপাদানগুলি সাধারণত অন্যান্য সফ্টওয়্যার উপাদানগুলির চেয়ে আরও জটিলতার অর্ডার (সমস্ত জিনিস সমান হয়ে থাকে)।

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

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

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

একটি ভাল নকশাযুক্ত উপাদান ধরে নিলেও, এটি সর্বদা পারফরম্যান্সের জন্য সুরযুক্ত অনুরূপ উপাদানগুলির চেয়ে কম জটিল হবে (সমস্ত জিনিস সমান হচ্ছে)।


3

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


2
    |
    পি
    ই
    আর
    এফ
    ও *
    আর * 
    এম *
    এ *
    এন *
    সি * * * * * *
    ই
    |
    ও - পুনঃনির্ধারণযোগ্যতা -

আপনি দেখতে পারেন ...

  • ত্যাগযোগ্য পাঠযোগ্যতা কর্মক্ষমতা বাড়িয়ে তুলতে পারে - তবে কেবলমাত্র এতটা। একটি নির্দিষ্ট বিন্দুর পরে, আপনাকে "রিয়েল" অর্থ আরও ভাল অ্যালগরিদম এবং হার্ডওয়ারের মতো অবলম্বন করতে হবে।
  • এছাড়াও, পঠনযোগ্যতার ব্যয়ে কর্মক্ষমতা হারাতে কিছুটা হলেও ঘটতে পারে। এর পরে, আপনি পারফরম্যান্সকে প্রভাবিত না করে আপনার প্রোগ্রামটিকে যতটা পঠনযোগ্য তাই করতে পারেন। উদাহরণস্বরূপ, আরও সহায়ক মন্তব্য যুক্ত করা কার্য সম্পাদন করে না doesn't

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


1

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


1

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

জিনিসটি বেশিরভাগ ক্ষেত্রে ক্ষেত্রে দ্রুত কোড অন্ধ করার দরকার হয় না। অনেক ক্ষেত্রে আইও বা ব্যবহারকারীর ইন্টারঅ্যাকশন আরও বেশি বিলম্ব ঘটায় তারপরে আপনার অ্যালগরিদম কার্যকর হওয়ার কারণ হয়। মুল বক্তব্যটি হ'ল বোতল ঘাড় যদি আপনি না জানেন তবে কোনও জিনিসকে আরও দক্ষ করে তোলার জন্য আপনার উপায়ের বাইরে যাওয়া উচিত নয়।

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

বিন্দু সামান্য জিনিস যে সম্পর্কে চিন্তা করবেন হয় পারে জিনিষ ভাল করতে। একজন প্রোফাইলার ব্যবহার করুন এবং দেখুন যে 1) আপনার এখন যা আছে তা একটি ইস্যু এবং 2) আপনি যা এটিকে পরিবর্তন করেছেন সেটি একটি উন্নতি ছিল।


1

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

আপনি যখন উচ্চতর পারফরম্যান্সের জন্য লিখেন, কোনও অ্যালগোরিদমিক অপটিজাইজেশন ফিক্স করার পরে, আপনি সেই বিবরণে প্রবেশ করেন যা প্রসঙ্গটি সম্পর্কে আরও বেশি জ্ঞানের প্রয়োজন। এটি স্বাভাবিকভাবেই কোনও প্রোগ্রামারকে অভিভূত করতে পারে যা এই কাজের জন্য যথেষ্ট মনোনিবেশ করে না।


1

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

এটি একটি অর্থনৈতিক নেতিবাচক বাহ্যতা, উপেক্ষা দূষণের এক ধরণের অনুরূপ। সুতরাং মোটেও পারফরম্যান্স সম্পর্কে চিন্তাভাবনার ব্যয় / উপকারের অনুপাতটি মানসিকভাবে বাস্তবতা থেকে বঞ্চিত।

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

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


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

1

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

মাইক্রো-দক্ষতা

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

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

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

কার্যকরী ভাষা

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

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

পঠনযোগ্যতা বনাম রক্ষণাবেক্ষণ

Now এর মত বলল, আমি বিশ্বাস করি পাঠযোগ্যতা এবং maintainability হয় না সুরেলা ধারণা। সর্বোপরি, আমাদের বেশিরভাগ পাঠযোগ্য কোড মানব চিন্তার নিদর্শনগুলির জন্য খুব স্বজ্ঞাত মানচিত্রের মানচিত্র, এবং মানব চিন্তার নিদর্শনগুলি সহজাতভাবে ত্রুটি-প্রবণ: " যদি এটি ঘটে থাকে তবে এটি করুন If যদি তা ঘটে থাকে তবে তা করুন Otherwise অন্যথায় এটি করুন O ওফ! , আমি কিছু ভুলে গেছি! যদি এই সিস্টেমগুলি একে অপরের সাথে যোগাযোগ করে তবে এটি হওয়া উচিত যাতে এই সিস্টেমটি এটি করতে পারে ... ওহ অপেক্ষা করুন, এই ইভেন্টটি যখন ট্রিগার হয় তখন সেই সিস্টেমটির কী হবে?"আমি সঠিক উক্তিটি ভুলে গিয়েছিলাম তবে একজন একবার বলেছিলেন যে রোমটি যদি সফ্টওয়্যারটির মতো তৈরি করা হত তবে এটি কেবল একটি পাখিটিকে একটি দেওয়ালে নেমে যাওয়ার জন্য নেমে যেতে লাগবে। বেশিরভাগ সফ্টওয়্যারের ক্ষেত্রেই এটি ঘটে থাকে often এখানে কিছু আপাতদৃষ্টিতে নিস্পষ্ট কোডের কয়েকটি লাইন এবং এটি আমাদের পুরো ডিজাইনের পুনর্বিবেচনা করার বিষয়টিকে থামিয়ে দিতে পারে, এবং উচ্চ স্তরের ভাষাগুলি যা যতটা সম্ভব পঠনযোগ্য হতে লক্ষ্য করে যেমন মানব নকশার ত্রুটিগুলি ব্যতিক্রম নয় ।

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


1
"মাইক্রো-দক্ষতা" বলতে বাছাইয়ের মতো "" ও (1) মেমরি অ্যাক্সেসের মতো কিছুই নেই "
ক্যালথ

0

একটি সমস্যা হ'ল সীমাবদ্ধ বিকাশকারী সময় মানে আপনি যেটিই অনুকূলিত করতে চান তা অন্য সমস্যার জন্য সময় ব্যয় করা থেকে দূরে সরে যায়।

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


একথাও ঠিক যে আপনি উৎসর্গ করতে আরো সময় কিন্তু শেষ পর্যন্ত আপনি জিজ্ঞাসাবাদ কেন ডেভেলপারদের Emacs প্রোগ্রামিং তাদের সন্তানদের প্রতি ভালোবাসা প্রকাশ করার বন্ধ সময় লাগবে শুরু, এবং যে সময়ে তুমি মূলত থেকে বিগ ব্যাং তত্ত্ব শেলডন
deworde

0

কারণ অভিজ্ঞ প্রোগ্রামাররা শিখেছেন যে এটি সত্য।

আমরা এমন কোডের সাথে কাজ করেছি যা হাতা এবং গড় এবং কার্য সম্পাদনের সমস্যা নেই।

আমরা প্রচুর কোডে কাজ করেছি যে, পারফরম্যান্সের সমস্যাগুলি সমাধান করা খুব জটিল।

একটি তাত্ক্ষণিক উদাহরণ যা মনে আসে তা হ'ল আমার শেষ প্রকল্পটিতে 8,192 টি ম্যানুয়ালি এসআরসিএল টেবিল অন্তর্ভুক্ত ছিল। পারফরম্যান্স সমস্যার কারণে এটির প্রয়োজন ছিল। 1 টেবিল থেকে বাছাই করতে সেটআপটি 8,192 শার্ড থেকে বাছাই করা এবং বজায় রাখার চেয়ে অনেক সহজ।


0

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

এখানে আমি মনে করি সবচেয়ে বিখ্যাত। ভূমিকম্প তৃতীয় এরিনা থেকে নেওয়া এবং জন কারমাককে দায়ী করা হয়েছে, যদিও আমি মনে করি এই ফাংশনটির বিভিন্ন পুনরাবৃত্তি হয়েছে এবং এটি মূলত তাঁর দ্বারা তৈরি করা হয়নি ( উইকিপিডিয়া দুর্দান্ত নয়? )

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
    //      y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

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