Особенности вызова функций в С++

    Не так давно у меня произошёл очередной разговор с коллегой на извечную тему: "по ссылке, или по значению". В результате возникла данная статья. В ней я хочу изложить результаты моего исследования по этой и смежным темам. Далее будут рассмотрены:


    • Регистры и их назначение при вызове функций.
    • Передача и возврат простых типов и структур.
    • Как передача по ссылке и по значению влияют на оптимизации тела функции компилятором.
    • Как используется место при многочисленных вызовах функций.
    • Механизм виртуальных вызовов.
    • Оптимизация хвостовых вызовов и рекурсии.
    • Инициализация структур, массивов и векторов.

    Осторожно! Статья содержит большое количество кода на C++ и ассемблере (Intel ASM с комментариями), а также множество таблиц с оценками производительности. Всё написанное актуально для x86-64 System V ABI, который используется во всех современных Unix операционных системах, к примеру, в Linux и macOS.


    Информация бралась из документа System V Application Binary Interface for x86-64. Ассемблерные листинги получены для clang 5.0.0 x86-64 с флагами -O3 -std=c++1z -march=sandybridge (с помощью сайта https://godbolt.org). Оценки производительности были сделаны для процессора Intel® Xeon® CPU E5-2660 2.20GHz.


    Содержание



    Регистры в x86-64


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


    • 16 регистров общего назначения: rax, rbx, rcx, rdx, rbp, rsi, rdi, rsp а также r8-r15. Размер каждого из них равен 64 битам (8 байтам). Для доступа к младшим 32 битам (4 байтам) используется префикс e вместо r (raxeax). Поддерживают только не векторные целочисленные операции.
    • rip (instruction pointer) указывает на инструкцию, которая будет исполнена следующей. Различные константные данные, лежащие в разделе памяти с инструкциями, могут считываться по смещению относительно rip.
    • rsp (stack pointer) указывает на последний элемент в стеке. Стек растёт в сторону меньших адресов. Запихивание чего-то в стек уменьшает значение rsp.
    • 16 SSE регистров размером 128 бит: xmm0 - xmm15. Если поддерживается режим AVX, то они ссылаются на младшие 128 бит регистров ymm0 - ymm15 каждый из которых имеет размер 256 бит. Для векторных, или не целочисленных операций, данные необходимо предварительно загрузить в эти регистры.

    Передача параметров


    В этом параграфе приведено несколько сокращённое и упрощённое описание алгоритма распределения аргументов по регистрам/стеку. Полное описание можно увидеть на странице 17 "System V ABI".


    Введём несколько классов объектов:


    • INTEGER – интегральные типы, помещающиеся в регистры общего пользования. Это bool, char, int и так далее.
    • SSE – числа с плавающей точкой, вмещающиеся в векторный регистр. Это float и double.
    • MEMORY – объекты, передаваемые через стек.

    Для унификации описания, типы __int128 и complex представляются как структуры из двух полей:


    struct __int128 {
      int64 low, high;
    };
    struct complexT {
      T real, imag;
    }; // Где T - float, или double.

    В начале каждый аргумент функции классифицируется:


    1. Если тип больше 128 бит, или имеет не выровненные поля, то он MEMORY.
    2. Если есть нетривиальные деструктор, конструктор копирования, виртуальные методы, виртуальные базовые классы, то он передаётся через "прозрачную ссылку". Объект заменяется указателем, который имеет тип INTEGER.
    3. Агрегаты, а это структуры и массивы, анализируются кусками по 8 байт.
      1. Если в куске есть поле типа MEMORY, то весь кусок MEMORY.
      2. Если есть поле типа INTEGER, то весь кусок INTEGER.
      3. Иначе весь кусок SSE .
    4. Если есть кусок типа MEMORY, то весь аргумент MEMORY.
    5. Типы long double и complex long double используют специальный набор x87 FPU регистров и имеют тип MEMORY.
    6. Типы __m256, __m128 и __float128 имеют тип SSE .

    После классификации, все 8 байтные куски (в одном куске может быть несколько полей структуры, или элементов массива) распределяются по регистрам:


    1. MEMORY передаются через стек.
    2. INTEGER передаются через следующий свободный регистр rdi, rsi, rdx, rcx, r8, r9 в именно таком порядке.
    3. SSE передаются через следующий свободный регистр xmm0 - xmm7.

    Аргументы рассматриваются слева направо. Те аргументы, которым не хватило регистров, передаются через стек. Если какому-либо куску аргумента не хватило регистра, то весь аргумент передаётся через стек.


    Возвращение значений производится следующим образом:


    1. MEMORY типы возвращаются через стек. Место на нём предоставляется вызывающей функцией и адрес его начала передаётся через rdi как будто бы это первый аргумент функции. При возврате это адрес должен быть возвращён через rax. Первый оригинальный аргумент будет передан, соответственно, как второй, и так далее.
    2. INTEGER кусок возвращается через следующий свободный регистр rax, rdx.
    3. SSE кусок возвращается через следующий свободный регистр xmm0, xmm1. Эти регистры используются как для приёма, так и для возврата значений.

    Сводная таблица с регистрами и их назначением, очень полезна при чтении ассемблера:


    Регистр Назначение
    rax Временный регистр, возврат первого (ret 1) INTEGER результата.
    rbx Принадлежит вызывающей функции, не должен быть изменён на момент возврата.
    rcx Передача четвёртого (4) INTEGER аргумента.
    rdx Передача третьего (3) INTEGER аргумента, возврат второго (ret 2) INTEGER результата.
    rsp Указатель на стек.
    rbp Принадлежит вызывающей функции, не должен быть изменён на момент возврата.
    rsi Передача второго (2) INTEGER аргумента.
    rdi Передача первого (1) INTEGER аргумента.
    r8 Передача пятого (5) INTEGER аргумента.
    r9 Передача шестого (6) INTEGER аргумента.
    r10-r11 Временные регистры.
    r12-r15 Принадлежит вызывающей функции, не должны быть изменены на момент возврата.
    xmm0-xmm1 Передача и возврат первого и второго SSE аргументов.
    xmm2-xmm7 Передача с третьего по шестой SSE аргументов.
    xmm8-xmm15 Временные регистры.

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


    Простые примеры


    Если явно не указано обратное, то все используемые функции были помечены как NOINLINE. Делаем вид, что тело функции расположено в cpp файле, а LTO отключено. Также все результаты функций передаются в пустую NOINLINE функцию, чтобы предотвратить удаление всего кода оптимизатором.


    #define NOINLINE __attribute__((noinline))
    #define INLINE static __attribute__((always_inline))

    Рассмотрим что-нибудь простое.


    double foo(int8_t a, int16_t b, int32_t c, int64_t d, float x, double y) {
      return a + b + c + d + x + y;
    }
    ...
    auto result = foo(1, 2, 3, 4, 5, 6);

    Параметры передаются так:


    Имя Регистр Имя Регистр Результат
    a rdi d rcx xmm0
    b rsi x xmm0
    c rdx y xmm1

    Рассмотрим сгенерированный код подробнее.


    foo(signed char, short, int, long, float, double):
      add edi, esi # Складываем a и b.
      add edi, edx # Прибавляем c.
      movsxd rax, edi # Копируем результат в rax, расширяя его до 64 бит с сохранением знака.
      add rax, rcx # Прибавляем d.
      vcvtsi2ss xmm2, xmm2, rax # Конвертируем результат в float и сохраняем его в xmm2.
      vaddss xmm0, xmm2, xmm0 # Прибавляем x, суффикс 's' инструкции vaddss обозначает работу с single precision.
      vcvtss2sd xmm0, xmm0, xmm0 # Конвертируем результат в double.
      vaddsd xmm0, xmm0, xmm1 # Прибавляем y, суффикс 'd' команды vaddsd обозначает работу с double precision.
      ret # Выходим из функции и переходим по адресу, сохранённому на вершине стека, стек при этом уменьшается, то есть rsp увеличивается на 8.
    .LCPI1_0: # Секция с константными данными.
      .long 1084227584 # float 5
    .LCPI1_1:
      .quad 4618441417868443648 # double 6
    main: # @main
      sub rsp, 24
      # Распределяем аргументы по соответствующим регистрам.
      vmovss xmm0, dword ptr [rip + .LCPI1_0] # xmm0 = mem[0],zero,zero,zero
      vmovsd xmm1, qword ptr [rip + .LCPI1_1] # xmm1 = mem[0],zero
      mov edi, 1
      mov esi, 2
      mov edx, 3
      mov ecx, 4
      call foo(signed char, short, int, long, float, double) # call сохраняет адрес возврата на вершину стека, тем самым уменьшая rsp на 8, и переходит к месту начала функции.
      vmovsd qword ptr [rsp + 16], xmm0 # Копируем результат обратно на стек.

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


    Рассмотрим различные примеры агрегатов. Массивы можно рассматривать как структуры с несколькими полями.


    struct St {
      double a, b;
    };
    double foo(St s) { return s.a + s.b; }
    ...
    St s{1, 2};
    auto result = foo(s);

    Имя Регистр Имя Регистр Результат
    s.a xmm0 s.b xmm1 xmm0

    Казалось бы, ничто не мешает запихнуть сразу два double в один xmm регистр. Но увы, алгоритм распределения оперирует только восьмибайтными кусками.


    foo(St): # @foo(St)
      vaddsd xmm0, xmm0, xmm1 # Прибавляем второй аргумент к первому, который уже находится в регистре с результатом.
      ret
    .LCPI1_0:
      .quad 4607182418800017408 # double 1
    .LCPI1_1:
      .quad 4611686018427387904 # double 2
    main: # @main
      sub rsp, 24
      # Заполняем входные регистры.
      vmovsd xmm0, qword ptr [rip + .LCPI1_0] # xmm0 = mem[0],zero
      vmovsd xmm1, qword ptr [rip + .LCPI1_1] # xmm1 = mem[0],zero
      call foo(St)  
      vmovsd qword ptr [rsp + 16], xmm0 # Копируем double из регистра с результатом.

    Если добавить ещё одно double поле, то вся структура будет передана через стек, так как её размер превысит 128 байт.


    struct St {
      double a, b, c;
    };
    double foo(St s) { return s.a + s.b + s.c; }
    ...
    St s{1, 2, 3};
    auto result = foo(s);

    foo(St): # @foo(St)
      # При вызове функции, стек увеличивается на 8 байт, в которых хранится адрес возврата. Так как стек растёт в сторону уменьшения адреса, то первый аргумент будет расположен со по адресу rsp+8.
      vmovsd xmm0, qword ptr [rsp + 8] # xmm0 = mem[0],zero
      vaddsd xmm0, xmm0, qword ptr [rsp + 16]
      vaddsd xmm0, xmm0, qword ptr [rsp + 24]
      ret
    .L_ZZ4mainE1s:
      .quad 4607182418800017408 # double 1
      .quad 4611686018427387904 # double 2
      .quad 4613937818241073152 # double 3
    main: # @main
      sub rsp, 40 # Выделяем на стеке 40 байт.
      # Константы хранятся в разделе памяти с кодом, перекидываем их на стек. Это приходится делать через промежуточный регистр, так как mov не может копировать из памяти в память.
      mov rax, qword ptr [rip + .L_ZZ4mainE1s+16] # Загружаем в регистр '3'.
      mov qword ptr [rsp + 16], rax # Копируем '3' на стек.
      vmovups xmm0, xmmword ptr [rip + .L_ZZ4mainE1s] # Загружаем в xmm0 сразу '1' и '2'.
      vmovups xmmword ptr [rsp], xmm0 # Копируем '1' и '2 на стек. Сейчас стек выглядит так: 1 = *rsp , 2 = *(rsp+8), 3 = *(rsp+16).
      call foo(St)
      vmovsd qword ptr [rsp + 32], xmm0 # Копируем на стек один double с результатом.

    Посмотрим, что будет, если заменить double на uint64_t.


    struct St {
      uint64_t a, b;
    };
    uint64_t foo(St s) { return s.a + s.b; }
    ...
    St s{1, 2};
    auto result = foo(s);

    Имя Регистр Имя Регистр Результат
    s.a rdi s.b rsi rax

    foo(St): # @foo(St)
      lea rax, [rdi + rsi]
      ret
    main: # @main
      sub rsp, 24
      mov edi, 1
      mov esi, 2
      call foo(St)
      mov qword ptr [rsp + 16], rax

    Результат заметно компактнее. Подробнее про то, почему используется инструкция lea а не add, можно почитать, к примеру, тут: https://stackoverflow.com/a/6328441/1418863


    Если добавить ещё одно поле, то, как и в примере с double, структура будет передана через стек. Код, кстати, будет почти идентичен, даже загрузка на стек будет производиться через xmm регистры.


    Рассмотрим что-нибудь более интересное.


    struct St {
      float a, b, c, d;
    };
    St foo(St s1, St s2) {
      return {s1.a + s2.a, s1.b + s2.b, s1.c + s2.c, s1.d + s2.d};
    }
    ...
    St s1{1, 2, 3, 4}, s2{5, 6, 7, 8}; 
    auto result = foo(s1, s2);

    Имя Регистр Имя Регистр Результат
    s1.a xmm0 s1.b xmm0 xmm0, xmm1
    s1.c xmm1 s1.d xmm1
    s2.a xmm2 s2.b xmm2
    s2.c xmm3 s2.d xmm3

    В каждый xmm регистр запихиваются по два float поля.


    foo(St, St): # @foo(St, St)
      # Одной инструкцией vaddps складываем сразу два float значения.
      vaddps xmm0, xmm0, xmm2 
      vaddps xmm1, xmm1, xmm3
      ret
    .LCPI1_0:
      .long 1065353216 # float 1
      .long 1073741824 # float 2
      .zero 4
      .zero 4
      # Аналогично определены LCPI1_1 - LCPI1_3.
    ...
    main: # @main
      sub rsp, 24
      # Заполняем регистры, копируя константные данные из области кода.
      vmovapd xmm0, xmmword ptr [rip + .LCPI1_0] # xmm0 = <1,2,u,u>
      vmovapd xmm1, xmmword ptr [rip + .LCPI1_1] # xmm1 = <3,4,u,u>
      vmovaps xmm2, xmmword ptr [rip + .LCPI1_2] # xmm2 = <5,6,u,u>
      vmovaps xmm3, xmmword ptr [rip + .LCPI1_3] # xmm3 = <7,8,u,u>
      call foo(St, St)
      # Так как тут нужно загрузить результат в стек, то предварительно два регистра с результатом смешиваются в один. xmm имеет размер 256 байт, поэтому в младшие 128 байт копируются поля a и b, в старшие - c и d.
      vunpcklpd xmm0, xmm0, xmm1 # xmm0 = xmm0[0],xmm1[0]
      vmovupd xmmword ptr [rsp + 8], xmm0

    Если бы в структуре было не 4, а три поля, то код функции был бы аналогичен, за исключением замены второй инструкции vaddps на vaddss, которая складывает только первые 64 бита регистра.


    struct St {
      int32_t a, b, c, d;
    };
    St foo(St s1, St s2) {
      return {s1.a + s2.a, s1.b + s2.b, s1.c + s2.c, s1.d + s2.d};
    }
    ...
    St s1{1, 2, 3, 4}, s2{5, 6, 7, 8}; 
    auto result = foo(s1, s2);

    Имя Регистр Имя Регистр Результат
    s1.a rdi s1.b rdi rax, rdx
    s1.c rsi s1.d rsi
    s2.a rdx s2.b rdx
    s2.c rcx s2.d rcx

    foo(St, St): # @foo(St, St)
      lea eax, [rdx + rdi]
      movabs r8, -4294967296 # 0xFFFFFFFF00000000 Битовая маска.
      and rdi, r8
      add rdi, rdx
      and rdi, r8
      or rax, rdi
      lea edx, [rcx + rsi] # То же, что и add.
      and rsi, r8
      add rsi, rcx
      and rsi, r8
      or rdx, rsi
      ret
    main: # @main
      sub rsp, 24
      movabs rdi, 8589934593 # Загружаем в регистры сразу по два числа.
      movabs rsi, 17179869187
      movabs rdx, 25769803781
      movabs rcx, 34359738375
      call foo(St, St)
      mov qword ptr [rsp + 8], rax # Копируем результат на стек.
      mov qword ptr [rsp + 16], rdx

    Внутри функции происходит битовая магия, но принцип примерно ясен. Каждая пара 32 битных чисел запаковывается в один 64 битный регистр. Возврат производится таким же образом.


    Посмотрим, что будет, если начать смешивать типы полей, но так, чтобы в пределах 8 байтовых кусков они были одинакового класса.


    struct St {
      int32_t a, b;
      float c, d;
    };
    St foo(St s1, St s2) {
      return {s1.a + s2.a, s1.b + s2.b, s1.c + s2.c, s1.d + s2.d};
    }
    ...
    St s1{1, 2, 3, 4}, s2{5, 6, 7, 8};
    auto result = foo(s1, s2);

    Имя Регистр Имя Регистр Результат
    s1.a rdi s1.b rdi rax, xmm0
    s1.c xmm0 s1.d xmm0
    s2.a rsi s2.b rsi
    s2.c xmm1 s2.d xmm1

    foo(St, St): # @foo(St, St)
      lea eax, [rsi + rdi] # Эта часть аналогична предыдущему примеру.
      movabs rcx, -4294967296
      and rdi, rcx
      add rdi, rsi
      and rdi, rcx
      or rax, rdi
      vaddps xmm0, xmm0, xmm1 # Складываем сразу два поля.
      ret
    .LCPI1_0:
      .long 1077936128 # float 3
      .long 1082130432 # float 4
      .zero 4
      .zero 4
    ...
    main: # @main
      sub rsp, 24
      vmovaps xmm0, xmmword ptr [rip + .LCPI1_0] # xmm0 = <3,4,u,u>
      vmovaps xmm1, xmmword ptr [rip + .LCPI1_1] # xmm1 = <7,8,u,u>
      movabs rdi, 8589934593
      movabs rsi, 25769803781
      call foo(St, St)
      mov qword ptr [rsp + 8], rax # Копируем результат на стек.
      vmovlps qword ptr [rsp + 16], xmm0

    Но это не интересно, так как типы полей в каждом 8 байтном куске совпадают. Перемешаем поля.


    struct St {
      int32_t a;
      float b;
      int32_t c;
      float d;
    };
    St foo(St s1, St s2) {
      return {s1.a + s2.a, s1.b + s2.b, s1.c + s2.c, s1.d + s2.d};
    }
    ...
    St s1{1, 2, 3, 4}, s2{5, 6, 7, 8};
    auto result = foo(s1, s2);

    Имя Регистр Имя Регистр Результат
    s1.a rdi s1.b rdi rax, rdx
    s1.c rsi s1.d rsi
    s2.a rdx s2.b rdx
    s2.c rcx s2.d rcx

    Смотрим пункт 3.2. Так как в 8 байтном куске есть и float, и int, то весь кусок будет иметь тип INTEGER и будет передан в регистрах общего назначения.


    foo(St, St): # @foo(St, St)
      mov rax, rdx
      add edx, edi
      shr rdi, 32
      vmovd xmm0, edi
      mov rdi, rcx
      add ecx, esi
      shr rsi, 32
      vmovd xmm1, esi
      shr rax, 32
      vmovd xmm2, eax
      vaddss xmm0, xmm0, xmm2
      shr rdi, 32
      vmovd xmm2, edi
      vaddss xmm1, xmm1, xmm2
      vmovd eax, xmm0
      shl rax, 32
      or rdx, rax
      vmovd eax, xmm1
      shl rax, 32
      or rcx, rax
      mov rax, rdx
      mov rdx, rcx
      ret
    main: # @main
      sub rsp, 24
      movabs rdi, 4611686018427387905 # 0x4000000000000001, в младших 32 битах хранится int, в старших - float.
      movabs rsi, 4647714815446351875
      movabs rdx, 4665729213955833861
      movabs rcx, 4683743612465315847
      call foo(St, St)
      mov qword ptr [rsp + 8], rax # Возвращается результат тоже исключительно через 64 битные регистры.
      mov qword ptr [rsp + 16], rdx

    Тут можно видеть 6 операций сдвига для извлечения float полей и их запихивания в регистр с результатом. А также отсутствие каких-либо векторных операций. В общем, лучше не мешать типы полей в пределах 8 байтовых кусков структуры.


    Передача по ссылке


    Передача параметров по константной ссылке аналогично передаче указателя на объект. Если объект не помещается в регистрах, то он передаётся и возвращается через стек. Посмотрим, как это происходит. Для реалистичности рассмотрим структуру для трёхмерной точки.


    struct Point3f {
      float x, y, z;
    };
    struct Point3d {
      double x, y, z;
    };
    Point3f scale(Point3f p) { return {p.x * 2, p.y * 2, p.z * 2}; }
    Point3f scaleR(const Point3f& p) { return {p.x * 2, p.y * 2, p.z * 2}; }
    Point3d scale(Point3d p) { return {p.x * 2, p.y * 2, p.z * 2}; }
    Point3d scaleR(const Point3d& p) { return {p.x * 2, p.y * 2, p.z * 2}; }

    Сравним код функций. Использоваться будут преимущественно новые xmm регистры, поэтому логика вполне понятна.


    scale(Point3f): # @scale(Point3f)
      # Как и в прошлых примерах, x, y передаются в xmm0, z - xmm1, возвращается результат в них же.
      vaddps xmm0, xmm0, xmm0
      vaddss xmm1, xmm1, xmm1  
      ret
    scaleR(Point3f const&): # @scaleR(Point3f const&)
      # Указатель на аргумент находится в регистре rdi, служащего для передачи первого аргумента. Возврат так же через регистры xmm0, xmm1.
      vmovsd xmm0, qword ptr [rdi] # xmm0 = mem[0],zero
      vaddps xmm0, xmm0, xmm0
      vmovss xmm1, dword ptr [rdi + 8] # xmm1 = mem[0],zero,zero,zero
      vaddss xmm1, xmm1, xmm1
      ret
    scale(Point3d): # @scale(Point3d)
      # В регистре rdi передаётся адрес, по которому нужно записывать результат. Сам аргумент передаётся через стек и расположен по адресам [rsp+8, rsp+32). В [rsp, rsp+8) находится адрес возврата из функции.
      vmovapd xmm0, xmmword ptr [rsp + 8]
      vaddpd xmm0, xmm0, xmm0
      vmovupd xmmword ptr [rdi], xmm0
      vmovsd xmm0, qword ptr [rsp + 24] # xmm0 = mem[0],zero
      vaddsd xmm0, xmm0, xmm0
      vmovsd qword ptr [rdi + 16], xmm0
      mov rax, rdi # Возвращаем адрес, по которому записан результат.
      ret
    scaleR(Point3d const&): # @scaleR(Point3d const&)
      # Код абсолютно идентичен, но аргумент начинается не в [rsp+8, rsp+32), а в [rsi, rsi+24).
      vmovupd xmm0, xmmword ptr [rsi]
      vaddpd xmm0, xmm0, xmm0
      vmovupd xmmword ptr [rdi], xmm0
      vmovsd xmm0, qword ptr [rsi + 16] # xmm0 = mem[0],zero
      vaddsd xmm0, xmm0, xmm0
      vmovsd qword ptr [rdi + 16], xmm0
      mov rax, rdi
      ret

    Теперь посмотрим на место вызова этих функций.


    # scale(Point3f)
    main: # @main 
      sub rsp, 24
      # Копируем константы во входные регистры.
      vmovaps xmm0, xmmword ptr [rip + .LCPI4_0] # xmm0 = <1,2,u,u>
      vmovss xmm1, dword ptr [rip + .LCPI4_1] # xmm1 = <3,u,u,u>
      call scale(Point3f)
    
    # scaleR(const Point3f&)
    main: # @main  
      sub rsp, 24
      # Просто записываем адрес участка с константами в регистр rdi, в котором передаётся первый аргумент.
      mov edi, .L_ZZ4mainE1p # <1,2,3,u>
      call scaleR(Point3f const&)
    
    # scale(Point3d)
    main: # @main
      sub rsp, 64
      # Копируем константы из раздела с данным на стек.
      mov rax, qword ptr [rip + .L_ZZ4mainE1p+16]
      mov qword ptr [rsp + 16], rax
      vmovups xmm0, xmmword ptr [rip + .L_ZZ4mainE1p]
      vmovups xmmword ptr [rsp], xmm0  
      lea rbx, [rsp + 40]
      mov rdi, rbx # Результат будет записан в [rsp+40, rsp+64).
      call scale(Point3d)
    .L_ZZ4mainE1p:
      .quad 4607182418800017408 # double 1
      .quad 4611686018427387904 # double 2
      .quad 4613937818241073152 # double 3
    
      # scaleR(const Point3d&)
    main: # @main
      sub rsp, 64
      # То же самое.
      mov rax, qword ptr [rip + .L_ZZ4mainE1p+16]
      mov qword ptr [rsp + 32], rax
      vmovups xmm0, xmmword ptr [rip + .L_ZZ4mainE1p]
      vmovaps xmmword ptr [rsp + 16], xmm0
      lea rbx, [rsp + 40]
      lea rsi, [rsp + 16] # Аргумент будет по адресу [rsp+16, rsp+40).
      mov rdi, rbx # Результат будет записан в [rsp+40, rsp+64).
      call scaleR(Point3d const&)  

    Посмотрим, что если у нас много полей, но структура всё-таки влезает в регистры. Тут начинается самое интересное.


    struct St {
      char d[16];
    };
    
    St foo(St s1, St s2) {  // Просто суммируем s1 и s2.
        St res; 
        for(int i{}; i < 16; ++i) res.d[i] = s1.d[i] + s2.d[i]; 
        return res;
    }

    Код для функции, принимающей аргументы по значению.


    Имя Регистр Имя Регистр Результат
    s1.d[1:8] rdi s1.d[8:16] rsi rax, rdx
    s2.d[1:8] rdx s2.d[8:16] rcx

    foo(St, St): # @foo(St, St)
      mov qword ptr [rsp - 16], rdi
      mov qword ptr [rsp - 8], rsi
      mov qword ptr [rsp - 32], rdx
      mov qword ptr [rsp - 24], rcx
      mov eax, edx
      add al, dil
      mov byte ptr [rsp - 48], al
      mov r8, rdi
      shr r8, 8
      mov rax, rdx
      shr rax, 8
      add al, r8b
      mov byte ptr [rsp - 47], al
      mov r8, rdi
      shr r8, 16
      mov rax, rdx
      shr rax, 16
      add al, r8b
      mov byte ptr [rsp - 46], al
      mov r8, rdi
      shr r8, 24
      mov rax, rdx
      shr rax, 24
      add al, r8b
      mov byte ptr [rsp - 45], al
      mov r8, rdi
      shr r8, 32
      mov rax, rdx
      shr rax, 32
      add al, r8b
      mov byte ptr [rsp - 44], al
      mov r8, rdi
      shr r8, 40
      mov rax, rdx
      shr rax, 40
      add al, r8b
      mov byte ptr [rsp - 43], al
      mov r8, rdi
      shr r8, 48
      mov rax, rdx
      shr rax, 48
      add al, r8b
      mov byte ptr [rsp - 42], al
      shr rdi, 56
      shr rdx, 56
      add dl, dil
      mov byte ptr [rsp - 41], dl
      mov eax, ecx
      add al, sil
      mov byte ptr [rsp - 40], al
      mov rax, rsi
      shr rax, 8
      mov rdx, rcx
      shr rdx, 8
      add dl, al
      mov byte ptr [rsp - 39], dl
      shr rsi, 16
      shr rcx, 16
      add cl, sil
      mov byte ptr [rsp - 38], cl
      mov al, byte ptr [rsp - 21]
      mov cl, byte ptr [rsp - 20]
      add al, byte ptr [rsp - 5]
      mov byte ptr [rsp - 37], al
      add cl, byte ptr [rsp - 4]
      mov byte ptr [rsp - 36], cl
      mov al, byte ptr [rsp - 19]
      mov cl, byte ptr [rsp - 18]
      add al, byte ptr [rsp - 3]
      mov byte ptr [rsp - 35], al
      add cl, byte ptr [rsp - 2]
      mov byte ptr [rsp - 34], cl
      mov al, byte ptr [rsp - 17]
      add al, byte ptr [rsp - 1]
      mov byte ptr [rsp - 33], al
      mov rax, qword ptr [rsp - 48]
      mov rdx, qword ptr [rsp - 40]
      ret

    Да, тут все аргументы копируются на стек, после чего из него извлекается и складывается по одному байту за раз. Как можно посчитать, в функции ровно 16 инструкций add. GCC, кстати, в данном примере выдаёт гораздо более компактный код, но всё так же с копированием через стек. Можно ли что-то улучшить? Передадим структуру по ссылке.


    St fooR(const St& s1, const St& s2) { /* Без изменений. */ }

    Имя Регистр Имя Регистр Результат
    s1 rdi s2 rsi rax, rdx

    fooR(St const&, St const&): # @fooR(St const&, St const&)
      vmovdqu xmm0, xmmword ptr [rsi]
      vpaddb xmm0, xmm0, xmmword ptr [rdi]
      vmovdqa xmmword ptr [rsp - 24], xmm0
      mov rax, qword ptr [rsp - 24]
      mov rdx, qword ptr [rsp - 16]
      ret

    О да! Это выглядит гораздо лучше. Мы можем загрузить сразу 16 однобайтовых элементов в xmm регистр и вызывать vpaddb которая их все сложит за одну операцию. После этого результат копируется в выходные регистры через стек. Можно подумать, что от этой последней операции можно избавиться, заменив первый аргумент на не константную ссылку.


    void fooR1(St &s1, const St& s2) { 
        for(int i{}; i < 16; ++i) s1.d[i] += s2.d[i];
    }

    Имя Регистр Имя Регистр Результат
    s1 rdi s2 rsi

    fooR1(St&, St const&): # @fooR1(St&, St const&)
      mov al, byte ptr [rsi]
      add byte ptr [rdi], al
      mov al, byte ptr [rsi + 1]
      add byte ptr [rdi + 1], al
      mov al, byte ptr [rsi + 2]
      add byte ptr [rdi + 2], al
      mov al, byte ptr [rsi + 3]
      add byte ptr [rdi + 3], al
      mov al, byte ptr [rsi + 4]
      add byte ptr [rdi + 4], al
      mov al, byte ptr [rsi + 5]
      add byte ptr [rdi + 5], al
      mov al, byte ptr [rsi + 6]
      add byte ptr [rdi + 6], al
      mov al, byte ptr [rsi + 7]
      add byte ptr [rdi + 7], al
      mov al, byte ptr [rsi + 8]
      add byte ptr [rdi + 8], al
      mov al, byte ptr [rsi + 9]
      add byte ptr [rdi + 9], al
      mov al, byte ptr [rsi + 10]
      add byte ptr [rdi + 10], al
      mov al, byte ptr [rsi + 11]
      add byte ptr [rdi + 11], al
      mov al, byte ptr [rsi + 12]
      add byte ptr [rdi + 12], al
      mov al, byte ptr [rsi + 13]
      add byte ptr [rdi + 13], al
      mov al, byte ptr [rsi + 14]
      add byte ptr [rdi + 14], al
      mov al, byte ptr [rsi + 15]
      add byte ptr [rdi + 15], al
      ret

    Кажется, что-то пошло не так. Это получилось из-за того, что, по умолчанию, компилятор очень осторожен, и предполагает, что программист может быть не в духе и напишет что-то вроде такого:


    char buff[17];
    fooR1(*reinterpret_cast<St*>(buff+1), reinterpret_cast<const St*>(buff));

    В этом случае, на каждой итерации вычисляется buff[i+1] += buff[i], то есть имеется pointer aliasing. Для того, чтобы указать компилятору, что такого странного использования функции не предвидится, существует ключевое слово __restrict.


    void fooR2(St & __restrict s1, const St& s2) { /* Без изменений. */ }

    Что и даёт желаемый результат.


    fooR2(St&, St const&): # @fooR2(St&, St const&)
      vmovdqu xmm0, xmmword ptr [rdi]
      vpaddb xmm0, xmm0, xmmword ptr [rsi]
      vmovdqu xmmword ptr [rdi], xmm0
      ret

    Изменении сигнатуры на void fooR3(St &__restrict s1, St s2), тоже приведёт к раздутому ассемблерному коду, похожему на первый пример с St foo(St, St).


    Кстати, если размер массива заранее не известен, то void foo(char* __restrict s1, const char* s2, int size) генерирует примерно в полтора раза меньше строк кода, чем версия без __restrict.


    Сравнение производительности


    Будем четыре раза прибавлять b к a, к примеру, для foo это будет выглядеть так:


    St a, b; st(a, b); // st(St& a, St& b) { a = b = {}; } в другом файле.
    a = foo(a, b);
    a = foo(a, b);
    a = foo(a, b);
    a = foo(a, b);

    Code Cycles per iteration
    St a, b; st(a, b); 7.6
    4 x foo no reuse 121.9
    4 x foo 117.7
    4 x fooR no reuse 66.3
    4 x fooR 64.6
    4 x fooR1 84.5
    4 x fooR2 20.6
    4 x foo inline 51.9
    4 x fooR inline 30.5
    4 x fooR1 inline 8.8
    4 x fooR2 inline 8.8

    'no reuse' указывает на то, что для хранения каждого результата используется новая переменная. auto a2 = foo(a, b); auto a3 = foo(a2, b);. 'inline' означает, что функции помечены как INLINE, а не NOINLINE.


    Если посмотреть на листинг fooR1 inline / fooR2 inline, то в нём будет всего пара инструкций, но в случае, когда структура передаётся, или возвращается через регистры, foo inline / fooR inline, компилятор сходит с ума и выдаёт сотни строк кода. Видимо, встраивание происходит после распределения всех полей по регистрам, после чего компилятор запутывается в происходящем и уже не может нормально упростить результат.


    Прозрачные указатели


    Посмотрим, что будет, если добавить немного деструктора.


    struct Point3f {
      float x, y, z;
      ~Point3f() {}
    };
    Point3f scale(Point3f p) { return {p.x * 2, p.y * 2, p.z * 2}; }

    Первым параметром в rdi передаётся адрес, по которому нужно записывать результат. Вторым, в rsi, передаётся указатель на первый аргумент функции.


    scale(Point3f): # @scale(Point3f)     
      vmovss xmm0, dword ptr [rsi] # xmm0 = mem[0],zero,zero,zero
      vaddss xmm0, xmm0, xmm0
      vmovss dword ptr [rdi], xmm0
      vmovss xmm0, dword ptr [rsi + 4] # xmm0 = mem[0],zero,zero,zero
      vaddss xmm0, xmm0, xmm0
      vmovss dword ptr [rdi + 4], xmm0
      vmovss xmm0, dword ptr [rsi + 8] # xmm0 = mem[0],zero,zero,zero
      vaddss xmm0, xmm0, xmm0
      vmovss dword ptr [rdi + 8], xmm0
      mov rax, rdi
      ret

    Как видно, загрузка, умножение (через сложение) и сохранение производится по одному полю за раз. Компилятор не очень хочет оптимизировать не POD типы. Версия функции с константной ссылкой Point3f scaleR(const Point3f&) даст идентичный код. Посмотрим на место вызова.


    Point3f p{1, 2, 3};
    auto result = scale(p);
    sink(&result);

    main: # @main
      push rbx
      sub rsp, 48
      movabs rax, 4611686019492741120 # Копируем константы на стек.
      mov qword ptr [rsp + 16], rax 
      mov dword ptr [rsp + 24], 1077936128
      lea rbx, [rsp + 32]
      lea rsi, [rsp + 16] # Аргумент будет в [rsp+16, rsp+28)
      mov rdi, rbx # Результат будет в [rsp+32, rsp+44)
      call scale(Point3f)  
      mov qword ptr [rsp + 8], rbx # В [rsp+8, rsp+16) будет указатель на результат.
      lea rdi, [rsp + 8]
      call void sink<Point3f*>(Point3f* const&)
      xor eax, eax
      add rsp, 48
      pop rbx
      ret
      # Обработка исключений.
      mov rdi, rax
      call _Unwind_Resume

    Если сделать деструктор NOINLINE, то всё будет гораздо запутаннее.


    main: # @main
      push r14
      push rbx
      sub rsp, 56
      movabs rax, 4611686019492741120 # Константы будут в [rsp, rsp+12). Это переменная p.
      mov qword ptr [rsp], rax
      mov dword ptr [rsp + 8], 1077936128
      # Копируем константы в [rsp+24, rsp+36), это временная переменная pTmp.
      mov eax, dword ptr [rsp + 8]
      mov dword ptr [rsp + 32], eax
      mov rax, qword ptr [rsp]
      mov qword ptr [rsp + 24], rax
      lea r14, [rsp + 40]
      lea rbx, [rsp + 24]
      mov rdi, r14 # Результат сохраняем в [rsp+40, rsp+52), это result.
      mov rsi, rbx # Первый аргумент - указатель на pTmp.
      call scale(Point3f)
      mov rdi, rbx # Вызываем деструктор у pTmp. Первый аргумент деструктора - указатель this.
      call Point3f::~Point3f()
      mov qword ptr [rsp + 16], r14 # В [rsp+16, rsp+24) будет храниться указатель на result. Он же первый аргумент sink.
      lea rdi, [rsp + 16]
      call void sink<Point3f*>(Point3f* const&)
      lea rdi, [rsp + 40] # Вызывает деструктор у result.
      call Point3f::~Point3f()
      mov rdi, rsp # Вызывает деструктор у p.
      call Point3f::~Point3f()
      xor eax, eax
      add rsp, 56
      pop rbx
      pop r14
      ret
      # Обработка исключений. Сюда может быть произведён переход в случае возникновения и перехвата исключения.
      mov rbx, rax
      lea rdi, [rsp + 40] # Вызывает деструктор у result.
      call Point3f::~Point3f()
      mov rdi, rsp # Вызывает деструктор у p.
      call Point3f::~Point3f()
      mov rdi, rbx
      call _Unwind_Resume

    Если параметр p явно передавать по ссылке, то кода станет несколько меньше и будет произведено только два вызова деструктора.


    Переиспользование стека


    Посмотрим, как компилятор переиспользует регистры и стек между вызовами. Будут использоваться функции из параграфа про ссылки.


    # Point3f result = scale(scale(Point3f{1, 2, 3}));
      sub rsp, 24
      vmovaps xmm0, xmmword ptr [rip + .LCPI4_0] # xmm0 = <1,2,u,u>
      vmovss xmm1, dword ptr [rip + .LCPI4_1] # xmm1 = mem[0],zero,zero,zero
      # Так как регистры xmm0, xmm1 используются как для передачи, так и для возврата, то просто вызываем несколько раз нужную функцию!
      call scale(Point3f)
      call scale(Point3f)
      vmovlps qword ptr [rsp + 8], xmm0
      vmovss dword ptr [rsp + 16], xmm1
    
    # Point3f result = scaleR(scaleR(Point3f{1, 2, 3}));
      sub rsp, 56
      # Копируем константы на стек в диапазоне [rsp+24, rsp+36).
      movabs rax, 4611686019492741120 # 0x400000003F800000 = [2.0f, 1.0f]
      mov qword ptr [rsp + 24], rax
      mov dword ptr [rsp + 32], 1077936128 # 0x40400000 = 3.0f
      lea rdi, [rsp + 24] # Аргумент с указателем на входные данные.
      call scaleR(Point3f const&)
      # Сохраняем результат в [rsp+8, rsp+20).
      vmovlps qword ptr [rsp + 8], xmm0
      vmovss dword ptr [rsp + 16], xmm1
      lea rdi, [rsp + 8] # Аргумент с указателем на результат первого вызова.
      call scaleR(Point3f const&)
      vmovlps qword ptr [rsp + 40], xmm0
      vmovss dword ptr [rsp + 48], xmm1

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


    # Point3d result = scale(scale(Point3d{1, 2, 3}));
      sub rsp, 112
      # Загружаем константы в [rsp, rsp+24).
      vmovaps xmm0, xmmword ptr [rip + .LCPI4_0] # xmm0 = [1.000000e+00,2.000000e+00]
      vmovaps xmmword ptr [rsp + 32], xmm0
      movabs rax, 4613937818241073152 # 0x4008000000000000 = 3.0
      mov qword ptr [rsp + 48], rax
      mov rax, qword ptr [rsp + 48]
      mov qword ptr [rsp + 16], rax
      vmovaps xmm0, xmmword ptr [rsp + 32]
      vmovups xmmword ptr [rsp], xmm0
      # Результат будет в [rsp+64, rsp+88).
      lea rdi, [rsp + 64] # В rdi передаём адрес стека для результата.
      call scale(Point3d)
      # Аргумент второй функции будет также по адресу [rsp, rsp+24).
      mov rax, qword ptr [rsp + 80] # Копируем z результата в z аргумента.
      mov qword ptr [rsp + 16], rax
      vmovups xmm0, xmmword ptr [rsp + 64] # Копируем [x, y] результата в [x, y] аргумента.
      vmovups xmmword ptr [rsp], xmm0
      # Результат будет в [rsp+88, rsp+112).
      lea rbx, [rsp + 88]
      mov rdi, rbx
      call scale(Point3d)
    
    # Point3d result = scaleR(scaleR(Point3d{1, 2, 3}));
      sub rsp, 72
      # Загружаем константы в [rsp, rsp+24), аналогично предыдущему коду.
      vmovaps xmm0, xmmword ptr [rip + .LCPI4_0]
      vmovaps xmmword ptr [rsp], xmm0
      movabs rax, 4613937818241073152
      mov qword ptr [rsp + 16], rax
      lea r14, [rsp + 24]
      mov rsi, rsp # Второй аргумент - указатель на стек с входными данными [rsp, rsp+24).
      mov rdi, r14 # Первый аргумент - указатель на стек для результата [rsp+24, rsp+48).
      call scaleR(Point3d const&)
      lea rbx, [rsp + 48]
      mov rdi, rbx # Указатель на стек для результата [rsp+48, rsp+72).
      mov rsi, r14 # Указатель на стек с входными данными [rsp+24, rsp+48).
      call scaleR(Point3d const&)

    Видно, что при передаче аргументов, помещающихся в регистры, код значительно короче, если передавать по значению. Если же они не помещаются – то лучше передавать по ссылке. В этом случае компилятор может удалить лишние копирования и передавать сразу указатель на стек с результатом предыдущего вызова. Причём он не может сделать так же, если параметр передаётся по значению через стек, и ему приходится выполнять лишние копирования.


    Сравнение производительности


    Посмотрим, какое влияние всё это оказывает на быстродействие. Функции для получения точек были объявлены в отдельном файле, чтобы предотвратить оптимизации для константных данных. Напомню, что при возврате из функции и передаче по значению, Point3f будет передаваться через регистры, а Point3d – через стек.


    // В файле data.cpp. Предотвращаем встраивание.
    Point3f pf() { return {1, 2, 3}; }
    Point3d pd() { return {1, 2, 3}; }

    Code Cycles per iteration
    auto r = pf(); 6.7
    auto r = scale(pf()); 11.1
    auto r = scaleR(pf()); 12.6
    auto r = scale(scale(pf())); 18.2
    auto r = scaleR(scaleR(pf())); 18.3
    auto r = scale(scale(scale(pf()))); 16.8
    auto r = scaleR(scaleR(scaleR(pf()))); 20.2
    auto r = pd(); 7.3
    auto r = scale(pd()); 11.7
    auto r = scaleR(pd()); 11.0
    auto r = scale(scale(pd())); 16.9
    auto r = scaleR(scaleR(pd())); 14.1
    auto r = scale(scale(scale(pd()))); 21.2
    auto r = scaleR(scaleR(scaleR(pd()))); 17.2
    Если функции пометить INLINE 8.1 — 8.9

    Если заменить Point3f на struct Point3i { int32_t x, y, z; }; и Point3d на struct Point3ll { int64_t x, y, z; };, то различия в производительности будет менее выраженными. Видимо, значительное время уходит на распаковку параметров из регистров, вспомним, что в один 64 битный регистры обычно запаковывается сразу два int, а векторные операции они не поддерживают. С другой стороны, если заменить Point3f на struct Point2ll { int64_t x, y; }; и Point3d на struct Point4ll { int64_t x, y, z, a; };, то цифры будут примерно такие-же.


    Что можно заметить:


    • Небольшие параметры лучше передавать по значению. Передача по ссылке только вредит.
    • Параметры, не влезающие в регистры, лучше передавать по ссылке.
    • Если есть возможность сделать функцию inline и поместить её в заголовочный файл, то это стоит сделать. При этом способ передачи параметров, по ссылке, или значению, не играет особой роли. По крайней мере для небольших простых типов.

    Тип optional


    Стандартный тип std::optional, а также boost::optional, в данный момент имеет кривую реализацию, которая исправлена только в "x86-64 clang (experimental concepts)" и, вроде бы, MSVC последних версий, поэтому


    struct Point {
      float x, y;
    };
    using OptPoint1 = optional<Point>;

    будет совсем не эквивалентно


    struct OptPoint2 {
      float x, y;
      union { char _; bool d; }; // Как в std::optional.
    };

    Несмотря на одинаковые размер и выравнивание, OptPoint1 будет передаваться через стек, а OptPoint2 – через регистры.


    OptPoint1 foo(OptPoint1 s) { return Point{s->x + 1, s->y + 1}; }
    OptPoint2 foo(OptPoint2 s) { return {s.x + 1, s.y + 1, true}; }
    ...
    OptPoint1 s1{Point{1, 2}};
    OptPoint2 s2{3, 4, true};
    auto result1 = foo(s1);
    auto result2 = foo(s2);

    .LCPI0_0:
      .long 1065353216 # float 1
    foo(std::optional<Point>): # @foo(std::optional<Point>)
      vmovss xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
      # В rsi хранится адрес начала участка стека с аргументом.
      vaddss xmm1, xmm0, dword ptr [rsi] # Загружаем x со стека, прибавляя 1.
      vaddss xmm0, xmm0, dword ptr [rsi + 4] # Загружаем y со стека, прибавляя 1.
      vmovss dword ptr [rdi], xmm1 # Загружаем x на стек, rdi хранит адрес начала участка на стеке, в который нужно записывать результат.
      vmovss dword ptr [rdi + 4], xmm0 # Загружаем y на стек.
      mov byte ptr [rdi + 8], 1 # Флаг optional::has_value().
      mov rax, rdi # Возвращаем адрес с результатом.
      ret
    .LCPI1_0:
      .long 1065353216 # float 1
      .long 1065353216 # float 1
      .zero 4
      .zero 4
    foo(OptPoint2): # @foo(OptPoint2)
      vaddps xmm0, xmm0, xmmword ptr [rip + .LCPI1_0] # Складываем [x, y] c [1, 1]. В xmm0 хранится результат.
      mov al, 1  # Возвращаем d, al - это младшие 8 бит регистра rax.
      ret
    .LCPI2_0:
      .long 1077936128 # float 3
      .long 1082130432 # float 4
      .zero 4
      .zero 4
    main: # @main
      push rbx
      sub rsp, 64
      movabs rax, 4611686019492741120 # 0x400000003F800000 Поля x и y.
      mov qword ptr [rsp + 32], rax # Копируем x, y на стек.
      mov byte ptr [rsp + 40], 1 # Флаг optional::has_value().
      lea rbx, [rsp + 48]
      lea rsi, [rsp + 32] # Участок стека с аргументом.
      mov rdi, rbx # Участок стека с результатом.
      call foo(std::optional<Point>)
      # Второй вызов осуществляется гораздо проще.
      vmovaps xmm0, xmmword ptr [rip + .LCPI2_0] # xmm0 = <3,4,u,u>
      mov edi, 1 # Флаг bool d.
      call foo(OptPoint2)
      vmovlps qword ptr [rsp + 16], xmm0 # Копируем результат на стек.
      mov byte ptr [rsp + 24], al # В al хранится самый младший байт регистра rax.

    Впрочем, если пометить функции foo как inline, то генерируемый в месте использования код будет примерно одинаков.


      # OptPoint1 foo(OptPoint1) или OptPoint1 foo(const OptPoint1&)
      vmovss xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
      vaddss xmm1, xmm0, dword ptr [rsp + 32]
      vaddss xmm0, xmm0, dword ptr [rsp + 36]
      vmovss dword ptr [rsp + 8], xmm1
      vmovss dword ptr [rsp + 12], xmm0
      mov byte ptr [rsp + 16], 1
    
      # OptPoint2 foo(OptPoint2) или OptPoint2 foo(const OptPoint2&)
      vmovsd xmm0, qword ptr [rsp + 48] # xmm0 = mem[0],zero
      vaddps xmm0, xmm0, xmmword ptr [rip + .LCPI0_1]
      vmovlps qword ptr [rsp + 8], xmm0
      mov byte ptr [rsp + 16], 1

    Видно, что в случае с простой структурой, компилятор смог соптимизировать код чуть лучше, но в остальном всё одинаково.


    Вывод: если функция не inline, то лучше всегда передавать std::optional по ссылке.


    Виртуальные функции


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


    struct Fn {
      virtual ~Fn() noexcept = default;
      virtual int call(int x) const = 0;
    };
    
    struct Add final : Fn {
      Add(int a) : a(a) {}
      int call(int x) const override { return a + x; }
      int a;
    };
    
    NOINLINE bool isFixedPoint(const Fn& fn, int x) { return fn.call(x) == x; }
    
    int main() {
      Add add{32};
      bool result = isFixedPoint(add, 10);
    }

    В результат получим что-то вроде такого.


    Add::call(int) const: # @Add::call(int) const
      # В rdi передаётся указатель this первым аргументом, по адресу [rdi, rdi+8) будет указатель на таблицу виртуальных функций, за ней уже идут поля с данными.
      add esi, dword ptr [rdi + 8]
      mov eax, esi # Возвращаем результат через rax, eax указывает на его младшие 32 бита.
      ret
    
    # Таблица виртуальных функций для класса Add. Загрузка должна всегда быть со смещением 16, чтобы информация RTTI находилась по отрицательному смещению.
    vtable for Add:
      .quad 0
      .quad typeinfo for Add # Информация для RTTI. Смещение -8.
      .quad Fn::~Fn() # Деструкторы, смещение 0 байт от начала таблицы.
      .quad Add::~Add()
      .quad Add::call(int) const # Методы, смещение 16 байт.
    
    isFixedPoint(Fn const&, int): # @isFixedPoint(Fn const&, int)
      push rbx # Так как вызываемая функция не должна менять значение rbx, сохраняем его на стеке, чтоб восстановить перед возвратом.
      mov ebx, esi # Младшие 32 бита второго аргумента.
      mov rax, qword ptr [rdi] # В rdi хранится первый аргумент - указатель на Fn, далее этот же регистр используется для передачи параметра this метода.
      call qword ptr [rax + 16] # Вызываем Add::call.
      cmp eax, ebx # Возвращённое методом call значение лежит в rax, сравниваем его с ebx, в котором лежит значение второго аргумента.
      sete al # Записываем результат в младшие 8 бит регистра eax.
      pop rbx # Восстанавливаем значение rbx.
      ret  
    
    main: # @main
      sub rsp, 40
      mov qword ptr [rsp + 24], vtable for Add+16 # Загружаем на стек адрес таблицы виртуальных функций для класса Add, прибавляем к нему 16 для того, чтобы он указывал на, собственно, виртуальные функции. Для доступа к RTTI необходимо использовать отрицательное смещение.
      mov dword ptr [rsp + 32], 32 # Значение add.a сразу за таблицей.
      lea rdi, [rsp + 24] # Первый параметр указывает прямо на таблицу.
      mov esi, 10 # Второй константный параметр.
      call isFixedPoint(Fn const&, int)
      mov byte ptr [rsp + 15], al # Копируем на стек результат.
      ... 
      mov rdi, rax # Обработчик исключений.
      call _Unwind_Resume
      mov rdi, rax
      call _Unwind_Resume

    Если сделать деструктор protected и не виртуальным, то весь код связанный с обработкой исключений исчезнет (строки 34-37). Если же оставить деструктор виртуальным и убрать NOINLINE, то компилятор встроит все вызовы функций и методов и запишет на стек готовый результат (false в данном случае). Если пометить деструктор NOINLINE, то добавится просто куча кода с его вызовами. Для интереса переделаем пример с использованием шаблонов.


    struct Add final {
      Add(int a) : a(a) {}
      NOINLINE int call(int x) const { return a + x; }
      int a;
    };
    
    template<typename T>
    NOINLINE bool isFixedPoint(const T& fn, int x) { return fn.call(x) == x; }

    Add::call(int) const: # @Add::call(int) const
      add esi, dword ptr [rdi] # Тут ничего не изменилось, this передаётся в rdi первым аргументом, но так как уже нет таблицы виртуальных функций, то и дополнительное смещение не требуется.
      mov eax, esi
      ret
    
    bool isFixedPoint<Add>(Add const&, int): # @bool isFixedPoint<Add>(Add const&, int)
      push rbx
      mov ebx, esi 
      # Add::call использует те же самые аргументы на тех же местах, что и isFixedPoint.
      call Add::call(int) const
      cmp eax, ebx
      sete al
      pop rbx
      ret
    
    main: # @main
      sub rsp, 24
      mov dword ptr [rsp + 8], 32 # Инициализируем add.a.
      lea rdi, [rsp + 8] # Загружаем аргументы в регистры, в rdi хранится адрес поля add.a.
      mov esi, 10
      call bool isFixedPoint<Add>(Add const&, int)
      mov byte ptr [rsp + 7], al
      ...
      ret

    Как видно, код заметно компактнее даже с NOINLINE.


    Сравнение производительности


    В данном случае была будет проводится итерация по вектору с 1000 элементов типа Add и вызова isFixedPoint для каждого из них.


    Code Cycles per iteration
    Виртуальный call и деструктор, без вызова isFixedPoint и call 5267
    Виртуальный call и деструктор, NOINLINE isFixedPoint 10721
    Виртуальный call и деструктор, INLINE isFixedPoint 8291
    Виртуальный только call, NOINLINE isFixedPoint 10571
    Без виртуальных методов, NOINLINE call, шаблонный NOINLINE isFixedPoint 10536
    Без виртуальных методов, без вызова isFixedPoint и call 4505
    Без виртуальных методов, INLINE call, шаблонный INLINE isFixedPoint 4531

    Что можно заметить:


    • Виртуальные функций вызываются очень быстро.
    • Указатель на таблицу виртуальных функций увеличивает размер класса, что может сказаться на производительности.
    • Даже функции, принимающие аргументы по указателю на базовый класс, лучше объявлять, как inline. Компилятор может их встроить и девиртуализировать.
    • Не inline шаблоны не дают особого выигрыша в производительности. Под не inline я имею ввиду что-то с определением в cpp файле и последующим явным инстанцированием, или явно помеченные как NOINLINE.
    • inline шаблоны дают нулевой оверхед при встраивании.

    Хвостовые вызовы


    Немного рассмотрим особенности вызова функции не через call, а через jmp без изменения размера стека.


    Немного оффтоп. Компилятор clang умеет оптимизировать хвостовую рекурсию. К примеру, возьмём функцию быстрого возведения в степень:


    double exp_by_squaring(double x, int n, double y = 1) {
      if (n < 0) return exp_by_squaring(1.0 / x, -n, y);
      if (n == 0) return y;
      if (n == 1) return x * y;
      if (n % 2 == 0) return exp_by_squaring(x * x, n / 2, y);
      return exp_by_squaring(x * x, (n - 1) / 2, x * y);
    }

    Получим:


    .LCPI0_0:
      .quad 4607182418800017408 # double 1
    exp_by_squaring(double, int, double): # @exp_by_squaring(double, int, double)
      vmovsd xmm2, qword ptr [rip + .LCPI0_0] # xmm2 = mem[0],zero
      vmovapd xmm3, xmm0
      test edi, edi
      jns .LBB0_4
      jmp .LBB0_3
    .LBB0_9: # in Loop: Header=BB0_4 Depth=1
      shr edi
      vmovapd xmm3, xmm0
      test edi, edi
      jns .LBB0_4
    .LBB0_3: # =>This Inner Loop Header: Depth=1
      vdivsd xmm3, xmm2, xmm3
      neg edi
      test edi, edi
      js .LBB0_3
    .LBB0_4: # =>This Inner Loop Header: Depth=1
      je .LBB0_7
      cmp edi, 1
      je .LBB0_6
      vmulsd xmm0, xmm3, xmm3
      test dil, 1
      je .LBB0_9
      lea eax, [rdi - 1]
      shr eax, 31
      lea edi, [rdi + rax]
      add edi, -1
      sar edi
      vmulsd xmm1, xmm3, xmm1
      vmovapd xmm3, xmm0
      test edi, edi
      jns .LBB0_4
      jmp .LBB0_3
    .LBB0_6:
      vmulsd xmm1, xmm3, xmm1
    .LBB0_7:
      vmovapd xmm0, xmm1
      ret

    Как видно, нет ни одного рекурсивного вызова, лишь циклы. Код этой же функции, реализованной через цикл, будет примерно аналогичен. Причём рекурсивный даже будет на ~10% быстрее.


    Но я хотел рассмотреть особенности не рекурсивных вызовов функций непосредственно перед возвратом. Сравним три версии одной и той же функции по прибавлению единицы к аргументу.


    int64_t sum(int64_t x, int64_t y) { return x + y; }
    int64_t add1(int64_t x) { return sum(x, 1); }
    int64_t add2(int64_t x) { return sum(1, x); }
    int64_t add3(int64_t x) { return sum(-1, x) + 2; }

    sum(long, long): # @sum(long, long)
      lea rax, [rdi + rsi]
      ret
    add1(long): # @add1(long)
      mov esi, 1 # Добавляем второй аргумент.
      jmp sum(long, long) # TAILCALL
    add2(long): # @add2(long)
      mov rax, rdi # Переупорядочиваем значения регистров.
      mov edi, 1
      mov rsi, rax
      jmp sum(long, long) # TAILCALL
    add3(long): # @add3(long)
      push rax # Сохраняем rax между вызовами функции.
      mov rax, rdi # Так же, как и в add2, переупорядочиваем регистры.
      mov rdi, -1
      mov rsi, rax
      call sum(long, long)
      add rax, 2 # Прибавляем 2 к регистру с результатом.
      pop rcx
      ret

    Как видно, если функция вызывается перед выходом и её результат никак не изменяется, то компилятор использует не call, а более быстрый jmp. Отличие в том, что адрес возврата не меняется, и после завершения функции sum, управление передаётся сразу в функцию, взывавшую add.


    Если пример немного усложнить и замерить производительность, то разница между скоростью выполнения функций будет в районе 10%.


    Выводы:


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

    Инициализация


    В данном разделе я хочу рассмотреть особенности инициализации структур и массивов. Рассмотрим классы для 2D точки с различными состояниями по умолчанию:


    struct Point {
        double x, y;
    };
    
    struct ZeroPoint {
        double x{}, y{};
    };
    
    struct NanPoint {
        double x{quietNaN}, y{quietNaN};
    };

    Структура Point не инициализируется. ZeroPoint заполняется нулями. По стандарту IEEE 754-1985:


    The number zero is represented specially: sign = 0 for positive zero, 1 for negative zero; biased exponent = 0; fraction = 0;

    Так что их можно смело обнулять с помощью memset. NanPoint заполняется значениями numeric_limits<double>::quiet_NaN(); Да, я сам видел реализацию с такими значения по умолчанию для точки.


    Один элемент


    Point data;

      sub rsp, 24

    Просто выделяем место на стеке без какой-либо инициализации.


    ZeroPoint data;
    Point data{};

    Обе строки дают идентичный результат.


      sub rsp, 40
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp + 16], xmm0

    Выделяем место на стеке. Обнуляем регистр xmm0. Это делается через XOR так как vxorps работает быстрее записи нуля. Копируем значение из регистра в память стека.


    NanPoint data;

      sub rsp, 40
      vmovaps xmm0, xmmword ptr [rip + .LCPI0_0] # xmm0 = [nan,nan]
      vmovaps xmmword ptr [rsp + 16], xmm0

    То же самое, но в регистр загружаем значение из раздела с константными данными.


    Небольшой массив


    Здесь и далее будут использоваться следующие константы:


    static constexpr size_t smallSize = 8;
    static constexpr size_t bigSize = 321;
    extern size_t smallUnknownSize; // Also 8
    extern size_t bigUnknownSize;   // Also 321

    Рассмотрим простой массив на стеке.


    array<Point, smallSize> data;

    Как и раньше – просто перемещение указателя на стек.


      sub rsp, 136

    Как и в случае с одной точкой, но размер стека пропорционально больше.


    array<ZeroPoint, smallSize> data;
    array<ZeroPoint, smallSize> data{};
    array<Point, smallSize> data{};

    Заметим явный вызов конструктора по умолчанию в третьей строке.


      sub rsp, 192
      vxorps ymm0, ymm0, ymm0
      vmovaps ymmword ptr [rsp + 128], ymm0
      vmovaps ymmword ptr [rsp + 96], ymm0
      vmovaps ymmword ptr [rsp + 64], ymm0
      vmovaps ymmword ptr [rsp + 32], ymm0

    Память очищается кусками по 256 бит, или 2 точки.


    array<NanPoint, smallSize> data;
    array<NanPoint, smallSize> data{};

      sub rsp, 136
      vmovaps xmm0, xmmword ptr [rip + .LCPI0_0] # xmm0 = [nan,nan]
      vmovups xmmword ptr [rsp + 24], xmm0
      vmovups xmmword ptr [rsp + 8], xmm0
      vmovups xmmword ptr [rsp + 56], xmm0
      vmovups xmmword ptr [rsp + 40], xmm0
      vmovups xmmword ptr [rsp + 88], xmm0
      vmovups xmmword ptr [rsp + 72], xmm0
      vmovups xmmword ptr [rsp + 120], xmm0
      vmovups xmmword ptr [rsp + 104], xmm0

    Тут каждая точка инициализируется по отдельности.


    Большой массив


    array<Point, bigSize> data;

      sub rsp, 5144

    Это было предсказуемо.


    array<ZeroPoint, bigSize> data;
    array<ZeroPoint, bigSize> data{};
    array<Point, bigSize> data{};

      sub rsp, 5152
      lea rbx, [rsp + 16]
      xor esi, esi
      mov edx, 5136
      mov rdi, rbx
      call memset # Вызов memset(rsp+16, 0, 5136).

    После выделения места на стеке, вызывается memset. Указатель на начало, ноль в качестве заполнителся и размер, передаются через регистры rdi, esi, edx соответственно. Префикс e вместо d используется для манипуляции младшими 32 битами 64-битного регистра.


    array<NanPoint, bigSize> data;

      sub rsp, 5144
      lea rax, [rsp + 8]
      lea rcx, [rsp + 5144]
      vmovaps xmm0, xmmword ptr [rip + .LCPI0_0] # xmm0 = [nan,nan]
      # Цикл инициализации.
    .LBB0_1: # =>This Inner Loop Header: Depth=1
      vmovups xmmword ptr [rax], xmm0
      vmovups xmmword ptr [rax + 16], xmm0
      vmovups xmmword ptr [rax + 32], xmm0
      add rax, 48
      cmp rax, rcx
      jne .LBB0_1

    Тут уже используется цикл. В каждой итерации копируются сразу три элемента, так как число 321 делится на 3 без остатка. В регистрах rax, rcx хранятся адреса начала и конца массива.


    array<NanPoint, bigSize> data{};

      sub rsp, 5152
      lea rbx, [rsp + 16]
      xor esi, esi
      mov edx, 5136
      mov rdi, rbx
      call memset # Вызов memset(rsp+16, 0, 5136).
      lea rax, [rsp + 5152]
      vmovaps xmm0, xmmword ptr [rip + .LCPI0_0] # xmm0 = [nan,nan]
      # Цикл инициализации.
    .LBB0_1: # =>This Inner Loop Header: Depth=1
      vmovups xmmword ptr [rbx], xmm0
      vmovups xmmword ptr [rbx + 16], xmm0
      vmovups xmmword ptr [rbx + 32], xmm0
      add rbx, 48
      cmp rbx, rax
      jne .LBB0_1

    А вот тут результат довольно неожиданный. Присутствует как цикл, так и вызов memset. Это логично, так как в общем случае, в структуре могут быть зазоры между элементами. Но в данном случае это откровенно лишняя работа.


    Динамический массив


    vector<Point> data(smallSize);

      sub rsp, 40
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp], xmm0
      mov qword ptr [rsp + 16], 0
      mov edi, 128
      call operator new(unsigned long) # Вызов new(128).
      mov qword ptr [rsp], rax
      mov rcx, rax
      sub rcx, -128
      mov qword ptr [rsp + 16], rcx
      vxorps xmm0, xmm0, xmm0
      # Развёрнутый цикл с заполнением нулями.
      vmovups xmmword ptr [rax + 16], xmm0
      vmovups xmmword ptr [rax], xmm0
      vmovups xmmword ptr [rax + 32], xmm0
      vmovups xmmword ptr [rax + 48], xmm0
      vmovups xmmword ptr [rax + 64], xmm0
      vmovups xmmword ptr [rax + 80], xmm0
      vmovups xmmword ptr [rax + 96], xmm0
      vmovups xmmword ptr [rax + 112], xmm0

    Вызываем new и обнуляем все элементы. По умолчанию, контейнеры инициализируют все элементы значением T{}, это поведение можно переопределить, предоставив собственный аллокатор. Листинги для ZeroPoint и NanPoint практически аналогичны. Увлеичим количество элементов:


    vector<Point> data(bigSize);

    main: # @main
      push rbx
      sub rsp, 48
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp], xmm0
      mov qword ptr [rsp + 16], 0
      mov edi, 5136
      call operator new(unsigned long) # Вызов new(5136).
      mov qword ptr [rsp], rax
      mov qword ptr [rsp + 8], rax
      mov rcx, rax
      add rcx, 5136
      mov qword ptr [rsp + 16], rcx
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp + 32], xmm0
      xor edx, edx
      # Цикл с заполнением нулями.
    .LBB0_2: # =>This Inner Loop Header: Depth=1
      vmovaps xmm0, xmmword ptr [rsp + 32]
      vmovups xmmword ptr [rax + rdx], xmm0
      vmovaps xmm0, xmmword ptr [rsp + 32]
      vmovups xmmword ptr [rax + rdx + 16], xmm0
      vmovaps xmm0, xmmword ptr [rsp + 32]
      vmovups xmmword ptr [rax + rdx + 32], xmm0
      add rdx, 48
      cmp rdx, 5136
      jne .LBB0_2
      mov qword ptr [rsp + 8], rcx
      mov rax, rsp

    Как и в случае с массивом, инициализация происходит пачками через цикл. В случае с NanPoint листинг примерно аналогичен.


    vector<NanPoint> data(bigSize);

    main: # @main
      push rbx
      sub rsp, 32
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp], xmm0
      mov qword ptr [rsp + 16], 0
      mov edi, 5136
      call operator new(unsigned long) # Вызов new(5136).
      mov qword ptr [rsp], rax
      mov qword ptr [rsp + 8], rax
      mov rcx, rax
      add rcx, 5136
      mov qword ptr [rsp + 16], rcx
      xor edx, edx
      vmovaps xmm0, xmmword ptr [rip + .LCPI0_0] # xmm0 = [nan,nan]
      # Цикл с заполнением NAN.
    .LBB0_2: # =>This Inner Loop Header: Depth=1
      vmovups xmmword ptr [rax + rdx], xmm0
      vmovups xmmword ptr [rax + rdx + 16], xmm0
      vmovups xmmword ptr [rax + rdx + 32], xmm0
      add rdx, 48
      cmp rdx, 5136
      jne .LBB0_2
      mov qword ptr [rsp + 8], rcx
      mov rax, rsp

    A вот при использовании ZeroPoint код заметно отличается.


    vector<ZeroPoint> data(bigSize);

      sub rsp, 32
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp], xmm0
      mov qword ptr [rsp + 16], 0
      mov edi, 5136
      call operator new(unsigned long) # Вызов new(5136).
      mov qword ptr [rsp], rax
      mov rbx, rax
      add rbx, 5136
      mov qword ptr [rsp + 16], rbx
      xor esi, esi
      mov edx, 5136
      mov rdi, rax
      call memset # Вызов memset(&data, 0, 5136).

    Только в этом случае вызывается memset. Вспомним, что в случае с массивом, memset вызывался и при использовании Point. Посмотрим, что будет, если значение bigUnknownSize не известно на момент компиляции.


    vector<NanPoint> data(bigUnknownSize);

      sub rsp, 32
      mov rbx, qword ptr [rip + bigUnknownSize]
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp], xmm0
      mov qword ptr [rsp + 16], 0
      test rbx, rbx # Если bigUnknownSize == 0, то пропускаем new.
      je .LBB0_1
      mov rax, rbx
      shr rax, 60
      jne .LBB0_3
      mov rdi, rbx
      shl rdi, 4 # Умножение на 16 чере сдвиг на 4.
      call operator new(unsigned long) # Вызов new(bigUnknownSize*16).
      jmp .LBB0_6
    .LBB0_1:
      xor eax, eax
    .LBB0_6:
      mov rcx, rbx
      shl rcx, 4
      add rcx, rax
      mov qword ptr [rsp], rax
      mov qword ptr [rsp + 8], rax
      mov qword ptr [rsp + 16], rcx
      test rbx, rbx # Если bigUnknownSize == 0, то пропускаем инициализацию.
      je .LBB0_14
      lea rdx, [rbx - 1]
      mov rsi, rbx
      and rsi, 7
      je .LBB0_10
      neg rsi
      vmovaps xmm0, xmmword ptr [rip + .LCPI0_0] # xmm0 = [nan,nan]
      # Инициализируем первые 0-7 элементов.
    .LBB0_9: # =>This Inner Loop Header: Depth=1
      vmovups xmmword ptr [rax], xmm0
      dec rbx
      add rax, 16
      inc rsi
      jne .LBB0_9
    .LBB0_10:
      cmp rdx, 7
      jb .LBB0_13
      vmovaps xmm0, xmmword ptr [rip + .LCPI0_0] # xmm0 = [nan,nan]
      # Инициализируем оставшиеся элементы пачками по 8.
    .LBB0_12: # =>This Inner Loop Header: Depth=1
      vmovups xmmword ptr [rax], xmm0
      vmovups xmmword ptr [rax + 16], xmm0
      vmovups xmmword ptr [rax + 32], xmm0
      vmovups xmmword ptr [rax + 48], xmm0
      vmovups xmmword ptr [rax + 64], xmm0
      vmovups xmmword ptr [rax + 80], xmm0
      vmovups xmmword ptr [rax + 96], xmm0
      vmovups xmmword ptr [rax + 112], xmm0
      sub rax, -128
      add rbx, -8
      jne .LBB0_12
    .LBB0_13:
      mov rax, rcx
    .LBB0_14:
      mov qword ptr [rsp + 8], rax
      mov rax, rsp

    Можно увидеть два цикла. Первый, LBB0_9 заполняет по одной точке до тех пор, пока количество оставшихся элементов не станет кратно 8. После чего идёт заполнение сразу 8 точек за итерацию.


    Как и в прошлый раз, листинг с Point примерно такой же, а при ZeroPoint опять используется memset:


    vector<ZeroPoint> data(bigUnknownSize);

      sub rsp, 40
      mov rbx, qword ptr [rip + bigUnknownSize]
      vxorps xmm0, xmm0, xmm0
      vmovaps xmmword ptr [rsp], xmm0
      mov qword ptr [rsp + 16], 0
      test rbx, rbx # Если bigUnknownSize == 0, то пропускаем new.
      je .LBB0_1
      mov rax, rbx
      shr rax, 60
      jne .LBB0_3
      mov rdi, rbx
      shl rdi, 4
      call operator new(unsigned long) # Вызов new(bigUnknownSize*16).
      jmp .LBB0_6
    .LBB0_1:
      xor eax, eax
    .LBB0_6:
      mov rdx, rbx
      shl rdx, 4
      lea r14, [rax + rdx]
      mov qword ptr [rsp], rax
      mov qword ptr [rsp + 8], rax
      mov qword ptr [rsp + 16], r14
      test rbx, rbx  # Если bigUnknownSize == 0, то пропускаем memset.
      je .LBB0_8
      xor esi, esi
      mov rdi, rax
      call memset # Вызов memset(&data, 0, bigUnknownSize*16).
      mov rax, r14
    .LBB0_8:
      mov qword ptr [rsp + 8], rax
      mov rax, rsp

    Кстати, компиляция


    vector<NanPoint> data;
    data.resize(bigUnknownSize);

    произведёт больше 250 строк ассемблера, что заметно больше случая с передачей размера непосредственно в конструктор. Но operator new вызывается только один раз, так как при создании пустого вектора он не используется.


    Сравнение производительности


    Теперь сравним скорость выполенения всех вышерассмотренных примеров.


    Code Cycles per iteration
    Point p; 4.5
    ZeroPoint p; 5.2
    NanPoint p; 4.5
    array<Point, smallSize> p; 4.5
    array<ZeroPoint, smallSize> p; 6.7
    array<NanPoint, smallSize> p; 6.7
    array<Point, bigSize> p; 4.5
    array<ZeroPoint, bigSize> p; 296.0
    array<NanPoint, bigSize> p; 391.0
    array<Point, bigSize> p{}; 292.0
    array<NanPoint, bigSize> p{}; 657.0
    vector<Point> p(smallSize); 32.3
    vector<ZeroPoint> p(smallSize); 33.8
    vector<NanPoint> p(smallSize); 33.8
    vector<Point> p(bigSize); 323.0
    vector<ZeroPoint> p(bigSize); 308.0
    vector<NanPoint> p(bigSize); 281.0
    vector<ZeroPoint> p(smallUnknownSize); 44.1
    vector<NanPoint> p(smallUnknownSize); 37.6
    vector<Point> p(bigUnknownSize); 311.0
    vector<ZeroPoint> p(bigUnknownSize); 315.0
    vector<NanPoint> p(bigUnknownSize); 290.0
    vector<NanPoint> p; p.resize(bigUnknownSize); 315.0

    Выводы:


    • Создание массива на стеке без инициализации ничего не стоит.
    • Инициализация небольших массивов на стеке очень быстра.
    • Инициализация массивов на стеке через memset работает ощутимо быстрее, чем через явный цикл с инициализацией каждого элемента.
    • Не вызывайте конструктор у массива с элементами со сложной инициализацией.
    • Для небольших векторов выделение памяти более затратно, чем инициализация. Различия становятся малозаметны при размерах уже в несколько десятков элементов.
    • Инициализация элементов вектора происходит даже при отсутствии конструктора. Для изменения подобного поведения можно использовать свой аллокатор.
    • У векторов с большим количеством элементов, значительное количество времени уходит на инициализацию. Причём знание размера на момент компиляции не так важно.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 29

      0
      Но чтобы эти данные как-то изменить, их в начале необходимо загрузить в регистры.
      Вообще говоря это неверно для архитектуры x86. Есть команды (методы адресации) которые делают RMW или W напрямую с памятью. К примеру INC mem или MOV/ADD mem, imm
        0
        Ага, изменил формулировку. Я имел ввиду, что обычно нельзя изменить данные вообще не используя регистры. Тот же ADD не работает для двух memory операндов.
          +1
          Да я, это, собсно, так, побуквоедствовать.
          В доисторической рускоязычной литературе для обозначения регистров часто использовалась аббревиатура СОЗУ (сверхоперативное ЗУ). По сути регистры — это специального вида память, которая адресуется именами регистров (во многих современных архитектурах не мудрствуют и просто называют их r0, r1,… rN). Можно, для накала, рассматривать регистры как кэш управляемый вручную.
          На x86 можно написать аналог любой программы, которая использует регистры без использования оных (а вот на load-store архитектуре — не выйдет). Да, ценой быстродействия. Собстно регистровая адресация это всего-лишь способ устранения ботлнека с памятью и ничего более.
          Это я к тому, что данные загружаются в регистры не «так или иначе», а для устранения проблем быстродействия связанных с доступом к памяти (как и прозрачные кэши любого уровня).
        0
        А как передаются параметры в функцию с переменным числом аргументов?
        Ну или точнее, как она их ожидает получить? Через стек?

        ideone.com/uSmc8Y
          0
          Смотрю в main вызовы обеих функций абсолютно идентичны. Что, в общем-то, не удивительно: они вызываются через один и тот же указатель.
          Однако функция с переменным числом параметров похоже тоже забирает что-то из регистров.
          А что происходит дальше — навскидку пока непонятно.
          godbolt.org/g/HkqX5r
            0
            На 20 странице pdf описываются особенности при переменном числе аргументов. Суть в том, что в регистре `al` передаётся число используемых xmm регистров. Остальное то же самое. Внутри метода абсолютно все регистры, в которых могут быть аргументы, копируются на стек, после чего читаются из него по смещению.

            Кстати, ` reinterpret_cast(accumulateFunction);` является UB:

            The effect of calling a function through a pointer to a function type that is not the same as the type used in the definition of the function is undefined.


            Если посмотреть на ассемблер, то видно, что регистр `al` не очищается при вызове через указатель, то приводит, собственно, к UB.
              +1
              Интересно, а какой смысл передавать параметры через регистры, а потом кидать их в стек и использовать уже оттуда?
                0

                Иначе не получится в цикле считывать неизвестное количество аргументов. Если они все на стеке, то можно просто читать [rsp, rsp+sizeof(arg)).

                  0

                  Та функция, которая с фиксированным набором параметров мне кажется то же самое делает.

                    0

                    Если скомпилировать с оптимизацией (хотя бы -O1), то не делает:


                    accumulate3Function(int, int, int):
                      add edi, esi
                      lea eax, [rdi+rdx]
                      ret

                    GCC, кстати, хитрый. Если в функции не вызывается va_arg(args, double);, то он даже не проверяет регистр al.

                    +1
                    Да, но зачем в такой схеме вообще регистры?
                      0

                      Судя по всему, когда xmm регистров ещё не было, или в других ABI, va_arg функции были совместимы с обычными. То есть, можно было их вызывать через указатель на обычную функцию, или делать объявления с фиксированным количеством аргументов. Потом появился SSE и это стало UB.

              –1

              Вот если бы статья была озаглавлена "особенности вызова функций в clang (или даже llvm)" — я бы понял. А вы тут просто в одну кучу свалили всё — С++, ассемблер (кстати, зачем какие-то левые сайты, есть же директива -S у фронтенда, чтоб сразу получить ассемблер, как в gcc, не? У вас получилась статья на тему llvm abi для архитектуры x86_64. Думаю, к С++ или другому языку она имеет весьма опосредованное отношение (и не удивлюсь, если какой-нибудь скрипт js/lua после jit (если таковой есть через llvm) не будет ничем отличаться).


              В целом выглядит эпично, но мне кажется такие вещи было бы гораздо познавательнее выразить через анализ ОТКРЫТЫХ исходников того же clang, чем через reverse-engineering скомпилированного кода (опять же, в свете того, что даже этот шаг можно было бы сразу вывести в формате asm, минуя ненужный дизассемблинг; ещё бы пиратскую IDA тут заюзали для наглядности...). Что подсказывает, что в этих самых исходниках ещё и камменты есть на тему что и почему...

                0
                Да, возможно надо было более явно указать для какой конфигурации проводился обзор. С другой стороны, для других x86_64 компиляторов выводы будут примерно такие же. ABI и стандарт С++ накладывают ограничения.
                  0
                  В windows ABI отличается.
                    0
                    Меня настолько удивил результат clang для St foo(St s1, St s2) { // Просто суммируем s1 и s2., что я полез и таки посмотрел, что делает gcc. В общем, у gcc как-то там получше всё: вот.

                    Интересно, почему.
                      0
                      Ага, добавил про gcc. Clang, как я заметил, испытывает некоторые трудности с оптимизацией хитрых манипуляций с регистрами.
                    +4
                    А где вы тут видите дизассемблинг? Насколько я знаю, используемый автором godbolt.org как раз ключ -S и использует. Кстати, почему вы называете его «левым сайтом»?
                      0

                      Лично я не знаю, что там использует какой-то сайт (да, честно говоря, и знать это особо незачем, видя результат). И "левый" он как раз по причине, что он тут совершенно лишнее звено. ОСОБЕННО если, как вы говорите, он всего лишь запускает где-то там у себя gcc/clang с ключиком -S.

                        +3
                        Скажите, а у вас на своем компе есть все версии gcc и clang?
                          0

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

                            +4
                            То есть вы вместо официальных репозиториев используете какие-то левые софтины и непонятное хранилище образов? :-)
                              0

                              А gcc/clang это уже левые софтины? Ну здрассть…
                              Сборки под centos/rhel6/7, под long-term debian/ubuntu есть, плюс макось — а остальное неинтересно.

                                +1
                                Нет, «левой софтиной» я в шутку назвал докер. По крайней мере, два года назад он точно попадал в эту категорию.
                                0
                                У меня clang из SVN из официального репозитория gentoo ;)
                      +1
                      Спасибо за интересную статью, но один момент очень режет глаза. Скажите пожалуйста, в чём смысл делать оглавление и названия разделов на английском? Тут, конечно, большинство его понимает, но от этого возникает ощущение неряшливого перевода, брошенного почти в конце.
                        +1
                        Изначально была идея сохранить терминологию. Хотя сейчас, после множества изменений текста, она уже не особенно актуальна.
                        0
                        Спасибо за труд, впечатляет, очень полезно.
                          0
                          Спасибо за статью, полезно посмотреть что и как, у самого руки не так часто доходят:) В дополнение к статье добавлю свеженькое видео от Jason Turner на схожую тему — Negative Cost Structs

                          Only users with full accounts can post comments. Log in, please.