Latest update: I setup test cases for all of the warnings to verify that all but 1 don't impact results. This one does have an effect, but fixing still results in invalid results:

analyzeReport.cpp: In function ‘int ReportTripletEvent(float, float, float, float, int, int, int, const float*, int)’:
analyzeReport.cpp:439:60: warning: format ‘%g’ expects argument of type ‘double’, but argument 5 has type ‘int’ [-Wformat=]
   ti.score,ti.t.peak_power,ti.freq_bin,analysis_state.icfft);

I also compiled for AVX2 with no change. I have also tried -std=c++98 and other options, but still no signals reported. I will continue to dig deeper into the code. Let me know of any recommendations.

---

GitHub: Ricks-Lab
Instagram: ricks_labs

Yeah that is what has been holding me back, the utter pain it was to revert back to Sierra. I need to do just that though, install HS on a seperate drive and just plug my old one back in if the issue is still there. I always have plans to do things, the time to do them is always the issue. lol

I was finally able to get 10.13.5 working on my Mac Pro 3,1 using a new installer USB. Seems the major problem is whatever is done to make it work on the 3,1 doesn't play well with my ATI 6850, if I just use the NV GPUs it works for the most part. HS still has the Shutdown Error on my machine, but, I can get a version of zi3t2b to work about 60% of the time without the Error. This was happening quite a while ago and was fixed by removing the last cudaDeviceReset, unfortunately that fix doesn't appear to work with HS. I can get a different Error by using cudaThreadExit at the end instead, but, it still fails with an Error after the task is finished.

I just checked out 3883 and found it to be very different from the previous version I was working with. Just wondering if it is in a state that can be worked with at this time? I did try to compile and it could not find these 2 lib files:

/usr/bin/x86_64-linux-gnu-ld: cannot find -lboinc_api
/usr/bin/x86_64-linux-gnu-ld: cannot find -lboinc

Is this related to boinc-master? Do I need to get an updated version to work with 3883?

Also ran into a few other strange problems. After compiling, I tried running configure again with some changes to arguments, but it tells me the compiler can't output files. I had no problem running configure before I compiled the first time.

---

GitHub: Ricks-Lab
Instagram: ricks_labs

I updated LDFLAGS to include "-L/home/rick/BOINCdev/boinc/api/". I have also downloaded and compiled the latest boinc source code, but the file boinc.o is still missing. Also, many of the flags previously used don't seem to work with 3883. Has anyone else tried to compile it?

---

GitHub: Ricks-Lab
Instagram: ricks_labs

I was finally successful in compiling a working CPU MB app in Ubuntu 18.04! It gives valid results but runs in 5x the time the current Linux AVX app runs in. I have only tested with the test WU PG0395_v8.wu. My build is based on the latest extract which is version 3883. I had to make some tweaks to get it to compile. Here are my commands to run configure:

./configure --disable-server --disable-graphics --disable-shared --enable-bitness=64 --enable-client --enable-static-client --enable-dependency-tracking --enable-static --enable-intrinsics --enable-fast-math --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --with-boinc-platform=x86_64-pc-linux-gnu \
CXXFLAGS=" -march=znver1 -std=c++98" \
CPPFLAGS=" -DUSE_I386_XEON -DUSE_I386_OPTIMIZATIONS -DUSE_SSE42 -DUSE_FFTW -DFFTOUT -DSETI7 -DSETI8 -DUSE_JSPF -D_GLIBCXX_USE_CXX11_ABI=0" \
LDFLAGS="  -L/usr/lib64 -static -static-libgcc -static-libstdc++ -L/usr/local/lib/ -L/home/rick/BOINCdev/boinc/lib/ -L/home/rick/BOINCdev/boinc/api/" \
BOINCDIR=" /home/rick/BOINCdev/boinc/"

I previously had some errors in the way I was defining LDFLAGS. I also had to make a change to sighandler.h where I had to add:

#include <cstddef>

Now trying to build an optimized app...

I have compile with what I think should be optimized options:

./configure --disable-server --disable-graphics --disable-shared --enable-bitness=64 --enable-client --enable-static-client --enable-dependency-tracking --enable-static --enable-intrinsics --enable-fast-math --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --with-boinc-platform=x86_64-pc-linux-gnu \
CXXFLAGS=" -march=znver1 -mtune=native -O3 -msse4.2 -ffast-math -std=c++98 -fomit-frame-pointer -malign-double -fstrict-aliasing -fno-schedule-insns" \
CPPFLAGS=" -DUSE_I386_XEON -DUSE_I386_OPTIMIZATIONS -DUSE_SSE42 -DUSE_FFTW -DFFTOUT -DSETI7 -DSETI8 -DUSE_JSPF -D_GLIBCXX_USE_CXX11_ABI=0" \
LDFLAGS="  -L/usr/lib64 -static -static-libgcc -static-libstdc++ -L/usr/local/lib/ -L/home/rick/BOINCdev/boinc/lib/ -L/home/rick/BOINCdev/boinc/api/" \
BOINCDIR=" /home/rick/BOINCdev/boinc/"

I also tried it without the following options:

-mtune=native -fomit-frame-pointer -malign-double -fstrict-aliasing -fno-schedule-insns

KWSN-Linux-MBbench v3.0 cache-keeping edition
Running on NemesisU at Sun 24 Jun 2018 06:15:53 AM UTC
----------------------------------------------------------------
Starting benchmark run...
----------------------------------------------------------------
Suspending BOINC
Listing wu-file(s) in /testWUs :
PG0395_v8.wu

Listing executable(s) in /APPS :
setiathome-8.0.x86_64-pc-linux-gnu

Listing executable in /REF_APPS :
MBv8_8.04r3306_sse42_linux64
----------------------------------------------------------------
Current WU: PG0395_v8.wu

----------------------------------------------------------------
Skipping default app MBv8_8.04r3306_sse42_linux64, displaying saved result(s)
Elapsed Time: ....................... 170 seconds
----------------------------------------------------------------
Running app with command : .......... setiathome-8.0.x86_64-pc-linux-gnu
./setiathome-8.0.x86_64-pc-linux-gnu 316.71 sec 313.70 sec 0.91 sec
Elapsed Time : ...................... 317 seconds
Speed compared to default : ......... 53 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.91%

----------------------------------------------------------------
Done with PG0395_v8.wu

====================================================================
Hosts CPU data ...
model name      : AMD Ryzen Threadripper 1950X 16-Core Processor
cpu cores       : 16
cpu MHz         : 2973.924
cache size      : 512 KB
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

Done with Benchmark run! Removing temporary files!
Resuming BOINC

In both cases, the new app takes about twice as long as the sse4.2 version of r3306. Looks like there are many changes in r3883, so I am not sure if the slow down is due to the latest code or my optimizations.

I wonder if you will ever be as successful as the stock apps. I thought I remember reading a post that the stock apps had code that was highly hand optimized by Joe Segur and that there would be no way of beating their performance using just the stock compiling flags. Maybe someone can confirm my recollection.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I updated LDFLAGS to include "-L/home/rick/BOINCdev/boinc/api/". I have also downloaded and compiled the latest boinc source code, but the file boinc.o is still missing. Also, many of the flags previously used don't seem to work with 3883. Has anyone else tried to compile it?

I managed to download the 3883 version of sah_v7_opt by rebooting into El Capitan. For some reason you can't use the Connect to Server method in Sierra to connect to https://setisvn.ssl.berkeley.edu/svn/seti_boinc, but, it still works in the Older Systems. In Sierra you get 'There was a problem connecting to the server “setisvn.ssl.berkeley.edu”. ' El Capitan is the last one that will compile the CUDA App, so, I tried a few more CUDA compiles with 3883. No luck with the new CUDA Apps in High Sierra, after the task is finished BOINC gives a 'segmentation violation' instead of a 'called boinc_finish'. Strange that it doesn't happen with the tasks that Overflow, it happens only on the tasks that finish normally. So, what is BOINC checking at Finish on the normal tasks that it doesn't check on the Overflows? Or, what is the difference between an Overflow shutdown and a 'normal' shutdown?

I don't see any recent change to the sah_v7_opt folder, however, I also compiled a CPU App from the 3883 AKv8 folder in El Capitan and it too was about Twice as slow as the previous CPU Apps. Don't have a clue why there would be such a difference. If I get a chance today I'll try 3883 in Linux.

Oh, this machine really does have 4 GTX 1060s now, https://setiathome.berkeley.edu/show_host_detail.php?hostid=6796479
Unfortunately one is on a x1 extender, so it's a bit slower than the other 3, but, it's better than having Three 1060s and a 1050. We'll see how it does. Seems to be climbing in RAC....

