Плавающая точка и целочисленные вычисления на современном оборудовании

Я выполняю критическую работу с высокой производительностью на С++, и в настоящее время мы используем целочисленные вычисления для задач, которые являются по сути плавающей точкой, потому что "быстрее". Это вызывает множество неприятных проблем и добавляет много раздражающего кода.

Теперь я помню, как читал о том, как расчеты с плавающей запятой были настолько медленными примерно примерно через 386 дней, где я считаю (IIRC), что есть дополнительный соучастник. Но, безусловно, в настоящее время с экспоненциально более сложными и мощными процессорами он не имеет никакого значения в "скорости" при выполнении вычисления с плавающей точкой или целым числом? Тем более, что фактическое время вычисления крошечное по сравнению с чем-то вроде того, что вызывает срыв трубопровода или извлечение чего-либо из основной памяти?

Я знаю, что правильный ответ заключается в контроле на целевом оборудовании, что было бы хорошим способом проверить это? Я написал две крошечные программы на C++ и сравнивал их время работы с "временем" в Linux, но фактическое время выполнения слишком изменчиво (не помогает мне работать на виртуальном сервере). Если не потратить весь мой день на сотни тестов, сделать графики и т.д., То я могу сделать, чтобы получить разумный тест относительной скорости? Любые идеи или мысли? Я совершенно не прав?

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

#include <iostream>
#include <cmath>
#include <cstdlib>
#include <time.h>

int main( int argc, char** argv )
{
    int accum = 0;

    srand( time( NULL ) );

    for( unsigned int i = 0; i < 100000000; ++i )
    {
        accum += rand( ) % 365;
    }
    std::cout << accum << std::endl;

    return 0;
}

Программа 2:

#include <iostream>
#include <cmath>
#include <cstdlib>
#include <time.h>

int main( int argc, char** argv )
{

    float accum = 0;
    srand( time( NULL ) );

    for( unsigned int i = 0; i < 100000000; ++i )
    {
        accum += (float)( rand( ) % 365 );
    }
    std::cout << accum << std::endl;

    return 0;
}

Спасибо заранее!

Изменить: платформа, о которой я забочусь, - это обычные x86 или x86-64, работающие на настольных компьютерах Linux и Windows.

Изменить 2 (добавлено из комментария ниже): В настоящее время у нас есть обширная база кода. На самом деле я столкнулся с обобщением, что мы "не должны использовать float, поскольку вычисление целых чисел выполняется быстрее" - и я ищу способ (если это правда), чтобы опровергнуть это обобщенное предположение. Я понимаю, что было бы невозможно предсказать точный результат для нас, не выполняя всю работу и не профилируя ее впоследствии.

В любом случае, спасибо за все ваши прекрасные ответы и помощь. Не стесняйтесь добавлять что-нибудь еще:).

Ответ 1

Увы, я могу дать вам ответ "это зависит"...

По моему опыту, в производительности есть много, много переменных... особенно между целыми числами и математикой с плавающей запятой. Он сильно отличается от процессора к процессору (даже в пределах одного семейства, такого как x86), поскольку разные процессоры имеют разные длины "конвейера". Кроме того, некоторые операции, как правило, очень просты (например, добавление) и имеют ускоренный маршрут через процессор, а другие (например, деление) занимают гораздо больше времени.

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

Я предполагаю, что вы задаете этот вопрос, потому что работаете над критичным для производительности приложением. Если вы разрабатываете архитектуру x86 и вам нужна дополнительная производительность, вам может понадобиться использовать расширения SSE. Это может значительно ускорить арифметику с плавающей запятой с одинарной точностью, так как одна и та же операция может выполняться сразу по нескольким данным, плюс есть отдельный банк регистров для операций SSE. (Я заметил, что в вашем втором примере вы использовали "float" вместо "double", заставляя меня думать, что вы используете математику с одной точностью).

* Примечание. Использование старых команд MMX фактически замедлит работу программ, поскольку эти старые инструкции фактически используют те же регистры, что и FPU, что делает невозможным одновременное использование как FPU, так и MMX.

Ответ 2

Например (меньшие числа быстрее),

64-разрядная версия Intel Xeon X5550 с частотой 2,67 ГГц, gcc 4.1.2 -O3

short add/sub: 1.005460 [0]
short mul/div: 3.926543 [0]
long add/sub: 0.000000 [0]
long mul/div: 7.378581 [0]
long long add/sub: 0.000000 [0]
long long mul/div: 7.378593 [0]
float add/sub: 0.993583 [0]
float mul/div: 1.821565 [0]
double add/sub: 0.993884 [0]
double mul/div: 1.988664 [0]

