Нетрадиционное использование видеокарты.

Татарин>> Там же было долгое обсуждение вопроса... пришли к мнению, что овчинка выделки не стОит: гораздо сложнее программирование и оптимизация и никакой переносимости, а выигрыш - не столь уж и велик... Тем паче, что по цене хорошей видеокарты можно поставить дополнительную пару процов. Обычный кластер получался выгоднее, тем более, что его апгрейдить куда легче.
Murkt> Переносимость есть - OpenGL везде одинаков, а управляющее приложение без разницы на чём писать - C++, Python, Perl, Java.
Я, конечно, не эксперт в OpenGL, знаю только самые азы, но как его вообще там присобачить? через что?

Murkt> Выигрыш уже огромен.
Уже огромен - сколько, где, на чём?

Для всяких распределёных вычислений это имеет смысл даже если карта медленее, чем CPU. Потому что там достаточно соблюдения условия "карта+CPU быстрее CPU". Ибо всё равно видеокарта на домашних машинах есть, и она гарантировано простаивает (по самой идее системы). Если же предполагать, что вычислялка покупается не под игры, а именно под расчеты, то и расклад совсем иной.

Татарин> Имеет смысл только при массивно-параллельных расчётах небольшой точности.
AlexL> А что имеется ввиду под небольшой точностью?
Мантисса меньше 64 бит.

AlexL> В данном контексте я так понимаю - под малой точностью - понимается малая разрядность обрабатываемых чисел. Вот я и спрашивая малая - это сколько в данном случае.

Понятно. Про 32-х разрядность - забудьте, реально - float нужен 64-битный. Задумайтесь например почему в компьютере доступных значений чисел от 0 до 1 о от 1 до max floa - одинаковое количество.

Татарин>>> Там же было долгое обсуждение вопроса... пришли к мнению, что овчинка выделки не стОит: гораздо сложнее программирование и оптимизация и никакой переносимости, а выигрыш - не столь уж и велик... Тем паче, что по цене хорошей видеокарты можно поставить дополнительную пару процов. Обычный кластер получался выгоднее, тем более, что его апгрейдить куда легче.
Murkt>> Переносимость есть - OpenGL везде одинаков, а управляющее приложение без разницы на чём писать - C++, Python, Perl, Java.
Татарин> Я, конечно, не эксперт в OpenGL, знаю только самые азы, но как его вообще там присобачить? через что?

Через шейдеры. Данные в float-текстуру, шейдерами считаем.

Murkt>> Выигрыш уже огромен.
Татарин> Уже огромен - сколько, где, на чём?

Я же привёл пример того же Foldinghome. Где-то 40 раз между Core 2 Duo топовым и Radeon 1900 XTX. На данный момент уже есть видеокарточки гораздо мощнее.

В.М.> А насчет НИР - увы, но в части вычислений пока именно промышленность (САЕ-промышленность имется ввиду) в эти самые НИР больше вкладывает и, потому, все спецы именно там...

И вот интересно, почему же в рейтрейсинге есть уже работающие образцы (тот же Gelato), а в CAE - нет? Рейтрейсинг - тоже ничего себе промышленность, хоть и в другую степь. Хоть и денег там меньше гораздо.

Murkt>>> Переносимость есть - OpenGL везде одинаков, а управляющее приложение без разницы на чём писать Murkt> А при чём здесь переносимость? Насколько я понимаю термин "переносимость" - это значит что программу писали на Linux под Radeon, а запустить можно на Windows и GeForce.

Вот я и хочу увидеть переносимую управляющую часть программы векторного умножения матриц через OpenGL.

Murkt> Я в первую голову написал, что возможность использовать видеокарту для расчётов сильно зависит от типа вычислений. Только это почему-то никто не прочёл.

Это сказали и Татарин, и я. И даже там сказали, нет 10 кратного преимущества.

