iirc as mentioned above somewhere, they needed to have it all recoded in a modern language (C of some type) to make it effective as the old bodged together fortran/c code was restricting things. I assume this is what mini-rosetta is and it'll be tested there..

But what no developers, the project coders chiming in to talk about it .... :(

---

Team mauisun.org

But what no developers, the project coders chiming in to talk about it .... :(

Would you rather they were here spending time... or coding?

I'd pick coding ... :)

But that is just me ...

---

@Paul D. Buck - From one of my other postings...

Can you really have your cake and eat it too? :-0

How can the Project justify expending programming resources for this, under the criteria you have advocated in your various posts in this thread?

And if they can do that, then why can't they spend 15 mins / week here?

For example, how was this possible?

"When David Baker, who also serves as a principal investigator for Howard Hughes Medical Institute, originally developed the code, it had to be run in serial - broken into manageable amounts of data, with each portion calculated in series, one after another.

Through a research collaboration, SDSC's expertise and supercomputing resources helped modify the Rosetta code to run in parallel on SDSC's massive supercomputers, dramatically speeding processing, and providing a testing ground for running the code on the world's fastest non-classified computer.

@Paul D. Buck - From one of my other postings...

Can you really have your cake and eat it too? :-0

How can the Project justify expending programming resources for this, under the criteria you have advocated in your various posts in this thread?

And if they can do that, then why can't they spend 15 mins / week here?

For example, how was this possible?

"When David Baker, who also serves as a principal investigator for Howard Hughes Medical Institute, originally developed the code, it had to be run in serial - broken into manageable amounts of data, with each portion calculated in series, one after another.

Through a research collaboration, SDSC's expertise and supercomputing resources helped modify the Rosetta code to run in parallel on SDSC's massive supercomputers, dramatically speeding processing, and providing a testing ground for running the code on the world's fastest non-classified computer.

Different person ...

Different problem ...

And I did not say I did not want project participation on the boards, as a matter of record I was one of the first, if not the first to point out that RAH, which in the initial stages, was one of the best projects for having project participation on the boards ... would lose that interest within 6 months ... I was off by 2 months ... their presence waned in 4 months ...

I have been one of the few, if not the only, person in the participant community that has tried to interest the projects in mobilizing and using their participants into a usable tool rather than a "passive" herd of cows in their farm of computers ...

But, I was labeled loony for even suggesting that there is such a thing as a BOINC Community ... yet, there is, and we and the projects all belong to it ... A rather lawless place as my recent metaphor goes in that the projects can, and do, act like the old western gunfighters and we, the cowed and subservient townspeople ...

The fact that some, if not most, of the gunslingers are benign does not make them any less what they are ... and you cannot always tell by looking ... look at a picture of "Billy the Kid" and he does not look the part either ...

---

@Paul D. Buck: I was orignially referring to Post 52339.

I think we are basically on the same page as far as community and communication, and I respect your background.

We can respectfully disagree as to where the "break-even" point is, in regards to making an effort to evaluate the potential impact of new technology on the Project.

We can respectfully disagree as to where the "break-even" point is, in regards to making an effort to evaluate the potential impact of new technology on the Project.

Agreed... :)

One of the hardest concepts I tried to "sell" was the thought that we can disagree with out being disagreeable. At the moment, I think we are still above the threshold (at least I HOPE I have not dipped below... I know no one has offended me ...)

I was only trying to make the point that I want the coders coding and testing. Not so much talking to me.

Historically, the spokespersons for the projects have tended to be the moderators and (at least in the past) volunteers like myself and others who tried to read EVERYTHING so we could answer questions.

In this case, particularly when there is (apparently) a new version in the wings is not the right time to be thinking about specific CPU optimization efforts. I have tended to be a little "shorter" in that I find I am tiring faster so ... perhaps welcome relief to those that never cared for my, ahem, longwindedness.

Anyway. Optimizations have their place, it is just, unfortunately not as simple as we would like ...

Just as an example, the brevety of an SQL statement is by no means an indication that the query will execute quickly (one i worked on was 4:20 and some seconds 4.5 plus million rows to pull two). Nor that one that fills two pages of 11x14 paper will be slow (15 ms) ...

Anyway, *MY* main intent was to attempt to fill-in the background so that the "why not" might be a little easier to understand ... because ... it seems so simple ... :)

---

"Version 1.15 of minirosetta is now released, which includes protocols for doing very fast optimization of multiple starting structures, improved methods for modeling protein structures based on constraints, and faster versions of our all-atom refinement protocol."

Seems like this new version does have some of the optimizations that have been mentioned here (not SSE, but better algorhythms).

---

Intel's upcoming AVX instructions go back to the future

This past IDF, Intel announced its next major X86 instruction set facelift - the Advanced Vector Extensions, or AVX. What's the big deal, you may ask? After all, there were countless MMX and SSE rounds till this day.

Well, it is a nice 3-operand, RISC-like approach, so you can finally do A+B=C in a single opcode: AMD's proposed SSE5 is supposed to go along this line as well. Later, with fused multiply-adds, this could even become A*B+C=D. Then, you got a more efficient instruction format with a lot of baggage (and length) reduced - again, one of major problems of X86 on efficient fixed-opcode length RISCs. No need to mention the good ship Itanic here, it can have more instruction FORMATS than some RISCs have instructions - that's how 'elegant' it is.

Then, AVX doubles the SSE register length to 256 bits - doubling the amount of data fitting in and, matched with doubled data paths, providing twice the FP throughput per clock in the Sandy Bridge CPU some two years from now. And, one day maybe, you could fit two quad-precision 128-bit FP numbers into each of these registers. Marvellous!

AVX it is Geat,
but it will be in use, in 1.5 - 2 year when "4x core CPU with AVX" will cost 200-300$
and "CPU with AVX" will demands new MBRAM ((

---

is that enough advanced notice for the progrgammers to have an optimized Rosie app ready ?!

is that enough advanced notice for the progrgammers to have an optimized Rosie app ready ?!

I've just hopped onto this thread, and flicked through it quickly. Seems like there's a catch-22 going on. Developers won't spend huge amounts of time optimising Code for the latest CPUs if there are many takers. But there won't be many takers until the Code yields significant performance benefits.

My personal view is that Project Developers (not just R@H) should keep on top of the current state-of-play. At the end of the day, we are using our PCs (and electricity bills) to support their research, so they should do their utmost to keep us interested and onboard their Project. Using a Marketing tool such as "optimised for SSE4 etc", would keep us going!!!

Neil.

---

is that enough advanced notice for the progrgammers to have an optimized Rosie app ready ?!

I've just hopped onto this thread, and flicked through it quickly. Seems like there's a catch-22 going on. Developers won't spend huge amounts of time optimising Code for the latest CPUs if there are many takers. But there won't be many takers until the Code yields significant performance benefits.

My personal view is that Project Developers (not just R@H) should keep on top of the current state-of-play. At the end of the day, we are using our PCs (and electricity bills) to support their research, so they should do their utmost to keep us interested and onboard their Project. Using a Marketing tool such as "optimised for SSE4 etc", would keep us going!!!

Neil.

Unfortunately, the point is that the code isn't static and therefore 'optimisation' isn't a one-time job. It would possibly need to be re-done (at least in-part) after every new Rosetta release.

The guys at the lab wouldn't need to be involved with optimisation of the app anyway though - it could be (and has been) attempted by others. I'd suggest the reason no-one has been successful is because it's not a trivial job.

The final point is that it might be very well optimised already - maybe SSE4 would help, but maybe it wouldn't. I think the general consensus was that SSE1-3 wouldn't have helped.

---