Численные методы

Читая форумы: NVidia 8800GTX гигафлопсы, консистентность памяти и прочие тараканы

lexa - 24/Фев/2007 12:32

Третий день читаю форумы про NVidia CUDA и радуюсь сырости технологии.

Для начала, объявленные 520 GFLOP/s оказались обычным маркетингом The 520 GFLOPS number quoted in the technical brief includes some graphics-specific operations that are not directly accessible from CUDA. С точки зрения вычислений, гигафлопсов там 345 (считая Multiply-Add за две операции). Тоже неплохо. В реальности будет разика в два поменьше, но тоже ничего.
Для сравнения, гипотетический (пока) 3Ghz 4-ядерный Core2Duo умеет 8 операций на такт * 4 ядра * 3Ghz = 96 GFLOP/s, а получить удастся процентов 70 от этого.
Отсутствие атомарных операций сильно усложняет жизнь. Предлагается в цикле писать значение в global memory, до тех пор пока не убедишься в успехе.
На текущий момент все вызовы - блокирующие. Т.е. нет возможности
- Запустить счет и одновременно заливать/выливать данные для следующего/предыдущего счета.
- Использовать две (и более) карт
Обещают починить.
The performance gain you'll get by using CUDA over the graphics API largely depends on how much your application can take advantage of the shared memory. В-общем, идея понятная, но полностью противоречит всей прошлой истории GPGPU. Может оно и хорошо

Умножение матриц, серия 4: NVidia G80, CUDA, CuBLAS и RapidMind

lexa - 22/Фев/2007 22:35

GPGPU или зачем все эти упражнения

Все предыдущие и более ранние мои упражнения были сделаны в качестве «подхода к снаряду», нужна была baseline для более интересной задачи: вычислений общего назначения на видеокарте.

Эта тема в последние год-полтора (а особенно, в последние полгода) очень сильно нагрелась. В то же время, в варианте от NVidia hardware и софт общедоступны, покупаешь видеокарту и развлекаешься.

Приборы и материалы: NVidia CUDA и прочие

Настоящий общедоступный сдвиг произошел меньше месяца назад: 6 февраля 2006 г. вышла вторая версия NVidia CUDA Toolkit, она же первая публичная (и первая более-менее работающая), она же версия 0.8.

Эта версия доступна всем желающим без подписания NDA, следовательно результаты тестов можно открыто публиковать.

Тема исследования, как обычно, умножение матриц. Задача очень простая алгоритмически, но со своими особенностями. В силу простоты задачи, изучать особенности одно удовольствие.

Рассматривались три доступных умножителя матриц:

SGEMM в составе библиотеки CUBLAS.
Тестовый пример от NVidia, который очень подробно разобран в документации.
Реализация SGEMM от RapidMind.

Умножение матриц, серия 3: Woodcrest против Opteron, ACML против MKL, Goto BLAS против всех

lexa - 27/Янв/2007 23:19

Использованная в предыдущем тестировании библиотека численных методов Intel Math Kernel Library очевидно не является оптимизированной под процессоры AMD. Следовательно, нужно изучать альтернативы.

Альтернатив на сегодня видно три: это библиотека AMD Core Math Library от производителя процессора и две OpenSource библиотеки: Goto BLAS и ATLAS (Automatically Tuned Linear Algebra Software). Их и изучим.

Все бенчмарки были совершенно одинаковыми: заполнялись исходные матрицы (значениями от 0.0 до 1.0), затем вызывалась функция sgemm (для single precision) или dgemm (double), время выполнения которой и измерялось.

Кроме Dual Opteron 275, в руки попал еще сервер Dual Xeon 5140, показалось полезным сравнить две архитектуры.

Умножение матриц, серия 2: MKL против компилятора, single/double и int

lexa - 20/Янв/2007 19:17

Продолжаем умножать матрицы. Для начала смоделируем sgemm/dgemm: C=alpha*A*B+beta*C

Нас интересует, естественно, самый быстрый способ из изученных ранее, а вопрос заключается в разнице в скорости между float и double и разницы в скорости между простым кодом, написанным вручную, и библиотечной реализацией.

О перемножении матриц и прочих архитектурных заморочках

lexa - 04/Янв/2007 17:07

Осваиваю тут новую NUMA-архитектуру (пока не скажу какую, хотя многие уже в курсе). Хочется ее адекватно сравнивать с возможностями PC-CPU, т.е. опять гонять тесты. Начал с умножения матриц только на CPU.

Если оставить в стороне продвинутые алгоритмы Штрассена и Копперсмита с Виноградом, ограничившись классическим подходом с умножением "строка на столбец", то умножение матриц вполне прямолинейно: C(i,j) += A(i,k)+B(k,j) С другой стороны, входные матрицы могут быть транспонированы (одна или обе). При этом меняется pattern доступа к памяти, за счет чего ожидается некоторая разница в производительности.

Рассматривая результаты Linpack, я ожидал получить разницу между «плохим» и «хорошим» паттерном в разы. Результат превзошел все ожидания, получилась разница на полтора порядка.