Murkt> Почему? За то время, пока процессор обзавёлся четырьмя ядрами вместо двух, а каждое ядро ускорилось пусть в полтора раза (2 * 1.5 = 3), у видеокарточек количество шейдерных процессоров выросло с 16-и (вроде столко было), до 128-и, а частота с где-то 600 МГц до 1.2 ГГц (GeForce 8800 GTX). Прирост - шестнадцать против трёх. А насчёт более сложных расчётов - кто-то вообще будет спорить о том, что на четвёртых шейдерах можно сделать гораздо более сложные вещи, чем на вторых? У которых не было динамического ветвления, например, и была очень ограничена длина шейдера (255 инструкций, вроде бы).

Потому что так производительность не считают. Умножение, а тем более плавающее деление от тактовой линейно не зависит. Да и со сложением есть сложности. Начиная с проблем нормализации.

Murkt>> Я в первую голову написал, что возможность использовать видеокарту для расчётов сильно зависит от типа вычислений. Только это почему-то никто не прочёл.
Mishka> Это сказали и Татарин, и я. И даже там сказали, нет 10 кратного преимущества.

Стоп. Подтверждение? Ваше личное мнение? У меня есть более... кхмм... аргументированное мнение - и согласно ему, достигаемое преимущество более десяти раз. Давайте сначала ответите на этот вопрос.

Murkt>> Почему? За то время, пока процессор обзавёлся четырьмя ядрами вместо двух, а каждое ядро ускорилось пусть в полтора раза (2 * 1.5 = 3), у видеокарточек количество шейдерных процессоров выросло с 16-и (вроде столко было), до 128-и, а частота с где-то 600 МГц до 1.2 ГГц (GeForce 8800 GTX). Прирост - шестнадцать против трёх. А насчёт более сложных расчётов - кто-то вообще будет спорить о том, что на четвёртых шейдерах можно сделать гораздо более сложные вещи, чем на вторых? У которых не было динамического ветвления, например, и была очень ограничена длина шейдера (255 инструкций, вроде бы).
Mishka> Потому что так производительность не считают. Умножение, а тем более плавающее деление от тактовой линейно не зависит. Да и со сложением есть сложности. Начиная с проблем нормализации.

Хорошо, вычислительная мощность видеопроцессора выросла не в шестнадцать раз. Но ведь вычислительная мощность обычного процессора тогда тоже не в три раза выросла. Померяем просто скорость роста - всё равно видеопроцессор растёт в чистой производительности раз в пять быстрее обычного процессора. Даже если он стал всего вдвое быстрее - то ЦП стал быстрее процентов на 20.

Mishka> Скажем, некоторый опыт работы с векторными системами и распаралелливанием. На отдельных очень узких задачах может и будет больше. Но только на таких. Например, умножение на два в векторном варианте — там играет чисто количество процев. А вот с делением на 3 уже будет по другому. Особенно для больших чисел.

Так я и сказал что прирост сильно зависит от типа вычислений. А вы сказали, как будто в принципе практически нереально достичь прироста больше десяти раз, даже на очень узких задачах.

В.М.> Вы ребята не путайте т.н. "расчет физики" для игрушк и обычные инженерные расчты. Я с большим любопытсвоам послушаю о реально работающих системах расчeта например "сил-нагрузок-напряжний" МКЭ с использованием видеокарточек

Да дофига этого, читайте. Сразу скажу что этот народ знает что такое точность вычислений Считают силы например в N-body problem, ускорение вычисления относительно CPU и спецвычислителя (да, они делали себе маспар спецвычислитель для ускорения, со спецпроцессорами и архитектурой — всё вот так серьёзно:). Результаты в работах приводятся.

High-performance direct gravitational N-body simulations on graphics processing units
New Astronomy, Volume 12, Issue 8, November 2007, Pages 641-650
Simon F. Portegies Zwart, Robert G. Belleman and Peter M. Geldof

Large steps in GPU-based deformable bodies simulation
Simulation Modelling Practice and Theory, Volume 13, Issue 8, November 2005, Pages 703-715
Eduardo Tejada and Thomas Ertl

Performance analysis of direct N-body algorithms on special-purpose supercomputers
New Astronomy, Volume 12, Issue 5, July 2007, Pages 357-377
Stefan Harfst, Alessia Gualandris, David Merritt, Rainer Spurzem, Simon Portegies Zwart and Peter Berczik

