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

Ага, действительно интересно.

Я был уверен, что AVX-вариант умножает вектора длиной 8, но посмотрел в reference - нет, две половинки по 4.

Сделаю обязательно. Плюс, сделаю обязательно векторный вариант с транспонированными матрицами, как 256-битный, так и 128-битный.

Надо бы еще clang/llvm под виндой развернуть....

Есть данные сколько времени современные флэшки хранят информацию?
В свое время было не более пяти лет, в течении которых будет происходить утечка заряда и всё...

Сейчас наверное больше, но нужно будет создавать оптимальные условия. Появляется еще одна аналогия со слайдами - не только сливер и стоимость, но и отдельный "холодильник" для хранения. :)

М-да. У меня gcc 4.6.1 и брать елемент по индексу в векторе умеет.
На моем Core2 Quad Q9500 @ 2.83GHz, 64bit

С и без union-ом код разный получаеться

С union v4u

.L3:
movaps (%rdi,%rax), %xmm0
movl $0x00000000, -12(%rsp)
movaps xmat(%rip), %xmm1
mulps %xmm0, %xmm1
movaps %xmm1, -72(%rsp)
movaps xmat+16(%rip), %xmm1
mulps %xmm0, %xmm1
mulps xmat+32(%rip), %xmm0
movaps %xmm1, -56(%rsp)
movaps %xmm0, -40(%rsp)
movss -72(%rsp), %xmm0
addss -68(%rsp), %xmm0
addss -64(%rsp), %xmm0
addss -60(%rsp), %xmm0
movss %xmm0, -24(%rsp)
movss -56(%rsp), %xmm0
addss -52(%rsp), %xmm0
addss -48(%rsp), %xmm0
addss -44(%rsp), %xmm0
movss %xmm0, -20(%rsp)
movss -40(%rsp), %xmm0
addss -36(%rsp), %xmm0
addss -32(%rsp), %xmm0
addss -28(%rsp), %xmm0
movss %xmm0, -16(%rsp)
movaps -24(%rsp), %xmm0
movaps %xmm0, (%rdi,%rax)
addq $16, %rax
cmpq %rsi, %rax
jne .L3


Без union-а код, как по мне, получше, но черт его знает как быстро инструкция extractps отрабатывает.


.L8:
movaps (%rdi,%rax), %xmm1
movl $0x00000000, -12(%rsp)
movaps xmat(%rip), %xmm3
movaps xmat+16(%rip), %xmm2
mulps %xmm1, %xmm3
mulps %xmm1, %xmm2
mulps xmat+32(%rip), %xmm1
extractps $1, %xmm3, %edx
movaps %xmm3, %xmm0
movd %edx, %xmm4
addss %xmm4, %xmm0
extractps $2, %xmm3, %edx
movd %edx, %xmm4
extractps $3, %xmm3, %edx
movd %edx, %xmm3
extractps $1, %xmm2, %edx
addss %xmm4, %xmm0
movd %edx, %xmm4
extractps $2, %xmm2, %edx
addss %xmm3, %xmm0
movd %edx, %xmm3
extractps $3, %xmm2, %edx
movss %xmm0, -24(%rsp)
movaps %xmm2, %xmm0
addss %xmm4, %xmm0
movd %edx, %xmm4
extractps $1, %xmm1, %edx
movd %edx, %xmm2
extractps $2, %xmm1, %edx
addss %xmm3, %xmm0
movd %edx, %xmm3
extractps $3, %xmm1, %edx
addss %xmm4, %xmm0
movd %edx, %xmm4
movss %xmm0, -20(%rsp)
movaps %xmm1, %xmm0
addss %xmm2, %xmm0
addss %xmm3, %xmm0
addss %xmm4, %xmm0
movss %xmm0, -16(%rsp)
movaps -24(%rsp), %xmm0
movaps %xmm0, (%rdi,%rax)
addq $16, %rax
cmpq %rsi, %rax
jne .L8


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

typedef float __v4sf __attribute__ ((__vector_size__ (16)));
__v4sf xmat2[4] = {{0.17f, 0.55f, 1.01f, 0.0f}, {0.22f, 0.66f, 1.02f, 0.0f}, {0.33f, 0.77f, 1.03f, 0.0f}, {0.44f, 0.88f, 1.04f, 0.0f}}; // weights are transposed

