Универсальные вычисления на графических процессорах

редактировать

Универсальные вычисления на графических процессорах (GPGPU, редко GPGP ) - это использование графического процессора (GPU), который обычно выполняет вычисления только для компьютерной графики, для выполнения вычислений в приложениях, которые традиционно обрабатываются центральный процессор (CPU). Использование нескольких видеокарт в одном компьютере или большого количества графических чипов дополнительно распараллеливает и без того параллельный характер обработки графики. Кроме того, даже одна структура GPU-CPU обеспечивает преимущества, которые несколько процессоров сами по себе не могут предложить из-за специализации каждого чипа.

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

Конвейеры GPGPU были разработаны в начале 21 века для обработки графики (например, для лучше шейдеры ). Было обнаружено, что эти конвейеры хорошо удовлетворяют потребности научных вычислений, и с тех пор были разработаны в этом направлении.

Содержание
  • 1 История
  • 2 Реализации
    • 2.1 Мобильные компьютеры
  • 3 Поддержка оборудования
    • 3.1 Целые числа
    • 3.2 Числа с плавающей запятой
    • 3.3 Векторизация
  • 4 GPU по сравнению с CPU
    • 4.1 Кеши
    • 4.2 Файл регистров
    • 4.3 Энергетическая эффективность
  • 5 Потоковая обработка
    • 5.1 Концепции программирования GPU
      • 5.1.1 Вычислительные ресурсы
      • 5.1.2 Текстуры в виде потока
      • 5.1.3 Ядра
      • 5.1.4 Управление потоком
    • 5.2 Методы GPU
      • 5.2.1 Карта
      • 5.2.2 Уменьшение
      • 5.2.3 Фильтрация потоков
      • 5.2.4 Сканирование
      • 5.2.5 Разброс
      • 5.2.6 Собрать
      • 5.2.7 Сортировка
      • 5.2.8 Поиск
      • 5.2.9 Структуры данных
  • 6 Приложения
    • 6.1 Биоинформатика
      • 6.1.1 Молекулярная динамика
  • 7 См. Также
  • 8 Ссылки
  • 9 Внешние ссылки
История

В принципе, любая произвольная логическая функция, включая функции сложения, умножение и другие математические функции могут быть построены из функционально полного набора логических операторов. В 1987 году Game of Life Конвея стала одним из первых примеров вычислений общего назначения с использованием раннего потокового процессора, называемого блиттером, для вызова специальной последовательности логические операции с битовыми векторами.

Вычисления общего назначения на графических процессорах стали более практичными и популярными примерно после 2001 года, с появлением как программируемых шейдеров, так и плавающих Поддержка пункта на графических процессорах. Примечательно, что проблемы, связанные с матрицей и / или векторами, особенно двух-, трех- или четырехмерными векторами, было легко преобразовать в графический процессор, который работает с собственной скоростью и поддержкой. по этим типам. Эксперименты научного компьютерного сообщества с новым оборудованием начались с процедуры матричного умножения (2001); одной из первых общепринятых научных программ, которые работали на GPU быстрее, чем на CPU, была реализация LU-факторизации (2005).

Эти ранние попытки использовать GPU в качестве процессоров общего назначения потребовали переформулирования вычислительных проблемы с графическими примитивами, которые поддерживаются двумя основными API-интерфейсами для графических процессоров, OpenGL и DirectX. Этот громоздкий перевод был устранен с появлением языков программирования общего назначения и API, таких как Sh /RapidMind, Brook и Accelerator.

За ними последовала Nvidia CUDA, который позволял программистам игнорировать лежащие в основе графические концепции в пользу более общих концепций высокопроизводительных вычислений. Новые предложения, не зависящие от производителей оборудования, включают DirectCompute от Microsoft и OpenCL от Apple / Khronos Group. Это означает, что современные конвейеры GPGPU могут использовать скорость графического процессора, не требуя полного и явного преобразования данных в графическую форму.

Реализации

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

По состоянию на 2016 год OpenCL является доминирующим открытым языком вычислений на GPU общего назначения и представляет собой открытый стандарт, определенный Khronos Group. OpenCL предоставляет кроссплатформенную платформу GPGPU, которая дополнительно поддерживает параллельное вычисление данных на процессорах. OpenCL активно поддерживается на платформах Intel, AMD, Nvidia и ARM. Группа Khronos также стандартизировала и реализовала SYCL, модель программирования более высокого уровня для OpenCL в качестве встраиваемого языка с единым исходным кодом для конкретной предметной области, основанного на чистом C ++ 11.

