Изчисления на графични процесори

Технологията CUDA (Compute Unified Device Architecture) е софтуерна и хардуерна архитектура, която позволява изчисления с помощта на графични процесори NVIDIA, които поддържат технологията GPGPU (произволни изчисления на видеокарти). Архитектурата CUDA за първи път се появи на пазара с пускането на осмото поколение чип NVIDIA - G80 и присъства във всички следващи серии графични чипове, които се използват в семействата ускорители GeForce, ION, Quadro и Tesla.

CUDA SDK позволява на програмистите да внедряват, в специален опростен диалект на езика за програмиране C, алгоритми, които могат да се изпълняват на NVIDIA GPU и да включват специални функции в програмния текст на C. CUDA дава възможност на разработчика по свое усмотрение да организира достъп до набора от инструкции на графичния ускорител и да управлява паметта му, да организира сложни паралелни изчисления върху него.

История

През 2003 г. Intel и AMD бяха в съвместна надпревара за най-много мощен процесор. През годините тактовите честоти се повишиха значително в резултат на тази надпревара, особено след пускането на Intel Pentium 4.

След увеличаването на тактовите честоти (между 2001 и 2003 г. тактовата честота на Pentium 4 се удвои от 1,5 на 3 GHz) и потребителите трябваше да се задоволят с десети от гигахерца, които производителите пуснаха на пазара (от 2003 до 2005 г. часовник честотите се увеличават с 3 до 3,8 GHz).

Архитектурите, оптимизирани за високи тактови честоти, като Prescott, също започнаха да изпитват трудности, и то не само в производството. Производителите на чипове са изправени пред предизвикателства при преодоляването на законите на физиката. Някои анализатори дори прогнозираха, че законът на Мур ще спре да действа. Но това не се случи. Първоначалното значение на закона често се представя погрешно, но се отнася до броя на транзисторите на повърхността на силициево ядро. За дълго времеувеличаването на броя на транзисторите в процесора беше придружено от съответно увеличение на производителността - което доведе до изкривяване на смисъла. Но тогава ситуацията се усложни. Дизайнерите на архитектурата на процесора се доближиха до закона за намаляване на печалбата: броят на транзисторите, които трябваше да се добавят за желаното увеличение на производителността, стана все повече и повече, което доведе до задънена улица.

Причината, поради която производителите на графични процесори не са се сблъскали с този проблем, е много проста: процесорите са проектирани да получат най-добра производителност на поток от инструкции, които обработват различни данни (както цели числа, така и числа с плаваща запетая), извършват произволен достъп до паметта и т.н. d. Досега разработчиците се опитваха да осигурят по-голям паралелизъм на инструкциите - тоест да изпълняват възможно най-много инструкции паралелно. Така например, суперскаларното изпълнение се появи с Pentium, когато при определени условия беше възможно да се изпълнят две инструкции на такт. Pentium Pro получи извънредно изпълнение на инструкции, което направи възможно оптимизирането на производителността на изчислителните единици. Проблемът е, че паралелното изпълнение на последователен поток от инструкции има очевидни ограничения, така че сляпото увеличаване на броя на изчислителните единици не дава печалба, тъй като през повечето време те все още ще бъдат неактивни.

Работата с GPU е относително проста. Състои се от вземане на група полигони от едната страна и генериране на група пиксели от другата. Полигоните и пикселите са независими един от друг, така че могат да се обработват паралелно. По този начин в GPU е възможно да се разпредели голяма част от кристала за изчислителни единици, които, за разлика от CPU, реално ще бъдат използвани.

GPU се различава от CPU не само по това. Достъпът до паметта в GPU е много свързан - ако се чете тексел, след няколко цикъла ще бъде прочетен съседният тексел; когато се запише пиксел, съседният ще бъде записан след няколко цикъла. Чрез интелигентно организиране на паметта можете да получите производителност, близка до теоретичната честотна лента. Това означава, че GPU, за разлика от CPU, не изисква огромен кеш, тъй като неговата роля е да ускорява операциите по текстуриране. Необходими са само няколко килобайта, съдържащи няколко тексела, използвани в билинейни и трилинейни филтри.

Първи изчисления на GPU

Първите опити за такова приложение бяха ограничени до използването на някои хардуерни функции, като растеризация и Z-буфериране. Но през настоящия век, с появата на шейдъри, те започнаха да ускоряват изчисляването на матриците. През 2003 г. отделен раздел беше разпределен на SIGGRAPH за изчисления с GPU и беше наречен GPGPU (изчисление с общо предназначение на GPU).

Най-известният BrookGPU е компилаторът на езика за програмиране на потоци Brook, предназначен да извършва неграфични изчисления на GPU. Преди появата му разработчиците, използващи възможностите на видеочиповете за изчисления, избраха един от двата общи API: Direct3D или OpenGL. Това сериозно ограничи използването на GPU, тъй като 3D графиките използват шейдъри и текстури, за които паралелните програмисти не са длъжни да знаят, те използват нишки и ядра. Брук успя да им помогне да улеснят задачата си. Тези стрийминг разширения към езика C, разработени в Станфордския университет, скриха 3D API от програмистите и представиха видео чипа като паралелен копроцесор. Компилаторът анализира .br файл с C++ код и разширения, произвеждайки код, свързан с DirectX, OpenGL или x86-активирана библиотека.

Появата на Brook предизвика интереса на NVIDIA и ATI и допълнително отвори цял нов сектор от него - паралелни компютри, базирани на видеочипове.

Освен това някои изследователи от проекта Brook се преместиха в екипа за разработка на NVIDIA, за да въведат хардуерно-софтуерна паралелна изчислителна стратегия, отваряйки нов пазарен дял. И основното предимство на тази инициатива на NVIDIA беше, че разработчиците отлично познават всички възможности на своите графични процесори до най-малкия детайл и няма нужда да използвате графичния API и можете да работите с хардуера директно с помощта на драйвера. Резултатът от усилията на този екип е NVIDIA CUDA.

Области на приложение на паралелните изчисления на GPU

Когато изчисленията се прехвърлят към GPU, в много задачи се постига ускорение от 5-30 пъти в сравнение с бързите процесори с общо предназначение. Най-големите числа (от порядъка на 100x ускорение и дори повече!) се постигат при код, който не е много подходящ за изчисления с помощта на SSE блокове, но е доста удобен за GPU.

Това са само някои примери за ускоряване на синтетичен код на GPU спрямо SSE векторизиран код на CPU (според NVIDIA):

Флуоресцентна микроскопия: 12x.

Молекулярна динамика (изчисление на несвързана сила): 8-16x;

Електростатика (директно и многостепенно сумиране на Кулон): 40-120x и 7x.

Таблицата, която NVIDIA показва на всички презентации, която показва скоростта на GPU спрямо CPU.

Списък на основните приложения, в които се използва GPU изчисление: анализ и обработка на изображения и сигнали, симулация на физика, изчислителна математика, изчислителна биология, финансови изчисления, бази данни, динамика на газове и течности, криптография, адаптивна лъчева терапия, астрономия, обработка на звук, биоинформатика, биологични симулации, компютърно зрение, извличане на данни, цифрово кино и телевизия, електромагнитни симулации, географски информационни системи, военни приложения, минно планиране, молекулярна динамика, ядрено-магнитен резонанс (MRI), невронни мрежи, океанографски изследвания, физика на частиците, симулация на сгъване на протеини, квантова химия, проследяване на лъчи, изображения, радар, симулация на резервоар, изкуствен интелект, анализ на сателитни данни, сеизмично проучване, хирургия, ултразвук, видеоконферентна връзка.

Предимства и ограничения на CUDA

От гледна точка на програмиста, графичният конвейер е набор от етапи на обработка. Геометричният блок генерира триъгълници, а растерният блок генерира пиксели, показани на монитора. Традиционният модел на програмиране на GPGPU е както следва:

За прехвърляне на изчисления към GPU в рамките на такъв модел е необходим специален подход. Дори добавянето на два вектора елемент по елемент ще изисква изчертаване на формата към екрана или към буфер извън екрана. Фигурата е растеризирана, като цвета на всеки пиксел се изчислява по зададена програма (пиксел шейдър). Програмата чете входните данни от текстурите за всеки пиксел, добавя ги и ги записва в изходния буфер. И всички тези многобройни операции са необходими за това, което е написано в един оператор на конвенционален език за програмиране!

Следователно използването на GPGPU за изчисления с общо предназначение има ограничение под формата на твърде голяма сложност, която разработчиците могат да научат. Има и достатъчно други ограничения, защото пикселният шейдър е просто формула за зависимостта на крайния цвят на пиксела от неговите координати, а езикът на пикселния шейдър е език за писане на тези формули със синтаксис, подобен на C. Ранните методи на GPGPU са хитър трик за овладяване на мощността на GPU, но без никакво удобство. Данните там са представени чрез изображения (текстури), а алгоритъмът е представен чрез процес на растеризация. Трябва да се отбележи и много специфичен модел на памет и изпълнение.

Хардуерната и софтуерната архитектура на NVIDIA за изчисления на графични процесори от NVIDIA се различава от предишните модели GPGPU по това, че позволява писане на програми за графични процесори в реален C със стандартен синтаксис, указатели и необходимостта от минимум разширения за достъп до изчислителните ресурси на видеочиповете. CUDA не зависи от графични API и има някои функции, проектирани специално за изчисления с общо предназначение.

Предимства на CUDA пред традиционния подход към GPGPU изчисленията

CUDA осигурява достъп до 16 KB споделена памет на мултипроцесор, който може да се използва за организиране на кеш с по-висока честотна лента от извличането на текстури;

По-ефективен трансфер на данни между системата и видео паметта;

Няма нужда от графични API с излишък и режийни разходи;

