PDA

View Full Version : ارتباط کامپایل شدن یک دستور با اشغال حافظه



میلاد قاضی پور
جمعه 09 مهر 1389, 18:20 عصر
سلام . موقعی که کدی کامپایل میشه بسته به اینکه چه شی ای ایجاد شده و چقدر پیچیدگی در کد وجود داره مقداری از حافظه اشغال میشه . میخوام بدونم کامپایل یک دستور خیلی ساده مثل a=3 چقدر از حافظه اشغال میکنه اصلا آیا اشغال میکنه ؟ در کل میخوام بدونم آیا فقط انواع داده ای هستند که حافظه رو اشغال میکنن یا کامپایل شدن (پردازش جهت تبدیل کد به زبان ماشین) هم قسمتی از حافظه رو اشغال میکنه ؟

eshpilen
جمعه 09 مهر 1389, 18:49 عصر
بالاخره دستوراتی هم که کامپایل میشن نهایتا توی حافظه لود میشن. بنابراین اونا هم حافظه اشغال میکنن. اعم از ثابت هایی مثل رشته ها و اعداد صریح که در برنامه وجود دارن.
اما معمولا در تحلیل ها به فضای متغییرها کار دارن. شاید یک دلیلش این باشه که فضای کد معمولا کم و ثابت هست. مثلا یه برنامه نهایتا چند مگابایت حجم داره، اما ممکنه بصورت دینامیک چند برابر این حافظه رو برای کارهای دیگه اختصاص بده و مصرف کنه. مثلا لود کردن یک فایل حجیم در حافظه، یا اختصاص فضا برای یک پیاده سازی یک الگوریتم که مسئلهء خاصی رو حل میکنه.


میخوام بدونم کامپایل یک دستور خیلی ساده مثل a=3 چقدر از حافظه اشغال میکنه اصلا آیا اشغال میکنه ؟
اگر منظورتون خود دستوری هست که این کار رو انجام میده، بله فضا اشغال میکنه. فضایی که توی فایل اجرایی شما هست و بعد هم توی حافظه باید لود بشه تا برنامه بتونه اجرا بشه.
اما به دلایلی که گفتم معمولا فقط به خود متغییر کار دارن که چقدر فضا برای ذخیره سازی اون عدد نیاز داره.
البته این فقط یک بار در تعریف اولیهء متغییر مطرح هست و بعدا با تخصیص مقادیر دیگه به متغییر مورد نظر تغییر نمیکنه.

میلاد قاضی پور
جمعه 09 مهر 1389, 19:09 عصر
توضیحات روشنگرانه ای بود باز اگه دوستان دیگر هم نظر بدن استفاده میکنیم .

r00tkit
جمعه 09 مهر 1389, 21:08 عصر
سلام

توصیه می کنم کتاب های

Memory Management: Algorithms and Implementation in C/C++

و/یا

Code Optimization: Effective Memory Usage

رو بخونی اولی از بیل بلاندن نویسندهی کتاب معروف rootkit arsenal هستش ( همین یه اسم ادم رو مجبور می کنه کتاب رو تا اخر بخونه ) دومی هم از Kris Kaspersky نویسندهی سری Uncovered هستش و کتاباش واقعا ارزش منده

میلاد قاضی پور
جمعه 09 مهر 1389, 21:43 عصر
خوبه . اما فرصت زیادی نیاز هست برای خوندن این کتب گرانبها . من فصل مموری منیجمنت سیشارپ 2008 رو میخوندم که این سوأل برام پیشومد .

r00tkit
جمعه 09 مهر 1389, 22:21 عصر
من فصل مموری منیجمنت سیشارپ 2008 رو میخوندم
چه کتابی ؟
من خیلی وقته C# کار نکردم ولی اگه می خوای مدیریت حافظه تو .net رو درک کنی کتاب جفری ریچتر(چقدر شبیه جعفر نژاد شد) رو بخونی CLR via C#

حیف که این جا تشکر نداره:لبخند:

xxxxx_xxxxx
جمعه 09 مهر 1389, 22:32 عصر
سلام،
کوچکترین دستورات هم، (مثل همین a = 3) فضایی از حافظه رو در حین کامپایل اشغال می کنند.
توی همین دستور نیاز هست چندین چیز بررسی بشه. از جمله:
a چی هست؟ از چه نوعی هست؟ اگر عددی هست، محدوده اش چقدر هست؟
= چی هست؟
3 چی هست؟
اینها در حین کامپایل و تحلیل لغوی (Lexical Analysis) انجام میشه، بعد از لحاظ نحوی صحت دستور بررسی میشه (Syntax Analysis یا Parsing) و بعد هم از لحاظ معنایی (Semantic Analysis) و بعد کد میانی تولید میشه (IL) بعد هم احتمالاً بهینه سازی کد میانی رو داریم و در نهایت کد ماشین تولید میشه.
طی تمام این مراحل از منابع حافظه استفاده میشه.
زمان انقیاد (Binding Time) که خودش باز چندین نوع هست هم بدون شک از حافظه استفاده میشه.

حمید محمودی
شنبه 10 مهر 1389, 00:30 صبح
سلام،
بحث مموری منجمنت اومد گفتم سوالی رو بپرسم.

فرض کنید برای یک قسمت از برنامه چندین روش کدنویسی وجود داره و خواستیم ببینیم کدوم حافظه کمتری رو مصرف میکنه باید چه کنیم؟؟ (اصلا اینکار شدنیه؟)

یعنی مثلا بیایم برای یه قسمت از برنامه الگوریتم هایی که پیاده سازی میشه کرد رو از لحاظ اینکه کدوم حافظه کمتری میبره بررسی کنیم. آیا برنامه برای اینکار وجود داره که بشه دقیق این مساله(حافظه ای که یه قسمت از برنامه بعد از کامپایل میگیره -- مثلا دوتا باتن گزاشتین توی برنامه و توشون یه کاری رو با دو روش و الگوریتم مختلف پیاده سازی کردید و حالا ببینید که آیا الگوریتم 1 حافظه ی بیشتری میگیره و یا الگوریتم 2 و اونها رو با هم مقایشه کنید) رو مشاهده کرد؟

میلاد قاضی پور
شنبه 10 مهر 1389, 02:20 صبح
سلام،
کوچکترین دستورات هم، (مثل همین a = 3) فضایی از حافظه رو در حین کامپایل اشغال می کنند.
توی همین دستور نیاز هست چندین چیز بررسی بشه. از جمله:
a چی هست؟ از چه نوعی هست؟ اگر عددی هست، محدوده اش چقدر هست؟
= چی هست؟
3 چی هست؟
اینها در حین کامپایل و تحلیل لغوی (Lexical Analysis) انجام میشه، بعد از لحاظ نحوی صحت دستور بررسی میشه (Syntax Analysis یا Parsing) و بعد هم از لحاظ معنایی (Semantic Analysis) و بعد کد میانی تولید میشه (IL) بعد هم احتمالاً بهینه سازی کد میانی رو داریم و در نهایت کد ماشین تولید میشه.
طی تمام این مراحل از منابع حافظه استفاده میشه.
زمان انقیاد (Binding Time) که خودش باز چندین نوع هست هم بدون شک از حافظه استفاده میشه.


خب حالا به نظر شما این حد از اشغال حافظه تا حدی هست که مراقب حجم کدهای نوشته شدمون باشیم و قید خوانایی رو بزنیم یا بهتره کدهامونو کامل بنویسیم و در نسخه ریلیز خودش همه چیو ردیف میکنه ؟

میلاد قاضی پور
شنبه 10 مهر 1389, 02:22 صبح
سلام،
بحث مموری منجمنت اومد گفتم سوالی رو بپرسم.

فرض کنید برای یک قسمت از برنامه چندین روش کدنویسی وجود داره و خواستیم ببینیم کدوم حافظه کمتری رو مصرف میکنه باید چه کنیم؟؟ (اصلا اینکار شدنیه؟)

یعنی مثلا بیایم برای یه قسمت از برنامه الگوریتم هایی که پیاده سازی میشه کرد رو از لحاظ اینکه کدوم حافظه کمتری میبره بررسی کنیم. آیا برنامه برای اینکار وجود داره که بشه دقیق این مساله(حافظه ای که یه قسمت از برنامه بعد از کامپایل میگیره -- مثلا دوتا باتن گزاشتین توی برنامه و توشون یه کاری رو با دو روش و الگوریتم مختلف پیاده سازی کردید و حالا ببینید که آیا الگوریتم 1 حافظه ی بیشتری میگیره و یا الگوریتم 2 و اونها رو با هم مقایشه کنید) رو مشاهده کرد؟
__________________

