Из праздного интереса сравнил производительность на своем ПК родного memcpy и такого цикла

Дефолтная функция оказалась в 10-11 раз быстрее. Может кто знает, что за сильное колдунство в ней применено?

P.S.
mas - интовский массив, так что, если я ничего не путаю, проблем с выравниванием по вордам не должно быть

копирование двойными словами или четвертными словами.

AFAIK в memcpy используются какие-то специальные ассемблерные функции. Как msvc не знаю, а GCC при -03 выравнивает производительность memcpy и наколеночной реализации.

Добавлено через 1 минуту и 9 секунд
Утром исходник посмотрю.

Посмотрите исходники. все ран-таймовские сорцы должны быть. 
Вот исходник от 2008 студии (2010 под рукой нет, но думаю там ничего кардинального с memcpy не произошло)



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


Это сообщение отредактировал(а) volatile - 6.9.2011, 03:00

пример: http://notes.sochi.org.ru/1322/
в CRT GCC что-то вроде этой. но посложнее.
еще помню, однажды для копирования массивов, нужна была ооочень быстрая memcpy(). я в инетах нашел кучу. но тесты показали, что дефолтная нисколько не медленнее.

Добавлено через 1 минуту и 3 секунды

позор!  

Почему позор?

побайтное копирование! 

Добавлено через 6 минут и 56 секунд
volatile, посмотри на это? http://lxr.linux.no/linux+v3.0.4/arch/x86/...tring_32.h#L168
выше реализованы использованные в ней функции.

Добавлено через 8 минут и 31 секунду
одна из них в другом файле: http://lxr.linux.no/linux+v3.0.4/arch/x86/lib/mmx_32.c#L28

Где-то в старом борланде я видел асмовую memcpy, с копированиями 32-разрядными словами.
Внешне очень красивая. с трюками и развернутыми циклами. щас не могу найти. может завтра..
Но в реале она боюсь окажется не на много быстрее... Это связано с современными процессорами.
Там основное время тратится на не попадание в внутренний кеш процессора.
(страница памяти). И это невелирует различия побайтного и пословного копирования.


Вообще может сравню раельную производительность, если будет время.

кеш может на что-то повлиять, если происходит копирование массивов размером меньше линии кеша. это первое.
второе - т.к. массивов два(источник-приемник), то тогда оба массива должны попасть каждый в свою линию(иначе толку от одного кеша не будет). а это маловероятно.
третье - копирование словами/двойными_словами - всегда быстрее. сравни.

Это сообщение отредактировал(а) boostcoder - 6.9.2011, 03:35

Пример:
1. Побайтое копирование
читаем первый байт, который не находится в кеше. тратим на это 1000 тактов. (грубо)
читаем второй байт (а он уже в кеше) тратим на это 2 такта 
читаем 3 -ий байт тратим  2 такта 
читаем 4 -ый байт тратим  2 такта 
итого 1006 тактов.

2. Теперь читаем словами.
читаем слово, не попадаем в кеш, тратим 1000 тактов.

итого разница между побайтным и пословным копированием 1000 против 1006.

Цифры взял с потолка, просто чтоб объяснить свою мысль.


не спорю. просто возможно что не на много.
Реально может сравню.

размер линии кеша - 64 байта.
а теперь посчитай сколько тактов потребуется для копирования массива объемом 128 байт, к примеру ;)

Решил проверить, делая ставку на стандартную memcpy:


Результат неожиданный: 


Конфигурация - VS2010, WinXP SP3, i3, 2Gb. Проверил на VS2008 - результат аналогичный.

Посмотрел в ассемблерный листинг - самописанные процедуры в обоих студиях записались так:

(копирование строки с адреса ds:esi в адрес es:edi)

А вот memcpy - вызов внешней функции:


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

volatile же показал код memcpy() используемой в VC2008. чего он нее ожидать-то?  

ну я не знаю... надеялся на оптимизационные способности компилятора )))

Ребята, современные процессоры, довольно сложные штуковины.
там 3 уровня кеша.
К тому-же GetTickCount(); слишком груба чтобы сравнивать промежутки времени меньше минуты
у нее слишком большая дискретность.

Но дело здесь не в этом. Здесь дело в страничном выделении памяти.
Первая процедцра копирования работает с не выделенной памятью и тратит кучу времени на выделение этой памяти.
Вторая уже работает с выделенной памятью.
Просто поменяйте функции местами, и скорость получится не в вашу пользу с точность до наоборот



Просто меняю очередность вызовов местами:

Функции брал ваши без переделки.