Таблица соответствия gpu и cpu: Таблица совместимости процессор/видеокарты

Заметки на полях. Что быстрее, CPU или GPU? / Видеокарты

3DNews Видеокарты Общая информация Заметки на полях. Что быстрее, CPU или G… Самое интересное в новостях Центральные процессоры и видеочипы долгое время занимались решением принципиально разных задач. Но, так или иначе, их «область интересов» стала пересекаться. Существует ли способ сравнить их производительность? И если да, то кто из них быстрее? Время идет, процессоры становятся все мощнее и многоядернее. Видеокарты также наращивают количество вычислительных блоков и помимо создания 3D-изображения пытаются решать те задачи, которыми до сих пор занимались центральные процессоры. При этом разработчики видеокарт обещают значительное повышение производительности, что, в общем-то, подкрепляется цифрами. Но остается вопрос — на самом ли деле архитектура видеокарт лучше подходит для решения хорошо распараллеливаемых задач и потоковой обработки больших массивов данных? Если так, то зачем нам тогда многоядерные процессоры, может действительно стоит «переложить» нагрузку на видеокарты? Сегодня мы попытаемся ответить на вопрос — «кто кого поборет, кит или слон?», применительно к соревнованию CPU и GPU в части физических расчетов. Данный материал не претендует на полноту и всеохватность, более того — рассматриваемые здесь вопросы являются далеко не единственным примером «соревнования» CPU и GPU в области вычислений. Собственно, эти заметки и появились лишь в результате дискуссии с коллегами по поводу «кто сильнее, CPU или GPU». Не откладывая в долгий ящик, решено было проверить, а действительно — кто? Вы не поверите, но итог соревнования оказался не столь очевиден, и результаты удивили обе стороны. А почему так получилось, сейчас и увидим. В качестве тестового приложения мы решили взять 3DMark Vantage, а конкретно, один из входящих в пакет тестов — CPU Physics. Выбор, в общем-то, ничем особым не обусловлен, можно сказать — «что под руку попалось». Просто в 3DMark Vantage обычно мы тестируем видеокарты, а в него входит тест расчета «физики», который может выполнятся как на CPU, так и на видеоадаптерах NVIDIA. Вот давайте и посмотрим, кто считает «физику» быстрее. Тестовое оборудование Для сравнения мы взяли три процессора. Один из них уже довольно стар — Intel Core 2 Quad QX6850. Второй процессор более современный — AMD Phenom II X4 965. Третий еще современнее — AMD Athlon II X4 620. Конечно, надо было бы взять еще Core i7 или Core i5, но в это время они были заняты в других тестах. Впрочем, и трех имеющихся представителей «процессорного «лагеря будет вполне достаточно для получения качественных и количественных оценок. Тестовый стенд 1 Центральный процессор Intel Core 2 Quad QX6850 @ 3600 МГц (400×9) Материнская плата ASUS P5QC (Intel P45 + ICh20R) Оперативная память DDR3 Kingston 2x1GB @ 1600 MHz, 7-7-7-20-2T OS Windows 7 RTM Тестовый стенд 2 Центральный процессор AMD Phenom II X4 965 @ 3600 МГц (200×18) AMD Athlon II X4 620 @ 2600 МГц (200×13) Материнская плата ASUS M4A79 Deluxe (AMD 790FX + SB750) Оперативная память DDR2 Corsair 2x1GB @ 1066 MHz, 5-5-5-15-2T OS Windows 7 RTM Что касается видеокарт, то мы использовали три следующие модели NVIDIA: GeForce 9500GT (32 унифицированных процессора) GeForce 9600GT (64 унифицированных процессора) GeForce GTX260 (216 унифицированных процессоров) Мы не указываем частоты видеокарт, поскольку в процессе тестирования они постоянно менялись. Тестирование В качестве «удельной мощности» CPU или GPU мы будем рассматривать величину производительности в тесте 3DMark Vantage CPU Physics Test (которая измеряется в количестве кадров в секунду), поделенную на количество ядер или шейдерных блоков, а также частоту в мегагерцах. То есть, будем измерять «удельную мощность» в FPS/(МГц*количество вычислительных потоков). Собственно, для получения этой величины осталось измерить количество FPS в тесте при разных частотах процессоров и видеокарт, так как количество ядер CPU фиксировано, как и количество потоковых процессоров у видеокарт. Итак, приступим. Поскольку CPU до сих пор является «сердцем» компьютера, начнем именно с него. Мы решили немножко усложнить себе задачу и заодно выяснить, как масштабируется производительность CPU в данном тесте не только от частоты, но и от количества ядер. Ядра «отключались» путем задания соответствия на требуемое число ядер CPU для 3DMark Vantage в «Диспетчере задач». Данный метод неидеален, но для наших задач его вполне хватит. Кстати, несмотря на то, что процессор Intel Core 2 Quad QX6850 по сути состоит из двух ядер на одной подложке, какого либо влияния в данном тесте это не оказало. То есть, вариант, когда два ядра используют общий кэш объемом 4 Мб и случай, когда каждое из ядер использует кэш по 4 Мб, показали результаты, совпадающие в пределах погрешности. Ну а масштабирование по частоте осуществлялось путем изменения коэффициента умножения процессора в сторону понижения, прочие параметры системы оставались неизменными. Смотрим, что получилось. Как видите, с увеличением частоты производительность в тесте растет практически линейно. Теоретически, прямые линии должны начинаться от начала координат, поскольку при нулевой частоте CPU мы просто не получим никаких результатов, то есть нулевой FPS. Давайте проведем прямые линии от начала координат и проверим, насколько они совпадут с экспериментальными кривыми. Получаются весьма занятные результаты. Результаты Intel Core 2 Quad QX6850 практически идеально ложатся на прямые линии (за исключением случая для трех активных ядер, что может быть обусловлено как раз несимметричностью распределения кэш-памяти между ними в силу архитектуры). Результаты процессора AMD Athlon II X4 620 также хорошо ложатся на линию, проходящую через начало координат. А вот для AMD Phenom II X4 965 все несколько сложнее. Если проводить прямую от начала координат через точку, соответствующую минимальной частоте, то следующие точки отклоняются от этой прямой вниз (случай для одного и двух активных ядер). Если же проводить прямую через точки, соответствующие более высокой частоте CPU, то получается, что результаты на частоте 2000 МГц лежат сверху над прямой. Вероятно, такое поведение результатов можно объяснить наличием у AMD Phenom кэш-памяти третьего уровня. При частоте CPU равной 2000 МГц ядра и кэш-память L3 работают синхронно, поэтому результат максимален. При увеличении частоты ядер частота L3-кэш процессора остается неизменной, и он может вносить какие-то задержки, поэтому результаты «переходят» на прямую, коэффициент наклона которой ниже. Теперь давайте вычислим «удельную мощность» рассматриваемых процессоров в этом тесте. Напомним, что это по сути есть коэффициент наклона касательной, дополнительно разделенный на количество задействованных ядер CPU. Результаты приведены в таблице ниже. «Удельная мощность» CPU, FPS/(МГц*кол-во ядер) Кол-во ядер Core 2 Quad QX6850 Phenom II X4 965 Athlon II X4 620 1 0.001363 0.001467   2 0. 001252 0.001381   3 0.001249 0.001331   4 0.00124 0.001346 0.001348 Удивительно, но в при расчетах «физики» в 3DMark Vantage рассматриваемые процессоры AMD показывают чуть лучшие результаты, чем представитель архитектуры Intel Core 2 Quad. Теперь давайте посмотрим, какую «удельную мощность» продемонстрируют GPU производства NVIDIA. Поскольку видеопроцессор является довольно сложным устройством, возник вопрос — а как вообще эту «удельную мощность» считать? Поскольку вычислениями в основном занимаются шейдерные блоки, было решено строить графики результатов на основе именно этого параметра. Что касается частоты блоков ROP, то она выбиралась максимально возможной при данной частоте шейдеров. Как оказалось, минимальный коэффициент частоты шейдерных блоков по отношению к частоте ROP-блоков равен двум. Именно такое соотношение частот и сохранялось на протяжении всех тестов. Для этой части тестов использовался тестовый стенд на основе Core 2 Quad QX6850, рабочая частота процессора — 3600 МГц, все четыре ядра активны. Результаты показаны на графике ниже. Как видите, в данном тесте по абсолютным показателям видеокарты значительно опережают центральные процессоры в производительности. Причем даже самая слабая из присутствующих модель на минимальных частотах оказывается быстрее четырехъядерного CPU с частотой 3600 МГц. Однако поведение линий результатов несколько отличается от того, что мы видели для центральных процессоров. Более подробно это видно на графике ниже. На этом графике через точки, соответствующие минимальным рабочим частотам видеокарт, мы провели прямые линии. Как оказалось, они сходятся не в начале координат, а пересекают ось ординат на уровне примерно 20 FPS. Странно, не правда ли? Как оказалось, ничего странного нет, а поведение линий вполне закономерно. Для этого достаточно было посмотреть на загрузку CPU во время выполнения теста — она достигала 100% для каждого из ядер. Если вернуться к данным графика №1, то легко заметить, что результат теста на процессоре Intel Core 2 Quad QX6850 @ 3600 МГц как раз и составляет 18 FPS. Мы пробовали снижать частоту процессора и уменьшать количество активных ядер, и каждый раз уровень вертикального смещения линий результатов для GPU с хорошей точностью совпадал с производительностью центрального процессора в данном тесте. Что касается отклонения линий результатов от построенных прямых, то это объясняется проще — начиная с определенного момента часть шейдерных блоков, по всей видимости, загружены не полностью. Возможно, сказываются ограниченные возможности по распараллеливанию нагрузки самого теста, а может играют роль какие-то ограничения в архитектуре видеопроцессора. Как бы там ни было, давайте вычислим «удельную мощность» GPU, используя, как и прежде, коэффициент наклона построенных прямых, поделенный на количество потоковых процессоров. Полученные результаты отображены в таблице ниже. Также в ней указана «удельная мощность» Intel Core 2 Quad QX6850. «Удельная мощность» Коэффициент «отставания» GPU от CPU Intel Core 2 Quad QX6850 0.00124   9500GT (32 shaders) 0.00084 1.48 9600GT (64 shaders) 0.00063 1.97 GTX260 (216 shaders) 0.00050 2. 46 В это трудно поверить, но в тесте 3DMark Vantage CPU Physics Test «удельная мощность» довольно старого, по нынешним меркам, центрального процессора оказывается как минимум в полтора раза больше «удельной мощности» современных видеопроцессоров NVIDIA. Такой вот парадоксальный результат. Впрочем, мы вовсе не предлагаем отказаться от расчетов на GPU в пользу центральных процессоров. У GPU есть еще один козырь — большая производительность на ватт потребляемой мощности. Эти прикидки сделать несложно, поэтому оставим эту возможность читателям. Ну а если сравнить абсолютные результаты CPU и GPU, полученные в рамках данного тестирования, то современные процессоры еще не скоро до них дорастут. Впрочем, и отрицать успехи процессоростроения не стоит. Не так давно были опубликованы результаты тестирования разогнанного шестиядерного процессора Intel Core i9 Gulftown. Разогнанный до частоты 5892 МГц, этот процессор в тесте 3DMark Vantage CPU Physics Test показал результат 63,01 FPS. Если подсчитать «удельную мощность» новинки, то получаем величину 0.00178 FPS/(МГц*кол-во ядер), что в 1.44 раза больше «удельной мощности» процессора Core 2 Quad QX6850. То есть 44% прибавки достигаются за счет преимуществ архитектуры Core i9 и технологии HyperThreading. И хотя прямого противостояния CPU и GPU по всему фронту решаемых задач пока не наблюдается, кто знает, где именно между ними развернется жестокая конкуренция. Стоит упомянуть AMD Radeon HD 5870, обладающий вычислительной мощностью 2,7 TFLOPS, а также Microsoft DirectX 11 с поддержкой технологии Compute Shader, позволяющей переложить расчеты на GPU. То ли еще будет… — Обсудить материал в конференции     Если Вы заметили ошибку — выделите ее мышью и нажмите CTRL+ENTER. Материалы по теме Постоянный URL: https://3dnews.ru/580351 Теги: cpu или gpu? ⇣ Комментарии

