ПрограммированиеФорумГрафика

Хто-нить уже имел дело с Титаном? (2 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#15
20:57, 11 мар 2013

Mr.TyanVary
> Из за чего так получается?
Вопрос к vidia. Единственная карта которая более-менее быстро работает с даблами - это 580-я. Но и она это далает за 8 тактов (680-я, как я сказал,  за 24). Титан - за три. Оцени разницу.

#16
20:59, 11 мар 2013

san
> Не понял посыл.
VirT уже обьяснил :)


Mr.TyanVary
> А что вообще не так с динбранчом? Много слышал что он плох, но чем именно нет.
До недавнего времени было так: если в пределах одного блока/варпа вычисления идут по разным веткам - всё становится печально. Либо часть блока простаивает, либо приходится выполнять обе ветки.

> А с даблами в чем проблема? По мимо размерности они чем то отличаются от флоатов?
До недавнего времени видеокарты NVIDIA не умели нормально даже флоаты - для этого был отдельный блок, у которого огромный latency и их просто не хватало. Даблы же эмулировались, что было ровно в два раза медленнее.

VirT
> Если варп целиком идет по одной ветке, то все ок, если нет, то выполняются оба
> условия с маскировкой, нет?
Ну и это называется нормальный бранч?:)

#17
21:08, 11 мар 2013

bazhenovc
> > Не понял посыл.
> VirT уже обьяснил :)
Обьяснил что? Имеем паралельные вычисления которые должны быть завершены, когда ВСЕ процессора закончат работу. Т.е. единственный РЕАЛЬНЫЙ метод ускорения - если процессора уже закончившие вычисления подключаются к тем, кто ее еще не выполнил. Тогда будет 100% загрузки. Но вопрос - а как это сделать практически? Как распаралелить цикл на лету? Я (может тупой), но не вижу никакого решения.

#18
21:08, 11 мар 2013

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

#19
21:11, 11 мар 2013

san
> Т.е. единственный РЕАЛЬНЫЙ метод ускорения - если процессора уже закончившие
> вычисления подключаются к тем, кто ее еще не выполнил. Тогда будет 100%
> загрузки. Но вороос - а как это сделать практически? Как распаралелить цикл на
> лету?
Вообще-то как-то так оно и работает... Ядро никогда не выполняет один поток до конца. Практически на каждом такте меняется выполняемый варп. Это делается, чтобы скрыть задержку доступа к памяти.

#20
21:17, 11 мар 2013

bazhenovc
> До недавнего времени видеокарты NVIDIA не умели нормально даже флоаты - для
> этого был отдельный блок, у которого огромный latency и их просто не хватало
Изображение

#21
21:28, 11 мар 2013

VirT
> Вообще-то как-то так оно и работает... Ядро никогда не выполняет один поток до
> конца. Практически на каждом такте меняется выполняемый варп.

В моем случае (и наверно в 90% других) - нереально. Любой цикл работает с данными полученными на ПРЕДЫДУЩЕМ проходе. Как его можно параллелить?
Возьми самый обычный цикл, например:
float rez=0;
for (int i=0;i<20;i++)
{
    rez+=sin(rez+i);
}
И как его распаралелить?

#22
21:35, 11 мар 2013

san
разбить на n циклов , результат выполнения сложить

#23
21:36, 11 мар 2013

san
Это как-раз легко. Считаем 20 синусов и потом пирамидально суммируем.

#24
21:38, 11 мар 2013

Dron09
> разбить на n циклов , результат выполнения сложить
>
Ну расскажи, как это сделать. Алгоритм в студию!

#25
21:40, 11 мар 2013

FROL
> Это как-раз легко. Считаем 20 синусов и потом пирамидально суммируем.
Ага. Я чуток изменил формулу. Попробуй распаралелить.

#26
21:52, 11 мар 2013

san
> Я чуток изменил формулу
так не честно, изначально предложенный цикл отлично распараллеливался :)
> Ну расскажи, как это сделать
первая ссылка в гугле http://www.aptech.com/questions/loops-and-multithreading/

#27
22:07, 11 мар 2013

Dron09
> так не честно, изначально предложенный цикл отлично распараллеливался :)
Ну так это более-менее реальный случай. Вот мой обычный цикл:
              vec3 p= pos;
  for (i=0;i<20; i++)
  {
    p=clamp(p,-1,1)*2.0-p;
    p/=dot(p,p);
    p*=scale;
    }
Нифига он не распаралеливается.
Собственно разговор то не о нем, а о Титане...

#28
22:10, 11 мар 2013

Так вообщем получается чем больше ядер тем меньше будут потери от бранчинга? (ну из за простоя ALU?)
Или я чтото не довкурил?

А у титана ещё и кэш есть, получается у него обращения к текстурам будет быстрее или какую там роль играет кэш вообще?

#29
22:13, 11 мар 2013

bazhenovc
> До недавнего времени было так: если в пределах одного блока/варпа вычисления
> идут по разным веткам - всё становится печально. Либо часть блока простаивает,
> либо приходится выполнять обе ветки.
На CPU тоже нельзя половине SSE регистра сделать одну операцию, а второй половине -- другую. Обычные ограничения векторной архитектуры. Надо подгонять алгоритмы под размер варпа. Например, лучше считать недозаполненым варпом, чем полным, но с бранчем.

san
> Ага. Я чуток изменил формулу. Попробуй распаралелить.
Это не параллелится. Но достаточно большой процент задач можно решать на параллельных машинах. Другое дело, что часто стандартный алгоритм не подходит и надо придумывать параллельный.

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.