Не могу сказать, что уж очень там с "деталями" сложно. Хотя, опять же... Ну вот допустим, простейшие вещи - умножение и деление с плавающей запятой.

Умножение: Вроде все хорошо, допустим, числа нормализованы и всегда есть единичный старший бит. Тогда, по результатам умножения для нормализации надо проверить старший бит произведения, и, если он равен 0, то сдвинуть результат влево с увеличением результирующего порядка на 1. Типа перенос учесть в сумматоре порядков.

Деление: а тут таких простых результатов не получается - количество нулей в частном может быть произвольным. Т.к. выполнять после деления поиск первой единицы в частном и сдвиг результата до нормализованного очень уж тоскливо, есть смысл вкрутить автонормализацию в само деление. Допустим, если деление выполняется в столбик, то наличие каждого ведущего нулевого бита в частном должно приводить к уменьшению величины порядка результата на единичку. Как только встречается 1, то деление продолжается обычным образом.

Вроде и не очень страшно... но следующей стадией должна быть замена деления в столбик на более производительный метод, а там уже (возможно) не так просто будет решить вопрос с нормализацией малой кровью.

Сорри, я по старой доброй институтской памяти...



А как, например, косинус считают с плавающей точкой? Через ряды? (Я не про синус нуля, пи и прочее из школьных учебников). То есть я понимаю, что можно через "сложение" все сделать. Акцент на производительность (как это не в теории делается)? Или опять все сводится к реализации умножения/деления + конвейер?

Дополнение: наткнулся на интересную статейку чувствую, что в разных современных GPU таких уловок масса. Наткнулся на нее здесь, значит "в лоб" даже сопроцессор не считает.
Сорри за глупый вопрос, математику подзабыл, а до каких пор надо складывать, когда считаем синус, понимаю, что все вычисления приближенные, или в этом IEEE какраз это и описано?

Вы хотите сравнить сферического коня в вакууме. Для этого идеально подходит плавающая точка. А еще лучше вообще символьные преобразования.

по сути вы ушли в вычисления с фиксированной запятой, возможно с разным весом точки, делается в ручную на раз без всякого матлаба.



дык ее никто и не хает, но согласитесь что реализация плавающей точки весит больше чем фиксированной/целочисленной ?



последнее что я читал про GPU подводило к мысли что современные GPU как раз ушли с фиксированной точки на плавающую и все вычисления внутри строятся как раз на ней.



ну это был достаточно старый сопроцессор, с современными GPU не сравнить. А алгоритм расчета синуса зависит от требуемой вам точности.

Простой пример. Астрономы, когда считают расстояния до звезд, часто считают то синус (x) = x. И работает! Расстояние до какой-то там звезды, у черта на куличках такое, что диаметр орбиты нашего глобуса такой что плакать хочется. От этого углы крохотные, а вблизи нуля, синус это просто палка под углом в 45 градусов.

А в функциях что дает TI, синус вообще имеет период 65535, и амплитуду 32768 и тоже работает. И методов расчета его в ТИ предлагает три: через ряд (ну очень не длинный), через таблицу (ну очень не большую) и кажись через таблицу с интерполированием. И тоже работает! Асинхронные и синхронные двигатели + всякие УПСы, прекрасно работают на таком урезанном синусе. А астрономам не подходит: диаметр орбиты нашего глобуса, делёное на расстояние до какой-то там звезды стабильно дает 0, для почти всех звезд.

Про GPU. Не от хорошей жизни там FPU. Делается это все для того чтобы игрушки быстро бегали. А игрушки как пишут - быстрей-быстрей, дешевле-дешевле. Кто будет тратить время на оптимизации, фиксированную точку итд.

Это так, на пальцах.

да и проще им, собрал один раз качественный FPU на кремнии и размножил N раз, все же не фпга %)

Я не соглашусь. Сравните умножение какогонить урезанного эмулятора плавающей точки, где под float пару байт отведено и умножение с фиксированной точкой типа 64.64. Все хорошо на своем месте.


А на кремнии собрать несколько качественных FPU и запхать их в FPGA?

задачи конечно бывают разные, но на 64-х битном проце с умножителем 64х64 не вижу никаких проблем. На фпга для моих задач(модемная связь), максимум что потребовалось это ss10.24(36 бит). И то, это было взято с большим запасом



ИМХО не имеет смысла, это как идея, которая витала у хилых %) аппаратные элементы видео декодеров на фпга, даешь h.264 за 2 доллара (на спартан 3), которая быстра загнулась. Подобное (FPU) нужно небольшому количеству людей, а место на кристале будет занимать много (ведь надо делать честный IEEE, а не в тапки с...ь).

ЗЫ. кстати разумное применение плавающей точки есть у альтеры в FFT корке, они называют это блочной плавающей точкой. Подробно не разбирался, но как я понял данный вид арифметики позволяет использовать разумный ресурс на реализацию, при нормальной производительности

Я и на 8 битовом проблем не нахожу.


Не понял, это идея корейцев была? Вопли "h.264" в FPGA c их стороны шли?


То ихних маркетологов увольнять нада. Они могли эту самую блочную плавающую точку и в FIR фильтрах применять и вообще везде подряд. Работы на пол часа, толку ноль, зато кричать "мы круче ксилинкса" можно на всех сайтах типа edn.

у нас разный взгляд на проблему %)



мне ее озвучивал начальник, после встречи с манагерами хилых в америке, хотели аппаратный CABAC/CAVLC, Deblock и ME в фпга класса спартан3е Потом как я понял к нему микроба, ДДР2, интерфейсы и вуаля транскодер почти за 2 бакса %)



вам виднее, я подробно не разбирался что они там предлагают

А, закон постоянства интеллекта в действии.

Да я ничего сравнивать не хотел 
Хотел просто нарыть литературу.


Так вот мне, как раз, нужно не на пальцах, а много-много сложной теории. 

Сообщение отредактировал des333 - Sep 1 2009, 10:55

А нет ли какого-то математического САПРа, который покажет разные способы вычисления, например, синуса в зависимости от того, что мы хотим получить (погрешность, точность, и т.д.)? Имел дело только с Matlab'ом, но мельком (очень не понравился его суконный язык, ощущение такое, что работаешь с БолшойЭВМ и перфокартами и он вот вот обзовет тебя нехорошим словом) и с Mathemati'кой (строил графики). Интересно посмотреть, как он будет считать.



А какая там, у них, в FPU/GPU? Неужели про это нет книг и разбирать приходится на "живых" примерах. Так не охото идти в "Библиотеку имени Ленина" за книгой 1964 года "Вычислительная математика ЭВМ". У нас что с того времени книг не писали?

Вот лучше матлаба я лично не знаю.


Есть. К примеру посмотрите в хелпе матлаба.

Не, я его ни в коем случае не ругаю, просто описал первое впечатление Спасибо, попробую.