TPSieve CUDA Testing Thread - Page 4

mdettweiler · 2010-09-17, 16:57

Quote:

Originally Posted by Ken_g6

That's probably the cause. Some output goes to stderr (so that BOINC will save it, and/or because I'm lazy and haven't sorted out what shouldn't go to stderr

). Try a 2>&1 before your tee.

Ah, I hadn't thought of that. Okay, I'll try the 2>&1 next time.

Oddball · 2010-09-19, 05:28

Would Ken or anyone else be interested in developing a CUDA sieve for a fixed n? If so, it could be used on the n=1000000 sieve for the Operation Megabit Twin subproject.

Ken_g6 · 2010-09-19, 17:53

Forget what I said here before; that was a fixed-K sieve.

The main obstacle to a fixed-N sieve is producing a list of primes to sieve against on the GPU. It might be doable.

mdettweiler · 2010-09-19, 19:08

Quote:

Originally Posted by Ken_g6

Forget what I said here before; that was a fixed-K sieve.

The main obstacle to a fixed-N sieve is producing a list of primes to sieve against on the GPU. It might be doable.

I don't suppose tpsieve itself works for fixed-n sieves? Or is it just that it's way slower than NewPGen for such?

Ken_g6 · 2010-09-19, 19:23

Yeah, TPSieve-CUDA should work for a single N. It might even be faster than NewPGen, per CPU core run. And you might be able to run two or more processes at a time. But there would be a lot of bandwidth back and forth.

Oddball · 2010-09-19, 20:43

Quote:

Originally Posted by Ken_g6

Yeah, TPSieve-CUDA should work for a single N.

It doesn't work for large k ranges, though. From:

http://www.mersenneforum.org/showpos...6&postcount=86

Quote:

tpsieve (64-bit) refuses to sieve it:

Code:
tpsieve version 0.3.4 (testing)Compiled Sep 7 2009 with GCC 4.3.3kmax-kmin < 3*2^36 is required

edit: Is there any way you can get around the kmax-kmin < 3*2^36 limitation for the CPU version of TPSieve?

Ken_g6 · 2010-09-19, 20:53

That is an immense K range! The bitmap wouldn't fit in memory if you're getting that big. And besides, TPSieve wouldn't work until pmin > kmax.

How many candidates do you have in that range? Are you just sieving for twins, or for more specialized forms?

Oddball · 2010-09-19, 21:26

Quote:

Originally Posted by Ken_g6

That is an immense K range! The bitmap wouldn't fit in memory if you're getting that big. And besides, TPSieve wouldn't work until pmin > kmax.

How many candidates do you have in that range? Are you just sieving for twins, or for more specialized forms?

We're sieving k=1-120T for sophies and twins at first (until p=100G), but it's now a twin only sieve:

http://www.mersenneforum.org/showthread.php?t=13439

The file has about 85M candidates.

kar_bon · 2010-09-19, 22:51

Quote:

Originally Posted by Oddball

We're sieving k=1-120T for sophies and twins at first (until p=100G), but it's now a twin only sieve:

http://www.mersenneforum.org/showthread.php?t=13439

The file has about 85M candidates.

The file for k=1-120T at p=45T posted by Amphoria contains 78451842 candidates.

Ken_g6 · 2010-09-27, 18:14

Hi, all,

I have a new version of TPSieve-CUDA, V0.2.0, out for testing. It's a lot faster than the current version, but I've added one algorithm I'm not completely sure about. I need people to test this new version against previous sieve files, where 22 <= nstep <= 31 and p > 9T. (Just make sure it says that nstep is changed to 22.) And let me know if it misses any factors.

If this works, I have big plans for this app. One of those involves improving its speed a little more still. But if this app misses any factors, I need to know ASAP so I can re-arrange stuff.

Thanks!

amphoria · 2010-09-27, 21:16

I have re-run 510T-511T of 480000-485000 and the factors match. I used the default value of -m as the meaning has either changed or the new code puts a greater load on the GPU. My original best value of 24576 caused the code to grind to a halt. With the default value I got an improvement from 138M p/sec (CPU 0.41) to 195M p/sec (CPU 0.57).

2010-09-19, 05:28	#35
Oddball May 2010 1F3₁₆ Posts	Would Ken or anyone else be interested in developing a CUDA sieve for a fixed n? If so, it could be used on the n=1000000 sieve for the Operation Megabit Twin subproject. Last fiddled with by Oddball on 2010-09-19 at 05:28

2010-09-19, 17:53	#36
Ken_g6 Jan 2005 Caught in a sieve 5×79 Posts	Forget what I said here before; that was a fixed-K sieve. The main obstacle to a fixed-N sieve is producing a list of primes to sieve against on the GPU. It might be doable. Last fiddled with by Ken_g6 on 2010-09-19 at 17:59

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Fast Mersenne Testing on the GPU using CUDA	Andrew Thall	GPU Computing	109	2014-07-28 22:14
Inconsistent factors with TPSieve	Caldera	Twin Prime Search	7	2013-01-05 18:32
tpsieve-cuda slows down with increasing p	amphoria	Twin Prime Search	0	2011-07-23 10:52
Is TPSieve-0.2.1 faster than Newpgen?	cipher	Twin Prime Search	4	2009-05-18 18:36
Thread for non-PrimeNet LL testing	ThomRuley	Lone Mersenne Hunters	6	2005-10-16 20:11

2010-09-19, 19:23	#38
Ken_g6 Jan 2005 Caught in a sieve 5·79 Posts	Yeah, TPSieve-CUDA should work for a single N. It might even be faster than NewPGen, per CPU core run. And you might be able to run two or more processes at a time. But there would be a lot of bandwidth back and forth.

2010-09-19, 20:53	#40
Ken_g6 Jan 2005 Caught in a sieve 5·79 Posts	That is an immense K range! The bitmap wouldn't fit in memory if you're getting that big. And besides, TPSieve wouldn't work until pmin > kmax. How many candidates do you have in that range? Are you just sieving for twins, or for more specialized forms?

2010-09-27, 18:14	#43
Ken_g6 Jan 2005 Caught in a sieve 5×79 Posts	Hi, all, I have a new version of TPSieve-CUDA, V0.2.0, out for testing. It's a lot faster than the current version, but I've added one algorithm I'm not completely sure about. I need people to test this new version against previous sieve files, where 22 <= nstep <= 31 and p > 9T. (Just make sure it says that nstep is changed to 22.) And let me know if it misses any factors. If this works, I have big plans for this app. One of those involves improving its speed a little more still. But if this app misses any factors, I need to know ASAP so I can re-arrange stuff. Thanks!

2010-09-27, 21:16	#44
amphoria "Dave" Sep 2005 UK 2³×347 Posts	I have re-run 510T-511T of 480000-485000 and the factors match. I used the default value of -m as the meaning has either changed or the new code puts a greater load on the GPU. My original best value of 24576 caused the code to grind to a halt. With the default value I got an improvement from 138M p/sec (CPU 0.41) to 195M p/sec (CPU 0.57).