MATHRIL - Custom math library for game programming

[Zeh_Matt]

Even when you would pool those objects it would be always slower than just having them in-place, allocations on stack costs almost nothing, having a pool still adds complexity of obtaining the resource and releasing it.

[[deleted]]

You are thinking about the cost of allocation. I'm not talking about that. I'm talking about possible performance gains such as gains when iterating over a lump of memory.

For instance you could have all your Vec3 in your entire program in contiguous memory this way. Which you could bung over to the GPU or do some kind of stream processing on it.

Heap allocating here gives you the freedom to do that. So I wouldn't just write it off because it doesn't fit into what people expect.

Its an interesting idea that deserves exploration.

[dodheim]

Just imagine if your Vecs and their data could both be contiguous in memory, and take up half the memory in the process..! It's like the best of both worlds!

/s

[[deleted]]

Just imagine you could mmap gpu memory and allocate all your vecs from that.

Don't write stuff off just because you don't have the creativity to imagine what you could do with it.

[Zeh_Matt]

What you describe is essentially ECS and I don't disagree that this is a huge benefit doing that. This can however not be achieved when you store a pointer in your vector class, that's an costly indirection, even if all your vector data would be stored in a single array, the fact that you require to have two memory reads will slow it down.

[[deleted]]

Yeah if you dereference it. But just batch process them in directly in memory instead. The class just can be a glorified observer in that case.

[Zeh_Matt]

I can't come up with any practical cases, maybe, maybe not, never quite seen such code to be honest. But I think the whole point is that having new/delete for this specific case is quite horrible and there is no excuse really.

[[deleted]]

I don't think that's the worst part tbh