Линейно адресиране на паметта, събиране и разпръскване, възможност за запис на произволни адреси;

Хардуерна поддръжка за целочислени и битови операции.

Основни ограничения на CUDA:

Липса на поддръжка на рекурсия за изпълними функции;

Минималната ширина на блока е 32 нишки;

Затворена CUDA архитектура, собственост на NVIDIA.

Слабите страни на програмирането с предишни методи на GPGPU са, че тези методи не използват единици за изпълнение на върхови шейдъри в предишни неунифицирани архитектури, данните се съхраняват в текстури и се извеждат в буфер извън екрана, а многопроходните алгоритми използват единици за пикселни шейдъри. Ограниченията на GPGPU включват: недостатъчно ефективно използване на хардуерните възможности, ограничения на честотната лента на паметта, без операция на разпръскване (само събиране), задължително използване на графичния API.

Основните предимства на CUDA пред предишните методи на GPGPU произтичат от факта, че тази архитектура е проектирана да ефективно използваненеграфично изчисление на GPU и използва езика за програмиране C, без да се изисква прехвърляне на алгоритми във форма, удобна за концепцията за графичен тръбопровод. CUDA предлага нов начин GPU изчисления, които не използват графични API и предлагат произволен достъп до паметта (разпръскване или събиране). Такава архитектура е лишена от недостатъците на GPGPU и използва всички изпълнителни единици, а също така разширява възможностите чрез целочислена математика и операции за изместване на битове.

CUDA отваря някои хардуерни функции, които не са достъпни от графичните API, като споделена памет. Това е малко количество памет (16 килобайта на мултипроцесор), до което имат достъп блокове от нишки. Позволява ви да кеширате вашите най-често посещавани данни и може да предостави повече висока скорост, в сравнение с използването на извличания на текстури за тази задача. Това от своя страна намалява чувствителността на пропускателната способност на паралелните алгоритми в много приложения. Например, той е полезен за линейна алгебра, бързо преобразуване на Фурие и филтри за обработка на изображения.

По-удобен в CUDA и достъп до паметта. Програмен кодв графичния API, извежда данни под формата на 32 стойности с плаваща запетая с единична точност (RGBA стойности едновременно в осем цели за рендиране) в предварително дефинирани области, а CUDA поддържа разпръснат запис - неограничен брой записи на всеки адрес . Такива предимства правят възможно изпълнението на някои алгоритми на GPU, които не могат да бъдат ефективно реализирани с помощта на GPGPU методи, базирани на графичния API.

Също така, графичните API непременно съхраняват данни в текстури, което изисква предварително опаковане на големи масиви в текстури, което усложнява алгоритъма и налага използването на специално адресиране. И CUDA ви позволява да четете данни на всеки адрес. Друго предимство на CUDA е оптимизираната комуникация между CPU и GPU. А за разработчиците, които искат достъп до ниското ниво (например, когато пишат друг език за програмиране), CUDA предлага възможност за програмиране на асемблер на ниско ниво.

Недостатъци на CUDA

Един от малкото недостатъци на CUDA е неговата лоша преносимост. Тази архитектура работи само на видео чиповете на тази компания, и то не на всички, но като се започне от сериите GeForce 8 и 9 и съответните Quadro, ION и Tesla. NVIDIA дава цифра от 90 милиона CUDA-съвместими видео чипове.

Алтернативи на CUDA

Рамка за писане компютърни програмисвързани с паралелни изчисления на различни графични и централни процесори. Рамката OpenCL включва език за програмиране, базиран на стандарта C99 и интерфейс за програмиране на приложения (API). OpenCL осигурява паралелизъм на ниво инструкции и на ниво данни и е реализация на техниката GPGPU. OpenCL е напълно отворен стандарт и няма лицензионни такси за използването му.

Целта на OpenCL е да допълни OpenGL и OpenAL, които са отворени индустриални стандарти за 3D компютърна графика и звук, като се възползва от мощността на GPU. OpenCL се разработва и поддържа от Khronos Group, консорциум с нестопанска цел, който включва много големи компании, включително Apple, AMD, Intel, nVidia, Sun Microsystems, Sony Computer Entertainment и други.

CAL/IL (слой на изчислителна абстракция/междинен език)

ATI Stream Technology е набор от хардуер и софтуерни технологии, които ви позволяват да използвате AMD GPU, заедно с CPU, за ускоряване на много приложения (не само графични).

Областите на приложение на ATI Stream са приложения, които изискват изчислителни ресурси, като напр финансовия анализили обработка на сеизмични данни. Използването на поточен процесор направи възможно увеличаването на скоростта на някои финансови изчисления с 55 пъти в сравнение с решаването на същия проблем само с процесор.

NVIDIA не смята технологията ATI Stream за много силен конкурент. CUDA и Stream са две различни технологии, които са на различни нива на развитие. Програмирането за продукти на ATI е много по-трудно - техният език е по-скоро като асемблер. CUDA C, от друга страна, е език на много по-високо ниво. Писането на него е по-удобно и по-лесно. За големите развойни компании това е много важно. Ако говорим за производителност, можем да видим, че нейната пикова стойност в продуктите на ATI е по-висока, отколкото в решенията на NVIDIA. Но отново всичко се свежда до това как да получите тази сила.

DirectX11 (DirectCompute)

Интерфейс за програмиране на приложения, който е част от DirectX, набор от API от Microsoft, който е проектиран да работи на IBM PC-съвместими компютри, работещи операционна системаСемейство Microsoft Windows. DirectCompute е проектиран да извършва изчисления с общо предназначение на GPU, като е реализация на концепцията GPGPU. DirectCompute първоначално беше публикуван като част от DirectX 11, но по-късно беше наличен и за DirectX 10 и DirectX 10.1.

NVDIA CUDA в руската научна среда.

Към декември 2009 г. програмен модел CUDA се преподава в 269 университета по света. В Русия курсове за обучение по CUDA се преподават в държавните университети в Москва, Санкт Петербург, Казан, Новосибирск и Перм, Международния университет за природата на обществото и човека „Дубна“, Обединения институт за ядрени изследвания, Московския институт за електроника Технология, Ивановски държавен енергиен университет, BSTU. В. Г. Шухова, MSTU im. Бауман, РХТУ им. Менделеев, Руския изследователски център "Курчатовски институт", Междурегионалния суперкомпютърен център на Руската академия на науките, Таганрогския технологичен институт (TTI SFedU).

Характеристики на AMD/ATI Radeon архитектура

Това е подобно на раждането на нови биологични видове, когато живите същества се развиват, за да подобрят своята адаптивност към околната среда по време на развитието на местообитанията. По същия начин графичните процесори, започвайки с ускорено растеризиране и текстуриране на триъгълници, са разработили допълнителни способности за изпълнение на шейдърни програми за оцветяване на същите тези триъгълници. И тези способности се оказаха търсени в неграфичните изчисления, където в някои случаи осигуряват значително увеличение на производителността в сравнение с традиционните решения.

Правим аналогии по-нататък - след дълга еволюция на сушата, бозайниците проникват в морето, откъдето изтласкват обикновените морски обитатели. В конкурентната борба бозайниците използваха както нови усъвършенствани способности, появили се на земната повърхност, така и специално придобити за адаптиране към живота във водата. По същия начин графичните процесори, базирани на предимствата на архитектурата за 3D графики, все повече придобиват специална функционалност, полезна за неграфични задачи.

И така, какво позволява на GPU да претендира за собствен сектор в областта на програмите с общо предназначение? Микроархитектурата на графичния процесор е изградена много по-различно от конвенционалните процесори и има определени предимства от самото начало. Графичните задачи включват независима паралелна обработка на данни, а GPU е естествено многонишков. Но този паралелизъм е само радост за него. Микроархитектурата е проектирана да използва големия брой нишки, които трябва да бъдат изпълнени.

Графичният процесор се състои от няколко десетки (30 за Nvidia GT200, 20 за Evergreen, 16 за Fermi) процесорни ядра, които се наричат ​​Streaming Multiprocessor в терминологията на Nvidia и SIMD Engine в терминологията на ATI. В рамките на тази статия ще ги наричаме минипроцесори, защото те изпълняват няколкостотин програмни потока и могат да правят почти всичко, което може обикновен CPU, но все пак не всичко.

Маркетинговите имена са объркващи - те, за по-голяма важност, показват броя на функционалните модули, които могат да изваждат и умножават: например 320 векторни "ядра" (ядра). Тези ядки са по-скоро зърна. По-добре е да мислите за GPU като за многоядрен процесор с много ядра, изпълняващи много нишки едновременно.

Всеки минипроцесор има локална памет, 16 KB за GT200, 32 KB за Evergreen и 64 KB за Fermi (по същество програмируем L1 кеш). Той има подобно време за достъп до L1 кеша на конвенционален процесор и изпълнява подобни функции за доставяне на данни до функционалните модули възможно най-бързо. В архитектурата на Fermi част от локалната памет може да бъде конфигурирана като обикновен кеш. В GPU локалната памет се използва за бърз обмен на данни между изпълняващи се нишки. Една от обичайните схеми за GPU програма е следната: първо данните от глобалната памет на GPU се зареждат в локалната памет. Това е просто разположена обикновена видео памет (като системна памет) отделно от "собствения" процесор - в случай на видео, той е запоен от няколко микросхеми върху текстолита на видеокартата. След това няколкостотин нишки работят с тези данни в локалната памет и записват резултата в глобалната памет, след което се прехвърлят към процесора. Отговорност на програмиста е да напише инструкции за зареждане и разтоварване на данни от локалната памет. По същество това е разделяне на данни [на конкретна задача] за паралелна обработка. Графичният процесор също поддържа атомни инструкции за запис/четене в паметта, но те са неефективни и обикновено се изискват на последния етап за „залепване“ на резултатите от изчисленията на всички минипроцесори.

