Welcome, Guest. Please Login.
Gravity Simulator
11/23/17 at 17:43:35
News: Registration for new users has been disabled to discourage spam. If you would like to join the forum please send me an email with your desired screen name to tony at gravitysimulator dot com.
Home Help Search Login


Pages: 1
Send Topic Print
Multicore/multiprocessor/multisystem version of GS (Read 7032 times)
inetd
Uploader



I Love YaBB 2!

Posts: 4
Multicore/multiprocessor/multisystem version of GS
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
Back to top
 
 
View Profile   IP Logged
EDG
Ultimate Member
*****


oh, crumbs!!!

Posts: 611
Gender: male
Re: Multicore/multiprocessor/multisystem version o
Reply #1 - 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)?
Back to top
 
 

(formerly known as Mal)
View Profile WWW   IP Logged
Tony
YaBB Administrator
*****




Posts: 1051
Gender: male
Re: Multicore/multiprocessor/multisystem version o
Reply #2 - 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.
Back to top
 
 
Email View Profile WWW   IP Logged
inetd
Uploader



I Love YaBB 2!

Posts: 4
Re: Multicore/multiprocessor/multisystem version o
Reply #3 - 12/10/12 at 11:29:16
 
Quote from Tony on 12/04/12 at 19:29:18:
What you really want is a custom computer with one processor per object.

 Smiley Smiley Smiley Smiley
 
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 Smiley Smiley
 
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?
Back to top
 
 
View Profile   IP Logged
wil
Uploader



I Love YaBB 2!

Posts: 39
Re: Multicore/multiprocessor/multisystem version o
Reply #4 - 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.
Back to top
 
 
Email View Profile   IP Logged
EDG
Ultimate Member
*****


oh, crumbs!!!

Posts: 611
Gender: male
Re: Multicore/multiprocessor/multisystem version o
Reply #5 - 04/27/13 at 09:19:18
 
Quote from wil on 04/27/13 at 05:55:19:
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)
Back to top
 
 

(formerly known as Mal)
View Profile WWW   IP Logged
wil
Uploader



I Love YaBB 2!

Posts: 39
Re: Multicore/multiprocessor/multisystem version o
Reply #6 - 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.
Back to top
 
 
Email View Profile   IP Logged
Tony
YaBB Administrator
*****




Posts: 1051
Gender: male
Re: Multicore/multiprocessor/multisystem version o
Reply #7 - 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.
Back to top
 
 
Email View Profile WWW   IP Logged
EDG
Ultimate Member
*****


oh, crumbs!!!

Posts: 611
Gender: male
Re: Multicore/multiprocessor/multisystem version o
Reply #8 - 04/29/13 at 00:23:51
 
Quote from 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.

 
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?
Back to top
 
 

(formerly known as Mal)
View Profile WWW   IP Logged
wil
Uploader



I Love YaBB 2!

Posts: 39
Re: Multicore/multiprocessor/multisystem version o
Reply #9 - 05/03/13 at 07:21:39
 
Quote from 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.

 
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.as px
 
 
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!
Back to top
 
 
Email View Profile   IP Logged
frankuitaalst
Ultimate Member
*****


Great site

Posts: 1507
Gender: male
Re: Multicore/multiprocessor/multisystem version o
Reply #10 - 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 .
Back to top
 
 
Email View Profile   IP Logged
wil
Uploader



I Love YaBB 2!

Posts: 39
Re: Multicore/multiprocessor/multisystem version o
Reply #11 - 05/03/13 at 18:58:44
 
Quote from frankuitaalst on 05/03/13 at 12:33:33:
 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%. Grin
Back to top
 
 
Email View Profile   IP Logged
inetd
Uploader



I Love YaBB 2!

Posts: 4
Re: Multicore/multiprocessor/multisystem version o
Reply #12 - 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?
Back to top
 
 
View Profile   IP Logged
Pages: 1
Send Topic Print