std :: vector регрессия производительности при включении C ++ 11

Question

std :: vector регрессия производительности при включении C ++ 11

214

Я нашел интересную регрессию производительности в небольшом фрагменте С++, когда я включаю С++ 11:

#include <vector>

struct Item
{
  int a;
  int b;
};

int main()
{
  const std::size_t num_items = 10000000;
  std::vector<Item> container;
  container.reserve(num_items);
  for (std::size_t i = 0; i < num_items; ++i) {
    container.push_back(Item());
  }
  return 0;
}

С g++ (GCC) 4.8.2 20131219 (preerelease) и С++ 03 Я получаю:

milian:/tmp$ g++ -O3 main.cpp && perf stat -r 10 ./a.out

Performance counter stats for './a.out' (10 runs):

        35.206824 task-clock                #    0.988 CPUs utilized            ( +-  1.23% )
                4 context-switches          #    0.116 K/sec                    ( +-  4.38% )
                0 cpu-migrations            #    0.006 K/sec                    ( +- 66.67% )
              849 page-faults               #    0.024 M/sec                    ( +-  6.02% )
       95,693,808 cycles                    #    2.718 GHz                      ( +-  1.14% ) [49.72%]
  <not supported> stalled-cycles-frontend 
  <not supported> stalled-cycles-backend  
       95,282,359 instructions              #    1.00  insns per cycle          ( +-  0.65% ) [75.27%]
       30,104,021 branches                  #  855.062 M/sec                    ( +-  0.87% ) [77.46%]
            6,038 branch-misses             #    0.02% of all branches          ( +- 25.73% ) [75.53%]

      0.035648729 seconds time elapsed                                          ( +-  1.22% )

С включенным С++ 11, с другой стороны, производительность значительно ухудшается:

milian:/tmp$ g++ -std=c++11 -O3 main.cpp && perf stat -r 10 ./a.out

Performance counter stats for './a.out' (10 runs):

        86.485313 task-clock                #    0.994 CPUs utilized            ( +-  0.50% )
                9 context-switches          #    0.104 K/sec                    ( +-  1.66% )
                2 cpu-migrations            #    0.017 K/sec                    ( +- 26.76% )
              798 page-faults               #    0.009 M/sec                    ( +-  8.54% )
      237,982,690 cycles                    #    2.752 GHz                      ( +-  0.41% ) [51.32%]
  <not supported> stalled-cycles-frontend 
  <not supported> stalled-cycles-backend  
      135,730,319 instructions              #    0.57  insns per cycle          ( +-  0.32% ) [75.77%]
       30,880,156 branches                  #  357.057 M/sec                    ( +-  0.25% ) [75.76%]
            4,188 branch-misses             #    0.01% of all branches          ( +-  7.59% ) [74.08%]

    0.087016724 seconds time elapsed                                          ( +-  0.50% )

Может кто-нибудь объяснить это? До сих пор мой опыт заключался в том, что STL ускоряется, включив С++ 11, особенно. благодаря семантике перемещения.

РЕДАКТИРОВАТЬ: Как и было предложено, вместо container.emplace_back(); производительность будет соответствовать версии С++ 03. Как версия С++ 03 может быть одинаковой для push_back?

milian:/tmp$ g++ -std=c++11 -O3 main.cpp && perf stat -r 10 ./a.out

Performance counter stats for './a.out' (10 runs):

        36.229348 task-clock                #    0.988 CPUs utilized            ( +-  0.81% )
                4 context-switches          #    0.116 K/sec                    ( +-  3.17% )
                1 cpu-migrations            #    0.017 K/sec                    ( +- 36.85% )
              798 page-faults               #    0.022 M/sec                    ( +-  8.54% )
       94,488,818 cycles                    #    2.608 GHz                      ( +-  1.11% ) [50.44%]
  <not supported> stalled-cycles-frontend 
  <not supported> stalled-cycles-backend  
       94,851,411 instructions              #    1.00  insns per cycle          ( +-  0.98% ) [75.22%]
       30,468,562 branches                  #  840.991 M/sec                    ( +-  1.07% ) [76.71%]
            2,723 branch-misses             #    0.01% of all branches          ( +-  9.84% ) [74.81%]

   0.036678068 seconds time elapsed                                          ( +-  0.80% )

