সাধারণভাবে স্ট্যাকগুলি মুছে ফেলা এবং মেমরি পরিচালনার জন্য হ্যাপ ব্যবহার করা কি সাধারণ সিস্টেমগুলির পক্ষে আরও কার্যকর হতে পারে?


14

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

মডুলারিটি এবং পারফরম্যান্সের মধ্যে বাণিজ্য বন্ধের কথা ভাবেন। আমি জানি যে এই পরিস্থিতিটি বর্ণনা করার সর্বোত্তম উপায় নয় তবে সাধারণভাবে মনে হয় যে আরও ভাল পারফরম্যান্সের সম্ভাবনা থাকলেও বোঝার এবং নকশার সরলতা আরও ভাল বিকল্প হতে পারে।


1
সি এবং সি ++ এ আপনাকে স্পষ্টরূপে মেমরিটি হ্রাস করতে হবে যা গাদাতে বরাদ্দ করা হয়েছিল। এটা সহজ নয়।
ব্যবহারকারী16764

আমি একটি সি # প্রয়োগ বাস্তবায়ন করে প্রকাশ করেছি যে স্ট্যাক অবজেক্টগুলি ভয়াবহ আবর্জনা সংগ্রহের স্তূপের মতো জায়গায় বরাদ্দ করা হয়েছিল। আমার সমাধান? অবিচ্ছিন্ন হিপ মেমোরিতে সম্ভব সমস্ত কিছু (যেমন লুপ ভেরিয়েবল, অস্থায়ী ভেরিয়েবলস ইত্যাদি) সরান । প্রোগ্রামটি 10x র‌্যাম খাই এবং 10x গতিতে চালিত করে।
imallett

@ আইয়ানম্যাললেট: সমস্যা এবং সমাধানের আপনার ব্যাখ্যা আমি বুঝতে পারি না। আপনার কোথাও আরও তথ্যের সাথে একটি লিঙ্ক আছে? সাধারণত আমি স্ট্যাক-ভিত্তিক বরাদ্দটি আরও দ্রুত পাই।
ফ্রাঙ্ক হিলিমান

@ ফ্র্যাঙ্কহিল্যান মূল সমস্যাটি হ'ল: # # আমি ব্যবহার করছিলাম যার ফলে আবর্জনা সংগ্রহের গতি খুব খারাপ ছিল। "সমাধান "টি ছিল সমস্ত ভেরিয়েবলকে অবিচ্ছিন্ন করা যাতে রানটাইমের সময় কোনও মেমরি অপারেশন না ঘটে। আমি সি # / এক্সএনএ বিকাশ সম্পর্কে কিছুক্ষণ আগে একটি মতামত লিখেছিলাম যা প্রসঙ্গে কিছুটাও আলোচনা করে ses
ইমাললেট

@ ইয়ানমালেট: আপনাকে ধন্যবাদ একজন প্রাক্তন সি / সি ++ বিকাশকারী হিসাবে যারা আজকাল বেশিরভাগ ক্ষেত্রে সি # ব্যবহার করেন, আমার অভিজ্ঞতাটি একেবারেই আলাদা। আমি দেখতে পেয়েছি যে গ্রন্থাগারগুলি সবচেয়ে বড় সমস্যা। এটি XBox360 প্ল্যাটফর্ম। নেট বিকাশকারীদের জন্য অর্ধ-বেকড বলে মনে হচ্ছে। সাধারণত আমার যখন সিসির সমস্যা হয় তখন আমি পুলিংয়ের দিকে চলে যাই। এটা সাহায্য করে।
ফ্রাঙ্ক হিলিমান

উত্তর:


30

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

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


2
বাহ এই ভাল ছিল :) সত্যিই সংক্ষিপ্ত এবং একটি শিক্ষানবিশ তথ্যমূলক!
অন্ধকার টেম্পলার

1
অনেকগুলি সিপিইউতে স্ট্যাকটি হার্ডওয়্যারে পরিচালিত হয়, যা ভাষার বাইরে বাইরের একটি সমস্যা তবে এটি রান সময়টিতে একটি বড় ভূমিকা পালন করে।
প্যাট্রিক হিউজেস

@ পেট্রিক হিউজেস: হ্যাঁ, তবে হিপগুলি হার্ডওয়্যারেও রয়েছে, তাই না?
অন্ধকার টেম্পলার 21

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

3
@ ডোনাল ফেলো: সমস্ত সত্য। তবে মুল বক্তব্যটি হ'ল স্ট্যাকস এবং হিপসের উভয়েরই শক্তিশালী এবং দুর্বল পয়েন্ট রয়েছে এবং সে অনুযায়ী সেগুলি ব্যবহার করা সর্বাধিক দক্ষ কোড দেবে।
tmadmers

8

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


আপনি যখন বলছেন যে আধুনিক মেশিনগুলির স্ট্যাকের জন্য হার্ডওয়্যার সমর্থন রয়েছে তখন আপনি কী বলতে চান? স্ট্যাক নিজেই হার্ডওয়্যার মধ্যে আছে, তাই না?
অন্ধকার টেম্পলার