32-разрядный двухъядерный процессор AMD Opteron (tm) 265 @1,81 ГГц, gcc 3.4,6 -O3

short add/sub: 0.553863 [0]
short mul/div: 12.509163 [0]
long add/sub: 0.556912 [0]
long mul/div: 12.748019 [0]
long long add/sub: 5.298999 [0]
long long mul/div: 20.461186 [0]
float add/sub: 2.688253 [0]
float mul/div: 4.683886 [0]
double add/sub: 2.700834 [0]
double mul/div: 4.646755 [0]

Как указал Дэн, даже если вы нормализуете тактовую частоту (что может вводить в заблуждение само по себе в конвейерных конструкциях), результаты будут сильно различаться в зависимости от архитектуры ЦП (индивидуально производительность ALU/FPU performance, а также фактическое количество ALU/FPU, доступных на ядро в суперскалярных конструкциях, которые влияют на то, сколько независимые операции могут выполняться параллельно - последний фактор не выполняется в приведенном ниже коде, поскольку все операции ниже зависят друг от друга.)

Бедный человек FPU/ALU тест производительности:

#include <stdio.h>
#ifdef _WIN32
#include <sys/timeb.h>
#else
#include <sys/time.h>
#endif
#include <time.h>
#include <cstdlib>

double
mygettime(void) {
# ifdef _WIN32
  struct _timeb tb;
  _ftime(&tb);
  return (double)tb.time + (0.001 * (double)tb.millitm);
# else
  struct timeval tv;
  if(gettimeofday(&tv, 0) < 0) {
    perror("oops");
  }
  return (double)tv.tv_sec + (0.000001 * (double)tv.tv_usec);
# endif
}

template< typename Type >
void my_test(const char* name) {
  Type v  = 0;
  // Do not use constants or repeating values
  //  to avoid loop unroll optimizations.
  // All values >0 to avoid division by 0
  // Perform ten ops/iteration to reduce
  //  impact of ++i below on measurements
  Type v0 = (Type)(rand() % 256)/16 + 1;
  Type v1 = (Type)(rand() % 256)/16 + 1;
  Type v2 = (Type)(rand() % 256)/16 + 1;
  Type v3 = (Type)(rand() % 256)/16 + 1;
  Type v4 = (Type)(rand() % 256)/16 + 1;
  Type v5 = (Type)(rand() % 256)/16 + 1;
  Type v6 = (Type)(rand() % 256)/16 + 1;
  Type v7 = (Type)(rand() % 256)/16 + 1;
  Type v8 = (Type)(rand() % 256)/16 + 1;
  Type v9 = (Type)(rand() % 256)/16 + 1;

  double t1 = mygettime();
  for (size_t i = 0; i < 100000000; ++i) {
    v += v0;
    v -= v1;
    v += v2;
    v -= v3;
    v += v4;
    v -= v5;
    v += v6;
    v -= v7;
    v += v8;
    v -= v9;
  }
  // Pretend we make use of v so compiler does not optimize out
  //  the loop completely
  printf("%s add/sub: %f [%d]\n", name, mygettime() - t1, (int)v&1);
  t1 = mygettime();
  for (size_t i = 0; i < 100000000; ++i) {
    v /= v0;
    v *= v1;
    v /= v2;
    v *= v3;
    v /= v4;
    v *= v5;
    v /= v6;
    v *= v7;
    v /= v8;
    v *= v9;
  }
  // Pretend we make use of v so compiler does not optimize out
  //  the loop completely
  printf("%s mul/div: %f [%d]\n", name, mygettime() - t1, (int)v&1);
}

int main() {
  my_test< short >("short");
  my_test< long >("long");
  my_test< long long >("long long");
  my_test< float >("float");
  my_test< double >("double");

  return 0;
}

Ответ 3

Вероятно, существует значительная разница в скорости реального мира между математикой с фиксированной точкой и математикой с плавающей запятой, но теоретическая максимальная пропускная способность ALU против FPU совершенно не имеет значения. Вместо этого число целых и регистров с плавающей запятой (реальные регистры, а не имена регистров) в вашей архитектуре, которые иначе не используются при вычислении (например, для управления циклом), количество элементов каждого типа, которые вписываются в строку кэша, возможно оптимизация с учетом разной семантики для математики с целым числом по сравнению с математикой с плавающей запятой - эти эффекты будут доминировать. Зависимости данных вашего алгоритма играют здесь значительную роль, так что никакое общее сравнение не предсказывает разрыв в производительности вашей проблемы.

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

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

