Почему изменение от 0,1f до 0 снижает производительность в 10 раз?

Question

Почему изменение от 0,1f до 0 снижает производительность в 10 раз?

1336

Почему этот бит кода,

const float x[16] = {  1.1,   1.2,   1.3,     1.4,   1.5,   1.6,   1.7,   1.8,
                       1.9,   2.0,   2.1,     2.2,   2.3,   2.4,   2.5,   2.6};
const float z[16] = {1.123, 1.234, 1.345, 156.467, 1.578, 1.689, 1.790, 1.812,
                     1.923, 2.034, 2.145,   2.256, 2.367, 2.478, 2.589, 2.690};
float y[16];
for (int i = 0; i < 16; i++)
{
    y[i] = x[i];
}

for (int j = 0; j < 9000000; j++)
{
    for (int i = 0; i < 16; i++)
    {
        y[i] *= x[i];
        y[i] /= z[i];
        y[i] = y[i] + 0.1f; // <--
        y[i] = y[i] - 0.1f; // <--
    }
}

выполняется более чем в 10 раз быстрее, чем следующий бит (идентичный, если не указано)

const float x[16] = {  1.1,   1.2,   1.3,     1.4,   1.5,   1.6,   1.7,   1.8,
                       1.9,   2.0,   2.1,     2.2,   2.3,   2.4,   2.5,   2.6};
const float z[16] = {1.123, 1.234, 1.345, 156.467, 1.578, 1.689, 1.790, 1.812,
                     1.923, 2.034, 2.145,   2.256, 2.367, 2.478, 2.589, 2.690};
float y[16];
for (int i = 0; i < 16; i++)
{
    y[i] = x[i];
}

for (int j = 0; j < 9000000; j++)
{
    for (int i = 0; i < 16; i++)
    {
        y[i] *= x[i];
        y[i] /= z[i];
        y[i] = y[i] + 0; // <--
        y[i] = y[i] - 0; // <--
    }
}

при компиляции с Visual Studio 2010 SP1. (Я не тестировал другие компиляторы.)

Dragarro 16 фев. 2012, в 13:59

Источник

1

Убедитесь, что вы создаете сборку релиза, а не отладку.
tenfour 16 фев. 2012, в 16:14
51

0 является целочисленным литералом, поэтому возможно, что он должен быть преобразован в число с плавающей точкой во время выполнения.
Zyx 2000 16 фев. 2012, в 16:14
8

Как вы измерили разницу? А какие опции вы использовали при компиляции?
James Kanze 16 фев. 2012, в 16:19
151

Почему в этом случае компилятор просто не удаляет +/- 0?!?
Michael Dorgan 16 фев. 2012, в 16:25
4

Это тесно связано с проблемой в stackoverflow.com/questions/5180150/…
Stephen Canon 16 фев. 2012, в 19:46
2

ты пробовал 0f
ratchet freak 16 фев. 2012, в 20:46
117

@ Zyx2000 Компилятор не так уж и глуп. Разборка тривиального примера в LINQPad показывает, что он выдает один и тот же код независимо от того, используете ли вы 0 , 0f , 0d или даже (int)0 в контексте, где требуется double .
millimoose 17 фев. 2012, в 02:20
0

Смотрите diff здесь diffchecker.com/Rmf9561
Hamid Nazari 17 фев. 2012, в 03:20
14

какой уровень оптимизации?
Otto Allmendinger 17 фев. 2012, в 08:02
2

@ Otto Allmendinger уровень оптимизации, который я использовал, был 02 с включенным sse2
Dragarro 17 фев. 2012, в 09:03
1

@Dragarro - Просто любопытно - как ты закончил писать и синхронизировать этот код?
Vic 17 фев. 2012, в 10:31
0

@Vic Я просто дурачился, когда заметил это, просто синхронизировал разные функции и проверял разные флаги оптимизации компилятора. Сначала в коде была только часть умножения и деления, и я подумал о том, чтобы добавить сложение и вычитание, просто чтобы посмотреть, сколько дополнительного времени это займет, и, к моему удивлению, код ускорился в 10 раз. Я проверил, чтобы увидеть если я написал что-то странное, а потом я опубликовал это здесь, чтобы посмотреть, не пропустил ли я что-то.
Dragarro 17 фев. 2012, в 13:20
0

@HamidNazari - онлайн-паста для различий - отличная идея, но, похоже, она выплевывает «не удается открыть файл». По умолчанию он выглядит как «Не хранить diff», я выбрал «хранить навсегда», и он дал мне эту ссылку: diffchecker.com/U6w74qj
Kevin Vermeer 11 март 2012, в 18:04
0