Оптимальные процессор и видеокарта.

2021 год

Если перед вами стоит выбор подходящего под текущие потребности видеоадаптера, тогда таблица соответствия процессоров и видеокарт позволит немного его облегчить. С ее помощью можно определить, какой видеоадаптер лучше всего подойдет в качестве компаньона тому или другому процессору, что касается как бюджетных систем, так и компьютеров, собранных на базе топовых комплектующих. С другой стороны, вы также с ее помощью можете определить, какой процессор вам лучше всего приобрести при апгрейде системы с уже установленной видеокартой и стоит ли что-либо менять вообще.

Совместимость процессора и видеокарты

По большому счету все современные процессоры и видеокарты являются совместимыми между собой. Вопрос в другом: какова связка «процессор + видеокарта» будет наиболее производительной в играх. С целью ответить на него и была создана данная таблица.

*полужирным отмечены наиболее оптимальные видеоадаптеры, остальные перечисленные можно считать подходящими для построения игровых систем.

Процессоры из первой категории (AMD Athlon, Intel Pentium и AMD FX-63×0 / 83×0) подойдут для воспроизведения нетребовательных новых игр или многих бестселлеров прошлых лет. Увы, поиграть в современные игры уже не получится, но побегать в популярные онлайн-проекты или вспомнить новинки минувших лет — без проблем. В пару к  таким «камням» можно рекомендовать видеокарты прошлых поколений: Radeon RX 560, GeForce  GTX 1050 и GTX 1050 Ti.

