Ummm, so that means.... errrr....

What so sort of candy are we talking about? ;P

The sort that some people will say is delicious, some will say sucks rhino, some will say rots our teeth, some will say causes hyperactivity......

Yes, but am I getting enough credits for my crunch? :P

---

FYI- I am getting ~54 credits/hour with an XP Home quad with SETI optimized vs 48cr/hr with MW

Ummm, so that means.... errrr....

What so sort of candy are we talking about? ;P

Well...not the sugar-free stuff!

---

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

FYI- I am getting ~54 credits/hour with an XP Home quad with SETI optimized vs 48cr/hr with MW

Well, I think MilkyWay@home ought to get more credits to attract more crunchers for carrying out useful research into the evolution of the Milkyway galaxy.

It sounds like a fine project to me deserving heaps of support.

---

FYI- I am getting ~54 credits/hour with an XP Home quad with SETI optimized vs 48cr/hr with MW

So this is with the app optimized for Intel CPU's, Amd's are going to take a bigger hit than that....

If this is an Optimizes App, the the Credit should be more in line with Seti's Opto app.

If not what is the point in Seti having a Standard app to test the cph against other Projects only to allow an Opto app to receive much higher credit?

If this is an optimized app the credits should be more in line with Seti's opto.

And again AMD's are going to take a bigger hit than the Intel's without and AMD specific compiler.

This could go on and on.... Is it Optimized or not? If so that should set the standard against Seti's Opto.

Is it Optimized or not?

This is the standard app for now. There is no current optimized app released yet.

---

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

Is it Optimized or not?

This is the standard app for now. There is no current optimized app released yet.

The application as it is right now has all of the optimization's that were suggested to us by milksop, and a couple of my own. If people find ways to improve the performance further we'll implement them if they're suggested in the forums.

---

Is it Optimized or not?

This is the standard app for now. There is no current optimized app released yet.

The application as it is right now has all of the optimization's that were suggested to us by milksop, and a couple of my own. If people find ways to improve the performance further we'll implement them if they're suggested in the forums.

Travis

What you say is true in that the coding for the current MW stock client V0.6 has optimised the standard code.

However, optimsed code in the SETI sense, and to a lesser extent with Einstein, is code is specifically optimised to a CPU's extensions. The code is optimised to use the CPU extensions like - MMX, SSE, SSE2, SSE3, SSSE3x and/or SSE4.1.

Your code is not optimised code in that SETI/Einstein sense.

It is code reworked to be more efficient than that found in the original stock MW client.

My credits on a Core2Quad Q9400 @ 2.66GHz (not overclocked) under 64-bit-Linux, all projects with the vanilla app, all values are per core:

Einstein@Home: ~26 creds/h
Enigma@Home: ~28 creds/h (varies a bit since they still give benchmark-based cred)
MalariaControl: ~22 creds/h
MilkyWay@home: ~23 creds/h

No SETI, I'm afraid, but maybe this still helps.

Unfortunately, this doesn't seem like a very easy problem (or else someone would have come up with a good solution by now). So in light of that, we'd like to keep or credit in line with other projects. If it's too low we'll raise it, if it's too high we'll lower it.

Again, therein lies the rub. As I demonstrated, for Labbie's Q9450, SETI offers higher credit potential than here. However, if you look at speedimic's 2.8GHz Xeon and then drill down into the SETI and MW project stats for that specific system, you'll discover the following:

SETI - Average credit per CPU second 0.003885
MW@H - Average credit per CPU second 0.014103

So, from two different users, you have two completely different perspectives.

As you said, it isn't an "easy problem" to solve. The problem is getting project admins to understand that moving credits up and down isn't a real solution because it causes just as much "unfairness" as it purports to solve...

Brian, did you do your calculations over everything that this box crunched?
99% of the MW credits were gained with milksop's app - the recent MW optimized 0.4/6 yields roundabout 0.0055.
For SAH it might be right, I calculate 0.0032 to 0.0053 depending on AR.

Xeon 2.8 @ SAH
Xeon 2.8 @ MW

---

mic.

Is it Optimized or not?

This is the standard app for now. There is no current optimized app released yet.

The application as it is right now has all of the optimization's that were suggested to us by milksop, and a couple of my own. If people find ways to improve the performance further we'll implement them if they're suggested in the forums.

Travis

What you say is true in that the coding for the current MW stock client V0.6 has optimised the standard code.

However, optimsed code in the SETI sense, and to a lesser extent with Einstein, is code is specifically optimised to a CPU's extensions. The code is optimised to use the CPU extensions like - MMX, SSE, SSE2, SSE3, SSSE3x and/or SSE4.1.

Your code is not optimised code in that SETI/Einstein sense.

