প্রোগ্রামিং এর কোন ক্ষেত্রে অ্যালগরিদম রান সময় আসলে একটি গুরুত্বপূর্ণ সমস্যা?


15

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

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


1
LMAX বিপর্যয়কারী আপনার আগ্রহী হতে পারে: infoq.com/preferencesations/LMAX

"অ্যালগরিদমিক বাণিজ্য" একটি খারাপ উদাহরণ। অ্যালগরিদমগুলি প্রায়শই তুচ্ছ; চূড়ান্ত অ্যালগরিদম ডিজাইনের চেয়ে সামগ্রিক নিম্ন-বিলম্বিত পারফরম্যান্স উত্সর্গীকৃত সম্পদের বিষয়।
এস .লট

6
জটিলতা হ'ল হার্ডওয়্যার সংস্থার চেয়ে ডেটা আকার বাড়ার সাথে সাথে সবসময়ই বেশি গুরুত্বপূর্ণ is একটি O(n*log(n))অ্যালগরিদম 30 বছরের পুরানো কম্পিউটারের তুলনায় O(n!)বা O(n*n)আজকের সবচেয়ে ব্যয়বহুল হার্ডওয়্যারের চেয়ে দ্রুত শেষ হবে যদি nযথেষ্ট পরিমাণে বড় হয়।
বনাম

1
আপনি এটির মতো ভাবতে পারেন O(c * f(n))যেখানে ধ্রুবকটি cহার্ডওয়্যারটির অদক্ষতার উপর ভিত্তি করে। আপনার কাছে 1000 গুণ দ্রুত সিস্টেম থাকতে পারে, যেমন nঅনন্তের দিকে যায়, এটি কম-বেশি গুরুত্বপূর্ণ হবে। যদি সন্দেহ হয় যে এটি বড় হতে পারে তবে আমি কোনও দিনের O(10000 * log(n))পরিবর্তে একটি বেছে O(n)নেব n
বনাম

উত্তর:


14

গতি সবসময় চাহিদা হয়। আমার ধারণা আপনি ঠিক আছেন এখানে কয়েকটি উদাহরণ ছিল ঝরঝরে অ্যালগোরিদমগুলির চাহিদা রয়েছে:

  1. ক্রিপ্টোগ্রাফি

  2. বড় ডাটাবেস অনুসন্ধান করা হচ্ছে

  3. বাছাই এবং মার্জ করা

  4. ওয়াইল্ডকার্ড সহ পাঠ্য অনুসন্ধান (অ-সূচিযুক্ত)

  5. নিবিড় গণনা সহ গণিত সমস্যা

  6. ব্যাজ

  7. ডেটা মাইনিং অ্যাপ্লিকেশন

  8. অ্যানিমেশন

  9. এআই

  10. কম্পিউটার ভিশন


2
আমি চিকিত্সা সরঞ্জামের মতো এই "জীবন-সমালোচনামূলক" অ্যাপ্লিকেশনটিতে যুক্ত করতে চাই।
স্টুয়ার্টম্লার্ক

@ স্টুয়ার্টম্লার্ক, আপনি বেশ সঠিক। আমি অটোমেটিক কন্ট্রোল সিস্টেম এবং নেভিগেশন সিস্টেমের কথাও ভুলে গেছি!
NoChance

2
আপনি পাসওয়ার্ড ক্র্যাক করার চেষ্টা না করে গতি ক্রিপ্টোতে মারাত্মকভাবে প্রাসঙ্গিক নয়। আমি প্রথমে "বড় ডাটাবেস" রাখব। ইন্টারনেটে প্রাপ্ত তথ্যের পরিমাণটি বিস্ময়কর। একটি বোবা বড়-ডেটা অ্যালগরিদম এটি অনিবার্য বলে মনে করে একটি ভাল ধারণাটিকে হত্যা করতে পারে।
এসলট

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

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

7

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

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

  • বিশেষত জটিল পরিসংখ্যান বিশ্লেষণ। অদ্বিতীয় অ্যালগরিদম এবং বড় ডেটা সেটগুলির সংমিশ্রণটি বৃহত্তর মন্দা বোঝাতে পারে। কিছু গবেষণার জন্য, এটি কোনও ব্যাপার না, তবে আপনি যদি দ্রুত ঘুরে ফিরে কিছু করার চেষ্টা করছেন? আপনি যখন রাসায়নিক / পারমাণবিক / জৈবিক হুমকি নজরদারি সিস্টেম চালাচ্ছেন তখন সম্ভবত "এটি একটি মাসে সার্ভারটি বন্ধ হয়ে যাবে" a
  • বড় ডেটা সেটগুলিতে ডেটা মাইনিং।
  • অনেক পরিবর্তনশীল জড়িত সিমুলেশন।

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


4

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

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

আরও উপলব্ধ সংস্থান সহ, এটি পরে আরও ডেটা ক্রাঙ্কের প্রয়োজন হতে পারে। আজ আপনার 100,000 লাইন সহ একটি 10 ​​এমবি লগ ফাইল বিশ্লেষণ করতে হবে। এক বছরে আপনার 10,000,000,000 লাইন সহ 100 গিগাবাইট লগ ফাইল থাকতে পারে। যদি সংস্থার শক্তিগুলির চেয়ে ডেটার পরিমাণ দ্রুত বৃদ্ধি পায় তবে আপনি পরে সমস্যাগুলিতে চলে যান।

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

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


