I've Built a Couple OSX CUDA Apps...
Message boards :
Number crunching :
I've Built a Couple OSX CUDA Apps...
Message board moderation
Previous · 1 . . . 18 · 19 · 20 · 21 · 22 · 23 · 24 . . . 58 · Next
| Author | Message |
|---|---|
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 
 |
The only way I could compile with Xcode 7.2.1 was to remove everything between lines 164 & 304. Not sure about the effects that would have, except it stopped the errors. https://setisvn.ssl.berkeley.edu/trac/browser/branches/sah_v7_opt/Xbranch/client/alpha/PetriR_raw/cuda/cudaAcceleration.h I suppose I could let it run for a while and see if it helps with the inconclusives. In testing it uses just as much CPU as the other version, nearly 100% on my Mac. ID: 1770557 ·  |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
It looks as though the same 'crash after finish' error is still there. This is about the 6th one I've seen. Seems to happen with All the builds. The task is finished, the results match the wingpeoples, the runtime is normal for that AR. Yet it gives a crash; http://setiathome.berkeley.edu/result.php?resultid=4779898044 Spike count: 5 Autocorr count: 0 Pulse count: 0 Triplet count: 2 Gaussian count: 0 SIGBUS: bus error Crashed executable name: setiathome_x41p_zi_x86_64-apple-darwin_cuda75 Machine type Intel 80486 (64-bit executable) System version: Macintosh OS 10.10.5 build 14F1605 Wed Mar 9 12:19:46 2016 atos cannot load symbols for the file setiathome_x41p_zi_x86_64-apple-darwin_cuda75 for architecture x86_64. 0 setiathome_x41p_zi_x86_64-apple-darwin_cuda75 0x0000000108cf8e88 SIGPIPE: write on a pipe with no reader 1 setiathome_x41p_zi_x86_64-apple-darwin_cuda75 0x0000000108ce7e66 SIGPIPE: write on a pipe with no reader 2 libsystem_platform.dylib 0x00007fff9746ff1a SIGPIPE: write on a pipe with no reader 3 libsystem_malloc.dylib 0x00007fff8fcd9b1d SIGPIPE: write on a pipe with no reader 4 setiathome_x41p_zi_x86_64-apple-darwin_cuda75 0x0000000108b735b7 SIGPIPE: write on a pipe with no reader 5 setiathome_x41p_zi_x86_64-apple-darwin_cuda75 0x0000000108b833f2 SIGPIPE: write on a pipe with no reader 6 setiathome_x41p_zi_x86_64-apple-darwin_cuda75 0x0000000108b89f46 SIGPIPE: write on a pipe with no reader 7 setiathome_x41p_zi_x86_64-apple-darwin_cuda75 0x0000000108b65dc9 SIGPIPE: write on a pipe with no reader 8 libdyld.dylib 0x00007fff98f7e5c9 SIGPIPE: write on a pipe with no reader 9 ??? 0x0000000000000003 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0100001f rbx: 0x00000000 rcx: 0x7fff57098fc8 rdx: 0x00000028 rdi: 0x7fff57099030 rsi: 0x00000003 rbp: 0x7fff57099010 rsp: 0x7fff57098fc8 r8: 0x00000a0f r9: 0x00000000 r10: 0x000003b0 r11: 0x00000206 r12: 0x000003b0 r13: 0x00000028 r14: 0x7fff57099030 r15: 0x00000a0f rip: 0x7fff98e834de rfl: 0x00000206 ... It usually happens with a shorty... ??? ID: 1770569 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Oh well, that seemed to make the 'SIGBUS: bus error' even worse... I found App Cleaner does a very good job cleaning out Xcode. If you have a local copy you can have Xcode 6.1.1 up and running in just a few minutes. Seems using it with the 10.10 SDK brings back the Object.h error, however, the ASM Errors are gone. If you use Xcode 6.1.1 with the 10.9 SDK All the Errors are Gone...nice. The resulting 6.1.1 App even worked on the same shorty that had failed twice with the Xcode 7.2.1 generated App. This could be interesting. All I need is a few more shorties to test, there doesn't appear to be many around though. Bring on the Shorties please. ID: 1770643 · |
 Gary Charpentier     Send message Joined: 25 Dec 00 Posts: 30934 Credit: 53,134,872 RAC: 32
 |
