What I'd like to do is build some optimized apps that will work on my system, and perhaps the code under Xbranch is not a good place to start.

Hi Bobby,
You mentioned your GPU was AMD-Ati earlier, so you'd probably want to enquire about Linux-OpenCL builds for that (X-Branch, being Cuda, being proprietary nVidia only), with Lunatics. Pretty sure the source for that is somewhere around Cuda Xbranch sources. I'm not sure how far they've gotten with Linux ports of that, but imagine they're pretty close, if something isn't already operational.

I see your machine is Running V7 CPU tasks fine, but the GPU, not detected, is listed as '---'. Not sure what's up with that. You might have to check which GPUs are supported under AMD w/OpenCL, Boinc on Linux. There might also be certain drivers or runtimes needing installation for Boinc to pick it up (if it can).

HTH
Jason

I'm trying to figure out how to build optimized apps for V7 CPU tasks. I missed that Ivan mentioned CUDA in the OP, and thought this was a thread for porting V7 to Linux in general.

To the best of my knowledge AMD w/OpenCL requires proprietary graphics drivers (BOINC reports "No usable GPUs found") and I'm not going to install them; while I understand RAC would improve, there's system stability to consider.

Until last week I was using AK v8 optimized CPU apps from Lunatics, though these stopped working following the release of V7, and now I have stock apps which don't appear to crunch as well. I can wait for these to be built by others, though was hoping I could learn how to build them from others that have already managed.

---

I think you'll find it's a bit more complicated than that ...

Keep in mind that the MBv7 tasks do generally take longer to process than MB Enhanced.

Getting MB Cuda on to Linux is the last hurdle for my considering switching one of my hosts back to Linux. I had a more Linux hosts than Windows at one point, but when GPU applications became available, I switched many hosts to Windows to take advantage of that. Sorry that I haven't been reading this thread thoroughly but if you need another Linux tester, I should have a host available within the next few weeks.

---

Soli Deo Gloria

...Until last week I was using AK v8 optimized CPU apps from Lunatics, though these stopped working following the release of V7, and now I have stock apps which don't appear to crunch as well. I can wait for these to be built by others, though was hoping I could learn how to build them from others that have already managed.

Ah,
yeah V7 performs extra searches in the data (Autocorrelations), so take longer to process. To my knowledge stock V7 CPU apps received code optimisations including AVX support, newer FFT lib5raries & ported Alex Kan's Pulsefinding etc. Work's always ongoing though, so by all means take a crack at getting involved building, as you might find yourself getting faster versions sooner that way :)

Optimised Stock V7 CPU app code resides in Berkeley's svn repository at
https://setisvn.ssl.berkeley.edu/svn/seti_boinc
(svn checkout or web interface)

, and the right person to talk to at Lunatics would be Urs Echternacht, who may or may not already have improvements.

Jason

---

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

Bump, well the old' beast lives :D. A Ubuntu 11.10 p4 with GTX 260 in it, and sounds like a freight train. Took a bit of convincing to get the Cuda drivers updated and the Cuda 5 toolkit & samples running, but they do indeed, so a break from that while it does a few stock CPU tasks, before attempting to build X-branch.

Mmm, so newer cudart doing static linkage I gather, that's nice.

---

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

Bump, well the old' beast lives :D. A Ubuntu 11.10 p4 with GTX 260 in it, and sounds like a freight train. Took a bit of convincing to get the Cuda drivers updated and the Cuda 5 toolkit & samples running, but they do indeed, so a break from that while it does a few stock CPU tasks, before attempting to build X-branch.

Mmm, so newer cudart doing static linkage I gather, that's nice.

Once you get a build done, I will boot my i3 into Mint and take the app for a test run.

---

Once you get a build done, I will boot my i3 into Mint and take the app for a test run.

Great. One step at a time. Not a Linux Noob by any means, but probably will struggle with the library versions & such. I was just lucky the machine still boots & I didn't break the driver update.

---

"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 is this the thread that will tell me when Linux (x-86_64) CUDA V7 Optimised apps will be done. Could not see anything on the Lunatics site for CUDA on Linux for the new version ?

