А измеритель времени не от тех же клоков запитан случайно?


Это похоже на нормальное значение, хотя библиотеки RVCT работают примерно вдвое быстрее. Просто sin/cos по определению тормозные и мало подходят для работы в реальном времени.

А я, кажется, догадываюсь почему: в newlib-е libm раздваивается
(в math и mathfp) и вызов sin() считает синус два раза, очевидно для
проверки, что бы не ошибиться :)

10,000 клоков не предел, в DM6446 sin() (из DDR2, cache off,
release, no dbg info) считает здак 45,000 клоков и ничего,
только чип горячий и дым из эмулятора...

Сообщение отредактировал AndrewN - Jul 27 2009, 23:29

нет, от RTC


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


ээ.. то есть??

Есть, и использование таблицы - один из наиболее распространенных. Что же в ней некрасивого?

Можно, например, ограничится одним битом и считать что синус на [0, pi) равен 1, а на [pi,2*pi) равен 0. Но это путь скорби. Обычно, всё-же, сначала задаются необходимым значением точности, а потом ищут вычислитель, который зту точность обеспечит вместе с заданным временем вычисления - т.е. жертвуют деньгами вместо точности.

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

Мой вчерашний эксперимент с DM6446 показал удивительные результаты: огромное количество тактов тратится на всевозможные варианты переходов и на обращение к ОЗУ, тогда как обычные арифметические инструкции завершаются за 3-5 тактов.

Что, конечно, неудивительно само по себе, но что бы так много - 95 на переход, от 125 до 250 на LDM-ы в эпилогах (STM-ы в прологах укладываются за около 20 тактов). Понятно, что тайминг операций с памятью прямо пропорционален отношению частоты ЦПУ и частоты памяти и если включить кэш (я пока не научился работать с CP15) то времена должны улучшиться (в том числе и скорость переходов, так как она косвенно зависит от скорости обмена с памятью), но пока не знаю на сколько.

Вот эти операции и определяют, в итоге, скорость (точнее, медленность) симуляции плавающей точки, где на каждый чих (e.g. целое -> вещественное) свой вызов подпрограммы, т.е. переход, пролог и эпилог. Суммируя, ARM без аппаратной плавающей точки для вычисленений с этой самой точкой можно использовать только от отчаяния. Более подходящее применение - целочисленное преобразование.


Как-так само-собой получилось, ни причины, ни логики не смог увидеть. Может быть, экпериментирование с разными способами. Только вот в math некоторые функции (kf_...) проектировал явно бухгалтер. Еще одна спорная вещь - использование полиномиальной аппроксимации для тангенса. В C&W используется дробно-рациональная аппроксимация, т.е. меньше коэффициентов (6) плюс деление, что м.б. быстрее чем Хорнер с 13-ю коэффициентами, - как сделано в mathfp.

Спасибо, информацию принял к сведению. У меня правда уже есть сомнения относительно моих 10000 циклов на sin, проверю. Не уверен, что частота была действительно 200 МГц, еще не научился правильно ей управлять..