__Casin и Arcsine намного медленнее, чем синус в .NET? - PullRequest
1 голос
/ 20 октября 2010

Я проводил некоторые тесты eprofile медленной области кода. Это в Visual Studio 2008 и .NET 2 (полностью исправлено). Около 32% моих вычислений использует формула Хаверсайна. Для этого требуется два синуса, два косинуса, квадратный корень и арксинус - все с использованием стандартной библиотеки .NET Math (т. Е. Math.Sin, Math.Asin, Math.Sqrt). Я был в состоянии легко кэшировать косинусы - что привело к ускорению функции Хаверсайна примерно на 25-30%.

В профиле я вижу __CIasin_pentium4 и __CIasin, которые ничего не находят в Google, за исключением таких вещей, как дампы стека, которые публикуют люди. Вариант pentium4 собирает примерно вдвое больше образцов (как включающих, так и эксклюзивных). Я предполагаю, что это синусоида, но действительно ли это намного дороже синуса? В профиле нет признаков синуса, хотя будет вычислено вдвое больше.

Являются ли обе эти функции арксинусами или синусом? Если нет, то что они представляют?

Да, я видел различные статьи и посты в Интернете и здесь о быстрых синусах. Мне действительно нужна точность вычисленного синуса, а не таблица поиска или усеченная серия Тейлора. Я использую Haversine, чтобы вычислить и / или сравнить расстояния на поверхности Земли. Точность 10 м (минимальное ИМХО для моего приложения) равна примерно 1/640000 радиан.

Одной из мыслей о скорости является умножение тригонометрических тождеств. Хотя это приведет к увеличению числа триггерных функций, они станут зависимыми только от отдельных конечных точек и, следовательно, станут кешируемыми. Другой - развернуть арксинус и квадратный корень для моих сравнений. Я думаю, что у последнего есть много возможностей для улучшения, однако в данный момент я пытаюсь понять, что занимает время обработки и что именно представляют функции __CIasin.

Ответы [ 2 ]

1 голос
/ 21 октября 2010

Похоже, у Pentium FPU есть встроенные инструкции для синуса и косинуса (fsin и fcos), но не для арксинуса.Следовательно, функции __CIasin, которые я вижу, являются, вероятно, реализацией .NET arcsine, которая, как я понимаю, использует ряд Тейлора.Это объясняет большую разницу в скорости, так что асин появляется, а грех нет.(или cos или sqrt в этом отношении - это тоже нативные функции).

Я давно кодировал FPU x86.Давным-давно, я думаю, это был 8087 - так или иначе, единственный триг в те дни был частичным касательным!

Так что следующая задача в оптимизации - развернуть арксинус и квадратный корень из Haversineгде возможно.Результаты используются для простых сравнений больше / меньше (сортировка и т. Д.);и сравнить с «фиксированными» значениями.В обоих случаях должна быть возможность развернуть их.Например.фиксированное значение становится квадратным (sin (fixed)) и сравнивается с тем, что было внутри sqrt.

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

0 голосов
/ 08 ноября 2010

Да, определенно разверните sqrt и arc-sine. Обратные тригонометрические функции почти всегда медленнее, чем их прямые аналоги, потому что функции прямого триггера обычно реализуются в FPU.

...