Pull to refresh

Comments 66

UFO just landed and posted this here
Регистры 128-и битные, влазят 4 single или 2 double
UFO just landed and posted this here
Intel не позволит кануть x86. Вспомните про Larrabee, который поддерживает и базируется на x86 инструкциях.
эти 153 GFLOP достаточно непрактично использовать, потому и не
пробовал (с точки зрения выпуска программы не для внутреннего потребления).

Что имеется в виду?
Доступ к ним тяжеловато получить.
O RLY?
Не понимаю. Если это готовый сервер или акселератор с интерфейсом PCI-E, то вот они, ресурсы. Если это PS3, то ставим Yellow Dog (или какой-нибудь другой дистрибутив GNU/Linux) и делаем свои расчеты на всех доступных SPE.
Во всех случаях для программирования используются одни и те же библиотеки/фреймворки, так что разработка отличается не очень кардинально.
Для конечного пользователя релизнуть трудно.
Объяснять простому юзеру как ему надо на приставку линух ставить — достаточно трудновато.

Ну а о цене акселей с интерфейсом PCI-E лучше помолчим, чтобы не расстраиваться зря :-)
Речь о HPC. Зачем это «простым юзерам»?
Простому юзеру достаточно купить PS3 и интересующую его игру, но мы не о том.
На случай если пишеться клиент для распределенных вычислений типа Folding@Home.
Фолдингу то хорошо, с помощью сони они все без Линуха сделали, и запускать конечным пользователям легко.
К сожалению для простых смертных этот пусть закрыт :-)
Когда речь идёт о пиковой производительности то получить её на х86 не намного легче чем на CELL.
Умножение больших матриц даёт на полноценном CELL ожидаемые 200GFlops.
Строка «Реальная скорость, GFLOP» не несёт практической смысловой нагрузки, т.к. не указано каких операций. Тем более у разных операций различное время выполенения.
FLOPS — FLoating point Operations Per Second (операций с плавающей точкой(одинарной точности наверно))

так что все очень даже понятно: например надо перемножить 2 матрицы NxN, считаешь, сколько надо операций, и считаешь приблизительное время
Вы не правы. Каких операций не указано, это может быть вполе суммирование.
А умножение матриц требует умножение и аккумулирование — эти операции, к примеру могут выполянтся 10 тактов, а суммирование 1 или 2 такта.
По этому FLOPS довольно абстрактная хар-ка.
я с вами согласен. тут надо уточнить что считается за одну операцию.
Большинство операций на GPU выполняются за один такт(иногда правда со сниженной точностью) — вот именно такие и учитываются.
Побольше таких статей, если можно :)
А можно немного наглядных графиком с вычислением чего-нибудь одного?
Например решения судоку?
Это что-то не так, если при работе CUDA не работает ОС :) (Максимум могут быть проблемы, если меняется графический режим, и новый будет требовать больше памяти, чем предыдущий, а вся свободная использована под приложение.)
Безусловно, видеокарты нынче показывают феноменальную производительность на достаточно узкой категории задач (особенно двухчиповые), примерно в 8 раз быстрее хорошего кода на обычном x86 процессоре.
Откуда такая информация? Прирост вполне может составлять 10—50 раз. Если конечно не сравнивать «плохой» код на GPU с «хорошим» кодом CPU.

А вообще неплохо бы код раскрасить да лишние переносы строк убрать…
Хабрапарсер со статьей чет мудрит, продолжение в хабраредакторе буду ваять.
UFO just landed and posted this here
В синтетических — да, из одночиповых — на практике — 295ая нвидиа
295 — двухчиповая :]
А по себе скажу, что 4870 страдает от нехватки нормальных дров. Очень.
Это спорно, к тому же заточка многих игр под nVidia нивелирует незначительный прирост в производительности. Ну а вычисления на GPU пока массово идут под брендом CUDA.
Нет заточки под nVidia. Mean to be played — всего лишь шильдик, который значит, что если видяха в списке поддерживаемых есть, и компьютер соответствует минимальным требованиям — оно запустится.
Эта программа и есть для того, чтобы разработчики затачивали игры под GeForce, вообще-то.
en.wikipedia.org/wiki/The_way_it's_meant_to_be_played
Их просто_проверяют_на_совместимость. Есть аналогичный шильдик и у ATI, просто они отказались от использования, причину не помню, если найду статью — покажу. Те игры, которые реально лучше работают на ATI маркируются соответствующим красно-белым клеймом.
Кстати, а куда делать платформа OpenCL, которую помойму AMD и продвигает, как основного соперника CUDA?
AMD has decided to support OpenCL (and DirectX 11) instead of the now deprecated Close to Metal in its Stream framework.
АМД решила продвигать OpenCL, вместо CTM. Я об этом и говорю. Или от её слов до дела ещё не дошло?
На деле пока все крайне странно себя ведет, это раз, два — CTM — это как раз реализация низкоуровневых команд. (Даже название об этом говорит)
Вы, видимо не верно поняли мой вопрос.