Ответ 4

Дополнение намного быстрее, чем rand, поэтому ваша программа (особенно) бесполезна.

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

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

Ответ 5

TIL Это варьируется (много). Вот некоторые результаты использования компилятора gnu (кстати, я также проверил компиляцию на машинах, gnu g++ 5.4 из xenial намного быстрее, чем 4.6.3 из linaro для точных данных)

Intel i7 4700MQ xenial

short add: 0.822491
short sub: 0.832757
short mul: 1.007533
short div: 3.459642
long add: 0.824088
long sub: 0.867495
long mul: 1.017164
long div: 5.662498
long long add: 0.873705
long long sub: 0.873177
long long mul: 1.019648
long long div: 5.657374
float add: 1.137084
float sub: 1.140690
float mul: 1.410767
float div: 2.093982
double add: 1.139156
double sub: 1.146221
double mul: 1.405541
double div: 2.093173

Intel i3 2370M имеет похожие результаты

short add: 1.369983
short sub: 1.235122
short mul: 1.345993
short div: 4.198790
long add: 1.224552
long sub: 1.223314
long mul: 1.346309
long div: 7.275912
long long add: 1.235526
long long sub: 1.223865
long long mul: 1.346409
long long div: 7.271491
float add: 1.507352
float sub: 1.506573
float mul: 2.006751
float div: 2.762262
double add: 1.507561
double sub: 1.506817
double mul: 1.843164
double div: 2.877484

Intel (R) Celeron (R) 2955U (Chromebook Acer C720 под управлением xenial)

short add: 1.999639
short sub: 1.919501
short mul: 2.292759
short div: 7.801453
long add: 1.987842
long sub: 1.933746
long mul: 2.292715
long div: 12.797286
long long add: 1.920429
long long sub: 1.987339
long long mul: 2.292952
long long div: 12.795385
float add: 2.580141
float sub: 2.579344
float mul: 3.152459
float div: 4.716983
double add: 2.579279
double sub: 2.579290
double mul: 3.152649
double div: 4.691226

Процессор Intel® R Xeon® R (1 ГБ) DigitalOcean объемом 1 ГБ, версия E5-2630L v2 (работает надежно)

short add: 1.094323
short sub: 1.095886
short mul: 1.356369
short div: 4.256722
long add: 1.111328
long sub: 1.079420
long mul: 1.356105
long div: 7.422517
long long add: 1.057854
long long sub: 1.099414
long long mul: 1.368913
long long div: 7.424180
float add: 1.516550
float sub: 1.544005
float mul: 1.879592
float div: 2.798318
double add: 1.534624
double sub: 1.533405
double mul: 1.866442
double div: 2.777649

Процессор AMD Opteron (tm) 4122 (точный)

short add: 3.396932
short sub: 3.530665
short mul: 3.524118
short div: 15.226630
long add: 3.522978
long sub: 3.439746
long mul: 5.051004
long div: 15.125845
long long add: 4.008773
long long sub: 4.138124
long long mul: 5.090263
long long div: 14.769520
float add: 6.357209
float sub: 6.393084
float mul: 6.303037
float div: 17.541792
double add: 6.415921
double sub: 6.342832
double mul: 6.321899
double div: 15.362536

Здесь используется код из http://pastebin.com/Kx8WGUfg как benchmark-pc.c

g++ -fpermissive -O3 -o benchmark-pc benchmark-pc.c

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

Одним заметным исключением, похоже, является ALU mul против FPU mul. Сложение и вычитание кажутся тривиально разными.

Вот выше в форме диаграммы (нажмите для полного размера, ниже быстрее и предпочтительнее):

Chart of above data

Обновление для размещения @Peter Cordes

https://gist.github.com/Lewiscowles1986/90191c59c9aedf3d08bf0b129065cccc

i7 4700MQ Linux Ubuntu Xenial 64-bit (все исправления до 2018-03-13 применены)
    short add: 0.773049
    short sub: 0.789793
    short mul: 0.960152
    short div: 3.273668
      int add: 0.837695
      int sub: 0.804066
      int mul: 0.960840
      int div: 3.281113
     long add: 0.829946
     long sub: 0.829168
     long mul: 0.960717
     long div: 5.363420
long long add: 0.828654
long long sub: 0.805897
long long mul: 0.964164
long long div: 5.359342
    float add: 1.081649
    float sub: 1.080351
    float mul: 1.323401
    float div: 1.984582
   double add: 1.081079
   double sub: 1.082572
   double mul: 1.323857
   double div: 1.968488
