سیستم های محاسباتی ناهمگن با بهره گیری از پردازنده مرکزی و کارت گرافیک

[EMP 6,863]

ممنون می‌شوم تعریفی از خطا داشته باشید آیا منظور شما فقط خطا در floating point است یا حتی مواردی چون crash برنامه را نیز شامل می‌شود؟

متاسفانه در برنامه نویسی علمی بسیاری از این ظرایف مورد تووجه قرار نمی‌گیرد نمونه آن نیز استفاده‌از goto در این نرم افزارها است شاید

....

درود

تعریف خطا داستان درازی دارد.

به طور خلاصه:

خطا تعاریف متفاوتی دارد.

Failure ساقط شدن یک عنصر از کارکرد در موقع لازم. یا تولید پاسخ غلط ناشی از بروز fault

Fault وضعیت غیر طبیعی است که می تواند باعث failure بشود.

اختلاف بین نتایج محاسباتی و نتایج درست را Error می نامیم. اشتباه انسانی که باعث fault بشود را هم Error می نامند. در واقع Error لغتی است که developer بکار می برد و bug لغتی است که تستر بعد از کشف fault بکار می برد.

باگ در واقع نتیجه خطا در برنامه سازی است و وقتی به دنیا می آید که تستر درون برنامه fault بیابد.

اصطلاح دیگر Defect هست که در واقع به معنی انحراف از Requirement است. مشکلات سخت افزاری را هم Defect می نامند (مثلا تغییر محتوی حافظه کارت گرافیکی بر اثر برخورد نوترون هم defect حساب می شود)

اگر در Requirement سیستم کارکردی وجود داشته باشد اما در نرم افزار پیاده نشده باشد هم defect گفته می شود.

 

بنابراین اگز برنامه شما crash بکند باز خطایی رخ داده که منجر به آن شده است.

در برنامه سازی برای سیستم های safety-critical شما باید بتوانید برای برنامه خود MTBF بدهید و تستهای شما باید شناسنامه دار باشند. زمان وقوع failure ها و کشف باگ ها هم باید دقیقا ثبت بشود در چرخه حیات نرم افزار.

علاوه بر اینها تست های استاتیک و code review را باید کامل انجام بدهید. حتی برخی از سازمانها Formal verification را هم اجباری می دانند که قیمت هر خط برنامه را خیلی بالاتر از خطی هزار دلار می کند. بعد تست های دینامیک را باید مطابق با استانداردی که دارید انجام بدهید و همه خطوط برنامه را پوشش بدهید. تازه بعد از این فازهای تست هست که برنامه شما که از نظر متریک های ایمنی مثل Mccabe و halstead پیچیدگی کمی دارند، به تسترهای ایمنی داده می شود تا تست هایی مثل death task analysis و fault injection را انجام بدهند.

 

اما در نرم افزار های علمی که خروجی قابل پیش بینی نیست در واقع شما فاقد Test Oracle هستید و پیشگوی پاسخ نرم افزار به ورودی را ندارید تنها راه تست این هست که مدلهایی را که پاسخ آنها را دقیقا می دانید به بعنوان ورودی به نرم افزار بدهید و تست ها را انجام بدهید.

در پردازش موازی به این علت که محیط ممکن است نا همگن باشد و در اجراهای مختلف ممکن است که پردازنده های مختلف قسمتهای مختلفی را اجرا بکنند و تخمین اجباری انتهای اعداد ممیز شناور باعث تولید اعداد متفاوتی به عنوان پاسخ در یک کلاستر می تواند بشود اما در یک کارت گرافیکی یا کلاستری که اعداد ممیز شناور را با استاندارد IEEE754 اموله می کند، احتمال وقوع خطای اینچنین بسیار کاهش می یابد.

 

در مورد استفاده از goto این استفاده ایرادی ندارد اگر در جای خودش استفاده بشود نه اینکه باعث اسپاگتی شدن برنامه بشود.

 

در مورد decompiler ها باید بگویم که برای برنامه های Imperative خیلی فاجعه نیستند اما برای برنامه های OOP کم فایده هستند و بیشتر برای شگستن قفل فایده دارند تا چک کردن صحت کارکرد کامپایلر که وظیف اصلی آنها بوده در بدو پیدایش.

 

در مورد failure های مشهور قبلا من در تاپیک های مختلف خیلی موارد را دکر کرده ام.

فالت شتابسنج آریان 5، فالت نرم افزاری در therac-25 ، فالتهای متعدد و مرگبار در نرم افزارهای حیاتی همه انواع خودورهای تویوتا از سال 2001 تاکنون، مشکل نرم افزاری در 6 فروند اف-22 که در فوریه 2007 رخ داد و همه اویونیک دیجیتال این دسته 6 فروندی از دست رفت. استفاده ناسا از سمافور به جای mutex و در لوپ ریست گیر کردن سامانه و ..... خطای نرم افزاری پژو در خاموش شدن خود به خود خودرو.

