CUDALucas versus Mfaktc/o

[chalsall]

Originally Posted by Dubslow

Keep in mind that those who are doing mfakt* are doing so a very little impact to what their LL throughput was before. I have four cores; nominally all four do LL. Currently, one of them does mfaktc, which (usually) finds a factor every couple of days; that eliminates exponents much more quickly than using the core for LL. I realize that we can't factor everything, but I'm using my GPU at relatively little cost to my LL throughput. mfakt* hurts CUADLucas throughput, yes, but I would argue that even if we all ran CUDALucas instead of mfakt*, the total increase in LL throughput would be very very slight, and I'd make a wager that our impact would be less than 1% overall. Clearly mfakt* has a much bigger impact of TF and eliminating exponents.

If I may throw in my two cents worth in... In reference to the GPU to 72 Overall System Progress report...

Even though the conversion coefficient for GPU days to "Normalized GHz Days" continues to be debated, I think it is clear that at the LL "wave-back" GPUs are still better utilized doing TF than LL in the current range and "bit" level at this point in time. This may no longer be the case at the DC "wave-back".

And I can tell you with some authority that those taking true DC and LL work from the system are mostly using CPUs to do the work.

I think we're actually arguing somewhat in a vacuum. As in, we all have our opinions, but we're (mostly) not working from hard data.

I am going to add to the G72 system the ability for individual workers to enter empirical data for their individual systems (CPUs and GPUs) for hardware ability and "wall-clock" times for the various work types and methodologies. With enough data, we should be in a better position to determine exactly where the cost/benefit curves cross.

But I would argue strongly against changing the fundamental GHzDays metric already in use by Prime95 and PrimeNet. After all, a modern CPU can do orders of magnitude more work per day than (for example) an old Pentium. Should the P1 receive the same credit as a modern CPU?

Or, should the same CPU receive different GHzDays credit for the same "wall-clock time" for different work types? Doing so would simply distort the "economic signals" as to what work type had the most benefit.

[lycorn]

Originally Posted by chalsall

But I would argue strongly against changing the fundamental GHzDays metric already in use by Prime95 and PrimeNet. After all, a modern CPU can do orders of magnitude more work per day than (for example) an old Pentium. Should the P1 receive the same credit as a modern CPU?

Or, should the same CPU receive different GHzDays credit for the same "wall-clock time" for different work types? Doing so would simply distort the "economic signals" as to what work type had the most benefit.

I fully agree. The point is we need a meaningful unit of measure to allow us to quantify the amount of work done. For that matter, GHz-days is as good a reference as MHz-weeks or GHz-months could be.
If a modern CPU can test say 2 exponents in 10 days, whereas an old one can test just one, that means the modern CPU has to receive twice the credit for the same "wall clock" time of work. And this, regardless of the improvement being due to an increase in clock frequency, or in cache size, or to other architectural enhancements, or the use of new instructions not available in the old CPU. Same goes with GPUs: if a GPU can trial factor numbers 100x faster than a CPU, it obviously has to get 100 times more credit after they both have been working on TF for a certain amount of time. If we artificially change the metrics, we will be comparing apples and oranges, and the whole system of credit loses its meaning.

[Prime95]

Originally Posted by PsycO

So, if Prime95 read this little complaints, i hope something will be done to calm my consciousness...

I read many of the forum posts. I'd argue that there is no "correct" solution. If I change the formulas then those that are doing TF using a CPU are penalized.

Perhaps, the solution is to no longer have an overall Top Producers report which mixes CPU credits from hardware platforms that are not really comparable. Rather, we could support only the Top LL, Top Double-check, and Top TF reports.

In any event, remember the main goal is to generate useful mathematical results, not CPU credits.

[Brain]

Maybe Andrew Thall's new gpuLucas will solve the current "problem" with a super-fast-LL-implementation producing dozens of GHz-days per minute...

[nucleon]

I find this recalibration of GHz-days metric to be a non-discussion. If we change things now, we may have to change it all back with say a next generation GPU card comes out with similar LL throughput as TF throughput.

Using a GTX560Ti as a benchmark:

