SGEMM/DGEMM на видеокарте и CPU, серия 7: NVidia GTX280

Как я уже писал в прошлый раз, становится какой-то дурной традицией переделывать тест умножения матриц каждые несколько месяцев.

В этот раз причиной для тестов стало появление у меня в доступности видеокарты NVidia GTX280, что позволило протестировать два момента:

  • Производительность умножения матриц с одинарной точностью (SGEMM) на новом быстром оборудовании.
  • Производительность умножения матриц с двойной точностью (DGEMM).
И сравнить результаты с mainstream-поколением процессоров Intel (Penryn), к сожалению i7 в доступности у меня пока нет.

Участники забега

Hardware

  • Intel Core2Quad 9300, на частоте 3GHz, память DDR2 PC6400 4-4-4-12
  • NVidia GeForce GTX280 на штатной частоте
Software
  • Windows Vista Ultimate x64
  • Goto BLAS 1.26 (использовалась под Cygwin, 32-битный режим)
  • NVidia CUDA 2.1 beta (64-битная версия)

Методика тестирования

Методика совершенно незатейлива: берем квадратные матрицы, достаточно большого размера, пропорционального 1024 (для таких матриц получается максимальное быстродействие), инициализируем случайными данными, перемножаем библиотечным вызовом (SGEMM/DGEMM или аналогами), определяем затраченное на умножение время, считаем гигафлопсы. Перед забегом проверяем правильность работы перемножая маленькие матрицы (8x8) и проверяя глазом корректность результата.

В случае видеокарты необходимо учитывать, что отдельное время требуется на пересылку данных в видеокарту и получение обратно результата, поэтому для CUDA считалось два быстродействия:

  • Чистое быстродействие - без учета времени на пересылку данных.
  • Полное быстродействие - с учетом времени на ввод-вывод.

Результаты: одинарная точность

Производительность умножения матриц (SGEMM: одинарная точность), GFLOP/s
Описание теста размер задачи
  1024 2048 4096 6144
Goto BLAS 1.26 74.1 76.3 86.4 86.9
NVidia GTX280, CUDA 2.1 beta, чистое время вычислений 350 366 370 372
NVidia GTX280, CUDA 2.1 beta, вычисления+ввод-вывод 168 238 288 313
Производительность 8800GTX, для сравнения
NVidia 8800GTX, CUDA 2.0 beta, чистое время вычислений 202 204 205 -
NVidia 8800GTX, CUDA 2.0 beta, вычисления+ввод-вывод 151 177 190 -

В сравнении с предыдущей бенчмаркой скорость вычисления на CPU чуть-чуть (на пару процентов) упала, я немного грешу на Висту (предыдущие тесты были на WinXP x64), но изменение в пределах допустимой погрешности.

Чистая скорость вычислений на GTX280 соответствует ожиданиям: ожидали 370-375 Gflop/s, столько и получили. Это, конечно, очень далеко от креативных 900Gflop/s, которые рассчитываются исходя из предположения, что все вычислительные блоки считают MAD и ничего не ждут, но общее соотношение реального быстродействия к "креативному" примерно такое же, какое было на G80, может быть чуть хуже.

Полное (c учетом пересылки данных в/из видеокарты) быстродействие выросло не так сильно: для матрицы 1024x1024 роста практически нет, для матрицы 4096x4096 полное быстродействие выросло в 1.65 раза, а чистое - в 1.8 раза. Эффект неудивительный, ведь скорость PCIe интерфейса от скорости вычислений на карте не зависит.

Необходимо отметить, что 8800GTX не поддерживает асинхронного режима работы, а в более новых картах при работе с небольшими матрицами задержки на пересылку данных вполне можно спрятать: пока обсчитывается один набор данных, можно загружать данные для следующего или получать результаты предыдущего. Конечно, это имеет смысл, если наборов данных более одного, но если он всего один, то и скорость вычисления на CPU должна устроить.

