Parallel Powder Build
-
Good day to you all,
I would like to present my (64-bit) build of the Powder Toy.
The primary feature is that the simulation is actually done in parallel by exploiting a particular trick of how parts interract. This allows the game to have >30 fps when the screen is fully filled with materials.
It is also built with AVX (with SSE available too) to possibly offer more speed. There are certain problems with complicated circuits and water equalisation doesn't work but it is a big step up.
The build is available on my github:
https://github.com/Nessphoro/ParallelPowderToy
To play just get the build folder.
Currently only Windows is supported, but it should be really easy to compile for Linux and other platforms as it uses OMP and not any particular threading library.
-
The AVX one doesn't run at all for me, and the SSE2 one runs at 30 fps. Is it supposed to have any improvement on older computers? Mine is fairly old, so that might be the problem.
-
Yeah, AVX is only supported on newer machines.
The multi-threading starts to make a difference if you have a lot of parts, for me it runs a bit slower when I start TPT because of the overhead, but performance doesn't drop significantly when I add a lot of parts.
-
This is definitely a unique way to split particle updates.
Unfortunately by the nature of splitting updates at all, you cause major instability.
Particle movement causes overlap (a bit less than the last posted multithread mod).
Liquid movement is directionally biased.
I tested a few things for fun.
Destroyable city runs 15-20% slower.
Full screen of water runs 75% or more faster.
8x6 line display mostly works17758View Save 17758
My ARAY copier fails to work, so I expect -all- saves with frame perfect timing to completely fail.875764View Save 875764Edited 2 times by cracker64. Last: 5th Mar 2015 -
Indeed I have noticed numerical instabilities in certain simulations, but I'm sure they can be reduced by using different cell pools dimensions. Electricity is interesting as well, I was thinking of updating sparks seperatly, and serialy, to at least try and mitigate those issues somewhat.
EDIT: Fixed electronics. All of your examples now work.
Edited 2 times by Nessphoro. Last: 5th Mar 2015 -
Edited 2 times by ssccsscc. Last: 5th Mar 2015
-
@Nessphoro (View Post)
I don't think relying on menu sections to determine elements that need to be separated is going to work out in the long run. We have moved elements around all the time, or even created new sections.
This is a frame perfect machine that still fails, as would any machine that uses parts from non-electric menus.1732622View Save 17326221107352View Save 1107352
PUMP and HSWC are activating twice as fast as normal (spark white)109980View Save 109980 -
Looks interesting, I had some problems compiling it on linux though:
You deleted src/debug/. This is used (in the next version) for drawing some debug info to the screen when you use tpt.setdebug.
There is a broken file src/simulation/BRON.cpp (boron). I'm not sure why it's there but it doesn't have the directives used by generator.py to compile it correctly.
When I did get it compiled it crashed instantly ):, not sure why but maybe i'll look into it later. Compiling with --debugging makes it not crash ... annoying.
It crashes if you open certain saves, that's because you throw an std::exception(); when there are more than 1024 particles in a cell. I get that stacking is bad but ... you shouldn't make it crash like this, just continue;, or better, figure out how to multithread more than 1024 particles in a cell.
Multithreading the simulation is cool, but it's really hard to do properly and probably will never happen to official. If adding a few #pragma directives could make TPT multithreaded properly, we would have done it already. Maybe you can get it to a point where most of the big problems are gone and don't show up unless you are actually looking for them, that would be cool.
The main bugs with multithreading is that it makes particles move into each other since they all modify parts[] as they are moving, similar bugs happen with other particle updates. There are probably ways to fix this but it might require a bit of work :)
