predefined memcpy()

ассемблер, SSE инструкции, копировать по 128 бит?

256 не пойдет, или, возможно, выше? Если несложно, с деталями.

Обратите внимание что речь идет о малом единичном блоке памяти с потенциальными проблемами с выравниванием в блоке памяти назначения.

__builtin_memcpy ?

для константного размера (как у ТС) - gcc и так его использует

Обратите внимание, что размер структуры для копирования предопределен - основная задача - максимально оптимизировать эту операцию, все встроенные функции исходят все же из иных предпосылок

Можно подробнее?

Можно отсюда взять http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/multiarc...

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

железо, на данный момент - ксеоны последнего поколения. Какие последуют советы?

Любой специализированный (по длине копируемой структуры) способ копирования, хоть rep movs. Процессор всё равно команды на свои uops разберёт/соберёт с примерно одинаковым паттерном работы с uncore. А оптимизировать надо картину уровнем выше: чтобы переключений контекста не было, код в l1 умещался, промахов TLB не было, пайплайн не затыкался.

Оооо, «ultra low-latency trading platform developer» :)

Значит, для твоего левелбука надо в первую очередь озаботиться локальностью данных и прогнозируемым паттерном доступа к ним. Помимо must have техник, типа hugepages (и для размещения кода тоже, если какая-то аналитика делается), нужно ещё постоянно помнить, что латентность даже L2 на E5 порядка 8 тактов - это дюжина команд. Т.е. часто выгодней побольше посчитать на структуре посложне, чем дотянуться до данных в плоском массиве.

Прогнозируемый доступ (для сокращения eviction rate и засирания tlb) - это, например, выделение отдельного ядра на эйпл, чтобы не слишком прибыльный, но назойливый микрософт не мешал.

Спасибо за советы.

Какие решения применяются. 1. Это выделенные ядра, что на читателе, что на писателе. 2. Критичные потоки пасутся на одном физическом кеше L3

В данном случае речь идет про биржевое API. Задача - максимально быстро вернуть управление из коллбека, для этого и применяется специализированный memcpy.

И да, все вещи типа кеш-выравнивания и тому подобные предусмотрены изначально.

Интереса ради, а как вы поняли что у вас производительность упирается в копирование 100 байт?

У меня ничего никуда не упирается.

Это законы индустрии такие - коллбек должен вернуть управление за минимально возможное время.

В трейдинге латентность это абсолютно реальные деньги, поэтому, если есть возможность оптимизировать критический блок кода, он должен быть оптимизирован.

А при чем тут коллбек? Откуда куда данные копируете то? Я так понял ОС Linux + PREEMPT_RT используете? Не боитесь что кто-то другой процессорное время съест, в разы больше копирования 100байт? Или полностью свой планировщик задач у вас?

Есть биржевое API, которое вызывает определенные пользователем коллбеки. Пока коллбеки не вернут управление, поток биржевого API ждет.

Вот потому и решаю такого рода задачи.

А все остальное, то что вы упомянули, само собой, делается. И, обратите внимание, горячие потоки работают монопольно на выделенных ядрах, так что этот момент учтен.

Спасибо за пояснения, собственно направление на «монопольность потока на ядре» не дадите? как делается, может ссылки?

shed_setaffinity taskset irqbalance

Еще интересная дискуссия была на этом форуме, на предмет запрета выполнения на определенном ядре процессора kernel work queue

Спасибо, буду разбираться

Еще интересная дискуссия была на этом форуме, на предмет запрета выполнения на определенном ядре процессора kernel work queue

Ссылки не осталось?

исполнение задач на указанном ядре (комментарий)

Вы же там и засветились :)

Ну, это просто посетовали, что в Линуксе полностью нельзя от wq избавиться.. ;)

Любой специализированный (по длине копируемой структуры) способ копирования, хоть rep movs. Процессор всё равно команды на свои uops разберёт/соберёт с примерно одинаковым паттерном работы с uncore.

Если все обстоит именно так, какой тогда был смысл городить такие сложные способы копирования через SSSE3 инструкции, как: http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/multiarc...

Вот тут есть куча написанных на ассемблере функций для всяких разных SSE расширений http://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86_64/multiarch;h=46...

Еще мне вспомнил, был случай что из-за memcpy который копировал данные задом наперед(т.к. это оказывается эффективнее на каких-то процессорах), флеш плеер работал некорректно http://avva.livejournal.com/2323823.html

хоть rep movs. Процессор всё равно команды на свои uops разберёт/соберёт с примерно одинаковым паттерном работы с uncore.

Смешно такое читать. Удачного копирования через rep movsb!

Если все обстоит именно так, какой тогда был смысл городить такие сложные способы копирования через SSSE3 инструкции

Сложные? :)

glibc работает на куче разных процессоров с разными микроархитектурами, а у memcpy нет требований в выравниванию и размеру данных. У ТС данные выравнены, размер подогнан под РОН/XMM. Разницы между копированием через mov/movs посередине живого кода на E5 вообще не будет, через xmm тоже не будет, если префетчер правильно настроен.

Трейдерский софт такого уровня, каким ТС занимается, оптимизируется под конкретную микроархитектуру: будет работать на SB-EP, значит, всё затачивается под особенности SB-EP. На следующем интеловском tock, как правило, все заточки под предыдущую микроархитектуру пересматриваются. И вот это как раз хороший пример:

Еще мне вспомнил, был случай что из-за memcpy который копировал данные задом наперед(т.к. это оказывается эффективнее на каких-то процессорах)

Разницы между копированием через mov/movs посередине живого кода на E5 вообще не будет, через xmm тоже не будет, если префетчер правильно настроен.

Сначала не поверил, погуглил слегка. Наткнулся на статью http://habrahabr.ru/company/intel/blog/133962/

Цифра — во сколько раз самый продвинутый SSE4.1 код быстрее, чем std::memcpy, реализованный через rep movs

Bulldozer — 1.22x (спасибо stepmex за данные)

Penryn — 1.6x

Nehalem — 1.5x

Sandy Bridge — 1.008x

Этот бенчмарк не особенно точный, в реальном софте играют роль многие другие факторы, которые я вкраце перечислил выше.

Так что тут зависит от процессора

Пока на Xeon E3, это у меня девсервер такой, проделал эксперименты такие:

1. memcpy c литеральным параметром

2. builtin memcpy с литеральным параметром

3. применение 128-битных интринисков и копирование чз builtins

Во всех случаях gcc сгенерировал абсолютно идентичный код копирования памяти на ассемблере через MMX инструкции, причем серией с фиксированными смещениями, без всяких циклов, то есть пачку инструкций

Доберусь, сделаю постановочный эксперимент на icc

По ссылке http://gcc.1065356.n5.nabble.com/Ways-to-fill-the-stack-td912561.html#none в самом конце я тесты выкладывал под clang и gcc, там правда идет проверка способа записи данных в стек для передачи в функцию, но ситуация похожая. Можете переделать для своих тестов.

Спасибо, погляжу :)

Таких мест всего несколько на всю систему, придется инвестировать время в эксперименты, ибо бенефит тут явно имеется.