I’m using svn checkout to download. Major changes I see are that the entire sah_v7_opt directory is not downloaded, only what looks like AKv8, but named seti. Also, options like —enable-sse42 are no longer valid.

I updated LDFLAGS to include "-L/home/rick/BOINCdev/boinc/api/". I have also downloaded and compiled the latest boinc source code, but the file boinc.o is still missing. Also, many of the flags previously used don't seem to work with 3883. Has anyone else tried to compile it?

I managed to download the 3883 version of sah_v7_opt by rebooting into El Capitan. For some reason you can't use the Connect to Server method in Sierra to connect to https://setisvn.ssl.berkeley.edu/svn/seti_boinc, but, it still works in the Older Systems. In Sierra you get 'There was a problem connecting to the server “setisvn.ssl.berkeley.edu”. ' El Capitan is the last one that will compile the CUDA App, so, I tried a few more CUDA compiles with 3883. No luck with the new CUDA Apps in High Sierra, after the task is finished BOINC gives a 'segmentation violation' instead of a 'called boinc_finish'. Strange that it doesn't happen with the tasks that Overflow, it happens only on the tasks that finish normally. So, what is BOINC checking at Finish on the normal tasks that it doesn't check on the Overflows? Or, what is the difference between an Overflow shutdown and a 'normal' shutdown?

I don't see any recent change to the sah_v7_opt folder, however, I also compiled a CPU App from the 3883 AKv8 folder in El Capitan and it too was about Twice as slow as the previous CPU Apps. Don't have a clue why there would be such a difference. If I get a chance today I'll try 3883 in Linux.

Oh, this machine really does have 4 GTX 1060s now, https://setiathome.berkeley.edu/show_host_detail.php?hostid=6796479
Unfortunately one is on a x1 extender, so it's a bit slower than the other 3, but, it's better than having Three 1060s and a 1050. We'll see how it does. Seems to be climbing in RAC....

---

GitHub: Ricks-Lab
Instagram: ricks_labs

Maybe this is true for GPU apps, but with stock CPU apps built with a generic instruction set, optimization should be possible, and this is what we see when we upgrade to optimized apps. My comparison is between zen optimized r3883 app vs sse4.2 r3306. It would be good to compare my results to stock r3883. Can anyone suggest configure options to produce stock equivalent?

I wonder if you will ever be as successful as the stock apps. I thought I remember reading a post that the stock apps had code that was highly hand optimized by Joe Segur and that there would be no way of beating their performance using just the stock compiling flags. Maybe someone can confirm my recollection.

---

GitHub: Ricks-Lab
Instagram: ricks_labs

Maybe this is true for GPU apps, but with stock CPU apps built with a generic instruction set, optimization should be possible, and this is what we see when we upgrade to optimized apps. My comparison is between zen optimized r3883 app vs sse4.2 r3306. It would be good to compare my results to stock r3883. Can anyone suggest configure options to produce stock equivalent?

I wonder if you will ever be as successful as the stock apps. I thought I remember reading a post that the stock apps had code that was highly hand optimized by Joe Segur and that there would be no way of beating their performance using just the stock compiling flags. Maybe someone can confirm my recollection.

But that is and was not the case with the cpu apps. They were never built with a generic instruction set. Joe Segur hand coded most of them and most of the AVX code path was written by Joe.
Just look at the output of any cpu app stderr.txt and see the developers listed.

Mike said in a message and Jason Gee, another one of our past developers stated so also.
Message 1856870

Way back when I made the windows build under v7, the difference on Core2 45nM having SSE4.1, was small (a couple of percent) over ssse3, though consistent and reproducible on the core2Duos of the time. I never managed to afford an AVX capable system yet myself for development. Since the adoption of AVX, and Intel compiler becoming unusable, the situation changed a fair bit in that time (close to 10 years overall since I started), and Joe Segur hand coded AVX into stock. He's disappeared since then, and no-one has been able to precisely tell me what's happened, so we're probably looking at finding or making new CPU app resources from scratch, more or less.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Maybe this is true for GPU apps, but with stock CPU apps built with a generic instruction set, optimization should be possible, and this is what we see when we upgrade to optimized apps. My comparison is between zen optimized r3883 app vs sse4.2 r3306. It would be good to compare my results to stock r3883. Can anyone suggest configure options to produce stock equivalent?