Implementation and performance evaluation of reconstruction algorithms on graphics processors
Journal of Structural Biology, Volume 157, Issue 1, January 2007, Pages 288-295
Daniel Castaño Díez, Hannes Mueller and Achilleas S. Frangakis

Visual simulation of shallow-water waves
Simulation Modelling Practice and Theory, Volume 13, Issue 8, November 2005, Pages 716-726
T.R. Hagen, J.M. Hjelmervik, K.-A. Lie, J.R. Natvig and M. Ofstad Henriksen

Quantum Monte Carlo on graphical processing units
Computer Physics Communications, Volume 177, Issue 3, 1 August 2007, Pages 298-306
Amos G. Anderson, William A. Goddard III and Peter Schröder

Lattice QCD as a video game
Computer Physics Communications, Volume 177, Issue 8, 15 October 2007, Pages 631-639
Győző I. Egri, Zoltán Fodor, Christian Hoelbling, Sándor D. Katz, Dániel Nógrádi and Kálmán K. Szabó

Mass-spring systems on the GPU
Simulation Modelling Practice and Theory, Volume 13, Issue 8, November 2005, Pages 693-702
Joachim Georgii and Rüdiger Westermann

и т.д., это только самые свежие.

з.ы. Вот детальные примеры:

High-performance direct gravitational N-body simulations on graphics processing units
10.1016/j.newast.2007.05.004
We present the results of gravitational direct N-body simulations using the commercial graphics processing units (GPU) NVIDIA Quadro FX1400 and GeForce 8800GTX, and compare the results with GRAPE-6Af special purpose hardware. The force evaluation of the N-body problem was implemented in Cg using the GPU directly to speed-up the calculations. The integration of the equations of motions were, running on the host computer, implemented in C using the 4th order predictor–corrector Hermite integrator with block time steps. We find that for a large number of particles ( N~ >10⁴ ) modern graphics processing units offer an attractive low cost alternative to GRAPE special purpose hardware. A modern GPU continues to give a relatively flat scaling with the number of particles, comparable to that of the GRAPE. The GRAPE is designed to reach double precision, whereas the GPU is intrinsically single-precision. For relatively large time steps, the total energy of the N-body system was conserved better than to one in 10⁶ on the GPU, which is impressive given the single-precision nature of the GPU. For the same time steps, the GRAPE gave somewhat more accurate results, by about an order of magnitude. However, smaller time steps allowed more energy accuracy on the grape, around 10^−11, whereas for the GPU machine precision saturates around 10^−6 . For N~>10⁶ the GeForce 8800GTX was about 20 times faster than the host computer. Though still about a factor of a few slower than GRAPE, modern GPUs outperform GRAPE in their low cost, long mean time between failure and the much larger onboard memory; the GRAPE-6Af holds at most 256k particles whereas the GeForce 8800GTX can hold 9 million particles in memory.

Lattice QCD as a video game
10.1016/j.cpc.2007.06.005
The speed, bandwidth and cost characteristics of today's PC graphics cards make them an attractive target as general purpose computational platforms. High performance can be achieved also for lattice simulations but the actual implementation can be cumbersome. This paper outlines the architecture and programming model of modern graphics cards for the lattice practitioner with the goal of exploiting these chips for Monte Carlo simulations. Sample code is also given.

Fig. 1 and Fig. 2 show sustained performances for both Wilson and staggered matrix multiplication on various lattice sizes and a comparison is given with SSE optimized CPU codes on an Intel P4. ... For reference we give some numbers from Fig. 1 for the NVIDIA 8800 GTX card: 33 Gflops sustained performance on a 163×60 lattice using the Wilson kernel. ... As reference we list below the specification of the NVIDIA 8800 GTX card: 128 fragment processors, 1350 MHz clock speed, 768 MB DDR3 memory at 1800 MHz, 384 bit wide bus, 86.4 GB/s peak memory bandwidth.

 

Сравнивали с 3ГГц пнём-4 и оптимизированным под SSE2 кодом, в 15~20 медленнее он считает эти матрицы.
Вот там ещё референс возможно интересный: IDAV: Publications

