Я занимался измерением пропускной способности памяти для процессоров Intel с различными операциями, и одна из них - memcpy. Я делал это на Core2, Ivy Bridge и Haswell. Я выполнил большинство своих тестов, используя C / C ++ со встроенными функциями (см. Код ниже, но в настоящее время я переписываю свои тесты на сборке).

Чтобы написать свою собственную эффективную memcpy функцию, важно знать, какова наилучшая возможная пропускная способность. Эта полоса пропускания является функцией размера массивов, которые будут скопированы, и поэтому эффективная функция memcpy должна оптимизировать по-разному для малых и больших (и, возможно, промежуточных). Для простоты я оптимизировал для небольших массивов 8192 байта и больших массивов 1 ГБ.

Для небольших массивов максимальная пропускная способность чтения и записи для каждого ядра составляет:

Core2-Ivy Bridge             32 bytes/cycle
Haswell                      64 bytes/cycle

Это эталон, на который следует ориентироваться для небольших массивов. Для моих тестов я предполагаю, что массивы выровнены по 64 байтам и что размер массива кратен 8*sizeof(float)*unroll_factor. Вот мои текущие memcpy результаты для размера 8192 байта (Ubuntu 14.04, GCC 4.9, EGLIBC 2.19):

                             GB/s     efficiency
    Core2 ([email protected] GHz)  
        builtin               35.2    41.3%
        eglibc                39.2    46.0%
        asmlib:               76.0    89.3%
        copy_unroll1:         39.1    46.0%
        copy_unroll8:         73.6    86.5%
    Ivy Bridge ([email protected] GHz)                        
        builtin              102.2    88.7%
        eglibc:              107.0    92.9%
        asmlib:              107.6    93.4%
        copy_unroll1:        106.9    92.8%
        copy_unroll8:        111.3    96.6%
    Haswell ([email protected] GHz)
        builtin:              68.4    82.2%     
        eglibc:               39.7    47.7%
        asmlib:               73.2    87.6%
        copy_unroll1:         39.6    47.6%
        copy_unroll8:         81.9    98.4%

asmlib - это asmlib от Agner Fog. Функции copy_unroll1 и copy_unroll8 определены ниже.

Из этой таблицы мы видим, что встроенный memcpy GCC плохо работает на Core2 и что memcpy в EGLIBC плохо работает на Core2 или Haswell. Я недавно проверил головную версию GLIBC, и производительность на Haswell была намного лучше. Во всех случаях наилучший результат дает разворачивание.

void copy_unroll1(const float *x, float *y, const int n) {
    for(int i=0; i<n/JUMP; i++) {
        VECNF().LOAD(&x[JUMP*(i+0)]).STORE(&y[JUMP*(i+0)]);
    }
}

void copy_unroll8(const float *x, float *y, const int n) {
for(int i=0; i<n/JUMP; i+=8) {
    VECNF().LOAD(&x[JUMP*(i+0)]).STORE(&y[JUMP*(i+0)]);
    VECNF().LOAD(&x[JUMP*(i+1)]).STORE(&y[JUMP*(i+1)]);
    VECNF().LOAD(&x[JUMP*(i+2)]).STORE(&y[JUMP*(i+2)]);
    VECNF().LOAD(&x[JUMP*(i+3)]).STORE(&y[JUMP*(i+3)]);
    VECNF().LOAD(&x[JUMP*(i+4)]).STORE(&y[JUMP*(i+4)]);
    VECNF().LOAD(&x[JUMP*(i+5)]).STORE(&y[JUMP*(i+5)]);
    VECNF().LOAD(&x[JUMP*(i+6)]).STORE(&y[JUMP*(i+6)]);
    VECNF().LOAD(&x[JUMP*(i+7)]).STORE(&y[JUMP*(i+7)]);
}

}

Где VECNF().LOADis _mm_load_ps() для SSE или _mm256_load_ps() для AVX, VECNF().STORE это _mm_store_ps() для SSE или _mm256_store_ps() для AVX, а JUMP - 4 для SSE или 8 для AVX.

Для большого размера наилучший результат достигается при использовании инструкций невременного хранения и использования нескольких потоков. Вопреки тому, что многие считают , ни один поток НЕ обычно насыщают пропускную способность памяти.