См. Stackoverflow.com/questions/5180150/…
Anujith 15 фев. 2013, в 08:20
10

Почему на самом деле компилятор не сбрасывает +/- 0?
Vorac 10 май 2013, в 07:12

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

Теги:

c++

floating-point

performance

visual-studio-2010

compilation

5 ответов

383

Использование gcc и применение diff к сгенерированной сборке дает только эту разницу:

73c68,69
<   movss   LCPI1_0(%rip), %xmm1
---
>   movabsq $0, %rcx
>   cvtsi2ssq   %rcx, %xmm1
81d76
<   subss   %xmm1, %xmm0

cvtsi2ssq один в 10 раз медленнее.

По-видимому, версия float использует регистр XMM, загруженный из памяти, в то время как версия int преобразует реальное значение int 0 до float, используя инструкцию cvtsi2ssq, занимая много времени. Передача -O3 в gcc не помогает. (версия gcc 4.2.1.)

(Использование double вместо float не имеет значения, за исключением того, что оно меняет cvtsi2ssq на cvtsi2sdq.)

Обновить

Некоторые дополнительные тесты показывают, что это необязательно инструкция cvtsi2ssq. После устранения (используя int ai=0;float a=ai; и используя a вместо 0), разница в скорости остается. Итак, @Mysticial прав, денормализованные поплавки имеют значение. Это можно увидеть путем тестирования значений между 0 и 0.1f. Точка поворота в приведенном выше коде приблизительно равна 0.00000000000000000000000000000001, когда петли внезапно проходят в 10 раз.

Обновление < 1

Небольшая визуализация этого интересного явления:

Столбец 1: поплавок, разделенный на 2 для каждой итерации
Столбец 2: двоичное представление этого поплавка
Столбец 3: время, затраченное на суммирование этого поплавка 1 раз в 7 раз

Вы можете четко видеть, что показатель экспоненты (последние 9 бит) изменяется до самого низкого значения, когда вводится денормализация. В этот момент простое добавление становится в 20 раз медленнее.

0.000000000000000000000000000000000100000004670110: 10111100001101110010000011100000 45 ms
0.000000000000000000000000000000000050000002335055: 10111100001101110010000101100000 43 ms
0.000000000000000000000000000000000025000001167528: 10111100001101110010000001100000 43 ms
0.000000000000000000000000000000000012500000583764: 10111100001101110010000110100000 42 ms
0.000000000000000000000000000000000006250000291882: 10111100001101110010000010100000 48 ms
0.000000000000000000000000000000000003125000145941: 10111100001101110010000100100000 43 ms
0.000000000000000000000000000000000001562500072970: 10111100001101110010000000100000 42 ms
0.000000000000000000000000000000000000781250036485: 10111100001101110010000111000000 42 ms
0.000000000000000000000000000000000000390625018243: 10111100001101110010000011000000 42 ms
0.000000000000000000000000000000000000195312509121: 10111100001101110010000101000000 43 ms
0.000000000000000000000000000000000000097656254561: 10111100001101110010000001000000 42 ms
0.000000000000000000000000000000000000048828127280: 10111100001101110010000110000000 44 ms
0.000000000000000000000000000000000000024414063640: 10111100001101110010000010000000 42 ms
0.000000000000000000000000000000000000012207031820: 10111100001101110010000100000000 42 ms
0.000000000000000000000000000000000000006103515209: 01111000011011100100001000000000 789 ms
0.000000000000000000000000000000000000003051757605: 11110000110111001000010000000000 788 ms
0.000000000000000000000000000000000000001525879503: 00010001101110010000100000000000 788 ms
0.000000000000000000000000000000000000000762939751: 00100011011100100001000000000000 795 ms
0.000000000000000000000000000000000000000381469876: 01000110111001000010000000000000 896 ms
0.000000000000000000000000000000000000000190734938: 10001101110010000100000000000000 813 ms
0.000000000000000000000000000000000000000095366768: 00011011100100001000000000000000 798 ms
0.000000000000000000000000000000000000000047683384: 00110111001000010000000000000000 791 ms
0.000000000000000000000000000000000000000023841692: 01101110010000100000000000000000 802 ms
0.000000000000000000000000000000000000000011920846: 11011100100001000000000000000000 809 ms
0.000000000000000000000000000000000000000005961124: 01111001000010000000000000000000 795 ms
0.000000000000000000000000000000000000000002980562: 11110010000100000000000000000000 835 ms
0.000000000000000000000000000000000000000001490982: 00010100001000000000000000000000 864 ms
0.000000000000000000000000000000000000000000745491: 00101000010000000000000000000000 915 ms
0.000000000000000000000000000000000000000000372745: 01010000100000000000000000000000 918 ms
0.000000000000000000000000000000000000000000186373: 10100001000000000000000000000000 881 ms
0.000000000000000000000000000000000000000000092486: 01000010000000000000000000000000 857 ms
0.000000000000000000000000000000000000000000046243: 10000100000000000000000000000000 861 ms
0.000000000000000000000000000000000000000000022421: 00001000000000000000000000000000 855 ms
0.000000000000000000000000000000000000000000011210: 00010000000000000000000000000000 887 ms
0.000000000000000000000000000000000000000000005605: 00100000000000000000000000000000 799 ms
0.000000000000000000000000000000000000000000002803: 01000000000000000000000000000000 828 ms
0.000000000000000000000000000000000000000000001401: 10000000000000000000000000000000 815 ms
0.000000000000000000000000000000000000000000000000: 00000000000000000000000000000000 42 ms
0.000000000000000000000000000000000000000000000000: 00000000000000000000000000000000 42 ms
0.000000000000000000000000000000000000000000000000: 00000000000000000000000000000000 44 ms

