Например, у nVidia есть CUBLAS, который обещает ускорение в 7-14 раз. Наивно, это далеко не теоретическая пропускная способность любой из видеокарт nVidia. Каковы проблемы в ускорении линейной алгебры на графических процессорах, и есть ли уже доступные более быстрые линейные алгебраические маршруты?
Ответы:
Я не могу ответить на вторую половину вашего вопроса относительно других реализаций, но я могу дать некоторое представление о проблемах. Для справки, я лично использовал ViennaCL на nVidia GTX 560 Ti с 2 ГБ памяти для моих тестов.
По сравнению с последовательным кодом на i5 среднего уровня, я видел ускорения для плотного умножения матриц примерно в 40 раз. Для таких операций, как векторное скалярное умножение, я видел увеличение до 1000x. Однако 800-килограммовая горилла в комнате - это пропускная способность памяти. Для большинства коммерческих графических процессоров вы будете использовать что-то вроде PCIe, что ограничивает пропускную способность до 6 ГБ / с. В моем случае, хотя вычисления были в 40 раз быстрее, каждая из трех копий матрицы (две на графический процессор и одна задняя) занимала примерно столько же времени, сколько просто выполняла вычисления на процессоре.
Тогда проблема с любой общей библиотекой для линейной алгебры GPU состоит в том, что они не могут по-настоящему повторно использовать объекты в GPU, потому что они не знают, что вы собираетесь с ними делать. Таким образом, каждый вызов вычислительного ядра, вероятно, потребует копирования в графический процессор, а затем копирования результата обратно. Это съест большую часть прибыли.
Если вы можете повторно использовать объекты, такие как матрицы, то вы могли бы написать алгоритмы более высокого уровня, чтобы избежать как можно большего управления памятью, но библиотеке будет трудно сделать это эффективно.
Я надеюсь, что это поможет, и я уверен, что здесь есть другие люди, которые гораздо более опытны в этом, но это те впечатления и впечатления, которые я получил во время своего короткого знакомства с вычислениями на GPU.
Позвольте мне сосредоточиться только на CUDA и BLAS.
Ускорение по сравнению с реализацией хост-системы BLAS не является хорошим показателем для оценки пропускной способности, поскольку оно зависит от слишком многих факторов, хотя я согласен с тем, что ускорение обычно является тем, что беспокоит.
Если вы посмотрите на тесты, опубликованные NVIDIA, и примите во внимание, что Tesla M2090 имеет пиковую производительность 1331 Гигафлопс (одинарная точность) и 665 Гигафлопс (двойная точность), вы увидите, что для SGEMM и DGEMM мы имеем измеренную пропускную способность почти на уровне 60% от теоретического, что довольно неплохо.
Что касается устойчивой пропускной способности с плавающей запятой, я думаю, что флопсы должны вычисляться без учета данных и времени передачи результатов, и это затрудняет сравнение ускорений. Кроме того, вы должны принять во внимание размер матрицы, так как лучшая производительность для больших матриц.
Итог: ускорение реального приложения может сильно отличаться от пиковой измеренной производительности в процедурах линейной алгебры, так как вы должны учитывать инициализацию GPU, время передачи данных и т. Д. И т. Д. И т. Д.
Поэтому я не буду отвечать на ваш вопрос о самой быстрой библиотеке, так как вопрос не имеет смысла, если не определены точная метрика и проблема. Все это говорит, я думаю, что cuBLAS и MAGMA являются очень хорошей отправной точкой.