Локалната памет е обща за всички нишки, работещи в минипроцесора, така че например в терминологията на Nvidia тя дори се нарича споделена, а терминът локална памет означава точно обратното, а именно: определена лична област на отделна нишка в глобалната памет, видима и достъпна само за него. Но в допълнение към локалната памет, минипроцесорът има друга област на паметта, във всички архитектури, около четири пъти по-голяма по обем. Той е разделен по равно между всички изпълняващи се нишки; това са регистри за съхранение на променливи и междинни резултати от изчисления. Всяка нишка има няколко десетки регистъра. Точният брой зависи от това колко нишки изпълнява минипроцесорът. Това число е много важно, тъй като латентността на глобалната памет е много висока, стотици цикли и при липса на кеш памет няма къде да се съхраняват междинните резултати от изчисленията.

И още една важна характеристика на GPU: „мека“ векторизация. Всеки минипроцесор има голям брой изчислителни модули (8 за GT200, 16 за Radeon и 32 за Fermi), но те могат да изпълнят само една и съща инструкция с един и същ програмен адрес. Операндите в този случай могат да бъдат различни, различните нишки имат свои собствени. Например, инструкцията добавете съдържанието на два регистъра: изпълнява се едновременно от всички изчислителни устройства, но се вземат различни регистри. Предполага се, че всички нишки на GPU програмата, извършващи паралелна обработка на данни, обикновено се движат паралелно през програмния код. Така всички изчислителни модули се зареждат равномерно. И ако нишките, поради разклонения в програмата, са се разминавали по пътя си на изпълнение на кода, тогава се получава така наречената сериализация. Тогава не се използват всички изчислителни модули, тъй като нишките изпращат различни инструкции за изпълнение, а блокът от изчислителни модули може да изпълни, както вече казахме, само инструкция с един адрес. И, разбира се, производителността в същото време пада по отношение на максимума.

Предимството е, че векторизацията е напълно автоматична, не е програмиране с помощта на SSE, MMX и т.н. И самият графичен процесор се справя с несъответствията. Теоретично е възможно да се пишат програми за GPU, без да се мисли за векторния характер на изпълняващите се модули, но скоростта на такава програма няма да бъде много висока. Недостатъкът е голямата ширина на вектора. Това е повече от номиналния брой функционални модули и е 32 за Nvidia GPU и 64 за Radeon. Нишките се обработват в блокове с подходящ размер. Nvidia нарича този блок от нишки терминът warp, AMD - вълнов фронт, което е същото. По този начин, на 16 изчислителни устройства, "вълнов фронт" с дължина 64 нишки се обработва в четири цикъла (приемайки обичайната дължина на инструкцията). Авторът предпочита термина варп в случая, поради асоциацията с морския термин варп, обозначаващ въже, вързано от усукани въжета. Така нишките се "усукват" и образуват цялостен пакет. Но „фронтът на вълната“ може да се свърже и с морето: инструкциите пристигат до задвижващите механизми по същия начин, както вълните се търкалят една след друга към брега.

Ако всички нишки са напреднали еднакво в изпълнението на програмата (те са на едно и също място) и по този начин изпълняват една и съща инструкция, тогава всичко е наред, но ако не, тя се забавя. В този случай нишките от един и същи warp или wave front са на различни места в програмата, те са разделени на групи нишки, които имат еднаква стойност на номера на инструкцията (с други думи, указателя на инструкцията). И както преди, само нишките от една група се изпълняват едновременно - всички те изпълняват една и съща инструкция, но с различни операнди. В резултат warp се изпълнява толкова пъти по-бавно, на колкото групи е разделен, като броят на нишките в групата няма значение. Дори ако групата се състои само от една нишка, тя все пак ще отнеме толкова време, колкото и пълно изкривяване. В хардуера това се реализира чрез маскиране на определени нишки, тоест инструкциите се изпълняват формално, но резултатите от тяхното изпълнение не се записват никъде и не се използват в бъдеще.

Въпреки че всеки минипроцесор (поточен мултипроцесор или SIMD двигател) изпълнява инструкции, принадлежащи само на една деформация (група нишки) във всеки даден момент, той има няколко десетки активни деформации в изпълнимия пул. След като изпълни инструкциите на един warp, минипроцесорът изпълнява не следващата по ред инструкция на нишките на този warp, а инструкциите на някой друг в warp. Тази деформация може да бъде на съвсем различно място в програмата, това няма да повлияе на скоростта, тъй като само вътре в деформацията инструкциите на всички нишки трябва да са еднакви за изпълнение на пълна скорост.

В този случай всяка от 20-те машини SIMD има четири активни вълнови фронта, всеки с 64 нишки. Всяка нишка е обозначена с къса линия. Общо: 64×4×20=5120 нишки

По този начин, като се има предвид, че всеки фронт на деформация или вълна се състои от 32-64 нишки, минипроцесорът има няколкостотин активни нишки, които се изпълняват почти едновременно. По-долу ще видим какви архитектурни предимства обещава такъв голям брой паралелни нишки, но първо ще разгледаме какви ограничения имат минипроцесорите, които съставляват GPU.

Основното е, че графичният процесор няма стек, където могат да се съхраняват функционални параметри и локални променливи. Поради големия брой нишки за стека, просто няма място на чипа. Наистина, тъй като графичният процесор изпълнява едновременно около 10 000 нишки, с размер на стека на една нишка от 100 KB, общото количество ще бъде 1 GB, което е равно на стандартното количество на цялата видео памет. Освен това няма начин да поставите стек със значителен размер в самото ядро ​​на GPU. Например, ако поставите 1000 байта стек на нишка, тогава само един минипроцесор ще изисква 1 MB памет, което е почти пет пъти общото количество локална памет на минипроцесора и паметта, разпределена за съхранение на регистри.

Следователно няма рекурсия в програмата на GPU и не можете наистина да се обърнете с извиквания на функции. Всички функции се заместват директно в кода, когато програмата се компилира. Това ограничава обхвата на GPU до изчислителни задачи. Понякога е възможно да се използва ограничена емулация на стека, използваща глобална памет за алгоритми за рекурсия с известна малка дълбочина на итерация, но това не е типично GPU приложение. За да направите това, е необходимо специално да се разработи алгоритъм, да се проучи възможността за неговото прилагане без гаранция за успешно ускорение в сравнение с процесора.

Fermi за първи път представи възможността за използване на виртуални функции, но отново, използването им е ограничено от липсата на голям, бърз кеш за всяка нишка. 1536 нишки представляват 48 KB или 16 KB L1, тоест виртуалните функции в програмата могат да се използват сравнително рядко, в противен случай стекът ще използва и бавна глобална памет, което ще забави изпълнението и най-вероятно няма да донесе ползи в сравнение към версията на процесора.

По този начин GPU се представя като изчислителен копроцесор, в който се зареждат данни, обработват се по някакъв алгоритъм и се получава резултат.

Предимства на архитектурата

Но счита GPU за много бърз. И в това му помага високата му многопоточност. Голям брой активни нишки позволява частично да се скрие голямата латентност на отделно разположената глобална видеопамет, която е около 500 цикъла. Изравнява се особено добре за код с висока плътност. аритметични операции. По този начин не е необходима скъпа за транзистори L1-L2-L3 кеш йерархия. Вместо това много изчислителни модули могат да бъдат поставени на чип, осигурявайки изключителна аритметична производителност. Междувременно инструкциите на една нишка или warp се изпълняват, останалите стотици нишки тихо чакат своите данни.

Fermi представи кеш от второ ниво от около 1 MB, но той не може да се сравни с кешовете на съвременните процесори, той е по-скоро предназначен за комуникация между ядрата и различни софтуерни трикове. Ако размерът му се раздели между всичките десетки хиляди нишки, всяка ще има много незначително количество.

Но освен латентността на глобалната памет, има много повече латентности в изчислителното устройство, които трябва да бъдат скрити. Това е латентността на прехвърлянето на данни в рамките на чипа от изчислителните устройства към кеша от първо ниво, тоест локалната памет на GPU, и към регистрите, както и кеша на инструкциите. Регистърният файл, както и локалната памет, се намират отделно от функционалните модули, а скоростта на достъп до тях е около дузина цикъла. И отново, голям брой нишки, активни деформации, могат ефективно да скрият това забавяне. Освен това общата честотна лента (честотна лента) на достъп до локалната памет на целия графичен процесор, като се вземе предвид броят на минипроцесорите, които го съставляват, е много по-голяма от честотната лента на достъпа до кеша от първо ниво в съвременните процесори. GPU може да обработва значително повече данни за единица време.

Веднага можем да кажем, че ако графичният процесор не е снабден с голям брой паралелни нишки, тогава той ще има почти нулева производителност, защото ще работи със същото темпо, сякаш е напълно зареден, и ще върши много по-малко работа. Например, нека остане само една нишка вместо 10 000: производителността ще спадне с около хиляда пъти, защото не само че няма да се заредят всички блокове, но и всички закъснения ще се отразят.

Проблемът със скриването на закъсненията също е остър за съвременните високочестотни процесори; за премахването му се използват сложни методи - дълбок конвейер, извънредно изпълнение на инструкции (извън ред). Това изисква сложни програми за изпълнение на инструкции, различни буфери и т.н., което заема място на чипа. Всичко това е необходимо за най-добра производителност в еднопоточен режим.

Но за графичния процесор всичко това не е необходимо, той е архитектурно по-бърз за изчислителни задачи с голям брой нишки. Вместо това, той превръща многопоточността в производителност, както философският камък превръща оловото в злато.

