I was sad at how slow VLARs were running on my Linux / GTX 1070 node so I tried to build the source myself this morning.

For posterity here are my notes:

It's a fresh Ubuntu yakkety (16.10) install I did on Friday night.

For starters I had some problems with the Pascal GPUs at first but if I booted with nomodeset they went away; so to get the machine crunching I needed:

sudo vi /etc/default/grub
> GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"

sudo apt-get install build-essential subversion autoconf build-dep libtool libssl-dev pkg-config

wget http://us.download.nvidia.com/XFree86/Linux-x86_64/375.20/NVIDIA-Linux-x86_64-375.20.run
chmod 755 NVIDIA-Linux-x86_64-375.20.run
sudo ./NVIDIA-Linux-x86_64-375.20.run

(BOINC client setup not included).

My fumbling around with the SVN looked like this:

git clone https://github.com/BOINC/boinc boinc
svn checkout https://setisvn.ssl.berkeley.edu/svn/seti_boinc

cd set_boinc
./_autosetup
./configure --disable-server

vi configure
> $RM -f "$cfgfile"

make
many errors.

I'm not sure why I had to change the RM to be -f since my umask is 0002. I didn't debug more -- I just hacked and moved on with life.

This branch is evidently not the current build so I wasn't discouraged by the wall of compile errors. From what I can tell the active branch is over here:

svn checkout https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt/
cd sah_v8_opt/AKv8
chmod 755 _autosetup
./_autosetup
./configure --disable-server
make

I got less errors so it's encouraging

./../sah_config.h:669:37: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
 #define CUSTOM_STRING PACKAGE_STRING" "SVN_REV" "COMPILER_STRING
                                     ^
./../sah_config.h:669:47: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
 #define CUSTOM_STRING PACKAGE_STRING" "SVN_REV" "COMPILER_STRING
                                               ^
In file included from ../db/sqlrow.h:33:0,
                 from ../db/db_table.h:31,
                 from seti_header.h:43,
                 from seti.h:45,
                 from analyzeFuncs.h:31,
                 from main.cpp:91:
../db/xml_util.h:219:3: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
   "<?xml version=\"1.0\" encoding=\""XML_ENCODING"\"?>\n";
   ^
In file included from seti_header.h:43:0,
                 from seti.h:45,
                 from analyzeFuncs.h:31,
                 from main.cpp:91:
../db/db_table.h:538:17: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     sprintf(buf,"%"INT8_FMT,INT8_PRINT_CAST(sqlint8_t(r.id)));
                 ^
../db/db_table.h:549:17: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
     sprintf(buf,"<id>%"INT8_FMT"</id>",INT8_PRINT_CAST(sqlint8_t(r.id)));
                 ^
In file included from analyzeFuncs.h:31:0,
                 from main.cpp:91:
seti.h:57:19: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
 #define SINT8_FMT "%"PRId64
                   ^
seti.h:59:19: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
 #define UINT8_FMT "%"PRIu64
                   ^
In file included from s_util.h:142:0,
                 from main.cpp:89:
../../src/GPU_lock.h:5:38: note: #pragma message: ---SSE2 defined---
  #pragma message("---SSE2 defined---")
                                      ^
In file included from ../db/sqlrow.h:33:0,
                 from ../db/db_table.h:31,
                 from seti_header.h:43,
                 from seti.h:45,
                 from analyzeFuncs.h:31,
                 from main.cpp:91:
../db/xml_util.h: In function ‘std::string base64_encode(const T*, size_t)’:
../db/xml_util.h:282:65: warning: array subscript has type ‘char’ [-Wchar-subscripts]
     for (i=0;i<((nleft>3)?4:(nleft+1));i++) c[i]=encode_arr[c[i]];
                                                                 ^
../db/xml_util.h: In function ‘std::string base85_encode(const T*, size_t)’:
../db/xml_util.h:377:47: warning: array subscript has type ‘char’ [-Wchar-subscripts]
       for (i=0;i<5;i++) c[i]=encode_arr85[c[i]];
                                               ^
In file included from main.cpp:91:0:
analyzeFuncs.h: At global scope:
analyzeFuncs.h:77:9: error: ‘__m128’ does not name a type
 typedef __m128 vFloat;
         ^~~~~~
analyzeFuncs.h:78:9: error: ‘__m128i’ does not name a type
 typedef __m128i vUInt32;
         ^~~~~~~
analyzeFuncs.h:79:9: error: ‘__m128i’ does not name a type
 typedef __m128i vSInt32;
         ^~~~~~~
analyzeFuncs.h:80:9: error: ‘__m128i’ does not name a type
 typedef __m128i vUInt8;
         ^~~~~~~
analyzeFuncs.h:81:9: error: ‘__m128d’ does not name a type
 typedef __m128d vDouble;
         ^~~~~~~

