fnsieve - Page 2

schickel · 2011-11-24, 18:46

Quote:

Originally Posted by rogue

I've posted 1.0.1 here: http://home.roadrunner.com/~mrodenki...ieve_1.0.1.zip. The included build is for Win64. I can't test it as I don't have a Win64 box available to me.

The only change is to address sieving for p > 2^32. The other change will need to wait until next week.

I have access to a Vista and a 7 64-bit system, if you have a test case you want run.

Phil MjX · 2011-11-24, 20:40

Hello !

Still hangs for me at p>2^32 for me with the same test case and win64 1.0.1 binary...

But all is OK with the 32 bits binary and the speed is apparently not so different on my system !

Can I help you with other test cases ?

Thanks for the program,
Regards

Philippe

rogue · 2011-11-24, 20:52

Quote:

Originally Posted by Phil MjX

Still hangs for me at p>2^32 for me with the same test case and win64 1.0.1 binary...

But all is OK with the 32 bits binary and the speed is apparently not so different on my system !

Can I help you with other test cases ?

I can't look at it until next week.

Phil MjX · 2011-11-28, 19:33

Hi,

I haved finished a range up to 4e12 and have noticed a bug with version 1.01 (32 bits):

Code:

ABC 1*10^80+$a // Sieved to 4000000000003 with fnsieve
42
73
91
127
129
132
141
168
171
177
259
282
349
366
367
372
391
427
436
438
462
519
552
562
618
661
682
687
718...

In the result file, half of the candidates are even !

With version 1.00 64 bits, all is OK -at least up to 2^32!

Code:

ABC 1*10^80+$a // Sieved to 4294987951 with fnsieve
73
91
127
129
133
141
171
177
259
349
367
391
427
513
519
531
661
687
699
757...

Another point, in fnsieve.h, max p is 4e12+3.

Code:

/* If --pmax is not specified use pmax = pmin + DEFAULT_P_RANGE.
 */
#define DEFAULT_P_RANGE UINT64_C(4000000000000);

For prp'ing candidates, it is certainly more than enough, but in case of brilliant numbers search, I have reached the limit with a rate of 2s/candidate.

ECM up to 25 digits takes me 40 seconds so I'd like to increase pmax.

Is it possible without trashing everything ?

Kind regards
Philippe

rogue · 2011-11-28, 20:22

Use -P to override the max prime for sieving.

I just posted 1.0.2 here: http://home.roadrunner.com/~mrodenki...ieve_1.0.2.zip

It fixed the issue that was causing even values to not be sieved. It was also built on a 64-bit Windows machine, so it definitely goes above p = 2^32 without a problem.

smh · 2011-11-28, 20:46

Correct link: http://home.roadrunner.com/~mrodenki...ieve_1.0.2.zip

rogue · 2011-11-28, 20:48

Quote:

Originally Posted by smh

Correct link: http://home.roadrunner.com/~mrodenki...ieve_1.0.2.zip

Thanks. Fixed the link above.

smh · 2011-11-28, 20:56

When I resume a sieve the results are not saved

Code:

Sieving 100000000 <= p <= 200000000 eliminated 1084 terms, 29479 remain.
Wrote 0 terms to file fn_1_10_99.pfgw.
fnsieve stopped: at p=200000000 because --pmax was reached.

rogue · 2011-11-28, 21:33

Easy fix. I had a bug in a while loop.

I just posted 1.0.3 here: http://home.roadrunner.com/~mrodenki...ieve_1.0.3.zip

KEP · 2011-12-20, 15:07

Could someone please build a Windows 32-bit version, such that I can test it. I would like to test it on the n=999999 b=10 k=1 test that I'm currently doing? Since I have no 64bit OS, my options and possibilities are limited.

rogue · 2012-10-24, 00:34

I have posted an OpenCL version of fnsieve here.

Right now it just takes a sequence and a range of c and outputs factors regardless of whether one has already been found for that c. You will need to start with a larger prime when sieving, say 1e6 because of how I have it working right now. Smaller starting primes can crash the program. I'll fix that in the next release. I'll also have it read a pfgw file and output a pfgw file that will remove c for which a factor was found.

The GPU version is about 8x faster than the CPU version. It could potentially be faster, but the prime sieve is done in the CPU and that is the limiting factor. I recommend increasing the number of threads and the number of blocks to find an optimal rate. I had to use -t10 -b10000 to get 8x faster.

