Multi-core Computing

Message boards : Questions and problems : Multi-core Computing
Message board moderation

To post messages, you must log in.

AuthorMessage
foobar1234567890

Send message
Joined: 17 Sep 12
Posts: 23
United States
Message 47277 - Posted: 15 Jan 2013, 16:18:49 UTC

I know this has been brought up ad nauseam, but will the next version of BOINC have the ability to run the same task on multiple cores at once? I have a dual-core machine, and individual tasks (for, say, ClimatePrediction.net) would run a whole lot faster with this capability.
ID: 47277 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15060
Netherlands
Message 47281 - Posted: 15 Jan 2013, 16:41:55 UTC - in response to Message 47277.  

BOINC doesn't run any tasks, so it never needs to be able to do that. It's the science application that must be capable of so-called multi-threading. So you'll have to ask CPDN in this case if they can make an application that can do so.
ID: 47281 · Report as offensive
foobar1234567890

Send message
Joined: 17 Sep 12
Posts: 23
United States
Message 47318 - Posted: 16 Jan 2013, 18:51:32 UTC - in response to Message 47281.  

Can't the BOINC project kind of thumbscrew its most popular projects into doing this?
ID: 47318 · Report as offensive
SekeRob2

Send message
Joined: 6 Jul 10
Posts: 585
Italy
Message 47320 - Posted: 16 Jan 2013, 19:08:39 UTC - in response to Message 47318.  
Last modified: 16 Jan 2013, 19:14:19 UTC

There's where is benefit and where is not, a balance between complicating things [and adding overhead] and runtime and system resource use. I know one project that has one science it would like to multithread for very good reason. Whilst, it's not Berkeley's business to thumbscrew. Development actually for a substantial part is directed by the projects.

edit: There's actually one thing that bothers me about multithreaders: On a multi-core device, let's assume an octo, at some point this MT project gets it's turn. It will then pre-empt all other single threaded sciences. For 1 of 8 it can do thatt at checkpoint save, but the others will be somewhere in-between. What happens with those tasks if LAIM is not on [mine is always on]? They probably unload. Imagine you're running sciences that have checkpoint intervals that are long, longer, longest... the candidate science I mentioned has some from 3 to 6 hours and more depending on device speed. Worth thinking about what projects you mix when MT projects are involved.
Coelum Non Animum Mutant, Qui Trans Mare Currunt
ID: 47320 · Report as offensive
kdsjsdj

Send message
Joined: 5 Jan 13
Posts: 81
Message 47326 - Posted: 16 Jan 2013, 20:50:41 UTC - in response to Message 47318.  

Can't the BOINC project kind of thumbscrew its most popular projects into doing this?


How?

And why? Some algorithms simply do not lend themselves to multi-threading so there is absolutely 0 benefit to be gained from making them mt. You want BOINC to thumbscrew projects into spending many man hours on converting their app to mt when it won't help them at all? Nope! That'll never happen.
ID: 47326 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15060
Netherlands
Message 47327 - Posted: 16 Jan 2013, 20:58:24 UTC - in response to Message 47318.  

Can't the BOINC project kind of thumbscrew its most popular projects into doing this?

There is no BOINC Project. It doesn't do any science, that's all done by the project's science applications.

BOINC is an open source software, the projects that are using it are free to use it in any way they see fit, they aren't threatened, corralled, poked at or put in thumb screws over anything.
ID: 47327 · Report as offensive
Joe Bloggs

Send message
Joined: 6 Jan 13
Posts: 40
Hong Kong
Message 47338 - Posted: 17 Jan 2013, 6:29:39 UTC

The WUs ARE multithreaded though?

I open process explorer and each WU process under BOINC (e.g. wcg_hcc1 for a WCG help conquer cancer WU) has at least 3 threads, most of them 4?
ID: 47338 · Report as offensive
BilBg
Avatar

Send message
Joined: 18 Jun 10
Posts: 73
Bulgaria
Message 47341 - Posted: 17 Jan 2013, 7:01:05 UTC - in response to Message 47338.  


Those threads are not computing, e.g. one of them (probably) is for communication with BOINC
Run Process Explorer and in Properties window (click the process, Alt+Enter) see in Threads tab for CPU usage per thread.