GPU първоначално е проектиран да изпълнява оптимално шейдър програми за триъгълни пиксели, които очевидно са независими и могат да се изпълняват паралелно. И от това състояние той еволюира чрез добавяне на различни функции (локална памет и адресируем достъп до видео паметта, както и усложняване на набора от инструкции) в много мощно изчислително устройство, което все още може да се прилага ефективно само за алгоритми, които позволяват силно паралелно изпълнение използвайки ограничено количество локална памет.

Пример

Един от най-класическите проблеми с GPU е проблемът за изчисляване на взаимодействието на N тела, които създават гравитационно поле. Но ако, например, трябва да изчислим еволюцията на системата Земя-Луна-Слънце, тогава графичният процесор е лош помощник за нас: има малко обекти. За всеки обект е необходимо да се изчислят взаимодействията с всички останали обекти, а има само два от тях. В случай на движение на слънчевата система с всички планети и техните луни (около няколкостотин обекта), GPU все още не е много ефективен. Въпреки това, многоядрен процесор, поради високите режийни разходи за управление на нишки, също няма да може да покаже цялата си мощност, той ще работи в еднопоточен режим. Но ако също трябва да изчислите траекториите на комети и обекти от астероидния пояс, тогава това вече е задача за графичния процесор, тъй като има достатъчно обекти за създаване на необходимия брой паралелни изчислителни нишки.

Графичният процесор също ще се представи добре, ако е необходимо да се изчисли сблъсъкът на кълбовидни купове от стотици хиляди звезди.

Друга възможност за използване на мощността на графичния процесор в проблема с N-тела се появява, когато трябва да изчислите много отделни проблеми, макар и с малък брой тела. Например, ако искате да изчислите еволюцията на една система за различни опции за начални скорости. Тогава ще бъде възможно ефективното използване на GPU без проблеми.

Подробности за микроархитектурата на AMD Radeon

Разгледахме основните принципи на организацията на GPU, те са общи за видео ускорителите на всички производители, тъй като първоначално имаха една целева задача - шейдърни програми. Въпреки това, производителите намериха за възможно да не са съгласни относно детайлите на микроархитектурното изпълнение. Въпреки че процесорите на различните доставчици понякога са много различни, дори и да са съвместими, като например Pentium 4 и Athlon или Core. Архитектурата на Nvidia вече е широко известна, сега ще разгледаме Radeon и ще подчертаем основните разлики в подходите на тези доставчици.

Графичните карти на AMD получиха пълна поддръжка за изчисления с общо предназначение след фамилията Evergreen, която също е пионер в спецификацията DirectX 11. Картите от фамилията 47xx имат редица значителни ограничения, които ще бъдат обсъдени по-долу.

Разликите в размера на локалната памет (32 KB за Radeon срещу 16 KB за GT200 и 64 KB за Fermi) обикновено не са фундаментални. Както и размера на фронта на вълната от 64 нишки за AMD срещу 32 нишки на деформация за Nvidia. Почти всяка GPU програма може лесно да бъде преконфигурирана и настроена към тези параметри. Производителността може да се промени с десетки процента, но в случай на GPU това не е толкова важно, тъй като програмата на GPU обикновено работи десет пъти по-бавно от аналога си за CPU, или десет пъти по-бързо, или изобщо не работи.

По-важно е използването Технологии на AMD VLIW (Много дълга дума с инструкции). Nvidia използва прости скаларни инструкции, които работят със скаларни регистри. Неговите ускорители реализират прост класически RISC. Графичните карти на AMD имат същия брой регистри като GT200, но регистрите са 128-битови векторни. Всяка инструкция VLIW работи с няколко четирикомпонентни 32-битови регистъра, което е подобно на SSE, но възможностите на VLIW са много по-широки. Това не е SIMD (Single Instruction Multiple Data) като SSE - тук инструкциите за всяка двойка операнди могат да бъдат различни и дори зависими! Например, нека компонентите на регистър A са наречени a1, a2, a3, a4; за регистър B - аналогично. Може да се изчисли с една инструкция, която се изпълнява в един цикъл, например числото a1×b1+a2×b2+a3×b3+a4×b4 или двумерен вектор (a1×b1+a2×b2, a3× b3+a4×b4 ).

Това стана възможно благодарение на по-ниската честота на GPU в сравнение с CPU и силното намаляване на техническите процеси в последните години. Това не изисква никакъв планировчик, почти всичко се изпълнява на часовник.

С векторни инструкции върховата производителност на Radeon с единична точност е много висока, при терафлопс.

Един векторен регистър може да съхранява едно число с двойна точност вместо четири числа с единична точност. И една VLIW инструкция може или да събере две двойки двойки, или да умножи две числа, или да умножи две числа и да добави към третото. По този начин пиковата производителност при двойно е около пет пъти по-ниска, отколкото при плаващ. За по-старите модели Radeon отговаря на Производителност на Nvidia Tesla на новата архитектура Fermi и много по-висока производителност от двойните карти на архитектурата GT200. В потребителските видеокарти Geforce, базирани на Fermi, максималната скорост на двойните изчисления беше намалена четири пъти.


Принципна диаграма на работата на Radeon. Показан е само един минипроцесор от 20, работещи паралелно

Производителите на GPU, за разлика от производителите на CPU (на първо място, x86-съвместимите), не са обвързани от проблеми със съвместимостта. Програмата на GPU първо се компилира в някакъв междинен код и когато програмата се стартира, драйверът компилира този код в машинни инструкции, специфични за специфичен модел. Както беше описано по-горе, производителите на GPU се възползваха от това, като изобретиха удобна ISA (Instruction Set Architecture) за своите GPU и ги променяха от поколение на поколение. Във всеки случай това добави някакъв процент производителност поради липсата (като ненужен) на декодера. Но AMD отиде още по-далеч, изобретявайки свой собствен формат за подреждане на инструкции в машинен код. Те не са подредени последователно (според листинга на програмата), а по секции.

Първо идва секцията с инструкции за условен скок, които имат връзки към секции с непрекъснати аритметични инструкции, съответстващи на различни клонове на клонове. Те се наричат ​​VLIW пакети (пакети от VLIW инструкции). Тези раздели съдържат само аритметични инструкции с данни от регистри или локална памет. Такава организация опростява потока от инструкции и доставянето им до изпълнителните звена. Това е още по-полезно, като се има предвид, че VLIW инструкциите са относително големи. Има и секции за инструкции за достъп до паметта.

Раздели с инструкции за условно разклоняване
Раздел 0Разклоняване 0Връзка към раздел #3 от непрекъснати аритметични инструкции
Секция 1Разклоняване 1Линк към раздел #4
Раздел 2Разклоняване 2Линк към раздел #5
Раздели от непрекъснати аритметични инструкции
Раздел 3VLIW инструкция 0VLIW инструкция 1VLIW инструкция 2VLIW инструкция 3
Раздел 4VLIW инструкция 4VLIW инструкция 5
Раздел 5VLIW инструкция 6VLIW инструкция 7VLIW инструкция 8VLIW инструкция 9

Графичните процесори от двата производителя (както Nvidia, така и AMD) също имат вградени инструкции за бързо изчисляване на основни математически функции, квадратен корен, експонента, логаритми, синуси и косинуси за числа с единична точност в няколко цикъла. За това има специални изчислителни блокове. Те „дойдоха“ от необходимостта да се приложи бързо сближаване на тези функции в геометричните шейдъри.

Дори ако някой не е знаел, че графичните процесори се използват за графики и се е запознал само с техническите характеристики, тогава по този знак може да предположи, че тези изчислителни копроцесори произхождат от видео ускорители. По подобен начин някои черти на морските бозайници са накарали учените да вярват, че техните предци са били сухоземни същества.

Но по-очевидна характеристика, която издава графичния произход на устройството, са блоковете за четене на двуизмерни и триизмерни текстури с поддръжка на билинейна интерполация. Те се използват широко в GPU програми, тъй като осигуряват по-бързо и лесно четене на масиви от данни само за четене. Един от стандартни опцииПоведението на GPU приложение е да чете масиви от първоначални данни, да ги обработва в изчислителните ядра и да записва резултата в друг масив, който след това се прехвърля обратно към CPU. Такава схема е стандартна и често срещана, тъй като е удобна за архитектурата на GPU. Задачите, които изискват интензивно четене и запис в една голяма област от глобалната памет, като по този начин съдържат зависимости от данни, са трудни за паралелизиране и ефективно изпълнение на GPU. Освен това тяхната производителност ще зависи до голяма степен от латентността на глобалната памет, която е много голяма. Но ако задачата е описана от модела „четене на данни – обработка – запис на резултата“, тогава почти сигурно можете да получите голям тласък от нейното изпълнение на GPU.

За текстурните данни в GPU има отделна йерархия от малки кешове на първо и второ ниво. Той също така осигурява ускорение от използването на текстури. Тази йерархия първоначално се появи в GPU, за да се възползва от локалността на достъпа до текстури: очевидно, след обработка на един пиксел, съседен пиксел (с голяма вероятност) ще изисква близко разположени текстурни данни. Но много алгоритми за конвенционални изчисления имат подобен характер на достъп до данни. Така че кешовете на текстурите от графиките ще бъдат много полезни.

Въпреки че размерът на кешовете L1-L2 в картите на Nvidia и AMD е приблизително еднакъв, което очевидно се дължи на изискванията за оптималност по отношение на игровата графика, латентността на достъпа до тези кеши се различава значително. Забавянето на достъпа на Nvidia е по-високо, а кешовете на текстурите в Geforce помагат предимно за намаляване на натоварването на шината на паметта, вместо директно да ускоряват достъпа до данни. Това не се забелязва в графичните програми, но е важно за програмите с общо предназначение. В Radeon латентността на текстурния кеш е по-ниска, но латентността на локалната памет на минипроцесорите е по-висока. Ето един пример: за оптимално умножение на матрици на карти на Nvidia е по-добре да използвате локална памет, като зареждате матрицата там блок по блок, а за AMD е по-добре да разчитате на текстурен кеш с ниска латентност, четейки матричните елементи като необходими. Но това вече е доста фина оптимизация и за алгоритъм, който вече е фундаментално прехвърлен към GPU.

