Хотя для больших размеров блоков разница не в 3 раза будет, но она точно будет. И там действительно 2 такта (хотя от выравнивания кода зависит)

Shur
О привет!!!!!


Значит так, я сам вчера всё проверил . Опробывал где-то 50 вариаций.

вывод

======================================================
Поздравляю моя процедурка провалилась с треском!!!
Крис совершенно прав. Невыровненность приёмника ни на что не влияет.

Она ухудшает производительность всего то на 10%

И кстати что интерсно (Athlon) и для кеша это так :))

Теперь по книге. Крис пишет, что мол команду movsd переплюнуть нельзя.
Это не совсем так.

Обычная замена на mov при копировании данных блоками по 16 байт
(или 32)
выйгрыш около 5-7%

FPU даёт выйгрышь в 20-50%

А вот MMX в 2 раза!!!!!

При чём как в копировании блоков 256, так и 4K
Больше правда я не делал.
Но на то причины

Я пока не создаю функцию для копирования больших блоков памяти.

Кроме того, как алгоритмист хочу отметить, что замена movsd удобна в
алгоритме копирования.
Правда я пока не подтвердил эксперементально этот факт..

И тем не менее.

!!!Кстати хочу отметить, что код опережающий movsd на 5% был без всяких
ухищрений!!!!!
А если похитрить????

То есть

1. Учесть кеш
2. Чтение запись банков
3. И т.д.

Так что пока не будет сбрасывать с рельс замену movsd!!!!

А от выравнивания - ну практически никак :)

Поправлю.

Невыровненное esi -- даёт поигрышь в 300%-600%
То есть в 3-5 раз!!!!

А вот edi только в 5-10%

Стоит-ли огород городить? Или я чего-то опять не понимаю ?

Хех, стоит!!!

Зато теперь я знаю, что Алгоритм со сдвигами в 32-bits регистрах не стоит свечь

НО ОСТАЁТСЯ MMX!!!! ^)))

Так что бой не окончен

НО ОСТАЁТСЯ MMX!!!! ^)))

Так что бой не окончен
Мне-бы твой оптимизм :)

Невыровненное esi -- даёт поигрышь в 300%-600%
То есть в 3-5 раз!!!!

А вот edi только в 5-10%

И где ты получил 3-5 раз ??? В каком из 50-ти вариантов ???


Как мерял я:

DWORD copy_sub(void* src, void* dst, DWORD _size)
{
	__asm
	{
		mov esi,src;
		mov edi,dst;
		mov ecx,_size;
		shr ecx,2;
		rdtsc;
		mov ebx,eax;
		align 16;
_loop:
		mov eax,[esi];
		mov [edi],eax;
		add esi,4;
		add edi,4;
		dec ecx;
		jnz _loop;
		rdtsc;
		sub eax,ebx;
	}
}

Функция вызывается в цикле 1000 раз и берется среднее.
с любыми src, dst - 3 такта на итерацию.
Мне инетресно, что я не так делаю ?

Мне инетресно, что я не так делаю
Ну, например, тем, что кеш надо сбрасывать с помощью cpuid перед rdtsc. И все равно неточно будет...

кеш надо сбрасывать с помощью cpuid перед rdtsc.

Это мелочи.

На самом деле я уже понял. Надо просто развернуть цикл побольше - тогда некоторую разницу можно

почувствовать.
1.3 такта - оба выровнены
1.7 - невыровнен dst
1.5 - невыровнен src
2.1 - невыровнены оба.

Но все равно макс. разница только ~60%

Мне инетресно, что я не так делаю
align 16 - Здесь могут быть проблемы, в зависимости от компилятора. Ml.exe, например, не забивает пустоту NOP-ами. Правильнее было бы:
jmp _loop
align 16
_loop:

Shur
И где ты получил 3-5 раз ??? В каком из 50-ти вариантов ???

Замеры правда VTUNE при повторении кода более 0ffffh

Результаты примерно следубщие

1 000.000
3 000.000

И потом я мерял rep movsd хотя тут не должно быть большой разницы

почувствовать.
1.3 такта - оба выровнены
1.7 - невыровнен dst
1.5 - невыровнен src
2.1 - невыровнены оба.

Я могу проверить снова. Может ошибся? Хотя врядли.
Но проверю.

Мне-бы твой оптимизм :)

:) Надо попробывать.

Black_mirror
Представил. 100Kb askii string :)


Valery
Спасибо, теперь понял. Еще Вирт говорил, что алгоритмы без данных - как Ян без Инь.


Edmond
А вот MMX в 2 раза!!!!!
По словам AMD, должно быть максимум в 3.


sd2000
Ml.exe, например, не забивает пустоту NOP-ами.
Он должен забивать эквивалентными командами.

По словам AMD, должно быть максимум в 3.

Возможно

Edmond
На болиших блоках - точно

Я вижу уже в уме супер релиз на MMX

Ну просто перед глазами. Алгоритм тот же что и уменя.
Но кода меньше в 4 раза + скорость.

Чего мы имеем : копирование через MMX с выровненным dst и невыровненным src ~2.4 такта в расчете на 8 байт. Если ты хочешь его переплюнуть, тебе надо за эти 2.4 такта выполнить следующие вещи :загрузить очередные 8 байт в 2 регистра, сделать 2 сдвига +1 OR. ну и store. итого 6 команд. т.е. минимум 2 такта без учета расходов на организацию цикла.
т.е. максимум, что ты мог-бы выиграть на Атлоне -20%. (У меня эти 6 команд выполняются только за 2.7 такта). Да и если-бы был такой способ оптимизации копирования, AMD скорее всего упомянула бы о нем в 22007.pdf. Там-же только совет - Не можете выровнять оба - выровняйте хотя- бы dst.
На Интеле не знаю. Завтра померяю.

выровнять оба - выровняйте хотя- бы dst.

Ты хотел сказать SRC

копирование через MMX с выровненным dst и невыровненным src ~2.4

Может наоборот?

Shur
На мой взгляд, не совсем корректно измерять скорость копирования в байтах за такт. Потому что скорость ядра на порядок выше скорости доступа к памяти.
Более уместно использовать байты в секунду. Это хорошо согласуется с почти одинаковой скоростью копирования Athlon XP1600+ и Athlon XP2000+.

22007.pdf на сколько понял мой измученный мозг - общие советы.
Про большие блоки хорошо написал Mike Wall
http://cdrom.amd.com/devconn/events/AMD_block_prefetch_paper.pdf
или (почти тоже самое) http://cdrom.amd.com/devconn/events/gdc_2002_amd.pdf

На маленьких, конечно толку не будет :(
Хотя, если сразу несколько их в кеш загрузить...