Каковы приложения / преимущества 80-битного расширенного точного типа данных?
Да, я хотел сказать 80-бит. Это не опечатка...
мой опыт работы с переменными с плавающей запятой всегда включал 4-байтовые кратные, такие как одиночные (32 бит), двойные (64 бит) и длинные двойные (которые, как я видел, ссылались на 96-бит или 128-бит). Вот почему я был немного смущен, когда наткнулся на 80-битный расширенный тип данных точности пока я работал над некоторым кодом для чтения и записи в AIFF (формат файла обмена аудио) файлы: для хранения частоты дискретизации звуковой дорожки была выбрана расширенная переменная точности.
когда я просмотрел Википедию, я нашел ссылку выше вместе с кратким упоминанием 80-битных форматов в стандарт IEEE 754-1985 резюме (но не в стандарт IEEE 754-2008 резюме). Похоже, что на некоторых архитектурах "extended" и "long double" являются синонимами.
одно мне не попадались конкретные приложения, использующие расширенные типы данных точности (за исключением, конечно, частоты дискретизации файлов AIFF). Это заставило меня задуматься:--3-->
- кто-нибудь сталкивался с ситуацией, когда расширенная точность была необходима/полезна для некоторых приложений программирования?
- каковы преимущества 80-битного числа с плавающей запятой, кроме очевидного "это немного больше точности, чем двойной, но меньше байтов, чем большинство реализаций длинного двойной"?
- его применимость уменьшается?
6 ответов
FPUs Intel используют 80-битный формат внутри, чтобы получить больше точности для промежуточных результатов.
то есть у вас могут быть 32-разрядные или 64-разрядные переменные, но когда они загружаются в регистры FPU, они преобразуются в 80 бит; FPU затем (по умолчанию) выполняет все вычисления в 80 но; после вычисления результат сохраняется обратно в 32-разрядные или 64-разрядные переменные.
BTW-несколько неудачным следствием этого является то, что сборки отладки и выпуска может дать несколько иные результаты: в сборке выпуска оптимизатор может хранить промежуточную переменную в 80-битном регистре FPU, в то время как в сборке отладки она будет храниться в 64-битной переменной, что приведет к потере точности. Вы можете избежать этого, используя 80-разрядные переменные, или использовать переключатель FPU (или параметр компилятора) для выполнения всех вычислений в 64-разрядной версии.
для меня важно использовать 80 бит. Таким образом, я получаю собственные значения высокого порядка (30 000) и собственные векторы симметричных матриц с еще четырьмя цифрами при использовании библиотеки GOTO для векторных внутренних продуктов, а именно., 13 вместо 9 значимые цифры для типа матриц, которые я использую в релятивистских атомных расчетах, что необходимо, чтобы избежать падения в море отрицательных энергетических состояний. Мой другой вариант - использовать арифметику с четырехкратной точностью, которая увеличивает время процессора в 60-70 раз а также увеличивает требования к ОЗУ. Любой расчет, основанный на внутренних произведениях больших векторов, принесет пользу. Конечно, чтобы сохранить частичные внутренние результаты продукта в регистрах, необходимо использовать язык ассемблера, как в библиотеках GOTO. Вот как я полюбил мои старые процессоры Opteron 850, которые я буду использовать до тех пор, пока они длятся для этой части моих вычислений.
причина 80 бит быстра, тогда как большая точность настолько медленнее, что Стандартное оборудование CPU с плавающей запятой имеет 80-битные регистры. Поэтому, если вы хотите дополнительные 16 бит (11 дополнительных бит мантиссы, четыре дополнительных бита экспоненты и один дополнительный бит эффективно не используется), то это не стоит вам много, чтобы расширить от 64 до 80 бит-в то время как расширение за 80 бит чрезвычайно дорого с точки зрения времени выполнения. Таким образом, вы можете также использовать 80-битную точность, если хотите. Это не бесплатно использовать, но это довольно дешево.
Википедия объясняет, что 80-битный формат может представлять целое 64-разрядное целое число без потери информации. Таким образом, блок с плавающей запятой CPU может использоваться для реализации умножения и деления целых чисел.
еще одно преимущество, еще не упомянул, для 80-битных типов заключается в том, что в 16-битные или 32-битные процессоры, которые не имеют плавающей точкой, единицы, но есть "умножить" инструкция, которая дает результат в два раза длиннее операндов (размером 16x16->32 или 32x32->64), арифметические операции над 64-разрядной мантиссы подразделяется на четыре или два 16-разрядных или 32-разрядных регистров будет быстрее, чем арифметика на 53-разрядной мантиссы, которые охватывает то же количество регистров, но поделиться 12 битов регистра со знаком и экспоненты. Для приложений, которым не нужно ничего более точного, чем float, вычисления на 48-битном типе "extended float" также могут быть быстрее, чем вычисления на 32-битном float.
в то время как некоторые люди могут оплакивать поведение двойного округления типов расширенной точности, это реально говоря, только проблема в специализированных приложениях, требующих полной бит-точной кросс-платформенной воспроизводимости. С точность точки зрения, разница между ошибка округления 64/128 против 65/128 или 1024 / 2048ulp против 1025/2048 не является проблемой; в языках с типы переменных расширенной точности и последовательная семантика расширенной точности, польза выдвинутых типов на много платформ без оборудования с плавающей запятой (например врезанных систем) предложит и более высокую точность и лучшую скорость чем типы с плавающей запятой одиночн - или двойн-точности.
я использовал 80-бит для некоторых чисто математических исследований. Мне пришлось суммировать члены в бесконечном ряду, который вырос довольно большим, вне диапазона двойников. Сходимость и точность не были проблемами, просто способность обрабатывать большие показатели, такие как 1E1000. Возможно, какая-нибудь умная алгебра могла бы все упростить, но гораздо быстрее и проще было просто закодировать алгоритм с расширенной точностью, чем тратить время на размышления об этом.
У меня есть друг, который работает в этом. Он работает над библиотекой для обработки плавающих точек размером с гигабайт. Конечно, это что-то связанное с научными вычислениями(расчеты с плазмой), и, вероятно, только этот вид вычислений работает с такими большими числами...