Mr.TyanVary
> Из за чего так получается?
Вопрос к vidia. Единственная карта которая более-менее быстро работает с даблами - это 580-я. Но и она это далает за 8 тактов (680-я, как я сказал, за 24). Титан - за три. Оцени разницу.
san
> Не понял посыл.
VirT уже обьяснил :)
Mr.TyanVary
> А что вообще не так с динбранчом? Много слышал что он плох, но чем именно нет.
До недавнего времени было так: если в пределах одного блока/варпа вычисления идут по разным веткам - всё становится печально. Либо часть блока простаивает, либо приходится выполнять обе ветки.
> А с даблами в чем проблема? По мимо размерности они чем то отличаются от флоатов?
До недавнего времени видеокарты NVIDIA не умели нормально даже флоаты - для этого был отдельный блок, у которого огромный latency и их просто не хватало. Даблы же эмулировались, что было ровно в два раза медленнее.
VirT
> Если варп целиком идет по одной ветке, то все ок, если нет, то выполняются оба
> условия с маскировкой, нет?
Ну и это называется нормальный бранч?:)
bazhenovc
> > Не понял посыл.
> VirT уже обьяснил :)
Обьяснил что? Имеем паралельные вычисления которые должны быть завершены, когда ВСЕ процессора закончат работу. Т.е. единственный РЕАЛЬНЫЙ метод ускорения - если процессора уже закончившие вычисления подключаются к тем, кто ее еще не выполнил. Тогда будет 100% загрузки. Но вопрос - а как это сделать практически? Как распаралелить цикл на лету? Я (может тупой), но не вижу никакого решения.
bazhenovc
> Ну и это называется нормальный бранч?:)
Не могу утверждать обратного, т.к. не могу предложить альтернативный вариант :)
san
> Т.е. единственный РЕАЛЬНЫЙ метод ускорения - если процессора уже закончившие
> вычисления подключаются к тем, кто ее еще не выполнил. Тогда будет 100%
> загрузки. Но вороос - а как это сделать практически? Как распаралелить цикл на
> лету?
Вообще-то как-то так оно и работает... Ядро никогда не выполняет один поток до конца. Практически на каждом такте меняется выполняемый варп. Это делается, чтобы скрыть задержку доступа к памяти.
bazhenovc
> До недавнего времени видеокарты NVIDIA не умели нормально даже флоаты - для
> этого был отдельный блок, у которого огромный latency и их просто не хватало

VirT
> Вообще-то как-то так оно и работает... Ядро никогда не выполняет один поток до
> конца. Практически на каждом такте меняется выполняемый варп.
В моем случае (и наверно в 90% других) - нереально. Любой цикл работает с данными полученными на ПРЕДЫДУЩЕМ проходе. Как его можно параллелить?
Возьми самый обычный цикл, например:
float rez=0;
for (int i=0;i<20;i++)
{
rez+=sin(rez+i);
}
И как его распаралелить?
san
разбить на n циклов , результат выполнения сложить
san
Это как-раз легко. Считаем 20 синусов и потом пирамидально суммируем.
Dron09
> разбить на n циклов , результат выполнения сложить
>
Ну расскажи, как это сделать. Алгоритм в студию!
FROL
> Это как-раз легко. Считаем 20 синусов и потом пирамидально суммируем.
Ага. Я чуток изменил формулу. Попробуй распаралелить.
san
> Я чуток изменил формулу
так не честно, изначально предложенный цикл отлично распараллеливался :)
> Ну расскажи, как это сделать
первая ссылка в гугле http://www.aptech.com/questions/loops-and-multithreading/
Dron09
> так не честно, изначально предложенный цикл отлично распараллеливался :)
Ну так это более-менее реальный случай. Вот мой обычный цикл:
vec3 p= pos;
for (i=0;i<20; i++)
{
p=clamp(p,-1,1)*2.0-p;
p/=dot(p,p);
p*=scale;
}
Нифига он не распаралеливается.
Собственно разговор то не о нем, а о Титане...
Так вообщем получается чем больше ядер тем меньше будут потери от бранчинга? (ну из за простоя ALU?)
Или я чтото не довкурил?
А у титана ещё и кэш есть, получается у него обращения к текстурам будет быстрее или какую там роль играет кэш вообще?
bazhenovc
> До недавнего времени было так: если в пределах одного блока/варпа вычисления
> идут по разным веткам - всё становится печально. Либо часть блока простаивает,
> либо приходится выполнять обе ветки.
На CPU тоже нельзя половине SSE регистра сделать одну операцию, а второй половине -- другую. Обычные ограничения векторной архитектуры. Надо подгонять алгоритмы под размер варпа. Например, лучше считать недозаполненым варпом, чем полным, но с бранчем.
san
> Ага. Я чуток изменил формулу. Попробуй распаралелить.
Это не параллелится. Но достаточно большой процент задач можно решать на параллельных машинах. Другое дело, что часто стандартный алгоритм не подходит и надо придумывать параллельный.
Тема в архиве.