mersenneforum.org lpb34
 Register FAQ Search Today's Posts Mark Forums Read

2017-05-10, 15:08   #1
wreck

"Bo Chen"
Oct 2005
Wuhan,China

163 Posts
lpb34

This post is aimed to share some information that
I collected for lpbr/lpba 34.

Background:
I am considering the possible of factoring 10^323-1.
I am not sure whether msieve could tackle lpbr=34.
I know NFS@home do some large numbers
6,490+ gnfs212, 0.18 rel/q, 2000M -a and 1600M -r
3,766+ gnfs216, 0.25 rel/q, 2700M -a
2,1285- gnfs218, 0.05 rel/q, 5000M -a and 5000M -r
3,697+ gnfs221, 0.19 rel/q, 6000M -a
These numbers are seems both use lpbr=33,
because from the logs, I see the unique relations
The rel/q seems a little low, from the past sieve
experience, it is better near 2.
So could you confirm me , is there exist any
principle obstacle of msieve to do the matrix
when using lpbr=lpba=34 after collect enough
relations?

Response from jasonp:
Msieve can handle relations with any number of large primes up to 2^48.
The more serious issue is that there is a bug in the filtering that makes
it very difficult to find a matrix when starting with more than ~800M relations,
which a job with lpb=34 will definitely need.

Test with 10^71-1:
As a factorization with lpbr/lpba 34, I ask Kurt to give
a try with R71, using the following polynomial,
Code:
n: 11111111111111111111111111111111111111111111111111111111111111111111111
# 10^71-1, difficulty: 72.00, skewness: 1.47, alpha: 0.00
# cost: 6.36983e+010, est. time: 0.00 GHz days (not accurate yet!)
skew: 1.468
c6: 1
c0: -10
Y1: -1
Y0: 1000000000000
m: 1000000000000
type: snfs
rlim: 100000000
alim: 100000000
lpbr: 34
lpba: 34
mfbr: 68
mfba: 68
rlambda: 2.6
alambda: 2.6
After ONLY collect 364M relations, the factors pop out successfully,
so I think if we want to triggger the 800M issue, we have to select
some other larger numbers. The post-processing log is attached.

Also, there are numbers such as E148 (804M gnfs202),
11,671M (851M gnfs202), 2,1019+ (805M snfs307),
10,302+ (856M snfs302), etc. use more than 800M unique relations
to finish the factorization successfully. So I am not sure whether the
800M issue is still exist.
Attached Files
 r71.log (67.3 KB, 84 views)

 2017-05-10, 17:21 #2 VBCurtis     "Curtis" Feb 2005 Riverside, CA 10010000000002 Posts Don't let the msieve filtering bug stand in the way of trying 34LP; if the bug strikes you, you can use CADO for the postprocessing steps. NFS@home has stuck with 33LP because the sievers they distributed for BOINC are limited to 33-bit large primes (though perhaps the 16f siever is not, but I don't think that one is commonly used).
2017-05-10, 20:02   #3
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2·2,897 Posts

Quote:
 Originally Posted by VBCurtis Don't let the msieve filtering bug stand in the way of trying 34LP; if the bug strikes you, you can use CADO for the postprocessing steps. NFS@home has stuck with 33LP because the sievers they distributed for BOINC are limited to 33-bit large primes (though perhaps the 16f siever is not, but I don't think that one is commonly used).
It is just a case of commenting one line and recompiling.

 2017-10-18, 04:34 #4 VBCurtis     "Curtis" Feb 2005 Riverside, CA 10010000000002 Posts I've never had success compiling GGNFS; could anyone post links to the 34-bit-enabled linux sievers? Also, are binaries available for 16f, windows or linux or both? Henry once sent me 16e for windows with 33LP removed, and I still have that. Swellman included me in a test-sieve effort in support of a RyanP endeavor, and I want to explore parameters beyond 33LP/96mfbr. Do I recall correctly that 16f V5 does not have the 96 bit mfbr limit? I also have an inkling that 15e/34 might not be foolish; if compilation produces both 15e and 16e sievers, I would appreciate a 15e binary without the 33LP limit too.
 2017-10-20, 02:21 #5 VBCurtis     "Curtis" Feb 2005 Riverside, CA 460810 Posts I found the version 5 siever in this post: http://mersenneforum.org/showpost.ph...2&postcount=60 I also found a set of v5 sievers in a backup folder from 2013, so I'm using those at present rather than the ones linked above. I do not have linux sievers of any version with 33LP limit removed. If anyone has those handy, please post 'em here!
2017-10-23, 18:28   #6
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2×2,897 Posts

I have attached all the 5e sievers compiled under Bash on Windows. I believe these should work on Linux. The f variant is proving troublesome. I think I might need to spend a Saturday on it on real Linux(probably a virtual machine).
Attached Files
 lasieve 5e.7z (957.3 KB, 76 views)

 2017-10-23, 18:53 #7 pinhodecarlos     "Carlos Pinho" Oct 2011 Milton Keynes, UK 37×131 Posts I should have all binaries used at NFS@Home, is this of interest?
2017-10-23, 19:41   #8
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2·2,897 Posts

Quote:
 Originally Posted by pinhodecarlos I should have all binaries used at NFS@Home, is this of interest?
I think those binaries have been boincified.

 2017-10-23, 21:50 #9 VBCurtis     "Curtis" Feb 2005 Riverside, CA 29·32 Posts I am interested in the 16f used at NFS@home, not BOINCified. I found Greg's compilation instructions, but am presently hiding behind "GGNFS has never compiled for me, I don't want to fight it again," but I haven't tried his instructions so I can't really say I can't get them. If I do get 'em working this weekend, I'll surely let the forum know!
2017-10-23, 23:32   #10
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

10110101000102 Posts

I have managed to compile the f variant. This version has the option -d which is the number of divisors of the special q. When run with -d 1 it matches the e variant. However, the f variant is able to sieve below the fb bound.

Let me know if there are any issues. I managed to compile the g variant although it hasn't been ggnfsified.
Attached Files
 lasieve_5f.7z (366.9 KB, 79 views)

2017-10-24, 00:26   #11
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

110008 Posts

Quote:
 Originally Posted by henryzz I have managed to compile the f variant. This version has the option -d which is the number of divisors of the special q. When run with -d 1 it matches the e variant. However, the f variant is able to sieve below the fb bound. Let me know if there are any issues. I managed to compile the g variant although it hasn't been ggnfsified.
-d 1 is exactly the flag I was looking for to force 16f to sieve only prime special Q. Thank you!! I believe 16f with -d 1 is more effective on special Q below fb bound, with no downside.
I'll test these on linux tomorrow; I believe a 13f or 14f using -d 1 is faster than respective e versions when sieving special Q below the fb bound.