Not so sure I fully agree here. I agree with the first part, that the app has to work (be stable) and produce valid results, but rather than focusing on speed the focus should be on compatibility with a wide range of hardware (relatively speaking). The SETI@home stock applications have always focused on compatibility over speed so as to gain the most widespread support on a variety of hardware. Optimizations didn't come until the code went open-source and people starting compiling their own.

First of all, like i said earlier, all apps running on most of the cards.
I`m testing all apps for compatibility first.
So that`s our first goal too.

Entry Level GPU`s (AMD) have some restrictions so it make sense to implement special functions for those cards.
Can`t speak for NV part here.

Like mentioned in the Lunatics Read Me we can`t test on all kind of GPU`s out on the market simply because lack of man power and Hardware.
But the apps work.

It is normal that some volunteers have different priorities but that wouldn`t be different if we did it with an other focus.
You simply can`t make everyone happy.
But we make sure to fit the majority.
At least we are trying to.

---

With each crime and every kindness we birth our future.

P.S. and regarding your funny ignorance about what SoG means... use the search they say? ;)

https://www.sogknives.com/

---

The stock application has to be above all, stable on all platforms.
Beyond reproach.

Additional optimizations are up to those who wish to undertake them.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

P.S. and regarding your funny ignorance about what SoG means... use the search they say? ;)

https://www.sogknives.com/

Or just use http://www.acronymfinder.com/SoG.html

If you think that is bad. We now have 12 Android apps. After 4 or 5 months of running nearly 24/7 I still did not have the required "completed" tasks for each app.

I really think that being able to enable/disable apps by their plan class should be a default BOINC option.

. . Here, here!

or is that Hear! Hear! :)

P.S. and regarding your funny ignorance about what SoG means... use the search they say? ;)

https://www.sogknives.com/

Or just use http://www.acronymfinder.com/SoG.html

. . I found one that fits perfectly "Same Old Grind"

. . Thanks

Shooters of Gin :D

---

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

From the CUDA Toolkit thread-

NB to those who think "there should be only single OpenCL app" - ... go figure!

For stock, yes.
For optimised applications, obviously not.

Ideally we would have Seti@home running on as many systems as possible. To do that it would just be a case of download & install BOINC, select Seti@home as our project & then let it go. The more complicated it becomes, the more likely it is there will be issues, and more of them, and making them even more difficult to resolve.


The most important thing from the project's point of view is the science- the work returned needs to be correct. As we have seen each time optimised versions have been released they push the hardware closer to it's limits, and sometimes beyond, resulting in errors or invalid work.
We don't want that happening on set & forget systems.

The stock application should return valid work, and taking hardware to it's limits increases the likelihood of invalid work being returned. And if invalid work is being returned it will make it much more difficult to sort the issue out if there are multiple applications, with multiple possible settings, that need to be addressed to resolve the problems.
Given the issues here in the forums (that only a very small percentage of users make use of) in testing new applications & their settings it makes sense (to me) that the stock application should be as compatible as possible & not drive the hardware towards it's limits.


The developers set the limits- what is the minimum supported hardware? Minimum supported OS?
Once decided, the stock application would ideally support all the hardware from the baseline, to the current systems. Ideally the stock application would not make use of (or only very minimal use of) the most recently supported features of that CPU (eg AVX2, only use AVX; SSSE3, only use SSE3; SSE3, only use SSE2 etc). eg My i7 system had no issues running SSSE3 (which was a big jump up on the previous version performance wise), however going to AVX required an aftermarket cooler; the increased amount of heat produced was that great.
If testing shows that using the most recently supported features doesn't add any significant load to the CPU over using the previous one (ie CPU temps rise no more than 2°c, CPU fan speed increase is less than 10%) then it would probably be OK to use for the stock application, however it would be better to be cautious.
The important thing for the stock application is that it return valid work with no intervention necessary from the user.


In the case of GPUs there would ideally be a single stock application, however there are 3 different architectures with significant numbers in use, so there needs to be 3 different applications in order to support them. Only the GPU architecture in use on the system needs to be installed.

The developers need to set the minimum supported hardware. In the case of NVidia GPUs there was a significant change in architecture from Fermi onward. So a single application isn't possible to support all the hardware that is supported by the project.
So in this case there should be 2 applications, only the one being installed (or 2 if combinations of hardware on system- although less likely for set & forget non-crunchers) to support the hardware on the system.
Once again, the important thing is returning valid work, not how close to 100% the load is on the GPU.


Efficiency is good, hell it's important.
However the most important thing is the science, and the best way of returning valid work is not to push set and forget systems to their limits.
When people are installing BOINC & selecting Seti, let them know then about the forums & that there applications available to get the most from their system- but don't use the basic stock installation to boost efficiency.

All you need to do is look & the Windows 10 Yea or Nay hatred thread for the paranoia that results from something being pushed on to people without their knowledge or consent.
Mobile phones & the like have had automatic updates, upgrades, reporting of your phone, email, chat & browsing habits for years. But doing the same thing to someone's PC results in a huge backlash.

Better just to let people install & get Seti running and returning valid work, than have a whole lot of background optimising going on (without their knowledge or consent) and increasing the risk of invalid work because their hardware isn't up to the increased load.
If people want greater efficiency, let them chose it- don't force it on them.


EDIT- added note on my i7 system.

---

Grant
Darwin NT

From another thread-

Don't see why "stock" should be made deliberately slower than "optimized".

It isn't.
The stock application isn't made slower, the optimised applications are made faster than stock. I'm sure many will consider it nitpicking, but it is an important distinction.

The stock application comes first, it is the original, the reference point. It produces valid work on the widest possible range of hardware. It's not about speed, it's about accurate results, with no impact on the performance or the useability of the machines it is running on.
Then the optimised applications come along, and their primary goal should be to produce valid work, their secondary goal to produce as much of it as possible in the shortest possible time frame. There should be options to allow people to still use their systems while doing as much crunching as possible, and then for those with dedicated crunchers to optimise for maximum throughput, regardless of any effects on system usability.

The stock application is not made to be slower; the optimised applications are made to be faster.

---

Grant
Darwin NT