Разница в производительности между Windows и Linux при использовании компилятора Intel: взгляд на сборку

Я запускаю программу как в Windows, так и в Linux (x86-64). Он был скомпилирован тем же компилятором (Intel Parallel Studio XE 2017) с теми же параметрами, и версия для Windows в 3 раза быстрее, чем для Linux. Виновником является вызов std::erf, который разрешается в математике Intel. библиотека для обоих случаев (по умолчанию она подключается динамически в Windows и статически в Linux, но использование динамической компоновки в Linux дает одинаковую производительность).

Вот простая программа для воспроизведения проблемы.

#include <cmath>
#include <cstdio>

int main() {
  int n = 100000000;
  float sum = 1.0f;

  for (int k = 0; k < n; k++) {
    sum += std::erf(sum);
  }

  std::printf("%7.2f\n", sum);
}

Когда я профилирую эту программу с помощью vTune, я обнаруживаю, что сборка в версии для Windows и версии для Linux немного отличается. Вот место вызова (петля) на винде

Block 3:
"vmovaps xmm0, xmm6"
call 0x1400023e0 <erff>
Block 4:
inc ebx
"vaddss xmm6, xmm6, xmm0"
"cmp ebx, 0x5f5e100"
jl 0x14000103f <Block 3>

И начало функции erf, вызываемой в Windows

Block 1:
push rbp
"sub rsp, 0x40"
"lea rbp, ptr [rsp+0x20]"
"lea rcx, ptr [rip-0xa6c81]"
"movd edx, xmm0"
"movups xmmword ptr [rbp+0x10], xmm6"
"movss dword ptr [rbp+0x30], xmm0"
"mov eax, edx"
"and edx, 0x7fffffff"
"and eax, 0x80000000"
"add eax, 0x3f800000"
"mov dword ptr [rbp], eax"
"movss xmm6, dword ptr [rbp]"
"cmp edx, 0x7f800000"
...

В Linux код немного отличается. Место вызова:

Block 3
"vmovaps %xmm1, %xmm0"
"vmovssl  %xmm1, (%rsp)"
callq  0x400bc0 <erff>
Block 4
inc %r12d
"vmovssl  (%rsp), %xmm1"
"vaddss %xmm0, %xmm1, %xmm1"   <-------- hotspot here
"cmp $0x5f5e100, %r12d"
jl 0x400b6b <Block 3>

и начало вызываемой функции (erf):

"movd %xmm0, %edx"
"movssl  %xmm0, -0x10(%rsp)"   <-------- hotspot here
"mov %edx, %eax"
"and $0x7fffffff, %edx"
"and $0x80000000, %eax"
"add $0x3f800000, %eax"
"movl  %eax, -0x18(%rsp)"
"movssl  -0x18(%rsp), %xmm0"
"cmp $0x7f800000, %edx"
jnl 0x400dac <Block 8>
...

Я показал 2 точки, где теряется время в Linux.

Кто-нибудь достаточно разбирается в ассемблере, чтобы объяснить мне разницу двух кодов и почему версия для Linux в 3 раза медленнее?


person InsideLoop    schedule 10.11.2016    source источник
comment
Аппаратное обеспечение такое же?   -  person Leon    schedule 10.11.2016
comment
Да, такое же оборудование. Я протестировал этот случай на процессоре Core i7 Haswell для Windows и Linux, а также на Xeon Broadwell для Windows и Linux. Тот же результат. На ядре i7 я также тестировал его на macOS, и скорость такая же, как и на версии для Windows.   -  person InsideLoop    schedule 10.11.2016
comment
Работает ли Linux на виртуальной машине?   -  person Leon    schedule 10.11.2016
comment
Виртуальная машина на ядре i7 и двойная загрузка на Xeon. Это не имеет значения.   -  person InsideLoop    schedule 10.11.2016
comment
Являются ли результаты численно идентичными? Возможно, реализация Intel более точна. Конечно, определить это нетривиально.   -  person MSalters    schedule 10.11.2016
comment
Версия для Linux сохраняет, а затем восстанавливает xmm1 в/из ОЗУ в блоке 3 и блоке 4, а версия для Windows сохраняет (и я предполагаю позднее восстановление, но выше это не показано) xmm6 в/из ОЗУ.   -  person rcgldr    schedule 10.11.2016
comment
Я виню соглашения о вызовах.   -  person ratchet freak    schedule 10.11.2016
comment
Я уверен, что я не единственный, кто изначально сомневался, что узким местом были накладные расходы на вызов функции, а не вычисление самой erf() (которая является очень дорогой функцией). Функция ошибки очень быстро сходится к 1.0 для больших положительных входных данных. Переменная sum постоянно увеличивается. Таким образом, после нескольких итераций функция erf() рано выходит и возвращает 1.0, когда видит большой ввод. Таким образом, он вообще не выполняет никаких вычислений.   -  person Mysticial    schedule 10.11.2016


Ответы (2)


В обоих случаях аргументы и результаты передаются только в регистрах согласно соответствующим соглашениям о вызовах в Windows и GNU/Linux.

