00:04 <scientes> pub const arch = Arch{ .aarch64 = Arch.Arm64.v8 };

00:04 <scientes> this is weird

00:06 <scientes> I guess this came from llvm

13:16 <gamester> So I've been working on implementing a kind of "ECS" system that learns from Overwatch and the new stuff Unity is doing, as their approaches are super flexible, simple, and performant at the same time. Definitely the way to go for most code. On top of this Unity is working on something they call the Burst compiler which automatically SIMDifies their ECS code, they say it's already as good as ISPC. This is super interesting and it makes me hope

13:16 <gamester> that I can do something similar at some point by parsing Zig code (using the standard library) and auto converting it to @Vector code. How this will work and how difficult it will be I have no clue at this point as I have yet to think about it. A pipe dream perhaps, or perhaps not!

13:22 <gamester> This would all be directed from tags/comments in the source code which hint to the Zig-to-@vector transpiler on what to do

14:02 <gamester> andrewrk: Could this kind of thing happen in zig? https://pastebin.com/raw/YXPBXJcX - I assume slices are immune from it

14:03 <gamester> oops I forgot it's saturday, you might be away :)

15:34 <gamester> andrewrk: Will there be a way to utilize llvm math intrinsics? sqrt, cos, sin, etc

17:20 <andrewrk> gamester, https://github.com/ziglang/zig/issues/767

17:21 <andrewrk> I don't think auto converting to use @Vector makes sense. we should work on manually expressing things using vectors

18:22 <gamester> andrewrk: Well, the Unity Burst compiler is aware of Unity's job system, ECS architecture, containers, and memory layout (not exactly sure what they mean). It's a very specific thing. They need an entire compiler because C# is not powerful enough to let them use a c# to c# transpiler and of course when you've generated code it's always a question on how you combine that with the rest of your codebase especially if you intend it to replace other

18:22 <gamester> code. With Burst they can automatically convert job kernels (that look like very simple c# code) into extremely fast AOSOA code (for example).

18:23 <gamester> In this specific case of using an ECS architecture throughout your engine and game's codebase, I think a solution like this makes sense. In general I agree with you.

18:35 <gamester> andrewrk: Sorry everything's a bit vague still. I wasn't (and still am not) aware of the full details of Unity Burst so I just wrote about the SIMD stuff. I suspect that custom code gen might be worth it, I have some vague ideas about going further than Unity by generating multiple versions of job kernels to optimize some data layout stuff

18:37 <andrewrk> I think this has to do with Just-In-Time vs Ahead Of Time compilation

18:37 <andrewrk> as far as I'm aware, Unity using JIT, and zig is AOT

18:39 <gamester> No, this is about having a compiler that's aware of the details of Unity. (https://www.youtube.com/watch?v=NF6kcNS6U80)

18:40 <gamester> they're trying to get away from a general purpose compiler

18:42 <gamester> AOT is only part of it

19:26 <gamester> One thing I can do to simplify SIMD programming is making the allocation for all arrays a multiple of the maximum vector length. I wonder if SIMD programmers generally prefer that or if they duplicate their code to handle less data than the vector length

19:31 <gamester> oh or always do a masked load and store

21:43 <Barabas> I think vectorizing existing code is the wrong way to go about it.

21:45 <Barabas> It's better to be explicit about it. Either by writing explicit SSE code or by writing kernels like in graphics apis and ISPC.

21:46 <scientes> yes, auto-vectorization rarely works well

21:46 <scientes> look at how bag gcc's -O3 is

21:46 <scientes> *bad