As far as the set of .cpp files which are using vecmat.h are
concerned, `Zero_vector` is out of reach for the compiler optimizer,
because it is extern / lives in a separate translation unit. An
expression like `x == Zero_vector` or `v = Zero_vector` thus has to
perform memory loads (for Zero_vector's x,y,z parts) before
comparison or copying, respectively. By using an immediate zero
vector `vector{}` instead, the unnecessary extra loads should go
away.
I present exhibit A:
```
void copyxx(vector *x) { *x = Zero_vector; }
4905e0: 48 8b 05 41 c0 56 00 movq 0x56c041(%rip),%rax # 9fc628 <Zero_vector>
4905e7: 48 89 07 movq %rax,(%rdi)
4905ea: 8b 05 40 c0 56 00 movl 0x56c040(%rip),%eax # 9fc630 <Zero_vector+0x8>
4905f0: 89 47 08 movl %eax,0x8(%rdi)
4905f3: c3 ret
```
vs.
```
void copyxx(vector *x) { *x = vector{}; }
4905c0: 48 c7 07 00 00 00 00 movq $0x0,(%rdi)
4905c7: c7 47 08 00 00 00 00 movl $0x0,0x8(%rdi)
4905ce: c3 ret
```
Both e.g. AIGame3.cpp and DallasFuncs.cpp include
``osiris_vector.h``. Right now, this is not a problem because
DallasFuncs.cpp is not compiled itself, but included from
AIGame3.cpp, in other words, it is all just one translation unit.
I have a plan to do away with ``#include "DallasFuncs.cpp"``, which
means the linker invocation for AIGame3.so will have at least two
translation units, and thus two definitions of the osiris vector
functions, which is not allowed.
This also has the side-effect to reduce compile-time a little,
from 1m57.5s to 1m48.7s on my 1135G7 CPU using `make -j8`.
