Gravity Simulator
http://www.orbitsimulator.com/cgi-bin/yabb/YaBB.pl
General >> Discussion >> Multicore/multiprocessor/multisystem version of GS
http://www.orbitsimulator.com/cgi-bin/yabb/YaBB.pl?num=1354598537

Message started by inetd on 12/03/12 at 21:22:17

Title: Multicore/multiprocessor/multisystem version of GS
Post by inetd on 12/03/12 at 21:22:17

Hi, guys!!

Have a little investigation with forum's search for multi-xx usage of the Gravity Simulator. But with no results.

So I want to ask - does GS using multicore computation or not?
I have dual core Intel Centirno @ 2GHz and it seems, like only one core is used by GS (load at 48-49%).

What about multicore/multiprocessor or multisystem version of the GS?

Thanks!!
-------
Denys

Title: Re: Multicore/multiprocessor/multisystem version o
Post by EDG on 12/03/12 at 23:11:28

I've asked tony about this before, and the impression I've got from what he says is that the calculations don't lend themselves to parallel-processing.

I'm wondering if that's really true though. I can't imagine that the orbital evolution simulations that show up in science papers are all run on single processors - surely they're run on parallel clusters or something (otherwise they really would take forever). Maybe it's possible to run outer planets on one core, and inner planets on another core, for example (since they may not directly influence eachother)?

Title: Re: Multicore/multiprocessor/multisystem version o
Post by Tony on 12/04/12 at 19:29:18

The savings wouldn't be that great.  What you really want is a custom computer with one processor per object.

Title: Re: Multicore/multiprocessor/multisystem version o
Post by inetd on 12/10/12 at 11:29:16


Tony wrote:
What you really want is a custom computer with one processor per object.

:) :) :) :)

Actually, if all predictions from our IT-gurus will take place, in some (visible) future we will receive a lot of cheap and powerfull processors :) :)

But, seriously. Tony, could you, please, redirect me to the thread, where this question was rised earlier? (as EDG sayd)

Some time ago I have the idea to write my own simulator and for now have some thoughts how to make calculations in parallel way. I can sound them, but need some time to clarify them for myself.

And one more, Tomy, could you, please, in a few words explain how the engine of your GS works to understand it, and maybe, we can find some way to think about multicore processing?

Title: Re: Multicore/multiprocessor/multisystem version o
Post by wil on 04/27/13 at 05:55:19

Utilising many cores is rather easy in such calculations.

Simply we divide all objects by number of cores.
N - number of objects
k - number of cores (threads)

And every thread computes N/k objects.
For example: N = 10, and k = 2, then one thread computes the objects from 1 to 5, and second 6 to 10, simultaneously.

Title: Re: Multicore/multiprocessor/multisystem version o
Post by EDG on 04/27/13 at 09:19:18


wil wrote:
For example: N = 10, and k = 2, then one thread computes the objects from 1 to 5, and second 6 to 10, simultaneously.


But then how do you calculate the interactions between objects 1-5 and 6-10? You can't treat them in isolation since they'll be influencing eachother, and removing that influence would make the results less accurate (e.g. if you just calculated the planets of the inner solar system in one thread and the outer planets in another, you wouldn't see Jupiter's influence on the inner planets)

Title: Re: Multicore/multiprocessor/multisystem version o
Post by wil on 04/28/13 at 11:43:18

Algorithms, procedures remain intact.

Any thread sees and uses complet of data: actual positions and velocities for complect of bodies.

Difference reduces to:
one thread modifies several of objects only, instead of all; rest of data are read-only for it.

Two copies of data:
1. actual state - used in calculations
2. future state - after next step

Some standard synchronisation methods, typical in a multithreaded applications, are unavoidable, of course.

Anyway, we don't calculate the objects, but we solve the system of equations.
Number of equations in this problem is: (N-1) N / 2, and that should be split into k threads.

r_ij(t), v_ij(t) - calculated relationship pairs of objects.

Title: Re: Multicore/multiprocessor/multisystem version o
Post by Tony on 04/28/13 at 12:35:37

My computer is about 10 years old.  It is not multi-core.  So even if multi-core coding is possible, I can't do it.

Title: Re: Multicore/multiprocessor/multisystem version o
Post by EDG on 04/29/13 at 00:23:51


Tony wrote:
My computer is about 10 years old.  It is not multi-core.  So even if multi-core coding is possible, I can't do it.