Тази разлика се проявява и при използване на 3D текстури. Един от първите GPU изчислителни бенчмаркове, който показа сериозно предимство за AMD, просто използва 3D текстури, тъй като работи с триизмерен масив от данни. И забавянето на достъпа до текстурата в Radeon е значително по-бързо, а 3D кутията е допълнително по-оптимизирана хардуерно.

За да получите максимална производителност от хардуера на различни компании, е необходима известна настройка на приложението за конкретна карта, но тя е с порядък по-малко значима от по принцип разработването на алгоритъм за архитектурата на GPU.

Ограничения за серия Radeon 47xx

В това семейство поддръжката за GPU изчисления е непълна. Има три важни моменти. Първо, няма локална памет, тоест тя е физически там, но няма универсалния достъп, изискван от съвременния стандарт на GPU програми. Той е програмно емулиран в глобалната памет, което означава, че няма да има полза от използването му за разлика от пълнофункционален GPU. Втората точка е ограничена поддръжка за различни инструкции за операции с атомна памет и инструкции за синхронизиране. И третата точка е доста малък размеркеш на инструкциите: започвайки от определен размер на програмата, скоростта се забавя няколко пъти. Има и други малки ограничения. Можем да кажем, че само програми, които са идеално пригодени за GPU, ще работят добре на тази видеокарта. Въпреки че видеокартата може да покаже добри резултати в Gigaflops в прости тестови програми, които работят само с регистри, е проблематично да се програмира ефективно нещо сложно за нея.

Предимства и недостатъци на Evergreen

Ако сравним продуктите на AMD и Nvidia, тогава по отношение на GPU изчисленията серията 5xxx изглежда като много мощен GT200. Толкова мощен, че превъзхожда Ферми по върхова производителност около два и половина пъти. Особено след като параметрите на новите видеокарти на Nvidia бяха намалени, броят на ядрата беше намален. Но появата на L2 кеша във Fermi опростява внедряването на някои алгоритми на GPU, като по този начин разширява обхвата на GPU. Интересното е, че за добре оптимизирани за предишното поколение GT200 CUDA програми, архитектурните иновации на Fermi често не правеха нищо. Те се ускориха пропорционално на увеличаването на броя на изчислителните модули, тоест по-малко от два пъти (за числа с единична точност) или дори по-малко, защото честотната лента на паметта не се увеличи (или по други причини).

И в задачи, които се вписват добре в архитектурата на GPU и имат подчертан векторен характер (например умножение на матрици), Radeon показва производителност, относително близка до теоретичния връх и изпреварва Fermi. Да не говорим за многоядрените процесори. Особено при проблеми с числа с единична точност.

Но Radeon има по-малка площ на матрицата, по-малко разсейване на топлината, консумация на енергия, по-висок добив и съответно по-ниска цена. И директно в проблемите на 3D графиката, усилването на Ферми, ако има такова, е много по-малко от разликата в площта на кристала. Това до голяма степен се дължи на факта, че изчислителната архитектура на Radeon, с 16 изчислителни единици на минипроцесор, 64-нишков вълнов фронт и VLIW векторни инструкции, е идеална за основната си задача - изчислителни графични шейдъри. За огромното мнозинство обикновени потребителипроизводителността и цената в игрите са приоритет.

От гледна точка на професионални, научни програми, архитектурата Radeon осигурява най-доброто съотношение цена-производителност, производителност на ват и абсолютна производителност в задачи, които по принцип пасват добре на GPU архитектурата, позволяват паралелизиране и векторизация.

Например, в напълно паралелен, лесно векторизиращ се проблем за избор на ключ, Radeon е няколко пъти по-бърз от Geforce и няколко десетки пъти по-бърз от CPU.

Това съответства на общата концепция на AMD Fusion, според която графичните процесори трябва да допълват процесора и в бъдеще да бъдат интегрирани в самото ядро ​​на процесора, точно както преди това математическият копроцесор беше прехвърлен от отделен чип към ядрото на процесора (това се случи около преди двадесет години, преди появата на първите процесори Pentium). GPU ще бъде интегриран графично ядрои векторен копроцесор за стрийминг задачи.

Radeon използва сложна техника за смесване на инструкции от различни вълнови фронтове, когато се изпълняват от функционални модули. Това е лесно да се направи, тъй като инструкциите са напълно независими. Принципът е подобен на конвейерното изпълнение на независими инструкции от съвременните процесори. Очевидно това прави възможно ефективното изпълнение на сложни, многобайтови, векторни VLIW инструкции. В процесора това изисква усъвършенстван планировчик за идентифициране на независими инструкции или използването на технология Hyper-Threading, която също доставя на процесора известни независими инструкции от различни нишки.

мярка 0лента 1мярка 2мярка 3лента 4мярка 5мярка 6мярка 7VLIW модул
фронт на вълната 0фронт на вълната 1фронт на вълната 0фронт на вълната 1фронт на вълната 0фронт на вълната 1фронт на вълната 0фронт на вълната 1
инстр. 0инстр. 0инстр. 16инстр. 16инстр. 32инстр. 32инстр. 48инстр. 48VLIW0
инстр. единVLIW1
инстр. 2VLIW2
инстр. 3VLIW3
инстр. четириVLIW4
инстр. 5VLIW5
инстр. 6VLIW6
инстр. 7VLIW7
инстр. осемVLIW8
инстр. 9VLIW9
инстр. десетVLIW10
инстр. единадесетVLIW11
инстр. 12VLIW12
инстр. 13VLIW13
инстр. четиринадесетVLIW14
инстр. петнадесетVLIW15

128 инструкции на два вълнови фронта, всеки от които се състои от 64 операции, се изпълняват от 16 VLIW модула в осем цикъла. Има редуване и всеки модул всъщност има два цикъла за изпълнение на цяла инструкция, при условие че започне да изпълнява нова паралелно на втория цикъл. Това вероятно помага за бързото изпълнение на VLIW инструкция като a1×a2+b1×b2+c1×c2+d1×d2, тоест изпълнение на осем такива инструкции в осем цикъла. (Формално, оказва се, по един на часовник.)

Nvidia очевидно няма тази технология. И при отсъствието на VLIW, високата производителност при използване на скаларни инструкции изисква висока честота на работа, което автоматично увеличава разсейването на топлината и поставя високи изисквания към процеса (за да принуди веригата да работи на по-висока честота).

Недостатъкът на Radeon по отношение на GPU изчисленията е голяма неприязън към разклоненията. Графичните процесори обикновено не предпочитат разклоняването поради горната технология за изпълнение на инструкции: незабавно от група нишки с един програмен адрес. (Между другото, тази техника се нарича SIMT: Single Instruction - Multiple Threads (една инструкция - много нишки), по аналогия със SIMD, където една инструкция изпълнява една операция с различни данни.) . Ясно е, че ако програмата не е напълно векторна, тогава колкото по-голям е размерът на деформацията или фронта на вълната, толкова по-лошо, тъй като когато пътят през програмата се отклонява, се образуват съседни нишки повече групи, които трябва да се изпълняват последователно (сериализирани). Да кажем, че всички нишки са се разпръснали, тогава в случай на размер на деформация от 32 нишки, програмата ще работи 32 пъти по-бавно. А в случай на размер 64, както при Radeon, той е 64 пъти по-бавен.

Това е забележима, но не единствена проява на "нехаресване". Във видеокартите на Nvidia всеки функционален модул, иначе наричан CUDA ядро, има специален разклонителен процесор. А във видеокартите Radeon за 16 изчислителни модула има само две разклонени контролни единици (те са получени от домейна на аритметичните единици). Така че дори простата обработка на инструкция за условно разклоняване, дори ако нейният резултат е еднакъв за всички нишки във фронта на вълната, отнема допълнително време. И скоростта пада.

AMD също произвежда процесори. Те смятат, че за програми с много разклонения процесорът все още е по-подходящ, а графичният процесор е предназначен за чисто векторни програми.

Така Radeon осигурява по-малко ефективно програмиране като цяло, но по-добро съотношение цена-производителност в много случаи. С други думи, има по-малко програми, които могат да бъдат ефективно (полезно) мигрирани от CPU към Radeon, отколкото програми, които могат ефективно да се изпълняват на Fermi. Но от друга страна, тези, които могат да бъдат ефективно прехвърлени, ще работят по-ефективно на Radeon по много начини.

API за GPU изчисления

себе си технически спецификации Radeon изглежда привлекателно, дори и да не е необходимо да се идеализира и абсолютизира GPU изчисленията. Но не по-малко важен за производителността е софтуерът, необходим за разработване и изпълнение на GPU програма - компилатори от език от високо ниво и време за изпълнение, тоест драйвер, който взаимодейства между част от програмата, изпълнявана на CPU и GPU себе си. Това е дори по-важно, отколкото в случая с процесора: процесорът не се нуждае от драйвер, за да управлява трансфера на данни, а от гледна точка на компилатора графичният процесор е по-претенциозен. Например, компилаторът трябва да се задоволи с минимален брой регистри, за да съхранява междинни резултати от изчисленията, както и спретнато вградени извиквания на функции, отново използвайки минимум регистри. В края на краищата, колкото по-малко регистри използва една нишка, толкова повече нишки можете да изпълнявате и колкото по-пълно зареждате GPU, като по-добре скривате времето за достъп до паметта.