Эквивалентное обсуждение ARM можно найти в Stack Вопрос переполнения Денормализованная плавающая запятая в Objective-C?.

mvds 16 фев. 2012, в 16:40

23

-O не исправить это, но -ffast-math делает. (Я использую это все время, IMO в тех случаях, когда это вызывает проблемы с точностью, в любом случае не должно появляться в правильно разработанной программе.)
leftaroundabout 17 фев. 2012, в 10:17
0

С gcc-4.6 нет конверсии на любом положительном уровне оптимизации.
Jed 11 март 2012, в 16:14
0

@leftaroundabout: компиляция исполняемого файла (а не библиотеки) с помощью -ffast-math связывает некоторый дополнительный стартовый код, который устанавливает FTZ (сброс на ноль) и DAZ (ненормальный - ноль) в MXCSR, поэтому ЦП никогда не приходится выполнять медленную помощь по микрокоду для ненормальных.
Peter Cordes 16 янв. 2019, в 10:23

Показать ещё 1 комментарий

31

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

Возможно, не работает в некоторых средах GCC:
```
// Requires #include <fenv.h>
fesetenv(FE_DFL_DISABLE_SSE_DENORMS_ENV);
```

Возможно, не работает в некоторых средах Visual Studio: 1

// Requires #include <xmmintrin.h>
_mm_setcsr( _mm_getcsr() | (1<<15) | (1<<6) );
// Does both FTZ and DAZ bits. You can also use just hex value 0x8040 to do both.
// You might also want to use the underflow mask (1<<11)

Появляется для работы как в GCC, так и в Visual Studio:

// Requires #include <xmmintrin.h>
// Requires #include <pmmintrin.h>
_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
_MM_SET_DENORMALS_ZERO_MODE(_MM_DENORMALS_ZERO_ON);

У компилятора Intel есть опции для дезактивации денонсаций по умолчанию на современных процессорах Intel. Подробнее здесь
Коммутаторы компилятора. -ffast-math, -msse или -mfpmath=sse будут отключать денормалы и делать несколько других вещей быстрее, но, к сожалению, также много других приближений, которые могут нарушить ваш код. Тестовый тест! Эквивалент быстрой математики для компилятора Visual Studio составляет /fp:fast, но я не смог подтвердить, что это также отключает денормалы. 1

fig 26 фев. 2014, в 13:12

0

Это звучит как приличный ответ на другой, но связанный вопрос (как я могу предотвратить численные вычисления, чтобы получить ненормальные результаты?) Однако он не отвечает на этот вопрос.
Ben Voigt 21 июнь 2014, в 21:28
0

@BenVoigt IFTFY
vaxquis 23 июль 2014, в 15:45
0

Windows X64 пропускает настройку резкого снижения производительности при запуске .exe, а Windows 32-bit и linux - нет. В linux gcc -ffast-math должен устанавливать резкое понижение (но я думаю, что не в Windows). Предполагается, что компиляторы Intel инициализируются в main (), чтобы эти различия в ОС не проходили, но я был укушен, и мне нужно явно указать это в программе. Предполагается, что процессоры Intel, начинающиеся с Sandy Bridge, будут эффективно обрабатывать субнормалы, возникающие при сложении / вычитании (но не делении / умножении), поэтому есть смысл использовать постепенное понижение.
tim18 11 июнь 2016, в 20:03
1

