Some gravity particles

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

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