4

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

অ্যালগরিদমটি একটি ফার্মাসিউটিক্যাল ল্যাবরেটরিতে একটি নল বাছাই করা রোবট চালাতে ব্যবহৃত হত।

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

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

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


চমৎকার উদাহরণ! আপনি যেমন র‌্যাডিক্স সাজানোর মতো কিছু করেছেন বলে মনে হচ্ছে?
ব্যারি ব্রাউন

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

3

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

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


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

1

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


1

আজকাল অ্যালগরিদম দক্ষতা একটি বড় উদ্বেগ নয় কারণ আমরা দক্ষ অ্যালগরিদম ব্যবহার করছি। আপনি যদি কোনও ও (এন!) অ্যালগরিদম ব্যবহার করেন তবে এটি কোনও ধরণের হার্ডওয়্যারে ধীর হবে।


এটি একটি আকর্ষণীয় দৃষ্টিকোণ। "এটি কোনও সমস্যা নয়, কারণ এটি" এটি একটি ইস্যু, তবে একটি গুরুত্বপূর্ণ বিষয় নয় "না বলে" বলা উচিত নয়।
বাম দিকের বাইরে

1

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

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

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


0

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


0

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

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

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

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

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


0

আমি একবার এমন সমস্যায় পড়েছিলাম যেখানে সাধারণত একটি অ্যালগরিদম O (n) এ চলত, তবে বিরল এবং অত্যন্ত সম্ভাবনাময় পরিস্থিতিতে ও (এন ^ 3) সময়ের প্রয়োজন হবে - "বিরল" পরিস্থিতিগুলির মধ্যে এমন একটি ডিরেক্টরি ছিল যা নামের সাথে যুক্ত ছিল যা বৈধ ছিল একটি অপারেটিং সিস্টেম কিন্তু অন্যটিতে নয়।

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


0

আরও তিনটি উল্লেখ করা হয়নি:

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

2) অনেক অপ্টিমাইজেশন সমস্যা। (সম্পাদনা করুন: যেহেতু আমি এই উত্তরটি লিখেছি আমি একটি আঘাত করেছি My সেই রুটিনে, তখন আমি বুঝতে পারি এটি 2 was n Now এখন এটি n ^ 2 যদিও এটি কখনও কখনও সামান্য অ-অনুকূল ফলাফলও বয়ে আনতে পারে))

3) রিয়েলটাইমগুলিতে যেগুলি অবশ্যই প্রচুর পরিমাণে ডেটা পরিচালনা করে। ডিভিডি বিবেচনা করুন: আপনি সাধারণত 4.7 জিবিতে 2 ঘন্টা ভিডিও পান। একই রেজোলিউশনে একটি আদর্শ ভিডিও ফাইল বিবেচনা করুন: এই 2 ঘন্টা ভিডিওটি সাধারণত 1 জিবি এর আওতায় আসবে। এর কারণ হ'ল যখন ডিভিডি স্পেকটি বিছানো হয়েছিল আপনি যুক্তিসঙ্গত দামের ডিভিডি প্লেয়ার তৈরি করতে পারবেন না যা আরও বেশি আধুনিক ফর্ম্যাটগুলি দ্রুত যথেষ্ট ডিকোড করতে পারে।


0

ওয়েল, সাধারণত যে কোনও অ্যাপ্লিকেশন সুপার কম্পিউটারে চালিত হয় ( সবচেয়ে বড় মেশিনগুলির তালিকা ) যোগ্যতা অর্জন করে। এগুলি বিভিন্ন, তবে এগুলির একটি বৃহত উপক্লাস হ'ল পদার্থবিজ্ঞানের সিমুলেশন:

  • পদার্থবিজ্ঞানের সিমুলেশন:
    • আবহাওয়ার পূর্বাভাস
    • জলবায়ু অনুকরণ
    • বিস্ফোরিত তারা ইত্যাদির সিমুলেশন
    • বিস্ফোরিত সংকেতসমূহের অনুকরণ
    • গাড়ি / প্লেন / ট্রেন ইত্যাদির বায়বীয়তা সংক্রান্ত সিমুলেশনগুলি
    • ...
  • রেডিও টেলিস্কোপ ডেটা থেকে চিত্রগুলি গণনা করা হচ্ছে
  • জৈবিক অ্যাপ্লিকেশন:
    • ডিএনএ সিকোয়েন্স সহ স্টাফ (আমি আসলে সেগুলিতে নেই)
    • প্রোটিন ভাঁজ যেমন জৈব রাসায়নিক পদার্থ
    • স্নায়ু কোষ কীভাবে তথ্য প্রক্রিয়াকরণের জন্য একত্রে কাজ করে তার সিমুলেশনগুলি
    • বাস্তুতন্ত্রের মতো অন্যান্য জটিল ইন্টারঅ্যাকশনগুলির সিমুলেশন
    • ...
  • ...

এগুলি আমার শীর্ষস্থানীয় বিষয়ের শীর্ষস্থানীয়, তবে কেবলমাত্র বিভিন্ন সুপার কম্পিউটারের তালিকাটি পড়ুন এবং বুঝতে পারেন যে এগুলির প্রত্যেকটি একটিরকম ধরণের গণনা সক্ষম করতে তৈরি করা হয়েছে যা এই ধরণের বিশাল মেশিনগুলি ছাড়া সম্ভব না।

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

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