Welcome to MilkyWay@home

credit comparison to other projects

Message boards : Number crunching : credit comparison to other projects
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 . . . 15 · Next

AuthorMessage
Profile GalaxyIce
Avatar

Send message
Joined: 6 Apr 08
Posts: 2018
Credit: 100,142,856
RAC: 0
Message 7279 - Posted: 2 Dec 2008, 21:21:33 UTC - in response to Message 7277.  


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


ID: 7279 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
JAMC

Send message
Joined: 9 Sep 08
Posts: 96
Credit: 336,443,946
RAC: 0
Message 7280 - Posted: 2 Dec 2008, 21:33:41 UTC

FYI- I am getting ~54 credits/hour with an XP Home quad with SETI optimized vs 48cr/hr with MW
ID: 7280 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile banditwolf
Avatar

Send message
Joined: 12 Nov 07
Posts: 2425
Credit: 524,164
RAC: 0
Message 7281 - Posted: 2 Dec 2008, 21:39:48 UTC - in response to Message 7272.  


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.
ID: 7281 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile GalaxyIce
Avatar

Send message
Joined: 6 Apr 08
Posts: 2018
Credit: 100,142,856
RAC: 0
Message 7282 - Posted: 2 Dec 2008, 21:49:31 UTC - in response to Message 7280.  

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.


ID: 7282 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Stevea

Send message
Joined: 14 Jul 08
Posts: 50
Credit: 8,398,033
RAC: 0
Message 7286 - Posted: 2 Dec 2008, 22:49:38 UTC - in response to Message 7280.  
Last modified: 2 Dec 2008, 22:50:22 UTC

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.
ID: 7286 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile banditwolf
Avatar

Send message
Joined: 12 Nov 07
Posts: 2425
Credit: 524,164
RAC: 0
Message 7288 - Posted: 2 Dec 2008, 22:53:57 UTC - in response to Message 7286.  

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.
ID: 7288 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Travis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
Message 7290 - Posted: 2 Dec 2008, 23:44:14 UTC - in response to Message 7288.  

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.
ID: 7290 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
John Clark

Send message
Joined: 4 Oct 08
Posts: 1734
Credit: 64,228,409
RAC: 0
Message 7293 - Posted: 3 Dec 2008, 0:25:40 UTC - in response to Message 7290.  

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.
ID: 7293 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Annika Kremer

Send message
Joined: 30 Oct 08
Posts: 32
Credit: 60,528
RAC: 0
Message 7294 - Posted: 3 Dec 2008, 0:45:52 UTC
Last modified: 3 Dec 2008, 1:12:59 UTC

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.
ID: 7294 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile speedimic
Avatar

Send message
Joined: 22 Feb 08
Posts: 260
Credit: 57,387,048
RAC: 0
Message 7295 - Posted: 3 Dec 2008, 0:47:21 UTC - in response to Message 7267.  


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.


ID: 7295 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Travis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
Message 7296 - Posted: 3 Dec 2008, 0:48:03 UTC - in response to Message 7293.  

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.
ID: 7296 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Silvers

Send message
Joined: 21 Aug 08
Posts: 625
Credit: 558,425
RAC: 0
Message 7301 - Posted: 3 Dec 2008, 1:21:46 UTC - in response to Message 7295.  


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...
ID: 7301 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Silvers

Send message
Joined: 21 Aug 08
Posts: 625
Credit: 558,425
RAC: 0
Message 7302 - Posted: 3 Dec 2008, 1:50:07 UTC - in response to Message 7296.  


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"...
ID: 7302 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile speedimic
Avatar

Send message
Joined: 22 Feb 08
Posts: 260
Credit: 57,387,048
RAC: 0
Message 7303 - Posted: 3 Dec 2008, 2:14:05 UTC - in response to Message 7301.  

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.


ID: 7303 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile banditwolf
Avatar

Send message
Joined: 12 Nov 07
Posts: 2425
Credit: 524,164
RAC: 0
Message 7309 - Posted: 3 Dec 2008, 3:20:54 UTC

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.
ID: 7309 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Travis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
Message 7310 - Posted: 3 Dec 2008, 4:06:24 UTC - in response to Message 7309.  

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.
ID: 7310 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Travis
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 30 Aug 07
Posts: 2046
Credit: 26,480
RAC: 0
Message 7311 - Posted: 3 Dec 2008, 4:10:30 UTC - in response to Message 7302.  


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
ID: 7311 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Milksop at try

Send message
Joined: 1 Oct 08
Posts: 106
Credit: 24,162,445
RAC: 0
Message 7312 - Posted: 3 Dec 2008, 4:20:13 UTC - in response to Message 7296.  

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 ;)
ID: 7312 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Arion
Avatar

Send message
Joined: 10 Aug 08
Posts: 218
Credit: 41,846,854
RAC: 0
Message 7313 - Posted: 3 Dec 2008, 4:45:03 UTC

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,



ID: 7313 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Brian Silvers

Send message
Joined: 21 Aug 08
Posts: 625
Credit: 558,425
RAC: 0
Message 7314 - Posted: 3 Dec 2008, 4:50:31 UTC - in response to Message 7303.  


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...
ID: 7314 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 . . . 15 · Next

Message boards : Number crunching : credit comparison to other projects

©2024 Astroinformatics Group