Доминирующая проприетарная структура - Nvidia CUDA. Nvidia запустила CUDA в 2006 году, комплект разработки программного обеспечения (SDK) и интерфейс прикладного программирования (API), который позволяет использовать язык программирования C для кодирования алгоритмов для выполнения на графических процессорах серии GeForce 8 и более поздних.

Стандарты программирования для параллельных вычислений включают OpenCL (независимый от производителя), OpenACC и OpenHMPP. Марк Харрис, основатель GPGPU.org, ввел термин GPGPU.

Xcelerit SDK, созданный компанией, разработан для ускорения больших существующих кодовых баз C ++ или C # на GPU с минимальными усилиями. Он обеспечивает упрощенную модель программирования, автоматизирует распараллеливание, управляет устройствами и памятью и компилируется в двоичные файлы CUDA. Кроме того, из одного и того же исходного кода можно использовать многоядерные ЦП и другие ускорители.

OpenVIDIA был разработан в Университете Торонто в период с 2003 по 2005 год в сотрудничестве с Nvidia.

Altimesh Hybridizer, созданный путем компиляции Common Intermediate Language в CUDA двоичные файлы. Он поддерживает универсальные и виртуальные функции. Отладка и профилирование интегрированы с Visual Studio и Nsight. Он доступен как расширение Visual Studio на Visual Studio Marketplace.

Microsoft представила API вычислений DirectCompute GPU, выпущенный с DirectX 11 API.

Графический процессор Alea, созданный QuantAlea, представляет собственные вычислительные возможности графического процессора для языков Microsoft.NET F # и C #. Alea GPU также предоставляет упрощенную модель программирования GPU, основанную на параллельном и параллельном агрегировании GPU с использованием делегатов и автоматического управления памятью.

MATLAB поддерживает ускорение GPGPU с помощью Parallel Computing Toolbox и MATLAB Distributed Computing Server, а также сторонних производителей. такие пакеты, как Jacket.

Обработка GPGPU также используется для моделирования физики Ньютона с помощью физических движков, а коммерческие реализации включают Havok Physics, FX и PhysX, которые обычно используются для компьютеров и видеоигр.

Close to Metal, теперь называемых Stream, это AMD ' s Технология GPGPU для графических процессоров ATI Radeon.

C ++ Accelerated Massive Parallelism (C ++ AMP ) - это библиотека, которая ускоряет выполнение кода C ++ за счет использования аппаратного обеспечения параллельного обмена данными на графических процессорах.

Мобильные компьютеры

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

Google Android 4.2 с запущенным кодом RenderScript на графическом процессоре мобильного устройства. Apple представила проприетарный Metal API для iOS приложения, способные выполнять произвольный код через вычислительные шейдеры графического процессора Apple.

Поддержка оборудования

Компьютерные видеокарты производятся различными поставщиками, такими как Nvidia, AMD и ATI. Карты таких производителей различаются реализацией поддержки форматов данных, таких как целочисленные и форматы с плавающей запятой (32-битные и 64-битные). Microsoft представила стандарт Shader Model, чтобы упорядочить различные функции графических карт по простому номеру версии Shader Model (1.0, 2.0, 3.0 и т. Д.).

Целые числа

Видеокарты до DirectX 9 поддерживали только палитру или целочисленные типы цветов. Доступны различные форматы, каждый из которых содержит красный элемент, зеленый элемент и синий элемент. Иногда добавляется другое альфа-значение, используемое для прозрачности. Общие форматы:

  • 8 бит на пиксель - иногда режим палитры, где каждое значение является индексом в таблице с реальным значением цвета, указанным в одном из других форматов. Иногда три бита для красного, три бита для зеленого и два бита для синего.
  • 16 бит на пиксель - Обычно биты выделяются как пять бит для красного, шесть бит для зеленого и пять бит для синего.
  • 24 бита на пиксель - есть восемь бит для каждого из красного, зеленого и синего.
  • 32 бита на пиксель - есть восемь бит для каждого из красного, зеленого, синего и альфа.

числа с плавающей запятой

