memcpy - почему побайтно? Опции

[DASM]

598 */
599 void *memcpy(void *dest, const void *src, size_t count)
600 {
601 char *tmp = dest;
602 const char *s = src;
603
604 while (count--)
605 *tmp++ = *s++;
606 return dest;
607 }
608 EXPORT_SYMBOL(memcpy);
Такой вот сурец из string.c ... видел более оптимизированную версию с раскруткой цикла. Что то не понимаю, это же дикие тормоза на 32 битнике. Но люди то солидные писали, в чем прикол?
Собственно это вариант общий для разных процев, обрамлен ifndef ARCH_MEMCPY, но. для Арм версия такая
for (i = __n >> 3; i > 0; i--) {
15 *d++ = *s++;
16 *d++ = *s++;
17 *d++ = *s++;
18 *d++ = *s++;
19 *d++ = *s++;
20 *d++ = *s++;
21 *d++ = *s++;
22 *d++ = *s++;
23 }
Что не шибко лучше.

[DASM]

Так это же исходники линуксовые, с kernel.org .Мне собственно говоря copy_to_user нужен, но он в итоге зовет этот самый memcpy. Объемы копирования большие, вот и заинтересовался скоростью.. Это же четыре обращения к памяти, в случае 32 битной и вне кеша — это даже не в четыре раза потеря, поболее может быть вроде как. char * никакой оптимизатор имхо заменять права не имеет на int*

[sasamy]

Так это же исходники линуксовые, с kernel.org .Мне собственно говоря copy_to_user нужен, но он в итоге зовет этот самый memcpy.

Обсуждения оптимизаций для ARM были
http://comments.gmane.org/gmane.linux.port...m.kernel/251708

чем закончилось не знаю - посмотрите исходники текущего ядра с kernel.org, возможно уже все не так пессимистично как вы думаете По крайней мере в новостях что-то припоминаю - проскакивало про использование NEON в ядре.

Сообщение отредактировал sasamy - Nov 22 2013, 04:05