Microsoft / fp: fast (не по умолчанию) не выполняет никаких агрессивных действий, присущих gcc -ffast-math или ICL (по умолчанию) / fp: fast. Это больше похоже на ICL / fp: source. Поэтому вы должны явно установить / fp: (и, в некоторых случаях, режим недостаточного заполнения), если хотите сравнить эти компиляторы.
tim18 11 июнь 2016, в 20:09

Показать ещё 2 комментария

19

В gcc вы можете включить FTZ и DAZ с этим:

#include <xmmintrin.h>

#define FTZ 1
#define DAZ 1   

void enableFtzDaz()
{
    int mxcsr = _mm_getcsr ();

    if (FTZ) {
            mxcsr |= (1<<15) | (1<<11);
    }

    if (DAZ) {
            mxcsr |= (1<<6);
    }

    _mm_setcsr (mxcsr);
}

также использовать gcc-переключатели: -msse -mfpmath = sse

(соответствующие кредиты Карлу Хетерингтону [1])

[1] http://carlh.net/plugins/denormals.php

German Garcia 02 окт. 2012, в 05:45

0

Также смотрите fesetround() из fenv.h (определено для C99) для другого, более переносимого способа округления ( linux.die.net/man/3/fesetround ) (но это повлияет на все операции FP, а не только на подчиненные )
German Garcia 02 окт. 2012, в 13:52
0

Вы уверены, что вам нужно 1 << 15 и 1 << 11 для ЗСТ? Я видел только 1 << 15 цитируется в другом месте ...
fig 26 фев. 2014, в 11:45
0

@fig: 1 << 11 - для маски переполнения. Более подробная информация здесь: softpixel.com/~cwright/programming/simd/sse.php
German Garcia 26 фев. 2014, в 16:29
0

@GermanGarcia это не отвечает на вопрос ОП; вопрос был «Почему этот бит кода работает в 10 раз быстрее, чем ...» - вы должны либо попытаться ответить на этот вопрос, прежде чем предоставлять этот обходной путь, либо указать это в комментарии.
vaxquis 24 июль 2014, в 23:41

Показать ещё 2 комментария

3

Комментарий Дана Нили должен быть расширен в ответ:

Это не нулевая константа 0.0f которая денормализована или вызывает замедление, это значения, которые приближаются к нулю на каждой итерации цикла. По мере того, как они приближаются к нулю, им нужно больше точности для представления, и они становятся денормализованными. Это значения y[i]. (Они приближаются к нулю, потому что x[i]/z[i] меньше 1,0 для всех i.)

Принципиальная разница между медленной и быстрой версиями кода заключается в выражении y[i] = y[i] + 0.1f; , Как только эта строка выполняется при каждой итерации цикла, дополнительная точность в плавающей запятой теряется, и денормализация, необходимая для представления этой точности, больше не нужна. После этого операции с плавающей запятой на y[i] остаются быстрыми, потому что они не денормализованы.

Почему лишняя точность теряется при добавлении 0.1f? Потому что числа с плавающей запятой имеют только столько значащих цифр. Скажем, у вас достаточно памяти для трех значащих цифр, затем 0.00001 = 1e-5 и 0.00001 + 0.1 = 0.1, по крайней мере, для этого примера формата с плавающей запятой, поскольку в нем нет места для хранения 0.10001 бита в 0.10001.

Короче говоря, y[i]=y[i]+0.1f; y[i]=y[i]-0.1f; y[i]=y[i]+0.1f; y[i]=y[i]-0.1f; разве вы не думаете, что это не так?

Мистик сказал и это: имеет значение содержание float, а не только код сборки.

remicles2 01 авг. 2018, в 15:16

Ещё вопросы

