মাইক্রো-অপ্টিমাইজিং - বিএডি বনাম গেম ডেভেলপমেন্ট


12

গেম ডেভেলপমেন্টে C / C ++ রয়েছে প্রচুর পরিমাণে, ব্যবসায়িক অ্যাপ্লিকেশন সি # তে # আমি দেখেছি সি / সি ++ devs কীভাবে একটি একক কোড লাইন সমাবেশে অনুবাদ করে সে সম্পর্কে উদ্বেগ প্রকাশ করে। .NET- তে কেউ কেউ খুব কমই আইএল তে যান।

সি # তে "মাইক্রো-অপ্টিমাইজিং" এর উপর ভিত্তি করে দুর্লভ এবং সাধারণত সময় নষ্ট হয়। এটি গেম ডেভলপমেন্টের ক্ষেত্রে বলে মনে হয় না।

বিশেষত কী এই অসঙ্গতি সৃষ্টি করে? গেমস কি অবিচ্ছিন্নভাবে হার্ডওয়্যারের সীমাটি চাপ দেয়? যদি হ্যাঁ, হার্ডওয়্যার উন্নত হওয়ায় আমাদের কি উচ্চ স্তরের ভাষাগুলি গেমিংয়ের শিল্প গ্রহণের প্রত্যাশা করা উচিত?

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


গেম দ্বারা আপ আপডেট আমি আধুনিক, বড় স্কেল বিকাশ মানে। EG MMORPG's, Xbox, PS3, Wii ...


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

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

1
সম্পর্কিত: wiki.c2.com/?PrematureOptimization
পিটার

উত্তর:


17

ব্যবসায় অ্যাপ্লিকেশনগুলিতে, সিপিইউ সবসময় বাধা হয় না। একটি ব্যবসায়িক অ্যাপ্লিকেশন বেশিরভাগ সময় অপেক্ষা করে কাটাত। উদাহরণ:

  1. ডাটাবেস ক্যোয়ারী থেকে ফলাফলের জন্য অপেক্ষা করছে
  2. ওয়েব অনুরোধ শেষ হওয়ার জন্য অপেক্ষা করছে
  3. কোনও ইউআই ক্রিয়া করার জন্য ব্যবহারকারী অপেক্ষা করছে

প্রসেসিং কার্য সম্পাদনকে সর্বোত্তম করে তোলে এমন কোড কেন খুব বেশি মান যুক্ত করে না ts

প্রাথমিক বিবেচনাটি হ'ল:

  1. বাজার করার সময়
  2. সরলতা, অন্য কেউ কোডটি বুঝতে এবং পরিচালনা করতে পারেন

6
আমি সেই কোডটি উল্লেখ করব যে ডেটাবেস কোয়েরিগুলিকে অনুকূল করে যে ব্যবসায়িক অ্যাপ্লিকেশনগুলির ব্যবহারযোগ্যতার উন্নতি করতে পারে।
এইচএলজিইএম

4
+1 টি। ডাটাবেস এবং নেটওয়ার্ক অপ্টিমাইজেশন সাধারণত ব্যবসায়ের অ্যাপ্লিকেশনগুলিতে আরও বেশি ধাক্কা দেয়। উদাহরণস্বরূপ, জেএসএন বনাম এক্সএমএল এবং ডিবি সূচকগুলি
সুর ​​করার পছন্দ

2
+1 তবে আপনার সমীকরণের অন্য দিকটি যুক্ত করা উচিত: গেমের ফ্ল্যাবুইটিটির উপর নির্ভর করে গেমগুলিতে "মেইন লুপ (গুলি)" রেন্ডারিং (গুলি) প্রতিটি মাইক্রোসেকেন্ডকে মূল্য হ্রাস করে তোলে, কারণ গুণটি উপলব্ধিযোগ্য because চোখ এবং অন্যান্য জ্ঞান।
ক্লাইম

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

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

13

ব্যবসায়িক অ্যাপ্লিকেশনগুলিতে মাইক্রোসেকেন্ডগুলির পক্ষে বিষয়টি খুব বিরল। গেমগুলিতে, এটি জীবনের সত্য।

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

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

কেউ তুলনীয়, এবং অনুমানযোগ্য, পারফরম্যান্স না দেওয়া পর্যন্ত উচ্চ স্তরের কোনও ভাষা সি ++ কে কিক করার জন্য আশা করবেন না।