- ALF - "Find out what you don't do well ..... then don't do it!" :)
ID: 47341 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4819
United Kingdom
Message 47345 - Posted: 17 Jan 2013, 10:00:47 UTC

You can read our fun and games with a true multi-threaded application at MilkyWay Nbody 1.04. The app is MT, BOINC fully schedules and supports it - but the project admins haven't quite mastered the art of loading it on their servers with the required parameters yet.
ID: 47345 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15060
Netherlands
Message 47346 - Posted: 17 Jan 2013, 12:22:14 UTC - in response to Message 47338.  

The WUs ARE multithreaded though?

Workunits or tasks, depending on what you call them, are just blocks of hexadecimal data or text. They have no moving parts, they aren't executable, therefore they aren't multithreaded either.

If anything needs to be multithreaded it is the science applications and nothing else. That's the thing that is executable and uses up memory. A thread is just the smallest sequence of programmed instructions that an operating system can handle. It'll run multiple of them for just about any process you start up, depending on how that process is programmed.

I have a 4 core CPU (i5-2500K).
Winamp's winamp.exe runs at 13 threads on my computer. Is it therefore multithreaded?
Process Explorer's 64bit procexp64.exe runs at 6 threads on my computer. Is it therefore multithreaded?
Skype's skype.exe runs at 21 threads on my computer. Is it therefore multithreaded?

And then equally so,
Each of Seti's AK_V8b2_win_x64_SSE.exe runs at 3 threads on my computer. Are they therefore multithreaded?

Now careful...
The Einstein BRP4 GPU application einstein_BRP4_1.32_windows_x86_64__opencl-ati.exe has two threads with that name. Is it therefore multithreading on my GPU?

Sure, they all are multithreading, just not specifically done so to allow work to be processed in parallel on the same computer cores. It's just done to spread the memory load of the program over multiple computer cores, even to make it easier to debug said program.

Just think what would be easier to run (load into memory), a single program of 1 million lines, or a program that loads 100,000 lines and has 9 brethren doing the same. Those 10 threads together would then technically be multithreading.

If you want to learn more about threads, multithreading, hyperthreading etc. there's plenty of search engines available.
ID: 47346 · Report as offensive
skgiven
Avatar

Send message
Joined: 19 Aug 08
Posts: 87
United Kingdom
Message 47351 - Posted: 17 Jan 2013, 15:21:41 UTC - in response to Message 47346.  
Last modified: 17 Jan 2013, 15:22:47 UTC

If an mt-app, such as Sim1, runs using all the CPU cores/threads, and there is a GPU in the system, no work will be done on the GPU while the mt-app is running. Hardly a desirable situation! While Virtualization can be used to better allocate CPU and GPU resources, setting up and maintaining VM's is hardly something for the average cruncher and performance tends to fall.

Normally it's more productive to run 'single-threaded' tasks, and the best way for task sizes to be controlled is at the project level. Climateprediction have already created smaller models to accommodate lesser systems and infrequent users.
Years ago I was told that it wasn't possible to run one climate model on multiple processor cores. I expect that hasn't changed.
ID: 47351 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4819
United Kingdom
Message 47353 - Posted: 17 Jan 2013, 15:56:22 UTC - in response to Message 47351.  
Last modified: 17 Jan 2013, 15:59:00 UTC

If an mt-app, such as Sim1, runs using all the CPU cores/threads, and there is a GPU in the system, no work will be done on the GPU while the mt-app is running.

I remember that one. I think it was a client bug that only lasted a few versions, and I thought it had been fixed. Does it still happen with the v7.0.44 current alpha?

Edit - ah, yes, there it is. Changeset f2c38486, July 2012.
ID: 47353 · Report as offensive
skgiven
Avatar

Send message
Joined: 19 Aug 08
Posts: 87
United Kingdom
Message 47358 - Posted: 17 Jan 2013, 20:16:49 UTC - in response to Message 47353.  
Last modified: 17 Jan 2013, 20:20:21 UTC

Hi Richard,

Yes, for Sim1 the mt problem(s) existed with 7.0.28, 7.0.42 and still exist with 7.0.44