В варианте GNU/Linux xmm1 используется для накопления суммы. Поскольку это регистр с затиранием вызовов (он же сохраненный вызывающей стороной), он сохраняется (и восстанавливается) в кадре стека вызывающей стороны при каждом вызове.

В варианте Windows xmm6 используется для накопления суммы. Этот регистр сохраняется в соглашении о вызовах Windows (но не в GNU/Linux).

Таким образом, версия GNU/Linux сохраняет/восстанавливает как xmm0 (в вызываемом объекте[1]), так и xmm1 (в вызывающем объекте), тогда как версия для Windows сохраняет/восстанавливает только xmm6 (в вызываемом объекте).

[1] нужно посмотреть на std::errf, чтобы понять, почему.

person chill    schedule 10.11.2016
comment
Является ли тот факт, что регистр сохраняется вызываемым пользователем, всегда выполняется в Windows и никогда в Linux? - person InsideLoop; 10.11.2016
comment
Компиляторы всегда учитывают ABI, просто разные ABI определяют наборы регистров, сохраняемых вызывающей и вызываемой сторонами, по-разному. - person chill; 10.11.2016
comment
На самом деле ABI нужно соблюдать только для внешних вызовов, когда компилятор не может видеть определение. В противном случае (когда он может видеть определение вызываемого объекта) он может выполнить любое преобразование, которое ему нравится, которое не изменяет результаты четко определенного кода, включая встраивание или использование пользовательского соглашения о вызовах. - person R.. GitHub STOP HELPING ICE; 10.11.2016
comment
@R., действительно, для неэкспортируемых функций и когда известны все сайты вызовов. - person chill; 10.11.2016
comment
@chill: не обязательно знать все сайты звонков. Компилятор может (и gcc это делает) выдавать несколько версий функции, когда она доступна извне (не все сайты вызовов известны) и используется локально таким образом, что может выиграть от другого соглашения о вызовах (или внутрипроцедурного распространения констант и т. д.). ). - person R.. GitHub STOP HELPING ICE; 10.11.2016
comment
TL:DR: x86 (32- и 64-разрядная) System V ABI не имеет каких-либо регистров FP с сохранением вызовов, но в Windows ABI они есть (но только XMM, а не верхние половины YMM или ZMM). Таким образом, в Linux вызовы невстроенных функций сильно отстой для переменных FP. - person Peter Cordes; 11.11.2016
comment
@R .. у вас есть пример для случая, когда gcc выдает несколько версий функции? - person phuclv; 28.02.2017

Используя Visual Studio 2015, 64-битный режим Win 7, я нахожу следующий код для некоторых путей, используемых в erf() (показаны не все пути). Каждый путь включает до 8 (возможно, больше для других путей) констант, считываемых из памяти, поэтому одно сохранение/загрузка для сохранения регистра маловероятно приведет к трехкратной разнице в скорости между Linux и Windows. Что касается сохранения/восстановления, этот пример сохраняет и восстанавливает xmm6 и xmm7. Что касается времени, программа в исходном посте занимает около 0,86 секунды на Intel 3770K (процессор 3,5 ГГц) (VS2015/Win 7 64 бит). Обновление. Позже я определил, что накладные расходы на сохранение и восстановление регистра xmm составляют около 0,03 секунды в случае программ 10 ^ 8 циклов (около 3 наносекунд на цикл).

