دانلود مقاله ترجمه شده یک مدل تحلیلی برای یک معماری GPU با آگاهی موازیِ سطح حافظه و سطح نخ

معماری GPU در عصرِ چند هسته ای به طور فزاینده ای مهم است که این امر با توجه به تعداد بالایِ پردازنده های موازیِ خود آنهاست. برنامه ریزیِ هزاران نخِ انبوه موازی یک چالش بزرگ برای مهندسانِ نرم افزار است، اما درکِ تنگناهای عملکردِ برنامه های موازی در معماری GPU به منظور بهبود عملکرد برنامه ها، حتی از آن هم سخت تر است. روش های کنونی به برنامه نویسان تکیه می کند که برنامه های کاربردی خود را به طورِ کامل با بهره گیری از فضای طراحی تنظیم کنند بدون اینکه درک کاملی از ویژگی های عملکردِ برنامه های کاربردی داشته باشند. به منظورِ ارائه دیدگاه هایی در رابطه با تنگناهای عملکرد های موازیِ برنامه های کاربردی در معماری GPU، ما مدلِ تحلیلی ساده را پیشنهاد می کنیم که زمان اجرای برنامه های موازی را تخمین می زند. جزء کلیدیِ مدل ما، برآورد تعداد درخواست های حافظه موازی (ما این را حافظه پیچِ موازی می نامیم) با توجه به تعداد نخ های در حال اجرا و  پهنای باندِ حافظه می باشد. بر اساس درجه ی حافظه پیچِ موازی، این مدل هزینه درخواست های حافظه را برآورد می کند و در نتیجه زمان اجرای کلی برنامه را تخمین می زند. مقایسه ی بین  نتیجه ی مدل و زمان اجرای واقعی در چندین GPU نشان می دهد که میانگین هندسیِ خطای مطلقِ مدل ما در معیارِ میکرو، 5.4٪ است و در برنامه های محاسباتِ کاربردی GPU 13.3٪ است. تمام برنامه های کاربردی در زبانِ برنامه نویسی CUDA نوشته شده است.

افزایش قدرت محاسباتیِ GPU های به آنها اوج قدرت محاسبات قابلِ توجه بیشتری نسبت به پردازنده ها می دهد. به عنوان مثال، GTX280 GPU های NVIDIA در [3] قدرتِ  933 با 240 هسته را فراهم می کنند، در حالی که پردازنده Core2Quad اینتل [2] تنها  100 را ارائه کرده اند. نسل بعدی اینتل از پردازنده های گرافیکی بیشتر  از Gflop / s 900  [26] را پشتیبانی خواهند نمود. AMD / ATI آخرین GPU (HD4870)، Tflop / s 1.2 را فراهم می کند [1]. با این حال، حتی اگر سخت افزار، قدرتِ محاسباتی عملکرد بالا را هم فراهم کند، نوشتن برنامه های موازی با استفاده کامل از این کارایی با قدرت محاسباتیِ بالا، هنوز هم یک چالشِ بزرگ است. به تازگی، زبان های برنامه نویسی جدیدی آمده اند که با هدف ِکاهش بار برنامه نویسان در نوشتن برنامه های کاربردی موازی است که این برنامه ها برای پردازندههای گرافیکی مانند بروک + [5]، CUDA [22]، و] OpenCL [16 می باشند. با این حال، حتی با این زبان های برنامه نویسی به تازگی توسعه یافته، برنامه نویسان هنوز هم نیاز به صرف زمان و تلاشِ بسیار زیاد برای بهینه سازی برنامه های کاربردی خود دارندکه برای رسیدن به عملکرد بهتر است[24]. اگر چه انجمنِ] GPGPU [11 دستورالعمل های عمومی  برای بهینه سازی برنامه های کاربردی با استفاده از   CUDAرا فراهم می کند ، به روشنی مشخص است که هنوز هم درک های مختلف  از ویژگی هایِ معماری اساسی و عملکرد مرتبط تنگناها در برنامه های کاربردی هنوز هم همان مشق شب برنامه نویسان باقی مانده است. بنابراین، برنامه نویسان ممکن است نیاز به همه ی ترکیباتِ متفاوت داشته باشند تا بتوانند بهترین تنظیماتِ اجرایی را پیدا کنند[24]. به منظور ارائه بینشی در مورد تنگناهای عملکرد در انبوه معماری های موازی ، به ویژه معماری GPU ، ما مدل تحلیلی ساده را پیشنهاد می کنیم. این مدل می تواند به صورتِ ایستا مورد استفاده قرار گیرد و بدونِ اینکه برنامه ای اجرا شود. شهود اساسی از مدلِ تحلیلی ما این است که برآورد هزینه ی عملیاتی حافظه یک عنصرِ کلیدی است که برای برآورد بخشی از عملکرد برنامه های کاربردی GPU موازی می باشد. زمان اجرای یک برنامه  توسط  زمان تاخیرِ دستورالعمل های حافظه محدود می شود، اما زمان تاخیر هر عمل حافظه می تواند با اجرای درخواست های متعدد حافظه ها به صورت همزمان پنهان شود. با استفاده از تعدادِ نخ های همزمان در حال اجرا و مصرف پهنای باند حافظه، برآورد ما این است که چگونه بسیاری از درخواست هایِ حافظه را می توان به صورت همزمان اجرا کرد، که ما آن را حافظه ی ریسمانِ موازی (MWP) می نامیم. ما همچنین ریسمان محاسباتِ موازی را معرفی می کنیم(CWP. (CWP  نشان دهنده ی مقدار محاسبه انجام شده توسط دیگر ریسمانها می باشد در حالی که یک پیچ در انتظار مقادیرِ حافظه ای است. CWP شبیه به یک متریک است، که شدت محاسباتی  است[23] که در انجمنِ GPGPU معرفی شده اند. با استفاده از هر دوی MWP و CWP، ما به طورِ موثری هزینه درخواست های حافظه را تخمین می زنیم، در نتیجه زمان اجرای برنامه را تخمین می زنیم. ارزیابی مدل تحلیلی ما بر اساس] CUDA [20، 22  می باشد. زبان برنامه نویسی C با پسوند موضوعاتِ موازی است. ما نتایجِ مدل تحلیلی خود را با زمان اجرای واقعی بر روی چندین GPU مقایسه کردیم....