SIGPIPE error write on pipe with no reader means that the science app is trying to tell BOINC that it is done, but BOINC already knows it is done and closed the pipe. Should not happen. Possibly a error return on a pipe call was missed setting up a race. I doubt that the issue is related to different libraries or language standards, e.g POSIX vs GNU, but possible. 
ID: 1770673 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
So far I've received one SIGBUS error with the new build. After the 2nd try I turned the thing into a ghost, that would be this one; http://setiathome.berkeley.edu/workunit.php?wuid=2088328123 I'll deal with that one later, maybe bring it back as a cpu task. For now, forget about the Error list and just watch the Inconclusive list. I don't think you're going to see many of those anymore. The last build matches the results from a known good cpu app very closely. Usually that translates into very few Inconclusives. Now to fix the SIGBUS problem, if possible. This sounds similar to an ancient problem with BOINC a few of us are familiar with. ID: 1770684 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Well, I've tried everything I can, and I'm still getting these blasted SIGBUS Errors on shorties. I tried compiling it with bonic-master 7.5 & 7.7, switched to the newest version of BOINC, no luck. It appears the Inconclusives have been tamed, about the only inconclusive results now are Immediate Overflows and unreliable wingpeople. So, we fix the SIGBUS Errors and it's ready for Prime Time, right? Right??? ID: 1770818 · |
jason_gee  Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 
|
So, we fix the SIGBUS Errors and it's ready for Prime Time, right? 'PrimeTime' as is Advanced user widescale testing. Considerably more work to do for stock integration. "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. ID: 1770825 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
I still haven't been able to compile an App using Petri's code in Yosemite or El Capitan that doesn't have the SIGBUS problem. I don't have that problem with the Apps compiled in Mountain Lion. The highest CUDA Toolkit you can use in ML is 6.5. All the earlier Apps were compiled in Mountain Lion, I went back to one of those Apps for now. The latest problem is trying to use Xcode 6.1.1 in El Capitan with ToolKit 7.5. The build is stopping with two Errors; analyzeFuncs.cpp:1691:9: error: use of undeclared identifier 'cdft' cdft(NumPointsInChunk*2, 1, DataOutChunk, BitRevTab, CoeffTab); analyzeFuncs.cpp:1762:30: error: use of undeclared identifier 'cdft' cdft(NumPointsInChunk*2, -1, DataOutChunk, BitRevTab, CoeffTab); If I try adding either of the fft8g files it gives another error and just keeps snowballing. Any idea how to stop that Error without creating new ones? ID: 1771418 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 
 |
