Msieve v1.49 feedback - Page 5

fivemack · 2011-07-01, 20:39

I am not quite sure what sleigher is trying to do; the MPI code is used only when doing linear algebra, and the CUDA only when doing polynomial search, so it's easier just to make two executables and use one for one job and one for the other.

jasonp · 2011-07-01, 23:30

Removing the calls won't make it work better; in fact the opposite might happen :)

My guess is that your CUDA driver is not compatible with your CUDA toolkit. Isn't the v260 driver a little old?

bsquared · 2011-08-11, 19:34

Quote:

Originally Posted by jrk

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.

This one was reported to me:

Code:

Msieve v. 1.49 (SVN unknown)
Thu Aug 11 14:28:59 2011
random seeds: 2a1dbf04 d7575cc3
factoring 231385094471198973611 (21 digits)
error: tiny factoring failed
elapsed time 00:00:00

Using SVN 590 for tinyqs.c.

jrk · 2011-08-11, 19:44

Quote:

Originally Posted by bsquared

This one was reported to me:

Code:

Msieve v. 1.49 (SVN unknown)
Thu Aug 11 14:28:59 2011
random seeds: 2a1dbf04 d7575cc3
factoring 231385094471198973611 (21 digits)
error: tiny factoring failed
elapsed time 00:00:00

Using SVN 590 for tinyqs.c.

It worked when I tried it.

Code:

Msieve v. 1.49 (SVN 590)
Thu Aug 11 14:50:36 2011
random seeds: 7a4fdbbc 8baa4cf7
factoring 231385094471198973611 (21 digits)
prp11 factor: 12727196477
prp11 factor: 18180366343
elapsed time 00:00:00

bsquared · 2011-08-11, 19:57

Quote:

Originally Posted by jrk

It worked when I tried it.

You're right... I compiled svn 590 as msieve.exe, but ran the pre-compiled msieve149.exe instead.

All is well.

Has the pre-compiled executable been updated since you fixed this? The one I have is old, evidently.

jasonp · 2011-09-12, 00:19

Just reporting that two large patchsets have been committed to the trunk: one replaces most of the multiple precision computations in the NFS code with calls to GMP, and the other (by Ilya Popovyan) makes MPI linear algebra noticeably more efficient.

There shouldn't be any user-visible effects, but these changes have only undergone light testing so bear that in mind if you're working with the latest and greatest SVN.

debrouxl · 2011-09-13, 14:27

