Просчет с gpu на cpu. Вычисления на GPU: мифы и реальность. Что же такое вычисление на GPU
Использование GPU для вычислений с помощью C++ AMP
До сих пор в обсуждении приемов параллельного программирования мы рассматривали только ядра процессора. Мы приобрели некоторые навыки распараллеливания программ по нескольким процессорам, синхронизации доступа к совместно используемым ресурсам и использования высокоскоростных примитивов синхронизации без применения блокировок.
Однако, существует еще один способ распараллеливания программ - графические процессоры (GPU) , обладающие большим числом ядер, чем даже высокопроизводительные процессоры. Ядра графических процессоров прекрасно подходят для реализации параллельных алгоритмов обработки данных, а большое их количество с лихвой окупает неудобства выполнения программ на них. В этой статье мы познакомимся с одним из способов выполнения программ на графическом процессоре, с использованием комплекта расширений языка C++ под названием C++ AMP .
Расширения C++ AMP основаны на языке C++ и именно поэтому в данной статье будут демонстрироваться примеры на языке C++. Однако, при умеренном использовании механизма взаимодействий в. NET, вы сможете использовать алгоритмы C++ AMP в своих программах для.NET. Но об этом мы поговорим в конце статьи.
Введение в C++ AMP
По сути, графический процессор является таким же процессором, как любые другие, но с особым набором инструкций, большим количеством ядер и своим протоколом доступа к памяти. Однако между современными графическими и обычными процессорами существуют большие отличия, и их понимание является залогом создания программ, эффективно использующих вычислительные мощности графического процессора.
Современные графические процессоры обладают очень маленьким набором инструкций. Это подразумевает некоторые ограничения: отсутствие возможности вызова функций, ограниченный набор поддерживаемых типов данных, отсутствие библиотечных функций и другие. Некоторые операции, такие как условные переходы, могут стоить значительно дороже, чем аналогичные операции, выполняемые на обычных процессорах. Очевидно, что перенос больших объемов кода с процессора на графический процессор при таких условиях требует значительных усилий.
Количество ядер в среднем графическом процессор значительно больше, чем в среднем обычном процессоре. Однако некоторые задачи оказываются слишком маленькими или не позволяют разбивать себя на достаточно большое количество частей, чтобы можно было извлечь выгоду от применения графического процессора.
Поддержка синхронизации между ядрами графического процессора, выполняющими одну задачу, весьма скудна, и полностью отсутствует между ядрами графического процессора, выполняющими разные задачи. Это обстоятельство требует синхронизации графического процессора с обычным процессором.
Сразу возникает вопрос, какие задачи подходят для решения на графическом процессоре? Имейте в виду, что не всякий алгоритм подходит для выполнения на графическом процессоре. Например, графические процессоры не имеют доступа к устройствам ввода/вывода, поэтому у вас не получится повысить производительность программы, извлекающей ленты RSS из интернета, за счет использования графического процессора. Однако на графический процессор можно перенести многие вычислительные алгоритмы и обеспечить массовое их распараллеливание. Ниже приводится несколько примеров таких алгоритмов (этот список далеко не полон):
увеличение и уменьшение резкости изображений, и другие преобразования;
быстрое преобразование Фурье;
транспонирование и умножение матриц;
сортировка чисел;
инверсия хеша «в лоб».
Отличным источником дополнительных примеров может служить блог Microsoft Native Concurrency , где приводятся фрагменты кода и пояснения к ним для различных алгоритмов, реализованных на C++ AMP.
C++ AMP - это фреймворк, входящий в состав Visual Studio 2012, дающий разработчикам на C++ простой способ выполнения вычислений на графическом процессоре и требующий лишь наличия драйвера DirectX 11. Корпорация Microsoft выпустила C++ AMP как открытую спецификацию , которую может реализовать любой производитель компиляторов.
Фреймворк C++ AMP позволяет выполнять код на графических ускорителях (accelerators) , являющихся вычислительными устройствами. С помощью драйвера DirectX 11 фреймворк C++ AMP динамически обнаруживает все ускорители. В состав C++ AMP входят также программный эмулятор ускорителя и эмулятор на базе обычного процессора, WARP, которые служит запасным вариантом в системах без графического процессора или с графическим процессором, но в отсутствие драйвера DirectX 11, и использует несколько ядер и инструкции SIMD.
А теперь приступим к исследованию алгоритма, который легко можно распараллелить для выполнения на графическом процессоре. Реализация ниже принимает два вектора одинаковой длины и вычисляет поточечный результат. Сложно представить что-либо более прямолинейное:
Void VectorAddExpPointwise(float* first, float* second, float* result, int length) { for (int i = 0; i < length; ++i) { result[i] = first[i] + exp(second[i]); } }
Чтобы распараллелить этот алгоритм на обычном процессоре, требуется разбить диапазон итераций на несколько поддиапазонов и запустить по одному потоку выполнения для каждого из них. Мы посвятили достаточно много времени в предыдущих статьях именно такому способу распараллеливания нашего первого примера поиска простых чисел - мы видели, как можно это сделать, создавая потоки вручную, передавая задания пулу потоков и используя Parallel.For и PLINQ для автоматического распараллеливания. Вспомните также, что при распараллеливании похожих алгоритмов на обычном процессоре мы особо заботились, чтобы не раздробить задачу на слишком мелкие задания.
Для графического процессора эти предупреждения не нужны. Графические процессоры имеют множество ядер, выполняющих потоки очень быстро, а стоимость переключения контекста значительно ниже, чем в обычных процессорах. Ниже приводится фрагмент, пытающийся использовать функцию parallel_for_each из фреймворка C++ AMP:
#include
Теперь исследуем каждую часть кода отдельно. Сразу заметим, что общая форма главного цикла сохранилась, но первоначально использовавшийся цикл for был заменен вызовом функции parallel_for_each. В действительности, принцип преобразования цикла в вызов функции или метода для нас не нов - ранее уже демонстрировался такой прием с применением методов Parallel.For() и Parallel.ForEach() из библиотеки TPL.
Далее, входные данные (параметры first, second и result) обертываются экземплярами array_view . Класс array_view служит для обертывания данных, передаваемых графическому процессору (ускорителю). Его шаблонный параметр определяет тип данных и их размерность. Чтобы выполнить на графическом процессоре инструкции, обращающиеся к данным, первоначально обрабатываемым на обычном процессоре, кто-то или что-то должен позаботиться о копировании данных в графический процессор, потому что большинство современных графических карт являются отдельными устройствами с собственной памятью. Эту задачу решают экземпляры array_view - они обеспечивают копирование данных по требованию и только когда они действительно необходимы.
Когда графический процессор выполнит задание, данные копируются обратно. Создавая экземпляры array_view с аргументом типа const, мы гарантируем, что first и second будут скопированы в память графического процессора, но не будут копироваться обратно. Аналогично, вызывая discard_data() , мы исключаем копирование result из памяти обычного процессора в память ускорителя, но эти данные будут копироваться в обратном направлении.
Функция parallel_for_each принимает объект extent, определяющий форму обрабатываемых данных и функцию для применения к каждому элементу в объекте extent. В примере выше мы использовали лямбда-функцию, поддержка которых появилась в стандарте ISO C++2011 (C++11). Ключевое слово restrict (amp) поручает компилятору проверить возможность выполнения тела функции на графическом процессоре и отключает большую часть синтаксиса C++, который не может быть скомпилирован в инструкции графического процессора.
Параметр лямбда-функции, index<1> объекта, представляет одномерный индекс. Он должен соответствовать используемому объекту extent - если бы мы объявили объект extent двумерным (например, определив форму исходных данных в виде двумерной матрицы), индекс также должен был бы быть двумерным. Пример такой ситуации приводится чуть ниже.
Наконец, вызов метода synchronize() в конце метода VectorAddExpPointwise гарантирует копирование результатов вычислений из array_view avResult, произведенных графическим процессором, обратно в массив result.
На этом мы заканчиваем наше первое знакомство с миром C++ AMP, и теперь мы готовы к более подробным исследованиям, а так же к более интересным примерам, демонстрирующим выгоды от использования параллельных вычислений на графическом процессоре. Сложение векторов - не самый удачный алгоритм и не самый лучший кандидат для демонстрации использования графического процессора из-за больших накладных расходов на копирование данных. В следующем подразделе будут показаны два более интересных примера.
Умножение матриц
Первый «настоящий» пример, который мы рассмотрим, - умножение матриц. Для реализации мы возьмем простой кубический алгоритм умножения матриц, а не алгоритм Штрассена, имеющий время выполнения, близкое к кубическому ~O(n 2.807). Для двух матриц: матрицы A размером m x w и матрицы B размером w x n, следующая программа выполнит их умножение и вернет результат - матрицу C размером m x n:
Void MatrixMultiply(int* A, int m, int w, int* B, int n, int* C) { for (int i = 0; i < m; ++i) { for (int j = 0; j < n; ++j) { int sum = 0; for (int k = 0; k < w; ++k) { sum += A * B; } C = sum; } } }
Распараллелить эту реализацию можно несколькими способами, и при желании распараллелить этот код для выполнения на обычном процессоре правильным выбором был бы прием распараллеливания внешнего цикла. Однако графический процессор имеет достаточно большое количество ядер и распараллелив только внешний цикл, мы не сможем создать достаточное количество заданий, чтобы загрузить работой все ядра. Поэтому имеет смысл распараллелить два внешних цикла, оставив внутренний цикл нетронутым:
Void MatrixMultiply (int* A, int m, int w, int* B, int n, int* C)
{
array_view
Эта реализация все еще близко напоминает последовательную реализацию умножения матриц и пример сложения векторов, приводившиеся выше, за исключением индекса, который теперь является двумерным и доступен во внутреннем цикле с применением оператора . Насколько эта версия быстрее последовательной альтернативы, выполняемой на обычном процессоре? Умножение двух матриц (целых чисел) размером 1024 х 1024 последовательная версия на обычном процессоре выполняет в среднем 7350 миллисекунд, тогда как версия для графического процессора - держитесь крепче - 50 миллисекунд, в 147 раз быстрее!
Моделирование движения частиц
Примеры решения задач на графическом процессоре, представленные выше, имеют очень простую реализацию внутреннего цикла. Понятно, что так будет не всегда. В блоге Native Concurrency, ссылка на который уже приводилась выше, демонстрируется пример моделирования гравитационных взаимодействий между частицами. Моделирование включает бесконечное количество шагов; на каждом шаге вычисляются новые значения элементов вектора ускорений для каждой частицы и затем определяются их новые координаты. Здесь распараллеливанию подвергается вектор частиц - при достаточно большом количестве частиц (от нескольких тысяч и выше) можно создать достаточно большое количество заданий, чтобы загрузить работой все ядра графического процессора.
Основу алгоритма составляет реализация определения результата взаимодействий между двумя частицами, как показано ниже, которую легко можно перенести на графический процессор:
// здесь float4 - это векторы с четырьмя элементами, // представляющие частицы, участвующие в операциях void bodybody_interaction (float4& acceleration, const float4 p1, const float4 p2) restrict(amp) { float4 dist = p2 – p1; // w здесь не используется float absDist = dist.x*dist.x + dist.y*dist.y + dist.z*dist.z; float invDist = 1.0f / sqrt(absDist); float invDistCube = invDist*invDist*invDist; acceleration + = dist*PARTICLE_MASS*invDistCube; }
Исходными данными на каждом шаге моделирования является массив с координатами и скоростями движения частиц, а в результате вычислений создается новый массив с координатами и скоростями частиц:
Struct particle
{
float4 position, velocity;
// реализации конструктора, конструктора копирования и
// оператора = с restrict(amp) опущены для экономии места
};
void simulation_step(array
С привлечением соответствующего графического интерфейса, моделирование может оказаться очень интересным. Полный пример, представленный командой разработчиков C++ AMP, можно найти в блоге Native Concurrency. На моей системе с процессором Intel Core i7 и видеокартой Geforce GT 740M, моделирование движения 10 000 частиц выполняется со скоростью ~2.5 кадра в секунду (шагов в секунду) с использованием последовательной версии, выполняющейся на обычном процессоре, и 160 кадров в секунду с использованием оптимизированной версии, выполняющейся на графическом процессоре - огромное увеличение производительности.
Прежде чем завершить этот раздел, необходимо рассказать еще об одной важной особенности фреймворка C++ AMP, которая может еще больше повысить производительность кода, выполняемого на графическом процессоре. Графические процессоры поддерживают программируемый кеш данных (часто называемый разделяемой памятью (shared memory) ). Значения, хранящиеся в этом кеше, совместно используются всеми потоками выполнения в одной мозаике (tile). Благодаря мозаичной организации памяти, программы на основе фреймворка C++ AMP могут читать данные из памяти графической карты в разделяемую память мозаики и затем обращаться к ним из нескольких потоков выполнения без повторного извлечения этих данных из памяти графической карты. Доступ к разделяемой памяти мозаики выполняется примерно в 10 раз быстрее, чем к памяти графической карты. Иными словами, у вас есть причины продолжить чтение.
Чтобы обеспечить выполнение мозаичной версии параллельного цикла, методу parallel_for_each передается домен tiled_extent , который делит многомерный объект extent на многомерные фрагменты мозаики, и лямбда-параметр tiled_index, определяющий глобальный и локальный идентификатор потока внутри мозаики. Например, матрицу 16x16 можно разделить на фрагменты мозаики размером 2x2 (как показано на рисунке ниже) и затем передать функции parallel_for_each:
Extent <2> matrix(16,16); tiled_extent <2,2> tiledMatrix = matrix.tile <2,2> (); parallel_for_each (tiledMatrix, [=](tiled_index <2,2> idx) restrict(amp) { // ... });
Каждый из четырех потоков выполнения, принадлежащих одной и той же мозаике, могут совместно использовать данные, хранящиеся в блоке.
При выполнении операций с матрицами, в ядре графического процессора, взамен стандартного индекса index<2>, как в примерах выше, можно использовать idx.global . Грамотное использование локальной мозаичной памяти и локальных индексов может обеспечить существенный прирост производительности. Чтобы объявить мозаичную память, разделяемую всеми потоками выполнения в одной мозаике, локальные переменные можно объявить со спецификатором tile_static.
На практике часто используется прием объявления разделяемой памяти и инициализации отдельных ее блоков в разных потоках выполнения:
Parallel_for_each(tiledMatrix, [=](tiled_index <2,2> idx) restrict(amp) { // 32 байта совместно используются всеми потоками в блоке tile_static int local; // присвоить значение элементу для этого потока выполнения local = 42; });
Очевидно, что какие-либо выгоды от использования разделяемой памяти можно получить только в случае синхронизации доступа к этой памяти; то есть, потоки не должны обращаться к памяти, пока она не будет инициализирована одним из них. Синхронизация потоков в мозаике выполняется с помощью объектов tile_barrier (напоминающего класс Barrier из библиотеки TPL) - они смогут продолжить выполнение только после вызова метода tile_barrier.Wait(), который вернет управление только когда все потоки вызовут tile_barrier.Wait. Например:
Parallel_for_each (tiledMatrix, (tiled_index <2,2> idx) restrict(amp) { // 32 байта совместно используются всеми потоками в блоке tile_static int local; // присвоить значение элементу для этого потока выполнения local = 42; // idx.barrier - экземпляр tile_barrier idx.barrier.wait(); // Теперь этот поток может обращаться к массиву "local", // используя индексы других потоков выполнения! });
Теперь самое время воплотить полученные знания в конкретный пример. Вернемся к реализации умножения матриц, выполненной без применения мозаичной организации памяти, и добавим в него описываемую оптимизацию. Допустим, что размер матрицы кратен числу 256 - это позволит нам работать с блоками 16 х 16. Природа матриц допускает возможность поблочного их умножения, и мы можем воспользоваться этой особенностью (фактически, деление матриц на блоки является типичной оптимизацией алгоритма умножения матриц, обеспечивающей более эффективное использование кеша процессора).
Суть этого приема сводится к следующему. Чтобы найти C i,j (элемент в строке i и в столбце j в матрице результата), нужно вычислить скалярное произведение между A i,* (i-я строка первой матрицы) и B *,j (j-й столбец во второй матрице). Однако, это эквивалентно вычислению частичных скалярных произведений строки и столбца с последующим суммированием результатов. Мы можем использовать это обстоятельство для преобразования алгоритма умножения матриц в мозаичную версию:
Void MatrixMultiply(int* A, int m, int w, int* B, int n, int* C)
{
array_view Суть описываемой оптимизации в том, что каждый поток в мозаике (для блока 16 х 16 создается 256 потоков) инициализирует свой элемент в 16 х 16 локальных копиях фрагментов исходных матриц A и B. Каждому потоку в мозаике требуется только одна строка и один столбец из этих блоков, но все потоки вместе будут обращаться к каждой строке и к каждому столбцу по 16 раз. Такой подход существенно снижает количество обращений к основной памяти. Чтобы вычислить элемент (i,j) в матрице результата, алгоритму требуется полная i-я строка первой матрицы и j-й столбец второй матрицы. Когда потоки мозаике 16x16, представленные на диаграмме и k=0, заштрихованные области в первой и второй матрицах будут прочитаны в разделяемую память. Поток выполнения, вычисляющий элемент (i,j) в матрице результата, вычислит частичное скалярное произведение первых k элементов из i-й строки и j-го столбца исходных матриц. В данном примере применение мозаичной организации обеспечивает огромный прирост производительности. Мозаичная версия умножения матриц выполняется намного быстрее простой версии и занимает примерно 17 миллисекунд (для тех же исходных матриц размером 1024 х 1024), что в 430 быстрее версии, выполняемой на обычном процессоре! Прежде чем закончить обсуждение фреймворка C++ AMP, нам хотелось бы упомянуть инструменты (в Visual Studio), имеющиеся в распоряжении разработчиков. Visual Studio 2012 предлагает отладчик для графического процессора (GPU), позволяющий устанавливать контрольные точки, исследовать стек вызовов, читать и изменять значения локальных переменных (некоторые ускорители поддерживают отладку для GPU непосредственно; для других Visual Studio использует программный симулятор), и профилировщик, дающий возможность оценивать выгоды, получаемые приложением от распараллеливания операций с применением графического процессора. За дополнительной информацией о возможностях отладки в Visual Studio обращайтесь к статье «Пошаговое руководство. Отладка приложения C++ AMP» на сайте MSDN. До сих пор в этой статье демонстрировались примеры только на языке C++, тем не менее, есть несколько способов использовать мощь графического процессора в управляемых приложениях. Один из способов - использовать инструменты взаимодействий, позволяющие переложить работу с ядрами графического процессора на низкоуровневые компоненты C++. Это решение отлично подходит для тех, кто желает использовать фреймворк C++ AMP или имеет возможность использовать уже готовые компоненты C++ AMP в управляемых приложениях. Другой способ - использовать библиотеку, непосредственно работающую с графическим процессором из управляемого кода. В настоящее время существует несколько таких библиотек. Например, GPU.NET и CUDAfy.NET (обе являются коммерческими предложениями). Ниже приводится пример из репозитория GPU.NET GitHub, демонстрирующий реализацию скалярного произведения двух векторов: Public static void MultiplyAddGpu(double a, double b, double c)
{
int ThreadId = BlockDimension.X * BlockIndex.X + ThreadIndex.X;
int TotalThreads = BlockDimension.X * GridDimension.X;
for (int ElementIdx = ThreadId; ElementIdx Я придерживаюсь мнения, что гораздо проще и эффективнее освоить расширение языка (на основе C++ AMP), чем пытаться организовывать взаимодействия на уровне библиотек или вносить существенные изменения в язык IL. Итак, после того как мы рассмотрели возможности параллельного программирования в.NET и использованием GPU наверняка ни у кого не осталось сомнений, что организация параллельных вычислений является важным способом повышения производительности. Во многих серверах и рабочих станциях по всему миру остаются неиспользуемыми бесценные вычислительные мощности обычных и графических процессоров, потому что приложения просто не задействуют их. Библиотека Task Parallel Library дает нам уникальную возможность включить в работу все имеющиеся ядра центрального процессора, хотя при этом и придется решать некоторые интереснейшие проблемы синхронизации, чрезмерного дробления задач и неравного распределения работы между потоками выполнения. Фреймворк C++ AMP и другие многоцелевые библиотеки организации параллельных вычислений на графическом процессоре с успехом можно использовать для распараллеливания вычислений между сотнями ядер графического процессора. Наконец, имеется, неисследованная ранее, возможность получить прирост производительности от применения облачных технологий распределенных вычислений, превратившихся в последнее время в одно из основных направлений развития информационных технологий. Сегодня новости об использовании графических процессоров для общих вычислений можно услышать на каждом углу. Такие слова, как CUDA, Stream и OpenCL, за каких-то два года стали чуть ли не самыми цитируемыми в айтишном интернете. Однако, что значат эти слова, и что несут стоящие за ними технологии, известно далеко не каждому. А для линуксоидов, привыкших "быть в пролете", так и вообще все это видится темным лесом. Рождение GPGPU
Мы все привыкли думать, что единственным компонентом компа, способным выполнять любой код, который ему прикажут, является центральный процессор. Долгое время почти все массовые ПК оснащались единственным процессором, который занимался всеми мыслимыми расчетами, включая код операционной системы, всего нашего софта и вирусов. Позже появились многоядерные процессоры и многопроцессорные системы, в которых таких компонентов было несколько. Это позволило машинам выполнять несколько задач одновременно, а общая (теоретическая) производительность системы поднялась ровно во столько раз, сколько ядер было установлено в машине. Однако оказалось, что производить и конструировать многоядерные процессоры слишком сложно и дорого. В каждом ядре приходилось размещать полноценный процессор сложной и запутанной x86-архитектуры, со своим (довольно объемным) кэшем, конвейером инструкций, блоками SSE, множеством блоков, выполняющих оптимизации и т.д. и т.п. Поэтому процесс наращивания количества ядер существенно затормозился, и белые университетские халаты, которым два или четыре ядра было явно мало, нашли способ задействовать для своих научных расчетов другие вычислительные мощности, которых было в достатке на видеокарте (в результате даже появился инструмент BrookGPU, эмулирующий дополнительный процессор с помощью вызовов функций DirectX и OpenGL). Графические процессоры, лишенные многих недостатков центрального процессора, оказались отличной и очень быстрой счетной машинкой, и совсем скоро к наработкам ученых умов начали присматриваться сами производители GPU (а nVidia так и вообще наняла большинство исследователей на работу). В результате появилась технология nVidia CUDA, определяющая интерфейс, с помощью которого стало возможным перенести вычисление сложных алгоритмов на плечи GPU без каких-либо костылей. Позже за ней последовала ATi (AMD) с собственным вариантом технологии под названием Close to Metal (ныне Stream), а совсем скоро появилась ставшая стандартом версия от Apple, получившая имя OpenCL. GPU — наше все?
Несмотря на все преимущества, техника GPGPU имеет несколько проблем. Первая из них заключается в очень узкой сфере применения. GPU шагнули далеко вперед центрального процессора в плане наращивания вычислительной мощности и общего количества ядер (видеокарты несут на себе вычислительный блок, состоящий из более чем сотни ядер), однако такая высокая плотность достигается за счет максимального упрощения дизайна самого чипа. В сущности основная задача GPU сводится к математическим расчетам с помощью простых алгоритмов, получающих на вход не очень большие объемы предсказуемых данных. По этой причине ядра GPU имеют очень простой дизайн, мизерные объемы кэша и скромный набор инструкций, что в конечном счете и выливается в дешевизну их производства и возможность очень плотного размещения на чипе. GPU похожи на китайскую фабрику с тысячами рабочих. Какие-то простые вещи они делают достаточно хорошо (а главное — быстро и дешево), но если доверить им сборку самолета, то в результате получится максимум дельтаплан. Поэтому первое ограничение GPU — это ориентированность на быстрые математические расчеты, что ограничивает сферу применения графических процессоров помощью в работе мультимедийных приложений, а также любых программ, занимающихся сложной обработкой данных (например, архиваторов или систем шифрования, а также софтин, занимающихся флуоресцентной микроскопией, молекулярной динамикой, электростатикой и другими, малоинтересными для линуксоидов вещами). Вторая проблема GPGPU в том, что адаптировать для выполнения на GPU можно далеко не каждый алгоритм. Отдельно взятые ядра графического процессора довольно медлительны, и их мощь проявляется только при работе сообща. А это значит, что алгоритм будет настолько эффективным, насколько эффективно его сможет распараллелить программист. В большинстве случаев с такой работой может справиться только хороший математик, которых среди разработчиков софта совсем немного. И третье: графические процессоры работают с памятью, установленной на самой видеокарте, так что при каждом задействовании GPU будет происходить две дополнительных операции копирования: входные данные из оперативной памяти самого приложения и выходные данные из GRAM обратно в память приложения. Нетрудно догадаться, что это может свести на нет весь выигрыш во времени работы приложения (как и происходит в случае с инструментом FlacCL, который мы рассмотрим позже). Но и это еще не все. Несмотря на существование общепризнанного стандарта в лице OpenCL, многие программисты до сих пор предпочитают использовать привязанные к производителю реализации техники GPGPU. Особенно популярной оказалась CUDA, которая хоть и дает более гибкий интерфейс программирования (кстати, OpenCL в драйверах nVidia реализован поверх CUDA), но намертво привязывает приложение к видеокартам одного производителя. KGPU или ядро Linux, ускоренное GPU
Исследователи из университета Юты разработали систему KGPU, позволяющую выполнять некоторые функции ядра Linux на графическом процессоре с помощью фреймворка CUDA. Для выполнения этой задачи используется модифицированное ядро Linux и специальный демон, который работает в пространстве пользователя, слушает запросы ядра и передает их драйверу видеокарты с помощью библиотеки CUDA. Интересно, что несмотря на существенный оверхед, который создает такая архитектура, авторам KGPU удалось создать реализацию алгоритма AES, который поднимает скорость шифрования файловой системы eCryptfs в 6 раз.
Что есть сейчас?
В силу своей молодости, а также благодаря описанным выше проблемам, GPGPU так и не стала по-настоящему распространенной технологией, однако полезный софт, использующий ее возможности, существует (хоть и в мизерном количестве). Одними из первых появились крэкеры различных хэшей, алгоритмы работы которых очень легко распараллелить. Также родились мультимедийные приложения, например, кодировщик FlacCL, позволяющий перекодировать звуковую дорожку в формат FLAC. Поддержкой GPGPU обзавелись и некоторые уже существовавшие ранее приложения, самым заметным из которых стал ImageMagick, который теперь умеет перекладывать часть своей работы на графический процессор с помощью OpenCL. Также есть проекты по переводу на CUDA/OpenCL (не любят юниксоиды ATi) архиваторов данных и других систем сжатия информации. Наиболее интересные из этих проектов мы рассмотрим в следующих разделах статьи, а пока попробуем разобраться с тем, что нам нужно для того, чтобы все это завелось и стабильно работало. GPU уже давно обогнали x86-процессоры в производительности · Во-вторых, в систему должны быть установлены последние проприетарные драйвера для видеокарты, они обеспечат поддержку как родных для карточки технологий GPGPU, так и открытого OpenCL. · И в-третьих, так как пока дистрибутивостроители еще не начали распространять пакеты приложений с поддержкой GPGPU, нам придется собирать приложения самостоятельно, а для этого нужны официальные SDK от производителей: CUDA Toolkit или ATI Stream SDK. Они содержат в себе необходимые для сборки приложений заголовочные файлы и библиотеки. Ставим CUDA Toolkit
Идем по вышеприведенной ссылке и скачиваем CUDA Toolkit для Linux (выбрать можно из нескольких версий, для дистрибутивов Fedora, RHEL, Ubuntu и SUSE, есть версии как для архитектуры x86, так и для x86_64). Кроме того, там же надо скачать комплекты драйверов для разработчиков (Developer Drivers for Linux, они идут первыми в списке). Запускаем инсталлятор SDK:
$ sudo sh cudatoolkit_4.0.17_linux_64_ubuntu10.10.run Когда установка будет завершена, приступаем к установке драйверов. Для этого завершаем работу X-сервера: # sudo /etc/init.d/gdm stop Открываем консоль $ sudo sh devdriver_4.0_linux_64_270.41.19.run После окончания установки стартуем иксы: Чтобы приложения смогли работать с CUDA/OpenCL, прописываем путь до каталога с CUDA-библиотеками в переменную LD_LIBRARY_PATH:
$ export LD_LIBRARY_PATH=/usr/local/cuda/lib64
Или, если ты установил 32-битную версию: $ export LD_LIBRARY_PATH=/usr/local/cuda/lib32
Также необходимо прописать путь до заголовочных файлов CUDA, чтобы компилятор их нашел на этапе сборки приложения: $ export C_INCLUDE_PATH=/usr/local/cuda/include
Все, теперь можно приступить к сборке CUDA/OpenCL-софта. Ставим ATI Stream SDK Stream SDK не требует установки, поэтому скачанный с сайта AMD-архив можно просто распаковать в любой каталог (лучшим выбором будет /opt) и прописать путь до него во всю ту же переменную LD_LIBRARY_PATH:
$ wget http://goo.gl/CNCNo
$ sudo tar -xzf ~/AMD-APP-SDK-v2.4-lnx64.tgz -C /opt
$ export LD_LIBRARY_PATH=/opt/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/
$ export C_INCLUDE_PATH=/opt/AMD-APP-SDK-v2.4-lnx64/include/
Как и в случае с CUDA Toolkit, x86_64 необходимо заменить на x86 в 32-битных системах. Теперь переходим в корневой каталог и распаковываем архив icd-registration.tgz (это своего рода бесплатный лицензионный ключ): $ sudo tar -xzf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz -
С /
Проверяем правильность установки/работы пакета с помощью инструмента clinfo: $ /opt/AMD-APP-SDK-v2.4-lnx64/bin/x86_64/clinfo
ImageMagick и OpenCL Поддержка OpenCL появилась в ImageMagick уже достаточно давно, однако по умолчанию она не активирована ни в одном дистрибутиве. Поэтому нам придется собрать IM самостоятельно из исходников. Ничего сложного в этом нет, все необходимое уже есть в SDK, поэтому сборка не потребует установки каких-то дополнительных библиотек от nVidia или AMD. Итак, скачиваем/распаковываем архив с исходниками: $ wget http://goo.gl/F6VYV $ tar -xjf ImageMagick-6.7.0-0.tar.bz2
$ cd ImageMagick-6.7.0-0
$ sudo apt-get install build-essential Запускаем конфигуратор и грепаем его вывод на предмет поддержки OpenCL: $ LDFLAGS=-L$LD_LIBRARY_PATH ./confi gure | grep -e cl.h -e OpenCL
Правильный результат работы команды должен выглядеть примерно так: checking CL/cl.h usability... yes
checking CL/cl.h presence... yes
checking for CL/cl.h... yes
checking OpenCL/cl.h usability... no
checking OpenCL/cl.h presence... no
checking for OpenCL/cl.h... no
checking for OpenCL library... -lOpenCL
Словом "yes" должны быть отмечены либо первые три строки, либо вторые (или оба варианта сразу). Если это не так, значит, скорее всего, была неправильно инициализирована переменная C_INCLUDE_PATH. Если же словом "no" отмечена последняя строка, значит, дело в переменной LD_LIBRARY_PATH. Если все окей, запускаем процесс сборки/установки: $ sudo make install clean Проверяем, что ImageMagick действительно был скомпилирован с поддержкой OpenCL: $ /usr/local/bin/convert -version | grep Features
Features: OpenMP OpenCL Теперь измерим полученный выигрыш в скорости. Разработчики ImageMagick рекомендуют использовать для этого фильтр convolve: $ time /usr/bin/convert image.jpg -convolve "-1, -1, -1, -1, 9, -1, -1, -1, -1" image2.jpg
$ time /usr/local/bin/convert image.jpg -convolve "-1, -1, -1, -1, 9, -1, -1, -1, -1" image2.jpg
Некоторые другие операции, такие как ресайз, теперь тоже должны работать значительно быстрее, однако надеяться на то, что ImageMagick начнет обрабатывать графику с бешеной скоростью, не стоит. Пока еще очень малая часть пакета оптимизирована с помощью OpenCL. FlacCL (Flacuda) FlacCL — это кодировщик звуковых файлов в формат FLAC, задействующий в своей работе возможности OpenCL. Он входит в состав пакета CUETools для Windows, но благодаря mono может быть использован и в Linux. Для получения архива с кодировщиком выполняем следующую команду: $ mkdir flaccl && cd flaccl $ wget www.cuetools.net/install/flaccl03.rar
$ sudo apt-get install unrar mono
$ unrar x fl accl03.rar Чтобы программа смогла найти библиотеку OpenCL, делаем символическую ссылку: $ ln -s $LD_LIBRARY_PATH/libOpenCL.so libopencl.so
Теперь запускаем кодировщик:
$ mono CUETools.FLACCL.cmd.exe music.wav
Если на экран будет выведено сообщение об ошибке "Error: Requested compile size is bigger than the required workgroup size of 32", значит, у нас в системе слишком слабенькая видеокарта, и количество задействованных ядер следует сократить до указанного числа с помощью флага ‘--group-size XX’, где XX — нужное количество ядер. Сразу скажу, из-за долгого времени инициализации OpenCL заметный выигрыш можно получить только на достаточно длинных дорожках. Короткие звуковые файлы FlacCL обрабатывает почти с той же скоростью, что и его традиционная версия. oclHashcat или брутфорс по-быстрому Как я уже говорил, одними из первых поддержку GPGPU в свои продукты добавили разработчики различных крэкеров и систем брутфорса паролей. Для них новая технология стала настоящим святым граалем, который позволил с легкостью перенести от природы легко распараллеливаемый код на плечи быстрых GPU-процессоров. Поэтому неудивительно, что сейчас существуют десятки самых разных реализаций подобных программ. Но в этой статье я расскажу только об одной из них — oclHashcat. oclHashcat — это ломалка, которая умеет подбирать пароли по их хэшу с экстремально высокой скоростью, задействуя при этом мощности GPU с помощью OpenCL. Если верить замерам, опубликованным на сайте проекта, скорость подбора MD5-паролей на nVidia GTX580 составляет до 15800 млн комбинаций в секунду, благодаря чему oclHashcat способен найти средний по сложности восьмисимвольный пароль за какие-то 9 минут. Программа поддерживает OpenCL и CUDA, алгоритмы MD5, md5($pass.$salt), md5(md5($pass)), vBulletin < v3.8.5, SHA1, sha1($pass.$salt), хэши MySQL, MD4, NTLM, Domain Cached Credentials, SHA256, поддерживает распределенный подбор паролей с задействованием мощности нескольких машин. $ 7z x oclHashcat-0.25.7z $ cd oclHashcat-0.25 И запустить программу (воспользуемся пробным списком хэшей и пробным словарем): $ ./oclHashcat64.bin example.hash ?l?l?l?l example.dict
oclHashcat откроет текст пользовательского соглашения, с которым следует согласиться, набрав "YES". После этого начнется процесс перебора, прогресс которого можно узнать по нажатию Для возобновления — $ ./oclHashcat64.bin hash.txt ?l?l?l?l ?l?l?l?l
И различные модификации словаря и метода прямого перебора, а также их комбинации (об этом можно прочитать в файле docs/examples.txt). В моем случае скорость перебора всего словаря составила 11 минут, тогда как прямой перебор (от aaaaaaaa до zzzzzzzz) длился около 40 минут. В среднем скорость работы GPU (чип RV710) составила 88,3 млн/с. Выводы
Несмотря на множество самых разных ограничений и сложность разработки софта, GPGPU — будущее высокопроизводительных настольных компов. Но самое главное — использовать возможности этой технологии можно прямо сейчас, и это касается не только Windows-машин, но и Linux. Часто стал появляться вопрос: почему нет GPU ускорения в программе Adobe Media Encoder CC? А то что Adobe Media Encoder использует GPU ускорение, мы выяснили , а также отметили нюансы его использования . Также встречается утверждение: что в программе Adobe Media Encoder CC убрали поддержку GPU ускорения. Это ошибочное мнение и вытекает из того, что основная программа Adobe Premiere Pro CC теперь может работать без прописанной и рекомендованной видеокарты, а для включения GPU движка в Adobe Media Encoder CC, видеокарта должна быть обязательно прописана в документах: cuda_supported_cards или opencl_supported_cards. Если с чипсетами nVidia все понятно, просто берем имя чипсета и вписываем его в документ cuda_supported_cards. То при использовании видеокарт AMD прописывать надо не имя чипсета, а кодовое название ядра. Итак, давайте на практике проверим, как на ноутбуке ASUS N71JQ с дискретной графикой ATI Mobility Radeon HD 5730 включить GPU движок в Adobe Media Encoder CC. Технические данные графического адаптера ATI Mobility Radeon HD 5730 показываемые утилитой GPU-Z: Запускаем программу Adobe Premiere Pro CC и включаем движок: Mercury Playback Engine GPU Acceleration (OpenCL). Три DSLR видео на таймлайне, друг над другом, два из них, создают эффект картинка в картинке. Ctrl+M, выбираем пресет Mpeg2-DVD, убираем черные полосы по бокам с помощью опции Scale To Fill. Включаем также повышеное качество для тестов без GPU: MRQ (Use Maximum Render Quality). Нажимаем на кнопку: Export. Загрузка процессора до 20% и оперативной памяти 2.56 Гбайт. Загрузка GPU чипсета ATI Mobility Radeon HD 5730 составляет 97% и 352Мб бортовой видеопамяти. Ноутбук тестировался при работе от аккумулятора, поэтому графическое ядро / память работают на пониженных частотах: 375 / 810 МГц. Итоговое время просчета: 1 минута и 55 секунд
(вкл/откл. MRQ при использовании GPU движка, не влияет на итогове время просчета). Тактовые частоты процессора при работе от аккумулятора: 930МГц. Запускаем AMEEncodingLog и смотрим итоговое время просчета: 5 минут и 14 секунд
. Повторяем тест, но уже при снятой галке Use Maximum Render Quality, нажимаем на кнопку: Queue. Итоговое время просчета: 1 минута и 17 секунд
. Теперь включим GPU движок в Adobe Media Encoder CC, запускаем программу Adobe Premiere Pro CC, нажимаем комбинацию клавиш: Ctrl + F12, выполняем Console > Console View и в поле Command вбиваем GPUSniffer, нажимаем Enter. Выделяем и копируем имя в GPU Computation Info. В директории программы Adobe Premiere Pro CC открываем документ opencl_supported_cards, и в алфавитном порядке вбиваем кодовое имя чипсета, Ctrl+S. Нажимаем на кнопку: Queue, и получаем GPU ускорение просчета проекта Adobe Premiere Pro CC в Adobe Media Encoder CC. Итоговое время: 1 минута и 55 секунд
. Подключаем ноутбук к розетке, и повторяем результаты просчетов. Queue, галка MRQ снята, без включения движка, загрузка оперативной памяти немного подросла: Тактовые частоты процессора: 1.6ГГц при работе от розетки и включении режима: Высокая производительность. Итоговое время: 46 секунд
. Включаем движок: Mercury Playback Engine GPU Acceleration (OpenCL), как видно от сети ноутбучная видеокарта работает на своих базовых частотах, загрузка GPU в Adobe Media Encoder CC достигает 95%. Итоговое время просчета, снизилось с 1 минуты 55 секунд
, до 1 минуты и 5 секунд
. *Для визуализации в Adobe Media Encoder CC теперь используется графический процессор (GPU). Поддерживаются стандарты CUDA и
OpenCL. В Adobe Media Encoder CC, движок GPU используется для следующих процессов визуализации: Читаем про скрытый раздел на системном диске ноутбука ASUS N71JQ. Какая программа нужна для майнинга криптовалюты? Что учитывать при выборе оборудования для майнинга? Как майнить биткоины и эфириум с помощью видеокарты на компьютере? Оказывается, мощные видеокарты нужны не только фанатам зрелищных компьютерных игр. Тысячи пользователей по всему миру используют графические адаптеры для заработка криптовалюты! Из нескольких карт с мощными процессорами майнеры
создают фермы
– вычислительные центры, которые добывают цифровые деньги практически из воздуха! С вами Денис Кудерин – эксперт журнала «ХитёрБобёр» по вопросам финансов и их грамотного умножения. Я расскажу, что собой представляет майнинг на видеокарте
в 17-18 годах, как правильно выбрать устройство для заработка криптовалюты, и почему добывать биткоины на видеокартах уже не выгодно. Вы узнаете также, где купить самую производительную и мощную видеокарту
для профессионального майнинга, и получите экспертные советы по повышению эффективности своей майнинг-фермы. Хорошая видеокарта – не просто адаптер цифровых сигналов, но и мощный процессор, способный решать сложнейшие вычислительные задачи. И в том числе – вычислять хеш-код для цепочки блоков (блокчейна)
. Это делает графические платы идеальным инструментом для майнинга
– добычи криптовалюты. Вопрос:
Почему именно процессор видеокарты? Ведь в любом компьютере есть центральный процессор? Разве не логично проводить вычисления с его помощью? Ответ:
П
роцессор CPU тоже умеет вычислять блокчейны, но делает это в сотни раз медленнее, чем процессор видеокарты (GPU). И не потому, что один лучше, другой хуже. Просто принцип работы у них разный. А если совместить несколько видеокарт, мощность такого вычислительного центра повысится ещё в несколько раз. Для тех, кто понятия не имеет о том, как добываются цифровые деньги, небольшой ликбез. Майнинг – основной, а иногда и единственный способ производства криптовалюты
. Поскольку эти деньги никто не чеканит и не печатает, и они представляют собой не материальную субстанцию, а цифровой код, кто-то должен этот код вычислять. Этим и занимаются майнеры, а точнее, их компьютеры. Помимо вычислений кода, майнинг выполняет ещё несколько важнейших задач:
Сразу хочу охладить пыл начинающих добытчиков: процесс майнинга с каждым годом становится всё труднее. К примеру, с помощью видеокарты уже давно нерентабелен. Битки с помощью GPU добывают сейчас только упёртые любители, поскольку на смену видеокартам пришли специализированные процессоры ASIC
. Эти чипы потребляют меньше электроэнергии и более эффективны в плане вычислений. Всем хороши, но стоят порядка 130-150 тысяч рублей
. К счастью для майнеров, биткоин – не единственная на планете криптовалюта, а одна из сотен. Другие цифровые деньги – эфириумы, Zcash, Expanse
, догкоины
и т.д. по-прежнему выгодно добывать с помощью видеокарт. Вознаграждение стабильное, а оборудование окупается примерно через 6-12 месяцев. Но есть ещё одна проблема – дефицит мощных видеокарт
. Ажиотаж вокруг криптовалюты привел к удорожанию этих устройств. Купить новую, пригодную для майнинга, видеокарту в России не так-то просто. Начинающим майнерам приходится заказывать видеоадаптеры в интернет-магазинах (в том числе зарубежных) или приобретать подержанный товар. Последнее, кстати, делать не советую: оборудование для майнинга устаревает и изнашивается с фантастической скоростью
. На Авито даже продают целые фермы для добычи криптовалюты. Причин много: одни майнеры уже «наигрались» в добычу цифровых денег и решили заняться более прибыльными операциями с криптовалютой (в частности, биржевой торговлей), другие поняли, что конкурировать с мощными китайскими кластерами, работающими на базе электростанций, им не под силу. Третьи переключились с видеокарт на «асики». Однако ниша пока ещё приносит определенную прибыль, и если заняться с помощью видеокарты прямо сейчас, вы ещё успеете вскочить на подножку уходящего в будущее поезда. Другое дело, что игроков на этом поле становится всё больше. Причем суммарное количество цифровых монет от этого не увеличивается. Наоборот, награда становится меньше. Так, шесть лет назад награда за один блокчейн сети биткоин равнялась 50 монетам
, сейчас это лишь 12,5 БТК
. Сложность вычислений при этом увеличилась в 10 тысяч раз. Правда, и стоимость самого биткоина выросла за это время многократно. Есть два варианта майнинга – сольный и в составе пула. Одиночной добычей заниматься сложно – нужно иметь огромное количество хешрейта
(единиц мощности), чтобы начатые вычисления имели вероятность успешного закрытия. 99% всех майнеров работает в пулах
(англ. pool – бассейн) – сообществах, занятых распределением вычислительных задач. Совместный майнинг нивелирует фактор случайности и гарантирует стабильную прибыль. Один мой знакомый майнер высказался так по этому поводу: я занимаюсь майнингом уже 3 года, за это время не общался ни с кем, кто бы добывал в одиночку. Такие старатели похожи на золотоискателей 19 века. Можно искать годами свой самородок (в нашем случае – биткоин) и так и не найти. То есть блокчейн так и не будет закрыт, а значит никакой награды вы не получите. Чуть больше шансов у «одиноких охотников» за эфирами и некоторыми другими крипто-монетами. Из-за своеобразного алгоритма шифрования ETH не добывают с помощью специальных процессоров (их ещё не придумали). Используют для этого исключительно видеокарты. За счёт эфириумов и других альткоинов ещё держатся многочисленные фермеры современности. Одной видеокарты для создания полноценной фермы будет недостаточно: 4 штуки – «прожиточный минимум» для майнера
, рассчитывающего на стабильную прибыль. Не менее важна мощная система охлаждения видеоадаптеров. И не упускайте из виду и такую статью расходов, как плата за электроэнергию. Пошаговая инструкция обезопасит от ошибок и ускорит настройку процесса. Крупнейшие в мире криптовалютные пулы дислоцируются на территории КНР, а также в Исландии и в США. Формально эти сообщества не имеют государственной принадлежности, но русскоязычные сайты пулов – редкость в интернете. Поскольку добывать на видеокарте вам придётся скорее всего эфириум, то и выбирать нужно будет сообщество, занятое вычислением этой валюты. Хотя Etherium – относительно молодой альткоин, пулов для его майнинга существует множество
. От выбора сообщества во многом зависит размер вашего дохода и его стабильность. Выбираем пул по следующим критериям:
На рынке криптовалют изменения происходят ежедневно. Это касается и скачков курса, и появления новых цифровых денег – форков
биткоина. Случаются и глобальные перемены. Так, недавно стало известно, что эфир в ближайшем будущем переходит на принципиально иную систему распределения прибыли. В двух словах – доход в сети Etherium будут иметь майнеры, у которых есть «много кэцэ», то есть монет, а начинающим добытчикам останется либо прикрыть лавочку, либо переключиться на другие деньги. Но такие «мелочи» энтузиастов никогда не останавливали. Тем более, есть программка под названием Profitable Pool. Она автоматически отслеживает самые выгодные для добычи альткоины на текущий момент. Есть и сервис поиска самих пулов, а также их рейтинги в реальном времени. Зарегистрировавшись на сайте пула, нужно скачать специальную программу-майнер – не вычислять же код вручную с помощью калькулятора. Таких программ тоже достаточно. Для биткоина это – 50
miner
или CGMiner
, для эфира – Ethminer
. Настройка требует внимательности и определённых навыков. К примеру, нужно знать, что такое скрипты, и уметь вписывать их в командную строку вашего компьютера. Технические моменты я советую уточнять у практикующих майнеров, поскольку у каждой программы свои нюансы установки и настройки. Если у вас ещё нет биткоин-кошелька или эфириум-хранилища, нужно их обязательно зарегистрировать. Кошельки скачиваем с официальных сайтов.
Иногда помощь в этом деле оказывают сами пулы, но не безвозмездно. Осталось только запустить процесс и ждать первых поступлений. Обязательно скачайте вспомогательную программу, которая будет отслеживать состояние основных узлов вашего компьютера – загруженность, перегрев и т.д. Компьютеры работают круглосуточно и автоматически, вычисляя код
. Вам остаётся только следить, чтобы карты или другие системы не вышли из строя. Криптовалюта потечёт в ваш кошелёк со скоростью, прямо пропорциональной количеству хешрейта. Как переводить цифровую валюту в фиатную?
Вопрос, достойный отдельной статьи. Если коротко, то самый быстрый способ – обменные пункты. Они берут себе проценты за услуги, и ваша задача – найти наиболее выгодный курс с минимальной комиссией. Сделать это поможет профессиональный сервис сравнения обменников. Выбирать видеокарту нужно с умом. Первая попавшаяся или та, которая уже стоит на вашем компьютере, тоже будет майнить, но этой мощности даже для эфиров будет ничтожно мало
. Основные показатели следующие: производительность (мощность), энергопотребление, охлаждение, перспективы разгона. Тут всё просто – чем выше производительность процессора, тем лучше для вычисления хеш-кода. Отличные показатели обеспечивают карты с объёмом памяти более 2 ГБ. И выбирайте устройства с 256-разрядной шиной. 128-разрядные для этого дела не годятся. Мощность, это, конечно, здорово – высокий хешрейт и всё такое. Но не забывайте о показателях энергопотребления. Некоторые производительные фермы «съедают» столько электричества, что затраты едва окупаются либо не окупаются вообще. Стандартная состоит из 4-16 карт. Она производит избыточное количество тепла, губительное для железа и нежелательное для самого фермера. В однокомнатной квартире без кондиционера жить и работать будет, мягко говоря, некомфортно. Поэтому при выборе двух карт с одинаковой производительностью отдавайте предпочтение той, у которой меньше показатель тепловой мощности (TDP
)
. Наилучшие параметры охлаждения демонстрируют карты Radeon. Эти же устройства дольше всех остальных карт работают в активном режиме без износа. Дополнительные кулеры не только отведут лишнее тепло от процессоров, но и продлят срок их жизни. Разгон – принудительное повышение рабочих показателей видеокарты. Возможность «разогнать карту» зависит от двух параметров – частоты графического процессора и частоты видеопамяти
. Именно их вы и будете разгонять, если захотите повысить вычислительные мощности. Какие видеокарты брать?
Вам понадобятся устройства последнего поколения или по меньшей мере графические ускорители, выпущенные не раньше, чем 2-3 года назад. Майнеры используют карты AMD
Radeon
, Nvidia
, Geforce GTX
. Взгляните на таблицу окупаемости видеокарт (данные актуальны на конец 2017 года):
Как я уже говорил, видеокарты с ростом популярности майнинга превратились в дефицитный товар. Чтобы купить нужное устройство, придётся потратить немало сил и времени. Вам поможет наш обзор лучших точек онлайн-продаж. На момент написания статьи в продаже есть карты AMD
, Nvidia
(8 Gb) и другие разновидности, подходящие для майнинга. Компания неоднократно получала неофициальное звание лучшего в РФ магазина для майнеров. Оперативный сервис, доброжелательное отношение к клиентам, передовое оборудование – главные составляющие успеха. Прямой партнёр ведущего производителя видеокарт для игр и майнинга – Nvidia
. Максимальный срок ожидания товара – 14 дней. Нетерпеливые читатели, желающие начать майнинг прямо сейчас и получать доходы уже с завтрашнего утра, непременно спросят – сколько зарабатывают майнеры
? Заработки зависят от оборудования, курса криптовалюты, эффективности пула, мощности фермы, количества хешрейта и кучи других факторов. Одним удаётся получать ежемесячно до 70 000 в рублях
, другие довольствуются 10 долларами
в неделю. Это нестабильный и непредсказуемый бизнес. Полезные советы помогут повысить доходы и оптимизировать расходы. Будете майнить стремительно растущую в цене валюту, заработаете больше. Для примера – эфир сейчас стоит около 300 долларов
, биткоин – больше 6000
. Но учитывать нужно не только текущую стоимость, но и темпы роста за неделю. Калькулятор майнинга на сайте пула или на другом специализированном сервисе поможет выбрать оптимальную программу и даже видеокарту для майнинга. Ядер много не бывает… Современные GPU – это монструозные шустрые бестии, способные пережевывать гигабайты данных. Однако человек хитер и, как бы не росли вычислительные мощности, придумывает задачи все сложнее и сложнее, так что приходит момент когда с грустью приходиться констатировать – нужна оптимизацию 🙁 В данной статье описаны основные понятия, для того чтобы было легче ориентироваться в теории gpu-оптимизации и базовые правила, для того чтобы к этим понятиям, приходилось обращаться по-реже. Причины по которой GPU эффективны для работы с большими объемами данных, требующих обработки: Пропускная способность памяти (memory bandwidth)
– это сколько информации – бит или гигабайт – может может быть передано за единицу времени секунду или процессорный такт. Одна из задач оптимизации – задействовать по максимуму пропускную способность – увеличить показатели throughput
(в идеале она должна быть равна memory bandwidth). Для улучшения использования пропускной способности: Задержка (latency)
– промежуток времени между моментами, когда контролер запросил конкретную ячейку памяти и тем моментом, когда данные стали доступны процессору для выполнения инструкций. На саму задержку мы никак повлиять не можем – эти ограничения присутствуют на аппаратном уровне. Именно за счет этой задержки процессор может одновременно обслуживать несколько потоков – пока поток А запросил выделить ему памяти, поток Б может что-то посчитать, а поток С ждать пока к нему придут запрошенные данные. Как снизить задержку (latency) если используется синхронизация: В высоколобых разговорах об оптимизации часто мелькает термин – gpu occupancy
или kernel occupancy
– он отражает эффективность использования ресурсов-мощностей видеокарты. Отдельно отмечу – если вы даже и используете все ресурсы – это отнюдь не значит что вы используете их правильно. Вычислительные мощности GPU – это сотни процессоров жадных до вычислений, при создании программы – ядра (kernel) – на плечи программиста ложиться бремя распределения нагрузки на них. Ошибка может привести к тому, что большая часть этих драгоценных ресурсов может бесцельно простаивать. Сейчас я объясню почему. Начать придется издалека. Напомню, что варп (warp
в терминологии NVidia, wavefront
– в терминологии AMD) – набор потоков которые одновременно выполняют одну и туже функцию-кернел на процессоре. Потоки, объединенные программистом в блоки разбиваются на варпы планировщиком потоков (отдельно для каждого мультипроцессора) – пока один варп работает, второй ждет обработки запросов к памяти и т.д. Если какие-то из потоков варпа все еще выполняют вычисления, а другие уже сделали все что могли – имеет место быть неэффективное использование вычислительного ресурса – в народе именуемое простаивание мощностей. Каждая точка синхронизации, каждое ветвление логики может породить такую ситуацию простоя.
Максимальная дивергенция (ветвление логики исполнения) зависит от размера варпа. Для GPU от NVidia – это 32, для AMD – 64. Для того чтобы снизить простой мультипроцессора во время выполнения варпа: Для эффективного решения данной задачи имеет смысл разобраться – как же происходит формирование варпов (для случая с несколькими размерностями). На самом деле порядок простой – в первую очередь по X, потом по Y и, в последнюю очередь, Z. ядро запускается с блоками размерностью 64×16, потоки разбиваются по варпам в порядке X, Y, Z – т.е. первые 64 элемента разбиваются на два варпа, потом вторые и т.д. Ядро запускается с блоками размерностью 16×64. В первый варп добавляются первые и вторые 16 элементов, во второй варп – третьи и четвертые и т.д. Как снижать дивергенцию (помните – ветвление – не всегда причина критичной потери производительности) Как использовать ресурсы GPU по максимуму
Ресурсы GPU, к сожалению, тоже имеют свои ограничения. И, строго говоря, перед запуском функции-кернела имеет смысл определить лимиты и при распределении нагрузки эти лимиты учесть. Почему это важно? У видеокарт есть ограничения на общее число потоков, которое может выполнять один мультипроцессор, максимальное число потоков в одном блоке, максимальное число варпов на одном процессоре, ограничения на различные виды памяти и т.п. Всю эту информацию можно запросить как программно, через соответствующее API так и предварительно с помощью утилит из SDK. (Модули deviceQuery для устройств NVidia, CLInfo – для видеокарт AMD). Общая практика: При этом следует учитывать что абсолютный минимум – 3-4 варпа/вейфронта крутятся одновременно на каждом процессоре, мудрые гайды советуют исходить из соображения – не меньше семи вейфронатов. При этом – не забывать ограничения по железу! В голове все эти детали держать быстро надоедает, потому для расчет gpu-occupancy NVidia предложила неожиданный инструмент – эксельный(!) калькулятор набитый макросами. Туда можно ввести информацию по максимальному числу потоков для SM, число регистров и размер общей (shared) памяти доступных на потоковом процессоре, и используемые параметры запуска функций – а он выдает в процентах эффективность использования ресурсов (и вы рвете на голове волосы осознавая что чтобы задействовать все ядра вам не хватает регистров). информация по использованию: GPU и операции с памятью
Видеокарты оптимизированы для 128-битных операций с памятью. Т.е. в идеале – каждая манипуляция с памятью, в идеале, должна изменять за раз 4 четырех-байтных значения. Основная неприятность для программиста заключается в том, что современные компиляторы для GPU не умеют оптимизировать такие вещи. Это приходится делать прямо в коде функции и, в среднем, приносит доли-процента по приросту производительности. Гораздо большее влияние на производительность имеет частота запросов к памяти. Проблема обстоит в следующем – каждый запрос возвращает в ответ кусочек данных размером кратный 128 битам. А каждый поток использует лишь четверть его (в случае обычной четырех-байтовой переменной). Когда смежные потоки одновременно работают с данными расположенными последовательно в ячейках памяти – это снижает общее число обращений к памяти. Называется это явление – объединенные операции чтения и записи (coalesced access – good! both read and write
) – и при верной организации кода (strided access to contiguous chunk of memory – bad!
) может ощутимо улучшить производительность. При организации своего ядра – помните – смежный доступ – в пределах элементов одной строки памяти, работа с элементами столбца – это уже не так эффективно. Хотите больше деталей? мне понравилась вот эта pdf – или гуглите на предмет “memory coalescing techniques
“. Лидирующие позиции в номинации “узкое место” занимает другая операция с памятью – копирование данных из памяти хоста в гпу
. Копирование происходит не абы как, а из специально выделенной драйвером и системой области памяти: при запросе на копирование данных – система сначала копирует туда эти данные, а уже потом заливает их в GPU. Скорость транспортировки данных ограничена пропускной способностью шины PCI Express xN (где N число линий передачи данных) через которые современные видеокарты общаются с хостом. Однако, лишнее копирование медленной памяти на хосте – это порою неоправданные издержки. Выход – использовать так называемую pinned memory
– специальным образом помеченную область памяти, так что операционная система не имеет возможности выполнять с ней какие либо операции (например – выгрузить в свап/переместить по своему усмотрению и т.п.). Передача данных с хоста на видеокарту осуществляется без участия операционной системы – асинхронно, через DMA
(direct memory access). И, на последок, еще немного про память. Разделяемая память на мультипроцессоре обычно организована в виде банков памяти содержащих 32 битные слова – данные. Число банков по доброй традиции варьируется от одного поколения GPU к другому – 16/32 Если каждый поток обращается за данными в отдельный банк – все хорошо. Иначе получается несколько запросов на чтение/запись к одному банку и мы получаем – конфликт (shared memory bank conflict
). Такие конфликтные обращения сериализуются и соответственно выполняются последовательно, а не параллельно. Если к одному банку обращаются все потоки – используется “широковещательный” ответ (broadcast
) и конфликта нет. Существует несколько способов эффективно бороться с конфликтами доступа, мне понравилось описание основных методик по избавлению от конфликтов доступа к банкам памяти
– . Как сделать математические операции еще быстрее? Помнить что:
Для разработчиков CUDA имеет смысл обратить пристальное внимание на концепцию cuda stream,
позволяющих запускать сразу несколько функций-ядер на одному устройстве или совмещать асинхронное копирование данных с хоста на устройство во время выполнения функций. OpenCL, пока, такого функционала не предоставляет 🙁 Утиль для профилирования:
NVifia Visual Profiler – интересная утилитка, анализирует ядра как CUDA так и OpenCL. P. S. В качестве более пространного руководства по оптимизации, могу порекомендовать гуглить всевозможные best practices guide
для OpenCL и CUDA.
Альтернативы вычислений на графическом процессоре в.NET
. Чтобы приостановить процесс, кнопаем
При установленной галке Use Maximum Render Quality теперь нажимаем на кнопку: Queue.
- Изменение четкости (от высокой к стандартной и наоборот).
- Фильтр временного кода.
- Преобразования формата пикселей.
- Расперемежение.
Если визуализируется проект Premiere Pro, в AME используются установки визуализации с GPU, заданные для этого проекта. При этом будут использованы все возможности визуализации с GPU, реализованные в Premiere Pro. Для визуализации проектов AME используется ограниченный набор возможностей визуализации с GPU.
Если последовательность визуализируется с использованием оригинальной поддержки, применяется настройка GPU из AME, настройка проекта игнорируется. В этом случае все возможности визуализации с GPU Premiere Pro используются напрямую в AME.
Если проект содержит VST сторонних производителей, используется настройка GPU проекта. Последовательность кодируется с помощью PProHeadless, как и в более ранних версиях AME. Если флажок Enable Native Premiere Pro Sequence Import (Разрешить импорт исходной последовательности Premiere Pro) снят, всегда используется PProHeadless и настройка GPU.1. Майнинг на видеокарте – легкие деньги или неоправданные расходы
2. Как майнить криптовалюту с помощью видеокарты – пошаговая инструкция
Шаг 1.
Выбираем пул
Шаг 2.
Устанавливаем и настраиваем программу
Шаг 3.
Регистрируем кошелек
Шаг 4.
Запускаем майнинг и следим за статистикой
Шаг 5.
Выводим криптовалюту
– лучший в Рунете ресурс такого плана. Этот мониторинг сравнивает показатели более 300 обменных пунктов и находит лучшие котировки по интересующим вас валютным парам. Более того, сервис указывает резервы криптовалюты в кассе. В списках мониторинга – только проверенные и надёжные обменные сервисы.3. На что обращать внимание при выборе видеокарты для майнинга
1) Мощность
2) Энергопотребление
3) Охлаждение
Качественное охлаждение процессора - непременное условие успешного майнинга4) Возможность разгона
4. Где купить видеокарту для майнинга – обзор ТОП-3 магазинов
1) TopComputer
Московский гипермаркет, специализирующийся на компьютерной и бытовой технике. Работает на рынке больше 14 лет, поставляет товары со всего мира почти по ценам производителей. Работает служба оперативной доставки, бесплатная для москвичей.2) Мybitcoinshop
Специализированный магазин, торгующий исключительно товарами для майнинга
. Здесь вы найдёте всё для постройки домашней фермы – видеокарты нужной конфигурации, блоки питания, переходники и даже ASIC-майнеры (для майнеров нового поколения). Есть платная доставка и самовывоз со склада в Москве.3) Ship Shop America
Покупка и доставка товаров из США. Посредническая компания для тех, кому нужны действительно эксклюзивные и самые передовые товары для майнинга.5. Как увеличить доход от майнинга на видеокарте – 3 полезных совета
Совет 2.
Используйте калькулятор майнинга для выбора оптимального оборудования
Использование ресурсов GPU на полную – GPU Occupancy
http://docs.nvidia.com/cuda/cuda-c-best-practices-guide/#calculating-occupancy