Для ранних фиксированных функций или графики с ограниченной программируемостью (т. Е. Вплоть до графических процессоров, совместимых с DirectX 8.1), этого было достаточно, потому что это также представление, используемое в дисплеях. Важно отметить, что это представление имеет определенные ограничения. Учитывая достаточную мощность обработки графики, даже программисты графики хотели бы использовать более качественные форматы, такие как форматы данных с плавающей запятой, для получения таких эффектов, как формирование изображений с расширенным динамическим диапазоном. Многие приложения GPGPU требуют точности с плавающей запятой, которые поставляются с видеокартами, соответствующими спецификации DirectX 9.

DirectX 9 Shader Model 2.x предлагал поддержку двух типов точности: полной и частичной. Полная поддержка точности могла быть FP32 или FP24 (32- или 24-битная с плавающей запятой на компонент) или выше, в то время как частичная точность была FP16. Графические процессоры серии ATI Radeon R300 поддерживали точность FP24 только в конвейере программируемых фрагментов (хотя FP32 поддерживался в вершинных процессорах), в то время как Nvidia Серия NV30 поддерживает как FP16, так и FP32; другие поставщики, такие как S3 Graphics и XGI, поддерживали смесь форматов вплоть до FP24.

Реализации с плавающей запятой на графических процессорах Nvidia в основном соответствуют IEEE ; однако это верно не для всех поставщиков. Это имеет последствия для правильности, которые считаются важными для некоторых научных приложений. Хотя 64-битные значения с плавающей запятой (с плавающей запятой двойной точности) обычно доступны в процессорах, они не всегда поддерживаются графическими процессорами. Некоторые архитектуры графических процессоров жертвуют соответствием IEEE, в то время как другим не хватает двойной точности. Были предприняты попытки эмулировать значения с плавающей запятой двойной точности на графических процессорах; однако компромисс в скорости сводит на нет какие-либо преимущества, связанные с переносом вычислений на GPU в первую очередь.

Векторизация

Большинство операций на GPU работают в векторизованном виде: одна операция может выполняться на до четырех значений одновременно. Например, если один цвет должен быть модулирован другим цветом , графический процессор может создать результирующий цвет за одну операцию. Эта функциональность полезна в графике, потому что почти каждый базовый тип данных является вектором (2-, 3- или 4-мерным). Примеры включают вершины, цвета, векторы нормалей и координаты текстуры. Многие другие приложения могут найти здесь хорошее применение, и из-за их более высокой производительности векторные инструкции, называемые одиночной инструкцией, множеством данных (SIMD ), уже давно доступны для процессоров.

GPU. vs. CPU

Первоначально данные просто передавались в одностороннем порядке от центрального процессора (CPU) к графическому процессору (GPU), а затем к устройство отображения. Однако со временем для графических процессоров стало полезно хранить сначала простые, а затем сложные структуры данных, которые затем передавались обратно в ЦП, который анализировал изображение, или набор научных данных, представленных как 2D- или 3D-формат, который видеокарта может понять. Поскольку графический процессор имеет доступ к каждой операции отрисовки, он может быстро анализировать данные в этих формах, тогда как центральный процессор должен опрашивать каждый пиксель или элемент данных намного медленнее, поскольку скорость доступа между процессором и его большим пулом случайных -доступ к памяти (или, что еще хуже, к жесткому диску ) работает медленнее, чем графические процессоры и видеокарты, которые обычно содержат меньшие объемы более дорогой памяти, доступ к которой осуществляется намного быстрее. Передача части набора данных для активного анализа в эту память графического процессора в виде текстур или других легко читаемых форм графического процессора приводит к увеличению скорости. Отличительной особенностью конструкции GPGPU является способность передавать информацию двунаправленно обратно от GPU к CPU; обычно пропускная способность данных в обоих направлениях идеально высока, что приводит к влиянию множителя на скорость конкретного часто используемого алгоритма . Конвейеры GPGPU могут повысить эффективность особенно больших наборов данных и / или данных, содержащих 2D или 3D изображения. Он используется в сложных графических конвейерах, а также в научных вычислениях ; в большей степени в областях с большими наборами данных, таких как картирование генома, или где полезен двух- или трехмерный анализ - особенно в настоящее время анализ биомолекул, исследование белков, и др. сложная органическая химия. Такие конвейеры могут также значительно повысить эффективность в обработке изображений и компьютерном зрении, среди других областей; а также параллельная обработка в целом. Некоторые очень сильно оптимизированные конвейеры дали увеличение скорости в несколько сотен раз по сравнению с исходным конвейером на базе ЦП при выполнении одной часто используемой задачи.

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

