Jörn Engel (joern.delete@this.purestorage.com) on July 13, 2020 10:10 am wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on July 13, 2020 8:38 am wrote:
> >
> > We do some vector and matrix algebra with SIMD, but I can't say much about
> > it. It's mostly based on vector4, so only makes use of four wide SIMD.
>
> That sounds like you have 32bit or 64bit types. I agree, going 4x faster
> isn't that exciting. If you can get by with smaller data types and go 16x
> or 32x faster, you are willing to suffer a bit more for that advantage.

We have both floats and doubles (floats aren't accurate enough in some cases), but SIMD only for floats and in practice only in the form of SIMDVec4.

> Run a profiler and see what stands out. If you have one thing responsible for 10% of runtime, it might be worth
> it.

Yeah, we don't have anything taking 10 % of runtime, unless that something is more or less buggy. At that point it's time to take a look and rewrite the obviously idiotic code. Vectorized idiocy is still idiocy, even if it's only 0.25 idiocy.

An example of this sort of idiocy some time back was a "property connection system" we have. It connects properties (ints, floats, booleans) to each other so that when one at the beginning of the chain is modified, the modification propagates. There may be operations in between, so you get propA + PropB inserted to propC.

The system is utter crap. Whenever some part of the game using it gets too expensive, we simply rewrite the functionality without property connections. The point here is that the system surely isn't vectorizeable (and in practice not threadable either). The solution is not to try to speed up property connections (which are inherently huge ball of spaghetti), but not to use them at all.

Pretty much all the really expensive things that pop up are a variation of this theme (outside of graphics).

> > The problem for me is that pretty much only abstraction that I know could be easily used
> > would be Vec3 operations, and that at the best gives just 3x improvement[1]. Even the amount
> > of matrix calculations in a game engine are low. All the hard work happens on GPU.
>
> The abstraction I wanted and eventually noticed I could get is pretty much C syntax.
>
> a += b;
> a >>= 4;
>
> That is code I can read and work with. It doesn't make a huge difference whether "a" is a
> u8, u64 or vector of u16. It took me about a year of suffering until I realized that it's
> possible to do that, you basically have to define your own types and then provide wrapper functions
> every time you want to use Intel intrinsics to do the type casting back and forth.

Yeah, I would likely do something like this too (I'm really extremely bad in deciphering or even recognizing the sort of names MMX/SSE/AVX intrinsics have). The problem is that I don't ever run into a problem where I'd need to add and array of floats with other array of floats item-to-item.

I have a hobby project, which I never seem to get around to, where I plan to create a class for operating on arrays of floats or Vec3s. I'm not sure if I can actually use them in any sensible way, but if I can, then it would make sense to apply SSE and AVX. But it's been ten years coming and I haven't started yet, because it would be a hobby. No need for such code at work.

> a = _mm256_add_epi16(a, b);
> a = _mm256_srl_epi32(b, 4);
>
> Be honest, did you spot the two bugs I slipped into this code?

I'd had to google those intrinsics first :D .

-JLarja