gpuOwL: an OpenCL program for Mersenne primality testing

[kriesel]

Originally Posted by mnd9

Does anyone have a sense of whether adding additional RAM always contributes to Prime95 throughput? E.g. I currently have 2 x 8GB DDR3 memory @ 1333 mHz -- would adding another 2 sticks help? Is it safe to assume memory bandwidth is always limiting?

More ram total could help P-1 stage 2 significantly (or ECM if you run that work type), providing you adjust the allowed memory in prime95 accordingly. 16GB is plenty for running primality tests at the wavefront. (It's possible to run primality tests on old systems with 1 or 2 GB, cpu or ram speed, not ram amount is the problem there.)

[VBCurtis]

Originally Posted by kriesel

More ram total could help P-1 stage 2 significantly (or ECM if you run that work type), providing you adjust the allowed memory in prime95 accordingly. 16GB is plenty for running primality tests at the wavefront. (It's possible to run primality tests on old systems with 1 or 2 GB, cpu or ram speed, not ram amount is the problem there.)

You noticed he asked about memory bandwidth, not capacity, right?

mnd9-
If CPU is the bottleneck, a worker with 4 threads will run proportionally faster than a worker with 3 threads because the 4th core gets to be fully used (there is some overhead to splitting the job onto N workers; it won't quite be perfectly proportional). If memory is bottlenecked, a 4-thread worker won't be appreciably faster than a 3-thread worker.

If you have an enthusiast motherboard, you could also try underclocking the CPU; if dropping CPU speed by 200 mhz doesn't change your sec/iteration speed, it's the memory holding you back rather than the CPU. Some folks do this all the time, to save a bit on power; CPU power use scales with Mhz linearly but with the square of voltage, and a small underclock can be paired with some undervolting to meaningfully drop power consumption "for free".

Some people have reported Prime95 speed improvements with dual-rank memory (different from dual-channel); running 4 sticks of memory in a 2-channel board may have the same effect. That said, it's a small effect, perhaps 5-10%, and thus generally not a justification for buying more memory. It did motivate some folks to spec dual-rank memory when they built new machines, though!

[kriesel]

Originally Posted by VBCurtis

You noticed he asked about memory bandwidth, not capacity, right?

Not exactly. mnd9 first asked

Does anyone have a sense of whether adding additional RAM always contributes to Prime95 throughput?...would adding another 2 sticks help?

You noticed he asked about adding ram, affecting prime95 performance, not power efficiency or underclocking or multiple channels or memory speed ratings or system performance in general, right?
Although I raised cooling effectiveness as a possible reason he sees interaction between mfakto and prime95, which he is interested in enough to suspend running mfakto for now.
Ok, I'm going to assume you were not 100% alert either when responding. The forum is better when we're all cordial and do not demand (some version of) perfection outside of number theory proofs. I'm unaware of any rules against offering information related if a bit tangential to the direct question(s) posed. And a certain amount of tolerance for drifting off topic briefly on a thread is customary. Too much, and a moderator may move it to its own separate thread(s). There are other threads that fit these related or tangential issues better than this gpuowl specific thread does. (You've been here long enough to know that, but there are also new folk here, or will be later reading this.) And some questions don't fit neatly in one category or the other, relating to the interaction of hardware configuration or settings and related software performance.

[XZT]

Hi,

I'm trying to use gpuOwl on some hardware that is slightly unreliable (I'd prefer to run PRP double check assignments) but I probably haven't set it up correctly, getting a mismatch after a couple of days on M78374381.

I've now got a manual PRP running this again in Prime95 as a check. Not sure how to properly get it assigned to the CPU though. The manual assignments page didn't pick it up nor did manual communication from Prime95. Currently using the below line in Prime95 worktodo, not sure it this is right, which should finish in ~3 days.

PRP=N/A,1,2,78374381,-1

My other manual PRP test on M78362279 also looks like a mismatch, not checked in yet. For reference, the result line is:

 {"exponent":"78362279", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"v6.5-c48d46f"}, "timestamp":"2019-06-19 14:34:36 UTC", "aid":"****", "fft-length":4718592, "res64":"cf01d39aa645c3__", "residue-type":4}

