Some gravity particles

[imcold]

Nice demo! Few notes:
-too many ops per one star, some reduction helps, for example

d := G_FORCE/(d*d*d);

- division is one of the slowest ops you can do (just this one line change makes it 20% faster)
-no use of more than 2 calculation threads on dual-core, more threads than cores makes it slower actually
-Application.Processmessages is an invitation for reentrancy problems, and at least use interlocked decrement on the thread counter (thread joining would be better, sleep really isn't a synchronization primitive)

[User137]

Nice notice (fixed it into my version)

d := G_FORCE/(d*d*d);

It does mean same thing as:

f:=G_FORCE/(d*d); 
d:=f/d;

Also there is no Application.ProcessMessages in that version (you can remove "forms" from gameunit uses list). It was replaced by

while Threads>1 do sleep(1);

in the physics main thread. It still doesn't hang the application because it's a separate thread. Spiking in framerate is simply because of heavy utilization of CPU i think. Trying with this seems to work too, but i feel like it is actually consuming CPU resources more with loop like that

while Threads>1 do ; // <- Don't do this

So with this i see an increase in physics loop time.

It should be ok to have 4 threads even on dualcore, remember that each thread gets different workload. Meaning that other CPU could be without work for longer time, if i only had 2 threads. At the same time people with quadcores can test it too. It might even be faster with 8 threads.

Also works better if i comment out SetFrameSkipping(false); Showing more realistic framerate (~40) numbers too, when it's not pushed to draw as much as possible.

[imcold]

Empty while loop is worse, for sure: use TThread.WaitFor. You probably want something like this in your TPhysicsMainThread:

 
  threads: array [0..MAX_THREADS-1] of TPhysicsThread;

...
  
     stars_per_thread := count div MAX_THREADS;
        for i := low(threads) to high(threads) do
            threads[i] := TPhysicsThread.Create(FParent, i * stars_per_thread, (i + 1) * stars_per_thread - 1);
        for i := low(threads) to high(threads) do begin
            threads[i].WaitFor;
            threads[i].Free;
        end;

[User137]

Wow, this became quite a practise for threads You are right again. But also with this change i could test how 32 threads would effect, and as expected, it seemed just as fast as 4 or 8 threads. And minor difference in the creation, to support odd particle counts aswell

        for i:=0 to MAX_THREADS-2 do
          pt[i]:=TPhysicsThread.Create(FParent,
            i*tcount, (i+1)*tcount-1);
        pt[MAX_THREADS-1]:=TPhysicsThread.Create(FParent,
          (MAX_THREADS-2)*tcount, count-2);

New version is also uploaded, and there is extra test in rendering loop commented out. I tried what it looks like when full screen clear would be replaced with slow fading to black. Particles can leave kind of trails when they move. I'm not sure if it looks better than original though, so that's why it's commented.

[imcold]

Also (a bit akin what Dan suggested) you can play with the condition affecting when to apply the force to particle:

if (d > 0) and (d < DISTANCE_TO_IGNORE)

With distance set to 15 or so gives a nice speedup in later stages, when the particles spread out.
Smaller distances (try 5) will give you more speedup in early stages but have a more noticeable effect on particle behavior (less tight clusters).
Larger distances (100) cause slowdown in early stages
Dynamically tuning the "ignore distance" would probably lead to best results (2xfaster execution shouldn't be a problem).

As per more calculation threads than cores: if threads with similar workload start competing for resources, you'll get slowdowns from overheads associated with threads, scheduling, context switching, cache trashing and so on.


Edit: you have an error within the last statement, (MAX_THREADS-2) should be (MAX_THREADS-1), otherwise the last thread will get more stars than it should (the same ones as in the prev. thread, not to mention it won't work with one thread

[User137]

Edit: you have an error within the last statement, (MAX_THREADS-2) should be (MAX_THREADS-1), otherwise the last thread will get more stars than it should (the same ones as in the prev. thread, not to mention it won't work with one thread

Just noticed that myself. I was testing with randseed:=1 just to see if i get same results with 1 thread or many. It crashed the moment i tried to set it on 1 thread Also 1 thread didn't result same kind of universe than 2 or more threads.

But that's fixed now. I added more debug info, like how many physics ticks are calculated, print out how many threads are used. Changed the visuals slightly, so that blue particles aren't add-blended, and there is the slow fade-to-black only when it is unpaused.

[imcold]

The visuals are really cool Final note for the threads - the load isn't distributed evenly between them, given the same amount of stars, the one with lower starting index does more cycle iterations. That's most likely why you see a speedup with more threads - the bigger the discrepancy, the more difference thread count does. Also, physicsthread.WaitFor on formClose; no need for thread counter at all.

[User137]

I realized today that while 3D is great, is not necessary to simulate the gravity particle effect, or should you call it "anti-gravity". This can be done in 2D, with big gain in performance, and better results to look at.

Now after testing it a little, it didn't seem to work somehow, or maybe i'm missing something. I also think that i'm able to rid of Sqrt() completely.

    for i:=FFirst to FLast do
      with star[i] do
        for j:=i+1 to count-1 do begin
          xx:=v.x-star[j].v.x;
          yy:=v.y-star[j].v.y;
          d:=xx*xx+yy*yy;
          if d>0 then begin
            d:=(G_FORCE*G_FORCE)/(d*d*d); // Compiler should optimize the constant multiplication to 1 value
            // If not, just remove multiplication and change G_FORCE value
            if star[j].positive<>positive then d:=-d;
            vec.x:=(star[j].v.x-v.x)*d;
            vec.y:=(star[j].v.y-v.y)*d;
            movement.x:=movement.x+vec.x;
            movement.y:=movement.y+vec.y;
            star[j].movement.x:=star[j].movement.x-vec.x;
            star[j].movement.y:=star[j].movement.y-vec.y;
          end;
        end;

The particles scatter endlessly, with no clear groupings done as was in 3D. I have tried with many different parameters. I wouldn't want to make boundaries to the "universe", where particles would bounce backwards, but i might have to. I also tried with every particle being same polarity, and they still did not group. It's not because of removal of sqrt(), that was almost last step in my tests, improvement to calculation time i'd say.