W7x64, i7-3770K (8threads), 8GB DDR3, SSD, GTX660Ti + GTX470 (and same issue on a different rig).
When CPU usage was limited to 75% (Boinc Manager) Sim1 grabbed all 6 'available' CPU threads, and thus interfered with GPU crunching:
I was running POEM on the GTX660Ti, with the GTX470 excluded as that fails - a project-specific multiple GPU issue. So app_info used to run two or more tasks at a time for POEM (1 CPU each), and cc_config preventing GPU in slot 1 (GTX470) from being used for POEM. The GTX470 was running Albert work (just one task at a time and 0.23CPUs).
When Sim1 started the GTX470 stopped running tasks (being in slot 1 and Slot 0 rightly getting preferential treatment) but the GTX660Ti only ran one task.
Before running Sim1 the CPU usage was just over 75% so Boinc was reserving cores for the GPU's according to the app_info.
When Sim1 started the CPU usage rose to 88 or 89% (so 7 CPU cores were being used)
When I reduced the number of CPUs to use (74%) Sim1 stopped, waiting for 6CPU threads to run on. If I then exited and started Boinc it still waited for 6CPU cores - so it would never finish!
When I increased the CPU back to 75% Sim1 started again. CPU usage rose to 88% and one PEOM task ran. I suspect the manager or Sim1 is not fully aware of the app_info settings.
When I increased the CPU to 99% a second POEM task started on the same GPU (as it should be). Actual CPU usage was now at 100%.
When I increased the CPU from 99% to 100% (all 8threads), device 1 started to be used (GTX470 running an Albert task).

You can't keep the CPU count at 100% or Sim1 will want to run the next task on all 8threads.

What we need is Sim1 (or any mt app) to count the number of available CPU's and subtract the number used by GPU's. I'm not sure where the mt app gets its available CPU count from, but it seems to be a different place than the non mt apps, as only 4 CPU tasks normally run on that system when I'm running two POEM tasks and have the CPU set to 75%.

If you want any further testing, let me know what flags to set, in addition to cpu_sched_debug.
ID: 47358 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4819
United Kingdom
Message 47359 - Posted: 17 Jan 2013, 21:14:53 UTC - in response to Message 47358.  

Hi Richard,

Yes, for Sim1 the mt problem(s) existed with 7.0.28, 7.0.42 and still exist with 7.0.44

W7x64, i7-3770K (8threads), 8GB DDR3, SSD, GTX660Ti + GTX470 (and same issue on a different rig).
When CPU usage was limited to 75% (Boinc Manager) Sim1 grabbed all 6 'available' CPU threads, and thus interfered with GPU crunching:
I was running POEM on the GTX660Ti, with the GTX470 excluded as that fails - a project-specific multiple GPU issue. So app_info used to run two or more tasks at a time for POEM (1 CPU each), and cc_config preventing GPU in slot 1 (GTX470) from being used for POEM. The GTX470 was running Albert work (just one task at a time and 0.23CPUs).
When Sim1 started the GTX470 stopped running tasks (being in slot 1 and Slot 0 rightly getting preferential treatment) but the GTX660Ti only ran one task.
Before running Sim1 the CPU usage was just over 75% so Boinc was reserving cores for the GPU's according to the app_info.
When Sim1 started the CPU usage rose to 88 or 89% (so 7 CPU cores were being used)
When I reduced the number of CPUs to use (74%) Sim1 stopped, waiting for 6CPU threads to run on. If I then exited and started Boinc it still waited for 6CPU cores - so it would never finish!
When I increased the CPU back to 75% Sim1 started again. CPU usage rose to 88% and one PEOM task ran. I suspect the manager or Sim1 is not fully aware of the app_info settings.
When I increased the CPU to 99% a second POEM task started on the same GPU (as it should be). Actual CPU usage was now at 100%.
When I increased the CPU from 99% to 100% (all 8threads), device 1 started to be used (GTX470 running an Albert task).

You can't keep the CPU count at 100% or Sim1 will want to run the next task on all 8threads.

