Page 5 of 5

Re: DAB & transparicy

Posted: Sun Nov 25, 2012 2:22 pm
by 7im
In some areas, FAH is an early adopter. It was the first DC project with a GPU client. And the first DC project with a true SMP client. First to have a PS3 client.

Re: DAB & transparency

Posted: Sun Nov 25, 2012 2:59 pm
by Punchy
7im wrote:In some areas, FAH is an early adopter. It was the first DC project with a GPU client. And the first DC project with a true SMP client. First to have a PS3 client.
Replace "areas" with "decades" and I'd agree. It seems that other DC projects are now adopting new technology much more rapidly. AVX is a good example.

Back to the thread topic...

Re: DAB & transparicy

Posted: Sun Nov 25, 2012 7:36 pm
by NookieBandit
JimF, Punchy,

I should clarify Point #2 in my original post that may have left you with an incorrect conclusion regarding the development environments, drivers, and other dependencies in order for F@H to advance. I'm not suggesting that PG be omniscient with respect to all the software development environments being used in tangential distributed computing projects. Specifically, PG must be aware of the dependencies that exist in the development tools, drivers and manufacturer support that limit the progress a given version of F@H can achieve. Without this information, they would have no basis whatsoever for developing a code release. To be as clear, I'm not asking for any new information only communication of information PG already has at their disposal when they make decisions about where to branch the project, including features, decrements, and bug fixes that are dependent on the advancement of underlying supporting code from other sources.

Once these specific dependencies related to F@H are exposed to the donor community, donors can then use that information to determine purchase decisions if they care to use it. Indeed, those decisions may very well be at the margin, but nevertheless it is information that factors into the calculus of any given individual donor's decision process.

In addition to the above, I'm certain that once communicated, this information could be used to rally the donor community to support PG in areas beyond "slots and watts". Recruiting the donor community to lobby the major hardware manufacturers to dedicate support to F@H functionality within their drivers and development tools to enable PG to issue code releases on a more consistent basis would be an excellent derivative of having a public F@H dependency list. Taking this further, imagine the influence strength PG would have on all other hardware manufacturers after just one event where this donor community banded together on the behalf of PG to get a manufacturer to definitively adopt F@H support as an on-going critical function set in their product lines. PG has the opportunity to wield a very large stick if they chose to exercise that power. However, they have to first put in place the mechanism to organize the donor community. In an almost surreal state of convenience, the information they already have in-hand, published to this community, is all it takes.

I'm not asking for PG to do any additional work on this topic other than to pluck an unpaid grad student (marketing major?) from a very large pool of candidates and assign them the product management responsibility of communicating to the donor community the status of information PG already has at hand. I've got to believe a job posting inside Stanford for this postion would be filled almost instantly, and probably could be filled as an internship position. While the argument of "lack of resources" may be valid, there are usually many ways around those limitations with enough creative thinking. And as well all know, creative thinking is certainly not lacking in an institution like PG or Stanford.

Re: DAB & transparency

Posted: Mon Nov 26, 2012 6:02 pm
by JimF
Yes, graduate students are a great resource that a university has available. But that touches on another resource that is not widely appreciated: Folding has enough work to do. That self-evident point is not always true for other projects. At the moment (I won't name names), several of the BOINC projects are very overloaded with users, especially those with AMD cards that don't have too many other places to go. Either the servers for those projects, or the scientists (or both) can't keep up. But PG never (thus far in my experience) has had that problem. They have enough talented researchers, both at Stanford and related institutions, to keep feeding them enough interesting projects to do. And it must be good work, based on the publications and notice they are getting in the scientific community. But organizational skill is the third leg (in addition to science and technology) that PG brings to the table. If they need additional input on that, it is fine with me, but I think they are in the best position to decide that. I can't tell them what proteins to work on either.

Re: DAB & transparency

Posted: Mon Nov 26, 2012 9:59 pm
by mdk777
If they need additional input on that, it is fine with me, but I think they are in the best position to decide that.
The Null hypothesis is self evident.