8
উচ্চ-ফ্রিকোয়েন্সি ট্রেডিং অ্যাপ্লিকেশনগুলিতে, মাইক্রোসেকেন্ডগুলি অনেক গুরুত্বপূর্ণ!
কোয়ান্ট_দেব

2
@ কোয়ান্ট: বেশিরভাগ স্ট্রিম-প্রসেসিং অ্যাপ্লিকেশনগুলির মতো - রোবোটিকস, পাওয়ার গ্রিড, রকেট্রি, চিকিত্সা প্রযুক্তি ইত্যাদি a
অ্যারোনআট

@quant_dev: হাই-ফ্রিকোয়েন্সি ট্রেডিং অ্যাপ্লিকেশন হয় খুব বিরল।
molbdnilo

আর না. এগুলি অ্যাকাউন্টিং অ্যাপ্লিকেশনগুলির তুলনায় বিরল, তবে বলে, বিমানের নকশা সফ্টওয়্যার more
কোয়ান্ট_দেব

মাইক্রোসেকেন্ডগুলি ব্যবসায়িক অ্যাপ্লিকেশনগুলিতেও গুরুত্বপূর্ণ, বাধাটি সাধারণত অন্য কোথাও পাওয়া যায় (নেটওয়ার্ক জুড়ে, একটি ডাটাবেস বা ফাইল সিস্টেমে)।
রাবারডাক

9

ঠিক আছে, তাই আপনি সি এবং সি ++ বিকাশকারীকে স্বতন্ত্র রেখাগুলিতে অবলম্বন করতে দেখেছেন। আমি বাজি ধরব যে তারা প্রতিটি লাইন ধরে না।

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

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

প্রচুর লোক রয়েছে যারা সি এবং সি ++ ব্যবহার করেন এবং অনুবাদটির বিবরণ সম্পর্কে খুব বেশি চিন্তা করবেন না যতক্ষণ না এটি যথেষ্ট দ্রুত বলে মনে হচ্ছে।


7

গেমস কি অবিচ্ছিন্নভাবে হার্ডওয়্যারের সীমাটি চাপ দেয়?

হ্যাঁ তারা করে.

যদি হ্যাঁ, হার্ডওয়্যার উন্নত হওয়ায় আমাদের কি উচ্চ স্তরের ভাষাগুলি গেমিংয়ের শিল্প গ্রহণের প্রত্যাশা করা উচিত?

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

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


1
+1 গেমসের একটি ভাল অংশ এই দিনগুলিতে অন্য কারও দ্বারা লিখিত একটি হাইপার-অপ্টিমাইজড ইঞ্জিন স্তর ব্যবহার করে, তারপরে পাইথনের মতো কিছু ব্যবহার করুন, বা জিনিসগুলিকে একসাথে মোড়ানোর জন্য কম মাতাল সি ++ ব্যবহার করুন।
মরগান হের্লোকার

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

7

সি # তে "মাইক্রো-অপ্টিমাইজিং" এর উপর ভিত্তি করে দুর্লভ এবং সাধারণত সময় নষ্ট হয়। এটি গেম ডেভলপমেন্টের ক্ষেত্রে বলে মনে হয় না।

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


0

"গেম" বেশ পরিবেষ্টিত শব্দ। যদি আপনার একটি এমএমওআরপিজি থাকে, ছোট অপ্টিমাইজেশনগুলি অনেক খেলোয়াড়কে প্রভাবিত করে।

গেমাররা হ'ল, এবং সম্ভবত সবসময়, তুলনামূলকভাবে বড় পরিমাণে জিনিসগুলি রিয়েলটাইমে ঘটেছিল once নিশ্চিত; এক সময়, একটি প্রতিক্রিয়াশীল প্যাকম্যান বা টেট্রিস থাকার লক্ষ্য ছিল। তবে তাদের এখনও প্রতিক্রিয়াশীল হতে হয়েছিল। Nowaydays, প্যাকেট-ড্রপিং নেটওয়ার্ক-সংযোগের ওপরে 3 ডিএমএমওআরপিজি।

আমি নিশ্চিত যে অনুকূলিত করতে চান বুঝতে।


0

গেমস ক্রমাগত প্রচুর পরিমাণে পটভূমি প্রক্রিয়াকরণ করে। ব্যবসায়িক অ্যাপ্লিকেশনগুলি না।