[divisionbyzero 836]

کامپایلر اینتل در کنار Intel Parallel Studio یک ابزار بسیار قدرتمند در اختیار شما قرار می دهد که برای معماری های مختلف اینتل می توانید کد ویژه کامپایل بکنید که این یعنی شما از جدید ترین دستورالعمل های موجود در این سخت افزار ها (مثلا Skylake i7 ) می توانید استفاده بکنید و برنامه شما دارای کمترین Conditional jump و بهترین کارایی ممکن می شود.(دستورات پرش شزطی پدر معماری pipeline را در می آورند)

کامپایلر های دیگر هیچ کدام چنین امکانی را به شما نمی دهند.

 

همه کامپایلرها مشکلاتی دارند که با استفاده از طی کردن مسیر معکوس از خروجی به سورس کد امکان تحقیق در مورد صحت کار کامپایلر را داریم که اگر چه برای سخت افزار این کار شدنی است اما برای نرم افزار با اینکه نرم افزار هایی مثل Boomrang و IDA l موجودند اما به هیچ وجه مناسب نیستند به ویژه برای برنامه های OOP.

بنابراین ما مجبوریم که از کامپایلرهایی استفاده بکنیم که دارای استاندارد باشند و بالاترین کیفیت را داشته باشند. تا جایی که من می دانم نه اینتل و نه PGI و نه GCC استاندارد ایمنی ندارند اما حداقل کار بیشتری روی اینتل و PGI با بودجه خیلی بیشتر انجام می شود.

 

یک سوال در این قسمت برام ایجاد شد. چطور کامپایلر میتونه  اکثر  کاندیشنال جامپ ها رو حذف کنه دقیفا؟ آیا کامپایلری برای سیستم های امبدد هم هست که همچین قابلیتی داشته باشه؟. این مورد اگه برای سیستم های امبدد وجود داشته باشه به شدت برام جالبه چون تو سیستم های امبدد حتی لوپ ها و کاندیشنال جامپ ها هم عملا کاندیشنال برنچ هستن(البته استثناهایی هم هست مثل کاندیشنال MOV به PC). اگه یه مثال ساده بزنین خیلی خوب میشه (حتی اگه مثال بر اساس معماری اینتل باشه صرفا برای فهمیدن این موضوع)

راجع به آیدا و از بین رفتن هیرارکی کلاس ها و تایپ ها و آبجکت ها (احتمالا هدفتون از بیان OOP همین بوده؟)  کارایی انجام شده که تا حدودی هم موفق بوده (مقالات مرتبط با این مورد میتونین در زمینه حفاظت از  برنامه های COTS از طریق CFI پیدا کنین ). به نظرم مشکله از مثلا ELF به دیس اسمبلی وجود نداره (با وجود چیزایی مثل Capstone) مشکل بیشتر تبدیل دیس اسمبلی به کد منبع هست اونم به دلیل وجود کامپایلر و بهینه سازی هایی که انجام میده و البته یه دلیل دیگه که در ادامه بهش اشاره میکنم.

 

به نظر شما decompilerها برای نرم افزارهای تجاری تاچه حد موفق عمل می‌کنند

 

ممنون

 

موفق عمل نمیکنن. یه مشکل دیگه ای که بعضا ما باهاش مواجه میشن قضیه آدرس دهی داینامیکه (و البته تبدیل دیس اسمبلی به سورس) که کلا خیلی اذیت میکنه. دیگه قویترینشون همون آیدا با پکیچ pseudocode Generation هگز ریز هست که اونم چنگی به دل نمیزنه.

 

برای علاقه مندان به این مبحث :

 

http://www.amazon.com/gp/product/0321446119

 

این کتاب رو خوندم راستش چیز جالبی نبود. خوب نویسندگانش و البته دوست ایرانی آمریکاییمون :پی خیلی افراد ماهری هستن ولی به نظرم کتاب خوبی نبود.

ویرایش شده در خرداد 95 توسط divisionbyzero

[EMP 6,863]

یک سوال در این قسمت برام ایجاد شد. چطور کامپایلر میتونه  اکثر  کاندیشنال جامپ ها رو حذف کنه دقیفا؟ آیا کامپایلری برای سیستم های امبدد هم هست که همچین قابلیتی داشته باشه؟. این مورد اگه برای سیستم های امبدد وجود داشته باشه به شدت برام جالبه چون تو سیستم های امبدد حتی لوپ ها و کاندیشنال جامپ ها هم عملا کاندیشنال برنچ هستن(البته استثناهایی هم هست مثل کاندیشنال MOV به PC). اگه یه مثال ساده بزنین خیلی خوب میشه (حتی اگه مثال بر اساس معماری اینتل باشه صرفا برای فهمیدن این موضوع)