فکر کنم برای اونم باید بین کدهامون برنامه بنویسیم که برامون دو تا روش رو حساب کنه بده .... چی گفتی اینو عمه هامونن میدونن ؟ اوکی...

حمید محمودی
شنبه 10 مهر 1389, 13:26 عصر
نه بابا اون بیچاره ها مموری منجمنت چه میدونن چیه؛ جواب شما جواب پرباری بود :لبخند:

اما از شوخی گذشته، راستش بیشتر منظورم بعد از کامپایل بود، که وقتی برنامه رو لود کردیم، بیایم حافظه ای که اون دوتا الگوریتم میگیره رو وقتی روی باتن های فرضی کلیک کردیم محاسبه کنیم. نمیدونم شدنیه یا نه؟

اما اگه درحین کد نویسی هم میشه، چطوریه؟؟ (برای Delphi یا vb6 ، دوستان یه demo دارن ؟؟ )

مرسی

میلاد قاضی پور
شنبه 10 مهر 1389, 15:56 عصر
فکر کنم کلاس یا توابعی وجود داشته باشند که اندازه حافظه اشغال شده توسط هر کلاس یا فیلد یا ... رو که بهش میدیم رو جمع بزنه و بریزه تو یه متغیر نشون بده . کار ‍یچیده ای به نظر نمیاد . مثلا محاسبه ی میزان فضای اشغالی کلاس ایکس که توش چهار تا فیلد از نوع صحیح داره و ما هم میدونیم اینت چقدر فضا میگیره کار سختی نیست . اما من خودم نمیشناسم همچین توابعی رو که معرفی کنم خدمت شما .

xxxxx_xxxxx
شنبه 10 مهر 1389, 16:42 عصر
خب حالا به نظر شما این حد از اشغال حافظه تا حدی هست که مراقب حجم کدهای نوشته شدمون باشیم و قید خوانایی رو بزنیم یا بهتره کدهامونو کامل بنویسیم و در نسخه ریلیز خودش همه چیو ردیف میکنه ؟
بستگی به این داره که برنامه شما قرار هست چه کاری رو انجام بده و در کجا استفاده بشه.
یه موقع هست که On-time بودن (و شاید Real-time بودن) برای شما اهمیت داره و هر بار واکشی و درج اطلاعات در حافظه هزینه بر هست در نتیجه کاهش Performance رو داریم. در این جور مواقع برای بهینه سازی باید خوانایی برنامه رو فدای Performance کنیم.

ولی در اغلب اوقات نیازی به این بهینه سازی های سخت گیرانه نیست.
وقتی از روی اصول برنامه نویسی کنیم، مطمئن باشید که بهترین زمان کامپایل رو داریم و بهترین کد ماشین رو تولید می کنیم.
برخی اوقات نا خواسته کاری رو انجام میدیم که هزینه زیادی رو در بر داره، رجوع بی مورد (ناخواسته) به کتابخانه ها یکی از شایع ترین مواردی هست که من می بینم.

بعضی وقت‌ها هم فکر می کنیم که اگر فلان کار رو انجام بدیم از لحاظ زمانی و یا اشغال حافظه یک جور بهینه سازی انجام دادیم در حالی که ممکنه هیچ تفاوتی نکنه و شاید بدتر هم بشه. برای اینکه بفهمیم دقیقاً چه کارهایی باعث میشه تا بهینه سازی مون مؤثر واقع بشه باید با ساختار کامپایلری که برنامه رو باهاش کامپایل میکنیم آشنا باشیم. مراحل کامپایل و بهینه سازی هایی که خود کامپایلر انجام میده رو هم درنظر بگیریم.

بعضی دستورات در زمان کامپایل (Compile-time) انجام میشه، بعضی ها هم در زمان اجرا (Run-Time). این دستورات رو باید شناسایی کنیم. اگر زمان کامپایل برای ما اهمیت داره می تونیم برخی کارها رو به زمان اجرا محول کنیم و برعکس.

مثلاً در VB6 یک ماژول طولانی پر از توابع و اشیاء مختلف می نویسم بدون اینکه توجه کنیم که کل محتویات این ماژول هر بار در حین اجرا توی حافظه بارگذاری میشه. در حالیکه میتونیم بخش اعظمی از این ماژول رو در یک Class بنویسیم که هم اصولی تر هست و هم بهینه تر.