Really last post on memcpy: flame@habr
Jan. 14th, 2012 07:31 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
izardВ комментариях к моему последнему посту на хабре мы поспорили с уважаемым лж-френдом ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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> копированием килобайта можно что-то намерять.
Мой ответ на последний коммент:
1. Причина, по которой я не выложил исходник бенчмарка в текст темы только в том, что код получился размером в пару сотен строк. Поэтому чтобы его опубликовать в официальном блоге как сотруднику Интела, мне пришлось бы получать официальное разрешение от кучи людей, включая юристов. Бенчмарк я описал подробно, так что реализовать его можно независимо от меня за полчаса. (Или спросить у меня, я не скрываюсь, готов выслать лично по первому требованию.) В Линуксе еще проще - просто сравнить производительность memcpy, выдрав его из ядра, и memcpy из glibc. Можно сравнивать как я (я минимизировал влияние всех возможных факторов, кроме pipeline'а), можно еще десятком способов. Цель сравнения - подтвердить мои наблюдения, или опровергнуть.
2. Моя цель в этом споре - узнать, при каких еще условиях SSE версия memcpy в 20 раз обгоняет по производительности rep movs версию на Sandy Bridge. Я пока знаю один вариант, когда это возможно, но не исключаю, что он не единственный.
Уважаемый френд levgem мог бы очень помочь мне и многим другим людям (серьезно!) если бы описал новый способ, которым можно продемонтстрировать 20х разницу в производительность rep movs и SSE memcpy. Пока данных, предоставленных оппонентом, мне для этого недостаточно. Быть может, у Макса есть его собственный SSE memcpy, который гораздо быстрее, чем код из ICC, glibc, Agner Fog (все они достаточно близки)?
3. У меня уже есть несколько гипотез (например, в понедельник, когда приду на работу, проверю, что будет с прерываниями на Sandy Bridge. Сделаю аффинити треда на CPU 0, заассайню туда же все MSI-X прерывания сетевухи, полностью выключу на сетевухе interrupt coalescing, и пошлю на нее мелких пакетов на лайн рейт. Ну и посмотрю, что будет при этом со средней производительностью обеих memcpy на данных, из L1D, L2, LLC, памяти) Это на самом деле очень интересный тест. Если производительность обеих версий будет страдать одинаково, то тогда вместо сетевухи я вставлю PCI express logic analyzer, и посмотрю, что там с latency прерываний.
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> копированием килобайта можно что-то намерять.
Мой ответ на последний коммент:
1. Причина, по которой я не выложил исходник бенчмарка в текст темы только в том, что код получился размером в пару сотен строк. Поэтому чтобы его опубликовать в официальном блоге как сотруднику Интела, мне пришлось бы получать официальное разрешение от кучи людей, включая юристов. Бенчмарк я описал подробно, так что реализовать его можно независимо от меня за полчаса. (Или спросить у меня, я не скрываюсь, готов выслать лично по первому требованию.) В Линуксе еще проще - просто сравнить производительность memcpy, выдрав его из ядра, и memcpy из glibc. Можно сравнивать как я (я минимизировал влияние всех возможных факторов, кроме pipeline'а), можно еще десятком способов. Цель сравнения - подтвердить мои наблюдения, или опровергнуть.
2. Моя цель в этом споре - узнать, при каких еще условиях SSE версия memcpy в 20 раз обгоняет по производительности rep movs версию на Sandy Bridge. Я пока знаю один вариант, когда это возможно, но не исключаю, что он не единственный.
Уважаемый френд levgem мог бы очень помочь мне и многим другим людям (серьезно!) если бы описал новый способ, которым можно продемонтстрировать 20х разницу в производительность rep movs и SSE memcpy. Пока данных, предоставленных оппонентом, мне для этого недостаточно. Быть может, у Макса есть его собственный SSE memcpy, который гораздо быстрее, чем код из ICC, glibc, Agner Fog (все они достаточно близки)?
3. У меня уже есть несколько гипотез (например, в понедельник, когда приду на работу, проверю, что будет с прерываниями на Sandy Bridge. Сделаю аффинити треда на CPU 0, заассайню туда же все MSI-X прерывания сетевухи, полностью выключу на сетевухе interrupt coalescing, и пошлю на нее мелких пакетов на лайн рейт. Ну и посмотрю, что будет при этом со средней производительностью обеих memcpy на данных, из L1D, L2, LLC, памяти) Это на самом деле очень интересный тест. Если производительность обеих версий будет страдать одинаково, то тогда вместо сетевухи я вставлю PCI express logic analyzer, и посмотрю, что там с latency прерываний.