void fdotp_vec3 (__v4sf *d, int sz)
{
__v4sf rr0,rr1,rr2,rr3;
for(int i=0;i

Здесь и без слов понятно, что все на порядок быстрее

.L12:
movaps (%rdi,%rax), %xmm1
movaps xmat2(%rip), %xmm0
movaps xmat2+16(%rip), %xmm2
mulps %xmm1, %xmm0
mulps %xmm1, %xmm2
addps %xmm2, %xmm0
movaps xmat2+32(%rip), %xmm2
mulps %xmm1, %xmm2
mulps xmat2+48(%rip), %xmm1
addps %xmm2, %xmm0
addps %xmm1, %xmm0
movaps %xmm0, (%rdi,%rax)
addq $16, %rax
cmpq %rsi, %rax
jne .L12


Кстати, я также думаю что первый проход по массиву пикселей будет всегда медленней всех последующих. Было бы хорошо проверить.

Да как-то не вижу я ее в 4.6.2:

__v4sf rr0,rr1,rr2,res;
....
res[0] = rr0[0]+rr0[1]+rr0[2]+rr0[3];

Дает: dotp.cpp:172:7: error: invalid types '__v4sf {aka __vector(4) float}[int]' for array subscript

Возможно, я готовлю как-то не так, примеров на вебе как-то совсем мало вменяемых.

$ gcc -v
gcc version 4.6.2 20110826 (prerelease) (FreeBSD Ports Collection)

Вот clang так понимает, только разницы никакой:
dotp_vec(): 130.9 Mpix/sec (15283.4 msec)
dotp_vec2(): 130.6 Mpix/sec (15312.4 msec)

(_vec2 - это без union)

Ну вот у меня в посте ссылка ("например такой") на какой-то китайский универсальный зарядник для 3.7 и 7.4 с питанием от 5В и от 12.
Пока не пробовал.

А вопрос больной, потому что батарей разных набегает много и брать запасных каждого вида очень уж хлопотно.

"лягушка" - это не "от вампирчика", это чистый и незамутненный китай.

А стабилизатор 5В ("от вампирчика") работал на ура и зарядил и книжку и, что более ценно, айфон (который от китайского солнечного зарядника не только не заряжался, но даже просто не включался, току мало).

Ну круто, а то asm встраивать везде по своему надо (AT&T/etc). В VisualStudio x64 asm вообще нельзя встраивать в код, приходится отдельно линковать..

Ну да, оно все раздражает. И трансляция из регистров в имена переменных и разный порядок операндов в командах у gcc и Intel/MS.

С vex-командами (трехадресными) вообще начало сносить крышу:

vdpps xmm11, xmm5, xmm0, 241
против
vdpps $241, %xmm3, %xmm0, %xmm1

Блин.

Такой код бы был хорошо портируемый и с хорошей производительностью, хотя скорее всего не с оптимальной.

intrinsic вроде у каждого компилятора свои, или нет?

Его на intrinsic'и переписывать не очень удобно, мне приходиться для многих инструкций по справке искать ее название в intrinsic'ах.
Iscp хорош, надеюсь в нем уже исправили багу что при target SSE2 в аутпут попадали и SSE4 инструкции.

А чем просто ассемблерный вывод нехорош?

Ну и ispc есть, для векторного случая (т.е. сильно векторизуемых данных) - в самый раз.

OpenCL выиграет только если надо "10 раз".

Ну вот я смотрю в книгу в листинг, вижу разницу
а) в movups/movaps
б) в обработке итераций цикла (как и для i7-1)

Ну не должна быть такая разница от инвариантов. Хрен его знает, конечно.

Ну так "производительность не переносится".
Ну разве только в виде библиотек, заранее написанных на ассемблере, вроде IPP.

Я тут, к удивлению своему, обнаружил, что SSE4.1 (в виде dpps и blendps) есть не на всех Core2. На макбуке 4-летнем (2007-й) процессор T7500, а на нем только SSE3.