Відносні достоїнства обчислення фіксованої точки проти плаваючої точки?


9

У мене є система цифрової обробки сигналів, яка працює на швидкій машині x86, використовуючи подвійні точні числа з плаваючою комою . Мені прийшло в голову, що я не дуже використовую величезний динамічний діапазон подання плаваючої точки - всі величини легко вписуються в діапазон ± 32768.

Моє запитання: чи можливо, що перехід на обчислення з фіксованою точкою дасть перевагу чисельній точності (високий пріоритет) або час обчислень (низький пріоритет)?

Звичайно, відповідь залежить від того, скільки бітів доступно для обчислення з фіксованою точкою. Скільки бітів точності використовують типові системи з фіксованою точкою? Чи можливо ефективно робити обчислення з фіксованою точкою, скажімо, з 64 бітами ( 16 біт цілочисельною частиною, 48 біт дробовою частиною ) на x86-64?

Я завжди думав, що обчислення з фіксованою точкою використовуються лише в ситуаціях, коли потужність процесора обмежена - чи є сенс використовувати обчислення з фіксованою точкою, коли потужність процесора не викликає занепокоєння?


Вам справді потрібно більше, ніж ~ 15 значущих цифр, які дає двозначна точність з плаваючою комою? Хоча широкі узагальнення погані, я б сказав, що якби ви подивилися на сукупність усіх систем DSP з фіксованою точкою, 16-бітові цілі числа, ймовірно, будуть найпоширенішим форматом.
Джейсон Р.

Відповіді:


7

Числова точність цілих чисел буде кращою, ніж числова точність поплавків, якщо краща роздільна здатність буде кращою. У парних 52 дробових біта, тому поплавці подвійної точності мають роздільну здатність гірше, ніж цілі числа252, що значно більше 32768 (215). Отже, ні, числова точність не буде кращою, якщо ви перейдете до цілих чисел.

Друге питання - швидкість. Відповідь: це залежить від обладнання. Якщо ви запускаєте свою програму на цифровому сигнальному процесорі, який має декілька фіксованих / накопичуючих ядер, то так, це буде набагато швидше у фіксованій точці. З іншого боку, на чіпі x86 він, ймовірно, буде повільніше у фіксованій точці. Я зробив саме те, про що ви зараз говорили, і побачив, що час моїх страт збільшився.

Після деяких пошуків в Інтернеті я з'ясував, що це звичайне явище. Причина полягає в тому, що у нього є виділений процесор з плаваючою комою, який нічого не робить при переході на фіксовану точку, тоді як апаратне забезпечення з фіксованою точкою ділиться звичайними діями з фіксованою точкою, такими як арифметика вказівника.

Якщо ви хочете прискорити обробку, спосіб зробити це - перейти від поплавців подвійної точності до одноточних поплавців. Це повинно призвести до значного збільшення швидкості. Це, звичайно, зменшило б вашу чисельну точність.


Я мав на увазі те, що ця відповідь говорить, коли я писав свою. Цей краще. Якщо я не помиляюсь, я також десь читав, що на деяких комп’ютерах (64 біт, можливо?) Нативної апаратної плаваючої точки з подвійною точкою подвійний, тому використання плаваючих точок однієї точності (чотирьох байтів) фактично може бути повільніше. Це все-таки слід врахувати.
heltonbiker

Поодинокі точності поплавці мають 23 бітну mantissae, двійники мають 52 біта.
Пол Р

Я пропоную 16-бітовий цілий + 48-бітний дріб як альтернативу плаваючої точки з подвійною точністю. Я згадав 32768, щоб вказати, що мої значення легко впишуться в цей діапазон. Зважаючи на обмеження цих значень, я думаю, що Q16.48 забезпечив би більшу числову точність, ніж плаваюча точка з подвійною точністю.
nibot

1
@nibot Добре. Подвійні мали б кращу точність від -16 до +16, а дробові цілі числа мали б кращу точність в інших місцях до -32769 та +32768. Вони, звичайно, не могли представляти нічого іншого поза цим. Вони також будуть повільнішими, ніж удвічі. Для мене обмежений діапазон і низька швидкість будуть вимикачами, але YMMV.
Джим Клей

6

Переваги фіксованої точки здебільшого полягають у потужності (наприклад, коли у вас є вибір апаратного забезпечення процесора або процесор добре вимикає невикористані функціональні блоки). Це тому, що одиниці з фіксованою точкою зазвичай менші (менше транзисторів, коротший провід, менша ємність для подолання на MAC) для заданої технології та швидкості випуску, ніж плаваюча точка.

Однак величезна кількість поширених сучасних процесорів (сервер, ПК і навіть мобільний) мають більше і швидших FPU (особливо одноточних FP-одиниць), ніж цілочисельні множники, і більшість енергосистем системи не в тому, щоб використовувати FPU, тому використовуючи фіксовану -point матиме мало або не має переваг для типових обчислень DSP на цих продуктах і, ймовірно, може бути недоліком з точки зору чистої продуктивності. Використовуючи сучасні технології, будь-яка перевага перед фіксованою точкою в основному буде накопичуватися в основному в крихітних вбудованих продуктах, таких як пристрої розміром із кнопками.

Однак також врахуйте слід пам'яті кешу пам'яті та процесора. Розумне використання менших типів даних (короткий int та float) для повного розміщення обчислень у кеші даних може компенсувати будь-які переваги пропускної здатності FPU.