Убедитесь, что вы создаете сборку релиза, а не отладку.
0 является целочисленным литералом, поэтому возможно, что он должен быть преобразован в число с плавающей точкой во время выполнения.
Как вы измерили разницу? А какие опции вы использовали при компиляции?
Почему в этом случае компилятор просто не удаляет +/- 0?!?
Это тесно связано с проблемой в stackoverflow.com/questions/5180150/…
@ Zyx2000 Компилятор не так уж и глуп. Разборка тривиального примера в LINQPad показывает, что он выдает один и тот же код независимо от того, используете ли вы 0 , 0f , 0d или даже (int)0 в контексте, где требуется double .
@ Otto Allmendinger уровень оптимизации, который я использовал, был 02 с включенным sse2
@Dragarro - Просто любопытно - как ты закончил писать и синхронизировать этот код?
@Vic Я просто дурачился, когда заметил это, просто синхронизировал разные функции и проверял разные флаги оптимизации компилятора. Сначала в коде была только часть умножения и деления, и я подумал о том, чтобы добавить сложение и вычитание, просто чтобы посмотреть, сколько дополнительного времени это займет, и, к моему удивлению, код ускорился в 10 раз. Я проверил, чтобы увидеть если я написал что-то странное, а потом я опубликовал это здесь, чтобы посмотреть, не пропустил ли я что-то.
@HamidNazari - онлайн-паста для различий - отличная идея, но, похоже, она выплевывает «не удается открыть файл». По умолчанию он выглядит как «Не хранить diff», я выбрал «хранить навсегда», и он дал мне эту ссылку: diffchecker.com/U6w74qj
Почему на самом деле компилятор не сбрасывает +/- 0?
-O не исправить это, но -ffast-math делает. (Я использую это все время, IMO в тех случаях, когда это вызывает проблемы с точностью, в любом случае не должно появляться в правильно разработанной программе.)
С gcc-4.6 нет конверсии на любом положительном уровне оптимизации.
@leftaroundabout: компиляция исполняемого файла (а не библиотеки) с помощью -ffast-math связывает некоторый дополнительный стартовый код, который устанавливает FTZ (сброс на ноль) и DAZ (ненормальный - ноль) в MXCSR, поэтому ЦП никогда не приходится выполнять медленную помощь по микрокоду для ненормальных.
Это звучит как приличный ответ на другой, но связанный вопрос (как я могу предотвратить численные вычисления, чтобы получить ненормальные результаты?) Однако он не отвечает на этот вопрос.
Windows X64 пропускает настройку резкого снижения производительности при запуске .exe, а Windows 32-bit и linux - нет. В linux gcc -ffast-math должен устанавливать резкое понижение (но я думаю, что не в Windows). Предполагается, что компиляторы Intel инициализируются в main (), чтобы эти различия в ОС не проходили, но я был укушен, и мне нужно явно указать это в программе. Предполагается, что процессоры Intel, начинающиеся с Sandy Bridge, будут эффективно обрабатывать субнормалы, возникающие при сложении / вычитании (но не делении / умножении), поэтому есть смысл использовать постепенное понижение.
Microsoft / fp: fast (не по умолчанию) не выполняет никаких агрессивных действий, присущих gcc -ffast-math или ICL (по умолчанию) / fp: fast. Это больше похоже на ICL / fp: source. Поэтому вы должны явно установить / fp: (и, в некоторых случаях, режим недостаточного заполнения), если хотите сравнить эти компиляторы.
Также смотрите fesetround() из fenv.h (определено для C99) для другого, более переносимого способа округления ( linux.die.net/man/3/fesetround ) (но это повлияет на все операции FP, а не только на подчиненные )
Вы уверены, что вам нужно 1 << 15 и 1 << 11 для ЗСТ? Я видел только 1 << 15 цитируется в другом месте ...
@fig: 1 << 11 - для маски переполнения. Более подробная информация здесь: softpixel.com/~cwright/programming/simd/sse.php
@GermanGarcia это не отвечает на вопрос ОП; вопрос был «Почему этот бит кода работает в 10 раз быстрее, чем ...» - вы должны либо попытаться ответить на этот вопрос, прежде чем предоставлять этот обходной путь, либо указать это в комментарии.

Mysticial · Accepted Answer · 2012-02-16T17-10-00.000Z

1506

Лучший ответ

Добро пожаловать в мир denormalized floating-point! Они могут нанести ущерб производительности!!! p >

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

Если вы распечатываете номера после 10 000 итераций, вы увидите, что они сходились к разным значениям в зависимости от того, используется ли 0 или 0.1.

Здесь тестовый код, скомпилированный на x64:

int main() {

    double start = omp_get_wtime();

    const float x[16]={1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8,1.9,2.0,2.1,2.2,2.3,2.4,2.5,2.6};
    const float z[16]={1.123,1.234,1.345,156.467,1.578,1.689,1.790,1.812,1.923,2.034,2.145,2.256,2.367,2.478,2.589,2.690};
    float y[16];
    for(int i=0;i<16;i++)
    {
        y[i]=x[i];
    }
    for(int j=0;j<9000000;j++)
    {
        for(int i=0;i<16;i++)
        {
            y[i]*=x[i];
            y[i]/=z[i];
#ifdef FLOATING
            y[i]=y[i]+0.1f;
            y[i]=y[i]-0.1f;
#else
            y[i]=y[i]+0;
            y[i]=y[i]-0;
#endif

            if (j > 10000)
                cout << y[i] << "  ";
        }
        if (j > 10000)
            cout << endl;
    }

    double end = omp_get_wtime();
    cout << end - start << endl;

    system("pause");
    return 0;
}