milianw 07 янв. 2014, в 15:30

Источник

1

Если вы скомпилируете сборку, вы можете увидеть, что происходит под капотом. Смотрите также stackoverflow.com/questions/8021874/…
Cogwheel 07 янв. 2014, в 17:15
8

Что произойдет, если вы измените push_back(Item()) на emplace_back() в версии C ++ 11?
Cogwheel 07 янв. 2014, в 17:17
8

Смотри выше, что «исправляет» регрессию. Я до сих пор удивляюсь, почему push_back регрессирует в производительности между C ++ 03 и C ++ 11.
milianw 07 янв. 2014, в 17:24
0

Или мой процессор медленнее, чем ваш @remyabel? Во всяком случае, GCC, который я использую, взят из официального пакета ArchLinux.
milianw 07 янв. 2014, в 17:26
0

Попробуйте -fwhole-program (и -march=native и т. Д.)
dyp 07 янв. 2014, в 17:51
1

@milianw Оказывается, я собирал не ту программу. Игнорируйте мои комментарии.
user1508519 07 янв. 2014, в 18:03
0

@Cogwheel Ну, emplace_back будет быстрее, потому что избегает лишних копий с использованием движущейся семантики. Я бы порекомендовал попробовать это в другом компиляторе (например, clang), потому что это может быть ошибка в g ++ или просто нарушение стандарта (например, в std :: list.size ())
Pedrom 07 янв. 2014, в 19:00
2

С clang3.4 версия C ++ 11 быстрее, 0,047 с против 0,058 для версии C ++ 98
Praetorian 07 янв. 2014, в 19:33
0

Мое первое впечатление заключается в том, что push_back в версии C ++ 11 не устраняет копирование во время оптимизации и копирования фактически, тогда как не-C ++ 11 можно видеть, что Item () ограничен только аргументом функции. Я думаю, что это лучший способ, потому что я хотел бы, чтобы он НАСТОЯЩИМ КОПИРОВАЛ (я предполагаю, что MOVED в этом примере, но так как это структура POD, это то же самое, что и копия), когда я использую push_back вместо emplace_back. (Может быть, я хочу сделать что-то в конструкторе копирования / перемещения)
Etherealone 07 янв. 2014, в 20:21
0

Вы также можете попытаться поместить Item() в область видимости main как Item a(); , push_back(a); и сравните результат, чтобы убедиться, что он скопирован. Также возможно модифицировать потом , чтобы убедиться , что все еще не оптимизировано. a
Etherealone 07 янв. 2014, в 20:27
0

отличный вопрос как упомянул @Etherealone, это может быть копирование - stackoverflow.com/questions/10890653/…
stellarossa 08 янв. 2014, в 00:22

Показать ещё 9 комментариев

Теги:

c++

performance

c++11

vector

gcc

1 ответ

Ещё вопросы

Если вы скомпилируете сборку, вы можете увидеть, что происходит под капотом. Смотрите также stackoverflow.com/questions/8021874/…
Что произойдет, если вы измените push_back(Item()) на emplace_back() в версии C ++ 11?
Смотри выше, что «исправляет» регрессию. Я до сих пор удивляюсь, почему push_back регрессирует в производительности между C ++ 03 и C ++ 11.
Или мой процессор медленнее, чем ваш @remyabel? Во всяком случае, GCC, который я использую, взят из официального пакета ArchLinux.
Попробуйте -fwhole-program (и -march=native и т. Д.)
@milianw Оказывается, я собирал не ту программу. Игнорируйте мои комментарии.
@Cogwheel Ну, emplace_back будет быстрее, потому что избегает лишних копий с использованием движущейся семантики. Я бы порекомендовал попробовать это в другом компиляторе (например, clang), потому что это может быть ошибка в g ++ или просто нарушение стандарта (например, в std :: list.size ())
С clang3.4 версия C ++ 11 быстрее, 0,047 с против 0,058 для версии C ++ 98
Мое первое впечатление заключается в том, что push_back в версии C ++ 11 не устраняет копирование во время оптимизации и копирования фактически, тогда как не-C ++ 11 можно видеть, что Item () ограничен только аргументом функции. Я думаю, что это лучший способ, потому что я хотел бы, чтобы он НАСТОЯЩИМ КОПИРОВАЛ (я предполагаю, что MOVED в этом примере, но так как это структура POD, это то же самое, что и копия), когда я использую push_back вместо emplace_back. (Может быть, я хочу сделать что-то в конструкторе копирования / перемещения)
Вы также можете попытаться поместить Item() в область видимости main как Item a(); , push_back(a); и сравните результат, чтобы убедиться, что он скопирован. Также возможно модифицировать потом , чтобы убедиться , что все еще не оптимизировано. a
отличный вопрос как упомянул @Etherealone, это может быть копирование - stackoverflow.com/questions/10890653/…

