Рабочая нагрузка гп видеокарта или вычислить amd что лучше
Но для начала немного предыстории от куда вообще появилось это разделение работы видеокарт на два режима работы.
В уже далеком 2017 году (по меркам майнинг индустрии) новейшие на тот момент видеокарты AMD Radeon RX470/RX480 и RX570/RX580 стали постепенно с каждой новой эпохой в майнинге Ethereum терять свою производительность, т.е. хешрейт падал с каждой новой эпохой и общее падение производительности видеокарт Polaris в майнинге Ethereum на тот момент оценивалось в 30%. Эпоха тогда, кстати, была под номером 130, сейчас же 352. То же самое с ростом DAG файла (эпохи) происходило и с видеокартами AMD предыдущих поколений HD 7000, R9 200, R9 300, причем это падение для этих видеокарт началось на год раньше. Этот печальный факт так бы и оставался не замеченным самой AMD если бы не бум криптовалют в 2017 году и Ethereum в частности, когда на рынок оборудования для майнеров обратили свое внимание не только производители видеокарт, но и вообще весь мир.
Что бы не проигрывать конкурентную борьбу за рынок майнинг оборудования своему сопернику Nvidia, которая как раз выпустила очень удачную в плане майнинга 1000 серию своих видеокарт, компания AMD взялась за решение проблемы падения хешрейта своих видеокарт с увеличением DAG файла криптовалюты Ethereum. И первым таким шагом стал выпуск специальных драйверов называемых Blockchain Compute, которые решали проблему падения производительности видеокарт AMD на эпохах выше 130, но только для видеокарт серий RX400 и RX500 и новее. Эти специализированные для майнинга драйвера имели статус Beta и дальнейшего развития не получили, т.к. разработанный функционал был внедрен в обычные «игровые» драйвера, но при этом пользователю необходимо самостоятельно выбирать в каком режиме будет работать его видеокарта: Вычислитель или Графика.
Кому интересен более подробный экскурс в историю, могут почитать следующие материалы:
Включение режима Вычислить или Compute Mode в драйверах AMD Software Radeon Adrenalin. Инструкция.
Данное руководство используйте только если у Вас видеокарты AMD и операционная система Windows. В специальных для майнинга операционных системах на базе Linux в таких действиях нет необходимости.
1. Запустить приложение Driver AMD Adrenalin
Если такого значка в меню Windows Вы не нашли, значит у Вас не установлено приложение AMD Adrenalin. Скачать актуальную версию драйверов для своей операционной системы можно на сайте AMD.com
2. В окне программы управления видеокартами Radeon перейдите в меню ИГРЫ
3. Далее ОБЩИЕ НАСТРОЙКИ
4. В настройках найдите пункт РАБОЧАЯ НАГРУЗКА ГП и выберите ВЫЧИСЛИТЬ вместо ГРАФИКА. Повторить для всех видеокарт AMD в системе (верхнее меню в этом же окне)
5. Перезагрузить компьютер
После изменения режима работы видеокарт AMD Radeon в Compute Mode, производительность (хешрейт) Ваших видеокарт увеличиться на 10-100% в зависимости от алгоритма майнинга. Наибольшее увеличение хешрейта до двух раз будет на алгоритмах Ethash, ProgPow, KawPow, которые в своих расчетах интенсивно используют видеопамять.
Вывод: Всегда, когда используете видеокарты AMD для майнинга криптовалют, переключайте в драйверах режим работы с Видеокарта на Вычислить, что бы максимально эффективно использовать свое оборудование. Для примера популярная видеокарта Radeon RX580 без включения режима Compute Mode выдает 14-16 MH/s при добыче Ethereum, а с включенным режимом Compute Mode 25-33 MH/s в зависимости от разгона GPU и памяти GDDR5.
Подпишись на наш Telegram канал @cryptoage и Вконтакте, узнавай новости про криптовалюты первым.
Общайся с криптоэнтузиастами и майнерами в Telegram чате @CryptoChat
Лучшие биржи для покупки и обмена криптовалют, токенов:
Биржа | Преимущества | Бонусы при регистрации |
Binance |
Примечание | Этот вариант доступен на поддерживаемых графических адаптерах, использующих AMD Radeon Crimson Live Edition 17.10.2 и более поздних версий. Информация о поддерживаемых графических процессорах представлена в примечаниях к версии драйвера. |
В следующих шагах объясняется, как получить доступ к параметрам рабочей нагрузки GPU.
* Корпорация Intel предложите вам материалы на сторонних веб-сайтах для вашего удобства и может предоставить ссылки на дополнительные сайты сторонних компаний. Предоставление такого контента и/или ссылок означает только предложения и не должно считаться одобрением или рекомендацией для выполнения каких-либо конкретных действий. Выполнение действий, рекомендованных сторонними поставщиками, может привести к неправильной работе, повреждению системной платы или процессора или сокращению срока службы продукции. Корпорация Intel не несет никакой ответственности в отношении использования вами сторонних компаний или материалов, а также отказывается от прямых или косвенных гарантий, связанных с сайтами или материалами сторонних компаний. Корпорация Intel не контролирует и не проверяет сторонние материалы или веб-сайты сторонних компаний, упоминаемые на веб-сайтах других компаний. Вы должны посетить веб-сайт, на котором есть ссылка, и подтвердить точность данных, указанных в ссылке.
Вычисления на GPU – зачем, когда и как. Плюс немного тестов
Всем давно известно, что на видеокартах можно не только в игрушки играть, но и выполнять вещи, никак не связанные с играми, например, нейронную сеть обучить, криптовалюту помайнить или же научные расчеты выполнить. Как так получилось, можно прочитать тут, а я хотел затронуть тему того, почему GPU может быть вообще интересен рядовому программисту (не связанному с GameDev), как подступиться к разработке на GPU, не тратя на это много времени, принять решение, нужно ли вообще в эту сторону смотреть, и «прикинуть на пальцах», какой профит можно получить.
Статья написана по мотивам моего выступления на HighLoad++. В ней рассматриваются в основном технологии, предлагаемые компанией NVIDIA. У меня нет цели рекламировать какие-либо продукты, я лишь привожу их в качестве примера, и наверняка что-то похожее можно найти у конкурирующих производителей.
Два процессора можно сравнить по разным критериям, наверное, самые популярные — это частота и количество ядер, размер кэшей и прочее, но в конечном счете, нас интересует, сколько операций процессор может выполнить за единицу времени, что это за операции вопрос отдельный, но наиболее распространенной метрикой является количество операций с плавающей запятой в секунду — flops. И когда мы хотим сравнить теплое с мягким, а в нашем случае GPU с CPU, эта метрика приходится как нельзя кстати.
Ниже на графике изображены рост этих самых флопсов с течением времени для процессоров и для видеокарт.
(Данные собраны из открытых источников, нет данных за 2019-20 годы, т.к. там не все так красиво, но GPU все-таки выигрывают)
Что ж, заманчиво, не правда ли? Перекладываем все вычисления с CPU на GPU и получаем в восемь раз лучшую производительность!
Но, конечно же, не все так просто. Нельзя просто так взять и переложить все на GPU, о том почему, мы поговорим дальше.
Привожу многим знакомую картинку с архитектурой CPU и основными элементами:
Что здесь особенного? Одно ядро и куча вспомогательных блоков.
А теперь давайте посмотрим на архитектуру GPU:
У видеокарты множество вычислительных ядер, обычно несколько тысяч, но они объединены в блоки, для видеокарт NVIDIA обычно по 32, и имеют общие элементы, в т.ч. и регистры. Архитектура ядра GPU и логических элементов существенно проще, чем на CPU, а именно, нет префетчеров, бранч-предикторов и много чего еще.
Что же, это ключевые моменты отличия в архитектуре CPU и GPU, и, собственно, они и накладывают ограничения или, наоборот, открывают возможности к тому, что мы можем эффективно считать на GPU.
Я не упомянул еще один важный момент, обычно, видеокарта и процессор не «шарят» память между собой и записать данные на видеокарту и считать результат обратно — это отдельные операции и могут оказаться «бутылочным горлышком» в вашей системе, график зависимости времени перекачки от размера данных приведен далее в статье.
Ограничения и возможности при работе с GPU
Какие ограничения накладывает такая архитектура на выполняемые алгоритмы:
Какие возможности открывает:
Трансформация
У нас есть два массива, A и B, и мы хотим к каждому элементу массива A добавить элемент из массива B. Ниже приведен пример на C, хотя, надеюсь, он будет понятен и тем, кто не владеет этим языком:
(не забываем, что пример нужно компилировать компилятором от NVIDIA)
Как видите, thrust::sort очень похож на аналогичный алгоритм из STL. Эта библиотека скрывает много сложностей, в особенности разработку подпрограммы (точнее ядра), которая будет выполняться на видеокарте, но при этом лишает гибкости. Например, если мы хотим отсортировать несколько гигабайт данных, логично было бы отправить кусок данных на карту запустить сортировку, и пока выполняется сортировка, дослать еще данные на карту. Такой подход называется latency hiding и позволяет более эффективно использовать ресурсы серверной карты, но, к сожалению, когда мы используем высокоуровневые библиотеки, такие возможности остаются скрытыми. Но для прототипирования и замера производительности как раз таки подходят, в особенности с thrust можно замерить, какой оверхед дает пересылка данных.
Я написал небольшой бенчмарк с использованием этой библиотеки, который выполняет несколько популярных алгоритмов с разным объемом данных на GPU, давайте посмотрим, какие результаты получились.
Для тестирования GPU я взял инстанс в AWS с видеокартой Tesla k80, это далеко не самая мощная серверная карта на сегодняшний день (самая мощная Tesla v100), но наиболее доступная и имеет на борту:
И для тестов на CPU я взял инстанс с процессором Intel Xeon CPU E5-2686 v4 @ 2.30GHz
Трансформация
Время выполнения трансформации на GPU и CPU в мс
Как видите, обычная трансформация элементов массива выполняется по времени примерно одинаково, как на GPU, так и на CPU. А все почему? Потому что оверхед на пересылку данных на карту и обратно съедает весь performance boost (про оверхед мы поговорим отдельно), да и вычислений на карте выполняется относительно немного. К тому же не стоит забывать, что процессоры также поддерживают SIMD инструкции, и компиляторы в простых случаях могут эффективно их задействовать.
Давайте теперь посмотрим, насколько эффективно выполняется агрегация на GPU.
Агрегация
Время выполнения агрегации на GPU и CPU в мс
В примере с агрегацией мы уже видим существенный прирост производительности с увеличением объема данных. Стоит также обратить внимание на то, что в память карты мы перекачиваем большой объем данных, а назад забираем только одно агрегированное значение, т.е. оверхед на пересылку данных из карты в RAM минимален.
Перейдем к самому интересному примеру — сортировке.
Сортировка
Время выполнения сортировки на GPU и CPU в мс
Несмотря на то, что мы пересылаем на видеокарту и обратно весь массив данных, сортировка на GPU 800 MB данных выполняется примерно в 25 раз быстрее, чем на процессоре.
Как видно из примера с трансформацией, не всегда очевидно, будет ли GPU эффективен даже в тех задачах, которые хорошо параллелятся. Причиной тому — оверхед на пересылку данных из оперативной памяти компьютера в память видеокарты (в игровых консолях, кстати, память расшарена между CPU и GPU, и нет необходимости пересылать данные). Одна из характеристик видеокарты это — memory bandwidth или пропускная способность памяти, которая определяет теоретическую пропускную способность карты. Для Tesla k80 это 480 GB/s, для Tesla v100 это уже 900 GB/s. Также на пропускную способность будет влиять версия PCI Express и имплементация того, как вы будете передавать данные на карту, например, это можно делать в несколько параллельных потоков.
Давайте посмотрим на практические результаты, которые удалось получить для видеокарты Tesla k80 в облаке Amazon:
Время пересылки данных на GPU, сортировки и пересылки данных обратно в RAM в мс
HtoD — передаем данные на видеокарту
GPU Execution — сортировка на видеокарте
DtoH — копирование данных из видеокарты в оперативную память
Первое, что можно отметить — считывать данные из видеокарты получается быстрее, чем записывать их туда.
Второе — при работе с видеокартой можно получить latency от 350 микросекунд, а этого уже может хватить для некоторых low latency приложений.
Ниже на графике приведен оверхед для большего объема данных:
Время пересылки данных на GPU, сортировки и пересылки данных обратно в RAM в мс
Наиболее частый вопрос — чем отличается игровая видеокарта от серверной? По характеристикам они очень похожи, а цены отличаются в разы.
Основные отличия серверной (NVIDIA) и игровой карты:
Это, пожалуй, основные важные отличия, которые я нашел.
Многопоточность
После того как мы разобрались, как запустить простейший алгоритм на видеокарте и каких результатов можно ожидать, следующий логичный вопрос, а как будет себя вести видеокарта при обработке нескольких параллельных запросов. В качестве ответа у меня есть два графика выполнения вычислений на GPU и процессоре с 4-мя и 32-мя ядрами:
Время выполнения математических расчетов на GPU и CPU c матрицами размером 1000 x 60 в мс
На этом графике выполняются расчеты с матрицами размером 1000 x 60 элементов. Запускаются вычисления из нескольких программных потоков, для GPU дополнительно создается отдельный stream для каждого CPU-потока (используется тот самый Hyper-Q).
Как видно, процессор справляется с такой нагрузкой очень хорошо, при этом latency для одного запроса на GPU существенно растет с увеличением числа параллельных запросов.
Время выполнения математических расчетов на GPU и CPU c матрицами 10 000 x 60 в мс
На втором графике те же самые вычисления, но с матрицами в 10 раз больше, и GPU под такой нагрузкой ведет себя существенно лучше. Эти графики очень показательны, и можно сделать вывод: поведение под нагрузкой зависит от характера самой нагрузки. Процессор может также довольно эффективно справляться с матричными вычислениями, но до определенных пределов. Для видеокарты характерно то, что для небольшой вычислительной нагрузки производительность падает примерно линейно. С увеличением нагрузки и количества параллельных потоков видеокарта справляется уже лучше.
Сложно строить гипотезы, как будет себя вести GPU в различных ситуациях, но, как видите, при определенных условиях серверная карта может достаточно эффективно обрабатывать запросы из нескольких параллельных потоков.
Обсудим еще несколько вопросов, которые могут возникнуть у вас, если вы все-таки решили использовать GPU в своих проектах.
Ограничение ресурсов
Как мы уже говорили, два основных ресурса видеокарты — это вычислительные ядра и память.
К примеру, у нас несколько процессов или контейнеров, использующих видеокарту, и хотелось бы иметь возможность поделить видеокарту между ними. К сожалению, простого API для этого нет. NVIDIA предлагает технологию vGPU, но карту Tesla k80 я не нашел в списке поддерживаемых, и насколько мне удалось понять из описания, технология больше заточена на виртуальные дисплеи, чем на вычисления. Возможно, AMD предлагает что-то более подходящее.
Поэтому, если планируете использовать GPU в своих проектах, стоит рассчитывать на то, что приложение будет использовать видеокарту монопольно, либо вы будете программно контролировать объем выделяемой памяти и количество ядер, используемых для вычислений.
Контейнеры и GPU
Если с ограничением ресурсов вы разобрались, то следующий логичный вопрос: а если в сервере несколько видеокарт?
Опять же, можно на уровне приложения решать, какой GPU оно будет использовать.
Другой более удобный способ — это Docker-контейнеры. Можно использовать и обычные контейнеры, но NVIDIA предлагает свои контейнеры NGC, с оптимизированными версиями различного софта, библиотек и драйверов. Для одного контейнера можно ограничить количество используемых GPU и их видимость для контейнера. Оверхед на использования контейнера около 3%.
Работа в кластере
Другой вопрос, что делать, если вы хотите выполнять одну задачу на нескольких GPU в рамках одного сервера или кластера?
Если вы выбрали библиотеку на подобии thrust или более низкоуровневое решение, то задачу придется решать вручную. Высокоуровневые фреймворки, например, для машинного обучения или нейронных сетей, обычно поддерживают возможность использования нескольких карт из коробки.
Дополнительно хотелось бы отметить то, что, например, NVIDIA предлагает интерфейс прямого обмена данными между картами — NV, который существенно быстрее чем PCI Express. И есть технология прямого доступа к памяти карты из других PCI Express устройств — GPUDirect RDMA, в т.ч. и сетевых.
Если вы размышляете об использовании GPU в своих проектах, то GPU, скорее всего, вам подойдет если:
Заранее также стоит задаться вопросами:
На этом все, надеюсь, материал будет вам полезен и поможет принять верное решение!
Бенчмарк и результаты на github — https://github.com/tishden/gpu_benchmark/tree/master/cuda
В дополнение к теме запись доклада «Базы данных на GPU — архитектура, производительность и перспективы использования»
- Переделка авто с дизеля на бензин
- Розовая рубашка с чем носить мужчинам