4
প্রচুর ব্যবসায়িক অ্যাপস ব্যবহার করবেন না, তাই না?
আমার সঠিক মতামতটি

2
ব্যবসায়ের অ্যাপ্লিকেশনগুলির প্রতি সেকেন্ডে 60 বার তাদের স্থিতি আপডেট করার দরকার নেই তা জানার জন্য যথেষ্ট। তদতিরিক্ত, আমি স্পষ্টভাবে বলেছি "নিয়মিত"।
user16764

2
রিয়েল-টাইম ট্রেডিংয়ের কথা কখনও শুনেছেন?
আমার সঠিক মতামতটি

0

আমি সর্বদা শব্দটি "মাইক্রো-অপ্টিমাইজেশন" পেয়েছিলাম, বরং অস্পষ্ট। মেমোরি লেআউট এবং অ্যাক্সেস প্যাটার্নগুলিতে কিছু নির্দেশ-স্তরের পরিবর্তন যদি অ্যালগরিদমিক জটিলতায় কোনও হ্রাস না করে তাদের হটস্পটগুলি পরিমাপ করে শৃঙ্খলাবদ্ধ পেশাদার থেকে কিছুটা 80 গুণ দ্রুত করে তোলে, এটি কি "মাইক্রো-অপ্টিমাইজেশন"? আমার কাছে এটি একটি "মেগা-অপ্টিমাইজেশন" যা বাস্তব-বিশ্বের ব্যবহারের ক্ষেত্রে 80 গুণ বেশি দ্রুত তৈরি করতে পারে। এই ধরনের অপ্টিমাইজেশনের সাথে মাইক্রোস্কোপিক প্রভাব থাকে যেমন লোকেরা এই বিষয়ে কথা বলতে ঝোঁক।

আমি আর গেমদেদে কাজ করছি না তবে আমি পথের সন্ধানের মতো অঞ্চলে ভিএফএক্স-এ কাজ করি এবং আমি সেখানে বিভিএইচ এবং কেডি গাছের অনেকগুলি বাস্তবায়ন দেখেছি যা একটি জটিল দৃশ্যে প্রতি সেকেন্ডে ~ 0.5 মিলিয়ন রশ্মি প্রক্রিয়াকরণ করে (এবং এটি দিয়ে মাল্টিথ্রেডেড মূল্যায়ন)। মোটামুটিভাবে বলতে গেলে আমি একাধিক রে / সেকেন্ডের নীচে মাল্টিথ্রেড মূল্যায়ন সহ এক মিলিয়ন রে / সেকেন্ডের নিচে রাইসট্র্যাকিং প্রসঙ্গে একটি বিভিএইচ-এর প্রত্যক্ষ বাস্তবায়ন দেখতে পাই। এম্ব্রির একটি বিভিএইচ রয়েছে যা একই हार्डवेयर সহ একই দৃশ্যে 100 মিলিয়ন রশ্মি প্রসেস করতে পারে।

এটি পুরোপুরি "মাইক্রো-অপ্টিমাইজেশনের" কারণে যে এম্ব্রি 200 গুণ দ্রুত (একই অ্যালগোরিদম এবং ডেটা কাঠামো), তবে অবশ্যই এটি এত দ্রুত কারণ হ'ল এর পিছনে ইন্টেলের ডেভেলপাররা পেশাদার যারা তাদের প্রোফাইল এবং পরিমাপের উপর ঝুঁকছেন এবং সত্যিই গুরুত্বপূর্ণ যে ক্ষেত্রগুলি সুরক্ষিত। তারা হানির বাইরে কোড উইলি-নিলি পরিবর্তন করছে না এবং পরিবর্তন করেছে যা উল্লেখযোগ্যভাবে অবনমিত রক্ষণাবেক্ষণের জন্য 0.000000001% উন্নতি করেছে। এগুলি বিচার্য হাতে প্রয়োগ করা খুব নির্ভুল অপটিমাইজেশন ছিল - এগুলি ফোকাসের ক্ষেত্রে মাইক্রোস্কোপিক হতে পারে তবে কার্যক্ষেত্রে ম্যাক্রোস্কোপিক।

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

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

যদি হ্যাঁ, হার্ডওয়্যার উন্নত হওয়ায় আমাদের কি উচ্চ স্তরের ভাষাগুলি গেমিংয়ের শিল্প গ্রহণের প্রত্যাশা করা উচিত?

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

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

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

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

