Не IEEE 754
Как правило, вы не можете. Всегда есть компромисс между последовательностью и производительностью, и C ++ передает это вам.
Для платформ, в которых нет операций с плавающей запятой (например, встроенных процессоров и процессоров обработки сигналов), вы не можете использовать «родные» операции C ++ с плавающей запятой, по крайней мере, не переносимые. Хотя программный уровень был бы возможен, это, конечно, неосуществимо для устройств такого типа.
Для них вы можете использовать 16-битную или 32-битную арифметику с фиксированной точкой (но вы можете даже обнаружить, что long поддерживается только в зачаточном состоянии - и часто div очень дорогой). Однако это будет намного медленнее, чем встроенная арифметика с фиксированной точкой, и станет болезненным после четырех основных операций.
Я не встречал устройств с поддержкой плавающей запятой в другом формате, чем IEEE 754 . Исходя из моего опыта, вам лучше всего надеяться на стандарт, потому что в противном случае вы обычно заканчиваете тем, что строите алгоритмы и кодируете возможности устройства. Когда sin(x) внезапно стоит в 1000 раз дороже, вам лучше выбрать алгоритм, который ему не нужен.
IEEE 754 - Согласованность
Единственная непереносимость, которую я обнаружил здесь, - это когда вы ожидаете идентичные результаты на разных платформах. Наибольшее влияние оказывает оптимизатор. Опять же, вы можете обменять точность и скорость на последовательность. У большинства компиляторов есть возможность для этого - например, «согласованность с плавающей точкой» в Visual C ++. Но учтите, что это всегда точность за пределами гарантий стандарта.
Почему результаты становятся противоречивыми?
Во-первых, регистры FPU часто имеют более высокое разрешение, чем двойные (например, 80 бит), поэтому до тех пор, пока генератор кода не сохранит значение обратно, промежуточные значения сохраняются с более высокой точностью.
Во-вторых, эквивалентности типа a*(b+c) = a*b + a*c не являются точными из-за ограниченной точности. Тем не менее, оптимизатор, если разрешено, может использовать их.
Кроме того, что я усвоил трудным способом - функции печати и синтаксического анализа не обязательно одинаковы для разных платформ, возможно, из-за неточностей в цифрах.
поплавок
Распространено заблуждение, что операции с плавающей запятой по своей природе быстрее, чем удвоение. Работа с большими массивами с плавающей запятой происходит быстрее, обычно за счет меньшего количества пропусков кэша.
Будьте осторожны с точностью поплавка. это может быть «достаточно хорошо» в течение длительного времени, но я часто видел, как он терпел неудачу быстрее, чем ожидалось. БПФ на основе плавающей запятой может быть намного быстрее благодаря поддержке SIMD, но генерировать заметные артефакты довольно рано для обработки звука.