31–40 of 52 posts
now this can then be wrapped in another layer (SoSoA?) when partitioning a set of heterogeneous enum values but the post makes no mention of that
I don't get it, why wouldn't you just store tag + count instead? Am I missing something?
I don't get it, why wouldn't you just store tag + count instead? Am I missing something?
The idea that arrays of structs are inherently more cache friendly and thus data-oriented-er is a bit reductive of the whole practice of data-oriented code. The point is to optimize data layout for access patterns . Putting fields of a struct into their own arrays is only actually an optimization if you're only accessing that field in-bulk. And if so, why is it even in a struct in the first place? If you use all fiel…
Performance issues start to crop up with naive pre-fetching, and thus 100% guaranteed cache misses if the arrays are larger than L2.
This is why LLM AI generated slop degrades blogs into slop delivery services. =3
Earlier quoted context omitted.
It's an alternative to OOP. You can get there via a series of transformations: 1. Start with OOP (heap-allocated objects with shared base structs) 2. Transform to using tagged unions instead 3. Transform to the approach outlined in the OP (I call it the "encoding" approach in this talk: https://vimeo.com/649009599 ) It's handy because you get to use an index to refer to an object, and you get serialization benefits.…
I'll tell you my experience with Zig. I don't have any. I saw maybe Primagen talking about it and I see your post here. I watched 10 minutes of your vimeo video. I see it has 30k+ stars on github. So now I have to try to understand it in a nutshell. First like any language, I go to indeed.com and put in "Zig" to see if there are any jobs listed which use it. I don't see any. Then I click to https://ziglang.org/ and i…
Makes me wonder why you felt the need to create a burner account.
This isn't to say anything one way or another about you, its just my 2 second of reading about you.
Earlier quoted context omitted.
It's an alternative to OOP. You can get there via a series of transformations: 1. Start with OOP (heap-allocated objects with shared base structs) 2. Transform to using tagged unions instead 3. Transform to the approach outlined in the OP (I call it the "encoding" approach in this talk: https://vimeo.com/649009599 ) It's handy because you get to use an index to refer to an object, and you get serialization benefits.…
I'll tell you my experience with Zig. I don't have any. I saw maybe Primagen talking about it and I see your post here. I watched 10 minutes of your vimeo video. I see it has 30k+ stars on github. So now I have to try to understand it in a nutshell. First like any language, I go to indeed.com and put in "Zig" to see if there are any jobs listed which use it. I don't see any. Then I click to https://ziglang.org/ and i…
The idea that arrays of structs are inherently more cache friendly and thus data-oriented-er is a bit reductive of the whole practice of data-oriented code. The point is to optimize data layout for access patterns . Putting fields of a struct into their own arrays is only actually an optimization if you're only accessing that field in-bulk. And if so, why is it even in a struct in the first place? If you use all fiel…
This is wrong! Cache optimization isn't the only factor here. Even given an algorithm that seemingly handles each object one-by-one and uses all fields, SIMD turns individual operations into a hidden bulk access, and giving each field its own array will speed things up. This is counter-intuitive at first but becomes obvious if you write SIMD by hand (the article mentions this but doesn't make it super clear IMO)
Worth mentioning that you can always safely switch between AoS and SoA. Either can represent the other; all you've done is transpose the data. The same is not true of AoE/EoA. The AoE [Spam1, Egg1, Spam2, Spam3, Egg2] has no corresponding EoA that can represent it. What they're actually doing is an AoE => AoEoA transformation: find batches elements with the same tag and reorder the elements so that redundant tags can…
If the order doesn't matter, you could use a separate field for each variant of the enum.
The idea that arrays of structs are inherently more cache friendly and thus data-oriented-er is a bit reductive of the whole practice of data-oriented code. The point is to optimize data layout for access patterns . Putting fields of a struct into their own arrays is only actually an optimization if you're only accessing that field in-bulk. And if so, why is it even in a struct in the first place? If you use all fiel…
Yes. That's the point.
> Putting fields of a struct into their own arrays is only actually an optimization if you're only accessing that field in-bulk.
Yes, that's the scenario.
> And if so, why is it even in a struct in the first place?
Because that's how everyone is taught to model domains.
> If you use all fields of a struct in your algorithm, then an array of structs is the optimal way.
No. Your personal belief goes against both theoretical and empirical evidence. Others already talked about cache, padding, vectorized instructions, etc. I recommend you do a quick googling on the topic.
inb4: "The concepts are language independent."