Richard Haselgrove wrote:

Double-check whether all of the applications you are referring to by plan_class names are actually different binary executables. I think they probably are, this time round, but it's as well to be sure. In earlier incarnations, sometimes the same app appeared in different clothes - e.g. so that an OpenCL app could present and be run as a straight ATI/CAL app for the benefit of a pre-OpenCL client.

Let's see...
SAH is not used on APUs.
CAT132 is not used on APUs.
NOCAL is not used on APUs (although this is strange, it includes _ATI_, but as far as I know there are no pre-ATI5 GPUs that don't have CAL support.)
SOG is not used on _ATI_

According to the Applications page we have the choice of: opencl_ati5_cat132, opencl_ati5_nocal, opencl_ati5_sah, opencl_ati5_SoG, opencl_ati5_SoG_cat132, opencl_ati5_SoG_nocal, opencl_atiapu_sah, opencl_atiapu_SoG, opencl_ati_cat132, opencl_ati_nocal, opencl_ati_sah
Thus far I have seen:
setiathome_8.12_windows_intelx86__opencl_ati_sah.exe
setiathome_8.12_windows_intelx86__opencl_ati5_sah.exe
setiathome_8.12_windows_intelx86__opencl_ati5_SoG.exe
setiathome_8.12_windows_intelx86__opencl_atiapu_sah.exe
setiathome_8.12_windows_intelx86__opencl_atiapu_SoG.exe

What I see is that opencl_ati5_cat132 is run with setiathome_8.12_windows_intelx86__opencl_ati5_sah.exe and opencl_ati5_SoG_cat132 with setiathome_8.12_windows_intelx86__opencl_ati5_SoG.exe

Richard Haselgrove wrote:

I think that the best current answer is more along the lines of "no-one can predict which application will perform best on a given host, given the variety of hardware platforms (GPU + host CPU/motherboard) run by volunteers here - which greatly exceeds the number of platforms run by testers". So Eric lets BOINC work it out by itself.

Then how does a project like Primegrid manage to run 24 different kinds of prime calculations with all just one application per sort of hardware? They must be aces in being able to predict how their applications work on the variety of different sorts of hardware. Or maybe they're just not thinking too difficult about it, and just have the one application fits all methodology. :)

In that sense it really doesn't matter what the science is that's being done, whether it's to find the first tooth paste commercial of the aliens nearest to us, or to find a prime with more than 1,024,921 digits.

---

msattler wrote:

Maybe the diversity of hardware requires more apps than some would realize.

Hardware is hardware is hardware. There's a big difference in hardware between a Pentium 4 CPU, an early AMD Athlon and the newest Intels and AMDs. Yet they all run one and the same v8 application. There isn't even a 64bit version of the application, just one plain 32bit version.

As long as it all works, this is a rather stupid question in the first place.

"There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question". ~ Carl Sagan, The Demon-Haunted World: Science as a Candle in the Dark.

---

Then how does a project like Primegrid manage to run 24 different kinds of prime calculations with all just one application per sort of hardware? They must be aces in being able to predict how their applications work on the variety of different sorts of hardware. Or maybe they're just not thinking too difficult about it, and just have the one application fits all methodology. :)

In that sense it really doesn't matter what the science is that's being done, whether it's to find the first tooth paste commercial of the aliens nearest to us, or to find a prime with more than 1,024,921 digits.
____________

That`s not so easy to explain.

It would run on one application but seti members want more.
Especially speed.
So you can blame Raistmer for trying to make most volunteers happy.
Maybe i am a bad tester, who knows.

But to make it clear only Raistmer or myself can answer this.

---

With each crime and every kindness we birth our future.

"There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question". ~ Carl Sagan, The Demon-Haunted World: Science as a Candle in the Dark.

Given....the only stupid question is the one not asked.
I stand down.

Meow.

---

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

Mere users don't really need to dive into the highly technical BOINC documentation to get an answer to their question.

Depends on questions and details they would like to have.Of course if answer is "because" no any details needed :)

It would run on one application but seti members want more.
Especially speed.

I think Jord's point is that the stock app should be universal without speed optimizations with the focus on simply just working stably. Then the Lunatics pack should contain all the speed improvements and various applications required to achieve the most speed possible.

I'm not so sure that all SETI members want more, though I'm sure many do. There are some people out there that simply want to contribute and are happier with stability and simplicity over speed. Those that want speed can follow the same advise we've given for the past 10 years: install optimized applications.

It would run on one application but seti members want more.
Especially speed.

I think Jord's point is that the stock app should be universal without speed optimizations with the focus on simply just working stably. Then the Lunatics pack should contain all the speed improvements and various applications required to achieve the most speed possible.

I'm not so sure that all SETI members want more, though I'm sure many do. There are some people out there that simply want to contribute and are happier with stability and simplicity over speed. Those that want speed can follow the same advise we've given for the past 10 years: install optimized applications.

I totally understand this point of view but that`s Raistmer`s and Eric`s decission and i support it.

We have a similar situation for cuda builds BTW.
cuda 23
cuda 32
cuda 42
cuda 50 as stock apps.

So far i know cuda 23 would also run on all devices but the servers decide which app is best for which host.

---

With each crime and every kindness we birth our future.

I totally understand this point of view but that`s Raistmer`s and Eric`s decission and i support it.

We have a similar situation for cuda builds BTW.
cuda 23
cuda 32
cuda 42
cuda 50 as stock apps.

So far i know cuda 23 would also run on all devices but the servers decide which app is best for which host.

Think I covered the CudaMB for comparison in a previous post in this thread. There are *some* complications, particularly with Cuda23, because back then Cuda binaries did not embed forward compatible PTX. The project not wanting to cut off working crunchers is another aspect, then throw in that Cuda3.2 breaks on Maxwell...

You get the gist, similar situations (just a different angle)

Eventually the Cuda applications (IIRC started before OpenCL was a thing) will end up fully heterogeneous, though priorities for now are certainly on minimising breakage, accumulating fast code and new techniques.

It's an easy thing to say 'needs to be simpler', and IMO quite right, though at the same time crafting such 'simple' applications has a lot of devils in the details. Something I'm sure Raistmer and Primegrid Developers know too well.

---

"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 totally understand this point of view but that`s Raistmer`s and Eric`s decission and i support it.

Sure, but minds can change, can't they? It usually starts with open and honest discussion.

We have a similar situation for cuda builds BTW.
cuda 23
cuda 32
cuda 42
cuda 50 as stock apps.

So far i know cuda 23 would also run on all devices but the servers decide which app is best for which host.

I'm not convinced that a valid argument is essentially "well the Green Team's applications are mess too!" It would almost seem that those offering such an argument are taking it personally and so are pointing fingers elsewhere.


I don't think the intent is to make this personal for the ATi/AMD developers and testers, but rather to make development, testing, and supporting easier. Jord mentioned that the OpenCL standard was supposed to simplify our lives with a single unified application, yet it seems everyone here at SETI (Green Team and Red Team) have chosen the opposite path - all with the mindset of getting the most optimized speed available.

I think the question really comes down to: Can we reconsider our path and can we simply this process?

I totally understand this point of view but that`s Raistmer`s and Eric`s decission and i support it.

We have a similar situation for cuda builds BTW.
cuda 23
cuda 32
cuda 42
cuda 50 as stock apps.

So far i know cuda 23 would also run on all devices but the servers decide which app is best for which host.

Think I covered the CudaMB for comparison in a previous post in this thread. There are *some* complications, particularly with Cuda23, because back then Cuda binaries did not embed forward compatible PTX. The project not wanting to cut off working crunchers is another aspect, then throw in that Cuda3.2 breaks on Maxwell...

You get the gist, similar situations (just a different angle)

Eventually the Cuda applications (IIRC started before OpenCL was a thing) will end up fully heterogeneous, though priorities for now are certainly on minimising breakage, accumulating fast code and new techniques.

It's an easy thing to say 'needs to be simpler', and IMO quite right, though at the same time crafting such 'simple' applications has a lot of devils in the details. Something I'm sure Raistmer and Primegrid Developers know too well.

I know Jason.

I just wanted to keep it as simple as possible.
Its more complicated with OpenCL apps too.

---

With each crime and every kindness we birth our future.

It would run on one application but seti members want more.
Especially speed.

I think Jord's point is that the stock app should be universal without speed optimizations with the focus on simply just working stably. Then the Lunatics pack should contain all the speed improvements and various applications required to achieve the most speed possible.

I'm not so sure that all SETI members want more, though I'm sure many do. There are some people out there that simply want to contribute and are happier with stability and simplicity over speed. Those that want speed can follow the same advise we've given for the past 10 years: install optimized applications.

Users who want simplicity just attach to project and go to own tasks and deeds. No matters 1 app, 10 app or few GB ow initial download as some projects have.
It's too curious ones who wonder. And then, when they got full descriptive answer they wonder why so complex??? Because!

I totally understand this point of view but that`s Raistmer`s and Eric`s decission and i support it.

Sure, but minds can change, can't they? It usually starts with open and honest discussion.

We have a similar situation for cuda builds BTW.
cuda 23
cuda 32
cuda 42
cuda 50 as stock apps.

So far i know cuda 23 would also run on all devices but the servers decide which app is best for which host.

I'm not convinced that a valid argument is essentially "well the Green Team's applications are mess too!" It would almost seem that those offering such an argument are taking it personally and so are pointing fingers elsewhere.


I don't think the intent is to make this personal for the ATi/AMD developers and testers, but rather to make development, testing, and supporting easier. Jord mentioned that the OpenCL standard was supposed to simplify our lives with a single unified application, yet it seems everyone here at SETI (Green Team and Red Team) have chosen the opposite path - all with the mindset of getting the most optimized speed available.

I think the question really comes down to: Can we reconsider our path and can we simply this process?

Under current cicumstances the answer is no so far i can tell.

We try to keep it as simple as possible.
OTOH the users don`t have to do anything except letting the apps run.
So what`s the real problem in this case ?

---

With each crime and every kindness we birth our future.

So what`s the real problem in this case ?

Quoting myself, this:

...None of the applications barring stock CPU have very sophisticated dispatch mechanisms as yet. That makes for some pretty costly maintenance of number of builds on each platform.

In the Cuda case, which for now still suffers this build creep, I *try* to limit to builds that make sense, knowing that number of builds costs focus, project resources, confusion, and introduces more points of failure, While in the Cuda case ongoing decreasing performance with newer Cuda versions and baseline code.

---

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

It's an easy thing to say 'needs to be simpler', and IMO quite right, though at the same time crafting such 'simple' applications has a lot of devils in the details. Something I'm sure Raistmer and Primegrid Developers know too well.

There's no doubt that it is easier said than done, and there's no doubt that it requires a lot of work and development. Hopefully you know that Jord and I and others are intelligent enough to understand this.

Understanding that there's been a large push to get applications and support for hardware out the door, but I suppose a re-phrasing of the question comes down to: Why wasn't there more focus on simplification and unification in the first place?

In the beginning, for CUDA applications it was as simple as selecting an app that corresponded with your CUDA version supported in hardware to get the most speed. Now on the ATi/AMD side of things, it's application for hardware support, app_info.xml files, command line .txt files.... you get the gist, right? It seems things are constantly going toward speed optimization and complicated setups that stability is gone.

Again, I understand that development of these applications isn't easy, but there's definitely a pattern of a problematic approach.

I don't think the intent is to make this personal for the ATi/AMD developers and testers, but rather to make development, testing, and supporting easier. Jord mentioned that the OpenCL standard was supposed to simplify our lives with a single unified application, yet it seems everyone here at SETI (Green Team and Red Team) have chosen the opposite path - all with the mindset of getting the most optimized speed available.

I think the question really comes down to: Can we reconsider our path and can we simply this process?

No. If one wants to simplify testing and supporting one can take part in both activities.

Under current cicumstances the answer is no so far i can tell.

That's an incredibly discouraging and off-putting response. I suppose if that's the way it is, then it is what it is. Though I must say that doesn't instill me with much confidence in the development teams.

We try to keep it as simple as possible.
OTOH the users don`t have to do anything except letting the apps run.
So what`s the real problem in this case ?

How many times have I seen you assisting ATi/AMD users with a specific problem to modify the command line .txt file or to use a specific driver version or both? Still think users don't have to do anything but let apps run?

It's an easy thing to say 'needs to be simpler', and IMO quite right, though at the same time crafting such 'simple' applications has a lot of devils in the details. Something I'm sure Raistmer and Primegrid Developers know too well.

There's no doubt that it is easier said than done, and there's no doubt that it requires a lot of work and development. Hopefully you know that Jord and I and others are intelligent enough to understand this.

Understanding that there's been a large push to get applications and support for hardware out the door, but I suppose a re-phrasing of the question comes down to: Why wasn't there more focus on simplification and unification in the first place?

In the beginning, for CUDA applications it was as simple as selecting an app that corresponded with your CUDA version supported in hardware to get the most speed. Now on the ATi/AMD side of things, it's application for hardware support, app_info.xml files, command line .txt files.... you get the gist, right? It seems things are constantly going toward speed optimization and complicated setups that stability is gone.

Again, I understand that development of these applications isn't easy, but there's definitely a pattern of a problematic approach.

Oh *I'm* quite clear that yourself and Jord have an excellent understanding of the issues in hand. Just have to present that I'm fully aware of the limitations with respect to my own work, such that it can't be used as excuses :)

---

"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 what`s the real problem in this case ?

As I already said, the real problem that some want to transfer tech-oriented forum in cafe filial.
Self-imposed issue that actually only in mind of asking.
If one cares about how it will scale to iPhone - iPhone will get just baseline app (though I doubt it ever happened). ATi users will get apps more suitable for particular hardware. Also this will allow to select what path most suitable and allow further improvements.

Under current cicumstances the answer is no so far i can tell.

That's an incredibly discouraging and off-putting response. I suppose if that's the way it is, then it is what it is. Though I must say that doesn't instill me with much confidence in the development teams.

We try to keep it as simple as possible.
OTOH the users don`t have to do anything except letting the apps run.
So what`s the real problem in this case ?

How many times have I seen you assisting ATi/AMD users with a specific problem to modify the command line .txt file or to use a specific driver version or both? Still think users don't have to do anything but let apps run?

That`s true but merly speed related.
Would you prefer i dont help ?

In the beginning, for CUDA applications it was as simple as selecting an app that corresponded with your CUDA version supported in hardware to get the most speed. Now on the ATi/AMD side of things, it's application for hardware support, app_info.xml files, command line .txt files.... you get the gist, right? It seems things are constantly going toward speed optimization and complicated setups that stability is gone.

Neither me nor Raistmer are happy with this situation but we are not responsible for driver issues etc.
We just try to make the best out of this.

---

With each crime and every kindness we birth our future.

I don't think the intent is to make this personal for the ATi/AMD developers and testers, but rather to make development, testing, and supporting easier. Jord mentioned that the OpenCL standard was supposed to simplify our lives with a single unified application, yet it seems everyone here at SETI (Green Team and Red Team) have chosen the opposite path - all with the mindset of getting the most optimized speed available.

I think the question really comes down to: Can we reconsider our path and can we simply this process?

No. If one wants to simplify testing and supporting one can take part in both activities.

Excellent. Since you're already part of development and testing, I take this as tacit acceptance of the challenge laid out before you.