Request for increasing chunk size limit

[young ivy]

Is there any plan official will increase 16kb chunk size to bigger chunk size at 1.x release or later? Something like mega chunk (eg. 256kb) for general entities and tiny chunk (eg. 512 bytes) for singleton entity.

[potent stratus]

bigger size = it might not fit memory on some machines and will destroy cache efficiency.

[sick cave]

Just increasing chunk size is definitely not the solution. Imagine the case of all those unique entities sitting in single chunks

Also still limited to 128 entities per chunk.

It'd probably have to be done with some type of dynamic chunk sizing - archetype picks smallest chunk that 128 copies of itself can fit in

Sounds great, but even that has complications

Adding a component to entire chunk and it goes over size? Well you have to relocate the entire chunk.

[dusky latch]

The 128-entities-per-chunk limit isn't going anywhere any time soon; it's required for efficient iteration of chunk entities in the presence of enableable components. If the default SIMD register width on 95% of supported target platforms magically jumped from 16 bytes to 32, then maybe we can bump it to 256 entities. I'm not holding my breath 🙂

Within that constraint, the question of variable chunk sizes has come up in the past. 16KB is a convenient middle ground in most cases, but maybe you have a singleton, and you don't want to waste a full 16KB on it. Maybe you have an archetype with especially large entities, and want to pack more of them into fewer contiguous arrays for better cache locality.

It'd probably have to be done with some type of dynamic chunk sizing - archetype picks smallest chunk that 128 copies of itself can fit in
That would be a reasonable approach, except that a giant singleton entity would assume it needs a chunk big enough to hold 128 copies, and waste a ton of memory.

Anyway, it's on the radar and gets discussed from time to time. The problems aren't insurmountable, but there are still enough questions to answer and problems to solve that it's probably bit farther away on the roadmap.

[potent stratus]

shouldn't parallel chunks solve too big entity problem?

[near willow]

not so different from now where it has to move entities to different chunks of course

[sick cave]

only if it would exceed chunk capacity due to entities being full now

[young ivy]

Is that possible to have another new code path for entity that has zero enableable component to unlock this restriction? It seems like this 128 entities per chunk degrade performance a lot.

[sick cave]

it's really hard to get 128 entities in a chunk.
i'm one of the most aggressive at attempting and outside of my stats library which has perfect 128 capacity, pretty much none of my other libraries can achieve this
so in practice is it really causing performance limits?

when it was first announced i was pretty annoyed, i had previously compacted 450 entities per chunk and performance tanked on updating

but i ended up just reworking the library to utilize more of the chunk and fill perfectly

and the end result now is it actually scales better

[young ivy]

🤔 Not sure but maybe official will have difficulty to enable open world use case I dunno

[young ivy]

One more thing. About archetype for large entities, yes it's another reason why I need bigger chunk size for better performance. This even true when using dots netcode that needs to put ghost components at parent entity. And also when there's a lot of game stats, u will need to move to child entity to slim down per parent entity chunk size but now u will need to jump to child entity each time to access game stat. So dun have a way to get the best of both world.

[dusky latch]

All I can safely say at this point is that we're aware of this issue and are having some early design conversations around ways to address it. Nothing that I'd call imminent, though.