Ali · Accepted Answer · 2014-01-07T23-01-00.000Z

Я могу воспроизвести результаты на своей машине с теми вариантами, которые вы пишете в своем сообщении.

Однако, если я также включаю оптимизацию времени ссылки (я также передаю флаг -flto в gcc 4.7.2), результаты идентичны:

(Я компилирую ваш исходный код с помощью container.push_back(Item());)

$ g++ -std=c++11 -O3 -flto regr.cpp && perf stat -r 10 ./a.out 

 Performance counter stats for './a.out' (10 runs):

         35.426793 task-clock                #    0.986 CPUs utilized            ( +-  1.75% )
                 4 context-switches          #    0.116 K/sec                    ( +-  5.69% )
                 0 CPU-migrations            #    0.006 K/sec                    ( +- 66.67% )
            19,801 page-faults               #    0.559 M/sec                  
        99,028,466 cycles                    #    2.795 GHz                      ( +-  1.89% ) [77.53%]
        50,721,061 stalled-cycles-frontend   #   51.22% frontend cycles idle     ( +-  3.74% ) [79.47%]
        25,585,331 stalled-cycles-backend    #   25.84% backend  cycles idle     ( +-  4.90% ) [73.07%]
       141,947,224 instructions              #    1.43  insns per cycle        
                                             #    0.36  stalled cycles per insn  ( +-  0.52% ) [88.72%]
        37,697,368 branches                  # 1064.092 M/sec                    ( +-  0.52% ) [88.75%]
            26,700 branch-misses             #    0.07% of all branches          ( +-  3.91% ) [83.64%]

       0.035943226 seconds time elapsed                                          ( +-  1.79% )



$ g++ -std=c++98 -O3 -flto regr.cpp && perf stat -r 10 ./a.out 

 Performance counter stats for './a.out' (10 runs):

         35.510495 task-clock                #    0.988 CPUs utilized            ( +-  2.54% )
                 4 context-switches          #    0.101 K/sec                    ( +-  7.41% )
                 0 CPU-migrations            #    0.003 K/sec                    ( +-100.00% )
            19,801 page-faults               #    0.558 M/sec                    ( +-  0.00% )
        98,463,570 cycles                    #    2.773 GHz                      ( +-  1.09% ) [77.71%]
        50,079,978 stalled-cycles-frontend   #   50.86% frontend cycles idle     ( +-  2.20% ) [79.41%]
        26,270,699 stalled-cycles-backend    #   26.68% backend  cycles idle     ( +-  8.91% ) [74.43%]
       141,427,211 instructions              #    1.44  insns per cycle        
                                             #    0.35  stalled cycles per insn  ( +-  0.23% ) [87.66%]
        37,366,375 branches                  # 1052.263 M/sec                    ( +-  0.48% ) [88.61%]
            26,621 branch-misses             #    0.07% of all branches          ( +-  5.28% ) [83.26%]

       0.035953916 seconds time elapsed

Что касается причин, нужно посмотреть на сгенерированный код сборки (g++ -std=c++11 -O3 -S regr.cpp). В режиме С++ 11 сгенерированный код значительно более загроможден, чем для режима С++ 98, и вложение функции
void std::vector<Item,std::allocator<Item>>::_M_emplace_back_aux<Item>(Item&&)
не работает в режиме С++ 11 со значением по умолчанию inline-limit.

