বিগ ও কি আসলেই কিছু যায় আসে?


17

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

গেম প্রোগ্রামিং এবং ইন্ডাস্ট্রির বিশেষত, আসলে কী সবচেয়ে বেশি গুরুত্বপূর্ণ এবং কেন?

তথ্যসূত্রগুলি খুব সহায়ক হবে।


বড়-ও = অপ্টিমাইজেশন। বড় -0 কী ছিল তা নির্ধারণ করার জন্য আমাকে কিছুটা সময় নিয়েছে।
অ্যাটাকিংহোব

12
বিগ-ও "অপটিমাইজেশন" নয়। বিগ-ও হ'ল বিশ্লেষণের একটি ফর্ম যা আপনাকে জানায় যে দক্ষতার দিক থেকে বিভিন্ন অ্যালগরিদম কীভাবে আচরণ করবে, উপাদানগুলির সংখ্যা বৃদ্ধির সাথে সাথে। আরও বিশদের জন্য en.wikedia.org/wiki/Big_O_notation দেখুন ।
জোর্বাথুত

2
আমি আপনাকে আশ্বস্ত করতে পারি যে অক্ট্রি নিয়ে এসেছিল এবং বিএসপি / পিভিএস বিগ-ও সম্পর্কে সব জানত। শেষ পর্যন্ত, একমাত্র বিষয়টি হ'ল অ্যাপ্লিকেশনটির কার্য সম্পাদন। তবে সেখানে পৌঁছতে আপনাকে অ্যালগরিদমের অ্যাসিম্পোটিক জটিলতা সহ প্রচুর ডেটা পরিচালনা করে এমন সমস্ত ধরণের বিষয় বিবেচনা করতে হবে।
drxzcl

1
কখন অনুকূলিত করতে হবে তার নিয়মটি মনে রাখবেন: 1) এটি করবেন না। 2) (কেবল বিশেষজ্ঞরা) এটি এখনও করবেন না।
জারতুস্তর

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

উত্তর:


25

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

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

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

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

আমি অনুমান করি যে এটির পরিমাণ কমছে, যদিও; যে কোনও সময় প্রসেসর এমন কিছু করছেন যা সরাসরি খেলোয়াড়ের পক্ষে উপস্থাপনযোগ্য নয়, এটি সময় নষ্ট করে। প্রসেসর যে পরিমাণ কম্পিউটারের ডেটা কম্পিউটিং করছে তা প্লেয়ারকে দেখানো হবে তা কতটুকু বাড়িয়ে দিচ্ছে ! আপনি খেলোয়াড় দিচ্ছেন।


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

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

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

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

13

আমার থাম্বের নিয়মটি হ'ল আপনি ও (ভীতিজনক) না হলে আপনার অন্যান্য সমস্যাগুলি আরও প্রাসঙ্গিক।

আমার অন্যান্য থাম্বের নিয়মটি হ'ল ডেটা কিং। যদি না আপনি আপনার কোডটিকে বাস্তববাদী ডেটা সেট দিয়ে প্রোফাইল করেন তবে আপনি কেবল অনুমান করছেন।

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


8

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

টনি অ্যালব্রেক্ট থেকে একটি দুর্দান্ত উদাহরণ দেখুন: http://seven-degrees-of-freedom.blogspot.com/2010/07/question-of-sorts.html

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

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

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


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

7

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

এই ক্ষেত্রে আমি ধ্রুবক ফ্যাক্টর গুণক এবং নিম্ন-অর্ডার শর্তগুলির সাথে যতটা উদ্বিগ্ন আমি বিগ-ও-তে তেমন উদ্বিগ্ন নই। রানটাইমের মতো a*n^2 + b*n + c(যা হয় O(n^2)) কোনও ফাংশনের জন্য , আমি প্রায়শই হ্রাস aএবং সম্ভবত মুছে ফেলার সাথে অনেক বেশি উদ্বিগ্ন c। একটি সেটআপ বা টিয়ারডাউন খরচ cআনুপাতিকভাবে বড় বনাম একটি ছোট হয়ে যেতে পারেn

