Ожидаем поставку процессора с ядром Cortex-M4F с аппаратно реализованными операциями с плавающей точкой (32-битные float).

Точности float для некоторых наших вычислений недостаточно, приходится использовать 64-битный double.

Вопрос - есть ли способ использовать float-сопроцессор для операций формата double? Хотя бы для самых простых - сложение и вычитание?

Нет.

Если не смутит ссылка на Хабр, то здесь достаточно подробно описаны внутренности чисел с плавающей точкой, и сразу станет ясно, отчего более короткие float не удастся приспособить под работу с double, которые длиннее их.

Для только сложения и вычитания проще использовать long long. Без всяких float/double. Как бы значащих цифр больше, чем в double.

А я не знал что незяяяяя. Взял и включил сопр. В итоге на флоатах скорость поднялась в 12-15 раз, а на дублях в 3-4.

Эвона как! А ассемблерный листинг можете выложить? Допустим, ассемблерная реализация:

double a=2.123456789012345, b=-5.123456789012345, res; res = a+b;

в двух вариантах - при включенном и выключенном сопроцессоре.
Меня вот никак не отпускает ощущение, что ДОЛЖНО float ядро хоть как-то ускорять операции double.

Вот пришлось посидеть и понять почему у меня ускорение произошло. Просто у меня кучка всякой математики и некоторые ее части производились во флоуте ( ну где дубль не нужен был),
вот поэтому прога и ускорилась в 3-4 раза. Так что народ прав. В чистом виде для дубля сопр бесполезен. Но при грамотном смешевании дубля и флоута эффект будет.

Как видим, для деления вызывается подпрограмма, что и следовало ожидать: не может 32-разрядный ППЗ выполнять 64-разрядные операции. Ускорение же, возможно, произошло не только из-за смеси операций (32- и 64-разрядных), но и из-за повышения частоты процессора, если тестирование без ППЗ производилось на физически другом процессоре. Например, если ядро Cortex-M3 (без ППЗ) работало на частоте 60 МГц, а ядро Cortex-M4F (с ППЗ) -- на 180 МГц, то последнее, грубо говоря, будет в 3 раза быстрее на любых операциях именно за счёт роста частоты.



Ну, потратьте время на изучение матчасти -- и тогда поймёте, что никак оно не ускорит и не может ускорить в принципе.

Сообщение отредактировал SII - Nov 18 2013, 06:35

Странно. STM32F415, STM32F303 без очереди везде.

Вы в своём алгоритме скобки правильно расставьте и иногда масштабирование делайте. Так работают алгоритмы цифровой обработки сигналов .
Возможно компилятор gcc часть этой работы сделает и сам при включенной оптимизации.

число дабл - это мантисса + порядок.
если его разложить на 2 числа

младшая часть мантисы и порядок
и старшая часть мантисы и увеличенный порядок

то есть как бы число и уточнение, это позволит уменьшить длину мантисы

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

я в чем то не прав?

Разрешите не понять?






Во-во! Вот и я надеялся найти подсказку по алгоритму представления double числа в виде какой-то комбинации двух float. Как, например, операции для __int64 представляются в виде комбинаций обычных 32-битных int.

Сообщение отредактировал AlexeyT - Nov 18 2013, 19:42

В математике.
То что Вы сказали, переведите на математический язык (формулами).
И поймёте почему.

ну вот так как-то
(А+B ) * (D + C) = AD + BD + AC + BC
с этим я надеюсь все согласятся


далее мне кажется что число вида (для простоты будем оперировать целыми)
11112222 всегда можно представить в виде 1111 * 10000 + 2222

(A*B *C * D) == A*C*B*D

если число вида 1111 * 10000 считать А = 1111, B = 10000, то мы получаем
арифметику с числами 1111 2222 - половинного порядка, и выравнивание порядков и суммирование

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

Не согласятся.
У вас число в экспоненциальной форме - это не умножение, а возведение в степень.
ну-ка разложите: (где: ^ - операция возвдения в степень) в сумму

PS: Да и поймите - даже если вы найдёте способ, то это будет soft-преобразование double->float, потом будет float операция (или несколько) и обратное soft-преобразование float->double.
У вас всё равно 2 операции с double с soft-эмуляцией. Однозначно это будет медленее чем одна операция с double с soft-эмуляцией.

Ещё раз: изучите матчасть. А заодно повторите школьный курс математики, чтобы вспомнить, что такое экспоненциальное представление чисел.



У Вас описка: поскольку речь идёт об умножении, то
Впрочем, сути дела это не меняет.

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

В общем, наличие ППЗ одинарной точности абсолютно бесполезно, если необходимо выполнять вычисления с двойной точностью: он не может помочь ничем.

Сообщение отредактировал SII - Nov 19 2013, 10:19