Тригонометрия является в вычислительном отношении дорогой?
Я читал в статье где-нибудь, что аккуратные вычисления являются обычно дорогими. Действительно ли это верно? И если так, вот почему они используют право аккуратных справочных таблиц?
Править: Хм, поэтому если единственная вещь, которая изменения являются градусами (с точностью до 1 градуса), взгляд, представила бы в виде таблицы с 360 записями (для каждого угла) быть быстрее?
8 ответов
Дорогое понятие относительное.
Наиболее быстро выполняются математические операции, выполняемые непосредственно вашим процессором. Конечно, среди них будет целое сложение и вычитание. В зависимости от процессора также может быть умножение и деление. Иногда процессор (или сопроцессор) может обрабатывать операции с плавающей запятой изначально.
Более сложные вещи (например, квадратный корень) требуют выполнения ряда этих низкоуровневых вычислений.Эти вещи обычно достигаются с помощью математических библиотек (написанных поверх собственных операций, которые может выполнять ваш процессор).
В наши дни все это происходит очень-очень быстро, поэтому «дорого» зависит от того, сколько из этого вам нужно сделать и как быстро это должно произойти.
Если вы пишете программное обеспечение для 3D-рендеринга в реальном времени, вам может потребоваться множество умных математических уловок и ярлыков, чтобы выжать максимум скорости из вашей среды.
Если вы работаете над типичными бизнес-приложениями, велика вероятность того, что выполняемые вами математические вычисления не будут существенно влиять на общую производительность вашей системы.
Да (относительно других математических операций умножения, деления): если вы делаете что-то в реальном времени (операции с матрицами, видеоигры и т. Д.), Вы можете выбейте много циклов, вынув триггерные вычисления из внутреннего цикла.
Если вы не делаете что-то в реальном времени, тогда нет, это не дорого (по сравнению с такими операциями, как чтение пакета данных с диска, создание веб-страницы и т. Д.). Надеемся, что триггеры будут выполняться аппаратно вашим процессором (который может выполнять миллиарды операций с плавающей запятой в секунду).
Если вы всегда знаете вычисляемые углы, вы можете сохранить их в переменной вместо того, чтобы вычислять их каждый раз. Это также относится к вызову вашего метода / функции, когда угол наклона не изменится. Вы можете проявить смекалку, используя некоторые формулы (вычисляя sin (theta) из sin (theta / 2), зная, как часто повторяются значения - sin (theta + 2 * pi * n) = sin (theta)) и сокращая вычисления. См. эту статью в википедии
да, это так. Триггерные функции вычисляются путем суммирования ряда. В общем, это будет намного дороже, чем простая математическая операция. то же самое и с sqrt
Хотя быстрый ответ заключается в том, что они дороже, чем простые математические функции (сложение / умножение / вычитание и т. Д.), Они не -дорогие- с точки зрения человеческого времени. Обычно люди оптимизируют их с помощью справочных таблиц и приближений, потому что они вызывают их потенциально десятки тысяч раз в секунду, и каждая микросекунда может быть полезной.
Если вы пишете программу и вам просто нужно вызывать ее пару раз в секунду, встроенные функции будут достаточно быстрыми.
В процессоре Intel x86 для сложения или вычитания с плавающей запятой требуется 6 тактовых циклов, для умножения требуется 8 тактовых циклов, а для деления - 30-44 тактовых цикла. Но для косинуса требуется от 180 до 280 тактов.
Он по-прежнему очень быстр, поскольку x86 делает эти вещи аппаратно, но он намного медленнее, чем более простые математические функции.
Поскольку sin (), cos () и tan () - математические функции, которые вычисляются путем суммирования ряда, разработчики иногда используют таблицы поиска, чтобы избежать дорогостоящих вычислений.
Компромисс между точностью и памятью. Чем выше потребность в точности, тем больший объем памяти требуется для таблицы поиска.
Взгляните на следующую таблицу с точностью до 1 градуса.
Я бы порекомендовал написать тестовую программу и рассчитать время для себя. Да, они медленны по сравнению с плюсами и минусами, но они все еще однопроцессорные инструкции. Вряд ли это будет проблемой, если вы не выполните очень жесткий цикл с миллионами итераций.