Is it planned to run the routine to give credits to the units with Validate error?

thanks

It seem to run every day. No idea why it never shows on the summary page - that is annoying, I have to agree. It does show when you check each individual task though - an amount equal to the claimed credit.

---

Is it planned to run the routine to give credits to the units with Validate error?

thanks

It seem to run every day. No idea why it never shows on the summary page - that is annoying, I have to agree. It does show when you check each individual task though - an amount equal to the claimed credit.

For me it has not run in all the week, I have validate error wus with no credit as old as September 6. In total close to 300 wus.

Is it planned to run the routine to give credits to the units with Validate error?

thanks

If you check the task details, you will see the granted credit. For whatever reason, tasks given credit for errors do not show the granted credit on the task summary page.

I see now what you say, yes, the credit is granted in the task details page, so it is OK, weird that they do not show in the summary page.

thanks

We'll check with DK about this tomorrow!

I have had many of these units and because my runtime is 1 day I have lost 17 days of crunching and that's only those that remain in my list of WU's over 3 machines. I'm not in this for the credit but I would normally get well over 1000 credits for each day of prcessing so "300" is not good enough.

You are supposed to test when you change something, you didn't! It's little wonder that a lot of people sign up but don't stay long as a lot of "new" users to BOINC have "zero" tolerance to errors, they don't know what's going on and so abandon the project and you are always just left with the "hardcore" such as myself, who stick with you through "thick and thin" but you are trying my patience.

You don't write, you don't call, there is little information from you, yet you still expect us to crunch blindly, hopefully and obediently.

I often wonder how much belief there really is in BOINC and this and other projects. I think we are just a testbed and scientists have little confidence in BOINC and the public at large.

We're just a resource, that's what you think isn't it?

EDIT to add:

I think if this project and it's users were important to scientists we would not be waiting for optimizations in code to take advantage of extensions that have been around in CPU's for years if not decades such as SSE, SSE2, SSE3, SSE4 etc. Afterall these would reap you very generous rewards in computing power from existing users but you still haven't done it have you. It seems the idea of even using SSE has just crept int your consciousness.

Now if Rosetta, its users and its results were as important as you often say they are surely you would have done these things, in fact it beggars belief that you haven't and still maintain we and our results are of any importance.

*sigh* I wish there was a way to down-vote a post, Betting Slip certainly does not represent any of my views. David, Sergey, and countless others who take time out of their day to visit these forums and even collaborate directly with some of us - you guys all do a fantastic job!

I know from my day job how challenging software development is - add bioinformatics onto that and wow.. Bioinformatics is hard, some of it is even NP-hard (wow a pun).

Keep calm and crunch on! XD

I would just point out that the Rosetta development community is comprised of bioinformatics and physics researchers that are focused on accuracy of prediction, and less focused on development methodologies, hardware technologies, state-of-the-art practices etc. This exemplifies why cross-discipline collaboration is so important in the research community.

The research paper each is working on at the time will be no better with better compiler options or etc. So, I would take the recent pursuit of such improvements as being above-and-beyond their scope and mission, and am encouraged to be seeing it.

---

Rosetta Moderator: Mod.Sense

The research paper each is working on at the time will be no better with better compiler options or etc.

??
With better compiler options you have faster app, so more science in less time

---

The research paper each is working on at the time will be no better with better compiler options or etc. So, I would take the recent pursuit of such improvements as being above-and-beyond their scope and mission, and am encouraged to be seeing it.

What you are saying is that if Rosetta were "faster" more "efficient" increasing throughput of WU's would have no effect on each individual scientists work.

How can the improvement of their own project be "above-and-beyond their scope and mission"?

My post was about more than an improvement to compiler options but you obviously didn't understand or chose to ignore.

Is it planned to run the routine to give credits to the units with Validate error?

thanks

If you check the task details, you will see the granted credit. For whatever reason, tasks given credit for errors do not show the granted credit on the task summary page.

I see now what you say, yes, the credit is granted in the task details page, so it is OK, weird that they do not show in the summary page.

thanks

Weird... and a little annoying... but certainly confusing, which results in unneccessary complaints, like we're seeing <sigh>

---

I'm not in this for the credit but I would normally get well over 1000 credits for each day of processing so "300" is not good enough.

I was going to say this is wrong, but I've just checked and it's right. What <I've> been saying is wrong - though in my defence I'd never seen it before.

Where I've been saying granted credit is given equal to claimed credit, the day-long tasks Betting Slip has that are coming up with a Validation Error are claiming over 500 or over 800 but granting only a flat 300.

This certainly shouldn't be happening.

---

@Betting Slip

I am just trying to point out that the (very pertinent and valid) issues you are raising is sort of similar to asking the automotive engineer to resolve the issue with the odor the production cars have in the seat cushions or a flaw with the specific tires that are used. It is just not how they spend the majority of their time. They are more focused on the MPG, aerodynamics, and other aspects. Such runtime variations increase the complexity of the code they are constantly trying to rework in ways to produce better protein models. So there are also some valid reasons for keeping the codebase as simple as possible.

So, I'm not trying to say such issues should not be pursued, just that it is going to be a paradigm shift and likely require some skills development, and the community of developers involved is not all directly under the control of any one person. What the community contributes, comes as it comes.

I'll also take this opp. to point out that I am not on the Project Team, simply a volunteer cruncher, with one person's perspective.

---

Rosetta Moderator: Mod.Sense

This is probably getting off-topic now, but to pre-empt a response and summarise as per my understanding, I think the point from the other threads here and on Ralph, are:

It is generally(?) accepted/understood that code overhauls which would be required for parallel execution like GPGPU, are not practical given the nature of the code, the fact that it is continually evolving, and the development time required for that (assuming it were viable/useful).

