On request, using the same data I collected for my most recent GPU rankings, I parsed out data for tasks running the stock CUDA app and generated a comparison with OpenCL. As you can see the CUDA app generates less credit per hour on modern GPUs.

Hmmm, I actually expected OpenCL would be further ahead on single instance stock app/settings. In the Cuda app case, there are presently hard scaling limits (likely to be lifted later with optional CPU cost).

Would it be easy to extract the CPU usage [time], avg % of elapsed I suppose, per task for the same models/app ? Might give an idea how many Cuda streams we might be able to feed while staying on a single core (for the next gen).

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I somehow expected this; Latest GPUs are not used well by now old Cuda 5.0, while OpenCL is a bit higher level programming and OpenCL driver itself is doing a better job optimizing the task to actual higher-end GPU hardware.

Sure, well written code in Cuda 7.5/8.0 would probably be even better but requires some additional human effort to be put in...

---

I somehow expected this; Latest GPUs are not used well by now old Cuda 5.0, while OpenCL is a bit higher level programming and OpenCL driver itself is doing a better job optimizing the task to actual higher-end GPU hardware.

Sure, well written code in Cuda 7.5/8.0 would probably be even better but requires some additional human effort to be put in...

The biggest issue there is the switch to tasks the Cuda app was never designed to run efficiently, and the Cuda app's preference to low CPU use underfeeding the newest/largest GPUs with them.

After some tests I'm very hopeful Petri's contributed code will go a long way. I am, though, requesting more information on the CPU usage here, because this is a fairly critical CPU/GPU load balancing issue, when it comes to figuring out a way to scale across the range without locking up hosts/tasks.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

After some tests I'm very hopeful Petri's contributed code will go a long way. I am, though, requesting more information on the CPU usage here, because this is a fairly critical CPU/GPU load balancing issue, when it comes to figuring out a way to scale across the range without locking up hosts/tasks.

The advantage that Petri's code has is that it makes as much use as possible of the GPU when running only a single WU, so only 1 Core per GPU will be necessary to get maximum performance, where at present- particularly with high end hardware- you need 3-5 Cores per GPU to get maximum performance due to the need to run multiple WUs in order to make use of the GPU hardware available.
1 CPU core per GPU will only be an issue for the older/ most basic of systems.

The default stock installation should be set to have minimal impact on system usability; for those with 1 or more GPUs and 4 or more CPU cores give them the option to reserve a CPU core & use a more tuned setting for their GPU. Possibly a 3rd option for dedicated crunchers to go for the most tuned option for their hardware, irrespective of the effect on system usability; or the 3rd option is for them to use Lunatics to select the application & configuration of their choosing.

---

Grant
Darwin NT

After some tests I'm very hopeful Petri's contributed code will go a long way. I am, though, requesting more information on the CPU usage here, because this is a fairly critical CPU/GPU load balancing issue, when it comes to figuring out a way to scale across the range without locking up hosts/tasks.

The advantage that Petri's code has is that it makes as much use as possible of the GPU when running only a single WU, so only 1 Core per GPU will be necessary to get maximum performance, where at present- particularly with high end hardware- you need 3-5 Cores per GPU to get maximum performance due to the need to run multiple WUs in order to make use of the GPU hardware available.
1 CPU core per GPU will only be an issue for the older/ most basic of systems.

The default stock installation should be set to have minimal impact on system usability; for those with 1 or more GPUs and 4 or more CPU cores give them the option to reserve a CPU core & use a more tuned setting for their GPU. Possibly a 3rd option for dedicated crunchers to go for the most tuned option for their hardware, irrespective of the effect on system usability; or the 3rd option is for them to use Lunatics to select the application & configuration of their choosing.

Yeah, I'd agree with the conservative stock sentiment. Where the complexity comes into the choices/options is the moving target. Scaling to use a full CPU core to fill a new GPU now, then the problem manifests again when Volta surfaces next year (or so). More than likely as more of this information becomes better known, then better self-scaling can be employed to some degree, and flexibility in choices for those that want it, will be the way to go. Probably, at least for the Cuda-Xbranch side, that will continue to appear as conservative defaults, but with the addition of optional tools for configuration/tweaking.

