The Parallel Toy
-
So for more the lolz than anything else, we've been discussing over on the Discord server a not exactly new and not exactly elegant approach to multithreading TPT, and I've implemented it and am releasing it as a mod as an experiment of sorts. This is very much in development, expect updates.
The mod is based on a fairly recent development version of vanilla, so it's 99.3 with all the fixes and new stuff since then, e.g. BASE, SEED.
New features:
- multithreaded simulation, with caveats: not all of the simulation is multithreaded, and not always, but it still can provide very noticeable performance boosts
- new command line arg: threads:N
- new Lua function: sim.threads(N)
- a few new HUD readouts about timing in the top left area if you enable tpt.debug(0x100).
You WILL have to use sim.threads(N) to get any multithreading action because the initial value is 1, e.g. try sim.threads(4). To experience actual speedup, you may also have to uncap FPS with tpt.fpsCap(2). You can try using more and more threads until you hit a point where FPS doesn't go any higher. Do not expect linear speedup, e.g. 8x FPS for 8 threads, but definitely expect significant speedup.
sim.threads(1) is compatible with the old simulation, so everything works as it used to. sim.threads(N) for N > 1 may break things, see below.
Download links below. Builds naturally are hosted by @jacob1 and updated from starcatcher.
Known issues (will be updated as more issues are discovered or fixed):- There are several crashes caused by design issues, mostly when liquids are involved; these will be eventually fixed
- When using multiple threads, subframe is broken; this is by design and will not be fixed
- When using multiple threads, partial frame steps hinder multithreading and are no longer a useful debug tool
- Water equalization hinders multithreading; the game will behave as if you specified sim.threads(1)
- Lua scripts are currently expected to crash the game, please don't report such issues; will be fixed later
Please report any other issue here or on Discord. When the game crashes, unlike vanilla TPT, it may not show you a blue screen of death, and so it may look more like a hang, but it probably manages to output a crash.log into your data folder anyway; please attach this when reporting the crash.Edited 11 times by LBPHacker. Last: 8th April -
A thread of execution. Imagine the computer's CPU as a linear machine that takes in one command, then moves onto the next, then the next.
With mutliple threads, you can tell the CPU to do multiple things at once. Typically a program would use one thread, so everything has to wait in line. 2 threads means 2 lines, 3 means 3 lines, etc. But more threads = more complexity.
Also, another thing is that at the end of the day the CPU is only prentending to do multiple things at once, unless you have a multicore CPU. Luckly, it's 2025, so we all have multi-core CPUs. But that means if you use more threads than there are cores, the speedup will be minimal. That's because each core excecutes one thread. One core can fake running multiple threads well because OS and CPU designers are very smart, but that's still the core limitation.
All of this is very simplifed though ;) -
Thanks.It's 2026.
-
How did you get around RAW? If you were to blindly multithread TPT, particles will phase through eachother
Edited once by ALumpOfPowderToy. Last: 8th April -
I assigned a static neighbourhood radius to all particles and compare this with the areas of tiles I'm splitting the simulation area into. If a particle's neighbourhood is fully contained within the tile's area, tile assignment succeeds for the particle. Tiles are then updated in parallel, then all the particles that failed to be assigned to a tile are updated in series.
I'd rather not explain all the details here because there are many, and the best way to do it is either in a rolling conversation or a proper writeup; a forum post would be the worst of both worlds. Join our Discord server or IRC channel if you wish to discuss them.