1
x86 স্ট্যাকের সাথে কাজ করার জন্য বিশেষ রেজিস্টার এবং নির্দেশনা রয়েছে। x86 এর স্তূপগুলির জন্য কোনও সমর্থন নেই - এই জাতীয় জিনিসগুলি ওএস দ্বারা তৈরি করা হয়।
পাব্বি

8

না

সি ++ এর স্ট্যাক অঞ্চল তুলনায় অবিশ্বাস্যভাবে দ্রুত। আমি উদ্যোগ নিয়েছি যে কোনও অভিজ্ঞ সি ++ বিকাশকারীরা সেই কার্যকারিতাটি অক্ষম করার জন্য উন্মুক্ত হবে না।

সি ++ সহ আপনার পছন্দ আছে এবং আপনার নিয়ন্ত্রণ রয়েছে। ডিজাইনারগুলি এমন বৈশিষ্ট্যগুলি প্রবর্তন করতে বিশেষভাবে ঝোঁক ছিলেন না যা কার্যকরভাবে কার্যকর করার সময় বা স্থান যুক্ত করে।

সেই পছন্দটি অনুশীলন করা

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

বিকল্প

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

উভয়ই গুরুত্বপূর্ণ, এবং সি ++ আপনাকে প্রতিটি প্রদত্ত দৃশ্যের জন্য কার্যকরভাবে উভয়ই শক্তির ব্যবহার দেয়। এই বলে যে, সি ++ ভাষা আপনার ডিজাইনের জন্য আদর্শ নাও হতে পারে, যদি আপনার ওপিতে এই বিষয়গুলি আপনার পক্ষে গুরুত্বপূর্ণ হয় (উদাহরণস্বরূপ, উচ্চ স্তরের ভাষাগুলি পড়ুন)।


হিপ আসলে স্ট্যাকের মতো একই গতি, তবে বরাদ্দের জন্য বিশেষ হার্ডওয়্যার সমর্থন নেই doesn't অন্যদিকে, প্রচুর পরিমাণে গতি বাড়ানোর উপায় রয়েছে (বেশ কয়েকটি শর্ত সাপেক্ষে যা তাদের বিশেষজ্ঞ-কৌশল হিসাবে তৈরি করে)।
ডোনাল ফেলো

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

6

তারপরে সরলতার জন্য এবং আমরা যদি কিছু নির্দিষ্ট কাজের চাপের সাথে সামান্য পরিমাণে পারফরম্যান্সও হারিয়ে ফেলি তবে কেবল একটি মান (যেমন, গাদা) দিয়ে যাওয়া কি ভাল নয়?

আসলে পারফরম্যান্স হিট সম্ভবত যথেষ্ট হবে!

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

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


5

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


সুতরাং মূলত সি ++ কেবল পাশাপাশি হিপ ব্যবহার করে?
অন্ধকার টেম্পলার

2
@ ডার্ক: কি? না। সিমুলায় স্ট্যাকের অভাব এটি আরও ভাল করার অনুপ্রেরণা ছিল।
ফ্রেডওভারফ্লো

আহ আমি এখন আপনি কি বলতে চাইছেন! ধন্যবাদ +1 :)
অন্ধকার টেম্পলার 21

3

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


2

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

যেহেতু স্ট্যাক বরাদ্দ প্রায় কোনও সময় নেয় না, এমনকি খুব দক্ষ গাদাতে একটি বরাদ্দও 100 কে (যদি 1 এম + না হয়) বার ধীর হবে।

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

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


আপনি যখন বলবেন "স্থানীয় অ্যাপ্লিকেশনটি কতগুলি স্থানীয় ভেরিয়েবল এবং অন্যান্য ডেটা স্ট্রাকচার একটি আদর্শ অ্যাপ্লিকেশন ব্যবহার করে" আপনি অন্য কোন ডেটা স্ট্রাকচারকে বিশেষভাবে উল্লেখ করছেন?
অন্ধকার টেম্পলার

1
"100k" এবং "1M +" মানগুলি কি কোনওভাবে বৈজ্ঞানিক? নাকি এটি "প্রচুর" বলার উপায়?
ব্রুনো রেইস

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

2
"100k (1M + না হলে) বার ধীর"? এটি বেশ খানিকটা অতিরঞ্জিত। এটি ধীরে ধীরে দু'টি অর্ডার হওয়া যাক, সম্ভবত তিনটি, তবে এটি। কমপক্ষে, আমার লিনাক্স একটি কোর i5 এ 6 সেকেন্ডেরও কম সময়ে 100 এম হিপ বরাদ্দ (+ কিছু আশেপাশের নির্দেশাবলী) করতে সক্ষম হবে, যা বরাদ্দ প্রতি কয়েক শতাধিক নির্দেশাবলীর বেশি হতে পারে না - আসলে এটি প্রায় অবশ্যই কম। যদি এটি স্ট্যাকের চেয়ে প্রস্থের ছয়টি অর্ডার ধীর হয় তবে ওএসের হিপ বাস্তবায়নে কিছুটা ভুল রয়েছে। অবশ্যই উইন্ডোজের সাথে অনেক ভুল আছে, তবে তা ...