Я говорю про то, что вы использовали Brook+ и даже похвалили, что в нём реализованны CTM.

Хотелось увидеть в статье (возможно продолжение этой) OpenCL, как альтернативу CUDA и Broom+. Если можно, конечно.
Собираюсь просто этим заниматься скоро — OpenCL сейчас вижу, как достаточно продуманную кроссплатформенную (Radeon+Geforce) альтернативу.
Хороший обзор. Скажите, а чем предполагается компилировать код для Phenom?
Intel С++ с соответствующими настройками
Программы, работающие по 5 секунд — это ещё очень далеко от HPC. Может они и высокопроизводительные, но много насчитать не очень-то получится… Раз уж у вас есть под рукой необходимое оборудование, стоило бы проверить производительность на более приближенных к жизни операциях, например двумерном Фурье-преобразовании матрицы размером 8192x8192 :)
5 секунд — это всего лишь время через которое ОС посчитает что вычисления захватили ресурсы видеокарты и снимет процесс.
Если покупается GPU для специальных рассчетов, то монитор к ней подключать не следует, и в таком случае Windows watchdog не срабатывает, можно считать сколько нужно.
Обойти можно всё, это понятно :) Но это лишний камень в огород CUDA, пресс-релизы которой пестрят заявлениями о том, как же с ней удобно работать даже на офисных PC. Особенно, если не покупать новые топовые карты, а пробовать работать с той, которая стоит на рабочем компьютере.
5 секунд — это лимит на исполнение одного kernel'я, а в консьюмерских задачах кернели отрабатывают зачастую за миллисекунды.
И никаких камней нет, потому что ATI имеет те же проблемы.
Я имел в виду сравнение не с ATI, а с вычислительными системами на основе CPU :) Не спорю, что есть много задач, где вычисления занимают мало времени, просто я их, видимо, не отношу сильно к области HPC, которая была заявлена в заголовке статьи. Либо я не до конца понимаю терминологии, чтож, буду читать…
Спасибо за ссылку. Намного более адекватный результат, превосходство GTX280 над Core2Quad 9300 всего полтора раза. И это для перемножения матриц, которое для GPU идеально подходит.
Так написано же, что на double производительность в 10 раз падает. Смотрите float:
Blas — 87, Cuda — 372. В 4.3 раза быстрее чем Quad, в 17 раз быстрее одного ядра.

Думаю, быстрое преобразование фурье может дать больший разрыв во floate за счёт хорошего синуса в Nvidia.
Мне кажется сравнивать с одним ядром уже давно пора перестать :)

В том-то и дело, что в реальных считательных задачах не всегда достаточно float. Если кратко, то этого достаточно для видео, графики, игр, что и неудивительно, но не стоит экономить на точности при расчёте ядерных реакторов. Фурье само по себе имеет тенденцию терять точность даже при преобразовании туда-обратно, то делать это во float не очень хорошо.
Что то FLOPS в вашей табличке для чипов сильно расходятся с тем что приведено в en.wikipedia.org/wiki/FLOPS
Это потому что у вас «реальные»? :-)
Да, а там — теоритический максимум, практически нереально
На самом деле пиковая производительность x86 i7 @ 3GHz(Nehalem):
a) Single precision: 8*3Ghz = 24GFlops per core, 24*4 = 96GFlops per CPU;
b) Double precision: 4*3GHz = 12GFlops per core, 12*4 = 48GFlops per CPU.