So at this point I'm not sure if it's worth going any further. I'm sure I could fix this but since (rightly) don't have write-access to the SVN my patches would be irritating to share.

I don't mind picking away at this in my free time but I'm apprehensive about futile work not getting integrated back. I'd be much more inclined if I could fork on github and then just send pull requests to someone authorized to review my patches.

What do you recommend?

What do you recommend?

Have been wrestling with similar integration issues/decisions on the CUDA side of things, having been working with Petri's contributions. There, in X-branch, for the time being I have those aside in an alpha folder while I work out the best approach.

Much of the stock CPU and AKv8 code Raistmer's maintaining predates C++11 by a large margin, so you *might* have a smoother time of things if you can set gcc compiler options accordingly.

For repository contribution in the CPU/OpenCL optimised branches, discussing with Raistmer might be the go.

On the Cuda side I'm using the contributions, respite given by the OpenCL apps handling GBT tasks well, and major shifts in the Cuda architecture, to more or less migrate to Github, through a pretty involved refactoring/modernising redesign process. That's likely to take a while, due to modern methods deprecating a lot of old work, and turning up some vulnerabilities along the way.

modernising these things revealed that the good old gnu-tools build system has become pretty awkward for cross platform work, with both Linux and OSX compilers and libraries changing underneath it, several breaking changes making it 'interesting'. To that end I have been experimenting with the CMake and Gradle build systems, in the hopes that the 3 main platforms can be pulled into line. When I'm ready to take pull requests on Github I'll probably mention it in a test application post, so if you end up poking at the Cuda alpha code as well, then that'll be a little more open that it is now. [At this point it looks like I'll be settling on Gradle, since I managed to make it drive nvcc, visual studio, gcc and clang compilers, on all 3 platforms]

---

"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'm pretty optimistic about cross-platform -- at least Windows vs Linux; I have no experience with OSX but I would hope it can share enough with Linux that it would be fine. I have a dual-boot MacBook Air so if I got far enough with the Linux side I'd be willing to check out the other side.

I could nerf the Cx11 stuff but TBH it looked super easy to fix. The other stuff looked like just a missing include, too.

I saw that you'd put the CUDA stuff on github which is great -- I've just been so disappointed by the CUDA performance so far that I'd be content to just bring the OpenCL SoG linux port to parity with Windows.

The retro build system isn't great -- I'm more worried about the retro patch contribution system ;)

The retro build system isn't great -- I'm more worried about the retro patch contribution system ;)

haha, yeah. I think once Cuda's back on the map, I can demonstrate using a github workflow 'properly' can be way more effective. Just one of those many difficult to change bad habits ;)

FWIW, if you do end up playing with the Cuda alpha code, it's roughly 2-10x faster that generic baseline Cuda, depending on Angle range (mostly faster in the GBT/vlar region.

I've yet to be able to replicate the main validation concerns being discussed elsewhere, though have had multiple other issues. Most of those issues are extra load related, so heat and power. In my test case, i eventually seem to have stemmed the tide of errors/invalids, by jacking the GPU fan to ridiculous levels, We'll see. Probably some kindof throttles and considerable widening of the hardware it will run on will need to happen. In either case cranking out GBT vlars in ~7-8 minutes is amusing, even if there's a lot of work involved to bring things up to suitability for wider deployment.

---

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

Unfortunately, there is the reason to think that PulseFind refactoring in Petri's codebase is flawed. There were few cases already that demonstrated that bug.
Wrong Pulse picked at some conditions (not precision-related but refactoring-related issue).

So I would not recommend to "just build" from that codebase for production runs.
Debugging/benching/testing on beta - more valid options still.

Regarding building OpenCL path under Linux:
this repo branch should be used:
https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt

---

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

Regarding building OpenCL path under Linux:
this repo branch should be used:
https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt

Yup, that's where I built from the second time -- the errors I encountered were from AKv8 which is where I saw the most recent changes being made.

So again: if I fix stuff in there am I just wasting my time because the volunteers working on this are too busy to deal with patches? So far I've got a half page of notes for fixes I've made.

I can make an SVN patch if anyone would look at it -- there was some Cx11 lint which was easy to fix, some pure-scalar (no SIMD) ifdefs needed and there's a misplaced bracket in the #ifdef nightmare of main.cpp I need to track down still.

PM Urs Echternacht about your changes.
If he approves we take them into repo.
AFAIK he's working with iGPU Linux build currently. So NV and ATi ones could be outdated indeed.

---

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

I broke down and installed all the developer files in my new Ubuntu 14.04 system, on my New Hard Drive. Then managed to build a nVidia OpenCL App from r3566 without any Errors. It even works, but, uses 100% CPU, and seems slow compared to the 'Special' CUDA App. The first test with reference_work_unit_r3215 took 358 seconds and scored Q= 99.88% running on my 750Ti. It's running a BLC now.