Mass-spring systems on the GPU
10.1016/j.simpat.2005.08.004
We present and analyze different implementations of mass-spring systems for interactive simulation of deformable surfaces on graphics processing units (GPUs). For the amount of springs we target, numerical time integration of spring displacements needs to be accelerated and the transfer of displaced point positions for rendering must be avoided. To fulfill these requirements, we exploit features of recent graphics accelerators to simulate spring elongation and compression on the GPU, saving displaced point masses in graphics memory, and then sending these positions through the GPU again to render the deformed surface. Two different simulation algorithms implementing scattering and gathering operations on the GPU are compared with respect to performance and numerical accuracy. We discuss GPU specific issues to be considered in simulation techniques showing similar computation and memory access patterns to mass-spring systems.
(В 32-бит точности считали они.)

Murkt> Так я и сказал что прирост сильно зависит от типа вычислений. А вы сказали, как будто в принципе практически нереально достичь прироста больше десяти раз, даже на очень узких задачах.

Блин, цитирую сообщение нумер 3:
Murkt> До десяти раз... Зависит от видеокарты, типа вычислений и программиста. Можно выдавить гораздо больше, чем десять раз. Да, можно, достаточно несложно.

У меня впечатление от прочитанного такое. Зависит от типа. Но, поскольку нет упоминания про узость области применения, то воспринимается как обобщение — зависит от типа, но таких типов много. И, главное, не сложно достичь и более 10. Причём вот это выдаливание уже стоит после фразы про зависимость. Поэтому зависимость сюда и не относится вроде. Но это моё прочтение.

au> Сравнивали с 3ГГц пнём-4 и оптимизированным под SSE2 кодом, в 15~20 медленнее он считает эти матрицы.

Я увидел только SSE, но не SSE2. Точность тоже одиночная.

А так на спецзадачах 128 ядер будут очень быстрыми.

В.М.>> А насчет НИР - увы, но в части вычислений пока именно промышленность (САЕ-промышленность имется ввиду) в эти самые НИР больше вкладывает и, потому, все спецы именно там...
Murkt> И вот интересно, почему же в рейтрейсинге есть уже работающие образцы (тот же Gelato), а в CAE - нет? Рейтрейсинг - тоже ничего себе промышленность, хоть и в другую степь. Хоть и денег там меньше гораздо.

Потому, что штука - простая и точности особой не требующая. Пиксел влево-вправо никого особо не пугает..

В.М.>> Вы ребята не путайте т.н. "расчет физики" для игрушк и обычные инженерные расчты. Я с большим любопытсвоам послушаю о реально работающих системах расчeта например "сил-нагрузок-напряжний" МКЭ с использованием видеокарточек
au> Да дофига этого, читайте. Сразу скажу что этот народ знает что такое точность вычислений Считают силы например в N-body problem, ускорение вычисления относительно CPU и спецвычислителя


Про спецвычислители -я в курсе, промышленность (САЕ) их любит, но вот про использование на практике именно видеокарт для этого - нет..

au>> Сравнивали с 3ГГц пнём-4 и оптимизированным под SSE2 кодом, в 15~20 медленнее он считает эти матрицы.
Mishka> Я увидел только SSE, но не SSE2. Точность тоже одиночная.

Верно, SSE. Руками было печатано среди ночи, видимо увлёкся. Но клиент доволен, а его суровая задача всё посчиталось, речь как раз об этом. И точность можно поднять ценой производительности и алгоритмическими ухищрениями, и 64 бита будут в GPU, или уже есть.
10.1016/j.newast.2007.07.004: High performance direct gravitational N-body simulations on graphics processing units II: An implementation in CUDA


GeForce 8800 - Technical Specifications

В.М.> Про спецвычислители -я в курсе, промышленность (САЕ) их любит, но вот про использование на практике именно видеокарт для этого - нет..

Ёмаё, для кого я лазил в эту GPU-астрономию-физику...

