Оптимизация и полиморфный код

S_T_A_S_>

Скорости нового memread2 unrolled:2560 и prefetch: 1084



Что касается memcopy2, на Athlone пока проверить не могу, на Celeron результаты не плохие: 1279Мб/c MMX optimized x 16Mb. Тем не менее проигрывает. Копирование DWORD'ами отстает в 2 раза. Скоро попробую на Athlon 2000XP + 512DDR333 обе проги. Меня заинтересовал результат 1821Мб, это реально! На какой памяти не скажешь?



См. аттач memcopy в действии.

_38519057__memcopy.jpg

 

S_T_A_S_ можешь для сравнения в memcopy мой код копирования перенести? Я надеюсь адреса источника/приемника выровнены по кэш линейкам, иначе максимум небудет показан.

 

Да и ещё я тут пару раз упоминал одну доку, но ссылу оказывается так и не дал =)

 

Добавил код для сравнения

Сначала получились просто сказачные результаты, ~2500Mb/sec, но здраво рассудив, что это не реально на моей машине, нашёл пару мелких и один баг по-больше

Теперь больше похоже на правду - MOVNTQ не обгонишь, т.к. эта команда работает в обход кеша.

<font face="monospace]

Код (Text):

1.  
2. ---------------------------
3.   memcopy benchmark by S.T.A.S.
4. ---------------------------
5. CPU AuthenticAMD @ 1664 MHz
6. Test results:
7.  
8. copy method    bytes to copy / bandwidth
9.         16,0 Mb     1,0 Mb      64 Kb
10.  
11. fscanfrm.zip:   707 Mb/sec  672 Mb/sec  522 Mb/sec
12. mov w/GPRs: 739 Mb/sec  712 Mb/sec  572 Mb/sec
13. mmx (8*qwords): 784 Mb/sec  751 Mb/sec  584 Mb/sec
14. mmx/movntq: 1160 Mb/sec 1009 Mb/sec 755 Mb/sec
15. optimized mmx:  1859 Mb/sec 1416 Mb/sec n/a
16.  
17. ---------------------------
18. ОК  
19. ---------------------------

</font><!--face-->



ЗЫ

Память 266MHz и 333MHz - разницы практически нет, т.к. шина FSB ==266MHz



ЗЫЫ

С MessageBox можно копировать Ctrl+V (gj краёней мере в XP)



1729394837__memcopy2.zip

 

Показывает 615 Mb/s . Надо посмотреть отладчиком адреса источника-назначения, если не кратны 32, проблема в известном месте.

205385691__mcpy2.jpg

 

---------------------------

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,

добавил следующие команды:

Код (Text):

1.  
2.   or esi, 1fh
3.   inc esi
4.   or edi, 1fh
5.   inc edi
6.  

Хочу проверить...

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

509700158__memcopy2.Asm



[edited]

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

 

Да нет, данные выровнены по странице (4K).

Просто копирование шло в одно и тоже место (edi не увеличивался)

 

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

 

alpet



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

Но в аттаче файл подправленный под стандартные FASM'овые include. (путь к ним в переменной fasminc)





Black_mirror >

Да и на 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 будет всего один!





>

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

 

Не знаю как на других процах, но на Celeron'e со свигами есть небольшой выигрыш: 140 против 172 миллисекунд.

ROR еще на 486 могла до 1 такта на сдвиг тратить (30 макс), жаль нет более быстрой альтернативы.

Доработаю алгоритм посмотрим.

 

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

<font face="monospace]

Код (Text):

1.  
2. Instruction Mnemonic    First Byte  Second Byte ModR/M Byte Decode Type Execute Latency Note
3. ROR mreg16/32, imm8 C1h             11-001-xxx  DirectPath  1       3
4.  
5. Notes:
6. 3. The clock count, [i]regardless[/i] of the number of shifts or rotates as determined by CL or imm8.

</font><!--face-->



Вот на 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