# of Cores in Relation to WUs?
log in

Advanced search

Message boards : CPU : # of Cores in Relation to WUs?

Author Message
Yavanius
Avatar
Send message
Joined: 18 Nov 16
Posts: 42
Credit: 454,617
RAC: 0
Message 84 - Posted: 26 Nov 2016, 21:27:26 UTC

I'm curious to know how the # of cores affects work delivered or is it all the same and whatever # of cores is available will be utilized to the maximum?

I was playing with the # of cores and within sets of work, the estimated time stayed the same for 4, 3, and 2 cores.

I did note (and I don't know if this due to the way BOINC works) is that if I shut down the project and came back, all the WUs changed to 4 cores. I never tried testing that with any other projects that had multi-core support. It's certainly not a bad thing sofar as I can tell.

Yavanius
Avatar
Send message
Joined: 18 Nov 16
Posts: 42
Credit: 454,617
RAC: 0
Message 87 - Posted: 27 Nov 2016, 6:28:57 UTC - in response to Message 84.

I'll have to check with the BOINC folks, but I noticed some peculiarities.

For some reason if reduce my cores and a WU is obtained and noted for that many cores, other projects are not running even if I bump the available cores back up. Interestingly, if I have a max core WU it will run if I have less cores available and they are running other projects then I increase the cores, XANSONS happily runs with two cores even though it says 4 cores. Subsequent WUs however will take over those two cores running other projects.

None of this may necessarily be because of this project and may just be how BOINC behaves, but just a note anyways...

Vlad
Project administrator
Project developer
Project tester
Project scientist
Help desk expert
Send message
Joined: 26 Oct 16
Posts: 322
Credit: 103,382
RAC: 0
Message 92 - Posted: 27 Nov 2016, 10:11:10 UTC
Last modified: 27 Nov 2016, 10:14:28 UTC

That's an interesting question. Two questions, actually.
1) How the client estimates the remaining time?
2) What number of available threads client report to the app?

1) The native BOINC apps report their progress to the client from time to time by calling the respective function. So, the remaining time displayed by the client is usually correct in this case. But if the app is not native and uses the BOINC wrapper to run (like in this project), the remaining time is estimated using the two values: estimated number of FLOPS, I provide for each WU, and the Whetstone index of the CPU (or the theoretical peak performance of the GPU). The problem is that client for some reason ignores the number of threads). But anyway, since the atomic density of the structure is not calculated prior to WU creation, it's hard to estimate the number of FLOPS, so even if the client will take the number of threads into account, the remaining time will stay incorrect. This problem will be solved when I write the native apps.

2) Let's say you have reduced the CPU usage to 75% and your CPU has 4 threads. Then you get the single-threaded WU from other project, so the number of remaining threads is 2. And then you get the multi-threaded WU. The multi-threaded app asks the client for the number of threads to use and for some reason, despite the one thread is already in use, the returned number will be 3 (75%). So the CPU load will be 100% and your request to save the 25% of CPU time will be ignored. I have no idea, why this is implemented this way. However, when the single-threaded WU is completed, the new one will not start, because all three threads are already in use.

Profile bcavnaugh
Avatar
Send message
Joined: 13 Jul 17
Posts: 6
Credit: 6,988,821
RAC: 0
Message 417 - Posted: 14 Aug 2017, 17:15:59 UTC

It would be nice to split up 48 or 56 and even 32 Cores / Threads.

I did test this with no luck

<app_config>
<app>
<name>xansons_gpu</name>
<gpu_versions>
<gpu_usage>1.0</gpu_usage>
<cpu_usage>0.2</cpu_usage>
</gpu_versions>
</app>
<app>
<name>xansons_cpu</name>
<max_concurrent>4</max_concurrent>
<fraction_done_exact/>
</app>
<app_version>
<app_name>xansons_cpu</app_name>
<cmdline>-t 10</cmdline>
<avg_ncpus>10</avg_ncpus>
<max_ncpus>10</max_ncpus>
<app_version>
</app_config>
____________

Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community.

Vlad
Project administrator
Project developer
Project tester
Project scientist
Help desk expert
Send message
Joined: 26 Oct 16
Posts: 322
Credit: 103,382
RAC: 0
Message 418 - Posted: 14 Aug 2017, 18:28:29 UTC - in response to Message 417.

It would be nice to split up 48 or 56 and even 32 Cores / Threads.

I did test this with no luck

Your app_config has 2 errors:
(1) no plan class is specified,
(2) the correct option for the number of threads is --nthreads and not -t.
Here is the correct app_version section:
<app_version> <app_name>xansons_cpu</app_name> <plan_class>mt_windows</plan_class> <cmdline>--nthreads 10</cmdline> <avg_ncpus>10</avg_ncpus> </app_version>

Replace mt_windows with mt_linux in Linux.

Profile bcavnaugh
Avatar
Send message
Joined: 13 Jul 17
Posts: 6
Credit: 6,988,821
RAC: 0
Message 421 - Posted: 14 Aug 2017, 22:49:48 UTC - in response to Message 418.

It would be nice to split up 48 or 56 and even 32 Cores / Threads.

I did test this with no luck

Your app_config has 2 errors:
(1) no plan class is specified,
(2) the correct option for the number of threads is --nthreads and not -t.
Here is the correct app_version section:
<app_version> <app_name>xansons_cpu</app_name> <plan_class>mt_windows</plan_class> <cmdline>--nthreads 10</cmdline> <avg_ncpus>10</avg_ncpus> </app_version>

Replace mt_windows with mt_linux in Linux.


Thank you very much, Bill
____________

Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community.

Yavanius
Avatar
Send message
Joined: 18 Nov 16
Posts: 42
Credit: 454,617
RAC: 0
Message 482 - Posted: 15 Sep 2017, 1:07:51 UTC - in response to Message 417.

It would be nice to split up 48 or 56 and even 32 Cores / Threads.


56... You could share you know? ;)[/quote]

Yavanius
Avatar
Send message
Joined: 18 Nov 16
Posts: 42
Credit: 454,617
RAC: 0
Message 499 - Posted: 17 Sep 2017, 16:01:30 UTC

Just curious, how's the performance scale look on your end Vlad with the increase in the number of cores?

e.g. Does it scale linearly or exponentially, and about what ratio?

Cheers
~Yav

Vlad
Project administrator
Project developer
Project tester
Project scientist
Help desk expert
Send message
Joined: 26 Oct 16
Posts: 322
Credit: 103,382
RAC: 0
Message 506 - Posted: 18 Sep 2017, 16:28:29 UTC - in response to Message 499.

Just curious, how's the performance scale look on your end Vlad with the increase in the number of cores?

e.g. Does it scale linearly or exponentially, and about what ratio?

Cheers
~Yav

The performance scales almost linearly. It's "almost linearly" due to the small parts of the code in the beginning and in the end of the program, which are not parallelized.

Message boards : CPU : # of Cores in Relation to WUs?


Main page · Your account · Message boards


© 2021 Vladislav Neverov (NRC 'Kurchatov institute'), Nikolay Khrapov (Institute for Information Transmission Problems of RAS)