бенчмарки

Opera of the Phantom или сказание о канделябре

lexa - 14/Фев/2009 13:17

Вся эта история с PhantomOS интересна тем, что будучи еще vapourware оно всколыхнуло в людях пласты и позволило заглянуть в многочисленные бездны. Ссылок на дискуссии не даю, кому интересно - уже все видели.

Вместе с тем, dz продолжает утверждать, что всякий JIT на виртуальной машине рулит примерно не хуже, чем макроассемблер, известный нам под именем C/C++.

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

Да, действительно, судя по этим бенчмаркам Java временами рулит. Но что мы можем сказать про эти бенчмарки:

Они старые, 2003-й год, updated в 2004. Конечно, JIT за это время мог развиться на неимоверные высоты, однако и процессоростроители на месте не стояли, в i7, как я слышал, уже 3 SSE-юнита на ядро, а нормальное программирование SSE - это никакая не автовекторизация компилятором, а натурально фигурное выпиливание прямо на его ассемблере.
Что это за бенчмарки - мне с первого взгляда ясно не стало. Если это обращение матрицы 100x100, которая влезает в кэш L1 - это одно. Если это относительно большие данные, то плохие (не cache-aware) алгоритмы будут одинаково плохи, ибо cache miss будет стоить гораздо дороже, чем эффективность или неэффективность JIT. И, соответственно, выигрыши-провалы на тех графиках - это косвенное указание на то, попали или не попали в кэш.

Вместе с тем, быстрое пользование гуглом навело на реальную имплементацию FFT и реальные бенчмарки в сравнении не с каким-то левым sample/микробенчмаркой, а с кодом, который действительно доводится годами и считается оптимальным или близким к этому.

NVidia GTX280: бенчмарки с плавающей точкой

lexa - 26/Дек/2008 10:05

Каждые полгода ~~мы с друзьями~~ я бенчмаркаю вычисления на видеокартах. В этот раз изучалась 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.

Всякие соображения про масштабируемость решения - в самой статье.

Каждые полгода ~~мы с друзьями~~ я бенчмаркаю вычисления на видеокартах. В этот раз изучалась NVidia GTX280.

SGEMM/DGEMM на видеокарте и CPU, серия 7: NVidia GTX280
В чипе NVidia G200 появились операции с двойной точностью. Их производительность не феноменальна, но даже с учетом ввода-вывода данных в карту GTX280 обгоняет 4-ядерный 3-гигагерцовый Penryn. Если же рассматривать только скорость вычислений (что актуально, если задача позволяет спрятать затраты на ввод-вывод), то на двойной точности видеокарта быстрее CPU в 1.8 раза.
На одинарной точности разрыв видеокарты и CPU вырос: GTX280 обгоняет Core2Quad впятеро.

Всякие соображения про масштабируемость решения - в самой статье.

ATTO vs Areca

lexa - 30/Ноя/2008 11:20

Разное

Соблазнившись невиданной дешевизной: $217 за 8-портовый SAS RAID controller ATTO R348 приобрел себе такой (увы, помочь с привозом еще таких - не могу). Собственно, помимо дешевизны, преследовались три цели:

Отказаться от PCI-X. Еще несколько лет назад выбора не было: PCIe контроллеры отсутствовали, а RAID-контроллер в PCI-слоте - странный выбор. Но требование PCI-X - разорительно, только Asus наладил выпуск приемлемых 'Workstation'-материнских плат, а на серверные процессоры дома я уже не готов.
Иметь возможность поставить быстрый SAS-диск (скажем, Savvio 15.2K) на свап/TMP
Пишуть, что 1TB SAS-барракуды быстрее SATA на линейном чтении-записи и это хочется попробовать.

Опробованная год назад 3Ware-3650 меня совершенно не порадовала, производительность была так себе. В результате, я вяло обдумывал покупку ARC-1220 (SATA) или ARC-1222 (SAS), 750 баксов было очень жалко, а тут подвернулся deal на ATTO. По $27 за порт было невозможно удержаться.

Умножение матриц, серия 5: вычисления на GPU (2)

lexa - 16/Окт/2007 22:57

Почему переделываем тесты?

Предыдущая моя статья на эту тему была написана в феврале 2007 года, сразу после выхода первой публичной бета-версии CUDA Toolkit/CUDA SDK. Представители NVidia предупреждали, что в бета-версии производительность не является оптимальной, к релизу она будет улучшена.

За прошедшие полгода, пока я занимался совсем другими вещами, были выпущены релизы:

NVidia CUDA: SDK и библиотеки CUBLAS/CUFFT v1.0;
NVidia CUDA Display Driver 162.xx (драйвер, собственно, транслирует псевдокод в реальные программы GPU);
RapidMind Platform версий 2.0.0, а затем и 2.0.1.

Интересно посмотреть, стала ли производительность лучше.

Умножение матриц, серия 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, я ожидал получить разницу между «плохим» и «хорошим» паттерном в разы. Результат превзошел все ожидания, получилась разница на полтора порядка.