void copy_stream(const float *x, float *y, const int n) {
    #pragma omp parallel for        
    for(int i=0; i<n/JUMP; i++) {
        VECNF v = VECNF().load_a(&x[JUMP*i]);
        stream(&y[JUMP*i], v);
    }
}

Где stream - это _mm_stream_ps() для SSE или _mm256_stream_ps() для AVX

Вот memcpy результаты на моем E5-1620 @ 3,6 ГГц с четырьмя потоками на 1 ГБ с максимальная пропускная способность основной памяти 51,2 ГБ / с.

                         GB/s     efficiency
    eglibc:              23.6     46%
    asmlib:              36.7     72%
    copy_stream:         36.7     72%

И снова EGLIBC работает плохо. Это потому, что он не использует невременные хранилища.

Я изменил функции eglibc и asmlib memcpy, чтобы они работали параллельно, вот так

void COPY(const float * __restrict x, float * __restrict y, const int n) {
    #pragma omp parallel
    {
        size_t my_start, my_size;
        int id = omp_get_thread_num();
        int num = omp_get_num_threads();
        my_start = (id*n)/num;
        my_size = ((id+1)*n)/num - my_start;
        memcpy(y+my_start, x+my_start, sizeof(float)*my_size);
    }
}

Обычная функция memcpy должна учитывать массивы, которые не выровнены по 64 байтам (или даже по 32 или 16 байтам) и размер которых не кратен 32 байтам или коэффициенту развертки. Кроме того, необходимо принять решение о том, когда использовать невременные хранилища. Общее практическое правило - использовать невременные хранилища только для размеров, превышающих половину самого большого уровня кэша (обычно L3). Но это детали «второго порядка», с которыми, я думаю, следует разобраться после оптимизации для идеальных случаев больших и малых. Нет особого смысла беспокоиться о корректировке несоосности или неидеальных кратных размеров, если идеальный случай также работает плохо.

Обновить

Основываясь на комментариях Стивена Кэнона, я узнал, что на Ivy Bridge и Haswell более эффективно использовать rep movsb, чем movntdqa (инструкция невременного хранения). Intel называет это расширенным представлением movsb (ERMSB). Это описано в руководства по оптимизации Intel в разделе 3.7.6 Расширенная работа REP MOVSB ​​и STOSB (ERMSB).

Кроме того, в руководстве Agner Fog Оптимизация подпрограмм в сборке в разделе 17.9 Перемещение блоков data (Все процессоры) он пишет:

"Есть несколько способов перемещения больших блоков данных. Наиболее распространены следующие методы:

1. Инструкция REP MOVS.
2. Если данные выровнены: чтение и запись в цикле с наибольшим доступным размером регистра.
3. Если размер постоянный: встроенные инструкции перемещения.
4. Если данные не выровнены: сначала переместите столько байтов, сколько требуется, чтобы выровнять место назначения. Затем считайте невыровненные и выровненные записи в цикле с наибольшим доступным размером регистра.
5. Если данные не выровнены: чтение выровнено, сдвинуть, чтобы компенсировать несовпадение, и запись выровнена.
6. Если размер данных слишком велик для кеширования, используйте невременную запись для обхода кеша. При необходимости сместите, чтобы компенсировать перекос ».

Обычный memcpy должен рассмотреть каждый из этих пунктов. Кроме того, с Ivy Bridge и Haswell кажется, что точка 1 лучше, чем точка 6 для больших массивов. Для Intel и AMD и для каждой итерации технологии необходимы разные методы. Я думаю, ясно, что написание собственной общей эффективной memcpy функции может быть довольно сложным. Но в особых случаях, которые я рассмотрел, мне уже удалось добиться большего, чем встроенный memcpy GCC или EGLIBC, поэтому предположение, что вы не можете добиться большего, чем стандартные библиотеки, неверно.

На этот вопрос нельзя ответить точно без некоторых дополнительных деталей, таких как:

• Какова целевая платформа (архитектура ЦП, большая часть, но конфигурация памяти тоже играет роль)?
• Каково распределение и предсказуемость ¹ длин копий (и, в меньшей степени, распределение и предсказуемость согласований)?
• Будет ли когда-либо статически известен размер копии во время компиляции?