It is code reworked to be more efficient than that found in the original stock MW client.

Actually, we've compiled milkyway with architecture specific flags that have been suggested to us in the code discussion forum. In our case, sse2 was said to be the best performance improvement, so we've used that on architectures that support it.

I'm sure there's some more changes in the code that could make the app more efficient and i'm looking forward to what people come up with. Once I have the rest of the server-side stuff working the way I like it i'll probably take a deeper look myself.

However, I'm sure if people use architecture specific code optimizations, such as hand-coded vectorizations and things of that nature, even more performance could be squeezed out of the app -- I'm not sure if we'll be able to put those in the stock app since they're more specific than different compiler flags.

---

Brian, did you do your calculations over everything that this box crunched?
99% of the MW credits were gained with milksop's app - the recent MW optimized 0.4/6 yields roundabout 0.0055.
For SAH it might be right, I calculate 0.0032 to 0.0053 depending on AR.

Xeon 2.8 @ SAH
Xeon 2.8 @ MW

I didn't do any calculations, I just went on the CPCS reported by the projects' stat exports that is shown at the stat sites. However, you're right, that system here hadn't decayed enough yet to be a useful comparison. Despite that, based on what you have pointed out it's still true that from your system's perspective, MW is the "better paying" project, while from Labbie's system it is the other way around. Lowering for you brings "parity", while it brings even further "disparity" for Labbie's system...

Actually, we've compiled milkyway with architecture specific flags that have been suggested to us in the code discussion forum. In our case, sse2 was said to be the best performance improvement, so we've used that on architectures that support it.

If you are using Intel compilers, you need to be very careful in your selection of options. axw will have a different build from axn, which in turn has different builds from just xw and xn, with the latter pair being for Intel only. Additionally you may experience issues with MSVC++ (.net) in getting into some performance penalties for AMD systems depending on which version of the compiler you use. From what was experienced at Einstein, a good indicator is to hexedit the binary and look for the string "AuthenticAMD". That string is not in your binary, FWIW... Don't know what was used to compile with either...

As for the optimized app at SETI, my SSE3-capable Athlon64 was happiest with the SSE2 version with the axw option...

However, bear in mind those options are actually not done in the stock SETI app to the best of my knowledge... As someone pointed out, if you start bringing in all these options and vectorization and hotspot/hotloop improvements, you need to try to target credit towards the optimized app at SETI and not the stock app, else you devalue the effort you've put into it and make it to where the SETI optimized apps look extremely attractive to "competitive crunchers"...

I didn't do any calculations, I just went on the CPCS reported by the projects' stat exports that is shown at the stat sites. However, you're right, that system here hadn't decayed enough yet to be a useful comparison. Despite that, based on what you have pointed out it's still true that from your system's perspective, MW is the "better paying" project, while from Labbie's system it is the other way around. Lowering for you brings "parity", while it brings even further "disparity" for Labbie's system...

Right, those old rigs are a slightly favoured at MW, but they only play a side-role in the crunching game.

Looking at Labbie's Q9450 or my Q9550, SAH Optimized and MW optimized are quite even - enough parity for me.

SAH stock users might want lower credits for MW (as optimized is now stock), but that's a discussion for Saenger...

---

mic.

Are the wu's geting semi fixed credit? My completed vary by ~15 min and yet I get 39.84 for most of them. So that lowers my credit hour down to ~22.

---

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

Are the wu's geting semi fixed credit? My completed vary by ~15 min and yet I get 39.84 for most of them. So that lowers my credit hour down to ~22.

WUs have always been on fixed credit. nm_stripe86 does more work than nm_stripe79 and nm_stripe82, but it awards more credit based on the extra work. You should be getting more credit for the longer WUs.

---

Actually, we've compiled milkyway with architecture specific flags that have been suggested to us in the code discussion forum. In our case, sse2 was said to be the best performance improvement, so we've used that on architectures that support it.

If you are using Intel compilers, you need to be very careful in your selection of options. axw will have a different build from axn, which in turn has different builds from just xw and xn, with the latter pair being for Intel only. Additionally you may experience issues with MSVC++ (.net) in getting into some performance penalties for AMD systems depending on which version of the compiler you use. From what was experienced at Einstein, a good indicator is to hexedit the binary and look for the string "AuthenticAMD". That string is not in your binary, FWIW... Don't know what was used to compile with either...

As for the optimized app at SETI, my SSE3-capable Athlon64 was happiest with the SSE2 version with the axw option...

However, bear in mind those options are actually not done in the stock SETI app to the best of my knowledge... As someone pointed out, if you start bringing in all these options and vectorization and hotspot/hotloop improvements, you need to try to target credit towards the optimized app at SETI and not the stock app, else you devalue the effort you've put into it and make it to where the SETI optimized apps look extremely attractive to "competitive crunchers"...

