Gnight. I think any weaknesses will just have to come out in the wash. Does make sense to update api version on main release when not rushed, but doesn't make sense to break compatibility with every Cuda tool/sample (that all use that command line). Will just have to remeber to put api_version in app_infos...

---

"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.

Will just have to remeber to put api_version in app_infos...

I've been doing that in the installer, starting with v0.44 - using the same rule as stock deployment, locate the API string in the compiled executable (in my case with a hex editor), and copy it into app_info.

I'm on vacation and on some legal addi(c)tive too. And I'm happy to see we have dedicated, addicted to science, people all day and time zones on.

---

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

Enjoy your vacation, and come back fully fit and refreshed

---

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

Well finally got around to letting the Mac Pro update (in progress), so that it's *hopefully* up to snuff for the new build system refinement. Fingers crossed not too much Cuda/Boinc breaks in the process. The machine's primary display is on a Radeon, so no big deal if it needs some convincing regarding Cuda Drivers.

As Gradle is playing ball on Windows (small test pieces to get Cuda compiling+linking), which is presumably the most difficult environment for Cuda (because Microsoft Visual studio is propietary), embedding both GCC and Clang support needed for OSX and Linux, *should* be relatively straightforward.

All it'd mean for X-Branch, is going from 3 difficult to maintain/configure stale buildsystems, down to one modern one.

[A bit later:] well the mac pro seems to be running, without additional drivers needing update, will see how it goes. Meanwhile my Linux dev box must have got jealous and threw an error, lmao.

---

"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.

...
[A bit later:] well the mac pro seems to be running, without additional drivers needing update, will see how it goes. Meanwhile my Linux dev box must have got jealous and threw an error, lmao.

83C, looks like some dust bunny removal to do tomorrow.

---

"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.

So what does it say when you go to System Preferences/CUDA?

Looks as though all the tasks in Mavericks are finished. I'm going to see if I can compile an OpenCL App while here. The CUDA 42 test seems to have pasted, https://setiweb.ssl.berkeley.edu/beta/results.php?hostid=71141 Too bad the current CPU App is faster than those old CUDA cards...

So what does it say when you go to System Preferences/CUDA?

Looks as though all the tasks in Mavericks are finished. I'm going to see if I can compile an OpenCL App while here. The CUDA 42 test seems to have pasted, https://setiweb.ssl.berkeley.edu/beta/results.php?hostid=71141 Too bad the current CPU App is faster than those old CUDA cards...

Good question. The linux machine complained enough with a second error that I diverted attention and left the Mac to its own devices for a bit. Back to it momentarily.

Turns out GTX 680's don't work very well in Linux when the blower fans are completely blocked with crud :P. A cursory scoop out of fluffballs and it seems back down to 67C at full crunch, and 60% fan (quieter). There's a few opportunities to look at (dumb) problems like with fresh eyeballs, along the new buildsystem Journey. The machine should have been able to alert me before throwing errors on seti 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.

I got the new FFTW installed, tried the latest r3505 AKv8, and got;

analyzeFuncs.cpp:568:13: error: use of undeclared identifier 'cpu_MeanMaxIdx_buf'; did you mean 'cpu_MeanMaxIdx'?
                        (void *)&cpu_MeanMaxIdx_buf
                                 ^~~~~~~~~~~~~~~~~~
                                 cpu_MeanMaxIdx

That's a new one...
????

So what does it say when you go to System Preferences/CUDA?

Currently at 7.5.20 (working), wants to update to 7.5.30 . Do I need that ? (other than if I decide to make a Cuda 8rc build soon? e.g. to test the new build system )

Cuda driver info and updates button is also enabled... seeing what's under that...

---

"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 got the new FFTW installed, tried the latest r3505 AKv8, and got;

analyzeFuncs.cpp:568:13: error: use of undeclared identifier 'cpu_MeanMaxIdx_buf'; did you mean 'cpu_MeanMaxIdx'?
                        (void *)&cpu_MeanMaxIdx_buf
                                 ^~~~~~~~~~~~~~~~~~
                                 cpu_MeanMaxIdx

That's a new one...
????

Haven't done AKv8 builds for a long time. Probably something not enabled via preprocessor directives. Probably you'd have to search for the definition from that and compare to surrounding directives, and/or compare notes with Urs/Raistmer. GCC Vs Clang could be involved too.

---

"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'd say yes considering nVidia says you need 7.5.30 to support Darwin 15.5 & 16.0. The 7.5.30 page doesn't list 15.6, however, since 15.6 is between 15.5 & 16.0, and nVidia hasn't released a new driver for 15.6, I suppose nVidia figures 7.5.30 is good.
http://www.nvidia.com/object/macosx-cuda-7.5.30-driver.html

