slower CPU = more credit?

Gerry Rough
Gerry Rough
Joined: 1 Mar 05
Posts: 102
Credit: 1,847,066
RAC: 0
Topic 190788

I've been watching my credit lately pretty closely, and I'm puzzled with what is a pattern. Often my 1.6 gig pent. M outperforms my 3.2 gig P4 in credits per day/week. Is there really a tear appering in the space-time continuum or am I just being a dufuss?

Gerry Rough


(Click for detailed stats)

J D K
J D K
Joined: 27 Aug 05
Posts: 86
Credit: 103,878
RAC: 0

slower CPU = more credit?

The faster you process the fewer points you get per WU....

Pooh Bear 27
Pooh Bear 27
Joined: 20 Mar 05
Posts: 1,376
Credit: 20,312,671
RAC: 0

The PM is a better processor

The PM is a better processor for crunching, because of the larger L2 Cache. Plus the speed actually equates differently than the P4. So a 1.6 PM runs about the speed of a 3.2+ P4 in crunching speed.

Do some research on the chips.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,156
Credit: 7,179,394,931
RAC: 769,857

RE: I've been watching my

Quote:

I've been watching my credit lately pretty closely, and I'm puzzled with what is a pattern. Often my 1.6 gig pent. M outperforms my 3.2 gig P4 in credits per day/week. Is there really a tear appering in the space-time continuum or am I just being a dufuss?

Gerry Rough


With the 3-result quorum on Albert, plus the preference for issue of new results to your computer which use the same 7 Megabyte large data file already downloaded, your quorum buddies are very poorly randomized over the short term. I'm not talking about the multi-week settling time of the RAC computation, which is a separate issue.

If you start processing a a large datafile which happens to have a few low-claiming high processing capacity folks, they can push your score down for a weeks, and vice versa. I've seen this on my own small and motley fleet. Two old machines which have closely comparable processors differing by about 15% in real compute capability had Einstein cobblestone production differing by almost a factor of two for weeks because of luck of the work-unit draw.

I also have a 1.4 GHz Pentium M and a 3.2 GHz large-cache P4 (the 2Megabyte cache flavor). My P4 slaughters my M, getting over double the Einstein RAC as adjusted for resource share as compared to the M. I do run hyperthreaded nearly all the time. I also run a bit of SETI. So long as I keep the resource share below about 15%, nearly all the P4 SETI runs opposite an Einstein@home job, which gives startlingly low SETI execution times (about CPU 45 minutes for a nominal result). The M's one thread gives SETI nominal WU times of about 57 minutes, so is well under half as SETI-productive in this case, rising to almost two-thirds as productive in an all-SETI scenario) A small-cache P4 won't do nearly so well as mine on HT SETI, but the more extreme claims for P4 deficiency in numeric computing are ill-founded. Its power consumption, on the other hand, is justly maligned.

Also, my impression is that Einstein@home is not so abruptly sensitive to cache sizes in the .25 to 2 Megabyte/process range as is SETI@home. If you are not running HT, you may wish to try it.

Gerry Rough
Gerry Rough
Joined: 1 Mar 05
Posts: 102
Credit: 1,847,066
RAC: 0

RE: RE: I've been

Message 25260 in response to message 25259

Quote:
Quote:

I've been watching my credit lately pretty closely, and I'm puzzled with what is a pattern. Often my 1.6 gig pent. M outperforms my 3.2 gig P4 in credits per day/week. Is there really a tear appering in the space-time continuum or am I just being a dufuss?

Gerry Rough


With the 3-result quorum on Albert, plus the preference for issue of new results to your computer which use the same 7 Megabyte large data file already downloaded, your quorum buddies are very poorly randomized over the short term. I'm not talking about the multi-week settling time of the RAC computation, which is a separate issue.

If you start processing a a large datafile which happens to have a few low-claiming high processing capacity folks, they can push your score down for a weeks, and vice versa. I've seen this on my own small and motley fleet. Two old machines which have closely comparable processors differing by about 15% in real compute capability had Einstein cobblestone production differing by almost a factor of two for weeks because of luck of the work-unit draw.

I also have a 1.4 GHz Pentium M and a 3.2 GHz large-cache P4 (the 2Megabyte cache flavor). My P4 slaughters my M, getting over double the Einstein RAC as adjusted for resource share as compared to the M. I do run hyperthreaded nearly all the time. I also run a bit of SETI. So long as I keep the resource share below about 15%, nearly all the P4 SETI runs opposite an Einstein@home job, which gives startlingly low SETI execution times (about CPU 45 minutes for a nominal result). The M's one thread gives SETI nominal WU times of about 57 minutes, so is well under half as SETI-productive in this case, rising to almost two-thirds as productive in an all-SETI scenario) A small-cache P4 won't do nearly so well as mine on HT SETI, but the more extreme claims for P4 deficiency in numeric computing are ill-founded. Its power consumption, on the other hand, is justly maligned.

Also, my impression is that Einstein@home is not so abruptly sensitive to cache sizes in the .25 to 2 Megabyte/process range as is SETI@home. If you are not running HT, you may wish to try it.

Thanks much for the advice, but I have to admit I'm somewhat skeptical. How much gain can I get out of HT as opposed to running single thread? I think I remember this issue being hashed about awhile back with jsut 5-10% more with HT. That's okay, I suppose, but not great. I will change my preferences and see what hapopens over the next couple of weeks or so. Thanks again.

Gerry Rough


(Click for detailed stats)

Michael Roycraft
Michael Roycraft
Joined: 10 Mar 05
Posts: 846
Credit: 157,718
RAC: 0

RE: Thanks much for the

Message 25261 in response to message 25260

Quote:

Thanks much for the advice, but I have to admit I'm somewhat skeptical. How much gain can I get out of HT as opposed to running single thread? I think I remember this issue being hashed about awhile back with jsut 5-10% more with HT. That's okay, I suppose, but not great. I will change my preferences and see what hapopens over the next couple of weeks or so. Thanks again.

Gerry Rough

Gerry,

I remember reading that the HT comes out about 1.2 x more throughput than single-thread, little bit less when both "cores" are running the same project, little bit more on dissimilar work.

Michael

microcraft
"The arc of history is long, but it bends toward justice" - MLK

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.