О производительности memcpy, Навеяно темой "jpeg на at91sam9g20" Опции

[aaarrr]

Надо будет проверить влияние этого на производительность.

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

В ходе эксперимента измерялась скорость копирования 256 блоков по одному мегабайту с различными смещениями источника и приемника данных. В качестве тестовой платформы использовался процессор EP9312 (ARM920T, FCLK = 200MHz, BCLK = 100MHz).
Первое число в квадратных скобках - смещение приемника, второе - источника, скорость приводится в мегабайтах в секунду:

Код

copy[0][0]: 60.674
copy[1][0]: 45.506
copy[2][0]: 45.506
copy[3][0]: 45.506

copy[0][1]: 46.397
copy[1][1]: 55.246
copy[2][1]: 45.506
copy[3][1]: 45.506

copy[0][2]: 46.397
copy[1][2]: 46.397
copy[2][2]: 55.245
copy[3][2]: 45.506

copy[0][3]: 46.397
copy[1][3]: 46.397
copy[2][3]: 46.397
copy[3][3]: 55.245

Примечательны два обстоятельства:
1. Относительно небольшое против ожидаемого снижение скорости при работе с неодинаковыми смещениями у источника и приемника
2. Заметное падение скорости в условиях, казалось бы близких к идеальным (n, n; при n > 0).

Объяснение первому эффекту находится достаточно просто: 60 МБайт/с - это ограничение, накладываемое производительностью контроллера памяти. И если снизить частоту ядра, оставив частоту шины на том же уровне (FCLK = BCLK = 100MHz), то разница в результатах получается более значительной:

Код

copy[0][0]: 60.672
copy[1][0]: 32.233
copy[2][0]: 32.233
copy[3][0]: 32.233

copy[0][1]: 32.233
copy[1][1]: 53.933
copy[2][1]: 32.233
copy[3][1]: 32.233
...

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

Зависимость скорости копирования от смещения данных, число в квадратных скобках - смещение в 32-битных словах:

Код

copy[0w]: 60.674102
copy[1w]: 55.245381
copy[2w]: 55.226639
copy[3w]: 52.582269
copy[4w]: 60.672306
copy[5w]: 55.246603
copy[6w]: 55.211088
copy[7w]: 52.584118
copy[8w]: 60.674150
...

И, наконец, последняя табличка. Она показывает скорость копирования при расположении источника и приемника данных в разных банках SDRAM.

Код

copy[0w]: 91.010796
copy[1w]: 79.629958
copy[2w]: 79.629988
copy[3w]: 73.539810
copy[4w]: 91.006777
copy[5w]: 79.630088
copy[6w]: 79.630112
copy[7w]: 73.539468
copy[8w]: 91.011220
...

Если резюмировать, то для эффективного копирования надо:
1. Выравнивать данные, причем иногда бывает мало и границы слова. Логичным представляется выравнивание по границе строки кэша.
2. По возможности располагать источник и приемник в разных банках SDRAM. Это позволит контроллеру памяти дольше держать банки открытыми (т.е. сэкономить на precharge).

[aaarrr]

aaarrr
Вы не могли бы добавить архивчик с исходником использованной в Ваших тестах memcpy()? Для полноты картины

Пожалуйста. Эта memcpy используется в ADS 1.2, RVDS 2.2 и RVDS 4.1. По всей видимости в ARM решили, что допиливать там больше нечего.

Никто бы не стал тестировать memcpy если б были исходники этой функции.

Почему же? У меня были, но все равно оказалось любопытно

CODE

__rt_memcpy
cmp r2,#3
bls _memcpy_lastbytes
ands r12,r0,#3
beq _memcpy_dest_aligned
ldrb r3,[r1],#1
cmp r12,#2
add r2,r2,r12
ldrlsb r12,[r1],#1
strb r3,[r0],#1
ldrccb r3,[r1],#1
strlsb r12,[r0],#1
sub r2,r2,#4
strccb r3,[r0],#1
_memcpy_dest_aligned
ands r3,r1,#3
beq __rt_memcpy_w
subs r2,r2,#4
bcc _memcpy_lastbytes
ldr r12,[r1,-r3]!
cmp r3,#2
beq _memcpy_src2_loop
bhi _memcpy_src3_loop
_memcpy_src1_loop
mov r3,r12,lsr #8
ldr r12,[r1,#4]!
subs r2,r2,#4
orr r3,r3,r12,lsl #24
str r3,[r0],#4
bcs _memcpy_src1_loop
add r1,r1,#1
b _memcpy_lastbytes
_memcpy_src2_loop
mov r3,r12,lsr #16
ldr r12,[r1,#4]!
subs r2,r2,#4
orr r3,r3,r12,lsl #16
str r3,[r0],#4
bcs _memcpy_src2_loop
add r1,r1,#2
b _memcpy_lastbytes
_memcpy_src3_loop
mov r3,r12,lsr #24
ldr r12,[r1,#4]!
subs r2,r2,#4
orr r3,r3,r12,lsl #8
str r3,[r0],#4
bcs _memcpy_src3_loop
add r1,r1,#3
b _memcpy_lastbytes
__rt_memcpy_w
subs r2,r2,#0x20
stmfd r13!,{r4,r14}
bcc _memcpy_small
_memcpy_aligned_loop
ldmcsia r1!,{r3,r4,r12,r14}
stmcsia r0!,{r3,r4,r12,r14}
ldmcsia r1!,{r3,r4,r12,r14}
stmcsia r0!,{r3,r4,r12,r14}
subcss r2,r2,#0x20
bcs _memcpy_aligned_loop
_memcpy_small
movs r12,r2,lsl #28
ldmcsia r1!,{r3,r4,r12,r14}
stmcsia r0!,{r3,r4,r12,r14}
ldmmiia r1!,{r3,r4}
stmmiia r0!,{r3,r4}
movs r12,r2,lsl #30
ldmfd r13!,{r4,r14}
ldrcs r3,[r1],#4
strcs r3,[r0],#4
moveq pc,r14
_memcpy_lastbytes
movs r2,r2,lsl #31
ldrmib r2,[r1],#1
ldrcsb r3,[r1],#1
ldrcsb r12,[r1],#1
strmib r2,[r0],#1
strcsb r3,[r0],#1
strcsb r12,[r0],#1
mov pc,r14

[AlexandrY]

Пожалуйста. Эта memcpy используется в ADS 1.2, RVDS 2.2 и RVDS 4.1. По всей видимости в ARM решили, что допиливать там больше нечего.


Почему же? У меня были, но все равно оказалось любопытно

Посмотрел сейчас дизассемблер в Keil-е. Ну не совпадает однако (у меня ARM926EJ-S)
У меня процедура заметно короче.
Да и как там совпасть? Компилер идет с кучей уже подготовленных либ под каждый нюанс архитектуры.

[aaarrr]

Посмотрел сейчас дизассемблер в Keil-е. Ну не совпадает однако (у меня ARM926EJ-S)
У меня процедура заметно короче.

Специально проверил - в точности совпадает. Только __rt_memcpy_w идет отдельным куском. Может, поэтому короче показалось?

Да и как там совпасть? Компилер идет с кучей уже подготовленных либ под каждый нюанс архитектуры.

Подходы к скоростному копированию на 7TDMI и 926EJ ну никак не отличаются.