Following up on one of my posts from February ( http://www.mersenneforum.org/showpos...9&postcount=33 )...

On the same computer as last time, an Athlon II X4 640, msieve SVN r637 is currently running CPU-based polynomial selection for the remaining C169 of near-repdigit http://hpcgi2.nifty.com/m_kamada/f/c.cgi?q=59999_273 .
I'm using -np1 on one core, and -np2 on another one, the way described by chris2be8 in the post above the one I linked.

After ~92h of CPU time in -np1 + ~15h of CPU time in -np2:
* ~87000 polynomials have been produced, i.e. nearly 4 times what the older version of msieve produced on the smaller C164 in an amount of time only a bit shorter

* the Murphy E scores range from ~2.2e-13 to ~4.3e-13. The ten best polys are:

Code:

# norm 1.818813e-16 alpha -5.773526 e 3.990e-13 rroots 3
# norm 1.827934e-16 alpha -6.595224 e 4.064e-13 rroots 1
# norm 1.833617e-16 alpha -6.446252 e 4.088e-13 rroots 3
# norm 1.876208e-16 alpha -6.006629 e 4.085e-13 rroots 1
# norm 1.894178e-16 alpha -6.848736 e 4.153e-13 rroots 3
# norm 1.894776e-16 alpha -6.225171 e 4.132e-13 rroots 1
# norm 1.913479e-16 alpha -7.553749 e 4.177e-13 rroots 3
# norm 1.921743e-16 alpha -6.107337 e 4.152e-13 rroots 1
# norm 1.985599e-16 alpha -6.814028 e 4.308e-13 rroots 3
# norm 2.027453e-16 alpha -6.666779 e 4.347e-13 rroots 3

* as happened with the C164, ~98% of the polynomials are not very good, and more than three quarters of the polynomials wouldn't make the cut if the lower bound for the score was only ~20% higher

Code:

$ grep " e " msieve.dat.p | wc -l
87310
$ grep -e " e 2.[12345]" msieve.dat.p | wc -l
69099
$ grep " e 2." msieve.dat.p | wc -l
85578
$ grep " e 3." msieve.dat.p | wc -l
1721
$ grep " e 4." msieve.dat.p | wc -l
11

debrouxl · 2011-09-18, 07:28

A power outage interrupted the polynomial selection for 59999_273 around ~200h of CPU time in -np1 + probably ~30-35h in -np2. I don't plan on restarting it where it died.
Final breakdown of the e values:

Code:

$ grep " e " msieve.dat.p | wc -l
191362
$ grep " e 2." msieve.dat.p | wc -l
187461
$ grep -e " e 2.[12345]" msieve.dat.p | wc -l
153673
$ grep " e 3." msieve.dat.p | wc -l
3887
$ grep " e 4." msieve.dat.p | wc -l
14

The three polynomials with highest e value are:

Code:

# norm 1.985599e-16 alpha -6.814028 e 4.308e-13 rroots 3
# norm 2.027453e-16 alpha -6.666779 e 4.347e-13 rroots 3
# norm 2.073765e-16 alpha -8.738431 e 4.326e-13 rroots 5

The newer version of msieve produced more polynomials on a more difficult number, good job

I have uploaded the msieve.dat.p (bzip2-ed, ~17.3 MB) file at http://www.sendspace.com/file/jkacpx . As a user, only the three best polynomials or so matter to me, but maybe maintainers will be able to extract useful information from the whole set.

chris2be8 · 2011-09-18, 15:57

Quote:

Originally Posted by debrouxl

I'm using -np1 on one core, and -np2 on another one, the way described by chris2be8 in the post above the one I linked.

I don't recommend that technique any more. You would do better with factMsieve.pl from http://mersenneforum.org/showthread.php?t=15662 which splits the search evenly across all cores.

Chris K

debrouxl · 2011-09-18, 17:27

Thanks for the reminder

However, this time, during most of the search, two cores were running other normal-priority tasks, and I needed to keep one core free (most of the time) for low-priority tasks... so -np1 on one core, and -np2 on another one, was about the best I could do

Jeff Gilchrist · 2011-09-26, 12:18

I have found what I think is a strange behaviour with the latest SVN that we have been using the for RSA-768 -np2 process.

If I run msieve on one of the files to boil down using -np2, and it happens to find some hits, then run it again on another file, it exits immediately without any kind of warning. It took me a while to figure out what was going on that an msieve.fb file was created.

I have to delete that msieve.fb file before it will let me do another -np2 in the same directory. Is there a particular reason for that? If yes, could you at least print a warning of some kind so that we will know that we made such a mistake?

Thanks,
Jeff.

2011-09-13, 14:27	#51
debrouxl Sep 2009 977 Posts	Following up on one of my posts from February ( http://www.mersenneforum.org/showpos...9&postcount=33 )... On the same computer as last time, an Athlon II X4 640, msieve SVN r637 is currently running CPU-based polynomial selection for the remaining C169 of near-repdigit http://hpcgi2.nifty.com/m_kamada/f/c.cgi?q=59999_273 . I'm using -np1 on one core, and -np2 on another one, the way described by chris2be8 in the post above the one I linked. After ~92h of CPU time in -np1 + ~15h of CPU time in -np2: * ~87000 polynomials have been produced, i.e. nearly 4 times what the older version of msieve produced on the smaller C164 in an amount of time only a bit shorter * the Murphy E scores range from ~2.2e-13 to ~4.3e-13. The ten best polys are: Code: # norm 1.818813e-16 alpha -5.773526 e 3.990e-13 rroots 3 # norm 1.827934e-16 alpha -6.595224 e 4.064e-13 rroots 1 # norm 1.833617e-16 alpha -6.446252 e 4.088e-13 rroots 3 # norm 1.876208e-16 alpha -6.006629 e 4.085e-13 rroots 1 # norm 1.894178e-16 alpha -6.848736 e 4.153e-13 rroots 3 # norm 1.894776e-16 alpha -6.225171 e 4.132e-13 rroots 1 # norm 1.913479e-16 alpha -7.553749 e 4.177e-13 rroots 3 # norm 1.921743e-16 alpha -6.107337 e 4.152e-13 rroots 1 # norm 1.985599e-16 alpha -6.814028 e 4.308e-13 rroots 3 # norm 2.027453e-16 alpha -6.666779 e 4.347e-13 rroots 3 * as happened with the C164, ~98% of the polynomials are not very good, and more than three quarters of the polynomials wouldn't make the cut if the lower bound for the score was only ~20% higher Code: $ grep " e " msieve.dat.p \| wc -l 87310 $ grep -e " e 2.[12345]" msieve.dat.p \| wc -l 69099 $ grep " e 2." msieve.dat.p \| wc -l 85578 $ grep " e 3." msieve.dat.p \| wc -l 1721 $ grep " e 4." msieve.dat.p \| wc -l 11 Last fiddled with by debrouxl on 2011-09-13 at 14:29

2011-09-18, 07:28	#52
debrouxl Sep 2009 977 Posts	A power outage interrupted the polynomial selection for 59999_273 around ~200h of CPU time in -np1 + probably ~30-35h in -np2. I don't plan on restarting it where it died. Final breakdown of the e values: Code: $ grep " e " msieve.dat.p \| wc -l 191362 $ grep " e 2." msieve.dat.p \| wc -l 187461 $ grep -e " e 2.[12345]" msieve.dat.p \| wc -l 153673 $ grep " e 3." msieve.dat.p \| wc -l 3887 $ grep " e 4." msieve.dat.p \| wc -l 14 The three polynomials with highest e value are: Code: # norm 1.985599e-16 alpha -6.814028 e 4.308e-13 rroots 3 # norm 2.027453e-16 alpha -6.666779 e 4.347e-13 rroots 3 # norm 2.073765e-16 alpha -8.738431 e 4.326e-13 rroots 5 The newer version of msieve produced more polynomials on a more difficult number, good job I have uploaded the msieve.dat.p (bzip2-ed, ~17.3 MB) file at http://www.sendspace.com/file/jkacpx . As a user, only the three best polynomials or so matter to me, but maybe maintainers will be able to extract useful information from the whole set.

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-07-01, 20:39	#45
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 7²·131 Posts	I am not quite sure what sleigher is trying to do; the MPI code is used only when doing linear algebra, and the CUDA only when doing polynomial search, so it's easier just to make two executables and use one for one job and one for the other.

2011-07-01, 23:30	#46
jasonp Tribal Bullet Oct 2004 3,541 Posts	Removing the calls won't make it work better; in fact the opposite might happen :) My guess is that your CUDA driver is not compatible with your CUDA toolkit. Isn't the v260 driver a little old?

2011-09-12, 00:19	#50
jasonp Tribal Bullet Oct 2004 DD5₁₆ Posts	Just reporting that two large patchsets have been committed to the trunk: one replaces most of the multiple precision computations in the NFS code with calls to GMP, and the other (by Ilya Popovyan) makes MPI linear algebra noticeably more efficient. There shouldn't be any user-visible effects, but these changes have only undergone light testing so bear that in mind if you're working with the latest and greatest SVN.

2011-09-18, 17:27	#54
debrouxl Sep 2009 977 Posts	Thanks for the reminder However, this time, during most of the search, two cores were running other normal-priority tasks, and I needed to keep one core free (most of the time) for low-priority tasks... so -np1 on one core, and -np2 on another one, was about the best I could do

2011-09-26, 12:18	#55
Jeff Gilchrist Jun 2003 Ottawa, Canada 3×17×23 Posts	I have found what I think is a strange behaviour with the latest SVN that we have been using the for RSA-768 -np2 process. If I run msieve on one of the files to boil down using -np2, and it happens to find some hits, then run it again on another file, it exits immediately without any kind of warning. It took me a while to figure out what was going on that an msieve.fb file was created. I have to delete that msieve.fb file before it will let me do another -np2 in the same directory. Is there a particular reason for that? If yes, could you at least print a warning of some kind so that we will know that we made such a mistake? Thanks, Jeff.