Multithreading Idea

  • QuanTech
    1st Aug 2017 Member 0 Permalink

    Multithreading has been rejected a lot in the past, because it is incredibly hard to multithread a simulation where each particle depends on the one before it. Here I propose an 'algorithm' that could allow particle simulation in TPT to be multithreaded, potentially. I have no idea if this could work or not, and I'm also waaay too lazy to implement.

     

    Basically, this way of multithreading would run the update function on multiple instances of the simulation. If you have, for example, 4 cores, you could simulate the current simulation and the next 3 frames. "But wait, the next frame still depends on the previous frame!". Read on.

     

    The Algorithm:


    For this example, I'll assume you have 4 cores, cuz I do :P. 

     

    1. Create 4-1 = 3 copies of all the simulation arrays (parts,pmap,etc.).  These 3 copies plus the already existing instance make a total of 4.

    2. Create 4 56-byte memory blocks. 56 bytes because each will hold a struct Particle

    3. Create 3 threads. The main thread plus these three threads will each act on the simulation instances and the 4 memory blocks

     

    So, how do these threads act on the memory blocks and simulation instances?? First, the main thread simulates the first particle of the first instance (lots of 'first'). Then, the particle data of the new particle (type, life, etc.) is placed in the first memory block. After that, the second thread copies that particle data onto its own simulation instance. The 1st thread's memory block is then cleared. The second thread then simulates its first particle. Meanwhile, the 1st thread is also simulating its second particle! Once the second thread is done, it writes the particle data of the simulated particle into its memory block, and the 1st thread finishes at around the same time, and writes to the first memory block again. Then, the 3rd thread copies that data onto its own simulation instance!!

     

    Once the 1st thread is done simulating its 235008 particles, it waits for the other 3 threads to finish, and then, after a frame, the 1st thread's simulation instance is replaced with the second thread's. After another frame, the 1st thread's simulation is replaced with the 3rd thread's. Finally, it is replaced with the 4th thread's instance after another frame. Then, the whole cycle is repeated.

     

    This way, you've just simulated the current frame AND the next 3 frames.

     

    Hopefully you managed to understand my crappy explanation :D.

     

    If you have any questions and/or concerns, please post them in this thread.

    Edited once by QuanTech. Last: 1st Aug 2017
  • jacob1
    1st Aug 2017 Developer 0 Permalink
    For context:

    <PowderBot> Thread 'Multithreading Idea' by QuanTech in Development; http://tpt.io/:21910
    <jacob1> that ... doesn't work at all
    <jacob1> you can't simulate the next frame unless every particle from the previous frame has already been simulated
    <jacob1> it also ignores many other things like air pressure
    <jacob1> also I want to multithread everything but the simulation itself, it's not rejected :P
    * QuanTech has joined #powder-forum
    <QuanTech> hi
    <QuanTech> jacob1: why does the prev frame neeed to be simulated first?
    <jacob1> lol, so you read logs
    <QuanTech> yeah
    <jacob1> it just does >_>, especially for electronics or subframe stuff
    <jacob1> and for movement
    <jacob1> you need to know where the free spots will be a particle can move in to
    <jacob1> for that, you need to know every spot that is empty from the previous frame
    <QuanTech> aww man. i thought i finally found a way to multithread the sim ;-;
    <jacob1> lol
    <jacob1> this is how I think about it:
    <QuanTech> odang, i just realized, ARAY,PSTN,and other stuff that affects multiple parts would not work at all
    <jacob1> graphics are 10-40% of the cpu time
    <jacob1> if I multithread that away, sudden speed boost!
    <jacob1> also, double scale mode uses a few % of the total cpu time, that needs to be threaded off too
    <jacob1> yes, ARAY and PSTN wouldn't work with your method
    Edited once by jacob1. Last: 1st Aug 2017
  • lamyipfu
    1st Aug 2017 Member 0 Permalink

    Let say the first thread is evaluating time=1 and second thread is on time=2
    The state of particle #1 in time=2 does not only depend on the state of itself in time=1.
    Instead, it is possibly depending on any other particle in time=1.

    For example, in time=1, there are 3 particles and #2 is trying to delete #1.
    In this case, #1 would not live to time=2

    But your method will lead to the survival of #1 in time=2 as it does not check for #2's action before sending its data into thread 2