[quote=Mini-Geek;205489]Does it still cover all factors? It seems to me that if you only cover 16 of the 30 potential values, you'd be missing about half the factors.[/quote]
Factors are +/-1 mod 8 (Euler).

[quote=davieddy;205494]Factors are +/-1 mod 8 (Euler).[/quote]
I know. This makes for 30 potential values mod 120. How can you eliminate 14 of those?
Actually, I think I see it now. Here are a few of the values mod 120 that are valid (by the +/- 1 mod 8 rule):
+-7
+-9
+-15

If a number is 9 mod 120 (3^2 mod 3*40), then it is divisible by 3 and so composite.
If it is 15 mod 120 (3*5 mod 2^3*3*5), then it is divisible by 3 and 5 and therefore composite.
But if it's 7 mod 120, then we don't know that it is composite. It might be prime.
14 of the 30 potential values can be eliminated by this, leaving 16 that might be prime.
Sound about right? :smile:

[QUOTE=TheJudger;205461]S485122: did you know that prime95 missed some factors as wel?

Oliver[/QUOTE]There is a thread about that: [url=http://www.mersenneforum.org/showthread.php?t=11541] P-1 Stage 1 factor [/url], and more specifically :
[QUOTE=Prime95;164808]Fixed in 25.9 build 4.

The CMOV code tests 4 potential factors simultaneously. When a 4KB sieve block ends, if there are 1,2,or 3 unprocessed potential factors saved up they (and their reciprocals) are postponed until the next 4KB sieve block. Unfortunately, the reciprocals were not properly saved and restored.

I think the sieve clears about 80% of the 32K bits in the 4KB sieve. Thus, on average, 1.5 potential factors out of each 6000 did not get tested. P-1 should catch many of these.[/QUOTE]So that bug is fixed.

And indeed unless one specifies an option Prime95 trial factoring sometimes does not report the smallest factor, but that is another problem.

Jacob

[quote=Mini-Geek;205498]
Sound about right? :smile:[/quote]
Sounds like what ATH said.
I think a penny has dropped:
I eliminated all 2kp+1 which were 3 or 5 (mod 8) or divisible by a prime
<40,000 and IIRC eliminated ~90%. "The Math" page said ~95%.
Presumably the mod 120 trick eliminates the extra 5%.
If this is right, I think it might be mentioned on "The Math" page.

David

[quote=davieddy;205536]Sounds like what ATH said.
I think a penny has dropped:
I eliminated all 2kp+1 which were 3 or 5 (mod 8) or divisible by a prime
<40,000 and IIRC eliminated ~90%. "The Math" page said ~95%.
Presumably the mod 120 trick eliminates the extra 5%.
If this is right, I think it might be mentioned on "The Math" page.

David[/quote]
If what I posted earlier is right, then the mod 120 trick is really just an easy way to sieve for very small primes (under 120). Maybe the 5% difference is due to the size of the k and p in question or the limit on small primes to divide by.

[QUOTE=Mini-Geek;205560]If what I posted earlier is right, then the mod 120 trick is really just an easy way to sieve for very small primes (under 120). Maybe the 5% difference is due to the size of the k and p in question or the limit on small primes to divide by.[/QUOTE]

Not exactly.
From 120 you get the 16 residual classes of numbers that are not multiples of 3,5 and are 1 or 7 mod 8 out of 60.

Luigi

[quote=Mini-Geek;205560]If what I posted earlier is right, then the mod 120 trick is really just an easy way to sieve for very small primes (under 120). Maybe the 5% difference is due to the size of the k and p in question or the limit on small primes to divide by.[/quote]
Sorry for any delay in posting - I'm getting more senile by the minute:
60 on Mar 18th (hint hint).
My estimate is 90% for factors ~2^15, 95% for 2^30 and 97% for 2^60.

Were you trying to suggest that Prime95 prioritized trial factors
according to their value mod 120?

David

Hi,

find attached version 0.05.
This is an other performance upgrade:
- GPU-code ~20% faster than it was in 0.04
- siever (CPU) is a little bit faster, too

For the next releas(es) I plan to add functionallity, move some compiletime options to runtime options and try to be more compatible to Windows users.

This includes a fix for the problem with "multiple factors close together" described earlier in this thread. This fix needs some more testing. A simple fix would be the usage of atomic operations _BUT_ they are not available on G80-GPUs (Geforce 8800 GTX/ GTS 320 / GTS 640 and their Quadro/Tesla variants)

I've added even more known factors to the selftest. The selftest is a test for the software, it is not designed as a hardware test. Without "MORE_CLASSES" defined it will take more than a hour even on a fast system.

-----
latest benchmark on my system:

Single Process
THREADS_PER_GRID: 30 * 2^15
THREADS_PER_BLOCK: 256
SIEVE_PRIMES: 29000

M66362159 from 2^ 1 to 2^64: 90.7s
M66362159 from 2^64 to 2^65: 83.4s
M66362159 from 2^65 to 2^66: 164.8s
M66362159 from 2^66 to 2^67: 326.5s

Single Process
THREADS_PER_GRID: 30 * 2^15
THREADS_PER_BLOCK: 256
SIEVE_PRIMES: 55000

M3321932839 from 2^50 to 2^71: 253.0s


Oliver

Hi,

raw speed on my GTX 275 is now 80M candidates per second for M66362159 (my official benchmark exponent ;)). This was achived by using 2 streams/datasets which allows concurrent data transfer and processing on newer GPUs.


Oliver

[QUOTE=TheJudger;207433]Hi,

raw speed on my GTX 275 is now 80M candidates per second for M66362159 (my official benchmark exponent ;)). This was achived by using 2 streams/datasets which allows concurrent data transfer and processing on newer GPUs.


Oliver[/QUOTE]

Does that mean that release 0.06 is coming? :smile:

Luigi

:bump::smile:

Luigi