Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

It is to the 11th place, so I believe they are fine. But let Travis say for sure.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

@ Travis

Why linux, OSX, and Win stock apps gave different results with the same wu?

Best regards.

At what level of accuracy?

Didn't you tested it...? Bad boy...:)

Try it, and give us your results.

Best regards.

With what we tested them on they were basically identical. I was wondering if someone was getting different results.

---

So, we have a new version of the SSE3 app that meets the 10 digit requirement. Does anyone have an updated SSE or SSE2 version?

Here we go...

http://rapidshare.com/files/184217251/astronomy_sse2_app.rar.html

Original app:
fitness: -3.046272445362277

this one:
fitness: -3.046272445362278

have fun...

LB

Thanks that helps me out.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

too slow....

I don t think so.
This is what Travis wrote:
Yeah that's fine. I think the cutoff where it would start to matter would be differences greater than 10^-10ish

So the last five digits are not necessary,i think...
There are only the last four incorrect...

Correct me,if i am wrong...

LB

Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

It is to the 11th place, so I believe they are fine. But let Travis say for sure.

Yeah this is fine. It would be nice to see how it does with a couple different inputs, just to make sure. Is this optimized app done with compiler flags or has there been significant code changes? If the 2nd is the case it would be nice if they were shared so we could update the stock app.

---

Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

It is to the 11th place, so I believe they are fine. But let Travis say for sure.

Yeah this is fine. It would be nice to see how it does with a couple different inputs, just to make sure. Is this optimized app done with compiler flags or has there been significant code changes? If the 2nd is the case it would be nice if they were shared so we could update the stock app.

---

Gonna try re-attaching with one SSE3 box. If I end up losing points I will shut it back down.

Gonna try re-attaching with one SSE3 box. If I end up losing points I will shut it back down.

I've been running with the latest SSE3 app all day without problems. The WUs are taking slightly (minimally) longer, but it's still turning WUs around far faster than the stock app.

---

Yeah this is fine. It would be nice to see how it does with a couple different inputs, just to make sure. Is this optimized app done with compiler flags or has there been significant code changes? If the 2nd is the case it would be nice if they were shared so we could update the stock app.

Im not shure but i think they "hand-optimzed" the code rather using compiler flags, dont know whtat is significant for you ;) . but better to ask them directly.

So I guess this SSE3-Version saves the party for us.

Result of the Test-WU:
fitness: -3.046272445362275

Yes, I also got
fitness: -3.046272445362275

But that still does not match the stock app output of
fitness: -3.046272445362277

Are they close enough it won't change the outcome (of the search) or should they be exact?

Yeah that's fine. I think the cutoff where it would start to matter would be differences greater than 10^-10ish

The app linked above is the only one I know of that is good. The last post above (the "Yeah that's fine" one) is from Travis.

I just install this new app on one of my hosts , and the finish complete time go to 195s from 22mn ....

That a a HUGE improvement !!!

Gonna try re-attaching with one SSE3 box. If I end up losing points I will shut it back down.

I've been running with the latest SSE3 app all day without problems. The WUs are taking slightly (minimally) longer, but it's still turning WUs around far faster than the stock app.

Pentium D working fine, just attached P-4 HT, waiting for first results to come in.

YIPPIE SKIPPIE!!!!!

Cant wait to see what one of the Quad-cores will do........

Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

Would be interesting to know if the app still suffers from the memleak that was 'build in' to the stock app and what's more important, if it still cuts off significant numbers when restated form a checkpoint like the stock app does (which of course makes the result invalid )

---

Join Support science! Joinc Team BOINC United now!

Pentium D & P-4 HT are validating. Quad core AMD Phenom now attached.

Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

Would be interesting to know if the app still suffers from the memleak that was 'build in' to the stock app and what's more important, if it still cuts off significant numbers when restated form a checkpoint like the stock app does (which of course makes the result invalid )

I'm pretty sure the newest versions of the stock app checkpoint to 20 digits past the decimal point so that isn't happening anymore.

*edit* And honestly, if there are bugs in the application that you know about, please post them to the code discussion forum. If you make a post about them there (instead of random snarky comments in random threads), it would actually be helpful to us so we can update the application and get rid of them.

---

Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

Would be interesting to know if the app still suffers from the memleak that was 'build in' to the stock app and what's more important, if it still cuts off significant numbers when restated form a checkpoint like the stock app does (which of course makes the result invalid )

At least my SSE3-App I linked to in this thread does not suffer from any of these shortcomings ;)

Heres what I got for the SSEv2 zip

Optimized
fitness: -3.046272445362275

Stock
fitness: -3.046272445361065


So are these results too different?

Would be interesting to know if the app still suffers from the memleak that was 'build in' to the stock app and what's more important, if it still cuts off significant numbers when restated form a checkpoint like the stock app does (which of course makes the result invalid )

At least my SSE3-App I linked to in this thread does not suffer from any of these shortcomings ;)

I for one am grateful for you making this available Cluster Physik.

I've already added it to www.arizmoon.com which I will be updating now with what I think are the 'correct' SSE2 and SSE apps.

---

I'm pretty sure the newest versions of the stock app checkpoint to 20 digits past the decimal point so that isn't happening anymore.

*edit* And honestly, if there are bugs in the application that you know about, please post them to the code discussion forum. If you make a post about them there (instead of random snarky comments in random threads), it would actually be helpful to us so we can update the application and get rid of them.

A silent update? I just checked it and the code version on the server is still from December 3rd which saves only 6 decimal places (not even the significant ones!) in the checkpoints and exhibits the memory leak, Crunch3r mentioned (some whopping 170MB!).

Concerning the memory leak, it shows up when calling calculate_probabilities from calculate_likelyhood, if I remember correctly.
Btw., you should output the values not with "%.nf" (with n the number of decimal places after the point), but better as "%.ng", as this preserves the significant digits in the shortest printable form.

At least my SSE3-App I linked to in this thread does not suffer from any of these shortcomings ;)

I for one am grateful for you making this available Cluster Physik.

I've already added it to www.arizmoon.com which I will be updating now with what I think are the 'correct' SSE2 and SSE apps.

OK, I've updated www.arizmoon.com with what has been agreed in this thread as usable optimized apps for SSE, SSE2 and SSE3.

Please let me know if I'm wrong, thanks.

---

I'm pretty sure the newest versions of the stock app checkpoint to 20 digits past the decimal point so that isn't happening anymore.

*edit* And honestly, if there are bugs in the application that you know about, please post them to the code discussion forum. If you make a post about them there (instead of random snarky comments in random threads), it would actually be helpful to us so we can update the application and get rid of them.

A silent update? I just checked it and the code version on the server is still from December 3rd which saves only 6 decimal places (not even the significant ones!) in the checkpoints and exhibits the memory leak, Crunch3r mentioned (some whopping 170MB!).

Concerning the memory leak, it shows up when calling calculate_probabilities from calculate_likelyhood, if I remember correctly.
Btw., you should output the values not with "%.nf" (with n the number of decimal places after the point), but better as "%.ng", as this preserves the significant digits in the shortest printable form.

I just looked at the code and i see the problem. The stock app should be updated by the end of the day.

---