I wonder if you will ever be as successful as the stock apps. I thought I remember reading a post that the stock apps had code that was highly hand optimized by Joe Segur and that there would be no way of beating their performance using just the stock compiling flags. Maybe someone can confirm my recollection.

I don't believe that's possible. The Only Stock App from SETI is a Generic CPU App that is designed to work on All CPUs in a given Platform. Optimizing for a Single CPU isn't possible. For Optimizing for a particular CPU you use the sah_v7_opt code as opt stands for Optimized. There really isn't any such thing as a 'Stock' GPU App, as All GPU Apps are built by 'Volunteers' and submitted to SETI. If SETI deems the submitted GPU App as useful then it will be placed on the SETI Server for general use. Back with SETIv7 I did manage to have some Optimized Mac CPU Apps placed on the SETI Server, simply because they were Twice as fast as the Stock generic CPU App. Unfortunately a handful of people complained about the Optimized Apps not having a ScreenSaver and SETI decided to cave to the few and do the Science at Half speed...oh well.

Joe Segur hand coded most of them and most of the AVX code path was written by Joe.

You forgot the part about Joe never coding a SETIv8 App. All his work was with the SETIv7 App which hasn't been used in a couple years. If you want an Optimized App You use the Optimized Code folder, sah_v7_opt.

I’m just comparing analyzeFuncs.cpp from r3813 to r3883 and it looks like r3883 doesn’t include optimized code. No define for SIGNALS_ON_GPU or USE_SSE42. Not sure why svn checkout is not pulling optimized code.

---

GitHub: Ricks-Lab
Instagram: ricks_labs

Try; svn checkout https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt

The only App you will compile at svn checkout https://setisvn.ssl.berkeley.edu/svn/seti_boinc (i.e. the seti_boinc folder) is a Generic CPU App coded to run on All CPUs.
Hmmmm;

tbar@TBar-iSETI:~$ svn checkout https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt
Error validating server certificate for 'https://setisvn.ssl.berkeley.edu:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: setisvn.ssl.berkeley.edu
- Valid: from Mar 1 18:13:38 2010 GMT until Apr 1 18:13:38 2020 GMT
- Issuer: setisvn.ssl.berkeley.edu, SETI@home / Space Sci Lab, University of California, Berkeley, California, US
- Fingerprint: 0E:58:97:AE:27:B9:CB:79:5D:85:7D:B1:0C:89:FA:24:09:CF:E3:C9
(R)eject, accept (t)emporarily or accept (p)ermanently?

I wonder if that is why Sierra refuses to connect to this fake server...

Thanks! I went back to the original PM I got from Raistmer which is exactly what you suggest. I think I was relying on my command history on my original development system then used the svn command from the website on my new setup and got the stock version. The good news is now I know the issues with no pulses being reported is somewhere in the optimized code.

Try; svn checkout https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt

The only App you will compile at svn checkout https://setisvn.ssl.berkeley.edu/svn/seti_boinc (i.e. the seti_boinc folder) is a Generic CPU App coded to run on All CPUs.
Hmmmm;

tbar@TBar-iSETI:~$ svn checkout https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt
Error validating server certificate for 'https://setisvn.ssl.berkeley.edu:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: setisvn.ssl.berkeley.edu
- Valid: from Mar 1 18:13:38 2010 GMT until Apr 1 18:13:38 2020 GMT
- Issuer: setisvn.ssl.berkeley.edu, SETI@home / Space Sci Lab, University of California, Berkeley, California, US
- Fingerprint: 0E:58:97:AE:27:B9:CB:79:5D:85:7D:B1:0C:89:FA:24:09:CF:E3:C9
(R)eject, accept (t)emporarily or accept (p)ermanently?

I wonder if that is why Sierra refuses to connect to this fake server...

I'm still not having any luck getting the CUDA Special App to work correctly in High Sierra. The same problem exists with the oldest version right through the CUDA 9.2 version. The task finishes with the correct results printed and then BOINC gives an Error instead of a called boinc_finish. The Error is pretty much the same each time;

Spike count:    13
Autocorr count: 1
Pulse count:    0
Triplet count:  2
Gaussian count: 6

