dot() vs cos()

S1mon

@ilya_baran

approachSpeed += dot(side1.tangent, positionDiffNormalized) - 1;

I'm digging through the code for Bridging curve, and there are several places where dot products are used on normalized vectors. It seems like cosine on the angle between the (non normalized) vectors would yield the same result.

Is this is done for speed?

mahir

I don't know for sure what the internal algorithms are for either dot() or cos(), but I would imagine cos() is just the tiniest bit faster since by definition dot(v1,v2) = norm(v1)*norm(v2)*cos(v1,v2). But if I had to guess, it's just easier to use dot() since it's a more general function that would apply to more than just unit normalized vectors. The code may have even been copy/pasted from other features. The code may also be easier to write or debug using dot() because it has a natural geometric meaning - the projection of one vector onto another.

Edit: @ilya_baran reminded me that also u⋅v = ux*vx + uy*vy + uz*vz.

ilya_baran

When doing geometry programming in a low-level language, it's automatic to avoid trig functions when possible (which is most of the time).  A dot product of 3d vectors is 3 multiplications and 2 additions, a cross product is 6 multiplications and 3 additions, which are all really cheap (can be even cheaper with vector instructions), and a trig function is a couple of orders of magnitude slower.  Square roots and divisions are slower than additions and multiplications, but not as slow as trig functions.  Computing the cosine of the angle between two vectors would also require getting that angle first (which is atan2 of a dot and a cross product), so two trig functions.  In FeatureScript, because of interpreter overhead, the accounting is different, and in this case, not the bottleneck, but coding in terms of dot and cross products is a strong force of habit (and likely to be easily understood by other geometry devs).

S1mon

Thanks @ilya_baran

I figured it was something like that.

I assume these days that trig functions are more optimized with look-up tables and interpolation or some other types of clever numerical methods. But yes, much slower than a few multiplies and adds. There’s also the extra effort to get the length of vectors in order to normalize them. 

I’m also curious how much overhead is there in FeatureScript to call functions. When I look at the source for some of the basic functions, there are ones which are only a few lines of code. Certainly using functions like that can make things much cleaner and easier to code, but I wonder when it would make sense (for performance reasons) to put some of these bits of code inline instead of calling a function.