Каждые полгода мы с друзьями я бенчмаркаю . В этот раз изучалась NVidia GTX280.
В чипе NVidia G200 появились операции с двойной точностью. Их производительность не феноменальна, но даже с учетом ввода-вывода данных в карту GTX280 обгоняет 4-ядерный 3-гигагерцовый Penryn. Если же рассматривать только скорость вычислений (что актуально, если задача позволяет спрятать затраты на ввод-вывод), то на двойной точности видеокарта быстрее CPU в 1.8 раза.
На одинарной точности разрыв видеокарты и CPU вырос: GTX280 обгоняет Core2Quad впятеро.
Понятно, что Core i7 разницу несколько сократит, но по тем бенчмаркам с плавающей точкой, что я видел (а видел я пока только Linpack, причем не факт что в оптимальном для i7 виде), рост в производительности i7 - процентов 20.
Всякие соображения про масштабируемость решения - в .
Каждые полгода мы с друзьями я бенчмаркаю вычисления на видеокартах. В этот раз изучалась NVidia GTX280.
SGEMM/DGEMM на видеокарте и CPU, серия 7: NVidia GTX280
В чипе NVidia G200 появились операции с двойной точностью. Их производительность не феноменальна, но даже с учетом ввода-вывода данных в карту GTX280 обгоняет 4-ядерный 3-гигагерцовый Penryn. Если же рассматривать только скорость вычислений (что актуально, если задача позволяет спрятать затраты на ввод-вывод), то на двойной точности видеокарта быстрее CPU в 1.8 раза.
На одинарной точности разрыв видеокарты и CPU вырос: GTX280 обгоняет Core2Quad впятеро.
Понятно, что Core i7 разницу несколько сократит, но по тем бенчмаркам с плавающей точкой, что я видел (а видел я пока только Linpack, причем не факт что в оптимальном для i7 виде), рост в производительности i7 - процентов 20.
Всякие соображения про масштабируемость решения - в самой статье.
Предыдущая моя статья на эту тему
была написана в феврале 2007 года, сразу после выхода первой публичной бета-версии
. Представители NVidia предупреждали,
что в бета-версии производительность не является оптимальной, к релизу она будет улучшена.
Все предыдущие
и более ранние мои упражнения были сделаны в качестве «подхода к снаряду», нужна
была baseline для более интересной задачи: вычислений общего назначения на видеокарте.
Эта тема в последние год-полтора (а особенно, в последние полгода) очень сильно нагрелась.
В то же время, в варианте от NVidia hardware и софт общедоступны, покупаешь видеокарту
и развлекаешься.
Приборы и материалы: NVidia CUDA и прочие
Настоящий общедоступный сдвиг произошел меньше месяца назад: 6 февраля 2006 г. вышла
вторая версия NVidia CUDA Toolkit, она же первая публичная (и первая более-менее работающая), она же
версия 0.8.
Эта версия без
подписания NDA, следовательно результаты тестов можно открыто публиковать.
Тема исследования, как обычно, умножение матриц. Задача очень простая алгоритмически, но
со своими особенностями. В силу простоты задачи, изучать особенности одно удовольствие.
Рассматривались три доступных умножителя матриц:
SGEMM в составе библиотеки CUBLAS.
Тестовый пример от NVidia, который очень подробно разобран в документации.
Использованная в предыдущем тестировании
библиотека численных методов
очевидно не является оптимизированной под процессоры AMD. Следовательно, нужно изучать альтернативы.
Альтернатив на сегодня видно три: это библиотека
от производителя процессора и две OpenSource библиотеки:
и
(Automatically Tuned Linear Algebra Software). Их и изучим.
Все бенчмарки были совершенно одинаковыми: заполнялись исходные матрицы (значениями от 0.0 до 1.0),
затем вызывалась функция sgemm (для single precision) или dgemm (double), время выполнения которой и измерялось.
Кроме Dual Opteron 275, в руки попал еще сервер Dual Xeon 5140, показалось полезным
сравнить две архитектуры.
Продолжаем умножать матрицы. Для начала смоделируем sgemm/dgemm:
C=alpha*A*B+beta*C
Нас интересует, естественно, самый быстрый способ из
, а вопрос заключается в разнице в скорости между float и double и разницы в скорости между простым кодом, написанным вручную, и библиотечной реализацией.
Осваиваю тут новую NUMA-архитектуру (пока не скажу какую, хотя многие уже в курсе). Хочется ее адекватно сравнивать с возможностями PC-CPU, т.е. опять гонять тесты. Начал с умножения матриц только на CPU.
Если оставить в стороне продвинутые алгоритмы и , ограничившись классическим подходом с умножением "строка на столбец", то умножение матриц вполне прямолинейно:
C(i,j) += A(i,k)+B(k,j) С другой стороны, входные матрицы могут быть транспонированы (одна или обе). При этом меняется pattern доступа к памяти, за счет чего ожидается некоторая разница в производительности.
Рассматривая , я ожидал получить разницу между «плохим» и «хорошим» паттерном в разы. Результат превзошел все ожидания, получилась разница на полтора порядка.