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?

And your point here? To illustrate how far we from one size fits all? Yes indeed we are very far from that. Part of answer on thread title? no?

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

Thank you so much, sir. You truly are a gentleman and a scholar.

And as one of the users of your hard work, I just want to let you know that I appreciate you and all the developers efforts. As do a lot of people who may not visit this thread. Just wanted you guys to hear it. Thank You. Very much.

---

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 ?

No, not at all sir. Once again, I think this is heading down a personal path and that's not the intent. I'm glad you help out as much as you do. I'm simply trying to show you that there is indeed a problem. BTW - I've seen your advice apply to problematic driver crashes (stability) and not just speed related.

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.

Understood, and again this isn't meant to be personal attacks against either you or Raistmer. I do hope that maybe there's some approach in development that was missed... maybe a different mindset approach to development... I don't know. I'm not a coder, I'm just a script-writer. Just thinking out loud here.

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

And you had any doubts that to make optimized software instead of "just working" is challenging? Hm :) Yes, it's a challenge. And very few times when I asked some of "advisers" to implement their "advise" I got any code in return.
Yep, it's challenging, it's the art. And almost always it can be done better then it done already. So what? Do better, be part of the team - all just benefit from that.

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?

And your point here? To illustrate how far we from one size fits all? Yes indeed we are very far from that. Part of answer on thread title? no?

Well yes, that is the topic at hand. Glad you can point out I'm on topic. Now, what to do about it? I'm sure I already know your answer though.

Why wasn't there more focus on simplification and unification in the first place?

Because I want to maximize project throughput. And unification+simplification though reduce my time spent on the project will result just in opposite.
Taking to the limit, most easy and simply way to do work... just doesn't do it at all. Use stock CPU app only, for example.
And unification w/o simplification actually will require much more efforts.

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 ?

No, not at all sir. Once again, I think this is heading down a personal path and that's not the intent. I'm glad you help out as much as you do. I'm simply trying to show you that there is indeed a problem. BTW - I've seen your advice apply to problematic driver crashes (stability) and not just speed related.

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.

Understood, and again this isn't meant to be personal attacks against either you or Raistmer. I do hope that maybe there's some approach in development that was missed... maybe a different mindset approach to development... I don't know. I'm not a coder, I'm just a script-writer. Just thinking out loud here.

