Some gravity particles

[SilverWarior]

@User137
Did I understand corectly that you intend to calculate force efect on every particle from every other particle? If that is ture than your current code is compleetly wrong as you are only calculating the force effects to current particle of all those who are positioned in the list after the current one.
This would cause compleetly wrong simulation.
But on the other hand it would mean that proper code would work even slower as your would need to do even nore calculations

[User137]

First loop i runs from 0 to count-2, and is divided for different threads. Second loop j runs from i+1 to count-1. Overall effect will be that each unique pair is calculated once, and once only. Index 0 vs 1 is counted, but index 1 vs 0 is not, and so on for all of them. They have same potential force towards eachother, because i assume they all have same mass, and it is applied to both of them at the same time. ... Well, i could try do that 1 fix where physics is calculated separately from main thread, to get 60 fps all the time possibly.

You may have also noticed that i modified form.onClose event: if threads are running when click it, it will call for threads to stop and then you have to click it again. Otherwise crash would happen on exit, due to accessing game data after threads finish, but data being freed already. It didn't help if i put a waiting loop in the onClose. That was 1 "fix the wheel with bubblegum"... I'll see if i could fix it aswell.

Update: Please download from the link again, i made proper threading. It looks slightly spiky, but it's doing 60+ fps while physics is calculating on my computer.
https://docs.google.com/file/d/0B7FI...it?usp=sharing

[User137]

Updated the file twice, second time after a little code cleaning.

[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