তবে, এটি বলার অপেক্ষা রাখে না যে বিগ-ও (বা আরও বিশেষত বড়-থিটা ) একটি দুর্দান্ত কোড গন্ধ সূচক। একটি দেখুনO(n^4) কোথাও, বা আরও খারাপ O(k^n)জ্যামিতিক সময় দেখুন এবং আপনি অন্যান্য বিকল্প বিবেচনা করছেন তা নিশ্চিত করার সময় এসেছে।

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

একটি সুনির্দিষ্ট উদাহরণ দেওয়ার জন্য: এটি ব্যাকগ্রাউন্ড টাইল-স্ট্রিমিং অ্যালগরিদম সহ সত্যই হাতছাড়া হয়ে গেছে যা 8x8 256-রঙের টাইলগুলি প্রবাহিত করে। ব্যাকগ্রাউন্ডের "স্তরগুলি" এর মধ্যে স্ট্রিমিং বাফারগুলি ভাগ করে নেওয়া দরকারী এবং আমাদের একটি নির্দিষ্ট স্তরে একই বাফার ভাগ করে নেওয়ার মধ্যে তাদের 6 টি পর্যন্ত থাকতে পারে। সমস্যাটি হ'ল প্রয়োজনীয় বাফারের আকার নির্ধারণ করা সমস্ত 6 টি স্তরের সম্ভাব্য অবস্থানের উপর ভিত্তি করে - এবং যদি সেগুলি প্রাথমিক সংখ্যার প্রস্থ / উচ্চতা / স্ক্রোল হার হয় তবে আপনি দ্রুত একটি বিস্তৃত অনুসন্ধানে প্রবেশ শুরু করুন - যা কাছে আসা শুরু করেO(6^numTiles)- যা অনেক ক্ষেত্রে "মহাবিশ্বের চেয়ে বেশি দীর্ঘ হবে" বিভাগে। ভাগ্যক্রমে বেশিরভাগ ক্ষেত্রে মাত্র ২-৩ স্তর রয়েছে তবে তারপরেও আমরা আধ ঘন্টা রানটাইমের উপরে চলে যাই। এই মুহুর্তে, আমরা এই সম্ভাবনার একটি খুব ছোট উপসেট নমুনা করেছি, নির্দিষ্ট পরিমাণ সময় না কাটা পর্যন্ত গ্রানুলারিলিটি বাড়ছে (বা আমরা কাজটি শেষ করেছি, যা ছোট ডাবল-স্তর কনফিগারেশনের জন্য ঘটতে পারে)। আমরা কতবার ভুল প্রমাণিত হয়েছিল তার পূর্বের পরিসংখ্যানের ভিত্তিতে আমরা এই অনুমানটিকে কিছুটা দ্বিধাগ্রস্থ করি এবং তারপরে ভাল পরিমাপের জন্য কিছুটা অতিরিক্ত প্যাডিং যোগ করি।

অন্য একটি মজাদার উদাহরণ: কিছুক্ষণ আগে পিসি গেমটিতে নেতৃত্ব প্রকৌশলী কিছুটা সময় বাদ দিয়ে তালিকাগুলি বাদ দিয়ে পরীক্ষা করেছিলেন । মেমরির ওভারহেড আরও ক্যাশে প্রভাব তৈরি করে, যা পুরো ব্যাপারটিতে এক ধরণের অ-ধ্রুবক গুণক যুক্ত করে - তাই এগুলি সামান্য ক্ষেত্রে মোটেই ভাল পছন্দ নয়'ren । তবে বৃহত্তর সাজানো তালিকার জন্য যেখানে অনুসন্ধানগুলি ঘন ঘন হয়, তারা একটি সুবিধা দেয় provide

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


4

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

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

তবে আমি অলস বোধ করছিলাম তাই আমি প্রতিটি দানবের বিরুদ্ধে প্রতিটি বুলেট তুলনা করি। এমনকি সবচেয়ে জটিল পরিস্থিতিতেও, সংঘর্ষের কোডটি 60fps এ 10% গেমের চেয়ে কম সিপিইউ ব্যবহার করছে using বড়-ও: গুরুত্বহীন।

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