И така софтуерната поддръжка за продуктите Radeon все още изостава от развитието на хардуера. (За разлика от ситуацията с Nvidia, където пускането на хардуер беше отложено и продуктът беше пуснат в съкратена форма.) Съвсем наскоро OpenCL компилаторът на AMD беше в бета статус с много недостатъци. Той твърде често генерира грешен код или отказва да компилира кода от правилния изходен код, или самият той дава грешка и се срива. Едва в края на пролетта излезе издание с висока производителност. Също така не е без грешки, но има значително по-малко от тях и те, като правило, се появяват в кулоарите, когато се опитвате да програмирате нещо на ръба на коректността. Например, те работят с типа uchar4, който определя 4-байтова четирикомпонентна променлива. Този тип е в спецификациите на OpenCL, но не си струва да работите с него на Radeon, защото регистрите са 128-битови: същите четири компонента, но 32-битови. И такава променлива uchar4 все още ще заема цял регистър, само ще се изискват допълнителни операции за опаковане и достъп до отделни байтови компоненти. Компилаторът не трябва да има никакви грешки, но няма компилатори без грешки. Дори Intel Compiler след 11 версия има грешки при компилиране. Идентифицираните грешки са коригирани в следващото издание, което ще бъде пуснато по-близо до есента.

Но все още има много неща, които трябва да се подобрят. Например, досега стандартният GPU драйвер за Radeon не поддържа GPU изчисления с помощта на OpenCL. Потребителят трябва да изтегли и инсталира допълнителен специален пакет.

Но най-важното е липсата на библиотеки с функции. За реални числа с двойна точност няма дори синус, косинус и степен. Е, това не е необходимо за матрично събиране/умножение, но ако искате да програмирате нещо по-сложно, трябва да напишете всички функции от нулата. Или изчакайте нова версия на SDK. ACML ще бъде пуснат скоро ( AMD Core Math Library) за фамилията Evergreen GPU с поддръжка на основни матрични функции.

В момента, според автора на статията, използването на Direct Compute 5.0 API изглежда реално за програмиране на видеокарти Radeon, естествено като се вземат предвид ограниченията: ориентация към платформата Windows 7 и Windows Vista. Microsoft има много опит в създаването на компилатори и можем да очакваме напълно функционална версия много скоро, Microsoft е пряко заинтересована от това. Но Direct Compute е фокусиран върху нуждите на интерактивните приложения: да се изчисли нещо и веднага да се визуализира резултатът - например потокът на течност върху повърхност. Това не означава, че не може да се използва просто за изчисления, но това не е естественото му предназначение. Например Microsoft не планира да добавя библиотечни функции към Direct Compute – точно тези, които AMD няма в момента. Тоест, това, което сега може да бъде ефективно изчислено на Radeon - някои не много сложни програми - може да бъде имплементирано и на Direct Compute, което е много по-просто от OpenCL и трябва да е по-стабилно. Плюс това, той е напълно преносим и ще работи както на Nvidia, така и на AMD, така че ще трябва да компилирате програмата само веднъж, докато реализациите на OpenCL SDK на Nvidia и AMD не са съвсем съвместими. (В смисъл, че ако разработите OpenCL програма на система AMD с помощта на AMD OpenCL SDK, тя може да не работи толкова лесно на Nvidia. Може да се наложи да компилирате същия текст с помощта на Nvidia SDK. И обратното, разбира се. )

След това има много излишни функции в OpenCL, тъй като OpenCL е предназначен да бъде универсален език за програмиране и API за широк набор от системи. И GPU, и CPU, и Cell. Така че в случай, че просто искате да напишете програма за типична потребителска система (процесор плюс видеокарта), OpenCL не изглежда да бъде, така да се каже, "високо продуктивен". Всяка функция има десет параметъра, като девет от тях трябва да бъдат зададени на 0. И за да зададете всеки параметър, трябва да извикате специална функция, която също има параметри.

И най-важното текущо предимство на Direct Compute е, че потребителят не трябва да инсталира специален пакет: всичко, което е необходимо, вече е в DirectX 11.

Проблеми на развитието на GPU изчисленията

Ако вземем областта на персоналните компютри, тогава ситуацията е следната: няма много задачи, които изискват много изчислителна мощност и силно липсват в конвенционален двуядрен процесор. Сякаш големи лакоми, но тромави чудовища бяха изпълзяли от морето на сушата, а на сушата нямаше почти нищо за ядене. И първичните жилища на земната повърхност намаляват по размер, учат се да консумират по-малко, както винаги се случва при недостиг на природни ресурси. Ако днес имаше същата нужда от производителност, както преди 10-15 години, GPU изчисленията биха били приети с гръм и трясък. И така проблемите със съвместимостта и относителната сложност на програмирането на GPU излизат на преден план. По-добре е да напишете програма, която работи на всички системи, отколкото програма, която е бърза, но работи само на GPU.

Перспективата за GPU е малко по-добра по отношение на използването им в професионални приложения и сектора на работните станции, тъй като има повече търсене на производителност. Появяват се плъгини за 3D редактори с поддръжка на GPU: например за изобразяване с проследяване на лъчи - да не се бърка с обикновено изобразяване на GPU! Нещо се появява и за 2D и редактори на презентации, с по-бързо създаване на сложни ефекти. Програмите за обработка на видео също постепенно придобиват поддръжка за GPU. Горните задачи, с оглед на техния паралелен характер, се вписват добре в архитектурата на GPU, но сега е създадена много голяма кодова база, отстранени са грешки, оптимизирани за всички възможности на CPU, така че ще отнеме време, за да се появят добри реализации на GPU.

В този сегмент се проявяват и такива слабости на GPU, като например ограничено количество видеопамет - около 1 GB за конвенционалните GPU. Един от основните фактори, които намаляват производителността на GPU програмите, е необходимостта от обмен на данни между CPU и GPU по бавна шина и поради ограниченото количество памет трябва да се прехвърлят повече данни. И тук концепцията на AMD за комбиниране на GPU и CPU в един модул изглежда обещаваща: можете да пожертвате високата честотна лента на графичната памет за лесен и лесен достъп до споделена памет, освен това с по-ниска латентност. Тази висока честотна лента на текущата DDR5 видео памет е много по-търсена директно графични програмиотколкото повечето GPU изчислителни програми. В общи линии, Обща памет GPU и CPU просто значително ще разширят обхвата на GPU, ще направят възможно използването на неговите изчислителни възможности в малки подзадачи на програми.

И най-вече графичните процесори са търсени в областта на научните изчисления. Вече са изградени няколко GPU-базирани суперкомпютри, които показват много високи резултати при теста на матричните операции. Научните проблеми са толкова разнообразни и многобройни, че винаги има набор, който пасва идеално на GPU архитектурата, за която използването на GPU улеснява постигането на висока производителност.

Ако изберете една от всички задачи на съвременните компютри, тогава това ще бъде компютърната графика - изображение на света, в който живеем. И оптималната за тази цел архитектура не може да бъде лоша. Това е толкова важна и фундаментална задача, че специално разработеният за нея хардуер трябва да бъде универсален и оптимален за различни задачи. Освен това видеокартите се развиват успешно.

Един от най скрити функции, в скорошна актуализация на Windows 10, е възможността да проверите кои приложения използват вашия графичен процесор (GPU). Ако някога сте отваряли диспечера на задачите, вероятно сте разглеждали използването на вашия процесор, за да видите кои приложения са най-интензивни за процесора. AT последни актуализациидобави подобна функция, но за GPU GPU. Помага да разберете колко интензивни са вашият софтуер и игри на вашия графичен процесор, без да изтегляте софтуер на трети страни. Има още една интересна функция, която помага да разтоварите вашия процесор към графичния процесор. Препоръчвам да прочетете как да изберете.

Защо нямам GPU в диспечера на задачите?

За съжаление, не всички графични карти ще могат да осигурят на Windows статистиката, от която се нуждае, за да чете GPU. За да сте сигурни, можете бързо да използвате инструмента за диагностика на DirectX, за да тествате тази технология.

  1. Щракнете върху " Започнете"и в търсенето напишете dxdiagза да стартирате инструмента за диагностика на DirectX.
  2. Отидете на раздела " екран",точно в колоната драйвери"трябва да имаш WDDM моделпо-висока от версия 2.0, за да използвате графиките на GPU в диспечера на задачите.

Активирайте GPU Graph в диспечера на задачите

За да видите използването на GPU за всяко приложение, трябва да отворите диспечера на задачите.

  • Натиснете комбинация от бутони Ctrl + Shift + Escза да отворите диспечера на задачите.
  • Кликнете Кликнете с десния бутонщракнете в диспечера на задачите върху празното поле " име"и проверете от падащото меню GPU.Можете също да отбележите GPU ядроза да видите кои програми го използват.
  • Сега в диспечера на задачите графиката на GPU и ядрото на GPU се виждат отдясно.


Вижте цялостната производителност на GPU

Можете да проследявате общото използване на GPU, за да наблюдавате и анализирате при тежки натоварвания. В този случай можете да видите всичко необходимо в " производителност"като изберете графичен процесор.


Всеки GPU елемент е разбит на отделни графики, за да ви даде още по-добра представа за това как се използва вашият GPU. Ако искате да промените диаграмите, които се показват, можете да щракнете върху малката стрелка до заглавието на всяка задача. Този екран също показва версията и датата на вашия драйвер, което е добра алтернатива на използването на DXDiag или Device Manager.


Никога няма твърде много ядра...

Съвременните графични процесори са чудовищно бързи зверове, способни да дъвчат гигабайти данни. Въпреки това, човек е хитър и, без значение как те растат изчислителна мощност, идва с все по-трудни задачи, така че идва моментът, в който трябва да констатирате с тъга, че е необходима оптимизация 🙁

