Really last post on memcpy: flame@habr

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

Вот наша публичная переписка, чтобы было с чего начинать:
levgem> опровержений им вагон и маленькая тележка. Пока простой memcpy жарит окружающих раскаленным процессором,
levgem> копируя картинку из одной области в другую, оптимизированная SSE-версия успевает сделать это раз в 20 быстрее. В 20
levgem> раз, а не в 2-3.
Я специально написал, что есть особый случай для non temporals/write combined памяти (которые и используются для копирования картинок по фреймбуфферам и memory mapped IO). Действительно, там возможна такая разница.
Для наиболее употребительного копирования нескольких килобайт в обычной памяти, могу прислать простой микро бенчмарк в личку. для виндов устроит, найдется nehalem/westmere/sandy bridge чтобы проверить?
levgem> при чём здесь какие-то фреймбуферы? О чём вы говорите?
levgem> Я писал про копирование картинки по обычной памяти для сжатия в H.264
levgem> Бенчмарки в личку — это просто какое-то неуважение. Впрочем, от виндового пользователя, который думает, что
levgem> копированием нескольких килобайт можно что-то проверить ничего другого ждать и не приходится.
Фреймбуфер — один из сценариев, в котором на Sandy Bridge и последующих процессорах код копирования, реализованный на SSE4 будет существенно быстрее, чем на rep movs.
Вы спросили про бенчмарк, т.к. вы считаете, что мои даные и/или микро бенчмарк некорректны. Я был готов прислать исходник. Где здесь неуважение? Еще пара человек спросили, выслал и им.
Если для виндов не подходит, то для какой ОС? И кстати, что не так с пользователями, которые в числе прочих ОС пользуются и виндами?
Основной тезис моей статьи был, что давно rep movs был эффективным, потом появились гораздо лучшие SSE реализации, но недавно, по сути с Sandy Bridge и последующих, копирование при помощи rep mov, которое используется в ядре Linux и некоторых других продуктов(MSVC stdlib и тд) сравнялось по скорости с сложным SIMD кодом.
Из двух ваших комментариев, если я их правильно понял, следует противоположный тезис — ничего не изменилось, на процессорах Sandy Bridge, которые вышли примерно год назад, SIMD реализация копирования в 20 раз быстрее, чем rep movs.
Я свой бенчмарк (которым, по-вашему, ничего проверить нельзя) описал. Можно узнать подробности вашего? В вашем бенчмарке, где вы копируете картинку для последующего сжатия, у вас просто
memcpu(kartinka_dest, kartinka_src, kartinka_len_in_bytes);
или вы копируете как-то по линиям или еще как-то? Какого размера область памяти? Находится ли она уже в LLC?
levgem> Выложите проверяемые бенчмарки в статье с их результатами. Иначе все ваши слова с вашей недостатейкой в которой
levgem> вы обманываете людей — полное фуфло. Впрочем, они и есть фуфло, потому что вы попросту не в теме и думаете, что
levgem> копированием килобайта можно что-то намерять.

Мой ответ на последний коммент:
( Read more... )