Hope someone is working on it somewhere.

---

Proud Founder and member of



Have a look at my WebCam

So is this the thread that will tell me when Linux (x-86_64) CUDA V7 Optimised apps will be done. Could not see anything on the Lunatics site for CUDA on Linux for the new version ?

Hope someone is working on it somewhere.

Releases are always announced in the sticky optimised applications thread here.

Cuda development has moved away from Lunatics - and development has never been on the front page anyway.

BTW Urs is working on AKv8c for Linux.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Should we invite Ivan over to CA?

yep, good Idea. Might make things a lot easier.

Will see if I can get my Linux beast alive sometime after work, then figure out what's needed for the full set of Cuda apps in parallel with Ivan. If it builds *something* pretty much off the bat, that's a good start. Figuring out if it's Xbranch, boincapi, boinc or other library/driver breaking might be the adventure, we'll see.

A couple of days of mainly doing other things...

It still segfaults when I try to run it under BOINC. I ran the Lunatics installer on my Windows machines last night and compared my app_config.xml file to the one the installer builds -- astropulse worked but the CUDA MB crashed. I tried moving my boinc apps back to the version I built the seti task with, and also added as many log flags as seemed useful to the cc_config.xml but didn't find any smoking guns in the BOINC log.

---

So is this the thread that will tell me when Linux (x-86_64) CUDA V7 Optimised apps will be done. Could not see anything on the Lunatics site for CUDA on Linux for the new version ?

Hope someone is working on it somewhere.

Releases are always announced in the sticky optimised applications thread here.

Cuda development has moved away from Lunatics - and development has never been on the front page anyway.

BTW Urs is working on AKv8c for Linux.

I have a test of his apps running on my dual booting i3 currently.

---

Should we invite Ivan over to CA?

yep, good Idea. Might make things a lot easier.

Will see if I can get my Linux beast alive sometime after work, then figure out what's needed for the full set of Cuda apps in parallel with Ivan. If it builds *something* pretty much off the bat, that's a good start. Figuring out if it's Xbranch, boincapi, boinc or other library/driver breaking might be the adventure, we'll see.

A couple of days of mainly doing other things...

It still segfaults when I try to run it under BOINC. I ran the Lunatics installer on my Windows machines last night and compared my app_config.xml file to the one the installer builds -- astropulse worked but the CUDA MB crashed. I tried moving my boinc apps back to the version I built the seti task with, and also added as many log flags as seemed useful to the cc_config.xml but didn't find any smoking guns in the BOINC log.

Sounds like I'll stick with the head of the old svn boincapi when I get that far, just in case there's an issue with the trunk or other later git versions.