Следующими кандидатами на покупку являются уже четырехъядерные и четырехпотоковые AMD Ryzen 3 1200 / 1300X / G2200 / G3200, Ryzen 5 1400 / 1500X / 2400G / 3400G, а также Intel Core i3-8100 / i3-8300 / i3-9100. Для среднеценовых видеокарт уровня AMD Radeon RX 570 и NVIDIA GeForce GTX 1060 их производительности будет вполне достаточно. Но для современных игр все же лучше присмотреться к чему-то более производительному.

Например, шестиядерным AMD Ryzen 5 2600 / 2600X, Intel Core i5-8400 / i5-8500 / i5-8600 / i5-9400F / i5-9500 / i5-9600. К ним мы бы советовали прикупить видеоадаптеры класса GeForce GTX 1660 / GTX 1660 Ti. Ну а к более новым и продвинутым AMD Ryzen 5 3600 / 3600X подойдут высокопроизводительные Radeon RX 5700, GeForce RTX 2060 / RTX 2060 SUPER / GTX 1070 / GTX 1070 Ti / GTX 1080. Таких систем хватит на несколько лет. 

Ну и конечно же, для любителей ультранастроек в высоком разрешении есть набор флагманских процессоров уровня AMD Ryzen 9 3900X и Intel Core i7-9700K. Видеокарту мы советуем выбирать, исходя из разрешения используемого монитора, поэтому вариантов много на любой вкус и цвет.

