پردازندهٔ مرکزی برای اجرای کارهای گوناگون و تغییر مسیر سریع ساخته شده است؛ پردازندهٔ گرافیکی تعداد زیادی عملیات مشابه را روی داده‌های فراوان انجام می‌دهد. برنامه‌نویسی GPU زمانی سودمند است که کار را بتوان به بخش‌های مستقل تقسیم کرد و زمان جابه‌جایی داده از سود موازی‌سازی کمتر باشد. داشتن GPU به‌تنهایی برنامه را سریع نمی‌کند؛ الگوریتم و نحوهٔ دسترسی به حافظه تعیین‌کننده‌اند.
کد GPU معمولاً تابعی به نام kernel را روی دسته‌ای از threadها اجرا می‌کند. سخت‌افزار threadها را در گروه‌هایی زمان‌بندی می‌کند و آن‌ها به حافظه‌های مختلف با سرعت و ظرفیت متفاوت دسترسی دارند. این مقاله سازوکار اجرا، هم‌زمانی، دقت و ارزیابی را توضیح می‌دهد؛ جزئیات زبان و ابزار بسته به سازنده و محیط برنامه‌نویسی فرق می‌کند.
GPU چه نوع کاری را سریع‌تر انجام می‌دهد؟ وقتی عملیات مشابه روی عناصر فراوان انجام شود، GPU می‌تواند محاسبه‌ها را به‌طور موازی پیش ببرد. نمونه‌ها شامل تبدیل تصویر، ضرب ماتریس، شبیه‌سازی عددی و برخی پردازش‌های علمی‌اند. اگر مسئله به وابستگی‌های زنجیره‌ای، تصمیم‌های متفاوت یا ورودی کوچک محدود باشد، بخش بزرگی از واحدهای محاسبه بیکار می‌مانند و GPU ممکن است از CPU کندتر شود.
مقالهٔ سازوکار رایانه مفهوم دستور و داده را مرور می‌کند؛ GPU همان محاسبه را با معماری متفاوت سازمان می‌دهد. معیار انتخاب، موازی‌پذیری واقعی بارکاری است، نه صرفاً اندازهٔ عددها یا نام محصول. الگوریتم باید به قطعه‌های مستقل تقسیم شود و هزینهٔ آماده‌سازی و بازگرداندن نتیجه هم حساب شود.
kernel چگونه روی داده اجرا می‌شود؟ Kernel تابعی است که روی دستگاه اجرا می‌شود و هر نسخهٔ آن معمولاً شناسه‌ای می‌گیرد تا بداند کدام عنصر ورودی یا خروجی را پردازش کند. میزبان پارامترها را آماده می‌کند، حافظهٔ لازم را اختصاص می‌دهد و اجرا را زمان‌بندی می‌کند. تعداد threadها و شکل شبکه با ابعاد داده و محدودیت سخت‌افزار رابطه دارد؛ انتخاب نامناسب می‌تواند کار را تکه‌تکه یا منابع را هدر دهد.
کد میزبان و کد دستگاه ممکن است زبان و ابزار متفاوت داشته باشند. خطای اندیس‌گذاری می‌تواند نوشتن بیرون از آرایه یا نتیجهٔ رقابتی بسازد. بررسی مرز داده و نگاشت هر thread به خروجی اهمیت دارد. برای مسئلهٔ دوبعدی، باید رابطهٔ مختصات block، thread و اندیس تصویر مشخص باشد؛ یک فرمول اندیس اشتباه می‌تواند فقط در لبه‌ها خطا بسازد.
گروه‌های thread چگونه زمان‌بندی می‌شوند؟ سخت‌افزار threadها را در گروه‌هایی اجرا می‌کند و معمولاً دستور مشترکی را برای چند مسیر داده پیش می‌برد. گروه‌بندی باعث می‌شود حجم زیادی از کار موازی شود، اما هزینهٔ منابع هر گروه روی تعداد گروه‌های هم‌زمان اثر دارد. ثبات و حافظهٔ محلی محدودند؛ kernelی که بیش از حد از آن‌ها استفاده کند، هم‌زمانی کمتری روی واحد محاسبه خواهد داشت.
اندازهٔ block یا workgroup باید با اندازهٔ داده و مدل زمان‌بندی سازگار باشد. اندازهٔ بسیار کوچک سربار و بیکاری ایجاد می‌کند؛ بزرگ‌بودن بیش‌ازحد ممکن است منابع را اشغال کند. راهبردهای مناسب وابسته به GPU و kernel هستند و باید اندازه‌گیری شوند. توصیهٔ عمومی فقط نقطهٔ شروع است، نه پیکربندی بهینه برای همهٔ دستگاه‌ها.
دانلود پوسته وردپرس باریستا؛ قالب کافیشاپ، رُستری قهوه و فروشگاه قهوه دوزبانه با منوی رومیزی، رزرو آنلاین میز با کد پیامکی و ووکامرس. طراحی اختصاصی inzip.ir
٪۲۶
تخفیف ویژه
۱,۰۳۰,۰۰۰ تومان
واگرایی شاخه‌ای چرا کار موازی را کند می‌کند؟ اگر threadهای یک گروه در شرطی به مسیرهای متفاوت بروند، سخت‌افزار ممکن است مسیرها را نوبتی اجرا کند و بخشی از زمان برخی threadها بیکار بماند. به این وضعیت واگرایی شاخه گفته می‌شود. الگوریتم‌هایی با دادهٔ نامنظم یا تصمیم‌های وابسته به هر عنصر ممکن است بیشتر درگیر آن شوند. مرتب‌سازی ورودی یا بازنویسی الگوریتم گاهی مسیرها را منظم‌تر می‌کند، اما ممکن است هزینهٔ آماده‌سازی اضافه کند.
حذف همهٔ شرط‌ها همیشه راه‌حل خوبی نیست؛ کد بدون شاخه ممکن است عملیات بیشتری انجام دهد یا خوانایی را کاهش دهد. پروفایل باید نشان دهد گلوگاه از واگرایی، حافظه یا محاسبه است. تحلیل نمودار دستورها و توزیع ورودی کمک می‌کند بدانید کدام مسیر غالب است. اجرای چند نوع ورودی برای یافتن رفتار میانگین و بدترین حالت لازم است.
حافظهٔ GPU چه سلسله‌مراتبی دارد؟ داده می‌تواند در حافظهٔ سراسری دستگاه، حافظهٔ اشتراکی میان threadهای یک block، حافظهٔ محلی یا ثبات‌ها قرار گیرد. هر سطح ظرفیت و تأخیر متفاوتی دارد. داده‌ای که بارها از حافظهٔ دور خوانده شود ممکن است زمان بیشتری از خود محاسبه بگیرد. استفادهٔ مجدد از مقدار و هم‌جوارکردن دسترسی‌ها می‌تواند پهنای باند مؤثر را بهتر کند.
الگوی دسترسی هم‌تراز و مجاور برای بسیاری از معماری‌ها سودمند است، اما چیدمان مناسب به نوع داده و kernel وابسته است. حافظهٔ اشتراکی می‌تواند داده را میان threadها بازاستفاده دهد؛ استفادهٔ نادرست از آن رقابت یا مصرف ظرفیت ایجاد می‌کند. ابزار پروفایل نشان می‌دهد بارهای حافظه کجا رخ می‌دهند، اما باید با سناریوی واقعی و اندازهٔ ورودی مناسب اجرا شود.
اجرای موازی روی GPU CPU گروه‌های thread حافظه یک kernel روی بلوک‌های دادهٔ موازی اجرا می‌شود؛ انتقال میان حافظه و دستگاه نیز بخشی از زمان کل است. انتقال داده میان CPU و GPU هزینه دارد داده معمولاً باید از حافظهٔ میزبان به دستگاه منتقل و پس از پردازش بازگردانده شود. اگر محاسبه کوچک باشد، انتقال و راه‌اندازی kernel از خود کار طولانی‌تر می‌شود. دسته‌بندی عملیات، نگهداری داده روی دستگاه و کاهش رفت‌وبرگشت‌ها می‌تواند سودمند باشد. بااین‌حال، حافظهٔ دستگاه محدود است و کپی بلندمدت دادهٔ بی‌استفاده ممکن است کارهای دیگر را از جا بیرون کند.
در سامانه‌های دارای حافظهٔ مشترک یا مسیرهای انتقال ویژه، رفتار متفاوت است و باید روی همان دستگاه آزموده شود. زمان‌گیری را به سه بخش شکسته ثبت کنید: انتقال ورودی، اجرای kernel و انتقال خروجی. اندازه‌گیری فقط kernel ممکن است شتابی چشمگیر نشان دهد، درحالی‌که زمان کل برنامه بهبود چندانی نکند.
همگامسازی میان threadها چگونه انجام می‌شود؟ اگر چند thread به یک مقدار مشترک بنویسند، نتیجه به ترتیب اجرا وابسته می‌شود مگر سازوکار همگامسازی به کار رود. barrier می‌تواند همهٔ threadهای یک گروه را تا رسیدن به نقطهٔ مشخص منتظر نگه دارد؛ عملیات اتمیک برای به‌روزرسانی‌های محدود مفید است. این ابزارها هزینه دارند و استفادهٔ نادرست ممکن است بن‌بست، رقابت یا خروجی نادرست بسازد.
همگامسازی میان blockهای مستقل اغلب محدودتر است و ممکن است به چند kernel یا سازوکار سطح دستگاه نیاز داشته باشد. الگوریتم را طوری طراحی کنید که تا جای ممکن هر thread خروجی مستقل خود را بسازد. اگر اشتراک لازم است، ترتیب حافظه و نقطهٔ همگامسازی را بر پایهٔ مدل برنامه‌نویسی انتخاب کنید و با ابزارهای تشخیص race آزمایش کنید.
دقت عددی در محاسبهٔ GPU چه چیزی را تغییر می‌دهد؟ جمع ممیز شناور به ترتیب عملیات حساس است؛ در اجرای موازی ترتیب کاهش مقادیر ممکن است با نسخهٔ ترتیبی فرق کند و نتیجه اندکی تغییر یابد. برخی GPUها قالب‌های عددی گوناگون با دامنه و دقت متفاوت پشتیبانی می‌کنند. انتخاب دقت پایین‌تر می‌تواند سرعت یا مصرف حافظه را بهتر کند، اما باید خطای حاصل برای مسئلهٔ علمی یا تجاری قابل‌قبول باشد.
برای ارزیابی، خروجی را با مرجع دقیق‌تر یا الگوریتم مستقل مقایسه کنید و تلورانس را بر اساس نیاز تعیین کنید. آزمون فقط روی دادهٔ خوش‌رفتار کافی نیست؛ مقدارهای بسیار بزرگ، کوچک و نزدیک مرز را هم بسنجید. بازتولید دقیق نتیجه ممکن است در اجرای موازی نیازمند تنظیمات خاص باشد و نباید پیش‌فرض گرفته شود.
چطور kernel را بهینه و اندازه‌گیری کنیم؟ ابتدا نسخهٔ ساده و درست بنویسید، سپس پروفایل بگیرید تا مشخص شود زمان در محاسبه، حافظه، همگامسازی یا انتقال صرف می‌شود. بهینه‌سازی بدون گلوگاه معلوم ممکن است فقط پیچیدگی بیفزاید. اندازهٔ ورودی، گرم‌شدن دستگاه، رقابت سایر پردازش‌ها و فرکانس متغیر GPU را در ثبت نتایج مشخص کنید.
مقایسه باید زمان کل کاربرد و مصرف حافظه را بسنجد، نه یک عملیات مصنوعی تنها. چند تکرار و توزیع ورودی‌های واقعی لازم است. نسخهٔ بهینه‌شده را با آزمون‌های صحت و مرجع عددی بسنجید. سرعت بیشتر اگر دقت، پایداری یا مصرف انرژی را به‌طور نامطلوب تغییر دهد، لزوماً بهبود محصول نیست.
چه زمانی GPU گزینهٔ مناسبی نیست؟ کارهای کوچک، وابسته به ترتیب یا دارای شاخه‌های بسیار نامنظم ممکن است از انتقال داده و زمان‌بندی سود نبرند. اگر برنامه بیشتر منتظر دیسک یا شبکه است، GPU گلوگاه را رفع نمی‌کند. همچنین نگهداری نسخهٔ چندسازنده‌ای می‌تواند به زنجیرهٔ ابزار، تست و نگاشت kernel جدا نیاز داشته باشد. هزینهٔ توسعه و پشتیبانی را کنار کارایی اندازه بگیرید.
برای تصمیم، یک نمونهٔ نماینده بسازید و روی سخت‌افزار مقصد، با کل مسیر داده، انرژی و کیفیت خروجی را مقایسه کنید. GPU ابزار قدرتمندی برای محاسبهٔ موازی است، اما همهٔ مسائل موازی‌پذیر نیستند و هر موازی‌سازی هم سود خالص نمی‌دهد. گزارش باید مدل داده، اندازهٔ دسته و شرایط آزمون را شفاف کند.
پیش از انتقال داده، ساختار مسئله را به خروجی‌های مستقل و وابستگی‌های ضروری تجزیه کنید. الگوریتمی که هر خانهٔ خروجی را از همسایه‌های مشخص می‌سازد ممکن است موازی‌سازی مستقیم داشته باشد؛ الگوریتمی که هر گام به نتیجهٔ گام قبلی وابسته است، شاید به بازطراحی یا محاسبهٔ تقریبی نیاز پیدا کند. تبدیل مسئله به kernel تنها بخش اجرا نیست: تخصیص حافظه، زمان‌بندی، همگامسازی، مدیریت خطا و آزادسازی منبع نیز باید در چرخهٔ عمر برنامه لحاظ شوند.
برای مقایسهٔ منصفانه، نسخهٔ CPU و GPU باید همان ورودی، همان دقت و همان تعریف خروجی را به کار برند. زمان‌سنجی نخستین اجرا ممکن است هزینهٔ کامپایل یا آماده‌سازی را هم بشمارد؛ روش اندازه‌گیری را مستند کنید و چند بار تکرار کنید. دادهٔ واقعی می‌تواند توزیع و شاخه‌هایی داشته باشد که در ورودی مصنوعی نیستند. علاوه بر سرعت، مصرف انرژی، حافظهٔ اشغال‌شده، زمان پاسخ و پایداری در بار طولانی را بسنجید؛ این معیارها در خدمت محصول از یک عدد حداکثر throughput مهم‌ترند.
بهینه‌سازی حافظه را نیز باید در چارچوب محاسبه دید. اگر هر داده فقط یک بار مصرف شود، جابه‌جایی آن به حافظهٔ سریع‌تر ممکن است هزینهٔ کپی اضافه کند بی‌آنکه سودی بدهد. اگر داده چند بار بازاستفاده شود، نگه‌داشتن آن در سطح نزدیک‌تر به واحد محاسبه می‌تواند دسترسی‌های تکراری را کاهش دهد. با این حال، ظرفیت محدود و رقابت میان گروه‌ها تعیین می‌کند چه مقدار داده واقعاً در آن سطح جا می‌گیرد. اندازه‌گیری با ابزار سازنده و آزمایش روی ابعاد واقعی از قواعد حدسی بهتر است.
همچنین باید دربارهٔ تکرارپذیری و خطای گردکردن تصمیم آگاهانه گرفت. الگوریتمی که عملیات اتمیک را در ترتیب متغیر انجام می‌دهد شاید در اجراهای مختلف نتیجهٔ اندکی متفاوت بسازد. برای کاربرد علمی، دامنهٔ خطا باید با فرض‌های مدل و دقت موردنیاز سازگار باشد؛ در یادگیری یا گرافیک نیز تفاوت کوچک لزوماً بی‌اهمیت نیست. نتیجه را در ورودی‌های مرزی و با مرجع معتبر بسنجید و گزارش کنید که آزمون کارایی از چه دستگاه و تنظیمی استفاده کرده است.
در یک مثال آموزشی، آرایه‌ای با 115 عنصر را می‌توان به threadهای جداگانه نگاشت تا هر کدام یک خروجی بسازند. چون اندازه با گروه‌های اجرا جور درنیاید، آخرین گروه ممکن است threadهای اضافی داشته باشد؛ شرط مرز مانع دسترسی بیرون از آرایه می‌شود. این نمونهٔ کوچک برای فهم اندیس‌گذاری است و هیچ مزیت سرعتی را اثبات نمی‌کند؛ ارزیابی کارایی به مسئله‌ای بزرگ‌تر و واقعی نیاز دارد.
٪۴۱
آموزش حرفه ای HTML از صفر در ۱۶ ویدیو: سند، متن، لینک، تصویر، جدول، فرم، معنایی‌سازی، دسترس‌پذیری و سئو، تا پروژهٔ کامل صفحهٔ فروشگاه محصول.
تماشای آنلاین + دانلود
دسترسی آنی و همیشگی
به‌روزرسانی رایگان
کیفیت Full HD
۹۹۰,۰۰۰ تومان
۵۹۰,۰۰۰ تومان
سود شما ۴۰۰,۰۰۰ تومان
مشاهده سریال