Murkt>> Так я и сказал что прирост сильно зависит от типа вычислений. А вы сказали, как будто в принципе практически нереально достичь прироста больше десяти раз, даже на очень узких задачах.
Mishka> Блин, цитирую сообщение нумер 3:
Murkt>> До десяти раз... Зависит от видеокарты, типа вычислений и программиста. Можно выдавить гораздо больше, чем десять раз. Да, можно, достаточно несложно.
Mishka> У меня впечатление от прочитанного такое. Зависит от типа. Но, поскольку нет упоминания про узость области применения, то воспринимается как обобщение — зависит от типа, но таких типов много. И, главное, не сложно достичь и более 10. Причём вот это выдаливание уже стоит после фразы про зависимость. Поэтому зависимость сюда и не относится вроде. Но это моё прочтение.

Ладно, мы друг друга не очень хорошо поняли.


Владимир Малюх, как вы себе представляете вот это "пиксель туда, пиксель сюда"?

В.М.>> Про спецвычислители -я в курсе, промышленность (САЕ) их любит, но вот про использование на практике именно видеокарт для этого - нет..
au> Ёмаё, для кого я лазил в эту GPU-астрономию-физику...

Для меня, я же сказал - я не в курсе, а не то "нету вааще" Уж не знаю зачем это астрономам понадобилось, но - всякие САПР заточенные исходнона OpenGL И наличие приличной видокарты, тем не менее "не чешутся" заточить встроенные вычислительные модули на ее использование. Даже не копаясь в деталях - не думаю, что от того, что "в голову не приходило"..

Murkt> Владимир Малюх, как вы себе представляете вот это "пиксель туда, пиксель сюда"?

Очень даже представляю - "разброс" цвета результирующего пикселя в картинке, полученной рейтресингом мало кого волнует на фоне всех упрощений и допущений...

Murkt>> Владимир Малюх, как вы себе представляете вот это "пиксель туда, пиксель сюда"?
В.М.> Очень даже представляю - "разброс" цвета результирующего пикселя в картинке, полученной рейтресингом мало кого волнует на фоне всех упрощений и допущений...

С одной стороны оно конечно да - кому какая разница, будет там цвет (255, 120, 32) или (250, 125, 30). Но как вы себе технически представляете вот это "пиксель туда, пиксель сюда"? Ошиблись в расчёте координаты, и луч промахнулся на пару пикселей? Там ведь не восьмибитная точность.

В.М.> Уж не знаю зачем это астрономам понадобилось, но - всякие САПР заточенные исходнона OpenGL И наличие приличной видокарты, тем не менее "не чешутся" заточить встроенные вычислительные модули на ее использование. Даже не копаясь в деталях - не думаю, что от того, что "в голову не приходило"..

Астрономы те считают гравитационную динамику тучи из N частиц, до миллиона. На пнях у них столько вообще не считается (нету цифр), а до сих пор они считали на спецвычислителе (маспар где этот расчёт развёрнут в самой схеме — зверь-машина). Но тот комп им обошёлся в 4 лимона, а GPU с точностью и скоростью похуже, но с ценой на четыре порядка ниже, их устроил. И ещё они ждут новых с 64 битами — будет им (и вам тоже?) щастя. Ещё привёл пример расчёта деформации чего-то там, и расчёт квантовой хромодинамики (ядрёна физика) — там тоже везде нужна точность, и её в каждом случае так или иначе достигли, сохранив выигрыш в скорости не хуже чем на порядок. Всё это к тому что люди успешно считают большие задачи с большой точностью на свежих GPU, и готовы отказаться от собственных спецвычислителей в их пользу.

Ну и от себя, потому что меня в своё время кое-то прямо забодал с этими волшебными GPU. Все дела с ними возникли оттого что они просто оказались под рукой и в рабочем состоянии (память, интерфейс, средства разработки). Но нынче прямо в панельку от CPU втыкается модуль с FPGA, в котором можно получить свой ускоритель под свои задачи, как тот спецвычислитель у астрономов, и не связываться с разработкой чипов. Астрономы, кстати, в курсе этого и имеют ввиду. Так что под любой САПР можно иметь зверский спецвычислитель уже сегодня.

Murkt> С одной стороны оно конечно да - кому какая разница, будет там цвет (255, 120, 32) или (250, 125, 30). Но как вы себе технически представляете вот это "пиксель туда, пиксель сюда"? Ошиблись в расчёте координаты, и луч промахнулся на пару пикселей? Там ведь не восьмибитная точность.

"Ошиблись" например в угле отклонения луча...