Невысокая скорость CPU на маленьких задачах объясняется, скорее всего, невысоким разрешением использованного таймера (порядка 10ms).

Результаты: двойная точность

Двойная точность вызывала у меня особый интерес: формальные характеристики G200 по двойной точности были относительно невысокими и если бы отношение реального быстродействия к заявленным "креативным" цифрам было бы таким же, как для одинарной точности, то для многих задач быстрее было бы посчитать их на CPU. Действительность оказалась заметно лучше ожиданий:

Производительность умножения матриц (DGEMM: двойная точность), GFLOP/s
Описание теста размер задачи
  1024 2048 4096
Goto BLAS 1.26 34.6 42.3 42.9
NVidia GTX280, CUDA 2.1 beta, чистое время вычислений 73 74.6 75.3
NVidia GTX280, CUDA 2.1 beta, вычисления+ввод-вывод 46.4 57.4 65.8

Как видим, не все так плохо: на двойной точности GTX280 более чем в полтора раза быстрее 4-ядерного десктопного процессора, даже с учетом пересылки данных. Если же затраты на пересылку спрятать (вычислений много), то видеокарта быстрее центрального процессора почти вдвое.

Из общих соображений, производительность на вычислениях с двойной точностью определяется не bandwidth памяти, а именно производительностью вычислителя: в сравнении с одинарной точностью быстродействие упало более чем вчетверо, а объем данных вырос ровно вдвое. Таким образом, выигрыша на вычислениях с бОльшей арифметической интенсивностью, в отличие от случая одинарной точности, ожидать не следует.

Обсуждение результатов и выводы

Полученные результаты можно рассматривать с трех разных точек зрения:

  • какова цена десктопного гигафлопса (метрика довольно сомнительная, но зато это одна цифра);
  • масштабируемость десктопных решений;
  • как это все масштабируется на относительно небольшие серверы.

Цена десктопного гигафлопса