What we need is Sim1 (or any mt app) to count the number of available CPU's and subtract the number used by GPU's. I'm not sure where the mt app gets its available CPU count from, but it seems to be a different place than the non mt apps, as only 4 CPU tasks normally run on that system when I'm running two POEM tasks and have the CPU set to 75%.

If you want any further testing, let me know what flags to set, in addition to cpu_sched_debug.

If Sim1 is set up the same way as AQUA used to be (which is the same as the way the new Milkyway app appears to want to run under app_info), the number of CPU cores the task is going to use is 'locked in' to that task at the time the task is allocated by the server.

In other words, to perform the sort of tests you're describing, you need to

* Set NNT, and finish existing work
* Change to the CPU setting you want to test
* Allow new work to be allocated at that CPU setting

Clumsy and clunky, but the only way I know to perform a valid test - unless you want to dive into client_state.xml every time you change a CPU setting, and edit

* Both <avg_ncpus> and <max_ncpus> for the application
* <cmdline>--nthreads 8</cmdline>

The first determines whether or not BOINC will schedule the task with the number of cores you've chosen: the second determines how many threads the application actually spawns, irrespective of the number of cores BOINC is expecting it to use.

The other complication is the number of GPU(s) and GPU tasks you're trying to run at the same time. If you add up all the fractional CPU demands for the GPU tasks (the fictional numbers displayed by BOINC, not the actual amount you might calculate for yourself), and if the total is equal to or greater than 1.000000, BOINC probably won't schedule everything you want to run concurrently.

At AQUA, I got round that by wrapping the MT AQUA apps in an app_info.xml file specifying <....ncpus> as 2.1 or 3.1, for apps I wanted to run 3-threaded or 4-threaded respectively with matching <cmdline> settings. That allowed an extra 0.9 CPUs for the GPU apps I was running: but that experiment long predated the changeset I pointed you to, and I haven't got far enough into Milkyway's N-body apps to re-test yet (we're still waiting for the v1.06 bug-fix release).
ID: 47359 · Report as offensive
Joe Bloggs

Send message
Joined: 6 Jan 13
Posts: 40
Hong Kong
Message 47363 - Posted: 18 Jan 2013, 2:03:46 UTC

Might you be able to specify the number of CPUs used using the new app_config.xml feature of 7.0.4x?
ID: 47363 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4819
United Kingdom
Message 47370 - Posted: 18 Jan 2013, 9:17:57 UTC - in response to Message 47363.  

Might you be able to specify the number of CPUs used using the new app_config.xml feature of 7.0.4x?

The <max_ncpus> - probably yes.

The <cmdline>--nthreads - almost certainly not. So you would probably find that the application used a different number of threads from the number of cores that BOINC had allocated. I can't think that that would be a good idea, in general.
ID: 47370 · Report as offensive
SekeRob2

Send message
Joined: 6 Jul 10
Posts: 585
Italy
Message 47372 - Posted: 18 Jan 2013, 10:42:20 UTC - in response to Message 47370.  

Let's not call tags by some name that's not documented. It's called <max_concurrent>. All possible current lines documented for app_config.xml are:

<app_config>
   <app>
      <name>shortname</name>
      <max_concurrent>1</max_concurrent>
      <gpu_versions>
          <gpu_usage>.n</gpu_usage>
          <cpu_usage>.n</cpu_usage>
      </gpu_versions>
    </app>
</app_config>


Someone also inserted <user_friendly> after <name> which did not throw an error message.

Whence whatever next client is ready to RPC the app_config.xml content over to the servers 7xx, and the servers have the code to do something with it, I'm hoping also to see an <in_progress> or something of that intend. This would allow them to know how much work of each science a specific host would want at most [of course higher what the project allows would not be exceeded]. There's toying with a [standard] multiplier idea of what <max_concurrent> indicates... for instance if you specify max=4, the host would not get more than 20, if the multiplier were 5 (maybe to be set per-science, so that the known regular length of a science can be considered... multiplier 5 if a task lasts 10 hours and 20 when a task lasts 2.5 hours, which for multi science projects would help to balance mixes for a host].
Coelum Non Animum Mutant, Qui Trans Mare Currunt
ID: 47372 · Report as offensive

Message boards : Questions and problems : Multi-core Computing

Copyright © 2022 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.