The 7.5.20 is old. They say you need 7.5.25 for Darwin 15.3.
http://www.nvidia.com/object/macosx-cuda-7.5.25-driver.html
nVidia builds new drivers for each new OS. Old drivers and new OSes usually don't work very well.

I built an OpenCL App with r3480, didn't have that Error. Something changed since then.
47 different cpu_MeanMaxIdx_buf in analyzeFuncs.cpp and it isn't found anywhere else in sah_v7_opt.
However, gpu_MeanMaxIdx is found in MB_CUDA_objects.h;
//extern float* GPUbuf;//R: temporary buffer for PulseFind needs
extern float2* gpu_ChirpedData;
extern float2* gpu_MeanMaxIdx;
extern float2* gpu_sample_rate;
extern float* gpu_PowerSpectrum;
...

Done. Cuda version now 7.5.30 instead of .20... seems to be crunching again, and updated host info here shows driver 4600.62, instead of 4600.52

Well the Mac host is apparently up to date, so will be ready to see what it takes to get Gradle triggering Cuda compilation on that this week. Probably will keep the Linux host on the older working Ubuntu LTS + driver for similar initial script refinement, but put the newer LTS edition on an SSD I have in the host.

Probably dedicated test pieces will end up making it to Mac and Linux first, just because M$ visual studio versions + Cuda Version Juggling is a nightmare on Windows.

Replicating the Working out of the minimal set of builds needed to go back to older Macs/Cudas as you've done, along with the same on Linux, will be part of what's needed for the new build system. In the case of Linux, it seems there are C-Runtime (glibC) overrides that can be embedded to ensure builds will work on old Linuxes though built on new (with appropriate older toolkit). It'll just depend on if any of the newest toolkits use GlibC features than have significantly changed.

Hopefully similar approaches can be forced on Mac, such that multiple build OSes won't be needed. Not counting on it though. There are two free drive bays and the option of VMs, but reducing the complexity if possible will bring all 3 platforms into line sooner.

---

"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 dunno. If you place float* cpu_MeanMaxIdx_buf; right below float* cpu_MeanMaxIdx; that error goes away.
Then you get,

analyzePoT.cpp:4060:60: error: use of undeclared identifier 'SleepQuantumCounter'
                                if(use_sleep_ex==1 && cur_quantum >0.9f && wait_time>7)SleepQuantumCounter::update(cur_quantum);
                                                                                       ^

I don't plan on using sleep. A couple // and then;
MBv8_8.17r3505_ssse3_clGPU_x86_64-apple-darwin

Yes!!

yeah, probably you should really be building from a working revision before the changes latest round. Looks like Raistmer's works in progress.

On Windows the 'órdinary' timers are pretty coarse, which led to me sticking with old school Cuda blocking Sync (low CPU but plenty of latency), Raistmer with OpenCL spinning on a core, and later offering use_sleep. Unfortunately ordinary sleeps on Windows aren't very predictable, or small enough granularity either, so for cross platform probably more sophisticated dynamic techniques will be needed in both camps.

That kindof [revision] confusion is why I chose last week to switch Xbranch x42 over to github, where the 'master' will eventually represent stable releases, and all new 'feature' and 'hotfix' works in progress developed on their own temporary forks, to be merged into release once proven (Only).

It's a strategy actively discouraged on svn/cvs, and unfamiliar to many developers (Something that [some] Boinc devs haven't grasped in their switch to Github, developing features and hotfixes in the master), but a move I'll have to make as I start to incrementally shovel my own 'Baseline'and Petri's optimised streaming code.

Short version is that under svn, Head/master will rarely 'work', while, under a properly managed Git arrangement, master *should* always 'work'.

---

"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.

Well....
It seems to work on the old GTS 250 running the sniff test. I'll have to replace the cards and boot to Yosemite to see how it works on the 950s. Might as well build an ATI version while I can.

Done. Cuda version now 7.5.30 instead of .20... seems to be crunching again, and updated host info here shows driver 4600.62, instead of 4600.52...

Hmmm, looking at the results it just seems that 780 is running much slower than it should. You're still running 2 at a time? If you are running 2 at a time it's slow, if 3...maybe not. Running the 8.11 App at Beta my 950 is running about 31 minutes on the BLC3s, this 980 is running about 27 minutes, http://setiathome.berkeley.edu/results.php?hostid=8037488&offset=200 with the older Baseline App (before the device selection fix). In any case, how about running a few of the 8.11 Apps at Beta just to see how it does. The only Macs there that have the CUDA Driver installed haven't run any of the 8.11 versions yet. It'd be interesting to see how it runs.

The OpenCL Apps are the same as before. In Mavericks they give the correct results, in El Capitan they are short by 1 Spike count. For some reason they don't want to run as standalone in Yosemite. Oh well. The New CPU App seems to be working well.