2
+1 для згадування важливості питань кешу щодо продуктивності. На сучасних процесорах x86 проектування алгоритму з кешем може мати величезний вплив на продуктивність.
Джейсон R

5

Віддайте перевагу поплавкам з одною точністю до подвоєнь - це зменшить удвічі ширину смуги пам’яті, слід кешу і вимоги до пам’яті та зробить деякі математичні операції швидшими. Це також відкриває можливість чотиристороннього SIMD, якщо потрібна подальша оптимізація.

Фіксована точка дійсно доцільна лише тоді, коли у вас немає FPU - у більшості сучасних процесорів x86 є два FPU, тому від використання фіксованої точки нічого не можна отримати, а продуктивність може бути навіть гірше з фіксованою точкою. (Зауважте також, що фіксована точка вимагає додаткових інструкцій порівняно з плаваючою точкою для таких операцій, як множення.)


Мені цікаво збільшити числову точність, а не зменшити її.
nibot

Як ви бачите фіксовану точку, що покращує числову точність відносно подвійної, яка вже має 52 біти точності та величезний динамічний діапазон?
Paul R

Ну, я міг би використовувати формат з фіксованою точкою з більш ніж 52 бітами.
nibot

Оскільки, мабуть, вам потрібно щонайменше 16 біт для цілої частини представлення вашої фіксованої точки, це забирає у вас понад 64 біти, тому ви, мабуть, тоді дивитесь на формат, для якого ваш процесор навіть не має жодних вказівок із цілим числом. У такому випадку ви можете просто використовувати наявну велику цілочисельну бібліотеку або подібну. Але найважливіше запитання, на яке потрібно відповісти: яка точність вам насправді потрібна ?
Пол Р

3

Окрім дуже хороших відповідей, наданих тут, варто додати ще кілька речей:

  • Бувають ситуації, коли навіть якщо у вас є дуже основні вимоги до динамічного діапазону оброблюваних даних, вам все одно знадобиться дуже хороша точність для деяких операцій, що виконуються на ньому - наприклад, ви захочете застосувати фільтр IIR, який вимагає відносно невеликих коефіцієнтів; і обрізання їх може спричинити нестабільність. Як тільки у вашій системі з'явиться зворотний зв'язок, є хороші шанси, що проблеми з квантуванням / укороченням відвернуть вас при використанні фіксованої точки - вам потрібно бути набагато уважнішими щодо таких речей, як топологія фільтру та схеми усікання / збереження дробів.
  • На відміну від багатьох архітектур DSP / DSC, x86 не має насичених цілих операцій (ну, це там у SSE, а не у стандартному скалярному коді). Це означає, що у разі переповнення можуть статися погані речі - значення, що змінюють знаки та "обгортання". Ви повинні бути особливо обережними з переливами та динамічним діапазоном або обприскувати тести на операндахпо всьому коду. Це може серйозно зашкодити роботі. Для порівняння, плаваюча точка є більш стійкою до цих проблем, тому що великий динамічний діапазон дає вам більше «прогону», а переливи не призведуть до катастрофічних збоїв. Більшість кодів обробки звукових сигналів, що працюють на настільних комп’ютерах, використовують діапазон -1,0 .. 1,0, одно- або подвійну точність; тож це дає більше сотень дБ прогону. Я написав код обробки аудіосигналу з обома підходами, і при використанні плаваючої точки є лише кілька місць, коли мені явно потрібно чітко обрізати / насичувати сигнал - як правило, в кінці ланцюжка обробки сигналів або в місцях, де відбувається зворотній зв'язок.

1

Деякі моменти, які слід врахувати:

  • Більшість сучасних процесорів вже багато років оптимізують зчитування числа з плаваючою комою, і навіть GPU використовуються для цього вже дуже успішно;
  • Обчислення з фіксованою точкою шкодять вашим даним і можуть спричинити серйозні проблеми, коли арифметичні операції недостатньо обумовлені (саме тому цифри з фіксованою точкою були замінені на плаваючі точки);
  • Навіть якщо ви використовуєте підписані шорти для ЗБРОЙНЯ ваших даних (лоти даних, що застосовують 16-бітову точність), РОЗРАХУВАННЯ слід робити в плаваючій точці, а потім перетворювати назад на цілі числа, інакше можуть бути артефакти, такі як квантування та псевдонім.

В кінцевому слові, я думаю, що наші дані в реальному світі є дорогоцінними, а незряче число комп'ютерів - це скромне завдання. Комп'ютер повинен бути поставлений на важку підйомну роботу для ваших даних і для вас, а не поводитися з ними так, ніби це справжня зірка в шоу.


Я не мав на увазі, що я використовую 16-бітові шорти, щоб утримувати свої кількості, а щось на зразок 64-бітового формату з фіксованою точкою з 16-бітною цілою частиною та 48-бітовою частковою частиною. Мотивація полягає в тому, що якщо я все одно не використовую більшість експонентних бітів у форматі з плаваючою точкою, чи поліпшиться моя чисельна точність, якби я замість цього використовував ці біти для надання додаткових значущих цифр?
нібот

До оригінального питання слід додати 16-бітове ціле число + 48-бітний дріб. Це виглядає як215викликає плутанину.
Крістофер Фелтон

І ще одне: мені здається, що StackOverflow (замість DSP.SE, тут) було б ідеальним місцем для глибших причин про плюси та мінуси одного формату над іншим.
heltonbiker
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.