Тем не менее, я могу указать на пару вещей, которые, вероятно, будут неоптимальными по крайней мере для некоторой комбинации вышеуказанных параметров.

Заявление о переключении из 32 регистров

Оператор switch с 32 регистрами - это симпатичный способ обработки конечных байтов от 0 до 31 и, вероятно, очень хорошо эталонного теста, но может плохо работать в реальном мире по крайней мере из-за двух факторов.

Размер кода

Один только этот оператор switch занимает несколько сотен байтов кода для тела в дополнение к таблице поиска из 32 записей, необходимой для перехода в правильное место для каждой длины. Стоимость этого не будет отображаться в целевом тесте memcpy на полноразмерном процессоре, потому что все по-прежнему соответствует самому быстрому уровню кеширования: но в реальном мире вы также выполняете другой код, и есть конкуренция за uop кеш и кеши данных и инструкций L1.

Такое количество инструкций может занять полностью 20% эффективного размера вашего кэша uop ³, а промахи кэша uop (и соответствующие циклы перехода от кеша к устаревшему кодировщику) могут легко свести на нет небольшое преимущество, которое дает этот сложный переключатель.

Вдобавок к этому коммутатору требуется таблица поиска с 32 записями и 256 байтами для целей перехода ⁴. Если вы когда-либо пропустите DRAM при этом поиске, вы говорите о штрафе в 150+ циклов: сколько не промахов вам нужно, чтобы получить switch того, что стоит, учитывая, что это, вероятно, сэкономит несколько или два максимум ? Опять же, это не будет отображаться в микробенчмарке.

Как бы то ни было, в этом memcpy нет ничего необычного: такое «исчерпывающее перечисление случаев» распространено даже в оптимизированных библиотеках. Я могу сделать вывод, что либо их разработка была вызвана в основном микробенчмарками, либо это все еще стоит того для большого фрагмента кода общего назначения, несмотря на недостатки. Тем не менее, безусловно, существуют сценарии (давление кэша инструкций и / или данных), где это неоптимально.

Прогнозирование ветвей

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

Поскольку это непрямая ветвь, существует больше ограничений на предсказуемость ветвления, чем у условного ветвления, поскольку количество записей BTB ограничено. Недавние процессоры добились здесь больших успехов, но можно с уверенностью сказать, что если ряды длин, подаваемых на memcpy, не следуют простой повторяющейся схеме за короткий период (всего 1 или 2 на старых процессорах), будет ветвление-неверный прогноз по каждому вызову.

Эта проблема особенно коварна, потому что она, вероятно, больше всего навредит вам в реальном мире именно в тех ситуациях, когда микробенчмарк показывает switch как лучший: короткие длины. Для очень больших длин поведение конечного 31 байта не очень важно, поскольку в нем преобладает массовое копирование. Для коротких отрезков switch имеет первостепенное значение (действительно, для копий размером 31 байт или меньше выполняется все)!

Для этих коротких длин предсказуемая серия длин очень хорошо работает для switch, поскольку косвенный прыжок в основном бесплатный. В частности, типичный memcpy эталонный тест «просматривает» серию длин, многократно используя одну и ту же длину для каждого субтеста, чтобы сообщить результаты для удобного построения графиков «время - длина». switch отлично справляется с этими тестами, часто выдает результаты, такие как 2 или 3 цикла для небольших отрезков в несколько байтов.

В реальном мире ваши длины могут быть небольшими, но непредсказуемыми. В этом случае косвенная ветвь будет часто неверно предсказывать ⁵, что приводит к штрафу в ~ 20 циклов на современных процессорах. По сравнению с лучшим случаем пары циклов это на порядок хуже. Таким образом, стеклянная челюсть здесь может быть очень серьезной (то есть поведение switch в этом типичном случае может быть на порядок хуже, чем у лучших, тогда как при большой длине вы обычно видите разницу максимум в 50% между разные стратегии).

Решения

Итак, как вы можете добиться большего, чем указано выше, по крайней мере, в условиях, когда switch разваливается?

Использовать устройство Даффа

Одним из решений проблемы размера кода является объединение корпусов переключателей вместе, устройство Даффа - стиль.

Например, собранный код для случаев длины 1, 3 и 7 выглядит так:

Длина 1

    movzx   edx, BYTE PTR [rsi]
    mov     BYTE PTR [rcx], dl
    ret

Длина 3

    movzx   edx, BYTE PTR [rsi]
    mov     BYTE PTR [rcx], dl
    movzx   edx, WORD PTR [rsi+1]
    mov     WORD PTR [rcx+1], dx

Длина 7

    movzx   edx, BYTE PTR [rsi]
    mov     BYTE PTR [rcx], dl
    movzx   edx, WORD PTR [rsi+1]
    mov     WORD PTR [rcx+1], dx
    mov     edx, DWORD PTR [rsi+3]
    mov     DWORD PTR [rcx+3], edx
    ret

Это можно объединить в один случай с различными переходами:

    len7:
    mov     edx, DWORD PTR [rsi-6]
    mov     DWORD PTR [rcx-6], edx
    len3:
    movzx   edx, WORD PTR [rsi-2]
    mov     WORD PTR [rcx-2], dx
    len1:
    movzx   edx, BYTE PTR [rsi]
    mov     BYTE PTR [rcx], dl
    ret

Этикетки ничего не стоят, они объединяют футляры вместе и удаляют две ret инструкции из 3. Обратите внимание, что основа для rsi и rcx здесь изменилась: они указывают на последний байт, из которого / в копируется, а не на первый. Это изменение бесплатное или очень дешевое, в зависимости от кода до перехода.

Вы можете удлинить это для большей длины (например, вы можете прикрепить длины 15 и 31 к цепочке выше) и использовать другие цепи для недостающих длин. Полное упражнение предоставляется читателю. Вероятно, вы сможете уменьшить размер на 50% только с помощью этого подхода, и гораздо лучше, если вы объедините его с чем-то еще, чтобы уменьшить размеры от 16 до 31.