How on earth are you surviving with such a relic?! GravSim must run so slowly for you! (even smartphones have multiple cores nowadays!)

Are you even close to being able to upgrade it?

Title: Re: Multicore/multiprocessor/multisystem version o
Post by wil on 05/03/13 at 07:21:39


Tony wrote:
My computer is about 10 years old.  It is not multi-core.  So even if multi-core coding is possible, I can't do it.


You can. Windows is a multitasking system from the begining.

CreateThread, and other tools for multithreaded applications are standard in Win32/64 API.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852%28v=vs.85%29.aspx


Maybe one day I'll do such simulator, because it is not very difficult.
Much more work is with business applications: many of windows, dialogs, printing, etc.

Once I developed the crosswords generator: complex algorithms, drawing diagrams - fonts, shapes, various decorations; database - dictionaries, images, sentences, etc.
Really a lot of work - perhaps 100 times more than in the gravity simulator!

Title: Re: Multicore/multiprocessor/multisystem version o
Post by frankuitaalst on 05/03/13 at 12:33:33


Multi core processing surely has advantages in certain applications . I see Tony's point when he thinks multi core brings little for the GravSim program . The reason is that the algorithm which is used doesn't allow  being split up over several cores . See one article about Arndahls Law about "paralelisability"  

http://en.wikipedia.org/wiki/Amdahl%27s_law.

Multi-core computing is done AFAIK for systems with a hughe number of body's , such as galaxies or even galaxy clusters ( 10^7 bodies or even more ) and needs different algorithm's , highly specialised ones in order to run .  The main idea is to split systems into sets of systems which are gravitationnaly weakly bound as a whole and treat each system in a core for instance , or creating subsystems which interact strongly and neglect the other weakly interacting particles .
This approach is necessary in this hughe simulations .  The drawback in doing so is loss of accurancy if one doesn't pay attention .
But accurancy often is not a priority when evaluating the overall behaviour of a galaxy ....
GravSim performs very well in my opnion for small systems. (1000 bodies ) .
I doubt multi core can speed up GravSim the way it works .

Title: Re: Multicore/multiprocessor/multisystem version o
Post by wil on 05/03/13 at 18:58:44


frankuitaalst wrote:
 The main idea is to split systems into sets of systems which are gravitationnaly weakly bound as a whole and treat each system in a core for instance , or creating subsystems which interact strongly and neglect the other weakly interacting particles .
This approach is necessary in this hughe simulations .  The drawback in doing so is loss of accurancy if one doesn't pay attention .
But accurancy often is not a priority when evaluating the overall behaviour of a galaxy ....


Yes, they have ignored the weak impact of a distant mass and thus discovered the dark matter in quantities of 500% of normal matter.

Very good precission: 500%. ;D

Title: Re: Multicore/multiprocessor/multisystem version o
Post by inetd on 10/10/13 at 08:57:33

Hello, guys!!

Sorry for long silence from my side (:

I have also thought about the multicore solution from technical point of view.
And for first view, task is pretty tough, especially when you are trying to build some chain (ring) of objects and calculate them.
Previously I had some experience with such chains in programming. For example we have the chain with 4 objects and we need to calculate them in pairs with each other.
Technically I had solved such a task like fixing pointer for [obj_1] and cycling to end of the chain and interacting [obj_1]-[obj_2], [obj_1]-[obj_3], [obj_1]-[obj_4].
Then moving pointer to [obj_2] and cycling to end of the chain and interacting [obj_2]-[obj_3], [obj_2]-[obj_4]
And last moving pointer to [obj_3] and cycling to end of the chain and interacting [obj_3]-[obj_4]

In such solution really very tough divide chain into subchains and calculate them separately.

BUT now I am thinking that mr.WIL is right - actually we have the system with fixed number of equations (interactions) between two objects.
So technically we can try to solve the multicore task like this: create some long array of interaction_pairs. For example [obj_1, obj_2]; [obj_1, obj_3]; [obj_1, obj_4]; [obj_2, obj_3]; [obj_2, obj_4]; [obj_3, obj_4].
And after that we can divide array for some dedicated threads.

The only issue with such array is to prevent SEAMLESS access from different threads to the SAME object, like {trd_1}<-[obj_1, obj_2] seamless with {trd_2}<-[obj_2, obj_3]

What do you think?

Gravity Simulator » Powered by YaBB 2.1!
YaBB © 2000-2005. All Rights Reserved.