Этот неудачный встроенный эффект имеет эффект домино. Не потому, что эта функция вызывается (его даже не называют!), а потому, что мы должны быть готовы: если он называется, функциональные выражения (Item.a и Item.b) должны быть уже в нужном месте. Это ведет к довольно грязный код.

Вот соответствующая часть сгенерированного кода для случая, когда встраивание выполняется:

.L42:
    testq   %rbx, %rbx  # container$D13376$_M_impl$_M_finish
    je  .L3 #,
    movl    $0, (%rbx)  #, container$D13376$_M_impl$_M_finish_136->a
    movl    $0, 4(%rbx) #, container$D13376$_M_impl$_M_finish_136->b
.L3:
    addq    $8, %rbx    #, container$D13376$_M_impl$_M_finish
    subq    $1, %rbp    #, ivtmp.106
    je  .L41    #,
.L14:
    cmpq    %rbx, %rdx  # container$D13376$_M_impl$_M_finish, container$D13376$_M_impl$_M_end_of_storage
    jne .L42    #,

Это хороший и компактный цикл. Теперь сравните это со случаем неудачного встроенного:

.L49:
    testq   %rax, %rax  # D.15772
    je  .L26    #,
    movq    16(%rsp), %rdx  # D.13379, D.13379
    movq    %rdx, (%rax)    # D.13379, *D.15772_60
.L26:
    addq    $8, %rax    #, tmp75
    subq    $1, %rbx    #, ivtmp.117
    movq    %rax, 40(%rsp)  # tmp75, container.D.13376._M_impl._M_finish
    je  .L48    #,
.L28:
    movq    40(%rsp), %rax  # container.D.13376._M_impl._M_finish, D.15772
    cmpq    48(%rsp), %rax  # container.D.13376._M_impl._M_end_of_storage, D.15772
    movl    $0, 16(%rsp)    #, D.13379.a
    movl    $0, 20(%rsp)    #, D.13379.b
    jne .L49    #,
    leaq    16(%rsp), %rsi  #,
    leaq    32(%rsp), %rdi  #,
    call    _ZNSt6vectorI4ItemSaIS0_EE19_M_emplace_back_auxIIS0_EEEvDpOT_   #

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

leaq    16(%rsp), %rsi  #,
leaq    32(%rsp), %rdi  #,
call    _ZNSt6vectorI4ItemSaIS0_EE19_M_emplace_back_auxIIS0_EEEvDpOT_   #

Даже если это никогда не выполняется, цикл устраивает вещи раньше:

movl    $0, 16(%rsp)    #, D.13379.a
movl    $0, 20(%rsp)    #, D.13379.b

Это приводит к беспорядочному коду. Если функция call отсутствует, потому что inlining преуспевает, у нас есть всего 2 команды перемещения в цикле, и нет никакого взаимодействия с %rsp (указателем стека). Однако, если вложение не выполняется, мы получаем 6 ходов, и мы много кладем с %rsp.

Просто чтобы обосновать мою теорию (обратите внимание на -finline-limit), как в режиме С++ 11:

 $ g++ -std=c++11 -O3 -finline-limit=105 regr.cpp && perf stat -r 10 ./a.out

 Performance counter stats for './a.out' (10 runs):

         84.739057 task-clock                #    0.993 CPUs utilized            ( +-  1.34% )
                 8 context-switches          #    0.096 K/sec                    ( +-  2.22% )
                 1 CPU-migrations            #    0.009 K/sec                    ( +- 64.01% )
            19,801 page-faults               #    0.234 M/sec                  
       266,809,312 cycles                    #    3.149 GHz                      ( +-  0.58% ) [81.20%]
       206,804,948 stalled-cycles-frontend   #   77.51% frontend cycles idle     ( +-  0.91% ) [81.25%]
       129,078,683 stalled-cycles-backend    #   48.38% backend  cycles idle     ( +-  1.37% ) [69.49%]
       183,130,306 instructions              #    0.69  insns per cycle        
                                             #    1.13  stalled cycles per insn  ( +-  0.85% ) [85.35%]
        38,759,720 branches                  #  457.401 M/sec                    ( +-  0.29% ) [85.43%]
            24,527 branch-misses             #    0.06% of all branches          ( +-  2.66% ) [83.52%]

       0.085359326 seconds time elapsed                                          ( +-  1.31% )

 $ g++ -std=c++11 -O3 -finline-limit=106 regr.cpp && perf stat -r 10 ./a.out

 Performance counter stats for './a.out' (10 runs):

         37.790325 task-clock                #    0.990 CPUs utilized            ( +-  2.06% )
                 4 context-switches          #    0.098 K/sec                    ( +-  5.77% )
                 0 CPU-migrations            #    0.011 K/sec                    ( +- 55.28% )
            19,801 page-faults               #    0.524 M/sec                  
       104,699,973 cycles                    #    2.771 GHz                      ( +-  2.04% ) [78.91%]
        58,023,151 stalled-cycles-frontend   #   55.42% frontend cycles idle     ( +-  4.03% ) [78.88%]
        30,572,036 stalled-cycles-backend    #   29.20% backend  cycles idle     ( +-  5.31% ) [71.40%]
       140,669,773 instructions              #    1.34  insns per cycle        
                                             #    0.41  stalled cycles per insn  ( +-  1.40% ) [88.14%]
        38,117,067 branches                  # 1008.646 M/sec                    ( +-  0.65% ) [89.38%]
            27,519 branch-misses             #    0.07% of all branches          ( +-  4.01% ) [86.16%]

       0.038187580 seconds time elapsed                                          ( +-  2.05% )

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