Для десктопных решений (которые, собственно, и тестировались) "экономика гигафлопса" выглядит следующим образом:

  • Гигафлопс одинарной точности стоит:
    • $1.3 если его покупать в виде NVidia Geforce GTX280
    • $1.0 в виде NVidia Geforce GTX260 (приблизительная оценка, исходя из частоты и количества
    • $2.9 в виде Intel Core2Quad Q9300 (разогнанный до 3GHZ, что он легко позволяет).
  • Гигафлопс двойной точности стоит:
    • $6.3 в виде GTX280
    • $4.8 в виде GTX260 (грубая оценка, исходя из частоты и количества процессоров)
    • $5.8 в виде Core2Quad

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

Вместе с тем, данный показатель считался и в тесте годовалой давности, можно видеть что цена GPU-гигафлопса упала впятеро (в том числе и за счет оптимизации программ), а CPU-гигафлопс подешевел за год втрое (вклад программ тоже есть, но меньший).

Вместе с тем, простые прикидки показывают, что разрыв между одним CPU и одним GPU по производительности с одинарной точностью за последний год только вырос (и Core i7 положение исправит не сильно), а отсутствие вычислений с двойной точностью за это же время было вылечено. По двойной точности разрыв не настолько велик, чтобы был смысл перетаскивать вычисления на GPU, но гибридные схемы (приближенный расчет с одинарной точностью и уточнение на двойной) стали гораздо интереснее: их можно делать не только на комбинации CPU/GPU как всего полгода назад, но и целиком на видеопроцессоре.

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

Нельзя забывать, что десктопная система допускает легкое и недорогое масштабирование еще втрое (путем добавления видеокарт). Да, не всякая задача такое допускает, но если у вас много независимых не очень крупных расчетов, то за $2000-2500 можно получить на столе чуть более реального терафлопса с одинарной точностью и более 200 GFLOP/s с двойной. Индустриальные решения (Quadro и Tesla) дороже, но и они более чем конкурентны по отношению цена/производительность. Дело лишь за программами.

Tags: 

Comments

очень-очень интересно

что привлекло моё внимание:
1. производительность CPU на double меньше, чем на float / 2 (хотя разница очень маленькая). в теории должно получаться, что dFLOPS >= sFLOPS/2. это следует из того, что сами ADD/MUL требуют одинаковое кол-во тактов и чтения регистров/памяти, но организовать blocking для double проще (особенно для матриц с размерами не 2^x), по крайней мере не сложнее. раньше я всегда это видел на тестах (как только скорость double и float сравнялась Intel Core, AMD K8).
2. удивительно, что разница между G80 и GT200 фактически пропорциональна кол-ву SP. хотя, согласно NV, GT200 научилась-таки реально выполнять ADD/MUL на SFU параллельно с MAD на SP. возможно это требует существенно изменить алгоритм GEMM, но это пока не было сделано.
3. касательно double вообще, здорово, что он появился и хотя бы не медленнее, чем на СPU. это избавляет от необходимости вычислять double на CPU для mixed precision схем.
4. главное. ИМХО брутфорс вроде GEMM нужен всё реже и реже, современные алгоритмы требуют более сложные структуры данных. очень и очень интересно было бы увидеть производительность Sparse BLAS 3 на GPU. особенно в свете того, что вроде как есть готовые примитивы для этого (scatter/gather/prefix sum).

Разница на CPU маленькая, но

Разница на CPU маленькая, но устойчивая - цифры усреднены за несколько прогонов. Ничего на эту тему не могу сказать, код бенчмарок практически одинаковый.

По перформансу y GPU: - реальная производительность SGEMM - 60% от пиковой (по презентации Волкова) и все уперто не в вычисления. При этом код в CuBLAS в точности Волковский (разница в производительности - в 4-м знаке), там все уперто в чтение из глобальной памяти и ку-ку.

А вообще - ценность данного текста в том, что это уже 7-й раз по примерно одной методике, контроллируемой одним человеком (поглаживает пузо), такие цифры легче сопоставлять.
В этом смысле Sparse BLAS приобретет ценность года через 2-3.

>>В этом смысле Sparse BLAS

>>В этом смысле Sparse BLAS приобретет ценность года через 2-3.
согласен. но пора бы уже и начать :-)

ещё важный момент. хотелось бы, чтобы вычисления на GPU через CUDA или OpenCL можно было проводить без "захвата" GPU и прерывания нормальной работы видеокарты, вроде срабатывания watch dog. нужно что-то вроде time slicing или параллельной обработки на уровне мультипроцессоров.
OpenCL вроде как умеет использовать ресурсы совместно с OpenGL. надеюсь, что это означает возможность выполнять вычисления параллельно графике.

Я готов взять некую

Я готов взять некую стандартную бенчмарку и начать ее пускать. Даже 8800GTX для этого достану из шкафа.
Но мои текущие интересы - они в плотной области, а не в sparse т.е. шансов, что я сам что-то слеплю из деталей - никаких.

А про блокировки и watchdogs - остается только надеяться на лучшее, обидно что за два года это место не починили, но там и внешний cancel kernel-у до сих пор не приделали, все обещают. Немножко детское все, да (не знаю как на Tesla)

эх, проблема в том, что нет

эх, проблема в том, что нет стандартной бенчмарки.
можно попробовать запустить код с http://scriptroute.cs.umd.edu/gpucompete/ на тестовых матрицах взятых у них же (square and large) и сравнить с Intel MKL SBLAS, вроде как в дистрибе должен быть какой-то benchmark. даже если такого и нет, то будут цифры для GPU, для SBLAS 2 и SBLAS 3.
полученная производительность может служить оценкой эффективности GPU для сложных задач моделирования, алгоритмов на графах.

Оно какое-то не убедительное,

Оно какое-то не убедительное, как мне кажется. Разреженные матрицы вообще дело такое, чуть шаг в сторону и все иначе.

Но я посмотрю на праздниках, оно на самом деле интересно т.к. задачи под sparse я вспомнил :)

Ну я посмотрел на тамошний

Ну я посмотрел на тамошний код - он неубедительный совершенно. Может быть оно и так сойдет, не знаю, но если MKL SBLAS вдруг выиграет - это не будет показательно никоим образом.

Насколько я знаю, GT200 не

Насколько я знаю, GT200 не может выполнять ADD на SFU, хотя может выполнять MUL. Смотри например главу "Improved Dual Issue" в "NVIDIA GeForce GTX 200 Architectural Overview" по ссылке: http://www.nvidia.com/object/io_1213615494642.html. Цитирую: "The individual streaming processing cores of GeForce GTX 200 GPUs can now perform near full-speed dual-issue of multiply-add operations (MADs) and MULs (3 flops/SP) by using the SP s MAD unit to perform a MUL and ADD per clock, and using the SFU to perform another MUL in the same clock." Мне нравится выражение "near full-speed".

Касательно разреженных матриц. Не так давно, NVIDIA выпустила умножение разреженной матрицы на вектор (SpMV), см. http://forums.nvidia.com/index.php?showtopic=83825.

Помоему плохо то что в тесте

Помоему плохо то что в тесте нет карточек АМД. Как по мне то наиболее актуальными тестами буду BarsWF и этот http://justanotherblog565.blogspot.com/2009/01/blog-post.html. Причём Результаты первого для флагманов от обоих производителей известны. Там стоимость MHash для карточки АМД будет 1260/ 267 = 4,49 и для проца 200/585 = 0,34, для нВидиа хуже в общем. Кстати второй бенч интересен тем что умеет считать гигафлопсы которые можно получить не в самом лучшем случае, с плохо замаскироваными задержками, и прочим.

Приносите еды, взвесим. В том

Приносите еды, взвесим.

В том смысле, что у меня таких данных нет, а если у вас есть - с удовольствием их опубликуем.

Пардон, статья про

Пардон, статья про SGEMM/DGEMM, мне казалось что мы все еще это приложение обсуждаем.

ОК

Смайлика с поднятыми лапками нету ?)))
Я с самого начала подумал о том что цель этой статьи скорее бенчмаркинг, определение более удачной платформы для различных задач, а не выяснение производительности( и удельной в том числе) ТОЛЬКО В ОДНОЙ конкретной задаче.

Бенчмаркинг - вообще очень трудная задача

Вот к примеру два жестких диска - у одного transfer вдвое быстрее, а у другого - seek. Какой "быстрее" ? Не зная задачи, выбрать невозможно, для streaming оптимален один, для базы данных - другой.

И это вообще проблема бенчмарок. Ну вот прогнали gpubench, получили набор из 10 цифр для разных операций. А какая операция будет наиболее проблемной для конкретной задачи - трудно узнать.

В этом смысле SGEMM/DGEMM или FFT как вычислительные бенчмарки очень хороши - про них многое известно, накоплена большая база и т.п..

Что касается BarsWF - это тоже очень интересная метрика, но ее можно рассматривать только по модулю автора (скажем, мне тамошнее масштабирование очень удивительно и я пока сам руками не пощупаю - а исходников нет - не могу быть убежден, что там с occupancy все нормально. Правда я только версию 0.7 смотрел).

В gpubench - много различных тестов

И в сумме они дастаточно информативны - зная throhput для всех инструкций можно 1) оптимизировать алгоритмы для исплючения самых медленных 2) рассчитать приблизительный throhput для всего кернела. У MM и FFT имеют одно и то же соотношение различных инструкций и не позволяют как либо оценить быстродействие конкретной карточки в другой задаче, как по вашему почему 3Dmark-и не умножают матрицы ? Есть примеры приложений чисто выжать максимум производетельности из конкретного железа - только вот лажа соотношение количества вычислительных/текстурных блоков у карточек разных производителей разное. Да ещё и обьёмы и архитектуры кешей. Бенчмарк должен дать представление о производительности в различных сценариях приближённых к реальности. Много задач решается перемножением матриц ? Нет, я понял что я малость не в свой монастырь полез, но умножение матриц - не единственное чем можно занять видеокарты.

Вот то, что тестов много - на

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

Вместе с тем - если есть желание пособирать цифирки gpubench или Bars-а - это дело тоже благородное, если будет желание опубликовать это на данном сайте - я только за.

Архитектуры чего ? Выбор

Архитектуры чего ? Выбор архитектуры приложения понятное дело делается раньше. А вот выбор конкретной модели видеокарты (или видеокарт ?) уже вопрос которые как по мне должен решатся в рабочем порядке. Думаю не очень сложно поменять карточку после того как подобрал нужный алгоритм. Если реально нужно выполнить какую-то работу на видеокарте (читай быстро и дёшево) особенно если это не ради забавы, а ради реального приложения которое потом нужно будет устанавливать на многие машины. У меня вот возникли проблемы с видеокартами АТИ которые ставят под вопрос решение задачи - я легко поменяю brook+ на CUDA ( например работа с локальной памятью у нвидиа поудобней для программиста реализована - а значит можно её эффективнее использовать) . Помоему очевидно что для быстрого дискретного преобразования Фурье, синус и квадратный корень не очень нужен ? И в принципе известно количество операций сложения и умножения. Какая разница насколько быстро работает карточка в одном тесте с определённым соотношением инструкций, если в реальном приложении оно будет другое ? GPUBench - даёт возможность не просто пособирать циферки (цифирки - меня не интересуют))) ), а понять как в разных сценариях работает железо. ФФТ в этом плане не информативен. Любой единственнй тест, результатом которого является одно число - время выполнения, не информативен. Извините, но у меня сложилось впечатления что вы только заголовок прочитали. На сбор циферок больше похоже перемножение матриц и любые другие не микро бенчмарки.

для быстрого дискретного

для быстрого дискретного преобразования Фурье синус как раз очень полезен. Именно через явное вычисление синуса и косинуса сейчас все FFT на NVIDIA GPU и работают. Соостветственно, отсутствие поддержки синуса в двойной точности в железе многое меняет в FFT двойной точности.

Микробенчмарки в самом деле очень полезны и широко использовались для разработки и FFT и SGEMM. Только GPUbench морально устарел и почти все важные детали пропускает мимо.

Синус полезен - в плане если

Синус полезен - в плане если считать Е через формулу Эйлера ? Не пробовал но думал быстрее будет в степень поднести. Сори у меня в отношении FFT только теория. Какие микробенчи посоветуете ?
Насчёт того что пропускает gpubench - согласно его данным ветвление на картах нвидиа бесплатное - что отнюдь не так судя по официальным рекомендациям для оптимизации приложений на CUDA (ссылку посеял, есть пдф-ка могу отослать).

на GPU есть отдельный, весьма

на GPU есть отдельный, весьма быстрый конвейер для синусов. Поэтому синусы иногда получается считать практически забесплатно впараллель с основными вычислениями. Микробенчмарки я бы посоветовал сам писать :) Можно ещё посмотреть некие результаты для NVIDIA GPUs в статье http://parlab.eecs.berkeley.edu/pubs/volkov-benchmarking.pdf

Совет дельный, спасибо)))

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

У MM и FFT вовсе не одно и то

У MM и FFT вовсе не одно и то же соотношение различных инструкций. В FFT гораздо меньше multiply-and-add-ов. У FFT меньшая арифметическая интенсивность, причём она медленнее растёт с обьёмом доступной памяти на чипе (log S vs sqrt(S)).

Извиняюсь глупость написал

Думал что пишу о том что два теста мало и это соотношение инструкций стабильное))). В то время как для оценки конкретной карточки лучше было бы прогнать большое количество различных сценариев.