Смотрите например тут:
icl.cs.utk.edu/hpcc/hpcc_results.cgi

Подтест DGEMM — как раз этот случай. Высокая локальность, чисто Flops-ы :)
S-DGEMM — замер на одном процессе, EP-DGEMM — замер на всех ядрах, усредненный.

Вот, а «Реальная скорость в 153 GFLOPS» — это от лукавого…
В этой статьи не рассматриваются вопросы связанные с падением производительности из-за памяти/кеша. К указанной в таблице цифре я приближался на всех платформах кросе Cell. На x86 все помещалось в регистры и немного L1 кеша, потому и скорость 150 а не 96.
Уважаемый — я вам даю теоретический пик. С которым вообщем-то согласны в индустрии. А вы мне черт знает что — я не могу понять в чем вы измеряете свои флопсы, откуда взялась эта цифра 150??
Этот теоретический пик — на матричных операциях, и я согласен что он тоже важен. В данной статье я привожу максимальную реально достижимую скорость, не учитывая ограничения памяти (например когда все в регистрах или в L1 кеше). Производительность работы с памятью (bandwidth & latency на разных уровнях) можно рассмотреть в отдельной статье, там тоже много интересного :-)
Теоретический пик как раз и не учитывает кэши и память.
Ну вы приведите код в конце концов, и все ведь станет ясно. Тот кусок кода что в оригинальной статье меряет не Flops-ы а Mips-ы, т.е целочисленные инструкции. Возможно отсюда у автора и такие цифры.

Про bandwidth и latency — пожалуйста. Только сразу указывайте для какой операции.
Производительность и на 32 битных целых, и синглах(по крайней мере пока мы говорим о простых операциях) у всех одинаковая — все занимает по одному такту.
Код в статье — лишь для примера.
Не может быть!!! Вас кто-то обманул :)
4 сингловые операции за такт или 3 целочисленные, а с применением адресной арифметики может быть и 5.
И вообще х86 сейчас может выполнять до 6-ти или 11-ти (точно не помню) инструкций за такт с помощию буфера циклов.
Я говорю об SSE операциях, так и получается 12 операций за такт на ядро — 3 операции по 4 числа.
Ставить вместо SSE операций обычные пожалуй не стоит :-)
Еще раз. В процессоре 1 блок SSE шириной 128бит. Он за 1 такт выполняет 1 SSE инструкцию над 128 битами.
«3 операции по 4 числа.» — нихт. Никак. Невозможно.
В Core2Duo и выше 3 SSE блока — это и дает очень большую скорость.
В Phenom — тоже 3, но 2 из них специализированные.

На реальных приложениях (например моя программа BarsWF) выжимает ~35 млрд операций в секунду на ядро, как это возможно если можно делать только 4 операции за такт?
Небольшой апдейт:
1 блок FP умножения и 1 блок FP сложения — отдельно.
Итого 2+2=4 double precision FP операции за такт.
Делилка и вычиталка — те же самые блоки.
Другие операции — сильно медленнее.
Конверсия чисел, load и store за операции не считаются.



Вобщем чтобы прекратить спор предлагаю вам написать программу, делающую больше 4 FP операций за такт. Хотспот вашей BarsWF подойдет.

peak FP throughput for vectorized code of 2 64-bit MUL and 2 64-bit ADD per cycle (8 SP or 4 DP FLOPS)
Отлично :)
Теперь можете прикинуть как это выглядит на больших машинах, на отлично вылизанном DGEMM (или распределенном Linpack) — сколько реально достигается процентов от пика. Ссылку я давал выше.
Данные будут примерно такого порядка: 75% на п4, 82% на Core2Duo и примерно 85-89% на Нехалеме. В этом и сила этого процессора.
Спасибо!!! Ещё бы вводные курсы по nVidia CUDA и AMD Brook почитать.
Кроме того, материнская плата под 4 видеокарты стоит намного дешевле платы под 4 процессора.
А можно пример такой материнки? Я максимум слышал про 3 карточки, и из них одна по шине еще зажата будет…
Sign up to leave a comment.

Articles