08-22-2020, 02:16 AM
I think a thousand players is well within capabilities of modern hardware. I'd venture to say 23GiB of memory is ez for a server, and given single core performance has stalled a bit, memory size (and core count) are the most easily scalable things right now. Also, when we get chunk palettes implemented I'm sure memory usage can get way lower.
Every tick reading every single block in every chunk might be too much of a worst-case. We're updating 50 blocks per chunk every tick, and assuming there aren't stupid numbers of entities/redstone wire I don't think saying on average 1% of 460GiB/second memory throughput is unreasonable.
And all this talk of independent, nonoverlapping chunks gives rise to another question. Given the concept of chunking exists anyway, why bottleneck ticks through the World? It could be a massive boon to dispatch chunk ticks to a thread pool. Any sort of reads, even across chunks are fine. Block writes can be redirected to some sort of overlay that gets applied after everything finishes. Client modifications are applied as normal before ticking begins, and updates are computed from the overlay (basically PendingSendBlocks) and sent back to clients after ticking ends.
In fact, if each chunk gets a lock we don't need any sort of overlay; just hope most of the time cross-chunk stuff doesn't happen for locking overheads to become an issue.
Every tick reading every single block in every chunk might be too much of a worst-case. We're updating 50 blocks per chunk every tick, and assuming there aren't stupid numbers of entities/redstone wire I don't think saying on average 1% of 460GiB/second memory throughput is unreasonable.
And all this talk of independent, nonoverlapping chunks gives rise to another question. Given the concept of chunking exists anyway, why bottleneck ticks through the World? It could be a massive boon to dispatch chunk ticks to a thread pool. Any sort of reads, even across chunks are fine. Block writes can be redirected to some sort of overlay that gets applied after everything finishes. Client modifications are applied as normal before ticking begins, and updates are computed from the overlay (basically PendingSendBlocks) and sent back to clients after ticking ends.
In fact, if each chunk gets a lock we don't need any sort of overlay; just hope most of the time cross-chunk stuff doesn't happen for locking overheads to become an issue.