Gianfranco Lizzio had the same problem with cdft. He might be able to help. 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 ID: 1771428 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
If using the gnutools mechanism, you may need to go through and take out the compiler define to use FFTW. Probably by Analyzefuncs.cpp a #define is clobbering oura FFT's include and other parts. That's because Xbranch hasn't used FFTW for a very long time, as the setup time for the baseline smoothing with fftw exceeds the time to just baseline smooth with Ourra. Naturally my flat Makefile just doesn't define USE_FFTW at all Next major version all the FFT's become plugins anyway, so the awkward preprocessor directive blocks disappear from most of the code, being one of the least nice ways of having separate copepaths. "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. ID: 1771469 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Seems to be a large number of lines dealing with FFTW in Analyzefuncs.cpp. Apparently I'm not choosing the correct ones to delete. Would you please post the part(s) I should remove. ID: 1771475 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
Simply everywhere it says #ifdef USE_FFTW, or #if defined(USE_FFTW), just change it to #uf 0, and the remaining spaghetti code will activate what's needed, most importantly the fft8g include near the top "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. ID: 1771486 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Unfortunately that doesn't seem to work either. It just turns a couple errors into many. Each attempt to correct a new error merely results in more...they're replicators... Hmmmm, if you put include fft8g.cpp Right under the "----CUFFT----" at the top the errors go away. I suppose it matters Where you put it. ID: 1771492 · |
Gianfranco Lizzio  Send message Joined: 5 May 99 Posts: 39 Credit: 28,049,113 RAC: 87 
|
Tom after ./compile ... the problem is in analyzeFuncs.cpp in the client folder. You have to append the follow line code #include <fft8g.h> after #endif // USE_IPP It works successfully for me. I don't want to believe, I want to know! ID: 1771505 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
should do :), who knows what gnutools is doing with the #defines, lol. "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. ID: 1771508 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
I ended up adding #include "fft8g.h" under CUFFT instead of "fft8g.cpp". So the change is now; #pragma message ("-----mmx-----") Even with cleaning up the Rube work it still failed in Yosemite with a linker error. After once again removing the 750s and booting into Mountain Lion the same code compiled without any trouble. So, I added a couple frameworks and built a new CUDA 6.5 App in ML. Seems to be working very well, the only inconclusives are from Immediate Overflows and Suspect wingpeople. Unfortunately it still uses a full CPU, unlike the Apps compiled with the older code. Since it uses a full CPU the -poll command doesn't have much affect. The -poll command does help the older App though, at the expense of using a full CPU. Take a look at the CUDA 42 App using the -poll command, the last part is with the command on; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72013 It speeds up the lower angle range tasks as well. ID: 1771600 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Two days later and the New Special Cuda 65 App, compiled in Mountain Lion, appears to be working well. Seems the SIGBUS Errors have disappeared. It's possible there may be more Inconclusives in El Capitan than Yosemite, but it's too early to determine. The Inconclusives in Yosemite are Very Low considering the amount of Valid results. I ran the app on Beta last night and the results were very consistent; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=63959 Speaking of Inconclusive results, I was looking at one of the recent returns; http://setiathome.berkeley.edu/workunit.php?wuid=2095009935 I looked at the nVidia tasks on that host and the best I can tell EVERY task was Inconclusive, except the Overflows, taking at least three results to Validate. That would be around a 100% Inconclusive rate. Now compare that to the Standard CUDA 65 App which has been available since Jan 21st, http://setiathome.berkeley.edu/results.php?hostid=7366840&offset=180. The CUDA 65 App has ZERO Inconclusives and preforms much faster on similar Hardware. That would be a 100% Validation rate as opposed to around a 100% Inconclusive rate. Heck, even the Special CUDA 65 App beats the current 'Official' App. Whatever... In other news I'm about to switch one of the Linux machines from ATI cards to two old nVidia cards and run the CUDA 42 App for a while. I plan on testing what happens when I use the opencl_ati5_sah plan class on the CUDA 42 App. Any predictions on the outcome? Of course I plan on disabling networking and having a backup BOINC folder...I remember the last time I tried that. ID: 1771923 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
I use <plan_class>opencl_nvidia_100</plan_class> with my cuda 6.5 special. You might get some more VLAR tasks and depending on your hardware it might be OK or not. I'd leave an entry for the old plan class too if the cache is not empty. 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 ID: 1771982 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
Hi TBar, Do you have a CUDA app that does not use a full core on your mac? If yes, I'd compare the piece of code that sets the cuda driver to yield, poll or whatever the third word is (a temporary dementia/amnesia has hit me). Another place to look at is the lines in my code that call nanosleep in a loop. They could be replaced with a normal cuda synchronization code for a CPU thread. You can look at the code in the cuda part of the pulsefind when the CPU is waiting for a stream to finish its work. 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 ID: 1771985 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
Sidenote: might have the facilities in place to parametrise those settings soon, if you locate any of help during experiments. I've been using adding .cfg file parsing for Mac+Linux as a test for gradle build automation. "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. ID: 1772000 · |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.