Message boards :
Number crunching :
Multi-threaded nBody
Message board moderation
Author | Message |
---|---|
Send message Joined: 29 Sep 10 Posts: 54 Credit: 1,386,559 RAC: 0 |
Anyone willing to run some nbody apps with 1, 2, 4, and 8 threads to compare times? I'm curious how much the speedup really is. If you have an app_info.xml file, add the following param (changing the 4's at the end to whatever): <app><!-- stock app for N-Body --> <name>milkyway_nbody</name> <user_friendly_name>MilkyWay@Home nBody</user_friendly_name> </app> <file_info> <name>milkyway_nbody_0.40_x86_64-pc-linux-gnu__mt</name> <executable/> </file_info> <app_version> <app_name>milkyway_nbody</app_name> <version_num>40</version_num> <file_ref> <file_name>milkyway_nbody_0.40_x86_64-pc-linux-gnu__mt</file_name> <main_program/> </file_ref> <avg_ncpus>4</avg_ncpus> <max_ncpus>4</max_ncpus> <cmdline>--nthreads=4 </cmdline> </app_version> |
Send message Joined: 29 Sep 10 Posts: 54 Credit: 1,386,559 RAC: 0 |
Running 4 threads, I had one finish in 27 minutes. Running 8 threads, I had one finish in 8 minutes. Seems a bit off. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
You can't directly compare random workunits. The time a simulation takes depends directly on the parameters being fit. The main factor (besides the number of bodies) on the run time is the radius of the dwarf model; smaller models use smaller timesteps and run for longer times. The actual time run also is a parameter fit, and the masses also have an impact on the timestep size (though not as significant). Additionally, if the dwarf gets more ripped up and spread out, the simulation will also run faster. Right now the search seems to hanging out on the upper limits of the radius, so most of the workunits are running fairly quickly. I've made a plot on my system using a fixed set of parameters for the same thing as the current set of N-body runs: This is on my quad core + HT Sandy Bridge system @4.2Ghz for 1, 2, 4, 8 and 12 threads. The number in parentheses is the speedup over using 1 thread. If anyone is wondering these workunits are using 2 10,000 body models (20,000 total). As you can see, it's pretty close to what you can expect for effective use of a quad core system (with a tiny bit of help with the hyperthreading). |
Send message Joined: 7 May 10 Posts: 8 Credit: 39,603,036 RAC: 0 |
.40 WU are estimated at 5+ hours for me. Using all 6 of my 1055Ts CPU finishes a WU in just under 1 hour. Would be nice if other Projects could Multithread, especially ClimatePrediction. |
Send message Joined: 6 Mar 11 Posts: 6 Credit: 59,274 RAC: 0 |
i just finished a 1.95cpu one in 18.08mins on a phenom II x6 3ghz anyways i don't like these multithreaded apps my cores are already being used to run other wu's and wouldn't mind being able to turn it off also i wouldn't like to see other projects use multithreading boinc already allows multitasking either running multiple milkyway wu's or different wu's from other projects and i personally think these mt wu's are detrimental to other projects i only have 2 cpu's for crunching and the third for handing none boinc stuff so it doesn't interfere with wu's and trying to balance the cpu resources the best i can the only reason i tolerate it now is because its only 18mins if it took hours i would be pressing abort and no longer accepting wu's if milkyway wants to use mt units either give us an option to turn them on/off or send them to clients that have 8-12+ cores |
Send message Joined: 24 Dec 07 Posts: 1947 Credit: 240,884,648 RAC: 0 |
i just finished a 1.95cpu one in 18.08mins on a phenom II x6 3ghz anyways i don't like these multithreaded apps my cores are already being used to run other wu's and wouldn't mind being able to turn it off also i wouldn't like to see other projects use multithreading boinc already allows multitasking either running multiple milkyway wu's or different wu's from other projects and i personally think these mt wu's are detrimental to other projects i only have 2 cpu's for crunching and the third for handing none boinc stuff so it doesn't interfere with wu's and trying to balance the cpu resources the best i can the only reason i tolerate it now is because its only 18mins if it took hours i would be pressing abort and no longer accepting wu's if milkyway wants to use mt units either give us an option to turn them on/off or send them to clients that have 8-12+ cores But that is what resource share is all about... |
Send message Joined: 6 Mar 11 Posts: 6 Credit: 59,274 RAC: 0 |
resource share works perfectly for apps that use 1 cpu but for multithreaded it doesn't work also it ignores the %of the cpu's settings |
Send message Joined: 29 Sep 10 Posts: 54 Credit: 1,386,559 RAC: 0 |
To set the nBody application to only use a specific number of processors (or just 1 CPU), you have to create an app_info.xml file like the one at the top of this thread. Just replace the avg_ncpus, max_ncpus, and nthreads values with 1 instead of 4. However, the project should do this CPU limiting automatically. |
Send message Joined: 24 Dec 07 Posts: 1947 Credit: 240,884,648 RAC: 0 |
resource share works perfectly for apps that use 1 cpu but for multithreaded it doesn't work That is not correct. I've been running Aqua@home which is mt and resource share works fine with the other projects I run. also it ignores the %of the cpu's settings Ahh...I can't comment on that. Why do you want to limit the %cpu setting? |
Send message Joined: 7 May 10 Posts: 8 Credit: 39,603,036 RAC: 0 |
i just finished a 1.95cpu one in 18.08mins on a phenom II x6 3ghz anyways i don't like these multithreaded apps my cores are already being used to run other wu's and wouldn't mind being able to turn it off also i wouldn't like to see other projects use multithreading boinc already allows multitasking either running multiple milkyway wu's or different wu's from other projects and i personally think these mt wu's are detrimental to other projects i only have 2 cpu's for crunching and the third for handing none boinc stuff so it doesn't interfere with wu's and trying to balance the cpu resources the best i can the only reason i tolerate it now is because its only 18mins if it took hours i would be pressing abort and no longer accepting wu's if milkyway wants to use mt units either give us an option to turn them on/off or send them to clients that have 8-12+ cores My Preferences are set to switch every hour and MW doesn't give me too many CPU WU. So it doesn't affect my other 3 Projects(ClimatePrediction, Einstein, Rosetta) much |
Send message Joined: 5 Apr 09 Posts: 71 Credit: 6,120,786 RAC: 0 |
home that does not work, they go all in error ... <app> <name>milkyway_nbody</name> <user_friendly_name>MilkyWay@Home nbody Simulation</user_friendly_name> </app> <file_info> <name>milkyway_nbody_0.40_windows_x86_64__mt.exe</name> <executable/> </file_info> <app_version> <app_name>milkyway_nbody</app_name> <version_num>40</version_num> <plan_class>mt</plan_class> <avg_ncpus>4</avg_ncpus> <max_ncpus>4</max_ncpus> <cmdline>--nthreads=4</cmdline> <file_ref> <file_name>milkyway_nbody_0.40_windows_x86_64__mt.exe</file_name> <main_program/> </file_ref> <file_info> <name>libgomp_64-1.dll</name> <executable/> </file_info> <file_info> <name>pthreadGC2_64.dll</name> <executable/> </file_info> </app_version> Team Alliance francophone, boinc: 7.0.18 GA-P55-UD5, i7 860, Win 7 64 bits, 8g DDR3, GTX 470 |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
<app> <name>milkyway_nbody</name> <user_friendly_name>MilkyWay@Home nbody Simulation</user_friendly_name> </app> <file_info> <name>milkyway_nbody_0.40_windows_x86_64__mt.exe</name> <executable/> </file_info> <file_info> <name>libgomp_64-1.dll</name> <executable/> </file_info> <file_info> <name>pthreadGC2_64.dll</name> <executable/> </file_info> <app_version> <app_name>milkyway_nbody</app_name> <version_num>40</version_num> <plan_class>mt</plan_class> <avg_ncpus>4</avg_ncpus> <max_ncpus>4</max_ncpus> <cmdline>--nthreads=4</cmdline> <file_ref> <file_name>milkyway_nbody_0.40_windows_x86_64__mt.exe</file_name> <main_program/> </file_ref> <file_ref> <file_name>libgomp_64-1.dll</file_name> </file_ref> <file_ref> <file_name>pthreadGC2_64.dll</file_name> </file_ref> </app_version> Marked in bold are the lines you need to change. Attention! This is only the part for the nbody application! If this is the only stuff in your app_info.xml, you need to add the <app_info> at top and </app_info> at the bottom of the file. |
Send message Joined: 6 Mar 11 Posts: 6 Credit: 59,274 RAC: 0 |
another problem if you only have 2 cpu's crunching and one of your cpu's is working on a wu running at high priority because boinc's client is broken and thinks a wu with a deadline a year away needs to be finished as soon as possible and then wants to crunch a mt 2.00 cpu wu it can make boinc's client just use 1 cpu for the high priority job and the other wu's left on a ready/waiting state and the second cpu left idle |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
Try a variation of the app_info.info above: <app_info> <app> <name>milkyway_nbody</name> <user_friendly_name>MilkyWay@Home nbody Simulation</user_friendly_name> </app> <file_info> <name>milkyway_nbody_0.40_windows_x86_64__mt.exe</name> <executable/> </file_info> <file_info> <name>libgomp_64-1.dll</name> <executable/> </file_info> <file_info> <name>pthreadGC2_64.dll</name> <executable/> </file_info> <app_version> <app_name>milkyway_nbody</app_name> <version_num>40</version_num> <plan_class>mt</plan_class> <cmdline>--nthreads=1</cmdline> <file_ref> <file_name>milkyway_nbody_0.40_windows_x86_64__mt.exe</file_name> <main_program/> </file_ref> <file_ref> <file_name>libgomp_64-1.dll</file_name> </file_ref> <file_ref> <file_name>pthreadGC2_64.dll</file_name> </file_ref> </app_version> </app_info> Marked in bold are the lines for a win64 system, you might need to change those. Check for the proper names in your mw directory. |
©2025 Astroinformatics Group