Comments 9
Псевдокодом для этой ассемблерной части будет такой, и судя по логике работы это вычисление синуса с помощью таблицы.
Таблицы Брадиса или их аналог первое о чем я подумал когда речь пошла об очень быстром синусе, и не ошибся.
Все эти __aeabi_fmul так же довольно сильно тормозят код. Их вставляет стандартный arm gcc, даже если указать neon, а вот в android ndk от них избавились (когда gcc еще там был). Насчет clang не помню, но вроде так же. Так что есть еще куда ускорять.
По поводу dagor_sin: на самом деле он вызывает v_sincos4, который считает сразу 4 синуса и косинуса и отдаёт единственный float, так что потенциал для оптимизации вроде бы есть.
Я год назад даже пытался его оптимизировать, даже получил смешные 10% ускорения, но не смог получить коэфициенты полинома, который давал бы такую же точность. Кажется, у меня была ошибка в двух последних битах мантиссы.
Это еще нужна задача соответствующая, чтобы задействовать на полную v_sincos4. Так то да, он считает сразу четыре пары, обычно считают один синус-косинус где-нить в алгоритме. Что если убрать cos-ветку вычислений из v_sincos4? там уберется как минимум 4 операции из 20. Надо попробовать сделать симд версию __sin_corf_nx_502 и сравнить. Странные конечно названия, надеюсь это всеже какието абревиатуры а не просто набор букв :)
А как быстродействие этих синусов со скоростью одного деления соотносится?
Извините, не понял вопроса? Ну разные алгоритмы вычисления синуса дают разную точность, и выполняются за различное время. В некоторых задачах важнее скорость, в некоторых точность. Все три алгоритма из сдк достигают ошибки не больше 1e-6, cо стандартным разложением в ряд, в статье я описал свой опыт, как мы обнаружили что Нинтендо в прошивке 5.0 использовала разные алгоритмы для каких то своих целей.
Зачем в Switch SDK три разных sin?