Как определить лучшую связку процессора и видеокарты?

Intel Core i5-6600K и Radeon R9 290

AMD Athlon 860K и Radeon R7 370

Для того чтобы понять принцип выбора связки процессора и видеокарты достаточно взглянуть на приведенные выше скриншоты. Верхний снимок — это сбалансированная связка мощного процессора Intel Core i5-6600K и производительной видеокарты Radeon R9 290. Как видим, CPU не ограничивает потенциал видеоадаптера, таким образом вы получаете максимально обеспечиваемый последним показатель FPS. Во втором случае под завязку нагружен уже процессор, из-за чего имеют место некоторые фризы, то есть микроподтормаживания. Таким образом, процессор ограничивает возможности видеокарты, и вы получаете не совсем то, за что платили. То есть в связке с AMD Athlon 860K более оптимальным будет решение уровня Radeon R7 360 или GeForce GTX 750 / 750 Ti. В таблице они выделены полужирным.

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

Если данный материал был полезным для вас, можете поделиться им в одной из социальных сетей (кнопки размещены ниже) или оставить ссылку на своем сайте.

Таблица по состоянию на 2019 год:

Таблица по состоянию на 2017-18 год:

Таблица по состоянию на 2016 год:

Обновления:

08. 02.21 (Ryzen 5000, RTX 3000, RX 6000)
18.09.19 (Ryzen 3000, Core 9000, RTX SUPER, RX 5000)
16.03.19 (Core i5-9600K, RX 590, RTX 2060, GTX 1660 / 1660 Ti)
15.10.18 (Athlon 200GE, RTX 2070, RTX 2080)
22.05.18 (Celeron G4900, G4920, Pentium G5400, G5500, G5600, Ryzen 5 2400G, 3 2200G)
25.10.17 (Core i7-8700K, i7-8700, i5-8600K, i5-8400, i5-7640X, i3-8300, i3-8100, Ryzen Threadripper 1900X; RX Vega 64, RX Vega 56)
11.08.17 (Ryzen 3 1200, 1300X, Ryzen 5 1400, 1500X, Ryzen Threadripper 1920X, 1950X, Core i9-7900X, Core i7-7740X)
23.05.17 (GT 1030, RX 550, RX 560, RX 570, RX 580, GTX 1080 Ti)