Тази статия описва основните понятия, за да улесни навигацията в теорията на gpu-оптимизацията и основните правила, така че тези понятия да се използват по-рядко.

Причините, поради които GPU са ефективни за работа с големи количества данни, които изискват обработка:

  • имат големи възможности за паралелно изпълнение на задачи (много, много процесори)
  • висока честотна лента на паметта

Честотна лента на паметта- това е колко информация - битове или гигабайти - може да бъде прехвърлена за единица време, секунда или процесорен цикъл.

Една от задачите на оптимизацията е да се използва максималната пропускателна способност - да се увеличи производителността пропускателна способност(в идеалния случай трябва да е равна на честотната лента на паметта).

За да подобрите използването на честотната лента:

  • увеличете количеството информация - използвайте честотната лента докрай (например всеки поток работи с float4)
  • намаляване на латентността - забавянето между операциите

Латентност- интервалът от време между моментите, в които контролерът поиска конкретна клетка от паметта, и момента, в който данните станаха достъпни за процесора за изпълнение на инструкции. Не можем да повлияем по никакъв начин на самото забавяне - тези ограничения са налице на хардуерно ниво. Благодарение на това забавяне процесорът може да обслужва едновременно няколко нишки - докато нишката A е поискала да му разпредели памет, нишката B може да изчисли нещо, а нишката C може да изчака, докато пристигнат исканите данни.

Как да намалите забавянето, ако се използва синхронизация:

  • намаляване на броя на нишките в блок
  • увеличаване на броя на блоковите групи

Пълно използване на ресурсите на GPU - GPU заетост

В разговорите за оптимизация терминът често мига - заетост на gpuили заетост на ядрото- отразява ефективността на използване на ресурсите-капацитети на видеокартата. Отделно отбелязвам, че дори да използвате всички ресурси, това не означава, че ги използвате правилно.

Изчислителната мощност на графичния процесор е стотици процесори, алчни за изчисления, при създаване на програма - ядрото (ядрото) - тежестта на разпределението на натоварването върху тях пада върху раменете на програмиста. Грешка може да доведе до бездействие на повечето от тези ценни ресурси без причина. Сега ще обясня защо. Трябва да започнете отдалече.

Нека ви напомня, че деформацията ( изкривяване в терминологията на NVidia, вълнов фронт - в терминологията на AMD) - набор от нишки, които едновременно изпълняват една и съща функция на ядрото на процесора. Нишките, обединени от програмиста в блокове, се разделят на изкривявания от планировчика на нишки (поотделно за всеки мултипроцесор) - докато една изкривяване работи, втората чака обработка на заявки за памет и т.н. Ако някои от warp нишките все още извършват изчисления, докато други вече са направили всичко по силите си, тогава има неефективно използване на изчислителния ресурс - популярно наричано празна мощност.

Всяка точка на синхронизация, всеки клон на логиката може да създаде такава празна ситуация. Максималната дивергенция (разклоняване на логиката на изпълнение) зависи от размера на деформацията. За GPU на NVidia това е 32, за AMD, 64.

За да намалите времето за престой на мултипроцесора по време на изпълнение на warp:

  • минимизиране на бариерите във времето за изчакване
  • минимизиране на различията в логиката на изпълнение във функцията на ядрото

За да се реши ефективно този проблем, има смисъл да се разбере как се образуват изкривявания (за случая с няколко измерения). Всъщност редът е прост - първо в X, след това в Y и последно в Z.

ядрото се стартира с 64×16 блока, нишките са разделени на основи в ред X, Y, Z - т.е. първите 64 елемента се разделят на две основи, след това втората и т.н.

Ядрото започва с 16x64 блока. Първият и вторият 16 елемента се добавят към първата основа, третият и четвъртият елемент се добавят към втората основа и т.н.

Как да намалите разминаването (запомнете - разклоняването не винаги е причина за критична загуба на производителност)

  • когато съседни нишки имат различни пътища за изпълнение - много условия и преходи по тях - потърсете начини за преструктуриране
  • потърсете небалансиран товар от нишки и го премахнете решително (това е, когато не само имаме условия, но поради тези условия, първата нишка винаги изчислява нещо, а петата не попада в това състояние и е неактивна)

Как да извлечете максимума от GPU ресурсите

GPU ресурсите, за съжаление, също имат своите ограничения. И, строго погледнато, преди да стартирате функцията на ядрото, има смисъл да се определят ограничения и да се вземат предвид тези ограничения при разпределяне на товара. Защо е важно?

Видеокартите имат ограничения за общия брой нишки, които един мултипроцесор може да изпълни, максималния брой нишки в един блок, максималния брой деформации на един процесор, ограничения за различни типове памет и т.н. Цялата тази информация може да бъде поискана както програмно, чрез съответния API, така и преди това с помощта на помощни програми от SDK. (deviceQuery модули за NVidia устройства, CLINfo модули за AMD видео карти).

Генерална репетиция:

  • броят на нишките блокове/работни групи трябва да е кратен на броя на поточните процесори
  • размерът на блока/работната група трябва да бъде кратен на размера на деформацията

В същото време трябва да се има предвид, че абсолютният минимум - 3-4 warps / wayfronts се въртят едновременно на всеки процесор, мъдрите ръководства съветват да се продължи от съображението - най-малко седем wayfronts. В същото време - не забравяйте ограниченията върху ютията!

Поддържането на всички тези подробности в главата ви бързо става скучно, затова за изчисляване на заетостта на gpu NVidia предложи неочакван инструмент - калкулатор на Excel (!), пълен с макроси. Там можете да въведете информация за максималния брой нишки за SM, броя на регистрите и размера на споделената (споделена) памет, налична на поточен процесор, и използваните параметри за стартиране на функции - и дава процент от ефективността на използването на ресурсите (и си скубеш косата, осъзнавайки, че нямаш достатъчно регистри, за да използваш всички ядра).

информация за употреба:
http://docs.nvidia.com/cuda/cuda-c-best-practices-guide/#calculating-occupancy

Операции с GPU и памет

Видеокартите са оптимизирани за 128-битови операции с памет. Тези. в идеалния случай всяка манипулация на паметта, в идеалния случай, трябва да промени 4 четирибайтови стойности наведнъж. Основното раздразнение за програмиста е, че съвременните компилатори за GPU не могат да оптимизират подобни неща. Това трябва да се направи точно във функционалния код и средно носи части от процента от печалбите в производителността. Честотата на заявките за памет има много по-голямо влияние върху производителността.

Проблемът е следният - всяка заявка връща в отговор част от данните, кратни на 128 бита. И всяка нишка използва само една четвърт от него (в случай на нормална четирибайтова променлива). Когато съседни нишки работят едновременно с данни, разположени последователно в клетките на паметта, това намалява общия брой достъпи до паметта. Това явление се нарича комбинирани операции за четене и запис ( обединен достъп - добре! както чета, така и пиша) - и с правилната организация на кода ( кратък достъп до непрекъсната част от паметта - лошо!) може значително да подобри производителността. Когато организирате вашето ядро ​​- запомнете - непрекъснат достъп - в рамките на елементите на един ред памет, работата с елементите на колона вече не е толкова ефективна. Искате повече подробности? Хареса ми този pdf - или Google за " техники за обединяване на паметта “.

Водещата позиция в номинацията „тясно място“ се заема от друга операция с памет - копирайте данни от паметта на хоста в GPU . Копирането не се случва така или иначе, а от област на паметта, специално разпределена от драйвера и системата: когато се направи заявка за копиране на данни, системата първо копира тези данни там и едва след това ги качва в GPU. Скоростта на пренос на данни е ограничена от честотната лента PCI шина Express xN (където N е броят на линиите за данни), чрез които съвременните видеокарти комуникират с хоста.

Въпреки това, допълнителното копиране на бавна памет на хоста понякога е неоправдано излишно. Изходът е използването на т.нар фиксирана памет - специално маркирана област на паметта, така че операционната система да не може да извършва никакви операции с нея (например разтоварване за размяна / преместване по свое усмотрение и т.н.). Прехвърлянето на данни от хоста към видеокартата се извършва без участието на операционната система - асинхронно, чрез DMA (директен достъп до паметта).

И накрая, още малко за паметта. Споделената памет на мултипроцесор обикновено е организирана под формата на банки памет, съдържащи 32-битови думи - данни. Броят на банките традиционно варира от едно GPU поколение до друго - 16/32 Ако всяка нишка изисква данни от отделна банка, всичко е наред. В противен случай се получават няколко заявки за четене / запис към една банка и получаваме - конфликт ( конфликт на банка споделена памет). Такива конфликтни извиквания се сериализират и следователно се изпълняват последователно, а не паралелно. Ако всички нишки имат достъп до една и съща банка, се използва отговор „излъчване“ ( излъчване) и няма конфликт. Има няколко начина за ефективно справяне с конфликтите на достъп, хареса ми описание на основните техники за премахване на конфликти при достъп до банки с памет – .

Как да направим математическите операции още по-бързи? Не забравяйте, че:

  • изчисленията с двойна точност са тежко натоварване при работа с fp64 >> fp32
  • константите във формата 3.13 в кода по подразбиране се интерпретират като fp64, ако не посочите изрично 3.14f
  • за оптимизиране на математиката, няма да е излишно да се консултирате в ръководствата - и има ли флагове за компилатора
  • доставчиците включват функции в своите SDK, които се възползват от характеристиките на устройството, за да постигнат производителност (често за сметка на преносимостта)

Има смисъл разработчиците на CUDA да обърнат голямо внимание на концепцията cuda поток,което ви позволява да изпълнявате няколко основни функции наведнъж на едно устройство или да комбинирате асинхронно копиране на данни от хост към устройството по време на изпълнение на функции. OpenCL все още не предоставя такава функционалност 🙁