Так что же забрать эту историю? Эти неудачные строки могут обойтись очень дорого, и вы должны в полной мере использовать возможности компилятора: Я могу только рекомендовать оптимизацию времени ссылки. Это дало значительный прирост производительности моим программам (до 2,5x) и все, что мне нужно сделать, это передать флаг -flto. Это довольно неплохая сделка!;)

Тем не менее, я не рекомендую вызывать код с ключевым словом inline; пусть компилятор решит, что делать. (Оптимизатору разрешено обрабатывать ключевое слово inline как пустое пространство в любом случае.)

Отличный вопрос, +1!

NB: inline имеет ничего общего с встраиванием функций; это означает «определенный в строке», а не «пожалуйста, укажите это». Если вы действительно хотите запросить вставку, используйте __attribute__((always_inline)) или подобное.
@JonPurdy Не совсем, например, функции-члены класса неявно встроены. inline - это также запрос к компилятору о том, что вы хотите, чтобы функция была встроенной, и, например, компилятор Intel C ++, используемый для выдачи предупреждений о производительности, если он не выполнил ваш запрос. (Я недавно не проверял icc, если это все еще происходит.) К сожалению, я видел, как люди ломали свой код inline и ожидали чуда. Я бы не использовал __attribute__((always_inline)) ; Скорее всего, разработчики компилятора лучше знают, что делать, а что нет. (Несмотря на контрпример здесь.)
@JonPurdy С другой стороны, если вы определяете встроенную функцию, которая не является функцией-членом класса , то у вас действительно нет другого выбора, кроме как пометить ее как встроенную, в противном случае вы получите несколько ошибок определения от компоновщика. Если это то, что вы имели в виду, тогда хорошо.
Да, это то, что я имел в виду. Стандарт гласит: « inline спецификатор указывает реализации, что внутренняя замена тела функции в точке вызова должна быть предпочтительнее обычного механизма вызова функции». (§7.1.2.2) Однако реализации не требуются для выполнения эта оптимизация, так как это в значительной степени совпадение, что inline функции часто оказываются хорошими кандидатами для встраивания. Так что лучше быть явным и использовать прагму компилятора.
@JonPurdy Что касается первой половины: да, именно это я и имел в виду, говоря: « Оптимизатору все равно разрешается использовать встроенное ключевое слово как пробел». Что касается прагмы компилятора, я бы этим не воспользовался, я бы оставил это на усмотрение оптимизации времени соединения независимо от того, встроен он или нет. Это делает довольно хорошую работу; это также автоматически решило эту проблему, обсуждаемую здесь в ответе.
@Ali Джон был прав в своем первом комментарии, inline необходимо , чтобы избежать ошибок в линии связи по линии «умножения определенных символов». Это не имеет ничего общего с оптимизацией, это для объединения времени соединения.
@ v.oddou Пожалуйста, прочитайте мой предыдущий комментарий.