Выбор количества узлов, процессорных ядер и графических процессоров

ОБЗОР

• Введение
• Время решения
• Серийные коды
• Многопоточные коды
• Многоузловые или параллельные коды MPI
• Гибридный многопоточный многоузловой код
• Коды GPU
• Получение помощи

Прежде чем приступить к выполнению производственных циклов с параллельным кодом на кластерах высокопроизводительных вычислений, вам сначала необходимо найти оптимальное количество узлов, задач, ядер ЦП на задачу и, в некоторых случаях, количество графических процессоров. На этой странице показано, как провести скейлинговый анализ для нахождения оптимальных значений этих параметров для разных типов параллельных кодов.

Когда задание отправляется планировщику Slurm, оно сначала ожидает в очереди, прежде чем будет выполнено на вычислительных узлах. Время, проведенное в очереди, называется временем ожидания. Время, необходимое для выполнения задания на вычислительных узлах, называется временем выполнения.

На рисунке ниже показано, что время ожидания увеличивается с увеличением ресурсов (например, ядер ЦП), а время выполнения уменьшается с увеличением ресурсов. Нужно попытаться найти оптимальный набор ресурсов, который минимизирует «время решения», которое представляет собой сумму времени ожидания и выполнения. Простое правило – выбирать наименьший набор ресурсов, обеспечивающий разумное ускорение по сравнению с базовым случаем.

Обратите внимание, что информация на этой странице относится только к параллельным кодам. Если ваш код не распараллелен, использование большего количества ресурсов не улучшит его производительность. Вместо этого это приведет к пустой трате ресурсов и снизит приоритет вашей следующей работы.

