#c #c #floating-point
#c #c #с плавающей запятой
Вопрос:
Я работаю над приложением, в котором скорость выполнения важнее точности. Обработка чисел включает в себя арифметику с плавающей запятой, и я обеспокоен тем, что double и / или long double обрабатывается программно, а не изначально на процессоре (это всегда верно для 32-разрядной arch, верно?). Я хотел бы выполнить условную компиляцию с использованием наивысшей точности с аппаратной поддержкой, но я не нашел быстрого и простого способа обнаружения программной эмуляции. Я использую g в GNU / Linux, и меня не беспокоит переносимость. Он работает на x86 arch, поэтому я предполагаю, что он float всегда является встроенным.
Комментарии:
1. Почему у людей есть эта мистическая вера в то, что «float» является родным, быстрее, лучше?
2. @unapersson: Спрашивающий на 9 лет моложе 8087. Это ужасно.
3. @unapersson: вероятно, потому, что это верно для некоторых архитектур (и потому, что это очень часто имеет место для целочисленных типов данных)
4. @Steve Да, я помню, как я купил (или, скорее, мой работодатель купил меня) свой первый сопроцессор 8087, когда это был отдельный чип, и дрожащими руками (уверен, что я собирался сломать контакты этого очень дорогого устройства) Я вставил его в сокет copro моего IBM XT. Это требовалось для компилятора Lahey F77, который не выполнял эмуляцию FP. Счастливых дней! Конечно, в то время я также жил в hole in the highway.
5. @jalf что обычно происходит с целыми числами?
Ответ №1:
Модуль с плавающей запятой (FPU) на современном x86 изначально равен double (фактически, он даже больше, чем double), а не float («32» в 32-разрядном формате описывает ширину регистра целых чисел, а не ширину с плавающей запятой). Однако это неверно, если ваш код использует векторизованные инструкции SSE, которые выполняют либо 4 одиночные, либо 2 двойные операции параллельно.
Если нет, то основное снижение скорости при переключении приложения с float на double будет связано с увеличением пропускной способности памяти.
Ответ №2:
(это всегда верно для 32-разрядной arch, верно?)
Нет. У обычных процессоров есть специальное оборудование для double (а в некоторых случаях long double также). И, честно говоря, если вас беспокоит производительность, то вы должны знать свой процессор. Загляните в руководства по процессору и выясните, каково снижение производительности для каждого типа данных.
Даже на процессорах, которым не хватает «надлежащей» double поддержки, это все еще не эмулируется программным обеспечением. Процессор Cell (известный Playstation 3) просто double дважды пропускает a через FPU, так что это намного дороже, чем float вычисления, но это не программная эмуляция. У вас все еще есть специальные инструкции для double обработки. Они просто менее эффективны, чем эквивалентные float инструкции.
Если вы не ориентируетесь на процессоры 20-летней давности или небольшие встроенные процессоры с ограниченным объемом, инструкции с плавающей запятой будут обрабатываться аппаратно, хотя не все архитектуры одинаково эффективно обрабатывают все типы данных
Комментарии:
1. Кто-нибудь может объяснить, почему это было отклонено? Я сказал что-нибудь неправильное?
Ответ №3:
x86 делает float , double и многое другое в аппаратном обеспечении, и делала это долгое время. Многие современные 32-разрядные программы предполагают поддержку SSE2, поскольку она существует уже несколько лет и может быть установлена на потребительский чип.
Ответ №4:
На x86 аппаратное обеспечение обычно использует 80 бит внутри, что более чем достаточно для double.
Вы уверены, что производительность действительно вызывает беспокойство (из-за профилирования кода) или просто предполагаете, что она может не поддерживаться?