The Powder Toy

LBPHacker

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.

Tadpole1

So what exactly is a thread?

LBPHacker

The more of them the game can use effectively, the faster it is.

Riptier1

@Tadpole1 (View Post)

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 ;)

Tadpole1

@Riptier1 (View Post)

Thanks.It's 2026.

ALumpOfPowderToy

@LBPHacker (View Post)

How did you get around RAW? If you were to blindly multithread TPT, particles will phase through eachother

LBPHacker

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.

Mdkar

Really cool! The aarch64-darwin-macos build seems to be broken. But x86_64-darwin-macos one works well using Rosetta. I have a M1 Macbook Pro. With 8 threads I saw a noticible FPS increase in a few specific cases, but not exactly across the board. I will have to try building locally using aarch64 to see if it works much better without Rosetta.

This save made the game crash, probably due to using subframe:

2308246View Save 2308246

Log:


ERROR - Details: Memory read/write error
An unrecoverable fault has occurred, please report it by visiting the website below

  https://powdertoy.co.uk

An attempt will be made to save all of this information to crash.log in your data folder.
Please attach this file to your report.

Version: 99.3.4 X86_64-DARWIN-MACOS MOD 17 UPSTREAM 392 LUACONSOLE HTTPS
Tag: mod17-v99.3.4
Date: 2026-05-04T03:32:32Z
Stack trace; Main is at 0x104ebd690:
 - 0   powderparallel                      0x000000010506cebe _ZN8Platform10StackTraceEv + 46
 - 1   ???                                 0x0000000000000000 0x0 + 0
 - 2   ???                                 0x0000600003d4bed8 0x0 + 105553180540632

LBPHacker

Thanks for testing! Yeah crashes are very much expected with this build; I've since discovered many bugs that I've fixed or am slowly fixing, so I'm not going to look into your specific crash too seriously, especially since for some reason the stack traces we get form macos are useless :( But I've tested the save you linked with my current build and it doesn't crash!

Sadly, we don't really have a way to test arm macos builds, because we don't have hardware for it, so it's possible that even vanilla is broken, even though we don't get reports about it.

pacmanfan123

This post has been removed by LBPHacker: not relevant

The Parallel Toy