Done. Cuda version now 7.5.30 instead of .20... seems to be crunching again, and updated host info here shows driver 4600.62, instead of 4600.52...

Hmmm, looking at the results it just seems that 780 is running much slower than it should. You're still running 2 at a time? If you are running 2 at a time it's slow, if 3...maybe not. Running the 8.11 App at Beta my 950 is running about 31 minutes on the BLC3s, this 980 is running about 27 minutes, http://setiathome.berkeley.edu/results.php?hostid=8037488&offset=200 with the older Baseline App (before the device selection fix). In any case, how about running a few of the 8.11 Apps at Beta just to see how it does. The only Macs there that have the CUDA Driver installed haven't run any of the 8.11 versions yet. It'd be interesting to see how it runs.

The OpenCL Apps are the same as before. In Mavericks they give the correct results, in El Capitan they are short by 1 Spike count. For some reason they don't want to run as standalone in Yosemite. Oh well. The New CPU App seems to be working well.

Other than running 2up, Never remotely attempted to finetune baseline for Mac operation (yet), and the driver latencies are the highest of the 3 platforms. Certainly there will be significant underutilisation, no use of -poll and the pulsefind command line options, though could easily do so (plenty of CPU).

At present I'm more interested in an operational, up to date, and stable development environment for working on the new codebase. As soon as more automation infrastructure is in place here, then ramping up performance becomes more important.[Will probably end up running 4-up, on beta, and trying different apps down the road]

With the missing spike(s), if you enabled it try disable --use-fast-math in the GCC options for the host code. With v8 Eric ramped up the host code precision such that on Windows Cuda I had to change from m$'s equivalent fp:fast to fp:precise, in order to better match. There may be some other GCC/Clang equivalent to fp:fast enabled as well. It adds a small amount of CPU cost, though since the OpenCL kernels are spinning on cores by default anyway. Finding the right setting, the impact should be small, but validation greatly improve.

---

"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.

but validation greatly improve.

And that is what we're after.
Faster is nice, but not at the expense of accuracy.

---

Grant
Darwin NT

Done. Cuda version now 7.5.30 instead of .20... seems to be crunching again, and updated host info here shows driver 4600.62, instead of 4600.52...

Hmmm, looking at the results it just seems that 780 is running much slower than it should. You're still running 2 at a time? If you are running 2 at a time it's slow, if 3...maybe not. Running the 8.11 App at Beta my 950 is running about 31 minutes on the BLC3s, this 980 is running about 27 minutes, http://setiathome.berkeley.edu/results.php?hostid=8037488&offset=200 with the older Baseline App (before the device selection fix). In any case, how about running a few of the 8.11 Apps at Beta just to see how it does. The only Macs there that have the CUDA Driver installed haven't run any of the 8.11 versions yet. It'd be interesting to see how it runs.

The OpenCL Apps are the same as before. In Mavericks they give the correct results, in El Capitan they are short by 1 Spike count. For some reason they don't want to run as standalone in Yosemite. Oh well. The New CPU App seems to be working well.

Other than running 2up, Never remotely attempted to finetune baseline for Mac operation (yet), and the driver latencies are the highest of the 3 platforms. Certainly there will be significant underutilisation, no use of -poll and the pulsefind command line options, though could easily do so (plenty of CPU).

At present I'm more interested in an operational, up to date, and stable development environment for working on the new codebase. As soon as more automation infrastructure is in place here, then ramping up performance becomes more important.[Will probably end up running 4-up, on beta, and trying different apps down the road]

With the missing spike(s), if you enabled it try disable --use-fast-math in the GCC options for the host code. With v8 Eric ramped up the host code precision such that on Windows Cuda I had to change from m$'s equivalent fp:fast to fp:precise, in order to better match. There may be some other GCC/Clang equivalent to fp:fast enabled as well. It adds a small amount of CPU cost, though since the OpenCL kernels are spinning on cores by default anyway. Finding the right setting, the impact should be small, but validation greatly improve.

The fast Math has absolutely nothing to do with the Problems with the OpenCL nVidia App and El Capitan. The Problem exists with the Stock App and the Apps at Beta. Changing the Math setting has no effect...I tried that when El Capitan was first released...Last year. The reason that 980 is now running the CUDA App is because the Stock OpenCL App was producing mostly Inconclusive results. Check his results since he went to the CUDA App, http://setiathome.berkeley.edu/results.php?hostid=8037488&state=3 Like night and day. The App he's running is the same App at Beta, save the device selection Fix.
No, the math setting is a Red Herring. Try it Yourself with the OpenCL App, I tried it long ago.


It would be nice to have a few people run the CUDA Apps at Beta...