The suggestion to make use of modern compiler options to make use of modern CPU extensions for free, is the alternative which requires no code changes, but does require some dev time to a) implement it, b) test it and c) fix it when it inevitably results in something unexpected.

Visual Studio 2015 is out now, which I think was one of the issues for testing AVX2 on the code (from here: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=6645)

Regardless of any of the above though, it is completely unfair for anyone to suggest what the project team should be doing with their time, given that none of us outside the lab have any idea what priorities will produce the best/quickest scientific results.

---

So, I'm not trying to say such issues should not be pursued, just that it is going to be a paradigm shift and likely require some skills development, and the community of developers involved is not all directly under the control of any one person. What the community contributes, comes as it comes.

I don't quite get it. We already had a 64-Bit version with SSEwhatever enabled and a significant speedup.

Has this app yielded false results or were there just ancients CPUs choking on SSE?

So, I'm not trying to say such issues should not be pursued, just that it is going to be a paradigm shift and likely require some skills development, and the community of developers involved is not all directly under the control of any one person. What the community contributes, comes as it comes.

I don't quite get it. We already had a 64-Bit version with SSEwhatever enabled and a significant speedup.

Has this app yielded false results or were there just ancients CPUs choking on SSE

I would be interested in the number of 32-bit hosts and number of ACTIVE 32-bit hosts. I suspect it is low but I would not be too surprised if it was significant. If the work of 32-bit hosts was below the percentage of improvement seen by a 64-bit optimization, then it might make sense to release only a 64-bit version .... if the decision was made to forego the 32-bit hosts. I thought the improvement was near 20% (from memory).


Compiling with any 64-bit option will cause the compiler to generate code that uses the SSE2 (or newer) instructions BUT!!! Rosetta code is compiling into SCALAR (one FP operation per instruction) code and not VECTOR (multiple FP operations per instruction) code. That means there would be little, if any, performance gain from AVX, AVX2, AVXn, ... Rosetta code will still just crunch one number at a time. IMO, it is not worth the "illegal opcode" errors that will result. If the Rosetta@Home team is incapable of generating a simple 64-bit -O -mSSE2 version, then building anything more complex is beyond their skill level.

It is pretty easy to break VECTOR code so the compiler is forced to generate SCALAR code again. With all the people making Rosetta changes, it would be really tough to clean up the coding problems to keep the compiled binary parallel.

There is some comfort in just having the Rosetta code consistently "work". I just put Rosetta on 10% resource setting and devote just a fraction of a host to them. It helps cool off my CPU from running the modern projects.

So, I'm not trying to say such issues should not be pursued, just that it is going to be a paradigm shift and likely require some skills development, and the community of developers involved is not all directly under the control of any one person. What the community contributes, comes as it comes.

I don't quite get it. We already had a 64-Bit version with SSEwhatever enabled and a significant speedup.

Has this app yielded false results or were there just ancients CPUs choking on SSE

I would be interested in the number of 32-bit hosts and number of ACTIVE 32-bit hosts. I suspect it is low but I would not be too surprised if it was significant. If the work of 32-bit hosts was below the percentage of improvement seen by a 64-bit optimization, then it might make sense to release only a 64-bit version .... if the decision was made to forego the 32-bit hosts. I thought the improvement was near 20% (from memory).


Compiling with any 64-bit option will cause the compiler to generate code that uses the SSE2 (or newer) instructions BUT!!! Rosetta code is compiling into SCALAR (one FP operation per instruction) code and not VECTOR (multiple FP operations per instruction) code. That means there would be little, if any, performance gain from AVX, AVX2, AVXn, ... Rosetta code will still just crunch one number at a time. IMO, it is not worth the "illegal opcode" errors that will result. If the Rosetta@Home team is incapable of generating a simple 64-bit -O -mSSE2 version, then building anything more complex is beyond their skill level.

It is pretty easy to break VECTOR code so the compiler is forced to generate SCALAR code again. With all the people making Rosetta changes, it would be really tough to clean up the coding problems to keep the compiled binary parallel.

There is some comfort in just having the Rosetta code consistently "work". I just put Rosetta on 10% resource setting and devote just a fraction of a host to them. It helps cool off my CPU from running the modern projects.

The Rosetta code works really well at what it is intended to do; one of the best, if not, the best tertiary protein structure predictor out there. It isn't optimized to squeeze everything out of modern CPUs unfortunately.

---

I too have a computer that has lots of validate errors . it does more work units and gets fewer points than my other system.

I would be interested in the number of 32-bit hosts and number of ACTIVE 32-bit hosts. I suspect it is low but I would not be too surprised if it was significant. If the work of 32-bit hosts was below the percentage of improvement seen by a 64-bit optimization, then it might make sense to release only a 64-bit version .... if the decision was made to forego the 32-bit hosts. I thought the improvement was near 20% (from memory).

In firsts 1000 top hosts no 32 bit OS.
So, a simple 10% more for these rac monsters outclasses all the 32 bit power.

---

In firsts 1000 top hosts no 32 bit OS.

On the first few pages this might be right, although it's hard to tell what all those Linux machines are. Anyway, there are still many powerfull machines using 32-bit OS, example host 1651904, currently with a RAC of almost 5000 on rank 250, ist using Windows 7 x86. That's not really slow.

So, a simple 10% more for these rac monsters outclasses all the 32 bit power.

You might want to explain how exactly you get this number.

---

.

In firsts 1000 top hosts no 32 bit OS.

On the first few pages this might be right, although it's hard to tell what all those Linux machines are. Anyway, there are still many powerfull machines using 32-bit OS, example host 1651904, currently with a RAC of almost 5000 on rank 250, ist using Windows 7 x86. That's not really slow.

No way. That's one craptastic CPU. No way. Decimal points?!