Прежде всего, я хочу поблагодарить Арона Ахмадию за то, что он указал мне на эту тему.
Что касается 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-интерфейс против перегрузок операторов), но их обсуждение выходит за рамки первоначального вопроса.