Этот подход помогает только с размером кода (и, возможно, с размером таблицы переходов, если вы уменьшите размер, как описано в ⁴, и получите меньше 256 байт, что позволяет использовать таблицу поиска байтового размера. Он ничего не делает для предсказуемости.

Перекрывающиеся магазины

Один из приемов, который помогает как с размером кода, так и с предсказуемостью, - это использовать перекрывающиеся хранилища. То есть memcpy размером от 8 до 15 байтов может быть выполнено без ветвлений с двумя 8-байтовыми хранилищами, причем второе хранилище частично перекрывает первое. Например, чтобы скопировать 11 байтов, вы должны сделать 8-байтовую копию в относительной позиции 0 и 11 - 8 == 3. Некоторые байты в середине будут «скопированы дважды», но на практике это нормально, поскольку 8-байтовая копия имеет ту же скорость, что и 1-, 2- или 4-байтовая копия.

Код на C выглядит так:

  if (Size >= 8) {
    *((uint64_t*)Dst) = *((const uint64_t*)Src);
    size_t offset = Size & 0x7;
    *(uint64_t *)(Dst + offset) = *(const uint64_t *)(Src + offset);
  }

... и соответствующая сборка не проблематична:

    cmp     rdx, 7
    jbe     .L8
    mov     rcx, QWORD PTR [rsi]
    and     edx, 7
    mov     QWORD PTR [rdi], rcx
    mov     rcx, QWORD PTR [rsi+rdx]
    mov     QWORD PTR [rdi+rdx], rcx

В частности, обратите внимание, что вы получаете ровно две загрузки, два хранилища и одно and (в дополнение к cmp и jmp, существование которых зависит от того, как вы организуете окружающий код). Это уже связано или лучше, чем большинство сгенерированных компилятором подходов для 8-15 байтов, которые могут использовать до 4 пар загрузки / сохранения.

Старые процессоры понесли некоторые штрафы за такое «перекрытие хранилищ», но новые архитектуры (по крайней мере, за последнее десятилетие или около того), похоже, справляются с ними без штрафных санкций ⁶. У этого есть два основных преимущества:

1. Поведение без ветвей для диапазона размеров. По сути, это квантует ветвление, так что многие значения идут по одному и тому же пути. Все размеры от 8 до 15 (или от 8 до 16, если хотите) идут по одному и тому же пути и не подвержены влиянию ошибочных прогнозов.

2. По крайней мере, 8 или 9 различных случаев из switch включены в один случай с долей общего размера кода.

Этот подход может быть объединен с подходом switch, но с использованием лишь нескольких случаев, или его можно расширить до большего размера с помощью условных перемещений, которые могут, например, выполнять все перемещения от 8 до 31 байта без переходов.

Что сработает лучше всего, опять же, зависит от распределения ветвей, но в целом этот метод «перекрытия» работает очень хорошо.

Выравнивание

Существующий код не касается выравнивания.

Фактически, это вообще недопустимо для C или C ++, поскольку указатели char * просто приводятся к более крупным типам и разыменовываются, что незаконно, хотя на практике он генерирует коды, которые работают на современных компиляторах x86 (но в факт не прошел бы для платформы с более строгими требованиями к выравниванию).

Кроме того, часто бывает лучше заниматься выравниванием отдельно. Есть три основных случая:

1. Источник и место назначения уже согласованы. Даже оригинальный алгоритм здесь будет работать нормально.
2. Источник и место назначения относительно выровнены, но абсолютно не выровнены. То есть есть значение A, которое может быть добавлено как к источнику, так и к месту назначения, чтобы оба они были выровнены.
3. Источник и место назначения полностью не совмещены (т. Е. Фактически не выровнены, и случай (2) не применяется).

Существующий алгоритм будет работать нормально в случае (1). В случае (2) потенциально отсутствует большая оптимизация, поскольку небольшой вводный цикл может превратить невыровненную копию в выровненную.

Это также, вероятно, плохо работает в случае (3), поскольку в общем случае в случае полного смещения вы можете выбрать либо выровнять место назначения, либо источник, а затем продолжить «полувыравнивание».

Штрафы за выравнивание со временем становятся все меньше, и на самых последних чипах они скромны для кода общего назначения, но все же могут быть серьезными для кода с большим количеством загрузок и сохранений. Для больших копий это, вероятно, не имеет большого значения, поскольку в конечном итоге вы ограничите пропускную способность DRAM, но для меньших копий несовпадение может снизить пропускную способность на 50% или более.

Если вы используете NT-хранилища, выравнивание также может быть важным, потому что многие из NT-хранилищ плохо работают с несовпадающими аргументами.

Нет разворачивания

По умолчанию код не разворачивается, а компиляторы разворачивают разное количество раз. Ясно, что это неоптимально, поскольку среди двух компиляторов с разными стратегиями развертывания лучше всего будет не более одного.

Лучший подход (по крайней мере, для известных целей платформы) - определить, какой коэффициент развертывания лучше всего, а затем применить его в коде.

Более того, развертывание часто можно разумно комбинировать с "вводным" нашим "завершающим" кодом, выполняя свою работу лучше, чем мог бы компилятор.

Известные размеры

Основная причина, по которой трудно превзойти «встроенную» memcpy процедуру с современными компиляторами, заключается в том, что компиляторы не просто вызывают библиотеку memcpy всякий раз, когда memcpy появляется в исходном коде. Они знают контракт memcpy и могут реализовать его с помощью одной встроенной инструкции или даже меньше ⁷ в правильном сценарии.

Это особенно очевидно при известной длине memcpy. В этом случае, если длина мала, компиляторы просто вставят несколько инструкций, чтобы выполнить копирование эффективно и на месте. Это не только позволяет избежать накладных расходов на вызов функции, но и позволяет избежать всех проверок размера и т. Д., А также генерирует во время компиляции эффективный код для копии, как и большой switch в приведенной выше реализации - но без затрат на switch.

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

Если вы просто реализуете memcpy2 как библиотечную функцию, это будет сложно воспроизвести. Вы можете частично разделить метод на маленькую и большую части: маленькая часть появляется в файле заголовка, а выполняет некоторые проверки размера и потенциально просто вызывает существующий memcpy, если размер мал, или делегирует библиотечную подпрограмму, если он большой. С помощью магии встраивания вы можете попасть в то же место, что и встроенный memcpy.

Наконец, вы также можете попробовать уловки с __builtin_constant_p или его эквивалентами, чтобы эффективно справиться с небольшим известным случаем.

¹ Обратите внимание, что здесь я провожу различие между «распределением» размеров - например, можно сказать _ равномерно распределенным между 8 и 24 байтами - и «предсказуемостью» фактической последовательности размеров ( например, есть ли у размеров предсказуемая закономерность)? Вопрос предсказуемости несколько тонкий, потому что он зависит от реализации, поскольку, как описано выше, определенные реализации по своей сути более предсказуемы.

² В частности, ~ 750 байтов инструкций в clang и ~ 600 байтов в gcc только для тела, поверх 256-байтовой таблицы поиска переходов для тела переключателя, в котором было 180-250 инструкций ( gcc и clang соответственно). Godbolt link.

³ В основном 200 объединенных мопов из эффективного размера кэша мопов в 1000 инструкций. В то время как недавние x86 имели размер кэша uop около ~ 1500 uop, вы не можете использовать все это за пределами чрезвычайно выделенного заполнения вашей кодовой базы из-за ограничительных правил назначения кода для кеширования.

⁴ Варианты переключения имеют разную скомпилированную длину, поэтому скачок нельзя вычислить напрямую. Как бы то ни было, это можно было сделать по-другому: они могли бы использовать 16-битное значение в таблице поиска за счет отказа от использования memory-source для jmp, сократив его размер на 75%.

⁵ В отличие от условного предсказания ветвления, которое имеет типичную скорость предсказания в наихудшем случае ~ 50% (для полностью случайных ветвей), трудно предсказуемая косвенная ветвь может легко приблизиться к 100%, так как вы не Подбрасывая монетку, вы выбираете почти бесконечный набор целей ветвления. Это происходит в реальном мире: если memcpy используется для копирования небольших строк с длиной, равномерно распределенной от 0 до 30, код switch будет неверно предсказывать ~ 97% времени.

⁶ Конечно, за смещение магазинов могут быть штрафы, но они также, как правило, небольшие и становятся все меньше.

⁷ Например, memcpy в стек, за которым следует некоторая манипуляция и копирование в другое место, можно полностью исключить, напрямую перемещая исходные данные в их окончательное место. Даже такие вещи, как malloc, за которым следует memcpy, можно полностью исключить.

Во-первых, основной цикл использует загрузку / сохранение невыровненного вектора AVX для копирования 32 байтов за раз, пока не останется ‹32 байта для копирования:

    for ( ; Size >= sizeof(__m256i); Size -= sizeof(__m256i) )
    {
        __m256i ymm = _mm256_loadu_si256(((const __m256i* &)Src)++);
        _mm256_storeu_si256(((__m256i* &)Dst)++, ymm);
    }

Затем последний оператор switch обрабатывает остаточные 0..31 байта с максимальной эффективностью, используя при необходимости комбинацию 8/4/2/1 байтовых копий. Обратите внимание, что это не развернутый цикл - это всего лишь 32 различных оптимизированных пути кода, которые обрабатывают остаточные байты с использованием минимального количества загрузок и сохранений.

Что касается того, почему основной 32-байтовый цикл AVX не разворачивается вручную - для этого есть несколько возможных причин:

• большинство компиляторов автоматически разворачивают небольшие циклы (в зависимости от размера цикла и переключателей оптимизации)
• чрезмерное развертывание может вызвать выпадение небольших петель из LSD-кеша (обычно только 28 декодированных мкопов)
• на текущих процессорах Core iX вы можете выполнить только две одновременные загрузки / сохранения перед остановкой [*]
• обычно даже такой неразвернутый цикл AVX может привести к перегрузке доступной полосы пропускания DRAM [*]

[*] обратите внимание, что последние два комментария выше относятся к случаям, когда источник и / или место назначения не находятся в кэше (т.е. запись / чтение в / из DRAM), и поэтому задержка загрузки / сохранения высока.

Использование преимуществ ERMSB

Также рассмотрите возможность использования REP MOVSB ​​для больших блоков.

Как вы знаете, с тех пор, как в 1993 году был выпущен первый процессор Pentium, Intel начала выполнять простые команды быстрее, а сложные команды (например, REP MOVSB) - медленнее. Итак, REP MOVSB ​​стал очень медленным, и больше не было причин его использовать. В 2013 году Intel решила вернуться к REP MOVSB. Если ЦП имеет бит CPUID ERMSB (Enhanced REP MOVSB), то команды REP MOVSB ​​выполняются иначе, чем на старых процессорах, и должны быть быстрыми. На практике это быстро только для больших блоков, 256 байт и больше, и только при соблюдении определенных условий:

• и исходный, и целевой адреса должны быть выровнены по 16-байтовой границе;
• исходный регион не должен перекрываться с целевым регионом;
• длина должна быть кратна 64, чтобы обеспечить более высокую производительность;
• направление должно быть вперед (CLD).

См. Руководство Intel по оптимизации, раздел 3.7.6 Расширенные операции REP MOVSB ​​и STOSB (ERMSB) http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

Intel рекомендует использовать AVX для блоков размером менее 2048 байт. Для больших блоков Intel рекомендует использовать REP MOVSB. Это связано с высокими начальными затратами на запуск РЭП МОВСБ (около 35 циклов).

Я провел тесты скорости, и для блоков размером более 2048 байт производительность REP MOVSB ​​непревзойденная. Однако для блоков размером менее 256 байт REP MOVSB ​​работает очень медленно, даже медленнее, чем простой MOV RAX вперед и назад в цикле.

Обратите внимание, что ERMSB влияет только на MOVSB, а не на MOVSD (MOVSQ), поэтому MOVSB ​​немного быстрее, чем MOVSD (MOVSQ).

Итак, вы можете использовать AVX для своей реализации memcpy (), и если размер блока превышает 2048 байт и все условия соблюдены, тогда вызовите REP MOVSB ​​- так что ваша реализация memcpy () будет непревзойденной.

Использование преимуществ механизма исполнения вне очереди

Вы также можете прочитать о механизме выполнения вне очереди в "Справочном руководстве по оптимизации архитектур Intel® 64 и IA-32" http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf раздел 2.1.2, и воспользуйтесь его преимуществами.

Например, в серии процессоров Intel SkyLake (запущен в 2015 году) в нем есть:

• 4 исполнительных блока для арифметико-логического блока (ALU) (add, and, cmp, or, test, xor, movzx, movsx, mov, (v) movdqu, (v) movdqa, (v) movap *, (v) movup ),
• 3 исполнительных модуля для Vector ALU ((v) pand, (v) por, (v) pxor, (v) movq, (v) movq, (v) movap *, (v) movup *, (v) andp *, (v) orp *, (v) paddb / w / d / q, (v) blendv *, (v) blendp *, (v) pblendd)

Таким образом, мы можем занимать вышеуказанные единицы (3 + 4) параллельно, если мы используем только регистровые операции. Мы не можем использовать 3 + 4 инструкции параллельно для копирования в память. Мы можем одновременно использовать максимум две 32-байтовые инструкции для загрузки из памяти и одну 32-байтовую инструкцию для сохранения из памяти, даже если мы работаем с кешем уровня 1.

Пожалуйста, посмотрите руководство Intel еще раз, чтобы понять, как сделать самую быструю реализацию memcpy: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architecture-optimisation-manual.pdf

Раздел 2.2.2 (Механизм нарушения порядка в микроархитектуре Haswelll): «Планировщик контролирует отправку микроопераций на порты отправки. Имеется восемь портов отправки для поддержки ядра выполнения вне очереди. Четыре из восьми портов предоставлены ресурсы выполнения для вычислительных операций. Остальные 4 порта поддерживают операции с памятью до двух 256-битных операций загрузки и одной 256-битной операции сохранения в цикле ».

В разделе 2.2.4 (Кэш и подсистема памяти) есть следующее примечание: «Кэш данных первого уровня поддерживает две микрооперации загрузки в каждом цикле; каждая микрооперация может извлекать до 32 байтов данных».

Раздел 2.2.4.1 (Улучшения операций загрузки и сохранения) содержит следующую информацию: Кэш данных L1 может обрабатывать две 256-битные (32 байта) операции загрузки и одну 256-битную (32 байта) операции сохранения в каждом цикле. Унифицированный L2 может обслуживать одну строку кэша (64 байта) за каждый цикл. Кроме того, доступно 72 буфера загрузки и 42 буфера хранения для поддержки выполнения микроопераций на лету.

Остальные разделы (2.3 и т. Д., Посвященные Sandy Bridge и другим микроархитектурам) в основном повторяют вышеизложенную информацию.

В разделе 2.3.4 (Ядро выполнения) приведены дополнительные сведения.

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

• Порт 0: ALU, Shift, Mul, STTNI, Int-Div, 128b-Mov, Blend, 256b-Mov
• Порт 1: ALU, быстрый LEA, медленный LEA, MUL, Shuf, Blend, 128bMov, Add, CVT
• Порт 2 и порт 3: Load_Addr, Store_addr
• Порт 4: Store_data
• Порт 5: ALU, Shift, Branch, Fast LEA, Shuf, Blend, 128b-Mov, 256b-Mov

Раздел 2.3.5.1 (Обзор операций загрузки и сохранения) также может быть полезен для понимания того, как сделать быстрое копирование в память, а также раздел 2.4.4.1 (Загрузка и сохранение).

Для других архитектур процессоров это опять же - две единицы нагрузки и одна единица хранения. Таблица 2-4 (Параметры кэша микроархитектуры Skylake) содержит следующую информацию:

Пиковая пропускная способность (байтов / цикл):

• Кэш данных первого уровня: 96 байт (2x32B нагрузки + 1 * 32B Store)
• Кэш второго уровня: 64 байта
• Кэш третьего уровня: 32 байта.

Я также провел тесты скорости на моем процессоре Intel Core i5 6600 (Skylake, 14 нм, выпущенном в сентябре 2015 года) с памятью DDR4, и это подтвердило теорию. Например, мой тест показал, что использование общих 64-битных регистров для копирования памяти, даже если несколько регистров параллельно, снижает производительность. Кроме того, достаточно использовать только 2 регистра XMM - добавление 3-го не увеличивает производительности.

Если ваш ЦП имеет бит AVX CPUID, вы можете воспользоваться преимуществами больших 256-битных (32 байтовых) регистров YMM для копирования памяти, чтобы занять два модуля полной загрузки. Поддержка AVX была впервые представлена ​​Intel с процессорами Sandy Bridge, поставка которых состоялась в первом квартале 2011 года, а затем AMD с процессорами Bulldozer, поставленными в третьем квартале 2011 года.

// first cycle  
vmovdqa ymm0, ymmword ptr [rcx+0]      // load 1st 32-byte part using first load unit
vmovdqa ymm1, ymmword ptr [rcx+20h]    // load 2nd 32-byte part using second load unit

// second cycle
vmovdqa ymmword ptr [rdx+0], ymm0      // store 1st 32-byte part using the single store unit

// third cycle
vmovdqa ymmword ptr [rdx+20h], ymm1    ; store 2nd 32-byte part - using the single store unit (this instruction will require a separate cycle since there is only one store unit, and we cannot do two stores in a single cycle)

add ecx, 40h // these instructions will be used by a different unit since they don't invoke load or store, so they won't require a new cycle
add edx, 40h

Кроме того, есть преимущество в скорости, если вы развернете этот код как минимум 8 раз. Как я писал ранее, добавление дополнительных регистров, помимо ymm0 и ymm1, не увеличивает производительность, потому что есть только две единицы загрузки и одна единица хранения. Добавление циклов типа «dec r9 jnz @@ again» снижает производительность, а простое «add ecx / edx» - нет.

Наконец, если ваш процессор имеет расширение AVX-512, вы можете использовать 512-битные (64-байтовые) регистры для копирования памяти:

vmovdqu64   zmm0, [rcx+0]           ; load 1st 64-byte part
vmovdqu64   zmm1, [rcx+40h]         ; load 2nd 64-byte part 

vmovdqu64   [rdx+0], zmm0           ; store 1st 64-byte part
vmovdqu64   [rdx+40h], zmm1         ; store 2nd 64-byte part 

add     rcx, 80h
add     rdx, 80h    

AVX-512 поддерживается следующими процессорами: Xeon Phi x200, выпущенный в 2016 году; Процессоры Skylake EP / EX Xeon "Purley" (Xeon E5-26xx V5) (второе полугодие 2017 г.); Процессоры Cannonlake (вторая половина 2017 года), процессоры Skylake-X - Core i9-7 ××× X, i7-7 ××× X, i5-7 ××× X - выпущены в июне 2017 года.

Обратите внимание, что память должна быть выровнена по размеру регистров, которые вы используете. Если это не так, используйте "невыровненные" инструкции: vmovdqu и moveups.