Where would the issue be?
I've read a bit of https://www.mersenneforum.org/showthread.php?t=23391 and this thread, but can't really follow.

GPUs are RX480 8GB on Windows 10 version 1809, Radeon Software Version 19.6.1.

Using gpuOwl v6.5-c48d46f from https://www.mersenneforum.org/showpost.php?p=516704 and running a test on 3021377 gets the same results as in the post.


As an aside:

• Is there a proper way to get specific PRP exponents assigned?
• Besides PRP, is there something else with sufficient error checking for (very slightly) unreliable hardware? I've done TF (mfakto) on these GPUs before and, from memory, found false positive factors and likely have left some false negatives.

[kriesel]

Originally Posted by XZT

Where would the issue be?

Here's a possibility.
For prp residues to match, the prp residue type must match.

Your gpuowl result shows PRP residue type 4. Gpuowl does whatever type the gpuowl version implements. Prime95 supports multiple residue types. I'm unsure which is prime95's default, but think it is residue type 1.

It's likely since you do not specify PRP residue type in your prime95 worktodo line, and there are at least 5 PRP residue types possible, that the residue types are not matching. See https://www.mersenneforum.org/showpo...32&postcount=8 and the prime95 readme.txt
See https://www.mersenneforum.org/showpo...3&postcount=15 for residue type versus gpuowl version.
Gpuowl v3.8 is pretty good and produces residues type 1.

There's no better error detection choice than PRP with GEC.
Prime95 also implements LL with Jacobi check but that has a 50% chance of detecting an error, considerably less than the nearly 100% of GEC.

P-1 and TF do not have equivalent error detection. (P-1 does some checks, like roundoff error checking.) The cost of an undetected error is less in factoring than in primality tests. False positive factors are easily detected; the primenet server checks every factor submitted. False negatives mean more computing time is used. There is a bit of overlap between TF and P-1; around 20% of factors are smooth enough and small enough that they could be found by either TF or P-1. The cost of adding a Jacobi check into P-1 appears higher and the payoff lower than for LL.

[Prime95]

Originally Posted by XZT

I'm trying to use gpuOwl on some hardware that is slightly unreliable (I'd prefer to run PRP double check assignments) but I probably haven't set it up correctly, getting a mismatch after a couple of days on M78374381.]

Your result is OK. You are a victim of gpuowl and prime95 producing different types of residues.

I thought Mihai had agreed to make type-1 residues gpuowl's default. However, it is still producing type-4.


BTW, go do first-time PRP tests. No matter how flaky the hardware, you will get a good result.

[endless mike]

It shouldn't let you assign the first one to yourself again since you already submitted a result for it. Your manual assignment will generate a type 1 residue and will most likely match the result submitted by Milwizzle. I can run a check with prime95 and submit as a type 4 residue to match yours as well. Submit the result you have for the second one, and I will run a doublecheck with prime95 and a type 4 residue as well.

Originally Posted by XZT

Hi,

I'm trying to use gpuOwl on some hardware that is slightly unreliable (I'd prefer to run PRP double check assignments) but I probably haven't set it up correctly, getting a mismatch after a couple of days on M78374381.

I've now got a manual PRP running this again in Prime95 as a check. Not sure how to properly get it assigned to the CPU though. The manual assignments page didn't pick it up nor did manual communication from Prime95. Currently using the below line in Prime95 worktodo, not sure it this is right, which should finish in ~3 days.

PRP=N/A,1,2,78374381,-1

My other manual PRP test on M78362279 also looks like a mismatch, not checked in yet. For reference, the result line is:

 {"exponent":"78362279", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"v6.5-c48d46f"}, "timestamp":"2019-06-19 14:34:36 UTC", "aid":"****", "fft-length":4718592, "res64":"cf01d39aa645c3__", "residue-type":4}

Where would the issue be?
I've read a bit of https://www.mersenneforum.org/showthread.php?t=23391 and this thread, but can't really follow.

GPUs are RX480 8GB on Windows 10 version 1809, Radeon Software Version 19.6.1.

