Каковы приложения/преимущества 80-битного расширенного типа данных с высокой точностью?

Да, я хотел сказать 80-битный. Это не опечатка...

Мой опыт работы с переменными с плавающей запятой всегда включал в себя 4-байтные мультиплееры, такие как синглы (32 бит), удваиваемые (64-разрядные) и длинные удвоения (которые я видел как 96-битные или 128-битные). Вот почему я был немного смущен, когда натолкнулся на 80-битный расширенный тип данных точности, когда я работал над некоторым кодом для чтения и записи на файлы формата AIFF (Audio Interchange File Format): для сохранения частоты дискретизации звуковой дорожки была выбрана расширенная прецизионная переменная.

Когда я просмотрел Википедию, я нашел ссылку выше и короткое упоминание о 80-битных форматах в IEEE 754-1985 резюме (но не в стандарте IEEE 754-2008). Похоже, что на некоторых архитектурах "расширенный" и "длинный двойной" являются синонимами.

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

  • Кто-нибудь сталкивался с ситуацией, когда расширенная точность была необходима/полезной для некоторых приложений программирования?
  • В чем преимущества 80-битного числа с плавающей запятой, кроме очевидного, "это немного больше точности, чем двойное, но меньшее количество байтов, чем большинство реализаций длинного двойника"?
  • Является ли его применимость убывающей?

ОТВЕТЫ

Ответ 1

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

То есть у вас могут быть 32-разрядные или 64-битные переменные, но когда они загружаются в регистры FPU, они преобразуются в 80 бит; FPU затем (по умолчанию) выполняет все вычисления в 80, но; после вычисления результат сохраняется обратно в 32-битные или 64-битные переменные.

BTW - Несколько неудачное следствие этого заключается в том, что сборка отладки и выпуска может иметь несколько иные результаты: в сборке релиза оптимизатор может хранить промежуточную переменную в 80-битном регистре FPU, тогда как в сборке отладки это будет храниться в 64-битной переменной, что приведет к потере точности. Вы можете избежать этого, используя 80-битные переменные, или использовать переключатель FPU (или параметр компилятора) для выполнения всех вычислений в 64-разрядной версии.

Ответ 2

Для меня использование 80 бит является ESSENTIAL. Таким образом, я получаю собственные значения и собственные векторы симметричных матриц высокого порядка (30 000) с четырьмя цифрами при использовании библиотеки GOTO для векторных внутренних продуктов, а именно 9 вместо 9 значащих цифр для типов матриц, которые я использую в релятивистских атомах расчеты, необходимые для того, чтобы не попасть в море состояний с отрицательной энергией. В моем другом варианте используется арифметика с четырьмя точками, которая увеличивает время процессора в 60-70 раз, а также увеличивает требования к ОЗУ. Любое вычисление, основанное на внутренних продуктах больших векторов, принесет пользу. Конечно, чтобы сохранить частичные результаты внутреннего продукта внутри регистров, необходимо использовать язык ассемблера, как в библиотеках GOTO. Именно так я полюбил свои старые процессоры Opteron 850, которые я буду использовать до тех пор, пока они продолжатся для этой части моих расчетов.

Причина 80 бит быстрая, тогда как более высокая точность намного медленнее, так это то, что стандартное аппаратное обеспечение с плавающей запятой CPU имеет 80-битные регистры. Поэтому, если вы хотите, чтобы дополнительные 16 бит (11 дополнительных бит мантиссы, четыре дополнительных бита экспоненты и один лишний бит эффективно не использовались), тогда вам не очень нужно расширять от 64 до 80 бит, тогда как для расширения более 80 бит является чрезвычайно дорогостоящим с точки зрения времени выполнения. Таким образом, вы можете использовать 80-битную точность, если хотите. Это не выгодно использовать, но оно довольно дешево.

Ответ 3

Википедия объясняет, что 80-битный формат может представлять целое 64-битное целое число без потери информации. Таким образом, блок с плавающей запятой CPU может использоваться для реализации умножения и деления для целых чисел.

Ответ 4

Еще одно преимущество, еще не упомянутое для 80-битных типов, заключается в том, что на 16-разрядных или 32-разрядных процессорах, которые не имеют блоков с плавающей запятой, но имеют инструкцию "умножить", которая дает результат в два раза дольше, чем операнды (16x16- > 32 или 32x32- > 64), арифметика на 64-битной мантиссе, делящаяся на четыре или два 16-битных или 32-битных регистра, будет быстрее, чем арифметика на 53-битной мантиссе, которая охватывает такое же количество регистры, но должен делиться 12 битами регистра со знаком и показателем. Для приложений, которые не нуждаются в чем-то более точном, чем float, вычисления по 48-битовому "расширенному поплавковому типу" также могли бы быть быстрее, чем вычисления в 32-битном float.

В то время как некоторые люди могут оплакивать поведение с двойным округлением типов с расширенной точностью, это реалистично говорит только о проблеме в специализированных приложениях, требующих полноразмерной кросс-платформенной воспроизводимости. С точки зрения точности разница между ошибкой округления 64/128 против 65/128, или 1024/2048ulp против 1025/2048, не является проблемой; в языках с переменными типами с расширенной точностью и последовательной семантикой расширенной точности использование расширенных типов на многих платформах без аппаратного обеспечения с плавающей запятой (например, встроенные системы) будет предлагать как более высокую точность, так и лучшую скорость, чем с плавающей запятой с одиночной или двойной точностью типы.

Ответ 5

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

Ответ 6

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