GPGPU - это принципиально концепция программного обеспечения, а не аппаратного обеспечения; это разновидность алгоритма , а не часть оборудования. Однако специализированное оборудование может еще больше повысить эффективность конвейеров GPGPU, которые традиционно выполняют относительно мало алгоритмов с очень большими объемами данных. Таким образом, массово распараллеленные задачи уровня гигантских данных могут быть распараллелены еще больше с помощью специализированных настроек, таких как вычисления в стойке (много похожих, специализированных машин, встроенных в стойку), что добавляет третий уровень - многие вычислительные блоки, каждое из которых использует много процессоров для соответствия ко многим графическим процессорам. Некоторые биткойн «майнеры» использовали такие установки для обработки больших объемов.

Кеши

Исторически ЦП использовали аппаратные кеши, но более ранние графические процессоры предоставляли только программно управляемую локальную память. Однако, поскольку графические процессоры все чаще используются для приложений общего назначения, современные графические процессоры разрабатываются с аппаратно управляемыми многоуровневыми кешами, которые помогли графическим процессорам перейти к массовым вычислениям. Например, графические процессоры с архитектурой GeForce 200 серии GT200 не имели кеш-памяти второго уровня, графический процессор Fermi имеет кеш последнего уровня 768 КиБ, графический процессор Kepler имеет 1,5 Кэш последнего уровня в MiB, графический процессор Maxwell имеет кеш последнего уровня 2 МБ, а графический процессор Pascal имеет кэш последнего уровня 4 МБ.

Файл регистров

Графические процессоры имеют очень большие файлы регистров, которые позволяют им уменьшить задержку переключения контекста. Размер файла регистров также увеличивается в зависимости от поколения графических процессоров, например, общий размер файла регистров на графических процессорах Maxwell (GM200), Pascal и Volta составляет 6 МБ, 14 МБ и 20 МБ соответственно. Для сравнения, размер файла регистров на ЦП невелик, обычно десятки или сотни килобайт.

Энергоэффективность

Высокая производительность графических процессоров достигается за счет высокого энергопотребления, которое при полной нагрузке фактически равно мощности всей остальной системы ПК вместе взятой. Максимальное энергопотребление графического процессора серии Pascal (Tesla P100) было указано на уровне 250 Вт. В нескольких исследовательских проектах сравнивалась энергоэффективность графических процессоров с энергоэффективностью процессоров и ПЛИС.

Потоковая обработка

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

Следующее обсуждение, касающееся вершин, фрагментов и текстур, касается в основном устаревшей модели программирования GPGPU, где графические API (OpenGL или DirectX ) использовались для выполнения общих -целевое вычисление. С введением универсальных вычислительных API-интерфейсов общего назначения CUDA (Nvidia, 2007) и OpenCL (независимый от производителя, 2008 г.) в новых кодах GPGPU больше нет необходимости сопоставлять вычисление графических примитивов. Природа потоковой обработки графических процессоров остается в силе независимо от используемых API. (См., Например,)

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

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

Арифметическая интенсивность определяется как количество операций, выполняемых на одно слово переданной памяти. Для приложений GPGPU важно иметь высокую арифметическую интенсивность, иначе задержка доступа к памяти ограничит ускорение вычислений.

Идеальные приложения GPGPU имеют большие наборы данных, высокий уровень параллелизма и минимальную зависимость между элементами данных.

Концепции программирования GPU

Вычислительные ресурсы

На GPU доступны различные вычислительные ресурсы:

  • Программируемые процессоры - вершинные, примитивные, фрагментные и в основном вычислительные конвейеры позволяет программисту выполнять ядро ​​с потоками данных
  • Растеризатор - создает фрагменты и интерполирует константы для каждой вершины, такие как координаты текстуры и цвет
  • Блок текстуры - интерфейс памяти только для чтения
  • Framebuffer - интерфейс памяти только для записи

Фактически, программа может заменить текстуру только для записи для вывода вместо фреймбуфера. Это делается либо с помощью Render to Texture (RTT), Render-To-Backbuffer-Copy-To-Texture (RTBCTT), либо более поздней потоковой передачи.

Текстуры как поток

Самая распространенная форма потока, принимаемого в GPGPU, - это 2D-сетка, потому что она естественным образом соответствует модели рендеринга, встроенной в графические процессоры. Многие вычисления естественно отображаются в сетки: матричная алгебра, обработка изображений, физическое моделирование и т. Д.