Using gpuOwl v6.5-c48d46f from https://www.mersenneforum.org/showpost.php?p=516704 and running a test on 3021377 gets the same results as in the post.


As an aside:

• Is there a proper way to get specific PRP exponents assigned?
• Besides PRP, is there something else with sufficient error checking for (very slightly) unreliable hardware? I've done TF (mfakto) on these GPUs before and, from memory, found false positive factors and likely have left some false negatives.

[XZT]

Thanks for the explanations!

I'll switch to some first-time PRP tests. I do still have a preference for double checks due to a desire to close the LL/LL-D gap and that it was a way to check hardware reliability. But I guess PRP with the Gerbicz error check now helps with the latter. I wonder how much the switch has impacted the LL gap as well.

Also out of curiosity:

• Is there a guide to the worktodo line arguments used by Prime95 or gpuOwl?
• Is it possible to set the PRP residue type used by a particular version of Prime95 or gpuOwl? Probably don't need it, but I made use of the -dir option of gpuOwl v6.5.
• Is there a way to determine the PRP residue type used on a running Prime95 test? Do we assume it's a type 1 by default (or whatever is set in worktodo?), though it doesn't seem to display on the gui?

Originally Posted by XZT

Thanks for the explanations!

I'll switch to some first-time PRP tests. I do still have a preference for double checks due to a desire to close the LL/LL-D gap and that it was a way to check hardware reliability. But I guess PRP with the Gerbicz error check now helps with the latter. I wonder how much the switch has impacted the LL gap as well.

Also out of curiosity:

• Is there a guide to the worktodo line arguments used by Prime95 or gpuOwl?
• Is it possible to set the PRP residue type used by a particular version of Prime95 or gpuOwl? Probably don't need it, but I made use of the -dir option of gpuOwl v6.5.
• Is there a way to determine the PRP residue type used on a running Prime95 test? Do we assume it's a type 1 by default (or whatever is set in worktodo?), though it doesn't seem to display on the gui?

The guide for gpuowl is at https://github.com/preda/gpuowl
but you can just type

./gpuowl -h

to show the help text.

[kriesel]

Originally Posted by XZT

Thanks for the explanations!

I'll switch to some first-time PRP tests. I do still have a preference for double checks due to a desire to close the LL/LL-D gap and that it was a way to check hardware reliability. But I guess PRP with the Gerbicz error check now helps with the latter. I wonder how much the switch has impacted the LL gap as well.

Also out of curiosity:

• Is there a guide to the worktodo line arguments used by Prime95 or gpuOwl?
• Is it possible to set the PRP residue type used by a particular version of Prime95 or gpuOwl? Probably don't need it, but I made use of the -dir option of gpuOwl v6.5.
• Is there a way to determine the PRP residue type used on a running Prime95 test? Do we assume it's a type 1 by default (or whatever is set in worktodo?), though it doesn't seem to display on the gui?

Each bullet point in turn:
1) prime95 has very good documentation files, so yes. gpuowl uses mostly the same style. PRP-1 iwas a prominent exception, in gpuowl 4.x and 5.0, for which there's no prime95 equivalent.

2) prime95 yes (see its readme.txt); gpuowl only in the sense of specifying PRP or PRP-1 (type 4 or type 0) in certain versions; otherwise pick a version of gpuowl that performs type 4 or a version that performs type 1. There's a table in the attachment at https://www.mersenneforum.org/showpo...3&postcount=15

3) during the run, look at the residue type field of the worktodo line; afterward, look it up on the primenet server ("Type" field). It does not show in the worker window text content or title status bar, or in the logs. (I think those would be good additions in some future rev of prime95.)

[kriesel]

Originally Posted by SELROC

The guide for gpuowl is at https://github.com/preda/gpuowl

The readme there mistakenly says "A long-standing distributed compting project named the Great Internet Mersenne Prime Search (GIMPS) has been searching for Mersenne primes for the last 30 years." 2019-30=1989.

Prime95 and GIMPS were created in 1996, not 1989
https://www.mersenne.org/various/history.php "GIMPS was founded in 1996 by George Woltman."