Side-issues presented in build systems, cross platform, and limits of the existing design shoehorning in performance code. The OpenCL lead is being taken as an opportunity to take Cuda into dry-dock for complete redesign-refit, as opposed to patching what's been a relatively solid design, but is now quite dated.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

According to site statistics

Windows/x86 8.00 (cuda23) 22 Jan 2016, 0:38:52 UTC 1,076 GigaFLOPS
Windows/x86 8.00 (cuda32) 22 Jan 2016, 0:38:52 UTC 7,321 GigaFLOPS
Windows/x86 8.00 (cuda42) 22 Jan 2016, 0:38:52 UTC 20,515 GigaFLOPS
Windows/x86 8.00 (cuda50) 22 Jan 2016, 0:38:52 UTC 22,408 GigaFLOPS
Windows/x86 8.12 (opencl_nvidia_sah) 18 May 2016, 1:10:51 UTC 33,985 GigaFLOPS
Windows/x86 8.12 (opencl_nvidia_SoG) 18 May 2016, 1:10:51 UTC 88,905 GigaFLOPS

Both SAH and SoG overall outperform CUDAxx.
But there are non-zero share of SAH app regarding SoG too (34:89).
Would be interesting to establish what cards prefer SAH over SoG and for what reason. It can be card type-based choice (that is, XYZ model prefers SAH over SoG on almost all hosts where this model installed) or just random choice of server due to close enough performance. In this case any particular XYZ model will crunch SAH on some hosts and SoG on others.

Such survey will be useful for project performance increase cause I plan to omit SAH build for next release (in case if no particular XYZ GPU model strongly prefers it over SoG).

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Would be interesting to establish what cards prefer SAH over SoG and for what reason. It can be card type-based choice (that is, XYZ model prefers SAH over SoG on almost all hosts where this model installed) or just random choice of server due to close enough performance.

In my case on Beta, the slowest application was chosen due to the work types being allocated at that time. SoG & Cuda50 got almost all Guppie work, SaH got mostly Guppie with some Arecibo work and Cuda42 got almost all Arecibo work- so it had the best processing rate & it got picked as the best application, even though was actually the slowest.

---

Grant
Darwin NT

Here's an interesting comparision.
My GTX 950 running the latest Special CUDA verses a GTX 780 running the Stock OpenCL
http://setiathome.berkeley.edu/workunit.php?wuid=2237103948

5097350994  6909215   14 Aug 2016, 22:56:00 UTC 14 Aug 2016, 23:12:16 UTC Completed and validated 367.83  367.83  56.24   SETI@home v8 v8.12 (opencl_nvidia_SoG) windows_intelx86
5097350995  7199204   14 Aug 2016, 22:55:50 UTC 14 Aug 2016, 23:06:08 UTC Completed and validated 375.86  353.63  56.24   SETI@home v8 Anonymous platform (NVIDIA GPU)

We'll have to wait until afternoon to see if the latest version is any better with the GUPPI Pulse count. About half the GUPPI tasks are off by One Pulse count in the older versions. Once that one little Pulse count is solved the App will be viable. This is a typical GUPPI task with the new App;
http://setiathome.berkeley.edu/result.php?resultid=5097390926

blc5_2bit_guppi_57451_66989_HIP117473_OFF_0016.13400.831.18.27.179.vlar_2
Run time: 15 min 22 sec
CPU time: 15 min 1 sec
Validate state: Valid

Nice, you compiled your own ap x41p_zi3c
Where can I download and try it on my V8-Xeon ?
Please compile it with CUDA8 too.
You can download CUDA8 from the "Developer area" of NVIDIA, I have it also installed..
_heinz

I've tried it with CUDA 8. You can find some results by looking through the Inconclusive list, http://setiathome.berkeley.edu/result.php?resultid=5064040827
My results show CUDA 8 isn't any better than 7.5, and CUDA 8 only works in Darwin 15.x, not to mention the Driver is Broken in Darwin 15.6. If you want to run the CUDA 8 driver, do Not update to Darwin 15.6. Fortunately I have a Backup system that is still running Darwin 15.4.

Checkout those results, CUDA verses Stock OSX OpenCL;

