পারফরম্যান্স বিবেচনা করার উপযুক্ত সময় কখন?


45

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

এখন প্রশ্নটি হল, আমাদের কি গেম ডেভলপমেন্টে কোডের প্রতিটি লাইনটিতে পারফরম্যান্স সম্পর্কে চিন্তাভাবনা করা উচিত?

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



10
প্রারম্ভে. প্রকল্পটি যখন এগিয়ে চলেছে ততই কার্য সম্পাদন আরও খারাপ হবে।
টমু জাটো

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

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

6
"বিবেচনা" কর্মক্ষমতা যেদিন তুমি করতে সিদ্ধান্ত নেন ঘটতে উচিত পণ্যের যে ব্যবহারকারীদের । ব্যবহারকারীদের ন্যূনতম কর্মক্ষমতা প্রত্যাশা রয়েছে, এবং যদি সেগুলি পূরণ না করা হয়, তবে আপনার পণ্যটি ব্যর্থ হবে। পারফরম্যান্সে ব্যয় হয় এবং পণ্যগুলির বাজেট থাকে । যদি সর্বনিম্ন গ্রহণযোগ্য পারফরম্যান্সের জন্য আপনার বাজেটের চেয়ে বেশি খরচ হয় তবে আপনার প্রকল্প ব্যর্থ হবে । একাদশে একশ নয়, একদিন সে সম্পর্কে চিন্তা করা স্মার্ট।
এরিক লিপার্ট

উত্তর:


90

পারফরম্যান্স জন্য ইঞ্জিনিয়ারিং

  • বিক্রেতার সুপারিশ অনুসরণ করুন।
  • সঠিক ডেটা স্ট্রাকচার ব্যবহার করুন।
  • সঠিক ব্যবহারের ধরণগুলি প্রয়োগ করুন।
  • বোকা কিছু করবেন না।

অপ্টিমাইজেশান

  • ইতিমধ্যে লিখিত কোডটি যখন ধীর গতিতে চলছে তখন এটি পরিমাপ করুন, এটি কেন দ্রুত তৈরি করার জন্য প্রয়োজনীয় কী তা কার্যকর করুন।

অকাল অপটিমাইজেশন

  • পরিমাপ ছাড়াই দ্রুত বা ধীর কী সম্পর্কে অনুমান করুন, কোডটি কীভাবে ডিজাইন করা এবং লিখিত হয়েছে সে সম্পর্কে এই অনুমানগুলি তৈরি করুন।

এই তিনটি জিনিস এক নয়

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

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

উদাহরণস্বরূপ: জিপিইউ বিক্রেতারা সকলেই পরামর্শ দেন যে প্রতিটি ফ্রেম জিপিইউ থেকে রিডব্যাক করা ধীর। আপনার কোডটি রিডব্যাক না করার জন্য ডিজাইন করা অকাল অপ্টিমাইজেশন নয়


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

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

5
পারফরম্যান্সের জন্য সঠিকভাবে ইঞ্জিনিয়ারে ব্যর্থ হওয়াও ডিজাইনটিকে হতাশার মতো ভাবা যেতে পারে। সুতরাং, যদি অকাল অপ্টিমাইজেশান সব মন্দ রুট , কি যে করতে না অকাল pessimization ? ; পি
নিনজালজ

1
@ আর্থার "অপ্টিমাইজেশনের জন্য আরও সময় [বাকি]"? এটির পাশাপাশি দেখার জন্য এটি একটি ভাল উপায়, আপনার নিজের সীমিত বিকাশের সংস্থানগুলি (এবং কর্মপ্রবাহ) অনুকূলিত করে যাতে আপনি আপনার অনুকূলকরণের প্রচেষ্টা থেকে সর্বোত্তম প্রভাব পেতে পারেন! এছাড়াও, আমি জানি আমরা স্ট্যাক ওভারফ্লো সঠিকভাবে নেই, তবে এটি আমাকে অবাক করে দেয় যে আমরা অপ্টিমাইজেশনের কথা বলছি এবং পেরেটো নীতিমালার কোনও উত্তরে এখনও উল্লেখ করা হয়নি ... আমি "শতাংশ" শব্দটিও দেখতে পাই না!
এসি

1
ভাল পারফরম্যান্সের জন্য আপনার ডেটা স্ট্রাকচারগুলি ডিজাইন করার সময়, আপনাকে কম্পিউটারগুলি দক্ষতার সাথে কী করতে পারে এবং কী করতে পারে তা জানতে হবে। উদাহরণস্বরূপ, আধুনিক সিপিইউগুলিতে অ্যারেগুলি লুপিং করা বিপুল পরিমাণ প্রয়োগ করতে পারে বিশেষত আপনি যদি জিনিসগুলি সেট আপ করেন যাতে সংকলকরা এসএসই / এভিএক্সের সাথে স্বয়ংক্রিয়ভাবে ভেক্টরাইজ করতে পারে। (যেমন এক্স স্থানাঙ্ক এবং y স্থানাঙ্ক, XY যুগল structs মধ্যে বা Xyz triples এর অ্যারে না বিন্যাসগুলির ব্যবহারকে অ্যারে দেখুন। stackoverflow.com/tags/sse/info কিছু লিঙ্ক, বিশেষ করে এর জন্য অনিদ্রারোগসংক্রান্ত গেমসে SIMD (GDC 2015)
পিটার Cordes

22

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

একটি ধীর মেশিন ব্যবহার করে আপনি জানতে পারবেন কখন আপনাকে কার্যকারিতা উন্নত করতে হবে।

আমাদের কি গেম ডেভলপমেন্টে কোডের প্রতিটি লাইনে পারফরম্যান্স নিয়ে চিন্তা করা দরকার?

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

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

অন্য কথায়: কিছু "দ্রুত" তৈরি করা অর্থহীন। আপনার লক্ষ্য "দ্রুত যথেষ্ট"। ইতিমধ্যে "দ্রুত যথেষ্ট" এমন কিছু "দ্রুত" তৈরি করা সময়ের অপচয় এবং এমন কিছু "দ্রুত" তৈরি করা যা এখনও "পর্যাপ্ত দ্রুত" নয়, এর অর্থ এটি এখনও খুব ধীর। "দ্রুত" অপ্রাসঙ্গিক, কেবলমাত্র "দ্রুত যথেষ্ট" প্রাসঙ্গিক।


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

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

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

9

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

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

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


3

কমপক্ষে যাওয়ার জন্য আপনার পর্যাপ্ত প্রচেষ্টা করা দরকার "এটি কি সম্ভাব্যরূপে বাধা হয়ে দাঁড়াবে, এবং যদি তা হয় তবে এটি সংশোধন করার ক্ষেত্রে কীভাবে এই পরিবর্তনটি জড়িত হবে?"

সাধারণত বললে, এর মধ্যে যদি সঠিক সিদ্ধান্ত এবং সময় / সংস্থানগুলি খারাপ সিদ্ধান্তগুলি পূর্বাবস্থায় ব্যয় করতে ব্যয় করে তবে সময় / সংস্থানগুলির মধ্যে ভারসাম্য জড়িত।

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

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

  • আমি কি গ্রাফিকাল ফ্রেমরেটে গেম আপডেটের হার বেঁধে দিচ্ছি?
  • আমি কি সিঙ্ক্রোনাস সঞ্চয় বাধ্য করছি?
  • আমি কি জোর করে নিচ্ছি (অ)?

1

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

এটি করার জন্য, না, আপনাকে প্রতিটি লাইনের পরে চিন্তা করতে হবে না।

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

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

সর্বশেষে, আপনি যখন কাজটি সম্পন্ন করেন এবং পরীক্ষাগুলি দেখায় যে আপনি লক্ষ্য ফ্রেম হারটি পূরণ করেন না , আপনাকে অনুকূলিতকরণ করতে হবে। একটি বৃহত্তম বাধা আবিষ্কার করুন যা 90% সময় নেয় এবং এটি অনুকূলিত করে। এটি যদি পর্যাপ্ত না হয় তবে সেকেন্ডটি সর্বাধিক সন্ধান করুন।
আপনি যদি লক্ষ্যটি পূরণ করেন তবে অভিনন্দন। এগিয়ে যান এবং এটি ভুলে যান।


0

বাস্তব পেতে। উত্তরটি পুরোপুরি কোনওভাবেই নেই। কোন আলোচনা নেই।

মূল সমস্যাটি আপনি জিজ্ঞাসার পদ্ধতি:

আমাদের কি গেম ডেভলপমেন্টে কোডের প্রতিটি লাইনে পারফরম্যান্স নিয়ে চিন্তা করা দরকার?

আপনার মানে, কনফিগার পর্দার মতো জিনিসগুলিতেও? একটি ছোট 1 কেবি সর্বোচ্চ কনফিগার ফাইলের জন্য এক সময়ের পার্সারের মতো? সিরিয়াসলি?

আপনার কোডটির বেশিরভাগ সময় কী সমালোচনামূলক তা বিবেচ্য নয়। একটি একক সফ্টওয়্যার নেই যেখানে প্রতিটি একক লাইন সময় সমালোচনামূলক। কোথাও.

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