Some gravity particles

[User137]

This is the only part where thread collisions can happen. It is possible that some force vectors are not added to movement, but is that likely?

            movement.x:=movement.x+vec.x;
            movement.y:=movement.y+vec.y;
            movement.z:=movement.z+vec.z;
            star[j].movement.x:=star[j].movement.x-vec.x;
            star[j].movement.y:=star[j].movement.y-vec.y;
            star[j].movement.z:=star[j].movement.z-vec.z;

Also the mainloop's part for threads is like:

    i2:=count div 4;
    i3:=i2*2;
    i4:=i2*3;
    TPhysicsThread.Create(self, 0, i2-1);
    TPhysicsThread.Create(self, i2, i3-1);
    TPhysicsThread.Create(self, i3, i4-1);
    TPhysicsThread.Create(self, i4, count-2);
    while threads>0 do begin
      sleep(1); // It takes usually over 140ms, so sleep here is not unnecessary
      Application.ProcessMessages;
    end;
...
constructor TPhysicsThread.Create(parent: TGame; const first, last: cardinal);
...
Thread execute:
...
    for i:=FFirst to FLast do
      with star[i] do
        for j:=i+1 to count-1 do begin

So it will not stop responding. I know it could be done better though, even so that fps wouldn't be affected. I also realize now that all the threads aren't getting equal workload at all. Especially the first thread gets biggest work, and 4th one the smallest.

Win32-binaries and source code here: https://docs.google.com/file/d/0B7FI...it?usp=sharing
Requires Lazarus and nxpascal to compile, possibly SVN version. All the required files are here:
https://code.google.com/p/nxpascal/s...%2Ftrunk%2Fsrc

[SilverWarior]

Also the mainloop's part for threads is like:

    i2:=count div 4;
    i3:=i2*2;
    i4:=i2*3;
    TPhysicsThread.Create(self, 0, i2-1);
    TPhysicsThread.Create(self, i2, i3-1);
    TPhysicsThread.Create(self, i3, i4-1);
    TPhysicsThread.Create(self, i4, count-2);
    while threads>0 do begin
      sleep(1); // It takes usually over 140ms, so sleep here is not unnecessary
      Application.ProcessMessages;
    end;
...
constructor TPhysicsThread.Create(parent: TGame; const first, last: cardinal);
...
Thread execute:
...
    for i:=FFirst to FLast do
      with star[i] do
        for j:=i+1 to count-1 do begin

So it will not stop responding. I know it could be done better though, even so that fps wouldn't be affected. I also realize now that all the threads aren't getting equal workload at all. Especially the first thread gets biggest work, and 4th one the smallest.

First of all get that Application.ProcessMessages out of that loop. It is not good to call Application.Process messages to often. And the reason why your main thread has so much load is becouse of Application.ProcessMessavges. It is quite resource consuming call. And all that processing time that is used by Application.ProcessMessages is taken away from one of your other threads making everything slower. And since you sad that you only have dual core the impact on overal speed can be quite big.
Wanna see how much Application.ProcessMessages affect your application. Start the simulation with setting sthat will cause low FPS, rotate the view and then pause the simulation. You will se that after you pause the simulation the overal view will quickly rotate to proper position while when being at low FPS it can be falling beind a litle.

[Darkhog]

I disagree that taking away ProcessMessages is solution. If you do that, application will "hang" (won't respond to paint request, button clicks, etc.). Though I agree it shouldn't be called every iteration. Maybe every tenth iteration or so.

[SilverWarior]

No the application still works OK but the performance gain is much smaler than I imagined it would be.
Yes I'm actually testing the source code to see where there may be major bottlenecks.

[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.