5064040826  6274868  28 Jul 2016,  3:18:55 UTC   6 Aug 2016, 12:07:27 UTC  Completed, validation inconclusive  7,346.61  195.25  pending  SETI@home v8 v8.00 (opencl_nvidia_mac) x86_64-apple-darwin
5064040827  6796479  28 Jul 2016,  3:19:05 UTC  28 Jul 2016, 12:44:11 UTC  Completed, validation inconclusive    390.14  381.89  pending  SETI@home v8 Anonymous platform (NVIDIA GPU)
5082539421  8028973   6 Aug 2016, 18:30:44 UTC  30 Sep 2016, 1:54:56 UTC              in progress 	          --- 	   --- 	   ---    SETI@home v8 v8.00 x86_64-pc-linux-gnu

The source code is here, https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/Xbranch/client/alpha/PetriR_raw3
From my experience the CUDA version doesn't matter, it's the 'Special' work accomplished by Petri using the new CUDA Streams code.

Merci TBar,
will have a look in it and try.

On request, using the same data I collected for my most recent GPU rankings, I parsed out data for tasks running the stock CUDA app and generated a comparison with OpenCL. As you can see the CUDA app generates less credit per hour on modern GPUs.

Shaggie,
Is your graph comparing with only 1task/gpu?
If so, from my experience, NV_SoG should be crushing Cuda50 on a GTX 750 Ti
...but it looks like there's only ~20% lead for NV_SoG.
Maybe I've been playing too much with Mr Kevvy's script that I can't remember the good old days of running guppis on GPU! lol
RobG ;-}

Would it be easy to extract the CPU usage [time], avg % of elapsed I suppose, per task for the same models/app ? Might give an idea how many Cuda streams we might be able to feed while staying on a single core (for the next gen).

Sure I can fiddle with that -- I'll need to rework the front end because I don't have that data in the digestion but I'll see what I can do.

Is your graph comparing with only 1task/gpu?

Yes, "stock."

Is your graph comparing with only 1task/gpu?

Yes, "stock."

I only asked because I found out yesterday that some run multiple tasks on GPU with stock. Can't remember the thread though.
I'm assuming it's those who use just the GPU to crunch S@h, and they don't want to reinstall Lunatics whenever there's a new update to apps.
I'm also assuming it's much more rare than Anonymous Platform, so it shouldn't affect your stats....much.

Maybe others have a better idea especially those running multiple projects: S@h on GPU and other project(s) on CPU.
Just another random thought!

You can run more than 1 per GPU with stock by just adding an app_config.xml

I'm pretty sure it won't show up as anonymous, but it's been a long time since I've done that.

I somehow expected this; Latest GPUs are not used well by now old Cuda 5.0, while OpenCL is a bit higher level programming and OpenCL driver itself is doing a better job optimizing the task to actual higher-end GPU hardware.

Sure, well written code in Cuda 7.5/8.0 would probably be even better but requires some additional human effort to be put in...

The biggest issue there is the switch to tasks the Cuda app was never designed to run efficiently, and the Cuda app's preference to low CPU use underfeeding the newest/largest GPUs with them.

After some tests I'm very hopeful Petri's contributed code will go a long way. I am, though, requesting more information on the CPU usage here, because this is a fairly critical CPU/GPU load balancing issue, when it comes to figuring out a way to scale across the range without locking up hosts/tasks.

The CPU usage on my system depends on the choise I give for the nanosleep that I use to replace Yield() via LD_PRELAOD on my Linux. For some unknown reason my system uses 100% if I use cuda blocking sync option that is meant to free the CPU. So I use Yield() and override that before program launch.

Wih 5000 nanoseconds (5 us) the CPU usage is 19-39 % per GPU task. If I increase the value for sleep the CPU usage and GPU usage drops and I could run more simultaneous apps. But I do not need to. I get 84 - 100% GPU usage (96% avg) and the power consumption of one GTX1080 is at 130-168W. Unmodified code used 79W doing guppi/vlar tasks.

Without nanosleep shprties would take 46 seconds both CPU and GPU. Now they use 52 seconds GPU and 20 seconds CPU. I'm taking off the nanosleep now for a few hours. My CPU time should increase.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Unmodified code used 79W doing guppi/vlar tasks.

CUDA or SoG?

(I'm guessing CUDA, but like to be sure)

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Unmodified code used 79W doing guppi/vlar tasks.

CUDA or SoG?

(I'm guessing CUDA, but like to be sure)

Your guess was right. I'm doing CUDA.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones