I would also like to add that this is a "production" project ...not an alpha or a beta.... They ought to be open to such queries on open source code unless copyrighted in the case of LHC six-track or CPDN... As SETI has done.... Einstein,Rosetta,or Predictor should allow open source-code to advance thier projects if possibble...my 2 cents

This was discussed a few months ago on these forums. So far the decision has been NOT to release the code. In terms of complexity there is no comparison between projects like SETI and Einstein. While CPND is as complex, it has been around for a long time, well before BOINC, and the goals of the processing are somewhat more ethereal, than Rosetta.

While it is possible that releasing the code MIGHT produce some speed improvements, that is by no means certain. It is even more likely that the open source code would produce inaccurate results, and even more problems than the project based release.

"Might" and unknown... Based on Seti's results more likely more advance but I appreciate the projects stance and will produce for other projects that are "open" and can "reward" me for my advanced library thank-you" until an "open" mind-source can be reached...and a couple months ago? Don't you think this issue ever needs to be re-addressed? A "couple" of months ago this project was Beta.I mean come on this seems a "closed" minded attitude for a project that professes itself to be open to ideas...I submit you will lose crunchers based on this attitude.And "complexity" sounds like a sorry excuse to keep it closed as others have "enlightened" projects on where they can improve.Moderator...you are losing me as a contributer based on your post...I would like to hear from admin before I make my final judgement.I have asked Einstein these questions and got at least much better answers.

---

[
As a personal note, you are of course entitled to your opinion, but some temperance in your expression of it might be in order.
[/color][/b]

Sorry Moderator9 if I offended you by my post.You should be able to address the issue not skirt it.I find it most profficient in Boinc message boards to say what I mean and mean what I say as I am passionate in my beleifs( kinda like religion) hehe and get better RESULTS(response) this way.(People DO listen if you are susccint enough)And sorry that"barely out of Beta" is not a valid excuse to me....something else would be proffered as an answer as "PRODUCTION" means I believe that ALL the startup issues have been addressed....but you seem to wish to change that meaning by your inference.And the link you posted was last posted to Dec 28th.... again we should never again address this til admin says
to? I mean you act like this problem/question has been addressed...Don't bother me.....And open-source code would alleviate a lot of questions from those who might crunch for Rosetta if the results can be shared/released/duplicated by others.

---

Rosetta is written in standard C++ which we have spent a huge amount of time trying to optimize. when compiling for the different architectures, we use the highest level of optimization available.

I do beleive you are somewhat wrong about this Dr.Dave ...all do respect intended...ie: I get rewarded in Seti with being able to use sse3....not on a standard app but an OPTIMIZED app..... the app runs significatny faster than a sse2 app on same machine...now are you telling me that when your app recognizes I am using sse3 it will automatically optimize to that compared to lets say my mmx library? I haven't seen evidence of this...so optimization is allowing the faster computers to go even faster and you have not done this yet from what I can tell....

You must differ between the different "optimized app" at setiathome.
There are optimized apps compiled with other compiler flags. They mostly are about 5 to 15 faster, depending on the optimisations (SSEx, 32/64 bit, compiler flags,...).
The other type of optimized apps have a modified source code. They get there performance from reducing the precisions for the calculations, and with add some caching and other functions to the sources.

---

Maybe this cruncher that can be of help ?

http://einstein.phys.uwm.edu/show_user.php?userid=121407

He is doing wonders with einstein cod.

Anders n

---

Maybe this cruncher that can be of help ?

http://einstein.phys.uwm.edu/show_user.php?userid=121407

He is doing wonders with einstein cod.

Anders n

I followed the link(s) to find that dude. They talk funny on that forum. I think they are all yankees, or something like that. Can't understand a word they say....

But, his RAC is pretty awesome - his 1700+ is outperforming my Opteron 1800 AS WELL AS the wife's 3400 AMD64. Awesome. Hope he's got his app optimized accurately.....

---

I followed the link(s) to find that dude. They talk funny on that forum. I think they are all yankees, or something like that. Can't understand a word they say....

But, his RAC is pretty awesome - his 1700+ is outperforming my Opteron 1800 AS WELL AS the wife's 3400 AMD64. Awesome. Hope he's got his app optimized accurately.....

I think he is from Hungary :)

Anders n

---

I followed the link(s) to find that dude. They talk funny on that forum. I think they are all yankees, or something like that. Can't understand a word they say....

But, his RAC is pretty awesome - his 1700+ is outperforming my Opteron 1800 AS WELL AS the wife's 3400 AMD64. Awesome. Hope he's got his app optimized accurately.....

Indeed Akosf has, Bruce Allen has included some of his code in to the base application and is adding hardware to handle the load when he implements most of the rest.

Bruce has also made some specific request of Akosf, who has been glad to help.

Akosf output files are flagged as his, so the project knows if there is a problem with them (although with Akosf, he usually shows the projects where they made their mistake). The results are at least as accurate as the standard results. Akosf uses less L1 cache (about 16K), which sped the client up enormously. He's swapped around arrays so they fill and empty more quickly.

Quite frankly, when I started with computers in 1972, I used punch cards to program. I've met a number of IT geniuses before and must say, Akosf seems to fit the profile well.

Find out for yourselves, go run Einstein for a while and use the fora to keep track of the optimised applications.

---

Click here to join the #1 Aussie Alliance on Rosetta

Einstein have actually used Akosf's code in ther new client release.

He definately knows what he is doing, I'am using his SSE2 optimized client and producing work 5 times faster. WU's now only take an hour on an AMD64 3500+ WinXP

It would be nice to see some collaboration with Rosetta and Akosf

---

Rosetta is written in standard C++ which we have spent a huge amount of time trying to optimize. when compiling for the different architectures, we use the highest level of optimization available.

I do beleive you are somewhat wrong about this Dr.Dave ...all do respect intended...ie: I get rewarded in Seti with being able to use sse3....not on a standard app but an OPTIMIZED app..... the app runs significatny faster than a sse2 app on same machine...now are you telling me that when your app recognizes I am using sse3 it will automatically optimize to that compared to lets say my mmx library? I haven't seen evidence of this...so optimization is allowing the faster computers to go even faster and you have not done this yet from what I can tell....

Some other food for thought for you.

AFAIK, SETI spends the bulk of it's time doing FFT calculations. The algorithms for this are extremely well understood, and hence amenable to "human" optimization. In addition, this makes it incredibly easy to tweak for a specific architecture (SSE2 / SSE3 / Altivec / whatever ) to maximize performance.

Meanwhile, the Rosetta algorithm itself is in a state of change today, because at this time we're testing different algorithms to see which one works the best. Therefore hand optimization of anything at this early stage might actually be counter productive. It'd be far better to spend six months to a year to lock down the best algorithm, and then optimize it.

"Premature optimization is one of the worst mistakes you can make in software engineering" -- Anon

"First make it work. Then make it work fast." -- Bob Buckley - U. Warwick, 1980

---