2011-11-24, 20:40	#13
Phil MjX Sep 2004 5·37 Posts	Hello ! Still hangs for me at p>2^32 for me with the same test case and win64 1.0.1 binary... But all is OK with the 32 bits binary and the speed is apparently not so different on my system ! Can I help you with other test cases ? Thanks for the program, Regards Philippe Last fiddled with by Phil MjX on 2011-11-24 at 20:41

2011-11-28, 19:33	#15
Phil MjX Sep 2004 5×37 Posts	Hi, I haved finished a range up to 4e12 and have noticed a bug with version 1.01 (32 bits): Code: ABC 110^80+$a // Sieved to 4000000000003 with fnsieve 42 73 91 127 129 132 141 168 171 177 259 282 349 366 367 372 391 427 436 438 462 519 552 562 618 661 682 687 718... In the result file, half of the candidates are even ! With version 1.00 64 bits, all is OK -at least up to 2^32! Code: ABC 110^80+$a // Sieved to 4294987951 with fnsieve 73 91 127 129 133 141 171 177 259 349 367 391 427 513 519 531 661 687 699 757... Another point, in fnsieve.h, max p is 4e12+3. Code: /* If --pmax is not specified use pmax = pmin + DEFAULT_P_RANGE. / #define DEFAULT_P_RANGE UINT64_C(4000000000000); For prp'ing candidates, it is certainly more than enough, but in case of brilliant numbers search, I have reached the limit with a rate of 2s/candidate. ECM up to 25 digits takes me 40 seconds so I'd like to increase pmax. Is it possible without trashing everything ? Kind regards Philippe Last fiddled with by Phil MjX on 2011-11-28 at 19:35 Reason: typos*

2011-11-28, 20:22	#16
rogue "Mark" Apr 2003 Between here and the 2·3²·353 Posts	Use -P to override the max prime for sieving. I just posted 1.0.2 here: http://home.roadrunner.com/~mrodenki...ieve_1.0.2.zip It fixed the issue that was causing even values to not be sieved. It was also built on a 64-bit Windows machine, so it definitely goes above p = 2^32 without a problem. Last fiddled with by rogue on 2011-11-28 at 20:48 Reason: fixed the link

2011-11-28, 20:56	#19
smh "Sander" Oct 2002 52.345322,5.52471 29·41 Posts	Bug? When I resume a sieve the results are not saved Code: Sieving 100000000 <= p <= 200000000 eliminated 1084 terms, 29479 remain. Wrote 0 terms to file fn_1_10_99.pfgw. fnsieve stopped: at p=200000000 because --pmax was reached.

2011-12-20, 15:07	#21
KEP Quasi Admin Thing May 2005 2×3×7×23 Posts	Could someone please build a Windows 32-bit version, such that I can test it. I would like to test it on the n=999999 b=10 k=1 test that I'm currently doing? Since I have no 64bit OS, my options and possibilities are limited. Last fiddled with by KEP on 2011-12-20 at 15:08

2011-11-28, 20:46	#17
smh "Sander" Oct 2002 52.345322,5.52471 29×41 Posts	Correct link: http://home.roadrunner.com/~mrodenki...ieve_1.0.2.zip

2011-11-28, 21:33	#20
rogue "Mark" Apr 2003 Between here and the 14322₈ Posts	Easy fix. I had a bug in a while loop. I just posted 1.0.3 here: http://home.roadrunner.com/~mrodenki...ieve_1.0.3.zip

2012-10-24, 00:34	#22
rogue "Mark" Apr 2003 Between here and the 2·3²·353 Posts	I have posted an OpenCL version of fnsieve here. Right now it just takes a sequence and a range of c and outputs factors regardless of whether one has already been found for that c. You will need to start with a larger prime when sieving, say 1e6 because of how I have it working right now. Smaller starting primes can crash the program. I'll fix that in the next release. I'll also have it read a pfgw file and output a pfgw file that will remove c for which a factor was found. The GPU version is about 8x faster than the CPU version. It could potentially be faster, but the prime sieve is done in the CPU and that is the limiting factor. I recommend increasing the number of threads and the number of blocks to find an optimal rate. I had to use -t10 -b10000 to get 8x faster.