---------------------------
memcopy benchmark by S.T.A.S.
---------------------------
CPU AuthenticAMD @ 1605 MHz
Test results:

copy method bytes to copy / bandwidth
16,0 Mb 1,0 Mb 64 Kb

fscanfrm.zip: 778 Mb/sec 756 Mb/sec 657 Mb/sec
mov w/GPRs: 850 Mb/sec 816 Mb/sec 666 Mb/sec
mmx (8*qwords): 888 Mb/sec 857 Mb/sec 711 Mb/sec
mmx/movntq: 1338 Mb/sec 1193 Mb/sec 971 Mb/sec
optimized mmx: 1852 Mb/sec 1528 Mb/sec n/a

---------------------------
OK
---------------------------

Похоже частота процессора не решает (MB на KT-400, память 333)

S_T_A_S_ плиз кинь ссылку на PE.inc,
добавил следующие команды:

  or esi, 1fh
  inc esi
  or edi, 1fh
  inc edi

Хочу проверить...
По таймеру меряю fscaner получается попрежнему 448мс на 10 итераций копирования 64Мб.
509700158__memcopy2.Asm

[edited]
Выравнивание как ни странно не причем, прибавление 1 к адресу источника ухудшает скорость до 547мс/640мб = 1185мб/c. Таймер вроде не врет - субьективно пол-секунды уходит на копирование. Ошибок пока не обнаружил, не понятно почему такие расхождения.

Да нет, данные выровнены по странице (4K).
Просто копирование шло в одно и тоже место (edi не увеличивался)

Вот он момент истины, исправил все на места встало. Скорость сразу в 3 раза уменьшилась. Проглядел каюсь

alpet

Что-то PE.inc я щас не найду (где-то на форуме валяется), инет совсем плохой стал. А так как это старая версия, которая заменена новой и не совместимой, то выкладывать его больше не буду :-)
Но в аттаче файл подправленный под стандартные FASM'овые include. (путь к ним в переменной fasminc)


Black_mirror > „Похоже частота процессора не решает (MB на KT-400, память 333)“

Да и на Athlon 1000 точно такие же результаты - ядро проца в ходостую работает, шина процессора 266MHz, так что более быстрая память роли не играет. (возможно только латентность кое-где уменьшает)


_1447249677__memcopy2.Asm

Решил переделать алгоритм поиска. Использовать только три (eax, ecx, edx) регистра для хранения множества (64 бита). Проблема попрежнему в переходе пакетного цикла (четверть времени выполнения пожирает). Думаю сделать опять на сдвигах как и раньше, однако команда ROR мне не нравиться, с издавна она много тактов потребляет.
Упаковка тоже работает не важно - проверяет в памяти значения, при не равенстве заменяет, при равенстве увеличивает количество совпадений. Не подскажите как ее на MMX сделать можно?
Скоро буду внедрять SMC, для этого придется все делать в отдельном .asm файле, что в принципе и к лучшему - цикл можно будет макросами развернуть.


_1256069317__fscanfrm.zip

alpet > „Проблема попрежнему в переходе пакетного цикла (четверть времени выполнения пожирает).“

Если ты о чтении DWORd'ов которые пересекают границу линеек кеша, то IMHO лучше так и оставить - аппаратные способности проца сдвигами не превзойдёшь..

Хотя ещё лучше IMHO - читать байтами, как я раньше говорил -
самое главное - вместо 3х циклов для BYTE, WORD, DWORD будет всего один!


> „команда ROR мне не нравиться, с издавна она много тактов потребляет. “

Нет, не издавна, а со времён 4го пня :-)

Не знаю как на других процах, но на Celeron'e со свигами есть небольшой выигрыш: 140 против 172 миллисекунд.
ROR еще на 486 могла до 1 такта на сдвиг тратить (30 макс), жаль нет более быстрой альтернативы.
Доработаю алгоритм посмотрим.

Ну, времена 486 уже давно прошли, вот что в доках AMD написано (если я правильно понял):

Instruction Mnemonic	First Byte	Second Byte	ModR/M Byte	Decode Type	Execute Latency	Note
ROR mreg16/32, imm8	C1h				11-001-xxx	DirectPath	1		3

Notes:
3. The clock count, regardless of the number of shifts or rotates as determined by CL or imm8.

Вот на PIV core сдвиги медленные :-/ а ротации ещё хуже :(

Вот я и хочу посильнее размазать этот код по телу цикла, чтобы и 30 тактов не сильно замедлили работу остального алгоритма. Конечно 30 тактов не будет, максимальный сдвиг на 8, соответствующим будет и количество тактов. Было бы здорово это проверить на VTune, да пока нет его.
Есть идея вынести весь код который обращается к смежным линейкам, в отдельный цикл, и смещения которые от него будут получаться, отсеивать тоже отдельным циклом. У кого нибудь есть соображения на этот счет?

Кстати, по VTune (я им не пользовался никогда, и нет у меня его).. аналогичная тулза от AMD (CodeAnalyst) требует наличае PDB файла. А эти файлы далеко не каждый компилятор создаёт, как я знаю.

Крис Касперски утверждает что для полноценной оптимизации нужны обе проги, Intel Compliler 7.0 (+VTune) у меня триальный закачан, правда триал недавно кончился, а я так и не попробывал. По описанию VTune, информации много выдает, в том числе безполезной и вредной для оптимизации, но не смотря на это более мощный чем CodeAnalyst.
Вот еще вопрос: ROR/ROL для 8 разрядного сдвига можно заменить чем нибудь из MMX, вообще MMX код применим для работы на стыках кеш-линеек?

Вот значит алгоритм поиска на сдвигах. На 64Мб тратит 141мс (495мб/c). Правда код еще не "размазан" и не распараллелен, есть дополнительные расходы из-за недостатка регистров (это будет решаться с помощью SMC).

а вот аттач, с первой (2,3,4,5,6) попытки не отправилось.

1214971353__fscanfrm.zip

Выдалось время, написал макросный вариант. Уже используется SMC для ограничения цикла. После его внедрения я код стал выполнятся быстрее, потому что до этого esi сравнивался с ячейкой памяти, которую процессору приходилось извлекать из кэша.
Сравнительное время выполнения: 490Mb/s для предыдущего варианта, и 537Mb/s для нового.
В конечном варианте будут изменятся все комманды cmp и setcc. Есть вариант использовать пару команд seta и setb, для составления множеств. Тогда после завершения итерации цикла, можно будет получить любой из вариантов >, <, =, != простыми операциями с полученными множествами. Однако в этом случае регистры быстро забьются поэтому цикл удастся развернуть только до 32 раз, да и скорость поиска вероятно упадет.

_907107893__FScan.zip