Процессор AMD Opteron (tm) 4122 (точный, общий хостинг DreamHost)
    short add: 1.235603
    short sub: 1.235017
    short mul: 1.280661
    short div: 5.535520
      int add: 1.233110
      int sub: 1.232561
      int mul: 1.280593
      int div: 5.350998
     long add: 1.281022
     long sub: 1.251045
     long mul: 1.834241
     long div: 5.350325
long long add: 1.279738
long long sub: 1.249189
long long mul: 1.841852
long long div: 5.351960
    float add: 2.307852
    float sub: 2.305122
    float mul: 2.298346
    float div: 4.833562
   double add: 2.305454
   double sub: 2.307195
   double mul: 2.302797
   double div: 5.485736
Intel Xeon E5-2630L v2 с частотой 2,4 ГГц (надежный 64-разрядный, DigitalOcean VPS)
    short add: 1.040745
    short sub: 0.998255
    short mul: 1.240751
    short div: 3.900671
      int add: 1.054430
      int sub: 1.000328
      int mul: 1.250496
      int div: 3.904415
     long add: 0.995786
     long sub: 1.021743
     long mul: 1.335557
     long div: 7.693886
long long add: 1.139643
long long sub: 1.103039
long long mul: 1.409939
long long div: 7.652080
    float add: 1.572640
    float sub: 1.532714
    float mul: 1.864489
    float div: 2.825330
   double add: 1.535827
   double sub: 1.535055
   double mul: 1.881584
   double div: 2.777245

Ответ 6

Две точки для рассмотрения -

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

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

Во-вторых, большинство процессоров в наши дни имеют инструкции SIMD для плавающей запятой, которые могут работать одновременно с множеством значений с плавающей запятой. Например, вы можете загрузить 4 поплавки в один регистр SSE и выполнить 4 умножения на них все параллельно. Если вы можете переписать части своего кода для использования инструкций SSE, то, скорее всего, он будет быстрее целочисленной версии. Visual С++ предоставляет встроенные функции компилятора, для получения некоторой информации см. http://msdn.microsoft.com/en-us/library/x5c07e2a(v=VS.80).aspx.

Ответ 7

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

Обычный первый шаг к вопросам эффективности - это профиль вашего кода, чтобы увидеть, где действительно выполняется время выполнения. Команда linux для этого - gprof.

Edit:

Хотя я предполагаю, что вы всегда можете реализовать алгоритм рисования линии с использованием целых чисел и чисел с плавающей запятой, назовите его много раз и посмотрите, не имеет ли это значения:

http://en.wikipedia.org/wiki/Bresenham's_algorithm

Ответ 8

Сегодня целочисленные операции обычно немного быстрее, чем операции с плавающей запятой. Поэтому, если вы можете выполнять вычисления с одинаковыми операциями в целочисленных и с плавающей запятой, используйте целочисленные. ОДНАКО вы говорите: "Это вызывает много раздражающих проблем и добавляет много раздражающего кода". Похоже, вам нужно больше операций, потому что вы используете целочисленную арифметику вместо числа с плавающей запятой. В этом случае с плавающей точкой будет работать быстрее, потому что

  • как только вам понадобится больше целочисленных операций, вам, вероятно, понадобится гораздо больше, поэтому небольшое преимущество в скорости будет более чем съедено дополнительными операциями

  • код с плавающей точкой проще, что означает, что писать код быстрее, а это значит, что если он критичен по скорости, вы можете потратить больше времени на оптимизацию кода.

Ответ 9

Версия с плавающей запятой будет намного медленнее, если операция останова отсутствует. Поскольку все добавления являются последовательными, процессор не сможет параллелизировать суммирование. Задержка будет критической. Задержка добавления FPU обычно составляет 3 цикла, а целочисленное добавление - 1 цикл. Тем не менее, делитель для оператора остатка, вероятно, будет важной частью, поскольку он не полностью конвейеризован на современных процессорах. поэтому, считая, что команда деления/остатка будет потреблять большую часть времени, разница из-за задержки добавления будет небольшой.

Ответ 10

Я проверил тест, который просто добавил 1 к числу вместо rand(). Результаты (на x86-64) были:

  • short: 4.260s
  • int: 4.020s
  • long long: 3.350s
  • float: 7.330s
  • double: 7.210s

Ответ 11

Основываясь на этом "надежном" "то, что я слышал", в прежние времена целочисленный расчет был примерно в 20-50 раз быстрее, чем с плавающей запятой, и в эти дни он был менее чем в два раза быстрее.