Zig Structs of Arrays (2024)

https://andreashohmann.com/zig-struct-of-arrays/

by Tomte • 2 months ago

128 50 2 months ago

Sweepi• 1 month ago

OT: I just spend a few minutes searching for the source of the "Not all CPU operations are created equal" slide of the linked presentation (Andrew Kelley - Practical DOD), its here:

https://6it.dev/blog/infographics-operation-costs-in-cpu-clo...

skywal_l• 1 month ago

You URL seems KO, an alternative I found: https://x.com/chessMan786/status/1879092981892067383/photo/1

trymas• 1 month ago

Slightly related recent HN post: https://news.ycombinator.com/item?id=48382382

Thaxll• 1 month ago

This is what games do with ECS.

hiccuphippo• 1 month ago

Hugged to death. Mirror: https://web.archive.org/web/20260608113005/https://andreasho...

binaryturtle2• 1 month ago

I'm just seeing a "410 Gone" error on the linked site (same happens to the parent URL too).

ArneCode• 1 month ago

Works for me

binaryturtle2• 1 month ago

Still the same. I guess it's some sort of wild anti-bot stuff basing on the user agent?

/edit

Yes, as confirmed with cURL, using my browser's "User Agent": 410 blocked. Using some other "User Agent" and it passes along the data. Pretty silly, IMHO.

smallstepforman• 1 month ago

The GPU loves arrays of structures AoS, since all vertex data fits in its triangle assembly cache. Once given to the GPU, the software side doesnt really care for all vertex parameters so this optimisation is pointless. Only relavent when you have instance rendering (leaves, grass) but then you only need an array of vec3’s, not the other parameters so back to normal arrays.

Meanwhile, game engines need operator overloading for adding/multiplying vectors (spatial transforms, lighting, physics) and core zig design philosophy prevents operator overloading.

Blind leading the blind. Disclaimer - I do professional rendering engines.

awesan• 1 month ago

Zig is adding native vectors including operator support, there are some recent issues/prs about this topic.

The general technique of SoA is pretty useful both in games and other applications, but of course I cannot speak to the specific use-case you are describing.

nvme0n1p12• 1 month ago

Zig vectors force data into SIMD registers even if that would make the code slower. They're a specialty type. You should only reach for vectors if you would have used SIMD intrinsics in C for example.

beepbooptheory• 1 month ago

So is the argument that any SoA is pointless? Or just for GPU stuff? Because this isn't really talking about all that one way or another.

Also does one really need operator overloading? That feels a little strong. I've gotten by with functions just fine.. Does that make the GPU not like me Mr. wise engineer?

geysersam• 1 month ago

Genuine question: why do you think game engines need operator overloading? I mean, what's wrong with generic functions like add, multiply, dot etc.

aaaashley2• 1 month ago

Not GP, but I've written game engines and rendering engines. Vector operations are just common enough that having to write `.mul` every time is a huge pain, especially when you put many of them together for a large formula. Compare:

(physics_data.velocity + omega * change) * frame_delta_time

physics_data.velocity.add(omega.mul(change)).mul(frame_delta_time)

We learn to read and think about math a certain way, which is incompatible with Zig. Also, Zig's design philosophy of "reading code over writing code" is incompatible with the kind of small modification-test-cycles required when doing games, and creative programming in general. So Zig is sort of DOA anyway for that kind of thing.

But I've been using Zig for non-game projects and it's been fantastic, so definitely not "Blind leading the blind" for the overall language design, imo.

hmry2• 1 month ago

Why have operators at all?

  x = x.add(step.mul(2)).mod(width)

Or in C

  x = imod(iadd(x, imul(step, 2)), width)

  x = (x + 2*step) % width

For me the answer is very simple: Operators make it easier to read the code which makes it easier to spot bugs. It also makes it easier to turn formulas from textbooks into code.

If 50% of the code you're working with is using vectors and matrices, not having operators for those parts is quite annoying.

Note that you can have vector operators without overloading, e.g. Odin has built in vector and matrix types.

But personally I think it's better to give the user more power instead of only letting the compiler author pick which types to allow operators on. Like how Java overloads + but only on the String class. Why do they get to do it, but not me?

Ciantic• 1 month ago

Rust should (eventually) support arrays of structures via compile-time reflection: https://fnordig.de/2026/03/25/rust-reflection-and-a-multi-ar...

smj-edison6• 1 month ago

I didn't realize compile time reflection was back on track, that's really exciting!

the__alchemist• 1 month ago

Meanwhile, game engines need operator overloading for adding/multiplying vectors (spatial transforms, lighting, physics) and core zig design philosophy prevents operator overloading.

This is a frustrating decision. My use cases for low level languages overlap closely with my use cases for vectors (etc) with operator overloading. It was one of the first things which put a bad taste in my mouth about Zig.

flohofwoe2• 1 month ago

Zig has a builtin vector type and will get a builtin matrix type. The only useful thing that's missing from shading language vector-math syntax is swizzling, but you don't get that via operator overloading either (and for dot- and cross-product you'll still need a function, but that's also in line with shading languages).

fasterik• 1 month ago

On the other hand, SIMD loves SoA, and so does the CPU cache. It all depends on what you're doing with your data.

Zig professes to be a C replacement, not a C++ replacement, so leaving out operator overloading is consistent with that design goal. But I agree, I would prefer to program in a language that expresses mathematical relationships more naturally.

flohofwoe2• 1 month ago

Splitting fat vertex component data into multiple streams also often makes sense in rendering engines (e.g. not all vertex shaders might need all vertex components). Strict SoA or strict AoS hardly ever makes sense, but an 'inbetween' approach often does (maybe call it SoAoS) - and this should be possible just fine with Zig's comptime approach, e.g. only apply the SoA transform to the toplevel items of a struct.

As for CPU-side vector math:

Zig already has a @Vector type (which will probably be renamed to @Simd) and it will get a builtin matrix type. With those two things, the main reason for operator overloading in game/rendering engines is pretty much handled via builtin types.

nejam2• 1 month ago

Jdoemhoe

nejam2• 1 month ago

Jfpe?

blt• 1 month ago

After that build-up, I was hoping to see a toy implementation of a method or two for `MultiArrayList`.

Zig Structs of Arrays (2024)

Related Stories