বিগ-ও গেমগুলিতে যেমন গুরুত্বপূর্ণ তেমনি অন্য সমস্ত কিছুর মধ্যে রয়েছে: এটি একেবারে গুরুত্বহীন বলা চলে যতক্ষণ না এটি সমালোচনা না করে।

কিছু কোড লিখুন। যদি এটি খুব ধীর হয়, তবে এটি প্রোফাইল করুন।


3

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

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

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

  1. নিশ্চিত হয়ে নিন যে আপনি প্রতিটি ফ্রেমে নতুন বা ম্যালোক কল করছেন না (এটি সর্বদা # 1 সমস্যা)
  2. কাজ হ্রাস করুন: কম রে কাস্ট, কম ছেলে ইত্যাদি
  3. বিগ-ও অ্যালগোরিদম ধরণের সমস্যা
  4. ক্যাশে সংহতি: বিক্ষিপ্ত মেমরির চেয়ে অ্যারেগুলিতে স্টাফ রাখুন
  5. ডিবাগ মোডে এসটিএল ব্যবহার করবেন না। (এবং আপনি সর্বদা ডিবাগ মোডে কাজ করতে চান)

2

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

স্পষ্টতই, সর্বদা প্রথম প্রোফাইল দিন এবং সর্বশেষটিকে অনুকূলিত করুন (যদি আপনি কোনও বৈশিষ্ট্য সম্ভাব্যতা অধ্যয়ন না করেন)।


1

আপনার সফ্টওয়্যারটিতে বিগ-ও-এর গুরুত্ব হ'ল ও (এন 2 )। এন বাড়ার সাথে সাথে সঠিক অ্যালগরিদম হওয়ার গুরুত্ব আরও বেড়ে যায়। :)


এটি যে অ্যালগরিদমকে প্রায়শই বলা হয় তার উপর নির্ভর করে না ..?
bobobobo

কিছু মাত্রায়. তবে দৌড়াতে যদি 3 দিন সময় লাগে তবে আপনি কেবল একবার ফোন করলে এটি সম্ভবত কিছু যায় আসে না। :)
কাইলোটন

1

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

1) যদি আপনার কাছে দুটি অ্যালগরিদম থাকে যা বেশিরভাগ একই জিনিসটি করে তবে একটিতে আরও ভাল ও রয়েছে, আপনার সম্ভবত সেইটির জন্য যাওয়া উচিত (স্পষ্টতই)

2) বিগ হে অ্যাসিপটোটিক বিশ্লেষণের সাথে সম্পর্কিতN বড় হলেই বিগ-ও কেবল সত্যই প্লে হয় । উদাহরণস্বরূপ, একটি ও (এন) অ্যালগরিদম কোনও ও (এন ^ 2) একের সাথে পারফরম্যান্সে খুব মিল থাকতে পারে .. ছোট এন এর জন্য । যদি আপনি এমন একটি অ্যালগরিদমের কথা বলছেন যা প্রতি ভার্টেক্সে n ^ 2 ক্রিয়াকলাপের প্রয়োজন, তবে n = 2 বা n = 3, তবে সেখানে নেই ক্ষেত্রের একটি হে রয়েছে (ঢ ^ 2) অ্যালগরিদম মধ্যে অনেক পার্থক্য (গ্রহণ 4 এবং 9 অপস রেস্প) এবং একটি হে (এন) এক (2 এবং 3 অপস রেস।) তবে, যদি এন = 9 হয়, তবে আপনি হঠাৎ করে ও (এন ^ 2) অ্যালগরিদমের জন্য 81 টি অপারেশন এবং ও (এন) এর জন্য কেবল 9 টির বিষয়ে কথা বলছেন - এবং যদি এন = 100 হয়, তবে আপনি 100 অপ্স বনাম 10000 সম্পর্কে কথা বলছি - অনেক বড় পার্থক্য।

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


0

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


0

আপনি যখন কোনও গেমের ফাংশন বা কোনও গেমের দিকটি প্রোটোটাইপ করেন, আপনার এটিকে একেবারে অনুকূল করার বিষয়ে চিন্তা করা উচিত নয় ।

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

