3 ms·

>The fact that it is natural doesn't make it performant and straightforward for all applications. How does changing the scale make anything more or less perfor

>The fact that it is natural doesn't make it performant and straightforward for all applications. How does changing the scale make anything more or less performant? If anything, it makes things less performant since to use any hardware supported trig functions you now have to convert your weird angle representation into radians. For simple addition or fractions of your angle, it is just as performant as using angles in any scaling. > For example linear algebra is the natural and general way to handle vectors. However game developers still find quaternions faster and more performant. They only use quaternions for a few things, like slerp, and mostly because of gimbal lock. For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.

btilly 4y ago
> How does changing the scale make anything more or less performant? As the article shows, in application code we are multiplying by 2 pi, and the very first step in the optimized assembly is to divide by 2 pi. Therefore changing the scale to what both sides want saves 2 operations. And why would the optimized version want that division? It is because the next step is to reduce down to a fixed range, then use a lookup table. > They only use quaternions for a few things, like slerp, and mostly because of gimbal lock. And yet they still do use them. > For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.
- SideQuark 4y ago
  >As the article shows, in application code we are multiplying... The article is wildly misleading. I just checked out the godot code (git version c2f6664, today), and checked to see if what the author wrote and you believe actually happens in the code. It does not. Not even once. Didn't you find it odd that the author took two different codebases to make an argument between them instead of simply using one codebase? Here is what I find: First, avx_mathfun is not in Godot, nor is sin256_ps, nor is anything like it I can find. Feel free to find it and post where it is in godot. The function sin is called 347 times in c, cpp, and h files. The function sinf is called 25 times. Of these, only 50 are scaled by tau in some direction. So right there it's terrible to optimize the other way. And here is the kicker. Not a single one, zero, nada, called a function like the contrived sin func the author wrote about. Every single one called std::sin. std::sin resolves on different architectures to (often) a hardware instruction or code like this from glibc (used on most x86 machines). Note this implementation, likely far more widely used than any other (since it's the code in GCC), does not use the method in the code the author posted. For cos and cosf the result is the same (with a little changes in the counts since some audio filters use more sin or cos than the other): cos occurred 370 times, cosf occurred 41 times, only 52 of these involved tau (again the majority has no tau on the front side), and of all these, again zero get passed to anything other than hardware std::cos. So this pretty clearly demonstrates for this codebase that changing scale as the author wants would make the code less, not more performant. Didn't you wonder why the author searched on tau alone and didn't compare to the tau cases? Or why he then jumped to a sin/cos approximation not in the original code? And why he didn't mention how prevalent hardware sin/cos is? So, do you now believe that changing scaling is going to make code perform worse, not better? [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD#l194 https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/iee...

btilly 4y ago

> How does changing the scale make anything more or less performant? As the article shows, in application code we are multiplying by 2 pi, and the very first step in the optimized assembly is to divide by 2 pi. Therefore changing the scale to what both sides want saves 2 operations. And why would the optimized version want that division? It is because the next step is to reduce down to a fixed range, then use a lookup table. > They only use quaternions for a few things, like slerp, and mostly because of gimbal lock. And yet they still do use them. > For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.

SideQuark 4y ago
>As the article shows, in application code we are multiplying... The article is wildly misleading. I just checked out the godot code (git version c2f6664, today), and checked to see if what the author wrote and you believe actually happens in the code. It does not. Not even once. Didn't you find it odd that the author took two different codebases to make an argument between them instead of simply using one codebase? Here is what I find: First, avx_mathfun is not in Godot, nor is sin256_ps, nor is anything like it I can find. Feel free to find it and post where it is in godot. The function sin is called 347 times in c, cpp, and h files. The function sinf is called 25 times. Of these, only 50 are scaled by tau in some direction. So right there it's terrible to optimize the other way. And here is the kicker. Not a single one, zero, nada, called a function like the contrived sin func the author wrote about. Every single one called std::sin. std::sin resolves on different architectures to (often) a hardware instruction or code like this from glibc (used on most x86 machines). Note this implementation, likely far more widely used than any other (since it's the code in GCC), does not use the method in the code the author posted. For cos and cosf the result is the same (with a little changes in the counts since some audio filters use more sin or cos than the other): cos occurred 370 times, cosf occurred 41 times, only 52 of these involved tau (again the majority has no tau on the front side), and of all these, again zero get passed to anything other than hardware std::cos. So this pretty clearly demonstrates for this codebase that changing scale as the author wants would make the code less, not more performant. Didn't you wonder why the author searched on tau alone and didn't compare to the tau cases? Or why he then jumped to a sin/cos approximation not in the original code? And why he didn't mention how prevalent hardware sin/cos is? So, do you now believe that changing scaling is going to make code perform worse, not better? [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD#l194 https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/iee...