Msieve v1.49 feedback - Page 2

chris2be8 · 2011-06-22, 17:06

Quote:

Originally Posted by Andi47

ooops you are right, the ; went indeed missing. I will do another test run in a few days. (I don't want to interrupt my current factorization.)

Try running factMsieve.pl without any parameters. You should get a usage message, which at least proves the perl doesn't have any obvious syntax errors.

Chris K

jasonp · 2011-06-22, 20:49

If you're doing NFS postprocessing, you don't even need a 'N' line in the relation file, and any such lines are ignored.

Right now whether relations are compressed or not is determined at compile time; if compiled with zlib, the library checks whether the beginning of the relation file is a recognizable zlib header, but only for reading relations. When compiled with compression, relations should always be written in compressed format IIRC.

You don't really want to use the line sieve anyway :)

Batalov · 2011-06-23, 02:22

With NO_ZLIB=1, there's no way for the binary to write the compressed output (it simply isn't equipped)!

With zlib, in msieve, reading is done from either compressed or uncompressed file, writing to a new file never happens*, and appending to an existing file honors and preserves its state - either compressed or uncompressed.

________
*Nobody line sieves!

...and even if they do, the perl script must have already created a file with "N ...." in it, by tradition. (An optionally modified perl script may have gzipped it, too; no harm in that. A further modified perl script may spawn sievers with -z option and concatenate them to the gzipped .dat file, too.) Don't know what the python script does. Then read on what happens while appending to an existing file.

chris2be8 · 2011-06-23, 16:48

In my experience line sieving is faster than lattice sieving very near the origin, but quickly slows down. So it's only worth doing a small range.

The existing perl script does a small range on the master system, but only uses one thread for it. What I am trying to do is to allow the use to choose which system does the line sieving, they get best overall throughput if it's done on a single core system that can't run the 64bit lattice siever.

I'll probably put a "N " line into the line sieving output file. The worst that can do is generate a "error -n reading relation m" message.

Chris K

Andi47 · 2011-06-24, 13:55

Quote:

Originally Posted by chris2be8

Try running factMsieve.pl without any parameters. You should get a usage message, which at least proves the perl doesn't have any obvious syntax errors.

Chris K

Seems to work now (currently in the poly search phase of 11^202+8^202, c122 cofactor)

xilman · 2011-06-24, 15:26

Quote:

Originally Posted by Andi47

Seems to work now (currently in the poly search phase of 11^202+8^202, c122 cofactor)

Phew!

It's only incompetence which saved me from having to disappoint you on this one. I thought my laptop had finished it about an hour ago but have just discovered that the c129 from 12-7,215 has been done instead.

Paul

Andi47 · 2011-06-24, 16:44

Quote:

Originally Posted by xilman

Phew!

It's only incompetence which saved me from having to disappoint you on this one. I thought my laptop had finished it about an hour ago but have just discovered that the c129 from 12-7,215 has been done instead.

Paul

Phew! Do you reserve the numbers you do at http://www.chiark.greenend.org.uk/uc...mack/homcun.pl ?

When I chose a homogeneous cunningham number to factor I look at this site first, and there I saw that 11,8,202+ was free, so I took (and reserved) it.

xilman · 2011-06-24, 16:57

Quote:

Originally Posted by Andi47

Phew! Do you reserve the numbers you do at http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl ?

When I chose a homogeneous cunningham number to factor I look at this site first, and there I saw that 11,8,202+ was free, so I took (and reserved) it.

I should do, but forgot on this occasion. Mea culpa.

In previous cases like this my procedure has been to ignore my factorization for reporting purposes and give credit to the person who reserved it correctly.

Paul

Andi47 · 2011-06-25, 07:02

Quote:

Originally Posted by Andi47

Seems to work now (currently in the poly search phase of 11^202+8^202, c122 cofactor)

done:
prp55 factor: 1296412830004084343004709487569988508453116368634023229
prp67 factor: 8724681460871729101591387153866541424385233604852729111953320015973

Mail to Paul is out.

fivemack · 2011-06-26, 19:07

Is there any way that I can get the timeout for sieving in stage 1 of polynomial selection to be measured in CPU-seconds rather than in realtime seconds? I would like to be able to have a polynomial-selection job running with 'nice -19 make -j 48' while I do sieving jobs at nice 0 on my large machine, and at present this appears to mean I get very few hits because about one CPU-second elapses per minute of realtime.

jrk · 2011-06-26, 20:03

I agree, it should be using CPU time instead of walltime (but GPU will still use walltime as before). I was meaning to change that at one point but forgot about it. Check again later in the week.

2011-06-26, 19:07	#21
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 7²×131 Posts	Is there any way that I can get the timeout for sieving in stage 1 of polynomial selection to be measured in CPU-seconds rather than in realtime seconds? I would like to be able to have a polynomial-selection job running with 'nice -19 make -j 48' while I do sieving jobs at nice 0 on my large machine, and at present this appears to mean I get very few hits because about one CPU-second elapses per minute of realtime. Last fiddled with by fivemack on 2011-06-26 at 19:10

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Msieve 1.53 feedback	xilman	Msieve	149	2018-11-12 06:37
Msieve 1.50 feedback	firejuggler	Msieve	99	2013-02-17 11:53
Msieve 1.43 feedback	Jeff Gilchrist	Msieve	47	2009-11-24 15:53
Msieve 1.42 feedback	Andi47	Msieve	167	2009-10-18 19:37
Msieve 1.41 Feedback	Batalov	Msieve	130	2009-06-09 16:01

2011-06-22, 20:49	#13
jasonp Tribal Bullet Oct 2004 3,541 Posts	If you're doing NFS postprocessing, you don't even need a 'N' line in the relation file, and any such lines are ignored. Right now whether relations are compressed or not is determined at compile time; if compiled with zlib, the library checks whether the beginning of the relation file is a recognizable zlib header, but only for reading relations. When compiled with compression, relations should always be written in compressed format IIRC. You don't really want to use the line sieve anyway :)

2011-06-23, 02:22	#14
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	With NO_ZLIB=1, there's no way for the binary to write the compressed output (it simply isn't equipped)! With zlib, in msieve, reading is done from either compressed or uncompressed file, writing to a new file never happens, and appending to an existing file honors and preserves its state - either compressed or uncompressed. ________ Nobody line sieves! ...and even if they do, the perl script must have already created a file with "N ...." in it, by tradition. (An optionally modified perl script may have gzipped it, too; no harm in that. A further modified perl script may spawn sievers with -z option and concatenate them to the gzipped .dat file, too.) Don't know what the python script does. Then read on what happens while appending to an existing file.

2011-06-23, 16:48	#15
chris2be8 Sep 2009 2078₁₀ Posts	In my experience line sieving is faster than lattice sieving very near the origin, but quickly slows down. So it's only worth doing a small range. The existing perl script does a small range on the master system, but only uses one thread for it. What I am trying to do is to allow the use to choose which system does the line sieving, they get best overall throughput if it's done on a single core system that can't run the 64bit lattice siever. I'll probably put a "N " line into the line sieving output file. The worst that can do is generate a "error -n reading relation m" message. Chris K

2011-06-26, 20:03	#22
jrk May 2008 3×5×73 Posts	I agree, it should be using CPU time instead of walltime (but GPU will still use walltime as before). I was meaning to change that at one point but forgot about it. Check again later in the week.