1
মডারেটর সম্ভবত এই সম্পূর্ণ মন্তব্যের থ্রেডটি মেরে ফেলবে। সুতরাং এখানে চুক্তিটি, আমি স্বীকার করি যে সত্যিকারের সংখ্যাগুলি আমার থেকে সরিয়ে নেওয়া হয়েছে ...., তবে আসুন আমরা সম্মত হই যে সত্যই, সত্যই বড় এবং বেশি মন্তব্য করা উচিত নয় :)
DXM

2

"আবর্জনা সংগ্রহ দ্রুত, তবে একটি স্ট্যাক আরও দ্রুত" আপনার আগ্রহ থাকতে পারে।

http://dspace.mit.edu/bitstream/handle/1721.1/6622/AIM-1462.ps.Z

আমি যদি এটি সঠিকভাবে পড়ে থাকি তবে এই ছেলাগুলি গাদাতে "স্ট্যাক ফ্রেমগুলি" বরাদ্দ করতে একটি সি সংকলক পরিবর্তন করে এবং তারপরে স্ট্যাকটি পপিংয়ের পরিবর্তে ফ্রেমগুলি ডি-বরাদ্দ করতে আবর্জনা সংগ্রহ ব্যবহার করে।

স্ট্যাক-বরাদ্দকৃত "স্ট্যাক ফ্রেমগুলি" হিপ-বরাদ্দ "স্ট্যাক ফ্রেমগুলি" নির্ধারিতভাবে ছাড়িয়ে যায়।


1

কল স্ট্যাক কীভাবে একটি স্তূপে কাজ করবে? মূলত, আপনাকে প্রতিটি প্রোগ্রামে স্তূপের জন্য একটি স্ট্যাক বরাদ্দ করতে হবে, তবে কেন ওএস + হার্ডওয়্যার আপনার জন্য তা করবে না?

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


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

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

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

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

1

স্ট্যাক এবং গাদা উভয়ই প্রয়োজনীয়। এগুলি বিভিন্ন পরিস্থিতিতে ব্যবহৃত হয়, উদাহরণস্বরূপ:

  1. গাদা বরাদ্দকরণের একটি সীমাবদ্ধতা রয়েছে যা আকারের (a [0]) == আকারের (এ [1])
  2. স্ট্যাক বরাদ্দের একটি সীমাবদ্ধতা রয়েছে যে আকারের (ক) সংকলন-সময় ধ্রুবক
  3. গাদা বরাদ্দ লুপ, গ্রাফ ইত্যাদি জটিল ডেটা স্ট্রাকচার করতে পারে
  4. স্ট্যাক বরাদ্দ সময় সংকীর্ণ আকারের গাছগুলি করতে পারে
  5. গাদা মালিকানার ট্র্যাকিং প্রয়োজন
  6. স্ট্যাক বরাদ্দ এবং ডিএলোকেশন স্বয়ংক্রিয়
  7. হিপ মেমরিটি পয়েন্টারগুলির মাধ্যমে সহজেই একটি স্কোপ থেকে অন্য স্কোপ এ যেতে পারে
  8. স্ট্যাক মেমোরি প্রতিটি ফাংশনে স্থানীয় এবং অবজেক্টগুলি তাদের আজীবন প্রসারিত করতে (বা সদস্য ফাংশনের অভ্যন্তরের পরিবর্তে অবজেক্টের ভিতরে সঞ্চিত) আস্তরণের দিকে স্থানান্তরিত হওয়া প্রয়োজন
  9. পারফরম্যান্সের জন্য গাদা খারাপ
  10. স্ট্যাক বেশ দ্রুত
  11. গাদা বস্তুগুলি ফাংশন থেকে মালিকানা গ্রহণকারী পয়েন্টারের মাধ্যমে ফিরে আসে। বা শেয়ারড_পটার্স।
  12. স্ট্যাক অবজেক্টগুলি রেফারেন্সগুলির মাধ্যমে ফাংশন থেকে ফিরে আসে যা মালিকানা নেয় না।
  13. হিপগুলি সঠিকভাবে মুছুন বা মুছতে মুছতে প্রতিটি নতুনের সাথে মিলে যায় []
  14. স্ট্যাক অবজেক্টস আরএআইআই এবং কনস্ট্রাক্টর ইনিশিয়ালেশন তালিকা ব্যবহার করে
  15. হিপ অবজেক্টগুলি কোনও ফাংশনের অভ্যন্তরে যে কোনও বিন্দুতে সূচনা করা যেতে পারে এবং কনস্ট্রাক্টর পরামিতি ব্যবহার করতে পারে না
  16. স্ট্যাক অবজেক্টস আরম্ভের জন্য কনস্ট্রাক্টর প্যারামিটার ব্যবহার করে
  17. হিপ অ্যারে ব্যবহার করে এবং অ্যারের আকার রানটাইমের সময় পরিবর্তন করতে পারে
  18. স্ট্যাক একক বস্তুর জন্য এবং আকারটি সংকলন-সময় স্থির করা হয়

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


1

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

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

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

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