ঘামবেন না।


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

প্রোটোটাইপিং গেম ডেভেলপমেন্টের কত শতাংশ? অবশেষে আপনি কিছু শিপ করতে চান , তাই না?
ড্যাশ-টম-ব্যাং

0

এটি সর্বস্ব ও শেষ-হওয়া উচিত নয়। তবে এটি সুস্পষ্ট সমস্যাগুলি বাছাই করতে সহায়তা করে যা পারফরম্যান্সের হিটগুলির কারণ হতে পারে; O (n ^ 2) সময়ে কেন কিছু ব্যবহার করবেন, যখন আপনি ও (লগ এন) সময়ে একই জিনিস করতে পারেন?

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


0

গেমের (এবং অন্যান্য বেশিরভাগ) বিকাশে আমরা লুপের জন্য প্রায় এক অতিরিক্ত ক্রিয়াকলাপ শোনাই:

for (int i = 0; i < array.length; i ++) { /* ... */ }

বনাম

for (int i = 0, l = array.length; i < l; i ++) { /* ... */ }

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

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

প্রচলিত সংঘর্ষ সনাক্তকরণ অ্যালগরিদমে, সময় জটিলতা হ'ল এন (বডি) এর মতো হে (এন ^ 2)। তবে এর থেকে আরও ভাল উপায় আছে: বিশ্বকে অনেকগুলি ছোট অংশে আলাদা করুন যাতে কেবল একই অংশের অভ্যন্তরগুলিতে সংঘর্ষ ঘটে। Http://www.videotutorialsrock.com/opengl_tutorial/collision_detection/text.php দেখুন ।

যদি আপনি খেলাটি স্ক্রিপ্টযোগ্য হয় তবে স্ক্রিপ্টারে স্ক্রিপ্টটিতে O (n ^ 2) (এবং উপরে) নম্বর-ক্রাঞ্চিং অ্যালগরিদমগুলি লিখবেন না যেমন ব্যবহারকারীর ব্যাগ অনুসন্ধান করা। পরিবর্তে কোডটিতে একটি অন্তর্নির্মিত ফাংশন তৈরি করুন।


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

-2

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

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


3
এটি ভুল, বিগ হে সংকেতটি লিনিয়ার অ্যালগোরিদমের সমান সমান্তরাল অ্যালগোরিদমের উপরের সীমানা দেখানোর জন্য ব্যবহৃত হয়। বিগ হে সাম্প্রতিক পাঠ / সমবর্তী রাইটিং আর্কিটেকচার ইত্যাদির জন্য ব্যবহার করা যেতে পারে আপনি এমনকি এন ^ 2 প্রসেসরের সাথে ও (1) বাছাই করার মতো পাগল জিনিসগুলি করতে পারেন
ডেভিড ইয়ং

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

3
"এন (2) কে এন। 2 প্রসেসরের সাথে বাছাই করা" আমি সাধারণত অনুভব করি যে আপনি যেভাবেই সমস্যাটি কাটবেন না কেন রিসোর্সের ব্যবহার এখনও ও (এন ^ 2) হওয়ায় এই ব্যবহার বিভ্রান্তিকর। বৃহত সংখ্যক থ্রেডের অর্থ প্রতি সেকেন্ডে কেবলমাত্র বৃহত সংখ্যক সিপিইউ চক্র নয়।
রিচার্ড ফ্যাবিয়ান

ও (1) এ এন ^ 2 প্রসেসরের সাথে বাছাই করা সেরা উদাহরণ নয়, এই ধরণের বিগ-ও সংকেত সম্ভবত প্রায়শই একাডেমিয়ায় দেখা যায়। এই জাতীয় কিছু cs.bu.edu/~best/crs/cs551/homeworks/hw1/pram.html আরও বাস্তবসম্মত সমান্তরাল অ্যালগরিদম লগ (এন) প্রসেসর ব্যবহার করতে পারে। এই ধরণের জিনিসগুলি জিপিইউ প্রসেসিং বা সুপার কম্পিউটিংয়ের ওভারলোডিংয়ের জন্য আরও উপযুক্ত where
ডেভিড ইয়ং

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