+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: How to speed up the simulators? (/thread-249.html)
Pages:
1
2
How to speed up the simulators? - Lapayo - 12-29-2011
Hey, I already did something to speed up the Simulators.
But they are still very slow when many blocks are getting moved.
I don´t have any ideas left how to speed it up.
It would be cool if someone else would look at it or give me any tips
thanks
Simon
RE: How to speed up the simulators? - mtilden - 12-29-2011
I will look at it but a lot of the simulator / chunk / block stuff baffles me. I can read code but when dealing with 3D space, coordinates and maths I get a little lost.
With any luck I'll notice something out of the ordinary but no guarantees.
RE: How to speed up the simulators? - Lapayo - 12-29-2011
Well in the Simulators made by me (Sand/Gravel and Fire) there is no math
But the water/lava simulator is very confusing for me too
RE: How to speed up the simulators? - AsianBusinessman - 12-29-2011
Is it slower than the vanilla server? I investigate how they did it since we all know Java is painfully slow...
And are you talking about all the simulators or just the fluid ones or?
RE: How to speed up the simulators? - rs2k - 12-29-2011
I haven't had time to test the simulators at all, but when does it start hogging the CPU? At all times when running? or when sand or gravel is dropping?
RE: How to speed up the simulators? - mtilden - 12-29-2011
From what I saw if you turn Water=1 in [Physics] in settings.ini then it just uses 100% CPU 24/7 even when you're not near any water that should be moving or whatever the case is.
RE: How to speed up the simulators? - FakeTruth - 12-29-2011
Slow? IMO the water flows amazingly fast compared to Vanilla.
(12-29-2011, 03:49 PM)mtilden Wrote: From what I saw if you turn Water=1 in [Physics] in settings.ini then it just uses 100% CPU 24/7 even when you're not near any water that should be moving or whatever the case is.Yea do not set Water to 1. It enables an old water simulator I created with finite water. It's not practical as giant oceans will keep on moving when you do as much as remove a block. In combination with the Notchian water things start failing, so if you want to see the old simulator turn off the new one first.
Also, the code is in cChunk.cpp somewhere in the Tick function
RE: How to speed up the simulators? - rs2k - 12-29-2011
Sounds like it's getting into a feedback loop, or it's not waiting for ticks, or it's just doing waaay too much at once. I had similar problems trying to make redstone work. The redstone simulator has to remember each block it looks at. IT uses two methods to do that, it uses the actual block state and it uses an array that changes blocks after a tick takes place.
RE: How to speed up the simulators? - Lapayo - 12-30-2011
Well, the simulator isn´t slow. But I think C++ could do much more speed. When you throw an 20 * 5 Sand plate in the ocean for example (With the old sand wakeup, where all blocks around are notified) it starts to lagg heavily. The Core goes to max and Ticks are taking more than a second. I think in this case the duplicate-check takes much time (Like mentioned somewhere else, it could happen that more than 3k Blocks are moved into the queue. And when adding a new block it iterates for each block through all tousend blocks and also adds a new one and then again and again
I already switched to list because I think it should be faster then vector when adding many items to it.
Another problem I saw is that blocks which get destroyed under water sometimes never leave the simulation queue. (Only occured when the block is destroyed under flowing water, not falling or stationary)
This also causes some lagg because every tick their flow gets calculated again and again but nothing changes
RE: How to speed up the simulators? - FakeTruth - 12-30-2011
So I managed to speed up the sand simulation by removing some stuff. I'd say it's roughly 10 times as fast now, and probably too fast, seeing how the client crashes when it can't keep up