- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
void MultipleSquareMatrix(Matrix*rres, Matrix*mul1, Matrix* mul2)
{
int N = mul1->height();
Matrix rmul1(N,N);
Matrix rmul2(N,N);
#define SM (CLS / sizeof (double))
for (i = 0; i < N; i += SM)
for (j = 0; j < N; j += SM)
for (k = 0; k < N; k += SM)
for (i2 = 0, rres = &res[i][j],
rmul1 = &mul1[i][k]; i2 < SM;
++i2, rres += N, rmul1 += N)
for (k2 = 0, rmul2 = &mul2[k][j];
k2 < SM; ++k2, rmul2 += N)
for (j2 = 0; j2 < SM; ++j2)
rres[j2] += rmul1[k2] * rmul2[j2];
}
guest 15.01.2011 20:06 # +8
shm 15.01.2011 23:14 # +2
Анонимус 16.01.2011 09:11 # +1
Altravert 16.01.2011 10:03 # +4
guest 16.01.2011 13:34 # +2
Автор, откликнитесь, каким мегаоптимизированным алгоритмом пользовались? Предлагаю закопирайтить эту интелектуальную собственность под своим именем "Метод ***(фамилия)".
rat4 15.01.2011 21:23 # +9
upd: они и ещё и глобальные?! 0_о
inkanus-gray 16.01.2011 19:25 # 0
guest 16.01.2011 20:36 # +4
С++?
Вот:
- класс или структура с конструктором и перегруженым оператором operator[].
guest 16.01.2011 20:45 # −2
dwinner 17.01.2011 07:46 # −4
nsa_a1 17.01.2011 10:01 # 0
guest 17.01.2011 11:43 # +1
nsa_a1 17.01.2011 13:27 # +2
#define CLS 64
#define N 1000
double res[N][N];
double mul1[N][N];
double mul2[N][N];
int main()
{
#define SM (CLS / sizeof (double))
double *rmul1;
double *rmul2;
double *rres;
int i,j,k,i2,j2,k2;
for (i = 0; i < N; i += SM)
for (j = 0; j < N; j += SM)
for (k = 0; k < N; k += SM)
for (i2 = 0, rres = &res[i][j],
rmul1 = &mul1[i][k]; i2 < SM;
++i2, rres += N, rmul1 += N)
for (k2 = 0, rmul2 = &mul2[k][j];
k2 < SM; ++k2, rmul2 += N)
for (j2 = 0; j2 < SM; ++j2)
rres[j2] += rmul1[k2] * rmul2[j2];
return 0;
}
в данном случае длина строка кеша выставлена в 64 байта, такая длина сейчас на большинстве современных Intel Core 2 и Quad.
в линейке процов AMD придется посмотреть в спецификации Cashe line size )
guest 17.01.2011 13:36 # 0
Это часть оптимизации?
guest 17.01.2011 13:37 # −1
Большой прирост хоть?
nsa_a1 17.01.2011 14:12 # 0
guest 17.01.2011 13:39 # 0
nsa_a1 17.01.2011 14:16 # +1
xXx_totalwar 17.01.2011 14:27 # +2
nsa_a1 17.01.2011 14:45 # 0
Так что, Вам в любом случае придется уменьшать количество промахов при обращении в кеш, конечно мы не можем напрямую влиять на кеш, однако можем подстроится под внутреннюю оптимизацию процессора и использовать её в своих целях.
xXx_totalwar 17.01.2011 15:02 # +2
>перемножаем строку на столбец
не так, золотце, вторая матрица транспонируется, не знал? ну вот поэтому я и говорю - байтоебство без знания алгоритмов - как минимум смешно.
nsa_a1 17.01.2011 15:09 # −2
xXx_totalwar 17.01.2011 15:13 # +1
проверь матрицы не 10х10, а 50000х50000 и удивись
а раз этот алгоритм здесь, то какой вывод?
nsa_a1 17.01.2011 15:24 # −2
xXx_totalwar 17.01.2011 15:26 # +2
nsa_a1 17.01.2011 15:30 # 0
nsa_a1 17.01.2011 15:38 # +2
lwn.net/Articles/250967
xXx_totalwar 17.01.2011 15:41 # +3
pushkoff 17.01.2011 15:42 # 0
на PS3 уже давно проще матрицу из кеша перемножить еще раз, чем читать ее из памяти (линия 128 байт)... поищи инфу в блоге Micke Aston...
xXx_totalwar 17.01.2011 15:44 # −5
в твоих
pushkoff 17.01.2011 15:45 # −5
xXx_totalwar 17.01.2011 15:47 # −5
pushkoff 17.01.2011 16:14 # +2
задумайся когда нибудь, что тормозит в твоих программах, и в 99% случаем это будет память... доступ в память мимо кеша это несколько сотен тактов процессора, что равно сотне команд работающих в пределах кеша...
pushkoff 17.01.2011 16:17 # +2
xXx_totalwar 17.01.2011 16:20 # +3
pushkoff 17.01.2011 16:20 # +2
guest 20.05.2016 23:13 # 0
Еще К.К. в "оптимизации программ по памяти" писал про этов 2003м году.
pushkoff 17.01.2011 15:40 # 0
guest 17.01.2011 23:03 # 0
guest 17.01.2011 23:06 # +1
guest 17.01.2011 14:46 # −1
nsa_a1 17.01.2011 14:50 # 0
guest 17.01.2011 14:59 # 0
К примеру, иногда можно это сделать на сопроцессорах, например на видюхе.
nsa_a1 17.01.2011 15:01 # −1
guest 17.01.2011 15:02 # 0
xXx_totalwar 17.01.2011 15:05 # +2
google://кластеры из PS3
guest 17.01.2011 15:15 # −2
xXx_totalwar 17.01.2011 15:16 # +2
TarasB 17.01.2011 14:50 # +1
nsa_a1 17.01.2011 14:57 # +1
xXx_totalwar 17.01.2011 15:07 # +4
serpanok 20.05.2016 18:00 # −1
bormand 20.05.2016 19:09 # +2
inkanus-gray 20.05.2016 23:06 # +2
gost 20.05.2016 22:24 # +2
Прямо связь поколений.
CHayT 20.05.2016 22:39 # +1
gost 20.05.2016 23:02 # +2
CHayT 20.05.2016 23:06 # +2
минусуйте меня
inkanus-gray 20.05.2016 23:15 # 0
CHayT 20.05.2016 23:36 # +1
big O определяется исходя из предпосылки, что время умножения и сложения плавающих петухов константно
guest 17.01.2011 14:55 # +3
Я скорее всего уже безнадёжно отстал от этой области, поэтому не спорю, но:
Где ассемблерные комманды процессора по упреждающему чтению данных в кэш?
Коли так, то это перемножение матриц оптимизированное под кэш конкретного размера.
Процессор сам сделает упреждающую выборку, если сможет. И это заслуга процессора, а не алгоритма.
nsa_a1 17.01.2011 15:02 # +1
Как говорится проще перечислить, когда упреждающая выборка работает хорошо, чем когда она работает плохо. Наша цель сделать так, чтобы она работала на нас, а не против нас.
pushkoff 17.01.2011 15:44 # +4
nsa_a1 17.01.2011 16:01 # −2
пожалуй лучше ссылки не придумать, здесь довольно подробно все рассмотрено.
pushkoff 17.01.2011 16:16 # +6
nsa_a1 17.01.2011 16:47 # 0
pushkoff 17.01.2011 16:53 # 0
nsa_a1 17.01.2011 17:09 # 0
bugmenot 17.01.2011 20:12 # +2
gegMOPO4 17.01.2011 21:34 # +5
Но!
Стиль ужасен. Нет комментариев. Ничего не говорящие имена переменных. #define посреди кода. Какая-то чушь с C++. Наконец, всё это работает только если N кратно SM (восьми).
Итого -- таки говнокод.
nsa_a1 18.01.2011 09:27 # +2
gegMOPO4 18.01.2011 16:15 # 0
nsa_a1 18.01.2011 18:34 # +2
gegMOPO4 21.01.2011 18:04 # +1