Your better off posting your problem over in the Number Crunching forum. This one is for News items.

If you see numerous failures from Intel GPU app please post links to host in this thread: http://setiathome.berkeley.edu/forum_thread.php?id=74179

---

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

Is somebody working on OS X GPU-Support?

I wish I could say someone was on it full time. We have a MacOS ATI astropulse app in the beta project if you'd like to help test it.

---

@SETIEric@qoto.org (Mastodon)

Tom, I don't think that ATI program will work on your system. Your computer is running an integrated Intel, not an AMD ATI Graphic. Just thought I should mention it before you tried running that program on your computer.

Yeah, in theory it's possible to make a device independent OpenCL app. But thus far it doesn't seem to have been done. Jason, Josef or Raistmer will correct me if I'm wrong about that.

---

@SETIEric@qoto.org (Mastodon)

Yeah, in theory it's possible to make a device independent OpenCL app. But thus far it doesn't seem to have been done. Jason, Josef or Raistmer will correct me if I'm wrong about that.

That's one of the challenges I'm currently facing, moving X-branch x42 toward fully dynamic heterogeneous capability.

There are a number of roadblocks, but none insurmountable. Most of those actually revolve first around boincapi and client limitations, then the four known credit System design flaws currently under detailed analysis.

The only barriers that really revolve around OpenCL per se, are slightly different implementations by hardware vendor, which Raistmer has already shown are manageable separately, so can be managed with unified conditional code down the line.

Also The Cuda builds cope with 6 quite different GPU architectures, though there are OS induced latency issues to be solved there, by refocussing on new ways to determine optimal code paths. The literature suggests a combination of traditional ( multibeam + fttw ) wisdom-like runtime optimisation, plus some amount of hardware awareness and narrowed search space by offline (install-time) optimisation (like mobile devices do), and hard dispatch, would yield the best usability results, though require some thought toward different user goals (like efficiency versus throughput versus display responsiveness or application sharing)

---

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

...then the four known credit System design flaws currently under detailed analysis.

Jason, can you elaborate on this part of your response?

---

The really short summary is, it sucks and nobody else uses it. Which is why most other projects give more credit than SETI@home, (although some projects are incredibly ridiculous about the credits they give).

---

@SETIEric@qoto.org (Mastodon)

...then the four known credit System design flaws currently under detailed analysis.

Jason, can you elaborate on this part of your response?

Sure, I'll summarise here. I did post more details in NC a while back, but these tend to get buried in mayhem. The Collatz April Fools joke post makes a nice summary too ;)

#1) Coarse scaling error: The FLOPs estimates from returned tasks at validation time, which get converted to the cobblestone scale to aquire a raw credit claim, are based on Boinc Whetstone [and elapsed time]... which for CPU implies that FPU, SSE-SSE3, and AVX are all the same. As the detected 'most efficient' application (stock CPU for multibeam), scales down every other application, then there is an effective underclaim of between 2.85 and 8x (probably around 3.3, subject to isolating the actual SIMD performance of modern processors & applications. That's important because creditnew is ignoring what's known as 'Instruction Level Parallelism'

#2) Stability: In Engineering senses, Credit awards show all the instabilities (ringing, overshoot, and skew) associated with an uncalibrated control system. Mathematically the system is a Sigma type feedback with some weighting, which is the same algorithm as a cheap DAC in a $5 disposable CD player. I'd like to see a properly stabilised PID controller implementation, one time tuned, with proper damping... for each of the two scales (host scale and gloabal app version scale). The current implementation appears to meet the requirements for Chaos, which are 'sensitivity to initial conditions', and some 'stirring' by the way validation times mix up estimates/avergaes, and self similar looking oscilaltions. (different to 'random')

#3) No Multithreading support: Milkyway users complained when MT plan class applications divided credits. Obviously Elapsed time 'per resource' should be being summed, making it greater than wall-time. It's used directly

#4) Overly sensitive to Task estimates: This really, in control theory, is a side effect of the earlier items. The task estimates only need to be a theoretical minimum (usually established from numerical computing theory). The problem here is that system is then receiving shorter elapsed times then expected (i.e. impossible), then downscaling estimates for everyone (feedback), and so attempting to convince us that magic is real, as opposed to some of the systems assumptions being faulty [such as the faulty assumption that stock CPU applications have no parallelism].

The old system used a credit multiplier of 2.85, which was removed/disabled. That would have been about right for SSE-SSE3 type SIMD implementation.. since AVX for multibeam we need a larger figure I believe around 3.3, but it'll be nicer to maintain the working - self scaling, self correcting - aspects of creditNew, but fix those assumptions, and damp the oscillations. Doing those things and embedding a little foresight toward upcoming technology change, will probably be a wise investment now, more useful long term than just piling on more bandaids and workarounds.

---

"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'll laugh at the Collatz joke when they start counting operations and using that to grant credit.

---

@SETIEric@qoto.org (Mastodon)

I'll laugh at the Collatz joke when they start counting operations and using that to grant credit.

I suppose us [temporarily] switching back to flopcounts with a SIMD compensating credit multiplier is out, given the logistics...

---

"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 wish. David stripped out the APIs entirely.

---

@SETIEric@qoto.org (Mastodon)

I wish I could say someone was on it full time. We have a MacOS ATI astropulse app in the beta project if you'd like to help test it.

Several of us have been using the Mac ATI GPU AP app since it was released there last year. No issues thus far, its probably ready for prime time.

Chris

---

I'd like to see a properly stabilised PID controller implementation, one time tuned, with proper damping

I was already in over my head before this line!

---

@Jason/Eric

Could be an "stupid sugestion" but: Why you not simply multiply the credits paid by MB & AP for a number who "aproximately compensate" the diferences until you could realy fix the problem?

I know this is a "non technical" solution but ... If some sort of balance is achieved sure most of the complains will end and you will gain the time needed to develop the real solution.

---

The server uncompensates for attempts to compensate.

---

@SETIEric@qoto.org (Mastodon)

The server uncompensates for attempts to compensate.

Then we are doomed... Snif!

Sorry but i can´t understand why you simply can´t add a simple multiplier to the actual credit paid. Something like (not the actual values just a guess)

MB Credit = MB Credit * 3.3

After all the creditscrew calculations where made, Nothing else. NO chanches in the Creditscrew code itself (that´s for another time).

If IIRC 3.3 was the number finded by Jasons as the discrepance on the values (i could be wrong)

Something similar could be made on the AP section.

---

The server uncompensates for attempts to compensate.

Then we are doomed... Snif!

Sorry but i can´t understand why you simply can´t add a simple multiplier to the actual credit paid. Something like (not the actual values just a guess)

MB Credit = MB Credit * 3.3

After all the creditscrew calculations where made, Nothing else. NO chanches in the Creditscrew code itself (that´s for another time).

If IIRC 3.3 was the number finded by Jasons as the discrepance on the values (i could be wrong)

Something similar could be made on the AP section.

Basically the system is a lot like one of those mechanical governers on a steam engine (but with the wrong kindof ball weight, and some bent pushrods at the moment... hooked to another for each passenger...).

You can wedge a brick in it to keep the throttle open, but then the boiler explodes and everyone dies, or the thing runs out of control derails & runs through downtown San-Francisco :)
[ Then also, piling on bandaids is probably what created the bent pushrods in the first place ]

The way to fix it would be to unbolt the device, make all the adjustments and test, then reinstall and finetune. The difference here is that we have to do it while the vehicle's in motion and fully loaded with passengers. Since Albert's willing to let us use their beta to test & tune some things (in time), we're hopeful for an Apollo 13 style rescue, over a Coors-Light party train disaster.

---

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

Since Albert's willing to let us use their beta to test & tune some things (in time), we're hopeful for an Apollo 13 style rescue, over a Coors-Light party train disaster.

Any ideia when the test begins? I allready join Albert to help with that.

The difference here is that we have to do it while the vehicle's in motion and fully loaded with passengers.

A nice challenge not? :)

---