Might want to take this to the code discussion, but we've been using the following for linux:
i686: -O2 -ftree-vectorize -funroll-loops
x86_64: -O2 -msse2 -ftree-vectorize -funroll-loops

and the following for osx:

ppc: -O2 -maltivec -mabi=altivec -mcpu=7400 -funroll-loops
i686: -O2 -msse2 -mfpmath=sse -mtune=prescott -ftree-vectorize -funroll-loops
x86_64: -O2 -mfpmath=sse -mtune=nocona -msse2 -ftree-vectorize -funroll-loops

If you have some better suggestions for us, heres the spot: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=488

---

The application as it is right now has all of the optimization's that were suggested to us by milksop, and a couple of my own. If people find ways to improve the performance further we'll implement them if they're suggested in the forums.

Travis

What you say is true in that the coding for the current MW stock client V0.6 has optimised the standard code.

However, optimsed code in the SETI sense, and to a lesser extent with Einstein, is code is specifically optimised to a CPU's extensions. The code is optimised to use the CPU extensions like - MMX, SSE, SSE2, SSE3, SSSE3x and/or SSE4.1.

Your code is not optimised code in that SETI/Einstein sense.

Actually, we've compiled milkyway with architecture specific flags that have been suggested to us in the code discussion forum. In our case, sse2 was said to be the best performance improvement, so we've used that on architectures that support it.

I'm sure there's some more changes in the code that could make the app more efficient and i'm looking forward to what people come up with. Once I have the rest of the server-side stuff working the way I like it i'll probably take a deeper look myself.

However, I'm sure if people use architecture specific code optimizations, such as hand-coded vectorizations and things of that nature, even more performance could be squeezed out of the app -- I'm not sure if we'll be able to put those in the stock app since they're more specific than different compiler flags.

Yes, that's right. Hand coded vectorizations normally buy you a factor of two or so. This is of course an average number. Sometimes it's more, sometimes less. But these kind of low level optimizations you can leave to the hands of the gifted ones like Crunch3r. Often it is too specific to implement into the standard app if you don't create such switcher apps like employed over at Einstein.

As I said, I didn't have time to look at the new code yet. Nevertheless, I think there are still some high level optimizations left. Maybe I will find some time to look into it. But as you have now released the code very transparently (not somehow hidden like before), I guess there are more capable guys out there to say something about this. Either way, I and my team are very pleased that the efficiency of the computations at this project have been grossly improved. I will be happy to lose my first place at this project, soon ;)

This very unscientific but here is a comparison that I did on 1 computer that is working 50/50 on Einstein and MW. System is AMD 64 6400+ (3.2GHz) Stock running Vista Ultimate 32 bit with 4 gigs of RAM. Using MW .06 client and Einstein's lastest beta optimized client .07 <--- SSE2

I pulled a continuous run of workunits from both projects as there are highs and lows and wanted an average over time.

I pulled 63,764.33 seconds - 1062.74 minutes of continuous work from MW. I added up all the credits for the units for this spread and received 1158.04 credits. So, 1158.04/1062.74 = 1.09 credits per minute.

I pulled 63,763.67 seconds - 1062.73 minutes of continuous work from Einstein. I received 444.86 credits for these workunits So, 444.86/1062.73 = .42 credits per minute.

How this relates to seti's stock app or optimized client is anyone's guess since I don't do anything for seti. For all that matter I don't really kow what it means here except that in the same amount of time using Milksap's app I was getting aprox. 2000+ credits for MW on the same system.

About the best I can come up with is that if MW was giving too much credit before to the point that DA paid us a visit and MW has cut their credits in 1/2 he shouldn't have anything to complain about. I make less credits than this on both of my other projects and I am willing to process at those for the science. I do the same thing here.


There are projects that give less credit as well as those that give more than this. I think that over all it is the individual projects responsiblility to come up with a formula that works for them. In the interest of cross project parity if they choose to award credits somewhere reasonably close to what other projects are awarding I think it works. There are too many variables to have everyone on every project being awarded the same credits. As was stated numerous times its hard enough even having intra-project parity much less inter-project parity.

If anyone sees a flaw in my calculations let me know. I was just trying to come up with a reasonably sane method. 1 roll of calculator paper later this was the best I could come up with. I realise that these figures may or may not represent a norm with others here,

---

Looking at Labbie's Q9450 or my Q9550, SAH Optimized and MW optimized are quite even - enough parity for me.

There are two 9450 systems. One is clocked at 3GHz, the other at 3.36... I was looking specifically at the 3.36...