Здравствуйте, reseacher2011, Вы писали:


R>согласен, что x[2] понятнее. Скорость работы *(x+2) и x[2] одинакова?
Для указателей да. Одинакова. Эти записи вообще эквивалентны. то есть

x[2] 
*(x + 2)
*(2 + x)
2[x]

ДАЮТ ОДИН И ТОТ ЖЕ КОД.


R>требуется написать процедуру, которая быстро заполнить матрицу больших размеров — это matrix_maker. Процедура пишется для numpy/ctypes из-за того, что ее аналог в Питон работает несколько суток.

А чем надо запонлить матрицу, и что значит "заполнить"? Нужно сформировать файл, данные в памяти, поток данных в трубе. что-то ещё? Почему бы каким-нибудь маткадом не воспользоваться, кстати?

Здравствуйте, Vzhyk, Вы писали:

V>Терпелив ты, однако.

А что делать? Есть, конечно шанс, что это тролль, но мне кажется, что у человека есть какая-то реальная проблема, просто он не смог понятно объяснить что же ему на самом деле-то надо...

Здравствуйте, jazzer, Вы писали:

J>тут все очень плохо с точки зрения алиасинга.
J>Компилятор не знает, могут ли разные указатели указывать на одно и то же, и поэтмоу после каждого присваивания будет перечитывать значения из памяти — а вдруг ты туда только что и записал как раз?
J>Я так понимаю, у тебя невозможно, чтобы аргументы указывали на одну и ту же память, даже со сдвигами.
J>Тогда используй restrict на всех своих параметрах-указателях.

Щито? Я буду очень удивлён, если библиотека векторных операций мне не даст посчитать скалярное произведение одного вектора на самого себя (сиречь квадрат евклидовой нормы, только без лишних операций квадрата и квадратного корня).

Здравствуйте, Centaur, Вы писали:

C>Щито? Я буду очень удивлён, если библиотека векторных операций мне не даст посчитать скалярное произведение одного вектора на самого себя (сиречь квадрат евклидовой нормы, только без лишних операций квадрата и квадратного корня).

Ну так внутри библиотеки restrict используется, вестимо

double dot_same(int n, double* v);
double dot_separate(int n, double* __restrict__ v1, double* __restrict__ v2);
double dot_xz(int n, double* v1, double* v2);
double dot(int n, double* v1, double* v2)
{
  return
    v1 == v2 ? dot_same(n,v1)
             : v1+n > v2 ? dot_separate(n,v1,v2)
                         : dot_xz(n,v1,v2);
}

(за сравнение на "больше" не пинать, я просто идею показываю.)

Либо в документации к функции прямо пишут, можно или нельзя перекрываться, например, memmove и memcpy.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, reseacher2011, Вы писали:
R>не нашел ответы на вопросы
R>1. равны ли в скорости *(x+i) b x[i]?

Да. В C x[i] по определению тождественно *(x+i). И любой вменяемый компилятор сгенерит идентичный код.

R>1.5. при заполнении матрицы все таки использование ++mtx будет быстрее?

Не факт. Умный оптимизирующий компилятор сам догадается, что матрица заполняется последовательно и введёт инкрементирующийся указатель. Или развернёт цикл. Или даже конвейеризирует. И явный изменяющийся указатель может только помешать.

Возможно, удастся и самому помочь компилятору, поменяв местами или направлением циклы. Это легче сделать, записывая всё явно.

R>2. я думал что module(vector,&scalar) будет быстрее scalar=module(vector)?

Отнюдь. В первом случае предполагается результат в памяти, а во втором компилятор спокойно оставит его в регистре сопроцессора. Разумеется, при инлайнинге может догадаться сделать так и в первом случае, но зачем его напрасно утруждать?

Вы его еще GPGPU научите...
Кстати, есть http://www.accelereyes.com/products/jacket