Профилиране на боклуци:

NVifia Visual Profiler е интересна помощна програма, която анализира както CUDA, така и OpenCL ядра.

P.S. Като по-дълго ръководство за оптимизация, мога да препоръчам да търсите в Google всички видове ръководство за най-добри практики за OpenCL и CUDA.

  • ,

Говорейки за паралелни изчисления на графичния процесор, трябва да помним в какво време живеем, днес е времето, когато всичко в света се ускорява толкова много, че губим представа за времето, без да забелязваме как то бърза. Всичко, което правим, е свързано с висока точност и скорост на обработка на информацията, в такива условия със сигурност се нуждаем от инструменти, за да обработим цялата информация, която имаме и да я преобразуваме в данни, освен това, говорейки за такива задачи, трябва да помним, че тези задачи са необходими не само за големи организации или мега-корпорации, но обикновените потребители вече също трябва да решават такива проблеми, които решават своите жизненоважни задачи, свързани с високите технологии у дома на персонални компютри! Появата на NVIDIA CUDA не беше изненадваща, а по-скоро оправдана, защото веднага след като ще трябва да обработвате много по-отнемащи време задачи на компютър, отколкото преди. Работата, която преди отнемаше много време, сега ще отнеме няколко минути, съответно това ще се отрази на цялостната картина на целия свят!

Какво е GPU Computing

GPU изчисленията са използването на GPU за изчисляване на технически, научни и ежедневни задачи. Изчисляването на GPU включва използването на CPU и GPU с разнороден избор между тях, а именно: последователната част от програмите се поема от CPU, докато отнемащите време изчислителни задачи остават от GPU. Благодарение на това задачите се паралелизират, което води до по-бърза обработка на информацията и намалява времето, необходимо за завършване на работата, системата става по-продуктивна и може едновременно да обработва повече задачи от преди. Въпреки това, за да се постигне такъв успех, само хардуерната поддръжка не е достатъчна, в този случай е необходима и софтуерна поддръжка, за да може приложението да прехвърли най-отнемащите време изчисления към GPU.

Какво е CUDA

CUDA е технология за програмиране на алгоритми на опростен език C, която работи на графични процесори от осмо поколение и по-стари ускорители GeForce, както и на съответните карти Quadro и Tesla от NVIDIA. CUDA ви позволява да включите специални функции в текста на C програма. Тези функции са написани на опростения език за програмиране C и се изпълняват на GPU. Първоначалната версия на CUDA SDK беше пусната на 15 февруари 2007 г. За успешен превод на код на този език, CUDA SDK включва свой собствен C компилатор командна линия nvcc от NVIDIA. Компилаторът nvcc е базиран на отворен компилатор Open64 и е проектиран да превежда кода на хоста (основен, контролен код) и кода на устройството (хардуерен код) (файлове с разширение .cu) в обектни файлове, подходящи за изграждане на крайната програма или библиотека във всяка програмна среда, напр. , в Microsoft Visual Studio.

Технологични възможности

  1. Стандартният език C за паралелно разработване на GPU приложения.
  2. Готови библиотеки за числен анализ за бързото преобразуване на Фурие и основния пакет от програми за линейна алгебра.
  3. Специален CUDA драйвер за изчисления с бърз трансфер на данни между GPU и CPU.
  4. Възможност за CUDA драйвер да взаимодейства с OpenGL и DirectX графични драйвери.
  5. Поддръжка на операционна зала Linux системи 32/64-битова, Windows XP 32/64-битова и MacOS.

Технологични ползи

  1. Интерфейсът за програмиране на приложения CUDA (CUDA API) се основава на стандартния език за програмиране C с някои ограничения. Това опростява и изглажда процеса на изучаване на CUDA архитектурата.
  2. Споделената памет от 16 KB между нишките може да се използва за организиран от потребителя кеш с по-широка честотна лента, отколкото при извличане от обикновени текстури.
  3. По-ефективни транзакции между паметта на процесора и видео паметта.
  4. Пълна хардуерна поддръжка за целочислени и побитови операции.

Пример за приложение на технологията

cRark

Най-трудната част от тази програма е тинктурата. Програмата има конзолен интерфейс, но благодарение на инструкциите, които идват със самата програма, тя може да се използва. Следното е кратка инструкцияза настройка на програмата. Ще тестваме програмата за производителност и ще я сравним с друга подобна програма, която не използва NVIDIA CUDA, в този случай добре познатата програма „Advanced Archive Password Recovery“.

От изтегления cRark архив ни трябват само три файла: crark.exe, crark-hp.exe и password.def. Сrark.exe е програма за кракване на пароли RAR 3.0 без криптирани файлове вътре в архива (т.е. отваряйки архива виждаме имената, но не можем да разопаковаме архива без парола).

Сrark-hp.exe е помощна програма за кракване на пароли RAR 3.0 от командния ред, която криптира целия архив (т.е. когато отваряме архив, не виждаме нито името, нито самите архиви и не можем да разопаковаме архива без парола).

Password.def е всеки преименуван текстов файл с много малко съдържание (например: 1-ви ред: ## 2-ри ред: ?*, в който случай паролата ще бъде разбита с всички знаци). Password.def е главата на програмата cRark. Файлът съдържа правилата за отваряне на паролата (или символната област, която crark.exe ще използва в своята работа). Повече подробности за възможностите за избор на тези символи са написани в текстовия файл, получен при отваряне на изтегления от сайта от автора на програмата cRark: russian.def.

обучение

Веднага трябва да кажа, че програмата работи само ако вашата видеокарта е базирана на GPU с поддръжка на нивото на ускорение CUDA 1.1. Така че серия от видеокарти, базирани на чипа G80, като GeForce 8800 GTX, е изключена, тъй като те имат хардуерна поддръжка за CUDA 1.0 ускорение. Използвайки CUDA, програмата избира само пароли за RAR архиви от версии 3.0+. Целият софтуер, свързан с CUDA, трябва да бъде инсталиран, а именно:

  • NVIDIA драйвери, поддържащи CUDA от 169.21
  • NVIDIA CUDA SDK, започвайки от версия 1.1
  • NVIDIA CUDA Toolkit, започвайки от версия 1.1

Създаваме всяка папка навсякъде (например на устройството C:) и я наричаме произволно име, например "3.2". Поставяме файловете там: crark.exe, crark-hp.exe и password.def и защитен с парола/криптиран RAR архив.

След това трябва да стартирате конзолата на командния ред на Windows и да отидете в създадената папка в нея. В Windows Vista и 7 трябва да извикате менюто "Старт" и да въведете "cmd.exe" в полето за търсене; в Windows XP от менюто "Старт" първо трябва да извикате диалоговия прозорец "Изпълнение" и да въведете "cmd .exe" в него. След като отворите конзолата, въведете команда като: cd C:\folder\ , cd C:\3.2 в този случай.

Набиране на персонал в текстов редактордва реда (можете също да запишете текста като .bat файл в папката с cRark), за да познаете паролата на защитен с парола RAR архив с некриптирани файлове:

ехо изключено;
cmd /K crark (име на архив).rar

за да познаете паролата на защитен с парола и криптиран RAR архив:

ехо изключено;
cmd /K crark-hp (име на архив).rar

Копирайте 2 реда текстов файлв конзолата и натиснете Enter (или стартирайте .bat файла).

резултати

Процесът на дешифриране е показан на фигурата:

Скоростта на избор на cRark с помощта на CUDA беше 1625 пароли / секунда. За една минута, тридесет и шест секунди беше позната парола с 3 знака: "q)$". За сравнение: скоростта на груба сила в Advanced Archive Password Recovery на моя двуядрен процесор Athlon 3000+ е максимум 50 пароли/секунда, а грубата сила ще отнеме 5 часа. Тоест избирането на RAR архив чрез bruteforce в cRark с помощта на видеокарта GeForce 9800 GTX+ е 30 пъти по-бързо, отколкото на CPU.

За тези, които имат процесор Intel, добра дънна платка с висока честота на системната шина (FSB 1600 MHz), скоростта на процесора и грубата сила ще бъдат по-високи. И ако имате четириядрен процесор и чифт видеокарти от ниво GeForce 280 GTX, тогава производителността на грубата сила на паролата се ускорява понякога. Обобщавайки примера, трябва да се каже, че този проблем беше решен с помощта на технологията CUDA само за 2 минути вместо за 5 часа, което показва висок потенциал за тази технология!

заключения

След като разгледахме днес технологията за паралелни изчисления CUDA, ние ясно видяхме цялата сила и огромен потенциал за развитието на тази технология, използвайки примера на програма за възстановяване на пароли за RAR архиви. Трябва да кажа за перспективите на тази технология, тази технологиясъс сигурност ще намери място в живота на всеки човек, който реши да го използва, независимо дали става дума за научни задачи, или задачи, свързани с обработка на видео, или дори икономически задачи, които изискват бързо точно изчисление, всичко това ще доведе до неизбежно увеличаване на труда производителност, която не може да бъде пренебрегната. Към днешна дата фразата "домашен суперкомпютър" вече започва да навлиза в лексикона; абсолютно очевидно е, че за да се превърне такъв обект в реалност, всеки дом вече разполага с инструмент, наречен CUDA. След пускането на карти, базирани на чипа G80 (2006 г.), голяма сумаБазирани на NVIDIA ускорители, които поддържат технологията CUDA, която може да превърне мечтата за суперкомпютри във всеки дом в реалност. Популяризирайки технологията CUDA, NVIDIA повишава доверието в очите на клиентите под формата на предоставяне на допълнителни функции към оборудването им, което много вече са закупили. Остава само да вярваме, че скоро CUDA ще се развие много бързо и ще позволи на потребителите да се възползват напълно от всички възможности за паралелно изчисление на GPU.