Posts by ivan

Grant. I think you're going to worry yourself
into an early grave.

Not worry, Panic.

And keep in mind this is the first generation of Xeon Phi, GPGPU computing has been around for over 5 generations.
The Xeon Phi has a huge potential in it's field.

A quick glance at my Linux boxes shows Astropulse runs about 50 MB and Seti7 runs 40 MB so there's no way to get all 240 threads running a WU each. Intel reckons that two threads/core is the sweet spot for big calculations, though.

Can it execute OpenCL on CPUs ?
If yes then OpenCL MB and AP can be configured to run few own instances each using few dozens of CPU cores, for example. This will reduce memory footprint considerably while using almost all CPU cores (in degree almost all GPU "cores" used now).

Are there any plans for SETI@HOME to support the Intel Xeon Phi coprocessors?

For something that specialised it'll be up to someone to volunteer their services to develop the support for the hardware.

And an extra-Z80 processor so I can run CP/M apps.
I'm still working on porting SETI@home to it.

I wonder if there's an FFT that can run in 1KB (ZX80) or 48KB (C64). :-)

I used to do 256-channel FFTs in CBASIC on a (Z80) Exidy Sorcerer -- cutting-edge stuff in Antarctica in 1980. It was faster to precompute the arrays of sins and coses needed, and then read them in from floppy disk, than to calculate them every run.

Hey - another Sorcerer user - I've still got mine in the cellar. But I did boring things like word processing and mailing lists on mine.

And an extra-Z80 processor so I can run CP/M apps.
I'm still working on porting SETI@home to it.

I wonder if there's an FFT that can run in 1KB (ZX80) or 48KB (C64). :-)

Discussed in 'Porting s@h V7 to Linux':
http://setiathome.berkeley.edu/forum_thread.php?id=71818

All 3 rigs now updated to 314.22 drivers.

We'll give 'er a meow and see how it flies.

The ones I checked happened after completion of the work. The OpenCL AstroPulse crash after processing completion - write here. thread discusses that. The cause is not fully understood, so the problem not fully fixed.

Joe

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

Add a pause at the beginning and once BOINC has started it attach gdb to running process?

[And hope the pause doesn't make the error disappear :)

edit: Come to think of it, you could configure you system to dump core and give that to gdb.

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.

Yep, prepackaged 6.10.58 Berkeley one installed in my home folder.... as opposed to the locally tailored 6.10.58 on my Windows machines.

Well even though the credits have plummeted my 2 recently upgraded rigs are still climbing the RAC ladder with my Q6600 now up to 72nd and my 2500K up to 94th (78th & 104th prior to change) so it isn't all that bad from my POV.

Cheers.

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.

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.

I would suggest providing an init_data.xml, either from a Boinc install or the test pack. probably won't change much, only help see if there is failure further on, such as checking for Boinc's shared mem (which won't be there standalone, or in a test bench)

Couple of things:
- That explains the 20 seconds. There must have been a completed state file present (uncleared from the first test task ?, indeed first one looks proper timing for a VLAR)
- On Windows, Cuda 4.1 release had a rather serious flaw involving the CUFFT & mixed generation GPUs in the same host. That could conceivably be a problem on Linux as well I guess, and may well explain your Sig 11's (just one possibility). Cuda 3.2, 4.2, 5, and probably the 5.5rc shouldn't have that particular issue.

How many creds do you need to replace a 1990 Oldsmobile Ciera anyway?

Meanwhile the FGset have finished so I'll process them anyway.