О производительности 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).

[AlexandrY]

Тут важнее каким компилером это делалось и какая шина была к SDRAM.

С другой стороны в драйверах где скорость особенно важна практически нет свободы выбора как будут размещены приходящие в драйвер данные.
Зато есть свобода выбора компилятора

[VslavX]

Тут важнее каким компилером это делалось и какая шина была к SDRAM.

Я бы сказал что не от компилятора, а от конкретной реализации memcpy() - она обычно на ассемблере пишется, компилятор никак не результат повлиять не может.

aaarrr
Вы не могли бы добавить архивчик с исходником использованной в Ваших тестах memcpy()? Для полноты картины
Про разные банки - эффект известный, Ваш тест очень хорошо его отобразил. Только пользоваться этим эффектом трудно, у тех контроллеров что мне попадались, биты адреса банка замешивались в середину физического адреса. И получалось что в адресном пространстве подряд шли страницы из разных банков, да еще они могли на разных платах быть разного размера - в зависимости от того какие чипы запаяли. В среднем (когда не задумываться о банках) это наверное эффективней, тем более в DDR2 банков уже может быть 8. Но при этом сознательно "разбанковать" данные становится трудновато.

[AlexandrY]

Я бы сказал что не от компилятора, а от конкретной реализации memcpy() - она обычно на ассемблере пишется, компилятор никак не результат повлиять не может.

Почему вы решили что все пишут на GCC?
Ни в IAR, ни в Keil, ни в GHS, ни в RealView исходники memcpy недоступны.
Никто бы не стал тестировать memcpy если б были исходники этой функции.

[VslavX]

Почему вы решили что все пишут на GCC?
Ни в IAR,

Надо признать, резон в замечании есть. Тут дело не столько в GCC, сколько в том, что memcpy() лично для меня функция важная и тщательно изученная не для одной архитектуры. Вот я и решил что все ее код "знают в лицо". Был неправ, что сказать . BTW, для IAR Full версии исходники доступны, и это они зря - там грустно

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

Исходники (ессно, в нормальном варианте) там бывают довольно любопытные - иногда я много нового узнаю . ИМХО, тестировать memcpy() следует потому что на современных системах производительность зависит не только (далеко не только) от того что написано в исходнике этой функции. Лично я всегда при помощи тестов memcpy() (своей имплементации RTL) тюнингую настройки контроллера DRAM, арбитра шины и прочие подобные мелочи.

ибо в IAR 4x был мрак с memcpy(), но IAR - для 4x и 5.x день и ночь по результатам.

Э-э-э-э, то есть 5-ый еще хуже чем 4-ый? Да куда ж там дальше-то. Я последний раз IAR-овские исходники смотрел в 4.30 - правда мрак.