Не следует пытаться явно вычислить время решения. Это связано с тем, что время ожидания для данной работы сильно различается в зависимости от вашего учебного отдела, вашей справедливой доли, качества обслуживания работы, времени года и т. д. Вместо того, чтобы пытаться оценить время ожидания, просто имейте в виду, что, как правило, чем больше ресурсов вы запрашиваете, тем больше времени ваше задание будет находиться в очереди перед выполнением. Время выполнения легко измерить, и оно указывается как «Время работы настенных часов» в отчете по электронной почте Slurm о завершенной работе.

Обратите внимание, что при выполнении анализа масштабирования вам не нужно часами запускать свой код, чтобы получить значимые данные. Однако вам нужно запускать его достаточно долго, чтобы можно было игнорировать однократные операции запуска. При необходимости добавьте операторы синхронизации в свой код, чтобы измерялись только соответствующие разделы. Обратите внимание, что вы должны работать не менее десятков секунд, чтобы можно было пренебречь неизбежными системными операциями.

Ниже мы покажем, как выполнить масштабный анализ для различных типов параллельных кодов. Масштабный анализ позволяет оценить оптимальные значения директив Slurm. Как только что было объяснено, время ожидания в очереди не учитывается при выполнении анализа масштабирования.

Для серийного кода есть только один выбор для директив Slurm:

#ДОПОЛНИТЕЛЬНО --nodes=1
#ДОПОЛНИТЕЛЬНО --ntasks=1
#SBATCH --cpus-per-task=1 

Использование более одного ядра ЦП для последовательного кода не уменьшит время выполнения, но приведет к пустой трате ресурсов и оставит вас с более низким приоритетом для вашего следующего задания. См. пример сценария Slurm для последовательного задания.

Некоторые программы, такие как процедуры линейной алгебры в NumPy и MATLAB, могут использовать несколько ядер ЦП через библиотеки, которые были написаны с использованием моделей параллельного программирования с общей памятью, таких как OpenMP, Intel Threading Building Blocks (TBB) или pthreads. Для чистых многопоточных кодов можно использовать только один узел и одну задачу (т. е. узлы = 1 и ntasks = 1), и ищется оптимальное значение процессора на задачу:

#ДОПОЛНИТЕЛЬНО --nodes=1
#ДОПОЛНИТЕЛЬНО --ntasks=1
#SBATCH --cpus-per-task= 

См. пример сценария Slurm для многопоточного задания. Чтобы найти оптимальное значение, необходимо провести масштабный анализ, при котором количество процессоров на задачу варьируется, и время выполнения кода записывается для каждого выбора:

В приведенной выше таблице время выполнения – это время, которое потребовалось для выполнения задания (например, настенные часы), а коэффициент ускорения .  – это время последовательного выполнения (процессор-на-задачу=1), деленное по времени выполнения. Параллельная эффективность измеряется относительно последовательного случая. То есть для cpus-per-task=2 имеем 42,0 / (22,0 × 2) = 0,95. Параллельная эффективность примерно равна «CPU Efficiency» в почтовых отчетах Slurm.

Данные в таблице выше показывают два ключевых момента:

• Время выполнения уменьшается с увеличением числа ядер ЦП до тех пор, пока не будет достигнуто число процессоров на задачу=32, когда код действительно работает медленнее, чем при использовании 16 ядер. Это показывает, что цель состоит не в том, чтобы использовать как можно больше ядер ЦП, а в том, чтобы найти оптимальное значение.
• Оптимальное значение числа процессоров на задачу равно 2, 4 или 8. Параллельная эффективность слишком мала, чтобы учитывать 16 или 32 ядра ЦП.

В этом случае ваш сценарий Slurm может использовать следующие директивы:

#ДОПОЛНИТЕЛЬНО --nodes=1
#ДОПОЛНИТЕЛЬНО --ntasks=1
#SBATCH --cpus-per-task=2
 