I broke down and installed all the developer files in my new Ubuntu 14.04 system, on my New Hard Drive. Then managed to build a nVidia OpenCL App from r3566 without any Errors. It even works, but, uses 100% CPU, and seems slow compared to the 'Special' CUDA App. The first test with reference_work_unit_r3215 took 358 seconds and scored Q= 99.88% running on my 750Ti. It's running a BLC now.

Ok! I'm wrestling with the Cx11 stuff in Ubuntu 16. It looks like the mix of _GLIBCXX_USE_CXX11_ABI 0 is leading to link-time errors or, if I don't clean up the compile-time lint for duplicate macro definitions I get a mile of errors about ambiguous std::string probably because half the time it's compiled with _GLIBCXX_USE_CXX11_ABI 1 and half the time 0. I'll keep digging.

I've run a few BLCs and it doesn't appear to be much better than the existing App. The GPUs in the 750Ti range seem to be taking around 24 minutes for a BLC3 and 4, http://setiathome.berkeley.edu/result.php?resultid=5303186250 Everything else seems to be working fine. Maybe I'll try an iGPU build and see how that works in Ubuntu.

Ok! I'm wrestling with the Cx11 stuff in Ubuntu 16. It looks like the mix of _GLIBCXX_USE_CXX11_ABI 0 is leading to link-time errors or, if I don't clean up the compile-time lint for duplicate macro definitions I get a mile of errors about ambiguous std::string probably because half the time it's compiled with _GLIBCXX_USE_CXX11_ABI 1 and half the time 0. I'll keep digging.

Is it possible you're using the Intel GPU Configure Line instead of the nVidia Line? Looking here I see the -D_GLIBCXX_USE_CXX11_ABI=0 is for the Intel build, https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/AKv8/ConfigureLinux64_AKv8d_OPENCL_SSE2_MBv8.txt#L20
The line I originally used is similar to the one labeled "configure commandline to add for an OpenCL NVidia GPU application (current)", when I went to use the Intel path I noticed that.

When I built my second NV App I just substituted the -DUSE_OPENCL_INTEL in place of -DUSE_OPENCL_NV and left the rest the same. I ran across a couple usual Errors, but was able to compile the App anyway without Counters and without "SleepQuantumCounter". The App built with the Intel path Appears to be slightly Faster than the one built with the NV path on my nVidia cards, http://setiathome.berkeley.edu/result.php?resultid=5302832129

The examples in https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/AKv8/ConfigureLinux64_AKv8d_OPENCL_SSE2_MBv8.txt are also supposed for pretty old RH6 and clones systems with 2.6 kernels. A stock gpu app has to still support these.
So, maybe the latest kernels can be problematic. I've tested iGPU on linux now upto kernel 4.7. If you use newer, no guarantees !

Which gcc version is in use ( gcc -v) ?
For gcc 4.8 or 4.9 the given examples should work.
For gcc 5.x the -D_GLIBCXX_USE_CXX11_ABI=0 is needed at the commandline in CPPFLAGS.
For gcc 6.x or 7 its untested.

Why is there no simple configure, make, make install triplet ?
No base app in optimized code base at /branches/sah_v7_opt/AKv8 that could be build this way. For linux alone there are more than 20 different codepathes in there.

---

_\|/_
U r s

Ok! I'm wrestling with the Cx11 stuff in Ubuntu 16. It looks like the mix of _GLIBCXX_USE_CXX11_ABI 0 is leading to link-time errors or, if I don't clean up the compile-time lint for duplicate macro definitions I get a mile of errors about ambiguous std::string probably because half the time it's compiled with _GLIBCXX_USE_CXX11_ABI 1 and half the time 0. I'll keep digging.

Is it possible you're using the Intel GPU Configure Line instead of the nVidia Line? Looking here I see the -D_GLIBCXX_USE_CXX11_ABI=0 is for the Intel build, https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/AKv8/ConfigureLinux64_AKv8d_OPENCL_SSE2_MBv8.txt#L20
The line I originally used is similar to the one labeled "configure commandline to add for an OpenCL NVidia GPU application (current)", when I went to use the Intel path I noticed that.

When I built my second NV App I just substituted the -DUSE_OPENCL_INTEL in place of -DUSE_OPENCL_NV and left the rest the same. I ran across a couple usual Errors, but was able to compile the App anyway without Counters and without "SleepQuantumCounter". The App built with the Intel path Appears to be slightly Faster than the one built with the NV path on my nVidia cards, http://setiathome.berkeley.edu/result.php?resultid=5302832129

Yup I got it working last night with -D_GLIBCXX_USE_CXX11_ABI=0 -- I was going to clean up my patches and test in U14 as well before submitting.