درود

بنا به آمار از حدود هر 6 دستور اسمبلی یک jump است و بسیاری از این jump ها شرطی هستند.

پاسخ شما معماری به معماری متفاوت است.

برای مثال در معماری اینتل شما برای پیش بینی مقصد jump های شرطی باید کاری بکنید در غیر این صورت، pipeline اینتل که 12 سطح دارد کارایی خودش را از دست می دهد.

معماری اینتل دارای روشی به نام branch prediction هست که در این روش از دو الگوریتم دینامیک و استاتیک استفاده می شود.

اگر کامپایلر برای معماری اینتل کامپابل بکند و شما ایندکس لوپ را unsigned int تعریف کرده باشید عمل چک کردن ایندکس با انتهای آن و عمل افزایش یا کاهش آن با یک دستور انجام می شود. در ضمن تقریبا همه کامپایلر ها لوپ را با jump به عقب پیاده می کنند در نتیجه الگوریتم استاتیک پیش بینی jump کارکرده و قبل از اینکه عمل مقایسه انجام بشود لوپ تکرار می گردد. اگر این تکرار حلقه اشتباه باشد که بعد از اجرای چند دستور مشخص می شود، نتایج در cache data و reg bank به روز نمی شود و انگار که دستوری اجرا نشده اما اگر درست باشد سیستم کارایی بیشتری می یابد. در برخی از میکروکنترلر ها هم این امکان افزوده شده است.

الگوریتم دینامیک پیش بینی jump هم اینگونه هست که jump ای که به جلو باشد انجام نمی شود مگر اینکه سابقه داشته باشد.

حالا چطور یک کامپایلر خوب می تواند jump کم کند؟

ما در پردازنده های اینتل بعد از 486 دارای دستوری مثل CMOV و در سریهای جدید چندین دستور پیچیده جدید نسبت به 486 هستیم اما کامپایلرها معمولا برای 386 یا 486 کامپایل می کنند و هم سایز خروجی آنها بشتر هست و هم دستورات ضعیف تری را کنار هم می گذارند.

با استفاده از دستور Compare and Move شما که برای یک مثلا سورت از IF then Else استفاده کرده اید و برای اجرای درست swap نیاز به jump شرطی دارید در کد زبان ماشین، با استفاده از CMOV این نیاز بر طرف می شود.

برای اینکه بهتر متوجه بشوید بروید یک برنامه را با visual studio و کامپایلر میکروسافت کامپایل بکنید و همان را با VectorC با تنظیم گزینه برای Pentium آنوقت اسمبلی های تولید شده هر دو برنامه کوچک را با هم مقایسه بکنید تا متوجه بشوید که چه مقدار متفاوت است.

همین کم کردن jump اگر درون لوپ باشد (jump خود لوپ pipeline  را تخریب نمی کندچون پرش به عقب است) لوپ شما تا 12 برابر سریعتر می شود!!!

[divisionbyzero 836]

درود

بنا به آمار از حدود هر 6 دستور اسمبلی یک jump است و بسیاری از این jump ها شرطی هستند.

پاسخ شما معماری به معماری متفاوت است.

ما در پردازنده های اینتل بعد از 486 دارای دستوری مثل CMOV و در سریهای جدید چندین دستور پیچیده جدید نسبت به 486 هستیم اما کامپایلرها معمولا برای 386 یا 486 کامپایل می کنند و هم سایز خروجی آنها بشتر هست و هم دستورات ضعیف تری را کنار هم می گذارند.

با استفاده از دستور Compare and Move شما که برای یک مثلا سورت از IF then Else استفاده کرده اید و برای اجرای درست swap نیاز به jump شرطی دارید در کد زبان ماشین، با استفاده از CMOV این نیاز بر طرف می شود.

برای اینکه بهتر متوجه بشوید بروید یک برنامه را با visual studio و کامپایلر میکروسافت کامپایل بکنید و همان را با VectorC با تنظیم گزینه برای Pentium آنوقت اسمبلی های تولید شده هر دو برنامه کوچک را با هم مقایسه بکنید تا متوجه بشوید که چه مقدار متفاوت است.

همین کم کردن jump اگر درون لوپ باشد (jump خود لوپ pipeline  را تخریب نمی کندچون پرش به عقب است) لوپ شما تا 12 برابر سریعتر می شود!!!

آها حالا متوجه شدم. مثال CMOV خوب بود. من فکر میکردم طور دیگه ای منظورتونه چون خود CMOV هم کاندیشنال هست. صرفا جهت اطلاع رسانی تقریبا تمامی نسخه های آرم و میپس از این ایستراکشن ها زیاد دارن. مثل MOVNE یا STRNE در واقع تفریبا تمام اینستراکشن هاشون به این صورت میتونن اجرا شن.

ممنون از پاسختون.