Вывод:

#define FLOATING
1.78814e-007  1.3411e-007  1.04308e-007  0  7.45058e-008  6.70552e-008  6.70552e-008  5.58794e-007  3.05474e-007  2.16067e-007  1.71363e-007  1.49012e-007  1.2666e-007  1.11759e-007  1.04308e-007  1.04308e-007
1.78814e-007  1.3411e-007  1.04308e-007  0  7.45058e-008  6.70552e-008  6.70552e-008  5.58794e-007  3.05474e-007  2.16067e-007  1.71363e-007  1.49012e-007  1.2666e-007  1.11759e-007  1.04308e-007  1.04308e-007

//#define FLOATING
6.30584e-044  3.92364e-044  3.08286e-044  0  1.82169e-044  1.54143e-044  2.10195e-044  2.46842e-029  7.56701e-044  4.06377e-044  3.92364e-044  3.22299e-044  3.08286e-044  2.66247e-044  2.66247e-044  2.24208e-044
6.30584e-044  3.92364e-044  3.08286e-044  0  1.82169e-044  1.54143e-044  2.10195e-044  2.45208e-029  7.56701e-044  4.06377e-044  3.92364e-044  3.22299e-044  3.08286e-044  2.66247e-044  2.66247e-044  2.24208e-044

Обратите внимание, что во втором прогоне числа очень близки к нулю.

Денормализованные числа обычно редки и, следовательно, большинство процессоров не пытаются эффективно их обрабатывать.

Чтобы продемонстрировать, что это имеет все, что связано с денормализованными числами, если сбросить денормалы до нуля, добавив это в начало кода:

_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);

Затем версия с 0 перестает быть на 10x медленнее и на самом деле становится быстрее. (Это требует, чтобы код был скомпилирован с включенным SSE.)

Это означает, что вместо того, чтобы использовать эти странные значения почти нулевой точности, мы просто округлим до нуля.

Сроки: Core i7 920 @3,5 ГГц:

//  Don't flush denormals to zero.
0.1f: 0.564067
0   : 26.7669

//  Flush denormals to zero.
0.1f: 0.587117
0   : 0.341406

В конце концов, это действительно не имеет никакого отношения к тому, является ли это целым числом или плавающей точкой. 0 или 0.1f преобразуется/сохраняется в регистре вне обеих петель. Таким образом, это не влияет на производительность.

Mysticial 16 фев. 2012, в 17:10

0

Единственная разница в сгенерированном коде - это fld qword ptr [__real@3fb99999a0000000 (11820E8h)] для быстрой версии и, fldz в начале цикла, по крайней мере для моей сборки в VS2010
Dervall 16 фев. 2012, в 16:27
3

@Dervall Это правильно. Там нет почти никакой разницы в коде. Это значение, которое влияет на денормализацию чисел или нет.
Mysticial 16 фев. 2012, в 16:30
5

Это особенно интересно, потому что последовательность, которая меняет вещи, в основном x += 0.1; x -= 0.1 , что также можно записать (x + 0.1) - 0.1 . Отмечается отсутствие ассоциативности. (Конечно, такое переписывание может изменить результаты, поскольку C ++ позволяет сохранять промежуточные результаты с повышенной точностью.)
James Kanze 16 фев. 2012, в 17:58
94

Я все еще нахожу немного странным, что компилятор по умолчанию не полностью оптимизировал "+ 0". Случилось бы это, если бы он поставил «+ 0.0f»?
s73v3r 16 фев. 2012, в 19:10
45

@ s73v3r Это очень хороший вопрос. Теперь, когда я смотрю на сборку, даже + 0.0f не оптимизируется. Если бы мне пришлось угадывать, могло бы случиться так, что у + 0.0f были бы побочные эффекты, если бы y[i] оказался сигнальным NaN или чем-то ... Хотя я могу ошибаться.
Mysticial 16 фев. 2012, в 19:31
0

Как производительность, если вы убираете сложение / вычитание? Я не удивлюсь, если это все еще дорого, потому что умножение / деление дороже для поднорм.
CodesInChaos 16 фев. 2012, в 20:05
3

@CodeInChaos Да, это все еще дорого, но всего 13.3208 секунды, а не 26.7669 . Числа все еще идут ненормально. Но я предполагаю, что поскольку операций всего вдвое меньше, это в два раза быстрее. Для меня несколько удивительно, что денормальное деление, кажется, происходит так же медленно, как и ненормальное сложение / вычитание.
Mysticial 16 фев. 2012, в 20:21
1

