زیاد در آمار در این زمینه ها اغراق میشود.
و این اغراق، و اعدادی که اغلب بصورت بدیهی یا مورد انتظار پذیرفته شده اند، در بعضی جاها جدا مشکل ساز میشود.
بطور مثال در بحث درمورد نوع بهینه سازی مورد نیاز/معقول برای یک برنامه.
در اینطور جاها باید حدود صحیح آمار را فرض قرار داد. چون نتیجه براستی تفاوت میکند.
در علم رایانه، اغلب تاثیر اینطور پارامترها در تاثیر فنی عملی و در نتیجه در تصمیمگیری و انتخاب بهینهء کلی خطی نیست؛ بلکه بعکس بسیار نوسان کننده و با تغییرات شدید و غیر هماهنگ است.
مثلا ما چیزی بنام «دهنهء بطری» یا شاید بقول خودمان «گلوگاه» داریم.
این جاییست که یک محدودیت سیستم شما قرار داد که با رسیدن به مرز ظرفیت و شروع تاثیر آن، بخشها و منابع دیگر سیستم باوجود داشتن ظرفیت بیشتر، عملا غیرقابل استفاده با ظرفیت بیشتری میشوند (حداقل در کاربرد مورد نظر).
اگر شما به این محدودیت رسیده باشید این عامل مهم و دارای اولویت خواهد شد (و در مقابل بخشهای دیگر عملا تا برطرف شدن مشکل در این قسمت ممکن است نادیده گرفته شوند یا دارای اولویت/اهمیت بسیار کمتری از پیش باشند). گرچه تا قبل از آن بهینه سازی استفاده از آن تاثیر اندکی در نتیجهء عملی کلی کارکرد برنامه داشته بوده باشد.
اگر به این محدودیت نرسیده باشید/نزدیک آن باشید، ممکن است پرداختن به بهینه سازی در آن بعد بعلت عدم تاثیر مشهود معقول نباشد.
و شما میتوانید این وقت و انرژی را در جای دیگری که مناسبتر و دارای تاثیر بیشتری است صرف کنید.
ضمن اینکه باید گفت عوامل زیادی با مفهوم کلی بهره برداری بهینه از منابع وجود دارند. منابع نه تنها منابع سخت افزاریست، بلکه وقت و انرژی برنامه نویس هم هست. هرکدام از اینها اهمیت و تاثیر خود را دارند که در هر مورد با شرایط خاص خودش و اعداد مربوطه در فرمول کلی محاسبه میشوند.
و باید درنظر داشت که بعضی اوقات بهینه سازی در یک بعد، رابطهء مخالف (با ضریب نسبی مربوط به هرمورد - کم یا زیاد) با بهینه سازی در بعد دیگر دارد. مثلا بهینه سازی سخت و دقیق و پیچیدهء کد میتواند باعث پایین آمدن خوانایی، بالا رفتن امکان باگ، پایین آمدن قابلیت حمل و گسترش و غیره درمورد برنامه شود، جدای از اینکه میتواند وقت و انرژٰی زیادی از برنامه نویس صرف کند.
پس باید متوجه این عوامل نیز بود. بهینه سازی در همه چیز وجود دارد.
تصمیم نهایی و میزان و عمق و نوع پرداختن به بهینه سازی در هر بخشی به اعداد و شرایط نسبی مورد خاص بستگی دارند که در فرمول کلی که شامل تمام بهینه سازیها و ابعاد مختلف و ضریب و اولویت های روشن شدهء آنهاست، محاسبه میشود.
این یک مسئلهء کاملا مستند و عملیست. و ضمنا یک مهارت و توانایی برنامه نویس راستین!
بطور مثال در برنامه نویسی در هر زمینه ای اغلب از زبانهای مختلفی استفاده میشود؛ گرچه بتوان آنها را با یک زبان و مثلا بهینه ترین زبان موجود از نظر کارایی سخت افزاری (A) نوشت.
اما بعکس در یک کاربرد ممکن است از یک زبانی که از نظر سخت افزاری چندین برابر کمتر از زبان دیگری بهینه است استفاده کنیم، بخاطر اینکه سرعت و راحتی و امکانات دیگر برنامه نویسی با آن زبان در آن زمینهء خاص بسیار بیشتر/مهمتر هستند.
وقتی این نیازهای مورد خاص در عمل به بهینگی سخت افزاری به اصطلاح بچربند، زبان دیگر انتخاب میشود.
در خیلی موارد ممکن است بهینه سازی های سخت افزاری ای که زبان اولیه (A) در آن مقوله انجام میدهد عملا تاثیر مشهودی نداشته باشد یا تاثیر آن قابل چشم پوشی باشد و بتوان با مقدار کمتر آن نیز کار را به نحو قابل قبول به انجام رساند.
نمونه های ملموس تر از چگونگی این اغراق ها:
بطور مثال درمورد آمارهای اینترنتی ای مثل ترافیک سایت اغلب اغراق میشود.
فرضا تازگی جایی یک نفر سخن از میلیونها کاربر ثبت نام شده و صد یا صدها هزار کاربر آنلاین در لحظه گفته بود؛ برای یک فروم نمونه.
درصورتیکه این آمار از واقعیت بسیار فاصله دارد.
اینطور افراد اغلب در مطالعهء منابع و مثالها و بهینه سازی های ارایه شده در آنها با استدلالهای مربوطه، که ممکن است آنها هم ناشیانه و با پیش فرض و آگاهیهای نه چندان صحیح بیان شده باشند، گمراه شده و آنها را بدون بررسی و تحقیق عملی میپذیرند.
فرضا آمار سایت گوگل را هم نباید با آمار یک سایت فروم معمولی مقایسه کرد!!
بعضی اینطور استدلال میکنند که چه بهتر که برنامهء ما از همه لحاظ بهینه باشد و بتواند در هر شرایطی بهینه باشد و بدون نیاز به دستکاری و تغییر مجدد بکار برده شود.
اما درواقع این با استدلالی که قبلا ارایه کردیم (فرمول عمومی)، رد میشود. یعنی ممکن است در بسیاری شرایط چنین چیزی ممکن نباشد (حداقل بصورت سخت گیرانهء آن). برنامهء شما چطور میتواند با اعداد شرایط دیگری غیر از شرایط موجود و نیاز و کاربرد شما محاسبه شود؟
این درصورتی است که تنها عامل را بهینگی سخت افزاری بدانیم. و بقیه مثل خوانایی و قابلیت حمل و گسترش و منابع انسانی و وقت و انرژی برنامه نویس را اصلا به حساب نیاوریم.
وگرنه مخالفتی با این وجود ندارد که برنامهء ما به بهترین شکل ممکن باشد. وقتی ممکن باشد مسلما چنین میکنیم. اما تعریف این بهترین شکل، تنها با بهینگی سخت افزاری بصورت استفادهء دقیق از بایت به بایت و صدم ثانیهء وقت سی پی یو بدست نمی آید. بخصوص که در شرایط مورد نظر این موارد اصلا در نتیجهء مشاهده شده هیچ تاثیر مشهود یا مهمی هم نگذارند.
اما این بدیهی است که برنامه نویس باید به تمام موارد و پدیده ها و تکنیک های بهینه سازی آگاه و مسلط باشد (حداقل در حیطهء تخصص و کاربردهای مختلف برنامه نویسی خودش) و بتواند هرکدام را بجای خودش بکار ببرد. و ضمنا برنامه نویسی سرسری و سرهم بندی کردن نیز درست نیست (که میتواند منجر به ضعف و عادات بد نیز بشود). پس صحبت ما اینها نبوده!
باید به مسایل فنی نیز توجه داشت؛ یعنی جایی که انواع بهینه سازی ها واقعا معنا پیدا میکنند؛ و جایی که یک عاملی که ظرفیت تاثیر در بهینه سازی برنامه را دارد براستی موثر میشود.
فرضا بسیاری از موارد تنها در شرایط خاص موثر میشوند. مثلا یک موردی که در زمان کوتاه به تعداد بالا تکرار شود. فرضا در یک حلقهء تکرار حداقل چند هزار بار.
بسیاری موارد تنها با داده هایی با شرایط خاصی موثر میشوند؛ چه از نظر حجم و چه از نظر نوع داده. البته اغلب حجم عامل عمومی و مهمی است.
فرضا در پیاده سازی یک دیتابیس بهینه سازی های خاص و پیچیده ای لحاظ میشوند که مسلما درمورد دیگری که یک کاربرد خیلی عادی تر است ممکن است معقول نباشند و حتی براحتی نتیجهء معکوس بدهند!
همانطور که اگر شما سعی کنید یک فایل با حجم بسیار کم (فرضا چند یا چند ده بایت) را با نرم افزارهای فشرده سازی فشرده کنید، حجم آن (فایل فشردهء حاصل) اغلب نه تنها کم نمیشود، بلکه اغلب میتواند بیشتر نیز بشود.
پس یک الگوریتم و روش در هرجایی موثر نیست و حتی میتواند اثر معکوس بدهد.
حال فکر کنید شما چند هزار فایل چند ده بایتی را با چنان برنامه ای به قصد صرفه جویی چند هزار بایتی فشرده کنید؛ نتیجه بجای کاهش، افزایش چند هزار بایت خواهد بود!!
اما اگر بدانید و بقدر کافی دانش و مهارت و دقت و هوشمندی داشته باشید، شاید بتوانید ابتدا آن فایلها را در یک فرمت آرشیو (مانند tar) تبدیل به یک فایل کرده، و سپس فشرده کنید. با اینکار احتمالا چند هزار بایت صرفه جویی خواهید کرد!
سخنی حکیمانه نیز در ارتباط با بهینه سازیهای وسواسی که توسط برنامه نویسان در بعضی زمینه ها انجام میشود جایی خوانده بودم که بدین مضمون بود: شما نمیتوانید چیزی را که نمیتوانید اندازه گیری کنید بهینه کنید!
میگویند در میان برنامه نویسان شایع است که سعی میکنند برنامه هایی را که درواقع از قبل بطور کامل یا قابل قبول بهینه هستند بهینه کنند! (با صرف وقت و انرژی قابل توجه و گاهی مایه گذاشتن از جنبه های دیگری که بدانها اشاره کردیم).
این میتواند علتهای مختلف داشته باشد، منجمله کم دانشی، و اغلب وسواس و همان پیش فرض و عادت کور که بدان اشاره کرده ایم.
برنامه نویس باید منعطف باشد و با دید عینی باز نسبت به هر مورد. دانش و مهارت او مسلما باید در آن زمینه کامل باشد، اما همهء آنها در هرموردی بدرد نمیخورند و مفید نیستند (حتی میتوانند بطور خاص (کمبود دانش در زمینهء شرایط تاثیر و کاربرد بهینه کننده) یا در نتیجهء کلی/عمومی نتیجهء عکس داشته باشند).
برنامه نویسی بسیار شناور است. فرض کردن ثبات و سختی در جایی که اینطور نیست، چیزی جز خطای برنامه نویس نخواهد بود. و چنین برنامه نویسی بحد کافی دانش و مهارت و دید عمیق اصولی و در عین حال بحد کافی کلی ندارد.
و این اغراق، و اعدادی که اغلب بصورت بدیهی یا مورد انتظار پذیرفته شده اند، در بعضی جاها جدا مشکل ساز میشود.
بطور مثال در بحث درمورد نوع بهینه سازی مورد نیاز/معقول برای یک برنامه.
در اینطور جاها باید حدود صحیح آمار را فرض قرار داد. چون نتیجه براستی تفاوت میکند.
در علم رایانه، اغلب تاثیر اینطور پارامترها در تاثیر فنی عملی و در نتیجه در تصمیمگیری و انتخاب بهینهء کلی خطی نیست؛ بلکه بعکس بسیار نوسان کننده و با تغییرات شدید و غیر هماهنگ است.
مثلا ما چیزی بنام «دهنهء بطری» یا شاید بقول خودمان «گلوگاه» داریم.
این جاییست که یک محدودیت سیستم شما قرار داد که با رسیدن به مرز ظرفیت و شروع تاثیر آن، بخشها و منابع دیگر سیستم باوجود داشتن ظرفیت بیشتر، عملا غیرقابل استفاده با ظرفیت بیشتری میشوند (حداقل در کاربرد مورد نظر).
اگر شما به این محدودیت رسیده باشید این عامل مهم و دارای اولویت خواهد شد (و در مقابل بخشهای دیگر عملا تا برطرف شدن مشکل در این قسمت ممکن است نادیده گرفته شوند یا دارای اولویت/اهمیت بسیار کمتری از پیش باشند). گرچه تا قبل از آن بهینه سازی استفاده از آن تاثیر اندکی در نتیجهء عملی کلی کارکرد برنامه داشته بوده باشد.
اگر به این محدودیت نرسیده باشید/نزدیک آن باشید، ممکن است پرداختن به بهینه سازی در آن بعد بعلت عدم تاثیر مشهود معقول نباشد.
و شما میتوانید این وقت و انرژی را در جای دیگری که مناسبتر و دارای تاثیر بیشتری است صرف کنید.
ضمن اینکه باید گفت عوامل زیادی با مفهوم کلی بهره برداری بهینه از منابع وجود دارند. منابع نه تنها منابع سخت افزاریست، بلکه وقت و انرژی برنامه نویس هم هست. هرکدام از اینها اهمیت و تاثیر خود را دارند که در هر مورد با شرایط خاص خودش و اعداد مربوطه در فرمول کلی محاسبه میشوند.
و باید درنظر داشت که بعضی اوقات بهینه سازی در یک بعد، رابطهء مخالف (با ضریب نسبی مربوط به هرمورد - کم یا زیاد) با بهینه سازی در بعد دیگر دارد. مثلا بهینه سازی سخت و دقیق و پیچیدهء کد میتواند باعث پایین آمدن خوانایی، بالا رفتن امکان باگ، پایین آمدن قابلیت حمل و گسترش و غیره درمورد برنامه شود، جدای از اینکه میتواند وقت و انرژٰی زیادی از برنامه نویس صرف کند.
پس باید متوجه این عوامل نیز بود. بهینه سازی در همه چیز وجود دارد.
تصمیم نهایی و میزان و عمق و نوع پرداختن به بهینه سازی در هر بخشی به اعداد و شرایط نسبی مورد خاص بستگی دارند که در فرمول کلی که شامل تمام بهینه سازیها و ابعاد مختلف و ضریب و اولویت های روشن شدهء آنهاست، محاسبه میشود.
این یک مسئلهء کاملا مستند و عملیست. و ضمنا یک مهارت و توانایی برنامه نویس راستین!
بطور مثال در برنامه نویسی در هر زمینه ای اغلب از زبانهای مختلفی استفاده میشود؛ گرچه بتوان آنها را با یک زبان و مثلا بهینه ترین زبان موجود از نظر کارایی سخت افزاری (A) نوشت.
اما بعکس در یک کاربرد ممکن است از یک زبانی که از نظر سخت افزاری چندین برابر کمتر از زبان دیگری بهینه است استفاده کنیم، بخاطر اینکه سرعت و راحتی و امکانات دیگر برنامه نویسی با آن زبان در آن زمینهء خاص بسیار بیشتر/مهمتر هستند.
وقتی این نیازهای مورد خاص در عمل به بهینگی سخت افزاری به اصطلاح بچربند، زبان دیگر انتخاب میشود.
در خیلی موارد ممکن است بهینه سازی های سخت افزاری ای که زبان اولیه (A) در آن مقوله انجام میدهد عملا تاثیر مشهودی نداشته باشد یا تاثیر آن قابل چشم پوشی باشد و بتوان با مقدار کمتر آن نیز کار را به نحو قابل قبول به انجام رساند.
نمونه های ملموس تر از چگونگی این اغراق ها:
بطور مثال درمورد آمارهای اینترنتی ای مثل ترافیک سایت اغلب اغراق میشود.
فرضا تازگی جایی یک نفر سخن از میلیونها کاربر ثبت نام شده و صد یا صدها هزار کاربر آنلاین در لحظه گفته بود؛ برای یک فروم نمونه.
درصورتیکه این آمار از واقعیت بسیار فاصله دارد.
اینطور افراد اغلب در مطالعهء منابع و مثالها و بهینه سازی های ارایه شده در آنها با استدلالهای مربوطه، که ممکن است آنها هم ناشیانه و با پیش فرض و آگاهیهای نه چندان صحیح بیان شده باشند، گمراه شده و آنها را بدون بررسی و تحقیق عملی میپذیرند.
فرضا آمار سایت گوگل را هم نباید با آمار یک سایت فروم معمولی مقایسه کرد!!
بعضی اینطور استدلال میکنند که چه بهتر که برنامهء ما از همه لحاظ بهینه باشد و بتواند در هر شرایطی بهینه باشد و بدون نیاز به دستکاری و تغییر مجدد بکار برده شود.
اما درواقع این با استدلالی که قبلا ارایه کردیم (فرمول عمومی)، رد میشود. یعنی ممکن است در بسیاری شرایط چنین چیزی ممکن نباشد (حداقل بصورت سخت گیرانهء آن). برنامهء شما چطور میتواند با اعداد شرایط دیگری غیر از شرایط موجود و نیاز و کاربرد شما محاسبه شود؟
این درصورتی است که تنها عامل را بهینگی سخت افزاری بدانیم. و بقیه مثل خوانایی و قابلیت حمل و گسترش و منابع انسانی و وقت و انرژی برنامه نویس را اصلا به حساب نیاوریم.
وگرنه مخالفتی با این وجود ندارد که برنامهء ما به بهترین شکل ممکن باشد. وقتی ممکن باشد مسلما چنین میکنیم. اما تعریف این بهترین شکل، تنها با بهینگی سخت افزاری بصورت استفادهء دقیق از بایت به بایت و صدم ثانیهء وقت سی پی یو بدست نمی آید. بخصوص که در شرایط مورد نظر این موارد اصلا در نتیجهء مشاهده شده هیچ تاثیر مشهود یا مهمی هم نگذارند.
اما این بدیهی است که برنامه نویس باید به تمام موارد و پدیده ها و تکنیک های بهینه سازی آگاه و مسلط باشد (حداقل در حیطهء تخصص و کاربردهای مختلف برنامه نویسی خودش) و بتواند هرکدام را بجای خودش بکار ببرد. و ضمنا برنامه نویسی سرسری و سرهم بندی کردن نیز درست نیست (که میتواند منجر به ضعف و عادات بد نیز بشود). پس صحبت ما اینها نبوده!
باید به مسایل فنی نیز توجه داشت؛ یعنی جایی که انواع بهینه سازی ها واقعا معنا پیدا میکنند؛ و جایی که یک عاملی که ظرفیت تاثیر در بهینه سازی برنامه را دارد براستی موثر میشود.
فرضا بسیاری از موارد تنها در شرایط خاص موثر میشوند. مثلا یک موردی که در زمان کوتاه به تعداد بالا تکرار شود. فرضا در یک حلقهء تکرار حداقل چند هزار بار.
بسیاری موارد تنها با داده هایی با شرایط خاصی موثر میشوند؛ چه از نظر حجم و چه از نظر نوع داده. البته اغلب حجم عامل عمومی و مهمی است.
فرضا در پیاده سازی یک دیتابیس بهینه سازی های خاص و پیچیده ای لحاظ میشوند که مسلما درمورد دیگری که یک کاربرد خیلی عادی تر است ممکن است معقول نباشند و حتی براحتی نتیجهء معکوس بدهند!
همانطور که اگر شما سعی کنید یک فایل با حجم بسیار کم (فرضا چند یا چند ده بایت) را با نرم افزارهای فشرده سازی فشرده کنید، حجم آن (فایل فشردهء حاصل) اغلب نه تنها کم نمیشود، بلکه اغلب میتواند بیشتر نیز بشود.
پس یک الگوریتم و روش در هرجایی موثر نیست و حتی میتواند اثر معکوس بدهد.
حال فکر کنید شما چند هزار فایل چند ده بایتی را با چنان برنامه ای به قصد صرفه جویی چند هزار بایتی فشرده کنید؛ نتیجه بجای کاهش، افزایش چند هزار بایت خواهد بود!!
اما اگر بدانید و بقدر کافی دانش و مهارت و دقت و هوشمندی داشته باشید، شاید بتوانید ابتدا آن فایلها را در یک فرمت آرشیو (مانند tar) تبدیل به یک فایل کرده، و سپس فشرده کنید. با اینکار احتمالا چند هزار بایت صرفه جویی خواهید کرد!
سخنی حکیمانه نیز در ارتباط با بهینه سازیهای وسواسی که توسط برنامه نویسان در بعضی زمینه ها انجام میشود جایی خوانده بودم که بدین مضمون بود: شما نمیتوانید چیزی را که نمیتوانید اندازه گیری کنید بهینه کنید!
میگویند در میان برنامه نویسان شایع است که سعی میکنند برنامه هایی را که درواقع از قبل بطور کامل یا قابل قبول بهینه هستند بهینه کنند! (با صرف وقت و انرژی قابل توجه و گاهی مایه گذاشتن از جنبه های دیگری که بدانها اشاره کردیم).
این میتواند علتهای مختلف داشته باشد، منجمله کم دانشی، و اغلب وسواس و همان پیش فرض و عادت کور که بدان اشاره کرده ایم.
برنامه نویس باید منعطف باشد و با دید عینی باز نسبت به هر مورد. دانش و مهارت او مسلما باید در آن زمینه کامل باشد، اما همهء آنها در هرموردی بدرد نمیخورند و مفید نیستند (حتی میتوانند بطور خاص (کمبود دانش در زمینهء شرایط تاثیر و کاربرد بهینه کننده) یا در نتیجهء کلی/عمومی نتیجهء عکس داشته باشند).
برنامه نویسی بسیار شناور است. فرض کردن ثبات و سختی در جایی که اینطور نیست، چیزی جز خطای برنامه نویس نخواهد بود. و چنین برنامه نویسی بحد کافی دانش و مهارت و دید عمیق اصولی و در عین حال بحد کافی کلی ندارد.
هیچ نظری موجود نیست:
ارسال یک نظر