Unnecessary vec3 copy

[enadream]

Hi, I decided to use cglm instead of glm because I thought glm doesn't make operations in place, I mean it creates an intermediate object to make operations and then copy the result into the target object. I thought if I use cglm that problem wouldn't be in case, however when I read your vec3.h file I saw that you used a lot of intermediate vec3 inorder to do operations and then copy that vector to the dest parameter. Why did you do that ? Why instead of copying results directly into dest vector you created a vec t and then copied it into dest using glm_vec3_copy ? What's the point of that ?

[recp]

Hi @enadream,

Sorry for the delay,

I mean it creates an intermediate object to make operations and then copy the result into the target object

In general creating an intermediate object is not a drawback but beneficial for some circumstances:

1. Safety: Let's take a look at glm_vec3_cross():

CGLM_INLINE
void
glm_vec3_cross(vec3 a, vec3 b, vec3 dest) {
  vec3 c;
  /* (u2.v3 - u3.v2, u3.v1 - u1.v3, u1.v2 - u2.v1) */
  c[0] = a[1] * b[2] - a[2] * b[1];
  c[1] = a[2] * b[0] - a[0] * b[2];
  c[2] = a[0] * b[1] - a[1] * b[0];
  glm_vec3_copy(c, dest);
}

can indeed be (without extra glm_vec3_copy()):

CGLM_INLINE
void
glm_vec3_cross(vec3 a, vec3 b, vec3 dest) {
  /* (u2.v3 - u3.v2, u3.v1 - u1.v3, u1.v2 - u2.v1) */
  dest[0] = a[1] * b[2] - a[2] * b[1];
  dest[1] = a[2] * b[0] - a[0] * b[2];
  dest[2] = a[0] * b[1] - a[1] * b[0];
}

bu if you call glm_vec3_cross(a, b, b); store cross of a and b then store result in b. In this case b would be used twice which would cause unexpected results (b -> dest):

  dest[0] = a[1] * dest[2] - a[2] * dest[1];
  dest[1] = a[2] * dest[0] - a[0] * dest[2];
  dest[2] = a[0] * dest[1] - a[1] * dest[0];

as you can see dest[0] is written in first line then used in other lines...

2. Optimization: compilers are smart enough to reduce intermediate objects' overhead if any. Actually sometimes produces faster code. We can load vec4 with simd ( if possible ) then work on registers directly which is fast. However in most cases we dont know where vec3 comes from, from array of vec3 or individual aligned or unaligned vec3 variable, from stack or heap or something elsewhere which may not be efficient to load individual items each time from remote source. Copying it once into intermediate value in stack brings extra copy but makes things fast because we are on stack now.

vec3 can be optimized with simd in the future if there will be enough room for efficiency

---

Struct API

cglm also provides structure api ( see documentation ). Struct api returns intermediate value directly and compilers may produce faster code by return value optimization and reduce extra copy/move operations. Both Array and Struct Api ( including CALL / GLMM APIs too ) can be used together.

[enadream]

@recp I hadn't thought about it this way. Thanks for the clarification.