Прошу высказаться о возможностях ускорения кода, путем грамотного его написанья для указанных ниже кусков. Т.е. есть ли здесь какие-то приемы, позволяющие получить максимально быструю программу?
25.07.2011 15:15, reseacher2011 пишет:
> Прошу высказаться о возможностях ускорения кода, путем грамотного его > написанья для указанных ниже кусков. Т.е. есть ли здесь какие-то приемы, > позволяющие получить максимально быструю программу? > > void dot_product(const double* x,const double* y,double *scalar){ > *scalar = *x*(*y)+*(x+1)*(*(y+1))+*(x+2)*(*(y+2)); > } > void cross_product(const double* x,const double* y,double *vector){ > *vector = *(x+1)*(*(y+2)) — *(x+2)*(*(y+1)); > *(vector+1) = — ( *x*(*(y+2)) — *(x+2)*(*y) ); > *(vector+2) = *x*(*(y+1)) — *(x+1)*(*y) ; > } > void module(const double *vect,double *mod){ > *mod = sqrt(pow(*vect,2.)+pow(*(vect+1),2.)+pow(*(vect+2),2.));
Жесть.
Переписал бы ты сначала все нормальным языком, чтобы читать можно было
(не бойся никто твой код не уворует, не надо так его обфусцировать).
А потом запустил бы профилеровщик, посмотрел где и что и почему медленно.
1) Сообщу на всякий случай, что double *x и double x[3] в описании ПАРАМЕТРОВ функции ОБОЗНАЧАЮТ ОДНО И ТО ЖЕ
2) Ещё сообщу, что для указателей записи *(x+1) и x[1] ТОЖЕ ЭКВИВАЛЕНТНЫ.
А что касается ускорения, то хорошо бы ПОНЯТНО объяснить, что надо сделать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
V>Жесть. V>Переписал бы ты сначала все нормальным языком, чтобы читать можно было V>(не бойся никто твой код не уворует, не надо так его обфусцировать).
Здравствуйте, reseacher2011, Вы писали:
R>Прошу высказаться о возможностях ускорения кода, путем грамотного его написанья для указанных ниже кусков. Т.е. есть ли здесь какие-то приемы, позволяющие получить максимально быструю программу?
1. Переписать более простым и понятным способом.
2. Посмотреть в сторону OpenMP. Вроде технология специально создавалась под многоядерность.
То, что я читал — довольно просто и понятно. Сам собираюсь пробовать в ближайшее время.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
25.07.2011 15:34, reseacher2011 пишет:
> мне нужно на C.
Только у тебя все падежи неправильные. Зачем ты индексацию выкинул?
Пиши нормальным языком x[i].
25.07.2011 15:32, Erop пишет:
> > 1) Сообщу на всякий случай, что double *x и double x[3] в описании > ПАРАМЕТРОВ функции ОБОЗНАЧАЮТ ОДНО И ТО ЖЕ > 2) Ещё сообщу, что для указателей записи *(x+1) и x[1] ТОЖЕ ЭКВИВАЛЕНТНЫ. > > Так что лучше писать ПОНЯТНЕЕ > > double dot_product(const double x[],const double y[]) > { > return x[0]*y[0] + x[1]*y[1] + x[2]*y[2]; > } >
Терпелив ты, однако.
E>1) Сообщу на всякий случай, что double *x и double x[3] в описании ПАРАМЕТРОВ функции ОБОЗНАЧАЮТ ОДНО И ТО ЖЕ E>2) Ещё сообщу, что для указателей записи *(x+1) и x[1] ТОЖЕ ЭКВИВАЛЕНТНЫ. E>Так что лучше писать ПОНЯТНЕЕ
согласен, что x[2] понятнее. Скорость работы *(x+2) и x[2] одинакова?
E>А что касается ускорения, то хорошо бы ПОНЯТНО объяснить, что надо сделать...
требуется написать процедуру, которая быстро заполнить матрицу больших размеров — это matrix_maker. Процедура пишется для numpy/ctypes из-за того, что ее аналог в Питон работает несколько суток.
25.07.2011 15:35, LaptevVV пишет:
> 2. Посмотреть в сторону OpenMP. Вроде технология специально создавалась > под многоядерность. > То, что я читал — довольно просто и понятно. Сам собираюсь пробовать в > ближайшее время.
Вообще-то надо четко осознавать где и для чего она нужна, какие вещи
нужно расспараллеливать, а какие нет.
Думаю, к этому автору еще рано идти.
Здравствуйте, Vzhyk, Вы писали:
V>Вообще-то надо четко осознавать где и для чего она нужна, какие вещи V>нужно расспараллеливать, а какие нет. V>Думаю, к этому автору еще рано идти.
я в вопросе написал " о возможностях ускорения кода, путем грамотного его написанья для указанных ниже кусков.", потому что прекрасно знаю о существовании того же OpenMP и в дальнейшем несколькими директивами распараллелю внешний цикл в matrix_maker.
Здравствуйте, reseacher2011, Вы писали:
LVV>>1. Переписать более простым и понятным способом. R>не нашел ответы на вопросы R>1. равны ли в скорости *(x+i) b x[i]?
равны R>1.5. при заполнении матрицы все таки использование ++mtx будет быстрее?
да R>2. я думал что module(vector,&scalar) будет быстрее scalar=module(vector)?
Нет. Какая разница, что передавать в стек — объект или адрес? R>может какие приемы есть и где-то хорошо описаны.
Это все — экономия на спичках. LVV>>2. Посмотреть в сторону OpenMP. Вроде технология специально создавалась под многоядерность. R>расспараллеливание пока не нужно.
Если матрицы большие, то выигрыш может быть существенным.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
25.07.2011 16:07, LaptevVV пишет:
> Если матрицы большие, то выигрыш может быть существенным.
Если матрицы большие то нужно думать о кэшах и скорости памяти.
25.07.2011 15:55, reseacher2011 пишет: > > Вы бы по делу что-то сказали.
Вот по делу:
Переписал бы ты сначала все нормальным языком, чтобы читать можно было.
А потом запустил бы профилеровщик, посмотрел где и что и почему медленно.
Не можешь научиться работать с профилеровщиком, напиши простенький тест,
который делает твою задачу и считает время выполнения.
И потом бы, найдя "бутылочные горлышки" спрашивал бы. А так твой вопрос
выглядит так: "Вот гора нечитаемого кода выполняющего непонять что,
непонять где. Как мне ускорить этого сферического коня в вакууме?"
pow(x,2.) — это специально чтобы подольше считало?
внутри pow(x,a) работает как exp(log(x)*a) — а логарифм и экспонента не самые дешевые операции.
чем помешало vect[0]*vect[0] ?
Здравствуйте, reseacher2011, Вы писали:
R>Прошу высказаться о возможностях ускорения кода, путем грамотного его написанья для указанных ниже кусков. Т.е. есть ли здесь какие-то приемы, позволяющие получить максимально быструю программу?
1. использовать хороший компилятор для используемой платформы.
2. Использовать быструю библиотеку линейной алгебры. (типа ublas+ATLAS, ublas+Intel MKL, EIGEN "http://eigen.tuxfamily.org/index.php?title=Main_Page")
3. Искать профайлером узкие места.
4. Переписать на С без С++ (just joke)
Здравствуйте, Erop, Вы писали:
E>1) Сообщу на всякий случай, что double *x и double x[3] в описании ПАРАМЕТРОВ функции ОБОЗНАЧАЮТ ОДНО И ТО ЖЕ E>Так что лучше писать ПОНЯТНЕЕ E>
Здравствуйте, reseacher2011, Вы писали:
LVV>>1. Переписать более простым и понятным способом.
R>не нашел ответы на вопросы
R>1. равны ли в скорости *(x+i) b x[i]?
Смотрите в асемблерный листинг скомпилированного кода.
R>1.5. при заполнении матрицы все таки использование ++mtx будет быстрее?
Смотрите в асемблерный листинг скомпилированного кода.
R>2. я думал что module(vector,&scalar) будет быстрее scalar=module(vector)?
Может быть быстрее , а может не быть. Сильно зависит от компилятора и внутренностей "module"
R>может какие приемы есть и где-то хорошо описаны.
Здравствуйте, reseacher2011, Вы писали:
R>Прошу высказаться о возможностях ускорения кода, путем грамотного его написанья для указанных ниже кусков. Т.е. есть ли здесь какие-то приемы, позволяющие получить максимально быструю программу?
тут все очень плохо с точки зрения алиасинга.
Компилятор не знает, могут ли разные указатели указывать на одно и то же, и поэтмоу после каждого присваивания будет перечитывать значения из памяти — а вдруг ты туда только что и записал как раз?
Я так понимаю, у тебя невозможно, чтобы аргументы указывали на одну и ту же память, даже со сдвигами.
Тогда используй restrict на всех своих параметрах-указателях.
Также используй локальные переменные — с ними компилятору гораздо легче справляться, так как они точно алиаситься не будут и их можно спокойно по регистрам раскидать: