CPU time difference

Message boards : Number crunching : CPU time difference
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4

AuthorMessage
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1795346 - Posted: 11 Jun 2016, 12:18:45 UTC - in response to Message 1794766.  
Last modified: 11 Jun 2016, 12:32:32 UTC


It was recommended they suspend GPU work several days ago to see how it effected their CPU processing times. No feedback was provided as to the results or if it was tried.
Ivy Bridge & Haswell based CPUs have shown using SETI@home apps on the CPU & iGPU at the same time would cause CPU apps to run more slowly. From one host with a Skylake i5 it was thought that the CPU slowdown may be greater on the newest CPUs. If that is true I would speculate that the increased iGPU speed in Skylake may be causing even more "cache thrashing". It has been speculated that running an app from a less cache heavy app on either the CPU or iGPU may be the solution, but I'm not sure anyone has set down and tested that yet.


. .

. . I5-6400 (2.7GHz) HD530 GPU.

. . Runtime for CPU non VLAR tasks with iGPU crunching approx 3.5 hours

. . Runtime same tasks with GPU use discontinued approx 2 hours

. . Runtime with Lunatics 0.44 running AVX approx 1 hour 15 mins.

. . And since 2 cores are hyperthreading does that not mean there is competition for the associated maths unit? I would think it would be best to try just 2 basic cores under lunatics and compare his productivity then.
ID: 1795346 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 1795368 - Posted: 11 Jun 2016, 14:21:54 UTC - in response to Message 1795346.  


It was recommended they suspend GPU work several days ago to see how it effected their CPU processing times. No feedback was provided as to the results or if it was tried.
Ivy Bridge & Haswell based CPUs have shown using SETI@home apps on the CPU & iGPU at the same time would cause CPU apps to run more slowly. From one host with a Skylake i5 it was thought that the CPU slowdown may be greater on the newest CPUs. If that is true I would speculate that the increased iGPU speed in Skylake may be causing even more "cache thrashing". It has been speculated that running an app from a less cache heavy app on either the CPU or iGPU may be the solution, but I'm not sure anyone has set down and tested that yet.


. .

. . I5-6400 (2.7GHz) HD530 GPU.

. . Runtime for CPU non VLAR tasks with iGPU crunching approx 3.5 hours

. . Runtime same tasks with GPU use discontinued approx 2 hours

. . Runtime with Lunatics 0.44 running AVX approx 1 hour 15 mins.

. . And since 2 cores are hyperthreading does that not mean there is competition for the associated maths unit? I would think it would be best to try just 2 basic cores under lunatics and compare his productivity then.


Nearly double CPU run time when using the iGPU is similar to previous observations.
My initial posts when I noticed it occurring
A journey: iGPU slowing CPU processing
iGPU tuning
Raistmer's research thread
Loading APU to the limit: performance considerations - ongoing research
It would be interesting to see the results of a CPU where the iGPUs has a dedicated cache to use. Typically only the Iris Pro iGPUs have the addition cache, but the current generation Iris 540 & 550 also list a dedicated iGPU cache. I suspect that little to no CPU slowdown will occur. Similar to the results I found with my Celeron J1900, Bay Trail, CPU when using the iGPU.

To run HT or not is an often debated topic here. I have always seen an increase in work output when using HT.
There are a few different configurations to test how well using HT works in a specific configuration after a baseline using all cores & threads has been found.
1) Disable HT in their BIOS.
2) Leave HT enabled & reduce the number of CPU threads BOINC is allowed to run.
3) Leave HT enabled, reduce the number of CPU threads BOINC is allowed to run, & start BOINC with affinity settings only allowing the physical cores to be used.
Running 4 CPU tasks at once on my i7-860 I found no real noticeable difference using config #3 over #2, but config #1 was slightly worse. Running 8 CPU tasks at once on my i7-860 I found an 11.1% increase in power consumption & a 27.7% increase in work output.

I have not run similar test on my i3-390M system. I will typically just use its Radeon GPU. As it is a notebook it doesn't really have the thermal capacity to run the GPU+CPU full tilt & the GPU can do about as much work as the CPU alone.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 1795368 · Report as offensive
Matthew@SETI@home

