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

Ну "относительно" же.

8800GTX - 16kb shared, 32kb регистров (8k по 4 байта) на SM, всего 48kb быстрой памяти.
Fermi: 48k shared, 16k L1, 128k регистров. Всего 192kb на SM.

Да, SM тоже подрос, поэтому оно не учетверилось в расчете на единицу SIMD, а удвоилось. С точки зрения блочных алгоритмов - часть утроилась (shared), а часть - удвоилась (регистры).

Это за 4 года, с 2006 по 2010.

Да, все так, но не все так плохо :)

Для алгоритмов, у которых отношение flops/memory небольшое и не растет с размером задачи - вы для внешних GPU окажетесь ограничены PCIe bandwidth. А для внутренних - memory bandwidth (которая в разы больше).

А если flops/mem растет с размером локального блока вычислений (как для dgemm, к примеру), то нагрузка на память уменьшается путем увеличения local/shared mem, что относительно недорого для производителей GPU/APU.

Но, кстати, конструкция Бульдозер+GPU в одном флаконе (т.е. APU, как они их называют) - для вычислений опять несбалансирована, потому что на I/O ничего тратить не надо.
Ну да она и для недорогих десктопов, с другой стороны.

А, ага.

Да, софт придется делать, это не вопрос. Именно придется, потому что гетерогенные архитектуры - это неизбежное ближайшее будущее, да и настоящее уже, что уж там.

> Но на эти два GPU - надо 6 ядер на I/O, четырех мало.

Пусть так. Но этим ядрам не особо то и нужны FPU, верно?

Я вот думаю, что тут расчет у AMD простой: Матрицы перемножать в больших количествах - это на ускорителях (скоро уже и 7xxx серия подоспеет с 2,000 ядрами). А SQL-серверу, web-серверу FPU (практически) не нужен. В последнем абзаце статьи по ссылке об этом как раз упоминается.

Я именно об этом и говорю - строка уже в кеше, и процессор может, но не обязан, это заметить. В любом случае, код некорректен из-за отсутствия fence, и все это мои спекуляции.

Ну так чтение происходит *до* записи, после записи - по тому же адресу ничего не читается.

История обсуждается вот тут в комментариях: http://blog.lexa.ru/2010/12/21/polna_chudes_moguchaya_priroda.html
Это примерно тот же самый код по смыслу: прочитали 4 float, что-то посчитали, записали в то же место.

И на i7-920 у меня получалось, что movntps для записи - заметно быстрее, чем movaps. Для i7-avx принципиальной разницы я не вижу.

Могу поугадывать.

Если тестовым примером был код из http://blog.lexa.ru/2011/09/01/o_kompilyatorakh_i_protsessorakh.html, то хочу обратить внимание, что тут производится кешируемое чтение по тем же страницам, по которым идет WC-запись. Интел называет это неопределенным поведением и требует обязательно использовать как минимум store fence вокруг WC-записей.

Мое предположение состоит в том, что self-snoop на core i7 и старше замечает, что строка уже в кеше, а на старых Core2 нет.

Даже на терабайтных записях кеш помогает за счет более гибкого write coalescing. Писатели драйверов видеокарт давно знают, что линейная запись текстуры в основной памяти и ремап в апертуру в разы быстрее записи через WC-апертуру.

В реальном мире оно как-то без шансов.

У меня данных - 1.6Gb, поэтому кэш уже несущественен.

На i7 movntps (для больших объемов) был заметно быстрее, на i7-AVX я не вижу большой разницы, на Core2 - медленнее и сильно.

Чудеса.

На моём i7 2670QM (2GHz) этот код выдаёт 475 MPix/sec если данные в L2, 450 MPix/sec если данные в L3, и 310 MPix/sec если данные в памяти

SECTION .rdata
align 32
table0 dd 0.44, 0.33, 0.22, 0.11, 0.44, 0.33, 0.22, 0.11
table1 dd 0.88, 0.77, 0.66, 0.55, 0.88, 0.77, 0.66, 0.55
table2 dd 1.04, 1.03, 1.02, 1.01, 1.04, 1.03, 1.02, 1.01

SECTION .text

global convert_pixels

; extern "C" void convert_pixels(const float* source, float* destination, size_t length)
convert_pixels:
; rcx - source
; rdx - destination
; r8 - length

vzeroupper
align 32
.main_processing_loop:
vmovaps ymm0, [rcx]
vmovaps ymm1, [rcx + 32]
vmovaps ymm2, [rcx + 64]
vmovaps ymm3, [rcx + 96]

vmulps ymm4, ymm0, [table0]
vmulps ymm5, ymm0, [table1]
vmulps ymm6, ymm0, [table2]
vmulps ymm7, ymm1, [table0]
vmulps ymm8, ymm1, [table1]
vmulps ymm9, ymm1, [table2]
vmulps ymm10, ymm2, [table0]
vmulps ymm11, ymm2, [table1]
vmulps ymm12, ymm2, [table2]
vmulps ymm13, ymm3, [table0]
vmulps ymm14, ymm3, [table1]
vmulps ymm15, ymm3, [table2]

vhaddps ymm4, ymm4, ymm5
vhaddps ymm6, ymm6, ymm7
vhaddps ymm8, ymm8, ymm9
vhaddps ymm10, ymm10, ymm11
vhaddps ymm12, ymm12, ymm13
vhaddps ymm14, ymm14, ymm15

vhaddps ymm4, ymm4, ymm6
vhaddps ymm8, ymm8, ymm10
vhaddps ymm12, ymm12, ymm14

vmovaps [rdx], ymm4
vmovaps [rdx + 32], ymm8
vmovaps [rdx + 64], ymm12
sub rcx, -128
add rdx, 96
sub r8, 32
jnz .main_processing_loop
vzeroupper

ret

Да, именно это я и предпологал. Писал я генератор псевдослучайных floats и там как раз скалярное произведение. Обрадовался я, и побежал sse4.1 использовать, а на практике оказалось на 15% медленее вручную прописанных mult_ps, add_ps. Но это на core2 было, подумал я что на i7 могли уже допилить до ума. А нет...

В таком духе можно и 256bit вариант написать. Должен быть самый быстрый.

Сделал: http://blog.lexa.ru/2011/09/04/o_kompilyatorakh_i_protsessorakh_avx.html