000007FEEE25CF90  mov         rax,rsp  
000007FEEE25CF93  movss       dword ptr [rax+8],xmm0  
000007FEEE25CF98  sub         rsp,48h  
000007FEEE25CF9C  movaps      xmmword ptr [rax-18h],xmm6  
000007FEEE25CFA0  lea         rcx,[rax+8]  
000007FEEE25CFA4  movaps      xmmword ptr [rax-28h],xmm7  
000007FEEE25CFA8  movaps      xmm6,xmm0  
000007FEEE25CFAB  call        000007FEEE266370  
000007FEEE25CFB0  movsx       ecx,ax  
000007FEEE25CFB3  test        ecx,ecx  
000007FEEE25CFB5  je          000007FEEE25D0AF  
000007FEEE25CFBB  sub         ecx,1  
000007FEEE25CFBE  je          000007FEEE25D08F  
000007FEEE25CFC4  cmp         ecx,1  
000007FEEE25CFC7  je          000007FEEE25D0AF  
000007FEEE25CFCD  xorps       xmm7,xmm7  
000007FEEE25CFD0  movaps      xmm2,xmm6  
000007FEEE25CFD3  comiss      xmm7,xmm6  
000007FEEE25CFD6  jbe         000007FEEE25CFDF  
000007FEEE25CFD8  xorps       xmm2,xmmword ptr [7FEEE2991E0h]  
000007FEEE25CFDF  movss       xmm0,dword ptr [7FEEE298E50h]  
000007FEEE25CFE7  comiss      xmm0,xmm2  
000007FEEE25CFEA  jbe         000007FEEE25D053  
000007FEEE25CFEC  movaps      xmm2,xmm6  
000007FEEE25CFEF  mulss       xmm2,xmm6  
000007FEEE25CFF3  movaps      xmm0,xmm2  
000007FEEE25CFF6  movaps      xmm1,xmm2  
000007FEEE25CFF9  mulss       xmm0,dword ptr [7FEEE298B34h]  
000007FEEE25D001  mulss       xmm1,dword ptr [7FEEE298B5Ch]  
000007FEEE25D009  addss       xmm0,dword ptr [7FEEE298B8Ch]  
000007FEEE25D011  addss       xmm1,dword ptr [7FEEE298B9Ch]  
000007FEEE25D019  mulss       xmm0,xmm2  
000007FEEE25D01D  mulss       xmm1,xmm2  
000007FEEE25D021  addss       xmm0,dword ptr [7FEEE298BB8h]  
000007FEEE25D029  addss       xmm1,dword ptr [7FEEE298C88h]  
000007FEEE25D031  mulss       xmm0,xmm2  
000007FEEE25D035  mulss       xmm1,xmm2  
000007FEEE25D039  addss       xmm0,dword ptr [7FEEE298DC8h]  
000007FEEE25D041  addss       xmm1,dword ptr [7FEEE298D8Ch]  
000007FEEE25D049  divss       xmm0,xmm1  
000007FEEE25D04D  mulss       xmm0,xmm6  
000007FEEE25D051  jmp         000007FEEE25D0B2  
000007FEEE25D053  movss       xmm1,dword ptr [7FEEE299028h]  
000007FEEE25D05B  comiss      xmm1,xmm2  
000007FEEE25D05E  jbe         000007FEEE25D076  
000007FEEE25D060  movaps      xmm0,xmm2  
000007FEEE25D063  call        000007FEEE25CF04  
000007FEEE25D068  movss       xmm1,dword ptr [7FEEE298D8Ch]  
000007FEEE25D070  subss       xmm1,xmm0  
000007FEEE25D074  jmp         000007FEEE25D07E  
000007FEEE25D076  movss       xmm1,dword ptr [7FEEE298D8Ch]  
000007FEEE25D07E  comiss      xmm7,xmm6  
000007FEEE25D081  jbe         000007FEEE25D08A  
000007FEEE25D083  xorps       xmm1,xmmword ptr [7FEEE2991E0h]  
000007FEEE25D08A  movaps      xmm0,xmm1  
000007FEEE25D08D  jmp         000007FEEE25D0B2  
000007FEEE25D08F  mov         eax,8000h  
000007FEEE25D094  test        word ptr [rsp+52h],ax  
000007FEEE25D099  je          000007FEEE25D0A5  
000007FEEE25D09B  movss       xmm0,dword ptr [7FEEE2990DCh]  
000007FEEE25D0A3  jmp         000007FEEE25D0B2  
000007FEEE25D0A5  movss       xmm0,dword ptr [7FEEE298D8Ch]  
000007FEEE25D0AD  jmp         000007FEEE25D0B2  
000007FEEE25D0AF  movaps      xmm0,xmm6  
000007FEEE25D0B2  movaps      xmm6,xmmword ptr [rsp+30h]  
000007FEEE25D0B7  movaps      xmm7,xmmword ptr [rsp+20h]  
000007FEEE25D0BC  add         rsp,48h  
000007FEEE25D0C0  ret  
person rcgldr    schedule 10.11.2016
comment
Каждый путь включает до 8 (возможно, больше для других путей) констант, считываемых из памяти. Это занимает всего 4 цикла пропускной способности на современных ЦП (семейство Intel SnB или AMD k8 и более поздние версии), а также для задержки: внеочередное выполнение может перекрыть его чем угодно, поскольку адреса известны заранее. то есть они могут быть выполнены и готовы к тому времени, когда будет готов ввод регистра в инструкцию, поэтому они не обязательно удлиняют цепочку зависимостей. Меня бы гораздо больше беспокоила цепочка mulss/addss! - person Peter Cordes; 11.11.2016
comment
Вы правы, это выглядит странно. Из C тестовая функция OP должна быть узким местом при задержке erf(), плюс 3c для добавления FP (или 4 для SKL) и, необязательно, + еще 5 или 6 циклов для сброса / перезагрузки XMM. Я невнимательно читал ассамблею. Возможно, сохранение/перезагрузка делает что-то еще менее эффективным. - person Peter Cordes; 11.11.2016
comment
@PeterCordes - продолжайте, я заменил erf подпрограммой сборки, которая просто возвращает, и той, которая сохраняет / загружает xmm0 и возвращает. Сохранение/загрузка накладных расходов xmm0 составляет 0,03 секунды с 10 ^ 8 циклами, == 3 наносекунды на пару инструкций сохранения/загрузки. Сравните 0,03 секунды хранения/загрузки с общим временем 0,86 секунды, используя erf() (опять же 10 ^ 8 циклов). - person rcgldr; 11.11.2016