Математические библиотеки для OpenCL?

Я ищу информацию от всех, кто пытался использовать OpenCL в своем научном коде. Кто-нибудь пробовал (недавно) ViennaCL ? Если да, то как это сравнить с острием ?

Как насчет OCLTools ? Это соответствует обещанию? Если это так, будет ли возможным начать писать математические ядра в OpenCL?

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

Что касается OpenCL в научном коде: OpenCL предназначен для низкоуровневого API, поэтому очень важно каким-то образом обернуть эту функциональность, чтобы достичь разумной производительности. Более того, как только задействовано несколько вычислительных ядер, код может ОЧЕНЬ испачкаться, если ядро ​​и дескрипторы памяти OpenCL необходимо интенсивно передавать внутри приложения. Я не знаю OCLTools, поэтому не могу сказать, полезны ли они в этом отношении.

Что касается ViennaCL: я глава ViennaCL, поэтому я недавно работал с библиотекой. :-) Далее я рассмотрю запрос на сравнение с cusp в несколько большем объеме, а именно: ViennaCL и математические библиотеки cusp на основе CUDA и MAGMA . Рассматривается только нынешнее состояние, хотя в настоящее время происходит много изменений (по крайней мере, с нашей стороны).

Функциональность . MAGMA предоставляет BLAS-функциональность для плотных матриц через обычные интерфейсы функций. Большая часть этой функциональности также предоставляется с ViennaCL 1.2.0 с использованием перегрузок операторов и другого синтаксического сахара.

Те же три итерационных решателя (CG, BiCGStab, GMRES) предоставляются с Cusp и ViennaCL. Набор предварительных кондиционеров заметно отличается: Cusp предоставляет диагональные, SA-AMG и различные предварительные кондиционеры Bridson. ViennaCL предлагает неполные факторизации LU, диагональные прекондиционеры, а в последнее время различные ароматы AMG и редкие приближенные обратные прекондиционеры. Насколько мне известно, все предварительные кондиционеры для каспов работают исключительно на GPU, в то время как ViennaCL полагается, в частности, на этапе установки на вычисления на базе процессора. В настоящее время число форматов разреженных матриц в CUSP больше: COO, CSR, DIA, ELL, HYB, в то время как ViennaCL 1.2.0 предоставляет COO и CSR.

В ViennaCL есть ряд дополнительных функций, которые не входят ни в MAGMA, ни в cusp: типы структурированных матриц (Circulant, Hankel и т. Д.), Быстрое преобразование Фурье, алгоритмы переупорядочения (например, Cuthill-McKee) и обертки для линейной алгебры. типы из других библиотек.

Спектакль. Большой набор функций и аппаратной поддержки в ViennaCL обычно достигается за счет более низкой производительности по сравнению с реализациями на основе CUDA. Это также отчасти связано с тем, что CUDA адаптирована к архитектуре продуктов NVIDIA, а OpenCL представляет в некотором смысле разумный компромисс между различными многоядерными архитектурами.

В целом, ViennaCL в настоящее время работает медленнее, чем MAGMA, особенно на уровне 3. BLAS. Причиной является различие в фокусе ViennaCL (разреженная вместо плотной линейной алгебры) и, следовательно, более высокая степень оптимизации в MAGMA. В частности, BLAS уровня 3 операции в настоящее время значительно быстрее в MAGMA.

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

Переносимость . Что касается переносимости аппаратного обеспечения, ViennaCL может использовать процессоры и графические процессоры всех основных производителей благодаря OpenCL. Напротив, Cusp и MAGMA полагаются на подходящий графический процессор NVIDIA.

ViennaCL предназначен только для заголовков, может быть скомпилирован на широком спектре компиляторов C ++ и должен быть связан только с библиотекой OpenCL, если требуется поддержка GPU. В принципе, универсальные алгоритмы в ViennaCL также могут использоваться без какой-либо связи OpenCL, в то время как cusp и MAGMA требуют компилятора NVIDIA для компиляции и библиотеки CUDA в целевой системе для выполнения. MAGMA также требует библиотеку BLAS, которая иногда может быть немного трудной для поиска или установки в новой системе.

API . MAGMA предоставляет функциональные интерфейсы в стиле BLAS для функциональности BLAS. Интерфейс C ++ cusp также использует некоторые функции из BLAS, но не перегружает операторы. Поскольку большинство интерфейсов в ViennaCL намеренно похожи на Boost.uBLAS и имеют синтаксический сахар, такой как перегрузки операторов, ViennaCL также предназначен для использования в качестве Boost.uBLAS. Таким образом, в дополнение к простому вызову предопределенного набора операций и алгоритмов наше намерение состоит в том, чтобы сделать переход от чисто процессорного исполнения к коду GPU как можно более простым, даже если нужно использовать нестандартные алгоритмы. В случае, если требуется выделенное ядро ​​OpenCL, есть также платформа для интеграции ваших собственных ядер OpenCL в ViennaCL. Таким образом, ViennaCL стремится гораздо больше квысокая производительность в том смысле, что время, необходимое для реализации новых алгоритмов на графическом процессоре, сводится к минимуму . Эта экономия может значительно перевесить любые потери производительности (если таковые имеются) по сравнению с каспом и MAGMA. (В теме о модульном тестировании также упоминалось, что время разработки кода является ценным ресурсом в науке.)

В моем сравнении, безусловно, есть ряд идеологических проблем (например, CUDA против OpenCL, BLAS-интерфейс против перегрузок операторов), но их обсуждение выходит за рамки первоначального вопроса.

OpenCL можно использовать, однако, отсутствует инфраструктура, например, важные зрелые стандартные математические библиотеки с настроенными де-факто стандартными компонентами линейной алгебры и в некоторой степени хорошие инструменты профилирования, хотя последняя проблема значительно улучшилась для графических процессоров. Это доступно в CUDA на сегодняшний день и может быть частью успеха Nvidia с этой моделью программирования. Тем не менее, OpenCL, кажется, догоняет (медленно).

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