Поскольку текстуры используются как память, поиск текстуры затем используется как чтение памяти. Из-за этого некоторые операции могут выполняться автоматически графическим процессором.

Ядра

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

// Сетки ввода и вывода имеют 10000 x 10000 или 100 миллионов элементов. void transform_10k_by_10k_grid (float in [10000] [10000], float out [10000] [10000]) {for (int x = 0; x < 10000; x++) { for (int y = 0; y < 10000; y++) { // The next line is executed 100 million times out[x][y] = do_some_hard_work(in[x][y]); } } }

На графическом процессоре программист указывает только тело цикла как ядро ​​и какие данные следует перебирать, вызывая обработку геометрии.

Управление потоком

В последовательном коде можно управлять потоком программы с помощью операторов if-then-else и различных форм циклов. Такие структуры управления потоком только недавно были добавлены в графические процессоры. Условная запись могла выполняться с использованием правильно созданной серии арифметических / битовых операций, но циклы и условное ветвление были невозможны.

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

методы графического процессора

M ap

Операция map просто применяет данную функцию (ядро) к каждому элементу в потоке. Простой пример - умножение каждого значения в потоке на константу (увеличение яркости изображения). Операцию карты просто реализовать на GPU. Программист генерирует фрагмент для каждого пикселя на экране и применяет программу фрагмента к каждому пикселю. Поток результатов того же размера сохраняется в выходном буфере.

Уменьшить

Некоторые вычисления требуют вычисления меньшего потока (возможно, потока только из одного элемента) из большего потока. Это называется уменьшением потока. Как правило, уменьшение может выполняться в несколько этапов. Результаты предыдущего шага используются в качестве входных данных для текущего шага, а диапазон, в котором применяется операция, сокращается до тех пор, пока не останется только один элемент потока.

Фильтрация потоков

Фильтрация потоков по существу является неравномерным сокращением. Фильтрация включает удаление элементов из потока на основе некоторых критериев.

Сканирование

Операция сканирования, также называемая суммой параллельных префиксов, принимает вектор (поток) элементов данных и (произвольную) ассоциативную двоичную функцию '+' с элементом идентичности 'i'. Если входом является [a0, a1, a2, a3,...], исключительное сканирование дает выход [i, a0, a0 + a1, a0 + a1 + a2,...], а инклюзивное сканирование дает output [a0, a0 + a1, a0 + a1 + a2, a0 + a1 + a2 + a3,...] и не требует наличия идентификатора. Хотя на первый взгляд операция может показаться изначально последовательной, эффективные алгоритмы параллельного сканирования возможны и были реализованы на графических процессорах. Операция сканирования используется, например, в быстрой сортировке и умножении разреженной матрицы на вектор.

Scatter

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

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

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

Gather

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

Сортировка

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

Поиск

Операция поиска позволяет программисту найти заданный элемент в потоке или, возможно, найти соседей указанного элемента. Графический процессор не используется для ускорения поиска отдельного элемента, а вместо этого используется для параллельного выполнения нескольких поисков. В основном используется метод поиска двоичный поиск по отсортированным элементам.

Структуры данных

На GPU могут быть представлены различные структуры данных:

Приложения

Ниже приведены некоторые из областей, в которых графические процессоры использовались для вычислений общего назначения:

Биоинформатика

Использование GPGPU в биоинформатике:

