[Experimental] Multi-threaded Particle's
-
Hi everyone,
I wanted to share a custom experimental build of The Powder Toy (based on v100.0.399) that adds multi-threaded particle simulation updates to get much better FPS when pushing the physics engine to its limits!
As we know, the core physics engine is historically single-threaded, which causes high lag when the screen is filled with particles. This build resolves that by parallelizing the main update loop.
### How it works:
1. **Global Thread Pool:** A lightweight thread pool is initialized on start, spawning worker threads corresponding to the number of logical cores on your CPU.
2. **Chunked Updates:** During each simulation tick, the active particle range is partitioned into chunks and distributed across the worker threads to process concurrently.
3. **Synchronization & Safety:** To prevent crashes and data corruption, all operations mutating the global state—such as particle allocation (create_part), destruction (kill_part), type changes (part_change_type), and portal transfers—are synchronized using low-overhead recursive locks.
4. **Preserved Determinism:** A major issue with multithreading is breaking subframe contraptions. This build checks the `ensureDeterminism` flag. If it is active, it runs the updates sequentially (single-threaded) to guarantee step-by-step determinism. It also runs single-threaded if the active particle count is low (<1000) to avoid thread scheduling overhead.
5. **Real-time Performance HUD:** We've added a thread usage overlay right next to the FPS indicator. It displays:
`FPS: [Value] Threads: [Active]/[PoolSize]` (e.g. `FPS: 60.00 Threads: 16/16` under high particle loads, or `Threads: 1/16` when empty or forced to single-threaded).### Source Code & Standalone Download:
You can find the code and download the ready-to-run ZIP containing the executable and its DLLs from the GitHub repository release page here:
https://github.com/JoshuaLanders99/The-Powder-Toy-Multithreaded/releasesWould love to hear feedback and see how it performs on different systems!
-
@jansuki (View Post) He probably meant "fps is still higher compared to the average fps in a simulation filled with WATR".
-
@jansuki (View Post) Then he did all that work for nothing I guess.
-
It's not for nothing. The Parallel Toy (the previous version) requires manually selecting the number of threads. In contrast, TPT Multithreaded (the version in this thread) is supposed to automatically choose the number of threads. It starts off at 1 thread for compatibility, but when maximum non-subframe performance is demanded, it dynamically scales to the CPU thread count. We can also compare the performance between the two versions.
(edited: wrong information)Edited 2 times by linfuciuscont. Last: 28th June -
For those who want to look (but can't because the mod's repository is broken as all hell and doesn't share history with vanilla), here's the diff from vanilla: https://pastebin.com/sbzeusjq
Not recommended; this is going to crash left and right. All that happens here is that particle update functions are asked to be run in parallel, with absolutely no regard to what happens to resources shared between them. So e.g. if two CRAYs try to remove the same particle, it might be deleted twice, which causes a crash down the line.
To the mod author, my best advice is to stop relying on AI.
@linfuciuscont (View Post)
This is not true, this mod uses either exactly 1 thread, or exactly as many threads as many cores the C++ runtime thinks you have. (Which in itself is a massively inaccurate reading; for example, there's really no point doing heavy computation on both threads of a HT/SMT core, but in the vast majority of cases, the C++ runtime counts those as two cores, so on a 8c16t CPU this is going to start 16 threads, which may even perform worse than 8 would.) There's absolutely no in-between option, and it definitely doesn't care about subframe when deciding how many threads to use (in fact, trying subframe stuff might be a good way to get it to crash).Edited 7 times by LBPHacker. Last: 28th June -
Judging by the AI description (incorrect formatting isn't a mistake you can make unless you copy-paste from somewhere), this looks like a RAW hell. Particles will phase into eachother outside of EHOLE, which creates BHOL if it happens too much. Double deletions everywhere; dropping DUST into a line of VOID will probably crash the game.
This... already exists, too.