I don`t take it personal at all.
Please consider that i had not much experience with FFT kermels when i started some years ago.
So some bugs kept undiscovered and i tried to fix this afterwards as good as possible.
I take it as it is my fault.
Also keep in mind that we have real jobs too and its not always easy to remain fully motivated.
We are humans too.

But i can assure you that we are trying our best.

---

With each crime and every kindness we birth our future.

Well yes, that is the topic at hand. Glad you can point out I'm on topic. Now, what to do about it? I'm sure I already know your answer though.

I know answer of course - to continue optimization efforts. And to ignore such threads to save time, perhaps? But I don't like to tolerate wrong rumors.

Though I must say that doesn't instill me with much confidence in the development teams.

Instead of religious questions here no confidence needed for things to work. They work because of testing and coding and debugging, not because someone confident or not in them :D

Part of the difficulty here is that what appears to the user as a simple 'set and forget' application can often be a much more complicated application to develop.

Just consider a modern operating system like Windows. Why does it have to contain quite so many gigabytes of code, just to run your computer? The answer is - because it has to run everybody else's computer as well. Different hardware, different drivers, different applications to support, different configurations requested by users, different .....

To make all of that work requires something akin to artificial intelligence - and that's bloody hard to develop. Does anybody know how many person-years of code writing has gone into windows so far? No, me neither - but it'll be a lot.

Here, for GPUs running under Windows, we have two people. Both volunteers, both with a living to earn away from BOINC. Those two volunteers have to provide both the stock applications and the optimised applications, because there's nobody at Berkeley with the time or the skillset required to write GPU application code.

Both our volunteers started as optimisers. Their applications have been circulated as stock apps too, simply to fill the vacuum: without the optimised apps being re-purposed, there would be no stock GPU computing at all.

Having said that, I too would prefer to see a simplification - with more of the tuning and tweaking transferred to the sort of unified dispatch mechanism that Jason has been talking about. But he's been trying to achieve that for several years now: every time he gets close, another part of the world spins around his head. What are we talking about on this board at the moment? Geforce 10x0 hardware, CUDA 8.0, SETI v9, Astropulse for GBT? And the same on the AMD side. Everyone wants their squeaky wheel oiled first, while professionalism demands "without breaking any of the old stuff".

I sympathise with the guys being pulled in every direction at once, and I understand if they sometimes pluck the low-hanging fruit in order to retain some job satisfaction in their work. But as I said, I too would prefer it if the direction of travel veered towards "maintenance free" apps that didn't need all those command line switches.

Yes, it's a challenge. And very few times when I asked some of "advisers" to implement their "advise" I got any code in return.

Not everyone knows how to code, but that doesn't make their advise/suggestion/question unimportant if they can't also follow-up with code to help.

Or to try to put it another way: I know software development teams that have Project Managers and Team Leads without a lick of coding experience, but they know how to take feedback and give it to the coders to guide the development along so that the end result is a better application instead of ignoring the feedback and having code written by engineers only, and therefore the resulting application and process only understood by engineers.

Yes, politically speaking those software engineers hate their Project Managers and Team Leads, and often think they're clueless... but the truth is, those positions serve their purpose whether a software coder wants to admit it or not.

Why wasn't there more focus on simplification and unification in the first place?

Because I want to maximize project throughput. And unification+simplification though reduce my time spent on the project will result just in opposite.
Taking to the limit, most easy and simply way to do work... just doesn't do it at all. Use stock CPU app only, for example.
And unification w/o simplification actually will require much more efforts.

So there you go. This is the answer to the thread. You've focused all your efforts on speed ("maximize project throughput"), and you don't want to simplify because it would result in a slower application.

Yes, unification without simplification would result in more effort in the short term, but long term you would be able to review the 'simplified' code and find areas which could benefit from improvement. This is the way the CPU apps and optimizations originally started out.

Also keep in mind that we have real jobs too and its not always easy to remain fully motivated.
We are humans too.

I understand this all-too-well too. My own volunteer efforts for the project have taken a back seat due to my own personal life, and motivation can be quite difficult at best when things aren't good on the home front.

But i can assure you that we are trying our best.

Respectfully, I truly think that you are, but when someone asks questions as to why development is focused on speed instead of simplicity and compatibility; such as why there has to be 5 different stock applications for AMD, and what can be done to make a single stock application instead... then we get told "no, it isn't going to happen", then we get told that the Lead Developer refuses because he wants to code for speed on each hardware platform instead of unification, thus answering the question on why there's 5 different stock applications... I don't want to say that you aren't trying your best, but I do want to give feedback that it seems like efforts aren't focused in the right area, In My Humble Opinion. Hopefully you understand where I'm coming from on this?

But as I said, I too would prefer it if the direction of travel veered towards "maintenance free" apps that didn't need all those command line switches.

Fully understood on all the rest of your post, and thank you for speaking up. But this closing statement is quite simply what I've been trying to say. I'm well aware of the history on why we even have ATi/AMD applications here at SETI, and it is thanks to Raistmer and Mike. But from Raistmer's own admittance, he doesn't care about maintenance free applications, he only wants fast applications, and such speed needs to be coded for each hardware platform and specific driver versions, which leads us to the mess we're in right now.

So how do we convince Raistmer to change his coding priorities without threads like this? If he loves optimizing for speed, he should be encouraged to do so in the optimized application releases for Lunatics, but stock applications should take a different approach.

Though I must say that doesn't instill me with much confidence in the development teams.

Instead of religious questions here no confidence needed for things to work. They work because of testing and coding and debugging, not because someone confident or not in them :D

If you think the questions are religious in nature, then you don't understand what is trying to be communicated to you. I'm just not sure if you purposefully ignore the attempts to change your mind, or if you really just don't see other points of view.

In context, my comment about confidence isn't so much about functionality of the applications, or even the ability of the development team to write code. The comment about confidence in the development team is an attempt to convey the obvious close-minded nature of the developer responding with an absolute "No, it isn't going to happen!" instead of listening to feedback.

stock applications should take a different approach.

That rather requires that we have a stock development team, separate and distinct from the optimisation development team. But that depends on funding, and I've just said all I dare to on that subject in an adjacent thread.

stock applications should take a different approach.

That rather requires that we have a stock development team, separate and distinct from the optimisation development team. But that depends on funding, and I've just said all I dare to on that subject in an adjacent thread.

Respectfully, while that is a nice dream line-item to have separate development teams, I don't think it needs to be exclusively true. I see no reason why those coding for optimization can't start with universal development in mind, then work toward optimizations in the existing code later.

Why wasn't there more focus on simplification and unification in the first place?

Because I want to maximize project throughput. And unification+simplification though reduce my time spent on the project will result just in opposite.
Taking to the limit, most easy and simply way to do work... just doesn't do it at all. Use stock CPU app only, for example.
And unification w/o simplification actually will require much more efforts.

So there you go. This is the answer to the thread. You've focused all your efforts on speed ("maximize project throughput"), and you don't want to simplify because it would result in a slower application.

Yes, unification without simplification would result in more effort in the short term, but long term you would be able to review the 'simplified' code and find areas which could benefit from improvement. This is the way the CPU apps and optimizations originally started out.

So far i`m concerned there are a few things we should keep in mind.

First of all the app has to work and produce valid results.
Since we started at Lunatics with optimized apps they should be fast too.

Of course some people have other wishes but that`s up to the programmer even if that`s possible and worth spending hours of coding and testing.

I want to add that wording is not one of my pros.
I more focused on technical stuff, not to forget that english is not my native language.
So please be fair and don`t use gold scales here.

---

With each crime and every kindness we birth our future.

So far i`m concerned there are a few things we should keep in mind.

First of all the app has to work and produce valid results.
Since we started at Lunatics with optimized apps they should be fast too.

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.

Since the SETI Project Scientists are unable to keep up with the changing landscape in software development, and since many of the optimized code have made their way back into the main branch of code, I would think it would be best to focus efforts on that compatibility and stability the project was known for.

Of course some people have other wishes but that`s up to the programmer even if that`s possible and worth spending hours of coding and testing.

Of course it is up to the programmer, but hopefully that person or individuals are open to feedback and a change of mind. As it is, as things become more complex, the troubleshooting part is getting out of hand. I would think it is in everyone's interest to make testing and support easier even if that means less speed in the application.

I want to add that wording is not one of my pros.
I more focused on technical stuff, not to forget that english is not my native language.
So please be fair and don`t use gold scales here.

I think you're doing fine with your English, sir. Thank you for taking part in this discussion. I don't think communication is necessarily our problem, I think it is merely trying to change hearts and minds in regards to development, and it is far harder to change minds than anything else.

For whatever it's worth, thanks to Raistmer's efforts that we even have an ATi/AMD application here at SETI, and I would imagine he could certainly use more help on the coding front. I really with I know how to code so I could help out.