LL Test - 11 GHz-days/day (source: GPU FAQ pdf)
TF - 175 GHz-days/day
(source: Last 10 day avg on my pc 2x 2.9Ghz i7 930 cores with sieveprimes=5000, GPU Load=99%)

Taken from:
http://mersenne-aries.sili.net

Using M46447963 as a guide. (Why this number? - it just happens to be one of the exponents I'm currently TF-ing :)

TF 41.1 GHz-days (64 to 74bits) 13.215% chance of factor
LL 80.6 GHz-days (+80.6 GHz-days for double check)

Take these resources:
2x 2.9GHz i7 930 cores
1x 560TI GPU

LL throughput: 11 + 2x3 (ish) = 17GHz-days per day
TF throughput: 175 GHz-days/day


So given enough exponents around this range, we'd need to TF approx 7.4 exponents to find a conclusive result, i.e. 1/0.13215, or put it another way 7.4 x 41.1 = 304.14 GHz-days worth of TF work is equivalent of 2x LL tests (161.2GHz days)

In my mind it's mathematically equivalent to find a factor of one exponent as it does to find matching non-zero LL residues.

This equates to, when using the above resources:
TF: 1.74 "real days" (using 175GHz-days/day)
LL: 9.48 "real days" (using 17GHz-days/day)

So TF on GPU is 5.45x more efficient than doing LL tests with the equivalent resources in the above example. YMMV.

To maximize your resources:

If you have sufficient matching CPU resources to your available GPU resources - run mfaktc.

On your remaining GPU resources - run LL tests on the remaining GPU resources.


-- Craig

[PsycO]

Originally Posted by nucleon

...
To maximize your resources:

If you have sufficient matching CPU resources to your available GPU resources - run mfaktc.

On your remaining GPU resources - run LL tests on the remaining GPU resources.


-- Craig

This is exactly what i do now... I run 1 mfaktc on my gt-430 bind to 1 cpu, and an another one on my gts-450 bind to the second core. As i only have 2 core, i can't fill my gts-450 with job, even if i only sieve 5000... So i run cudalucas on it to keep it busy.

For my previoux comments about changing the ghz/days ratio for LL, i was wrong... I not taken into account the multiples variables of this problem...

Originally Posted by Prime95

...
Perhaps, the solution is to no longer have an overall Top Producers report which mixes CPU credits from hardware platforms that are not really comparable. Rather, we could support only the Top LL, Top Double-check, and Top TF reports.

The Top Producers report stimulate competitions, so putting cpu with cpu, gpu with gpu on two page is the best option! The report already know from what software the result came from, so it's just a matter of adding a page a split them in their respective place! But if you don't want to do the job of splitting the things and add a page, maybe it's simply better to leave it this way...

[Prime95]

Originally Posted by PsycO

The Top Producers report stimulate competitions, so putting cpu with cpu, gpu with gpu on two page is the best option! The report already know from what software the result came from, so it's just a matter of adding a page a split them in their respective place! But if you don't want to do the job of splitting the things and add a page, maybe it's simply better to leave it this way...

The LL, double-check, etc reports already exist. The TF report shows TF credits from both GPU and CPU.

[Dubslow]

I think he meant putting CPU TF on one page, and GPU TF on another. Which results are which should be easy to determine, even retroactively; anything done in gpu is tagged with mfakt* somewhere in the results line.

[Xyzzy]

The current system seems to work well enough.

Who wouldn't trade all of their accumulated stats for a Mersenne prime?

[Dubslow]

Originally Posted by Xyzzy

The current system seems to work well enough.

Who wouldn't trade all of their accumulated stats for a Mersenne prime?

Well said.

[TheJudger]

Originally Posted by PsycO

The Top Producers report stimulate competitions, so putting cpu with cpu, gpu with gpu on two page is the best option!

Well, we should distinguish CC 1.x and CC 2.x GPU stats, too because CC 2.x is so much faster for as CC 1.x GPUs... that is not fair so we need additional stats! And for ATI/AMD GPUs we need another page, too!</irony>

My 2 cents: Same job => same credit, same stats! (or no credits/stats at all...) No matter which hardware was used and how much real time was needed for computation.

Oliver