Свежие комментарии

ArBB тоже работает над скалярами. смысл в том, чтобы писать код в "stream" терминах, явно указывать какие элементы зависимы, а какие нет. если элементы не зависимы, то делается AVX + openmp. язык примерно как у CUDA.

До меня доперло.

Вы же на четырех ядрах упражнялись. А я - на одном.
Если урезать осетра разделить вчетверо, то как раз нужные ~500-600Mb/sec у вас и получилось. У меня доходит до over 9000 720, но и мегагерцев поболее будет.

Собственно, в регистре 16 байт, 720/16 = 45 млн. обработок вектора на ядре, на четырех ядрах было бы 1.8e+8. Разница в тактовых частотах: 4500/3800 = 1.18, разница в быстродействии 1.8/1.4=1.28, получается ISPC ручной код маленько уделал :).

Правда не факт, что встроенная реализация exp(log()) у ISPC такая же точная, как обсуждаемая. Ну и скорость памяти тоже важна, просто на чтение-запись должно процентов 15 уходить.

О, нашел.

--math-lib=fast

fast отчего-то банально медленнее у меня, чем default. Разбираться лень :)

Увы, но для экспоненты там только одна версия, а экспонента жрет чуть меньше половины времени (проверил, заменив pow() на log())

Ну то есть есть еще куда расти: LLVM генерирует код хуже, чем написано ручками, неудивительно :)

1 float - 4 байта.
Т.е. около 2Gb/sec если бы мы только экспоненту считали.

А так как надо и экспоненту и логарифм, то значит надо пополам делить?

Плюс еще ветвление и если оно случилось, то всякий blendps (а проверка всяко есть). Ну то есть интеловские/ispc-шные 700Mb/sec получаются вполне адекватными.

Ну да, все так и делают. Либо по месту дотачивают (для нужной области входных значений), либо в общем виде.
Помянутые libm_sse2_pow(f) и svml_powf4(8) - это почти оно и есть, разве только не инлайны, а честные функции с call (инлайны тоже бывают).

В исходниках ispc, кстати, лежат готовые полиномы (которые потом попадают на вход компилятору и превращаются в инлайны). Вот тут, во второй половине файла: https://github.com/ispc/ispc/blob/master/stdlib.ispc

Только вот насчет e+11 - вы нолики не перепутали?
Ну собственно частота 3.8*1e+9, на 16 инструкций/такт (AVX, dual issue) на 4 ядра = 2.4e+11 flop/s (при очень либеральном способе оценки), это уже в пересчете на скаляры.

Я несколько не в тему, но вот что привлекло мое внимание:

> возведение в степень, которое тоже очень медленное: на SSE/AVX такой функции нет, на FP87 есть, но безобразно медленная

Я в своей работе использую (вернее, использовал) причесанный мною код некого Julien Pommier, который написал очень быстрые (и "достаточно" точные) SSE инлайны для sin, cos, tan, exp и log.

А та же powf(in[i],1/2.4f) - это ведь exp(1/2.4f * log(in[i]))

В диапазоне (0.0001, 1] применение этих приближенных функций дает ошибку до 6,0e-8 (по сравнению с powf)

А скорость такая: На моем i5-2500, разогнанном до 3,8 ГГц при всех 4 ядрах я получил 1,4e+11 обработок 4-компонентных векторов, или 5,6e+11 обработанных float. OpenMP использовал для загрузки всех 4 ядер.

1) int &t=mystruct.a;

Такой финт не сработает?

2) можно ловить exceptions внутри блока (то есть весь код трэда, будет завёрнут в try ()) сохранять их куда-то, и потом уже кидать их вне многонитевого кода. Конечно тут есть свои ограничения (на типы исключений), но это не вина C++. В смысле тот же ispc если и будет многонитвевым, исключений он вообще не будет давать(и опять же придётся делать то что вы описали - играться с флагами, errorState и т.п. в C-style) - в C++ хоть какие-то exceptions, но есть.

Да, я, кстати, обратил внимание. А есть от этого практическая польза прям сейчас? Или это лишь дает нам знать, что внедрение AVX инструкций в Intel OpenCL потребует не так много ресурсов?

OpenCL хотя-бы VEX-prefix команды генерирует, а эта - нет.

Кстати, чем он опять же тоже похож на бету OpenCL - это неиспользование AVX.

Не, я не говорю что его нужно усложнять. сам язык трогать не надо. (ох чувствую придёт C++0x через пару лет с его блэк джэком и шлюхами - будет весело).
Просто добавить прагму как extension в компилятор.
А что кстати с OpenMP не так? Мне беглого поверхностного изучения хватило для использования, и грабли ещё не встречались.
Не хотите в C++, пусть в C - для меня главное чтобы под рукой было.
Просто как-то не кайф иметь лишний dependence для сборки, ну чисто субъективно.

Насколько я понимаю, ArBB - это map-reduce над векторами, ну в первом приближении.
Это тоже ценная штука и многие вещи закроет (и как только будет не в бете и на маке - я туда посмотрю).

А ispc - это совсем другое. Оно не над векторами, оно над скалярами, просто берет этих скаляров по 4(8) в ряд.
Принципиально важно то, что оно условные операторы вполне разумно обрабатывает (естественно, разваливая вычисления на два блока, а потом собирая маской). Не бог весть как трудно вручную, но очень уж занудно.
Работал бы с 16-бит int - цены бы не было машинке.