ПриложениеОписаниеПоддерживаемые функцииОжидаемое ускорение †GPU ‡Многофункциональный Поддержка графического процессораСостояние выпуска
BarraCUDAДНК, включая эпигенетику, программное обеспечение для картирования последовательностейВыравнивание считываний коротких секвенирований6–10xT 2075, 2090, K10, K20, K20XДаСейчас доступно, версия 0.7.107f
CUDASW++Программное обеспечение с открытым исходным кодом для Smith- Поиск в базе данных белков Waterman на графических процессорахПараллельный поиск в базе данных Smith-Waterman10–50xT 2075, 2090, K10, K20, K20XДаДоступен сейчас, версия 2.0.8
CUSHAWПараллельный выравниватель с коротким считываниемПараллельный, точный выравниватель с длинным считыванием - выравнивание с зазором для больших геномов10xT 2075, 2090, K10, K20, K20XДаСейчас доступно, версия 1.0.40
GPU-BLASTLocal search with fast k-tuple heuristicProtein alignment according to blastp, multi CPU threads3–4xT 2075, 2090, K10, K20, K20XSingle onlyAvailable now, version 2.2. 26
GPU-HMMERParallelized local and global search with profile hidden Markov modelsParallel local and global search of hidden Markov models60–100xT 2075, 2090, K10, K20, K20XYesAvailable now, version 2.3.2
mCUDA-MEMEUltrafast scalable motif discovery algorithm based on MEMEScalable motif discovery algorithm based on MEME4–10xT 2075, 2090, K10, K20, K20XYesAvailable now, version 3.0.12
SeqNFindA GPU accelerated sequence analysis toolsetReference assembly, blast, Smith–Waterman, hmm, de novo assembly400xT 2075, 2090, K10, K20, K20XYesAvailable now
UGENEOpensource Smith–Waterman for SSE/CUDA, suffix array based repeats finder and dotplotFast short read alignment6–8xT 2075, 2090, K10, K20, K20XYesAvailable now, version 1.11
WideLMFits numerous linear models to a fixed design and responseParallel linear regression on multiple similarly-shaped models150xT 2075, 2090, K10, K20, K20XYesAvailable now, version 0.1-1

Molecular dynamics

ApplicationDescriptionSupported featuresExpected speed-up†GPU‡Multi-GPU supportRelease status
Abalone Models molecular dynamics of biopolymers for simulations of proteins, DNA and ligandsExplicit and implicit solvent, hybrid Monte Carlo 4–120xT 2075, 2090, K10, K20, K20XSingle onlyAvailable now, version 1.8.88
ACEMDGPU simulation of molecular mechanics force fields, implicit and explicit solventWritten for use on GPUs160 ns/day GPU version onlyT 2075, 2090, K10, K20, K20XYesAvailable now
AMBERSuite of programs to simu late molecular dynamics on biomoleculePMEMD: explicit and implicit solvent89.44 ns/day JAC NVET 2075, 2090, K10, K20, K20XYesAvailable now, version 12 + bugfix9
DL-POLYSimulate macromolecules, polymers, ionic systems, etc. on a distributed memory parallel computerTwo-body forces, link-cell pairs, Ewald SPME forces, Shake VV4xT 2075, 2090, K10, K20, K20XYesAvailable now, version 4.0 source only
CHARMM MD package to simulate molecular dynamics on biomolecule.Implicit (5x), explicit (2x) solvent via OpenMMTBDT 2075, 2090, K10, K20, K20XYesIn development Q4/12
GROMACS Simulate biochemical molecules with complex bond interactionsImplicit (5x), explicit (2x) solvent165 ns/Day DHFRT 2075, 2090, K10, K20, K20XSingle onlyAvailable now, version 4.6 in Q4/12
HOOMD-BlueP article dynamics package written grounds up for GPUsWritten for GPUs2xT 2075, 2090, K10, K20, K20XYesAvailable now
LAMMPS Classical molecular dynamics packageLennard-Jones, Morse, Buckingham, CHARMM, tabulated, course grain SDK, anisotropic Gay-Bern, RE-squared, "hybrid" combinations3–18xT 2075, 2090, K10, K20, K20XYesAvailable now
NAMD Designed for high-performance simulation of large molecular systems100M atom capable6.44 ns/days STMV 585x 2050sT 2075, 2090, K10, K20, K20XYesAvailable now, version 2.9
OpenMMLibrary and application for molecular dynamics for HPC with GPUsImplicit and explicit solvent, custom forcesImplicit: 127–213 ns/day; Explicit: 18–55 ns/day DHFRT 2075, 2090, K10, K20, K20XYesAvailable now, версия 4.1.1

† Ожидаемое ускорение во многом зависит от конфигурации системы. Производительность графического процессора по сравнению с многоядерным процессором x86. Производительность графического процессора оценивается на основе поддерживаемых функций графического процессора и может быть сравнением производительности ядра с ядром. Подробные сведения об используемой конфигурации см. На веб-сайте приложения. Ускорение согласно внутреннему тестированию Nvidia или документации независимых поставщиков программного обеспечения.

‡ Q = Quadro GPU, T = Tesla GPU. Nvidia рекомендовала графические процессоры для этого приложения. Обратитесь к разработчику или независимому поставщику программного обеспечения для получения информации о сертификации.

См. Также
Ссылки
Внешние ссылки
Последняя правка сделана 2021-05-21 14:25:14
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте