Как я уже писал в прошлый раз, становится какой-то дурной традицией переделывать тест умножения матриц каждые несколько месяцев.
В этот раз причиной для тестов стало появление у меня в доступности видеокарты NVidia GTX280, что позволило протестировать два момента:
- Производительность умножения матриц с одинарной точностью (SGEMM) на новом быстром оборудовании.
- Производительность умножения матриц с двойной точностью (DGEMM).
Участники забега
Hardware
- Intel Core2Quad 9300, на частоте 3GHz, память DDR2 PC6400 4-4-4-12
- NVidia GeForce GTX280 на штатной частоте
- 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) дороже, но и они более чем конкурентны по отношению цена/производительность. Дело лишь за программами.
Comments
Помоему плохо то что в тесте нет карточек АМД. Как по мне то наиболее актуальными тестами буду BarsWF и этот http://justanotherblog565.blogspot.com/2009/01/blog-post.html. Причём Результаты первого для флагманов от обоих производителей известны. Там стоимость MHash для карточки АМД будет 1260/ 267 = 4,49 и для проца 200/585 = 0,34, для нВидиа хуже в общем. Кстати второй бенч интересен тем что умеет считать гигафлопсы которые можно получить не в самом лучшем случае, с плохо замаскироваными задержками, и прочим.
Think Data Parallel http://justanotherblog565.blogspot.com/
Приносите еды, взвесим.
В том смысле, что у меня таких данных нет, а если у вас есть - с удовольствием их опубликуем.
http://www.gpgpu.ru/reviews/gpu-md5.html#comment-489
Было бы конешно интересно если бы владельцы топовых карточек поганяли этот тест http://graphics.stanford.edu/projects/gpubench/.
Think Data Parallel http://justanotherblog565.blogspot.com/
Пардон, статья про SGEMM/DGEMM, мне казалось что мы все еще это приложение обсуждаем.
Смайлика с поднятыми лапками нету ?)))
Я с самого начала подумал о том что цель этой статьи скорее бенчмаркинг, определение более удачной платформы для различных задач, а не выяснение производительности( и удельной в том числе) ТОЛЬКО В ОДНОЙ конкретной задаче.
Think Data Parallel http://justanotherblog565.blogspot.com/
Вот к примеру два жестких диска - у одного transfer вдвое быстрее, а у другого - seek. Какой "быстрее" ? Не зная задачи, выбрать невозможно, для streaming оптимален один, для базы данных - другой.
И это вообще проблема бенчмарок. Ну вот прогнали gpubench, получили набор из 10 цифр для разных операций. А какая операция будет наиболее проблемной для конкретной задачи - трудно узнать.
В этом смысле SGEMM/DGEMM или FFT как вычислительные бенчмарки очень хороши - про них многое известно, накоплена большая база и т.п..
Что касается BarsWF - это тоже очень интересная метрика, но ее можно рассматривать только по модулю автора (скажем, мне тамошнее масштабирование очень удивительно и я пока сам руками не пощупаю - а исходников нет - не могу быть убежден, что там с occupancy все нормально. Правда я только версию 0.7 смотрел).
И в сумме они дастаточно информативны - зная throhput для всех инструкций можно 1) оптимизировать алгоритмы для исплючения самых медленных 2) рассчитать приблизительный throhput для всего кернела. У MM и FFT имеют одно и то же соотношение различных инструкций и не позволяют как либо оценить быстродействие конкретной карточки в другой задаче, как по вашему почему 3Dmark-и не умножают матрицы ? Есть примеры приложений чисто выжать максимум производетельности из конкретного железа - только вот лажа соотношение количества вычислительных/текстурных блоков у карточек разных производителей разное. Да ещё и обьёмы и архитектуры кешей. Бенчмарк должен дать представление о производительности в различных сценариях приближённых к реальности. Много задач решается перемножением матриц ? Нет, я понял что я малость не в свой монастырь полез, но умножение матриц - не единственное чем можно занять видеокарты.
Think Data Parallel http://justanotherblog565.blogspot.com/
У MM и FFT вовсе не одно и то же соотношение различных инструкций. В FFT гораздо меньше multiply-and-add-ов. У FFT меньшая арифметическая интенсивность, причём она медленнее растёт с обьёмом доступной памяти на чипе (log S vs sqrt(S)).
Думал что пишу о том что два теста мало и это соотношение инструкций стабильное))). В то время как для оценки конкретной карточки лучше было бы прогнать большое количество различных сценариев.
Think Data Parallel http://justanotherblog565.blogspot.com/
Вот то, что тестов много - на мой взгляд и плохо. Как правило, на стадии выбора архитектуры структура задачи с точностью до соотношения инструкций еще не ясна
Вместе с тем - если есть желание пособирать цифирки gpubench или Bars-а - это дело тоже благородное, если будет желание опубликовать это на данном сайте - я только за.
Архитектуры чего ? Выбор архитектуры приложения понятное дело делается раньше. А вот выбор конкретной модели видеокарты (или видеокарт ?) уже вопрос которые как по мне должен решатся в рабочем порядке. Думаю не очень сложно поменять карточку после того как подобрал нужный алгоритм. Если реально нужно выполнить какую-то работу на видеокарте (читай быстро и дёшево) особенно если это не ради забавы, а ради реального приложения которое потом нужно будет устанавливать на многие машины. У меня вот возникли проблемы с видеокартами АТИ которые ставят под вопрос решение задачи - я легко поменяю brook+ на CUDA ( например работа с локальной памятью у нвидиа поудобней для программиста реализована - а значит можно её эффективнее использовать) . Помоему очевидно что для быстрого дискретного преобразования Фурье, синус и квадратный корень не очень нужен ? И в принципе известно количество операций сложения и умножения. Какая разница насколько быстро работает карточка в одном тесте с определённым соотношением инструкций, если в реальном приложении оно будет другое ? GPUBench - даёт возможность не просто пособирать циферки (цифирки - меня не интересуют))) ), а понять как в разных сценариях работает железо. ФФТ в этом плане не информативен. Любой единственнй тест, результатом которого является одно число - время выполнения, не информативен. Извините, но у меня сложилось впечатления что вы только заголовок прочитали. На сбор циферок больше похоже перемножение матриц и любые другие не микро бенчмарки.
Think Data Parallel http://justanotherblog565.blogspot.com/
для быстрого дискретного преобразования Фурье синус как раз очень полезен. Именно через явное вычисление синуса и косинуса сейчас все FFT на NVIDIA GPU и работают. Соостветственно, отсутствие поддержки синуса в двойной точности в железе многое меняет в FFT двойной точности.
Микробенчмарки в самом деле очень полезны и широко использовались для разработки и FFT и SGEMM. Только GPUbench морально устарел и почти все важные детали пропускает мимо.
Синус полезен - в плане если считать Е через формулу Эйлера ? Не пробовал но думал быстрее будет в степень поднести. Сори у меня в отношении FFT только теория. Какие микробенчи посоветуете ?
Насчёт того что пропускает gpubench - согласно его данным ветвление на картах нвидиа бесплатное - что отнюдь не так судя по официальным рекомендациям для оптимизации приложений на CUDA (ссылку посеял, есть пдф-ка могу отослать).
Think Data Parallel http://justanotherblog565.blogspot.com/
на GPU есть отдельный, весьма быстрый конвейер для синусов. Поэтому синусы иногда получается считать практически забесплатно впараллель с основными вычислениями. Микробенчмарки я бы посоветовал сам писать :) Можно ещё посмотреть некие результаты для NVIDIA GPUs в статье http://parlab.eecs.berkeley.edu/pubs/volkov-benchmarking.pdf
Синусы действительно считаются отдельными блоками, но их значительно меньше чем основных. Пересмотрел резалты gpubench - согласен, теперь понял почему так хороши синусы и косинусы. Оказывается они на любом железе считаются быстрее поднесения в степень.
Think Data Parallel http://justanotherblog565.blogspot.com/
сами АМД утверждают что 3870 даёт 300 Gflop/s в SGEMM и 137 Gflop/s в DGEMM, см. слайд 20 в http://ati.amd.com/technology/streamcomputing/IUCAA_Pune_PEEP_2008.pdf. Причём 4870 якобы ещё в 2.25-2.5 раз быстрее.
что привлекло моё внимание:
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).
Насколько я знаю, 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.
Разница на CPU маленькая, но устойчивая - цифры усреднены за несколько прогонов. Ничего на эту тему не могу сказать, код бенчмарок практически одинаковый.
По перформансу y GPU: - реальная производительность SGEMM - 60% от пиковой (по презентации Волкова) и все уперто не в вычисления. При этом код в CuBLAS в точности Волковский (разница в производительности - в 4-м знаке), там все уперто в чтение из глобальной памяти и ку-ку.
А вообще - ценность данного текста в том, что это уже 7-й раз по примерно одной методике, контроллируемой одним человеком (поглаживает пузо), такие цифры легче сопоставлять.
В этом смысле Sparse BLAS приобретет ценность года через 2-3.
>>В этом смысле 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 для сложных задач моделирования, алгоритмов на графах.
Ну я посмотрел на тамошний код - он неубедительный совершенно. Может быть оно и так сойдет, не знаю, но если MKL SBLAS вдруг выиграет - это не будет показательно никоим образом.
Оно какое-то не убедительное, как мне кажется. Разреженные матрицы вообще дело такое, чуть шаг в сторону и все иначе.
Но я посмотрю на праздниках, оно на самом деле интересно т.к. задачи под sparse я вспомнил :)