cudaAcc_free() called...
cudaAcc_free() running...
cudaAcc_free() PulseFind freed...
cudaAcc_free() Gaussfit freed...
cudaAcc_free() AutoCorrelation freed...
1,2,3,4,5,6,7,8,9,10,10,11,12,13
cudaAcc_free() DONE.

SIGSEGV: segmentation violation
Stack trace (8 frames):
0   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x0000000102ab314d _ZN7COPROCS5clearEv + 3389
1   libsystem_platform.dylib            0x00007fff6003ef5a _sigtramp + 26
2   ???                                 0x0000000000000000 0x0 + 0
3   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x000000010294200b _ZN10seti_errorC2EiPKciS1_ + 47931
4   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x00000001029512e2 _ZNSt3__16vectorIhNS_9allocatorIhEEE21__push_back_slow_pathIKhEEvRT_ + 18882
5   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x0000000102957eab _ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m + 1531
6   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x000000010293629e setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 + 4766
7   libdyld.dylib                       0x00007fff5fd30015 start + 1

Crashed executable name: setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92
Machine type Intel 80486 (64-bit executable)
System version: Macintosh OS 10.13.5 build 17F77
Thu Jun 28 05:21:25 2018

0   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x0000000102ac5346 std::__1::__tree<std::__1::__value_type<int, PROCINFO>, std::__1::__map_value_compare<int, std::__1::__value_type<int, PROCINFO>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, PROCINFO> > >::__insert_unique(std::__1::__value_type<int, PROCINFO> const&) + 998
1   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x0000000102ab3242 COPROCS::clear() + 3634
2   libsystem_platform.dylib            0x00007fff6003ef5a _sigtramp + 26
3   ???                                 0x0000000000000000  0
4   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x000000010294200b seti_error::seti_error(int, char const*, int, char const*) + 47931
5   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x00000001029512e2 void std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::__push_back_slow_path<unsigned char const>(unsigned char const&) + 18882
6   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x0000000102957eab std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) + 1531
7   setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 0x000000010293629e setiathome_x41p_zi3v_x86_64-apple-darwin_cuda92 + 4766
8   libdyld.dylib                       0x00007fff5fd30015 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0100001f  rbx: 0x00000003  rcx: 0x7ffeed2c7b58  rdx: 0x00000028
  rdi: 0x7ffeed2c7bc8  rsi: 0x00000003  rbp: 0x7ffeed2c7bb0  rsp: 0x7ffeed2c7b58
   r8: 0x00000607   r9: 0x00000000  r10: 0x000009c8  r11: 0x00000206
  r12: 0x000009c8  r13: 0x00000003  r14: 0x7ffeed2c7bc8  r15: 0x00000000
  rip: 0x7fff5fe7720a  rfl: 0x00000206

Anyone have any ideas?
I have found both cuda91 and 92 uses about 10-15% less system memory than 9.0, otherwise it appears they are the same.
I was also able to use the latest boinc-master 7.11 to build the new Apps, seems they finally fixed the 'posix-spawn' Error it's had for a while. Doesn't make any difference, it still gives the SIGSEGV instead of FINISH. It's extremely annoying to see a perfectly good result be trashed because of an Error after the task is Finished...

Now that's interesting. I managed to come up with a version of zi3xs3 that doesn't give the SIGSEGV Error. BUT, as with All versions of zi3x, it simply hates Every Overflow it sees. I tried the same compile with zi3v but it still gives the SIGSEGV. At least I now have One App that works in High Sierra, 6796475

So, look at the bottom of the Front Page, https://setiathome.berkeley.edu/top_hosts.php

Remind me again TBar. The zi3x series uses the inline CUDA libraries in the executable, correct? And are usually a few percentage faster than the zi3v series? Any chance of a production version of zi3xs3 making it to CA?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Yes, zi3x uses Static libraries and Direct Callback. It's about 15 to 20 seconds faster on my machines and produces about 10 times as many Inconclusives and many Invalids. This machine was running around 40 Inconclusives and Zero Invalids with zi3v, In progress (400) · Validation pending (2484) · Validation inconclusive (182) · Valid (1883) · Invalid (68), and it's just been a couple of days.
I don't think anyone would agree those numbers are worth 15 to 20 seconds to the Project.
I'd like to see zi3v with DC , my guess is it would be just as fast, without the warts. But, that's for someone else to code.