Итак ... что должен делать программист, который заботится о производительности, когда в него входят нулевые числа?
Chriszuma 16 фев. 2012, в 21:19
1

@Chriszuma, здесь проблема не в нулевых значениях, а в ненулевых денормалях. Если вам не нужно делать арифметику с супер крошечными числами, то сбрасывайте денормалы в ноль. Если вам нужно работать с такими маленькими числами, то, вероятно, быстрее использовать удвоения на большинстве платформ.
user57368 16 фев. 2012, в 21:44
13

Двойники все равно столкнутся с той же проблемой во многих случаях, но с другой числовой величиной. Сброс в ноль хорош для аудио приложений (и других, где вы можете позволить себе потерять 1e-38 здесь и там), но я считаю, что это не относится к x87. Без FTZ обычное решение для звуковых приложений состоит в том, чтобы вводить сигнал с очень низкой амплитудой (не слышимый) постоянного тока или прямоугольный сигнал в числа джиттера вдали от ненормальности.
Russell Borogove 17 фев. 2012, в 00:12
0

@RussellBorogove: Интересно, есть ли в каких-либо аппаратных разработках режим, который заставляет LSB усекать значения около нуля, чтобы избежать необходимости странно обрабатывать денормализованные значения?
supercat 17 фев. 2012, в 04:13
2

Примерно в 1998/1999 году я играл с плагинами для Jeskola Buzz. Для этого я обновился с Pentium 166MMX до Pentium 3 500MHz. Часть знаний тогда заключалась в том, что, когда значения упадут очень близко к нулю, «исключения из-за недостаточного потока» вызовут серьезное замедление - даже если отключено прерывание / прерывание / что-либо еще, это все равно вызовет большое замедление. Исправление состояло в том, чтобы заставить почти нулевые значения к нулю. Было ли это знание неправильно? Была ли это проблема денормализованных поплавков?
Steve314 17 фев. 2012, в 07:39
1

Если оставить в стороне производительность, почему y[i] = (y[i] + 0.1f) - 0.1f даже приводит к значению, отличному от y[i] = (y[i] + 0) - 0 ?
Isaac 17 фев. 2012, в 11:09
16

@Isaac, потому что, когда y [i] значительно меньше 0,1, добавление приводит к потере точности, поскольку наиболее значимая цифра в числе становится выше.
Dan Neely 17 фев. 2012, в 13:28
3

Это вызывает любопытство: есть ли у вас примеры того, как поставщики оборудования проводят эффективные денормальные вычисления?
nraynaud 17 фев. 2012, в 14:10
0

@supercat, если я правильно тебя понял, это, по сути, то, что такое «сброс на ноль».
Russell Borogove 17 фев. 2012, в 18:27
4

@ Steve314, знания, скажем, неточные. IEEE754 определяет «исключение недостаточного потока» для денормализованных чисел; если аппаратное обеспечение не может точно обрабатывать денормс, вместо этого оно должно вызывать исключение, но x87 действительно обрабатывает денормалы медленно, без возбуждения исключения.
Russell Borogove 17 фев. 2012, в 18:28
6

@nraynaud, новая микроархитектура Intel Sandy Bridge прекрасно справляется с денормализацией - по словам Агнера Фога, на полной скорости. agner.org/optimize/blog/read.php?i=142
Russell Borogove 17 фев. 2012, в 18:29
2

@RussellBorogove: как я понимаю, в системе сброса на ноль разница между наименьшим и вторым наименьшим положительным числом составляет крошечную долю от величины наименьшего числа. Добавление ненормальных в систему уменьшает величину наименьшего числа, чтобы соответствовать наименьшему измеримому отклонению между числами. Я бы посоветовал увеличить минимальную разницу между числами, чтобы она соответствовала наименьшему нормализованному числу. Это гарантировало бы, что если x! = Y, разница между x + (yx) и y будет иметь меньшую величину, чем разница между x и y.
supercat 17 фев. 2012, в 19:27
0

@RussellBorogove: В то время как обработка ненормированных значений требует добавления сложности ко всем аспектам обработки чисел с плавающей запятой, ограничение точности младших битов (на самом деле это должно быть сделано с помощью округления, а не усечения) потребует дополнительной логики только в одном месте. Вместо того, чтобы всегда округлять до одного мантиссы-LSB, иногда приходилось округлять до более грубого уровня.
supercat 17 фев. 2012, в 19:34
0