Send message
Joined: 14 Feb 16
Posts: 40
Credit: 9,278,146
RAC: 6
United States
Message 1797809 - Posted: 21 Jun 2016, 23:42:03 UTC
Last modified: 21 Jun 2016, 23:48:57 UTC



The precise placement of the bold vertical lines depends on two unknowns: (1) Does the graph use UTC or local time? and (2) What time-of-day is represented by the vertical gridlines? As closely as can be determined from the posts in this thread, the two changes to settings were made at roughly 18:00 5 June UTC and roughly 19:00 9 June UTC. I am at UTC-5.

But I think the evidence is clear enough regardless. On this computer, and likely on all Core i3's, the best settings are 100% of CPUs and GPU tasks disabled.

I will wait until this climb levels out a little (I want to see how far it will go first) and then try disabling GPU on one of my other i3's. If I don't post here to the contrary, you may assume that a similar improvement was seen.
ID: 1797809 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13720
Credit: 208,696,464
RAC: 304
Australia
Message 1797814 - Posted: 22 Jun 2016, 0:02:18 UTC - in response to Message 1797809.  
Last modified: 22 Jun 2016, 0:09:18 UTC

The precise placement of the bold vertical lines depends on two unknowns: (1) Does the graph use UTC or local time? and (2) What time-of-day is represented by the vertical gridlines? As closely as can be determined from the posts in this thread, the two changes to settings were made at roughly 18:00 5 June UTC and roughly 19:00 9 June UTC. I am at UTC-5.

The problem with RAC is the way it is calculated means it tends to be slow to respond change. Also the larger your cache, the slower the response. And it also depends very much on your wingmen & how quickly they return their results.
The best way to determine how things are going is to check the actual runtimes for WUs, keeping in mind the different runtimes for shorties, midrange units & longer running WUs (and then the longer still runtimes & their variability for Guppies).


But I think the evidence is clear enough regardless. On this computer, and likely on all Core i3's, the best settings are 100% of CPUs and GPU tasks disabled.

I think that's been the general conclusion of most people that have given crunching using their Intel on die GPU.
It shares power, bandwidth & heat constraints with the CPU, and it appears that the increased output from the iGPU doesn't offset the loss in CPU output when running work on both, and disabling CPU cores to further boost the iGPU still doesn't offset the loss of CPU processing.
While you can crunch on the iGPU, with the current generation there's no real benefit in doing so.
Grant
Darwin NT
ID: 1797814 · Report as offensive
Matthew@SETI@home

Send message
Joined: 14 Feb 16
Posts: 40
Credit: 9,278,146
RAC: 6
United States
Message 1797816 - Posted: 22 Jun 2016, 0:07:40 UTC - in response to Message 1797814.  
Last modified: 22 Jun 2016, 0:58:24 UTC

I think that's been the general conclusion of most people that have given crunching using their Intel on die GPU.

That's been my point throughout this thread. Raistmer said on 5 June: "Try to limit number of cores BOINC use to 2 instead of 4. How this will affect runtime?" - and nary a soul spoke up and said, "Hey Raistmer, that's inconsistent with the general conclusion." Thus pulling an i3 user who came here seeking expert advice in two different directions. Hopefully this will make things easier for future such users.

The best way to determine how things are going is to check the actual runtimes for WUs, keeping in mind the different runtimes for shorties, midrange units & longer running WUs (and then the longer still runtimes & their variability for Guppies).