Alright, adventures here too, as ubuntu 11.10 here (on Cuda 5's supported list for the toolkit, samples build & work including the OpenGL etc ) is past end of support, looks like more than a few packages to get i686 builds on x86_x64 going were either missing from ia32libs and/or makefiles not updated to be multiarched. So I've determined I'll let it update to 12.04 LTS on that x64 install, and put a seperate x86 install if i have to. That'll take a while.

Jason

---

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

...
Alright, adventures here too, as ubuntu 11.10 here (on Cuda 5's supported list for the toolkit, samples build & work including the OpenGL etc ) is past end of support, looks like more than a few packages to get i686 builds on x86_x64 going were either missing from ia32libs and/or makefiles not updated to be multiarched. So I've determined I'll let it update to 12.04 LTS on that x64 install, and put a seperate x86 install if i have to. That'll take a while.

Jason

Good move! Just one point (that might be annoying for some of the Linux users) : Users with older (incompatible) glibc will not be able to use your app. (just a hint, no bad intentions)

---

_\|/_
U r s

Good move! Just one point (that might be annoying for some of the Linux users) : Users with older (incompatible) glibc will not be able to use your app. (just a hint, no bad intentions)

What version of glibc do you call older? I upgraded my Linux pc's to glibc 2.14.1 to be able to use the x41g application.

This could be a good opportunity for a major upgrade of my Linux pc's as any Boinc version beyond 7.0.25 complains about missing or out-of-date libraries

---

Seti@Netherlands website

Good move! Just one point (that might be annoying for some of the Linux users) : Users with older (incompatible) glibc will not be able to use your app. (just a hint, no bad intentions)

What version of glibc do you call older? I upgraded my Linux pc's to glibc 2.14.1 to be able to use the x41g application.

This could be a good opportunity for a major upgrade of my Linux pc's as any Boinc version beyond 7.0.25 complains about missing or out-of-date libraries

Some might not have the opportunity to update their glibc's or BOINC as quick as you. (el5/el6 support by default glibc 2.11.x) Knowing that gave some base premise for building new opt. apps.

---

_\|/_
U r s

Good move! Just one point (that might be annoying for some of the Linux users) : Users with older (incompatible) glibc will not be able to use your app. (just a hint, no bad intentions)

What version of glibc do you call older? I upgraded my Linux pc's to glibc 2.14.1 to be able to use the x41g application.

This could be a good opportunity for a major upgrade of my Linux pc's as any Boinc version beyond 7.0.25 complains about missing or out-of-date libraries

Some might not have the opportunity to update their glibc's or BOINC as quick as you. (el5/el6 support by default glibc 2.11.x) Knowing that gave some base premise for building new opt. apps.

That's the problem I have (forced into SLC5) and why I've been building my own BOINCs for a while (plus they're needed to build s@h).

I've realised that there's an unstripped version of the executable in the build tree. I'm hoping that would give me a traceback on the exception (but does the stack dump go into stdout or stderr?), but I won't try for a while as I've got the benchmark script running right now. Minor differences in the results for the first WU (FG00091_V7.wu).

---

Good move! Just one point (that might be annoying for some of the Linux users) : Users with older (incompatible) glibc will not be able to use your app. (just a hint, no bad intentions)

What version of glibc do you call older? I upgraded my Linux pc's to glibc 2.14.1 to be able to use the x41g application.

This could be a good opportunity for a major upgrade of my Linux pc's as any Boinc version beyond 7.0.25 complains about missing or out-of-date libraries

Some might not have the opportunity to update their glibc's or BOINC as quick as you. (el5/el6 support by default glibc 2.11.x) Knowing that gave some base premise for building new opt. apps.

Haha, sounds like I'm stepping on the right land mines then. I do like older el & am familiar with it, so worst case is that I have to stack my old Linux box with a number of distros. Looks like multiple Cuda revisions might need that anyway, along with care to installation order & such. So all in all I'll call this a dry run on x64 ubunto 12.04, and fully expect that cards will like x86 builds better.

---

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

alright, deeper in now & can see what's happened.

Aside from the spotted issues, The original _autosetup --> configure sequence results in a client makefile that's 'a bit wonky' in terms of both cpu and Cuda compiler settings. Manually hacking that to setup the gpu architechure specifically for the GTX 260 in the machine resulte in an executable, which I'll have to test before going further. might work since I did manually override the architecture to the correct one for this card (as a test)

Well probably need to work out how best to revamp this source setup. The architectures in a releae build should include gencode binaries for each compute capability, plus forward compatible PTX. doesn't explain why yours is crashing under Boinc, and not standalone, though I suspect the boincapi may be building with incorrect options also...we'll see

---

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

And, first validation came in, with the Franken-build on the Franken-poota,
http://setiathome.berkeley.edu/workunit.php?wuid=1258979212
after a wild fright from the first task being a long running overflow.

It's not pretty, but a start to figure out where to go. Next step will probably be x86 distro with older libs... work out how to force static etc,as well as make it work for more than just GTX2xx on recent Cuda drivers.

[Edit:] and one computation error related to CUFFT. looks like we'll need to enable some of the safeties like the Windows build has (temp exits & thread safety)

---

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

Here's a partial listing of the benchmark results. Unfortunately we had a network glitch this afternoon in my building, which led to my desktop getting a new address from DHCP and "orphaning" my ssh session to the server. The results look close enough, if only I could come up with a method to find that pesky segfault! (Using the unstripped version didn't result in a traceback or any other information more in the stderr file.) Jason, which version of BOINC are you using on your Frankenputer?

----------------------------------------------------------------
Current WU: FG00091_V7.wu

----------------------------------------------------------------
Running default app with command :... setiathome_7.01_i686-pc-linux-gnu
./setiathome_7.01_i686-pc-linux-gnu 9825.01 sec 9755.18 sec 67.30 sec
Elapsed Time: ....................... 9825 seconds

----------------------------------------------------------------
Running app with command : .......... setiathome_x41_x86_64-pc-linux-gnu_cuda41
./setiathome_x41_x86_64-pc-linux-gnu_cuda41 7138.65 sec 106.92 sec 23.79 sec
Elapsed Time : ...................... 7139 seconds
Speed compared to default : ......... 137 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.94%

----------------------------------------------------------------
Done with FG00091_V7.wu

====================================================================
Current WU: FG00134_V7.wu

----------------------------------------------------------------
Running default app with command :... setiathome_7.01_i686-pc-linux-gnu
./setiathome_7.01_i686-pc-linux-gnu 9680.99 sec 9603.07 sec 75.33 sec
Elapsed Time: ....................... 9681 seconds

----------------------------------------------------------------
Running app with command : .......... setiathome_x41_x86_64-pc-linux-gnu_cuda41
./setiathome_x41_x86_64-pc-linux-gnu_cuda41 6808.87 sec 97.33 sec 20.85 sec
Elapsed Time : ...................... 6809 seconds
Speed compared to default : ......... 142 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.97%

----------------------------------------------------------------
Done with FG00134_V7.wu

====================================================================
Current WU: FG01307_V7.wu

----------------------------------------------------------------
Running default app with command :... setiathome_7.01_i686-pc-linux-gnu
./setiathome_7.01_i686-pc-linux-gnu 9441.82 sec 9363.48 sec 74.12 sec
Elapsed Time: ....................... 9442 seconds

----------------------------------------------------------------
Running app with command : .......... setiathome_x41_x86_64-pc-linux-gnu_cuda41
./setiathome_x41_x86_64-pc-linux-gnu_cuda41 2161.47 sec 88.19 sec 17.85 sec
Elapsed Time : ...................... 2161 seconds
Speed compared to default : ......... 436 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.97%

----------------------------------------------------------------
Done with FG01307_V7.wu

====================================================================
Current WU: FG02968_V7.wu

----------------------------------------------------------------
Running default app with command :... setiathome_7.01_i686-pc-linux-gnu
./setiathome_7.01_i686-pc-linux-gnu 14072.77 sec 14000.73 sec 69.50 sec
Elapsed Time: ....................... 14073 seconds

----------------------------------------------------------------
Running app with command : .......... setiathome_x41_x86_64-pc-linux-gnu_cuda41
./setiathome_x41_x86_64-pc-linux-gnu_cuda41 1502.04 sec 122.73 sec 16.70 sec
Elapsed Time : ...................... 1502 seconds
Speed compared to default : ......... 936 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.89%

----------------------------------------------------------------
Done with FG02968_V7.wu

====================================================================
Current WU: FG03853_V7.wu

----------------------------------------------------------------
Running default app with command :... setiathome_7.01_i686-pc-linux-gnu
./setiathome_7.01_i686-pc-linux-gnu 13757.72 sec 13642.14 sec 112.06 sec
Elapsed Time: ....................... 13758 seconds

----------------------------------------------------------------
Running app with command : .......... setiathome_x41_x86_64-pc-linux-gnu_cuda41
./setiathome_x41_x86_64-pc-linux-gnu_cuda41 1250.23 sec 105.88 sec 23.00 sec
Elapsed Time : ...................... 1250 seconds
Speed compared to default : ......... 1100 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.91%

----------------------------------------------------------------
Done with FG03853_V7.wu

---

Here's a partial listing of the benchmark results. Unfortunately we had a network glitch this afternoon in my building, which led to my desktop getting a new address from DHCP and "orphaning" my ssh session to the server. The results look close enough, if only I could come up with a method to find that pesky segfault! (Using the unstripped version didn't result in a traceback or any other information more in the stderr file.) Jason, which version of BOINC are you using on your Frankenputer?

Looks like 6.10.58.

---