Например, для многоузлового кода, использующего MPI, вам потребуется изменить количество узлов и ntasks-per-node. Используйте более 1 узла только в том случае, если параллельная эффективность очень высока при использовании одного узла. Чтобы свести к минимуму время завершения, выберите наименьший набор директив Slurm, обеспечивающий разумное ускорение. Для чистого кода MPI, который не использует многопоточность (например, OpenMP), cpus-per-task=1 и цель состоит в том, чтобы найти оптимальные значения узлов и ntasks-per-node:

#SBATCH --nodes=
#SBATCH --ntasks-per-node=
#SBATCH --cpus-per-task=1
 

См. полный пример сценария Slurm для задания MPI. Ниже приведен пример анализа масштабирования для параллельного кода MPI:

Мы видим, что код работает очень хорошо, пока не используются четыре узла или 128 процессорных ядер. Хорошим выбором, вероятно, будет использование двух узлов, где параллельная эффективность все еще составляет 90%. См. пример сценария Slurm для чистого кода MPI.

Некоторые коды используют параллелизм как с общей, так и с распределенной памятью (например, OpenMP и MPI). В этих случаях вам нужно будет варьировать количество узлов, ntasks-per-node и cpus-per-task. Создайте таблицу, как описано выше, но включите новый столбец для процессора на задачу. Обратите внимание, что при использовании полных узлов произведение ntasks-per-node и cpus-per-task должно равняться общему количеству процессорных ядер на узел. Используйте команду «snodes», чтобы найти общее количество ядер ЦП на узел для данного кластера.

Найдите оптимальные значения для этих директив Slurm:

#SBATCH --nodes=
#SBATCH --ntasks-per-node=
#SBATCH --cpus-per-task= 

См. пример сценария Slurm для многопоточного многоузлового задания.

Прежде чем рассматривать несколько графических процессоров, нужно сначала продемонстрировать высокую загрузку графического процессора при использовании одного графического процессора. Посетите страницу GPU Computing, чтобы узнать об измерении и улучшении использования. Если загрузка графического процессора достаточно высока для случая с одним графическим процессором, вам следует изучить возможность использования нескольких графических процессоров, выполнив анализ масштабирования, как показано в таблице ниже:

Приведенный выше анализ масштабирования показывает, что код плохо работает при использовании нескольких графических процессоров. То есть линейного масштабирования не наблюдается. Например, производительность с двумя GPU не в два раза выше, чем с одним. Принимая во внимание, что время ожидания увеличивается с увеличением ресурсов, может не иметь смысла использовать два GPU для этого конкретного кода.

Обратите внимание, что мы не упомянули количество ядер ЦП, используемых в приведенном выше анализе. Это связано с гораздо большей вычислительной мощностью графического процессора по сравнению с многоядерным процессором. Однако для производительности кода с поддержкой графического процессора часто критически важно, чтобы одно или несколько ядер ЦП были полностью задействованы.  Например, для кодов глубокого обучения TensorFlow и PyTorch оптимальная производительность может быть достигнута только тогда, когда несколько ядер ЦП используются для загрузки графического процессора путем подачи на него данных.

Многие научные коды используют OpenMP, MPI и графические процессоры. В этом случае ищутся оптимальные значения для узлов, ntasks-per-node, cpus-per-task и gres.

См. пример скрипта Slurm для простого задания GPU.

Получение помощи

Если у вас возникнут трудности при проведении анализа масштабирования кластеров HPC, отправьте электронное письмо по адресу [email protected] или посетите сеанс помощи.

Обзор архитектуры графического процессора

| Лучшее завтра с информатикой

27 апреля 2017 г.

Модель графического процессора

{: .center-image width:600px}

Это объясняет несколько важных конструкций, принятых в последних графических процессорах.