Имеет ли это какое-либо отношение к Obj-C. Я предполагаю, что ответом будет «возможно, сами сравните это?» Или это не может быть применено в Objective-C по какой-то причине ...?
Dan Rosenstark 18 фев. 2012, в 07:18
6

@Yar: это больше проблема процессора, чем языка, поэтому он, вероятно, имеет отношение к Obj-C на x86. (iPhone armv7, похоже, не поддерживает денормализованные поплавки, по крайней мере с настройками времени выполнения / сборки по умолчанию)
mvds 18 фев. 2012, в 11:56
4

@RussellBorogove У меня здесь есть процессор Sandy Bridge (i7-2620M), и я не могу наблюдать эту эффективность - я вижу 22-кратное замедление с gcc 4.6.1 и g++ -O3 -march=corei7-avx 9314534.cpp . Аналогичные результаты со всеми опциями компилятора, которые я пробовал.
je4d 23 фев. 2012, в 21:30
1

@ je4d Я заметил это и на своем 2600K. И это идет вразрез с тем, что говорит Агнер Фог. Сначала я подозревал, что, возможно, разделение все еще чувствительно к ненормальным. Но удаление деления (и умножение на обратную величину z[i] вместо этого) приводит к замедлению в 96 раз до ненормальных значений !!!
Mysticial 23 фев. 2012, в 21:47
0

@Mysticial все мои результаты поиска в Google по snb и денормализованным FP приводят к этой статье Agner Fog. Я также пробовал различные параметры компилятора (например, -mfpmath = ..., -mfast-math) со времени моего последнего комментария, и я не могу найти где 1: -DFLOATING не делает это быстрее и 2) результаты без -DFLOATING являются правильными. Так что AFAICS, претензия просто фальшивая.
je4d 23 фев. 2012, в 22:03
0

Интересно. Вы видите это на x87, SSE или на обоих?
Russell Borogove 23 фев. 2012, в 22:28
0

@RussellBorogove Я тестировал x87 в 32-битном режиме и SSE в 64-битном режиме. Те же результаты. Огромные замедления к денормалам как с разделением, так и без него. ~ 25x с делением и ~ 100x без деления.
Mysticial 23 фев. 2012, в 22:34
0

Понятия не имею, что случилось тогда. Вы можете связаться с Fog, если хотите разобраться.
Russell Borogove 23 фев. 2012, в 22:39
0

@RussellBorogove Я делаю только 64-битные, и я вижу замедление как для 387 (50x), так и для sse (14.5x) с двойными числами - аналогичные числа для чисел с плавающей запятой.
je4d 23 фев. 2012, в 23:10
0

@mvds Просто чтобы подтвердить, что это не единственная вещь компилятора, я могу видеть то же самое замедление в Delphi.
EMBarbosa 12 март 2012, в 13:21
8

Даунвотерс хочет прокомментировать?
Mysticial 14 март 2012, в 20:49
144

@ s73v3r: + 0.f нельзя оптимизировать, поскольку с плавающей запятой имеет отрицательный 0, а результат добавления + 0.f к -.0f равен + 0.f. Таким образом, добавление 0.f не является операцией идентификации и не может быть оптимизировано.
Eric Postpischil 06 июль 2012, в 17:59
0

Утверждение Фога о том, что денормали не увеличивают латентность, поскольку Sandy Bridge кажется довольно неправильным. Может быть, со времен Скайлэйк это правильно, но уж точно не на Хасвелле.
hdl 17 дек. 2015, в 16:28
2

@hdl Туман первоначально утверждал, что у Сэнди Бридж не было ненормальных замедлений. Но после того, как этот вопрос стал популярным, я думаю, что кто-то уведомил его, и он перепроверил. Вердикт был без замедления для сложений / вычитаний. Но все еще огромное замедление для умножений.
Mysticial 17 дек. 2015, в 20:34
0

@Mysticial Ну, он по- прежнему утверждает, что «ненормальные числа, NAN и бесконечность не увеличивают задержку». в декабре 2014 года PDF «Таблицы инструкций» для Sandy Bridge, Ivy Bridge и Haswell.
hdl 18 дек. 2015, в 10:49
0

@Eric Postpischil Оптимизация даже не проблема. Проблема возникает, даже если вы удалите дополнение полностью. Это связано с делением, что числа становятся денормализованными.
user32434999 18 июль 2018, в 13:02
0

@Pi: комментарий, на который вы отвечаете, не относится к исходной проблеме, опубликованной здесь, в которой ненормальные цифры приводили к снижению производительности. Речь идет о проблеме, поднятой s73v3r относительно того, почему добавление 0 не удаляется во время оптимизации.
Eric Postpischil 18 июль 2018, в 20:09

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