Как выравнивание адреса цикла влияет на скорость на Intel x86_64?

Question

Я вижу снижение производительности на 15% одного и того же кода C ++, скомпилированного с точно такими же машинными инструкциями, но расположенного по разным адресам Когда мой крошечный основной цикл начинается с 0x415220, он быстрее, чем с 0x415250. Я использую это на Intel Core2 Duo. Я использую gcc 4.4.5 на x86_64 Ubuntu.

Кто-нибудь может объяснить причину замедления и как я могу заставить gcc оптимально выровнять цикл?

Вот разборка для обоих случаев с аннотацией профилировщика:

  415220 576      12.56% |XXXXXXXXXXXXXX       48 c1 eb 08           shr    $0x8,%rbx
  415224 110       2.40% |XX                   0f b6 c3              movzbl %bl,%eax
  415227           0.00% |                     41 0f b6 04 00        movzbl (%r8,%rax,1),%eax
  41522c 40        0.87% |                     48 8b 04 c1           mov    (%rcx,%rax,8),%rax
  415230 806      17.58% |XXXXXXXXXXXXXXXXXXX  4c 63 f8              movslq %eax,%r15
  415233 186       4.06% |XXXX                 48 c1 e8 20           shr    $0x20,%rax
  415237 102       2.22% |XX                   4c 01 f9              add    %r15,%rcx
  41523a 414       9.03% |XXXXXXXXXX           a8 0f                 test   $0xf,%al
  41523c 680      14.83% |XXXXXXXXXXXXXXXX     74 45                 je     415283 ::Run(char const*, char const*)+0x4b3>
  41523e           0.00% |                     41 89 c7              mov    %eax,%r15d
  415241           0.00% |                     41 83 e7 01           and    $0x1,%r15d
  415245           0.00% |                     41 83 ff 01           cmp    $0x1,%r15d
  415249           0.00% |                     41 89 c7              mov    %eax,%r15d

  415250 679      13.05% |XXXXXXXXXXXXXXXX     48 c1 eb 08           shr    $0x8,%rbx
  415254 124       2.38% |XX                   0f b6 c3              movzbl %bl,%eax
  415257           0.00% |                     41 0f b6 04 00        movzbl (%r8,%rax,1),%eax
  41525c 43        0.83% |X                    48 8b 04 c1           mov    (%rcx,%rax,8),%rax
  415260 828      15.91% |XXXXXXXXXXXXXXXXXXX  4c 63 f8              movslq %eax,%r15
  415263 388       7.46% |XXXXXXXXX            48 c1 e8 20           shr    $0x20,%rax
  415267 141       2.71% |XXX                  4c 01 f9              add    %r15,%rcx
  41526a 634      12.18% |XXXXXXXXXXXXXXX      a8 0f                 test   $0xf,%al
  41526c 749      14.39% |XXXXXXXXXXXXXXXXXX   74 45                 je     4152b3 ::Run(char const*, char const*)+0x4c3>
  41526e           0.00% |                     41 89 c7              mov    %eax,%r15d
  415271           0.00% |                     41 83 e7 01           and    $0x1,%r15d
  415275           0.00% |                     41 83 ff 01           cmp    $0x1,%r15d
  415279           0.00% |                     41 89 c7              mov    %eax,%r15d

Answer 1

Gcc имеет опцию -falign-loops = n , где n - это максимальное количество пропускаемых байтов , если будет пропущено машинное значение по умолчанию.Gcc автоматически активирует это при -O2 и -O3 уровнях оптимизации.

Answer 2

В процессорах Intel с функцией Loop Stream Detection выравнивание кода тела цикла может повысить эффективность, особенно при нормальных уровнях развертывания.Выравнивание платит штраф при первом входе в цикл сверху.Вы не показывали код там, где были бы бессмысленные прославленные неоперационные инструкции в выровненном регистре.gcc обычно использует условное выравнивание, которое применяет выравнивание только в тех случаях, когда требуется ограниченное количество отступов.Когда я однажды посмотрел на него, варианты, которые влияют на это поведение, казались не очень эффективными.Как сказал Александр, важно установить значение для -march или -mtune, чтобы gcc мог использовать соответствующие настройки выравнивания.Все компиляторы, которые я использую, в некоторых случаях не могут выровнять тело цикла, и, похоже, это не контролируется.