1. MMIO .

   • Процессор обменивается данными с графическим процессором через MMIO.
   • Поддерживаются аппаратные механизмы для DMA для передачи больших объемов данных, однако команды следует писать через MMIO.
   • Порты ввода-вывода могут использоваться для косвенного доступа к областям MMIO, но используются редко. Драйвер устройства с открытым исходным кодом Nouveau в настоящее время никогда не использует его.

2. Контекст графического процессора .

   • Контекст представляет состояние вычислений GPU.
   • Владеет виртуальным адресным пространством в GPU.
   • На графическом процессоре может сосуществовать несколько активных контекстов.

3. Канал GPU .

   • Любая операция (например, запуск ядра) управляется командами, выдаваемыми ЦП.
   • Поток команд отправляется аппаратному блоку, называемому каналом GPU.
   • Каждый контекст графического процессора может иметь один или несколько каналов графического процессора. Каждый контекст графического процессора содержит дескрипторы канала графического процессора (каждый дескриптор создается как объект памяти в памяти графического процессора).
   • Каждый дескриптор канала GPU хранит настройки канала, которые включают таблицу страниц .
   • Каждый канал графического процессора имеет выделенный буфер команд, выделенный в памяти графического процессора, видимый для ЦП через MMIO.

4. Таблица страниц графического процессора .

   • Контекст GPU назначается с помощью таблицы страниц GPU, которая изолирует виртуальное адресное пространство от других.
   • Таблица страниц GPU отделена от таблицы страниц CPU.
   • Находится в памяти графического процессора, а его физический адрес указан в дескрипторе канала графического процессора.
   • Все команды и программы, отправленные через канал, выполняются в соответствующем виртуальном адресном пространстве графического процессора.
   • Таблицы страниц графического процессора преобразуют виртуальный адрес графического процессора не только в физический адрес устройства графического процессора, но и в физический адрес хоста. Это позволяет таблице страниц графического процессора до объединяет память графического процессора и основную память хоста в единое виртуальное адресное пространство графического процессора .

5. ШИНА PCIe .

   • Регистры базовых адресов (BAR) PCIe, которые работают как окна MMIO, настраиваются во время загрузки графического процессора.
   • управляющих регистров графического процессора и апертуры памяти графического процессора отображаются на BAR.
   • Эти сопоставленные окна MMIO используются драйвером устройства для настройки графического процессора и доступа к памяти графического процессора.

6. Двигатель PFIFO .

   • PFIFO — это специальный механизм, через который передаются команды графического процессора.
   • Поддерживать несколько независимых очередей команд, называемых каналами.
   • Очередь команд представляет собой кольцевой буфер с указателями put и get.
   • Все обращения к области управления каналом перехватываются механизмом PFIFO для выполнения.

   Драйвер графического процессора

   • использует дескриптор канала для хранения настроек связанного канала.
   • Nouveau говорит, что механизм PFIFO графического процессора считывает команды из раздела памяти и передает их механизму PGRAPH. (Может это для графики?)

7. Бо

   • Nouveau и gdev очень часто используют и .
   • Буферный объект (bo). Блок памяти. Он может хранить текстуру, цель рендеринга, код шейдера и т. д.

Ссылки

1. Yusuke Suzuki et al. GPUvm: виртуализация графического процессора в гипервизоре» . Транзакции IEEE на компьютерах. 2016
2. Hong-Cyuan Hsu et al. G-KVM: полная виртуализация графического процессора на KVM ». Международная конференция IEEE по компьютерным и информационным технологиям. 2016 г.
3. Новые термины. [В сети] (по состоянию на 27 апреля 2017 г. Версия документации от 24 августа 2013 г.)
4. Новая команда. Документация по оборудованию nVidia. [В сети] (По состоянию на 27 апреля 2017 г. Версия документации от 18 апреля 2017 г.)

#исследования

#cuda

Назад
Введение в VFIO

Далее
Перехват SGX ENCLS Leaf Function Call от KVM

Включите JavaScript для просмотра комментариев на основе Disqus.