উচ্চ স্তর! = কম দক্ষ

এই প্রশ্নে ফিরে আসা:

যদি হ্যাঁ, হার্ডওয়্যার উন্নত হওয়ায় আমাদের কি উচ্চ স্তরের ভাষাগুলি গেমিংয়ের শিল্প গ্রহণের প্রত্যাশা করা উচিত?

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

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

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

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


0

সি # তে "মাইক্রো-অপ্টিমাইজিং" এর উপর ভিত্তি করে দুর্লভ এবং সাধারণত সময় নষ্ট হয়। এটি গেম ডেভলপমেন্টের ক্ষেত্রে বলে মনে হয় না।

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

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

  1. অতিরিক্ত অর্থ ব্যয় কয়েক সেকেন্ড দ্রুত গতিতে একই ব্যবসায়িক মূল্য সরবরাহ করতে ব্যয় করেছে। গতির উন্নতিতে সংরক্ষিত অর্থটি অর্থের আলাদা পুল (ব্যবহারকারীর সময়) থেকে আসে তাই ব্যবসায়টি যে ব্যয় করে তা সাধারনত উপকৃত হয় না, ক্লায়েন্টটি ব্যবসায় ব্যয় করে does
  2. সাধারণত ব্যবসায়িক প্রোগ্রামারগুলির সামগ্রিক ব্যবসায়িক প্রক্রিয়াতে খারাপ দৃশ্যমানতা থাকে, তাই একক পদক্ষেপের অপ্টিমাইজেশান সামগ্রিক প্রক্রিয়াটির জন্য ভাল সুবিধা অর্জন করতে পারে না। উদাহরণস্বরূপ, আপনি যদি 3% প্রসেস 10x দ্রুত করেন তবে আপনি সম্পূর্ণ প্রক্রিয়াটি 2.7% বাড়িয়ে দিয়েছেন।
  3. সাধারণত ব্যবসায়ের বাকী কাজের একটি বৃহত তালিকা রয়েছে যার কিছু ব্যবসায়িক মূল্য রয়েছে এবং এটি (সম্ভবত) অল্প সময়ে একই মান সরবরাহ করার পরিবর্তে সেই মানটি যুক্ত করা অগ্রাধিকার দেবে।

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

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

সুতরাং ব্যবসায়ের ক্ষেত্রে, 4 পদক্ষেপের ব্যবসায়িক প্রক্রিয়া রূপটি 0.6 সেকেন্ড বা 0.5 সেকেন্ডে উপস্থাপন করে কিনা কেউই পাত্তা দেয় না। গেমিংয়ের সময়, কেউ যদি 200 মিমি গ্রহণের একটি রুটিনকে 100 মিমিতে কার্যকর করতে হ্রাস করতে পারে সেদিকে নজর দেয়।

এগুলি ক্লায়েন্টকে দেওয়া মূল্য, ক্লায়েন্টের প্রয়োজনীয়তা এবং পরিবর্তনের ব্যয়-বেনিফিটের অনুপাত সম্পর্কে।


-1

কেন সেই সরঞ্জামটি কোনও নির্দিষ্ট কাজের জন্য বেছে নেওয়া হয়েছিল তার সাথে এটিই করতে হবে।

গল্ফাররা দিকনির্দেশটি অনুগ্রহ করবে এবং চালক ব্যবহার করার সময় তারা কোনও পটারের সাথে প্রয়োগ করতে বাধ্য করবে।

কেন? কারণ তারা বিভিন্ন ধরণের শট। ড্রাইভের জন্য, আপনি এটিকে সর্বোচ্চ দূরত্বে দিয়ে ফেয়ারওয়েতে পেতে চান। একটি পুটের জন্য, আপনি এটি ঠিক গর্তে পেতে চান।

একই প্রয়োগ এখানে। গেম ডেভেলপাররা সি ++ পছন্দ করে কারণ এটি তাদেরকে বিভিন্ন ক্রিয়াকলাপের কার্যকারিতা নিয়ন্ত্রণ করে। আপনি যদি এটি বেছে নিয়ে থাকেন তবে আপনি এটির সুবিধা নিতে চান।


-3

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

নোট করুন যে এক্সেল-এর মতো একটি জন শ্রোতাদের লক্ষ্য করে একটি ব্যবসায়িক অ্যাপ্লিকেশন ভারীভাবে অনুকূলিত হয়েছে।

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