Msieve v1.49 feedback - Page 3

jrk · 2011-06-28, 05:01

Please try it now.

When doing polynomial search, the program should now apply only the actual CPU time used against the deadline. (For the CUDA version, the time elapsed in the GPU kernel calls will be applied as well.)

Jeff Gilchrist · 2011-06-28, 15:56

I'm not sure if anyone is interested in fixing a bug for small factors failing such as reported here: http://www.mersenneforum.org/showpos...6&postcount=28

The bug is still present in v1.49:

Code:

Msieve v. 1.49 (SVN unknown)
Tue Jun 28 11:53:37 2011
random seeds: 8396e0d8 8439d574
factoring 30341442928592512281446689 (26 digits)
error: tiny factoring failed
elapsed time 00:00:00


Msieve v. 1.49 (SVN unknown)
Tue Jun 28 11:53:37 2011
random seeds: 03177b7d 3e7d7a41
factoring 2711611651034302248235343 (25 digits)
error: tiny factoring failed
elapsed time 00:00:00

This also shows another issue, that the msieve source tarball on sourceforge doesn't have the SVN number tag in them so anyone who compiles it from there won't have that info.

Jason, do you just copy your raw source files when you make the tarball? Maybe you can pull them from SVN so they get tagged properly now that you are reporting this value?

Jeff.

jasonp · 2011-06-28, 16:41

I actually pulled from the respository, built the win32 binaries, then deleted the .svn directories and built the tarball. This means the zip file is half the size, but you don't get SVN info with it.

jrk · 2011-06-28, 18:12

I'm looking at the "tiny factoring failed" bug, and it looks fixable but I need to think about it a bit. There seems to be something wrong with the way the multiplier is handled at the end of the qs routine. I'll try fixing it and post again later.

jrk · 2011-06-28, 19:11

Jeff please try rev 587 and see if you still get the tiny factoring failed errors.

bdodson · 2011-06-28, 20:34

Quote:

Originally Posted by fivemack

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.

Are you still collecting polyn contributions for the prospective(?) c197
gnfs? We have two new C2070's that I'd be interested in comparing
with the old C2050's --- I checked rsa768 polyn enough to see that there's
not enough improvement to match the cpu search-times (definitely not
a factor of two, even). I'd be interested to see that they're at least
producing reasonable reports, as the current primegrid software (tpsieve)
is giving computational errors. -Bruce

fivemack · 2011-06-28, 20:41

I'd certainly still accept contributions to the C197, though I think probably we're at about the point to start sieving ... I have a forty-hours-on-48-cores job lined up to try to figure out which one's the right polynomial. I was rather thrown into confusion by the discovery that a 10%-larger-E polynomial sieved 20% slower, it makes me wonder whether I need to change a load of parameters and re-np2 everything.

(if I'm re-np2ing everything then I certainly might as well take more np1 contributions)

(am I right that the alim and rlim bounds in the Murphy-E computation should be the large-prime bound)

jrk · 2011-06-28, 20:46

Quote:

Originally Posted by jrk

Jeff please try rev 587 and see if you still get the tiny factoring failed errors.

Make that rev 589.

I found that tinyqs still fails occasionally on small inputs where there are few solutions to the matrix, and I made an attempt to fix it by forcing additional sieving when only trivial solutions are found.

Now, out of 4000 test composites I tried, I didn't get a "tiny factoring failed" error.

jrk · 2011-06-28, 20:58

Quote:

Originally Posted by fivemack

(am I right that the alim and rlim bounds in the Murphy-E computation should be the large-prime bound)

I'm not sure. The computation doesn't do anything to take large primes into consideration. Since the count of large primes per relation is limited when you sieve, it is not the same as if you sieved with a factor base with primes up to 2^lpb. A more accurate computation that takes large primes into consideration would be more complicated than what is done now.

jasonp · 2011-06-28, 23:30

Indeed, I think you shouldn't be using Dickman's function if you want to account for just one or just two primes above the factor base. Murphy's derivation of the formulas that you do need made my head hurt.

jrk: thanks a ton for fixing that; it's sad I've been using the same lame excuse about not having the time for at least the last 4 years :)

jrk · 2011-06-29, 03:23

Quote:

Originally Posted by jrk

Make that rev 589.

590 now. I made a small error earlier that would sometimes make the fb bounds too small when a multiplier is used. Fixed again.

Just passed 30000 tinyqs jobs without any more failures.

2011-06-28, 15:56	#24
Jeff Gilchrist Jun 2003 Ottawa, Canada 3·17·23 Posts	I'm not sure if anyone is interested in fixing a bug for small factors failing such as reported here: http://www.mersenneforum.org/showpos...6&postcount=28 The bug is still present in v1.49: Code: Msieve v. 1.49 (SVN unknown) Tue Jun 28 11:53:37 2011 random seeds: 8396e0d8 8439d574 factoring 30341442928592512281446689 (26 digits) error: tiny factoring failed elapsed time 00:00:00 Msieve v. 1.49 (SVN unknown) Tue Jun 28 11:53:37 2011 random seeds: 03177b7d 3e7d7a41 factoring 2711611651034302248235343 (25 digits) error: tiny factoring failed elapsed time 00:00:00 This also shows another issue, that the msieve source tarball on sourceforge doesn't have the SVN number tag in them so anyone who compiles it from there won't have that info. Jason, do you just copy your raw source files when you make the tarball? Maybe you can pull them from SVN so they get tagged properly now that you are reporting this value? Jeff. Last fiddled with by Jeff Gilchrist on 2011-06-28 at 15:56

2011-06-28, 23:30	#32
jasonp Tribal Bullet Oct 2004 3,541 Posts	Indeed, I think you shouldn't be using Dickman's function if you want to account for just one or just two primes above the factor base. Murphy's derivation of the formulas that you do need made my head hurt. jrk: thanks a ton for fixing that; it's sad I've been using the same lame excuse about not having the time for at least the last 4 years :) Last fiddled with by jasonp on 2011-06-28 at 23:31

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-28, 05:01	#23
jrk May 2008 3·5·73 Posts	Please try it now. When doing polynomial search, the program should now apply only the actual CPU time used against the deadline. (For the CUDA version, the time elapsed in the GPU kernel calls will be applied as well.)

2011-06-28, 16:41	#25
jasonp Tribal Bullet Oct 2004 6725₈ Posts	I actually pulled from the respository, built the win32 binaries, then deleted the .svn directories and built the tarball. This means the zip file is half the size, but you don't get SVN info with it.

2011-06-28, 18:12	#26
jrk May 2008 3·5·73 Posts	I'm looking at the "tiny factoring failed" bug, and it looks fixable but I need to think about it a bit. There seems to be something wrong with the way the multiplier is handled at the end of the qs routine. I'll try fixing it and post again later.

2011-06-28, 19:11	#27
jrk May 2008 10001000111₂ Posts	Jeff please try rev 587 and see if you still get the tiny factoring failed errors.

2011-06-28, 20:41	#29
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 1913₁₆ Posts	I'd certainly still accept contributions to the C197, though I think probably we're at about the point to start sieving ... I have a forty-hours-on-48-cores job lined up to try to figure out which one's the right polynomial. I was rather thrown into confusion by the discovery that a 10%-larger-E polynomial sieved 20% slower, it makes me wonder whether I need to change a load of parameters and re-np2 everything. (if I'm re-np2ing everything then I certainly might as well take more np1 contributions) (am I right that the alim and rlim bounds in the Murphy-E computation should be the large-prime bound)