I tried that, and it proved unworkable by someone at my level of knowledge. Most of the comparisons were between my CPU task and the wingman's GPU task. Others between my CPU and an i5 CPU. There just wasn't enough data for me to see anything meaningful in those comparisons. The tasks are not kept in the list long enough for me to have compared my current usage with my "before the change" usage (and I wouldn't really know what attributes constitute an apples-to-apples comparison anyway). But my tasks list appears to be publicly available, so anyone could have had a look.

This is why I suggested a way to run the same task before and after, easy enough for someone like me to use. Without making it that easy, only the gurus can maximize their contributions to the project, and that's hardly good for the project. I think many of us are probably in the field of software design/development, so we're in the business of making things easy for those less knowledgeable than ourselves. That skill could be applied here in my opinion.
ID: 1797816 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 1797825 - Posted: 22 Jun 2016, 0:35:04 UTC - in response to Message 1797816.  

I think that's been the general conclusion of most people that have given crunching using their Intel on die GPU.

That's been my point throughout this thread. Raistmer said on 5 June: "Try to limit number of cores BOINC use to 2 instead of 4. How this will affect runtime?" Apparently he hadn't received the memo. Now, with any luck, he has.

It is a known issue. I believe all previous tests were performed on i5 CPUs. Where HT was not a factor. So it would make sense to see if HT was a factor. Also checking how the current gen hardware responds with the newest app version is useful information.

The right mix of project CPU & iGPU apps is still an unknown. There are several projects that offer CPU & iGPU apps if you wish to experiment.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 1797825 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13720
Credit: 208,696,464
RAC: 304
Australia
Message 1797829 - Posted: 22 Jun 2016, 0:49:43 UTC - in response to Message 1797816.  
Last modified: 22 Jun 2016, 0:50:04 UTC

The best way to determine how things are going is to check the actual runtimes for WUs, keeping in mind the different runtimes for shorties, midrange units & longer running WUs (and then the longer still runtimes & their variability for Guppies).

I tried that, and it proved unworkable by someone at my level of knowledge. Most of the comparisons were between my CPU task and the wingman's GPU task. Others between my CPU and an i5 CPU. There just wasn't enough data for me to see anything meaningful in those comparisons. The tasks are not kept in the list long enough for me to have compared my current usage with my "before the change" usage (and I wouldn't really know what attributes constitute an apples-to-apples comparison anyway). But my tasks list appears to be publicly available, so anyone could have had a look.

I was suggesting keeping an eye on & comparing the processing time between your WUs, instead of relying on RAC to see what worked or didn't work best.
Grant
Darwin NT
ID: 1797829 · Report as offensive
Matthew@SETI@home

Send message
Joined: 14 Feb 16
Posts: 40
Credit: 9,278,146
RAC: 6
United States
Message 1797831 - Posted: 22 Jun 2016, 0:54:54 UTC - in response to Message 1797829.  

See my updates above.
ID: 1797831 · Report as offensive
Matthew@SETI@home

Send message
Joined: 14 Feb 16
Posts: 40
Credit: 9,278,146
RAC: 6
United States
Message 1797836 - Posted: 22 Jun 2016, 1:26:52 UTC - in response to Message 1797831.  
Last modified: 22 Jun 2016, 1:38:44 UTC

And it also depends very much on your wingmen & how quickly they return their results.

The downturn on 5 June is within the normal statistical variability, as seen by the history prior to that. It certainly didn't go up, however. The dramatic upturn 12 days ago, so close to that settings change and continuing until present (there has not been a single "down" day since the climb started), cannot be explained by a change in overall wingman behavior. I disagree that RAC is not useful for this purpose. But I'll let you know if I see an equally dramatic fall in RAC, indicating that the climb was an aberration.
ID: 1797836 · Report as offensive
Matthew@SETI@home

Send message
Joined: 14 Feb 16
Posts: 40
Credit: 9,278,146
RAC: 6
United States
Message 1797856 - Posted: 22 Jun 2016, 3:09:43 UTC
Last modified: 22 Jun 2016, 3:17:15 UTC

Self-quote:

I will wait until this climb levels out a little (I want to see how far it will go first) and then try disabling GPU on one of my other i3's. If I don't post here to the contrary, you may assume that a similar improvement was seen.

I must be losing it. Both of my others, 7935261 and 7938333, are i5's, not i3's. So disregard the above, but are they still "Intel on die GPUs"? If so, I'll probably try disabling GPU on them, just to see what happens, but it won't be useful to the i3 question.

I find it interesting (or puzzling) that the i3's current RAC (3106) is far higher than that of either i5 (2259, 1884). The i5's were added on 17 Feb and 21 Feb, so I'd think their RACs are fairly well stabilized.
ID: 1797856 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13720
Credit: 208,696,464
RAC: 304
Australia
Message 1797876 - Posted: 22 Jun 2016, 5:23:51 UTC - in response to Message 1797856.  

Both of my others, 7935261 and 7938333, are i5's, not i3's. So disregard the above, but are they still "Intel on die GPUs"?

Yep.
Grant
Darwin NT
ID: 1797876 · Report as offensive
Profile Wiggo
Avatar

Send message
Joined: 24 Jan 00
Posts: 34744
Credit: 261,360,520
RAC: 489
Australia
Message 1797890 - Posted: 22 Jun 2016, 7:10:54 UTC - in response to Message 1797856.  

Self-quote:

I will wait until this climb levels out a little (I want to see how far it will go first) and then try disabling GPU on one of my other i3's. If I don't post here to the contrary, you may assume that a similar improvement was seen.

I must be losing it. Both of my others, 7935261 and 7938333, are i5's, not i3's. So disregard the above, but are they still "Intel on die GPUs"? If so, I'll probably try disabling GPU on them, just to see what happens, but it won't be useful to the i3 question.

I find it interesting (or puzzling) that the i3's current RAC (3106) is far higher than that of either i5 (2259, 1884). The i5's were added on 17 Feb and 21 Feb, so I'd think their RACs are fairly well stabilized.

Actually both your other CPU's are mobile and/or mITX i5's so those 2 systems are based on lower powered Hyperthreaded technology (2 cores, 4 threads still) so they would be slower than your desktop i3, but still (yes I know, I'm repeating myself again) none of them can be compared to desktop i5 CPU times (which you have been doing). ;-)

Cheers.
ID: 1797890 · Report as offensive
Matthew@SETI@home

Send message
Joined: 14 Feb 16
Posts: 40
Credit: 9,278,146
RAC: 6
United States
Message 1797930 - Posted: 22 Jun 2016, 14:48:18 UTC - in response to Message 1797890.  
Last modified: 22 Jun 2016, 15:03:49 UTC

Both i5's are laptops, so lower powered makes sense.

I hear you as to your last point, and I understand it. Due to edits of existing posts, you may have missed what I added to my 22 Jun 2016, 0:07:40 UTC post (last 1.5 paragraphs). Maybe I'm just failing to understand, but I don't see how I can compare my times for two different tasks in any meaningful way. I don't know of any indicator of the "size" of a task other than the CPU time itself.
ID: 1797930 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 1797959 - Posted: 22 Jun 2016, 15:39:22 UTC - in response to Message 1797930.  
Last modified: 22 Jun 2016, 15:39:33 UTC

Both i5's are laptops, so lower powered makes sense.

I hear you as to your last point, and I understand it. Due to edits of existing posts, you may have missed what I added to my 22 Jun 2016, 0:07:40 UTC post (last 1.5 paragraphs). Maybe I'm just failing to understand, but I don't see how I can compare my times for two different tasks in any meaningful way. I don't know of any indicator of the "size" of a task other than the CPU time itself.

When you are looking at your Task List
Select the Task ID for a completed task.
Then within the Stderr output you sell see a line WU true angle range is :. You want to compare task where that value is similar. "Normal" tasks, which you ideally want to use as a baseline, fall in the 0.42-0.44 range. So if you are comparing a task with a value of 0.431888 to one with a value of 0.008735 it doesn't really tell you anything.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 1797959 · Report as offensive
Matthew@SETI@home

Send message
Joined: 14 Feb 16
Posts: 40
Credit: 9,278,146
RAC: 6
United States
Message 1797990 - Posted: 22 Jun 2016, 17:40:06 UTC - in response to Message 1797959.  

Ok, thanks.
ID: 1797990 · Report as offensive
Previous · 1 · 2 · 3 · 4

Message boards : Number crunching : CPU time difference


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.