Msieve 1.44 feedback

[xilman]

Originally Posted by jasonp

Bsquared had a similar segfault in the square root, and sent me a GDB trace ages ago. Will look into it soon.

Thanks.

Incidentally, a 32-bit WinXP installation completed the factorization after all the files were transferred there, so it wasn't a data problem.

Another factorization on the affected machine should complete in an hour or two. It will be interesting to see whether this one fails in the same way.

BTW, are you interested in collecting lines like these:

Prototype def-par.txt line would be:
gnfs,122,5,maxs1,maxskew,goodScore,efrac,j0,j1,eStepSize,maxTime,5600000,5600000,27,27,53,53,2.4,2.4,100000

?

If so, I can accumulate them as they appear and mail them to you every now and again.

If not, why do they get printed out? ;-)

Paul

Sqrt failed in the same way Oh well, at least I have a workaround.

[EdH]

msieve 1.44 compiled very cleanly on one of my linux machines (Fedora 11) and seems to be running fine under aliqueit, although I've not extensively tested anything.

I'm working a bootable CD/USB project and am wondering what files I need to keep, if I want to minimize without losing any msieve features. Is the msieve binary self-sufficient or do I need something else?

Thanks for all your work.

Take Care,
Ed

[jasonp]

The non-GPU version is self-contained. The GPU version needs the six .ptx files that are generated at compile time.

[EdH]

Thanks Jason,

Now, sorry to find out, after such great success on one of my linux machines, the other is totally opposite:

[user@id msieve-1.44]$ make x86 ECM=1
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -I. -Iinclude -Ignfs -Ignfs/poly -DHAVE_GMP_ECM -c -o common/filter/clique.o common/filter/clique.c
In file included from include/common.h:19,
                 from common/filter/filter.h:23,
                 from common/filter/filter_priv.h:23,
                 from common/filter/clique.c:15:
include/gmp_xface.h:19:17: error: gmp.h: No such file or directory
In file included from include/common.h:19,
                 from common/filter/filter.h:23,
                 from common/filter/filter_priv.h:23,
                 from common/filter/clique.c:15:
include/gmp_xface.h:32: error: expected declaration specifiers or ‘...’ before ‘mpz_t’
include/gmp_xface.h: In function ‘mp2gmp’:
include/gmp_xface.h:34: warning: implicit declaration of function ‘mpz_import’
include/gmp_xface.h:34: error: ‘dest’ undeclared (first use in this function)
include/gmp_xface.h:34: error: (Each undeclared identifier is reported only once
include/gmp_xface.h:34: error: for each function it appears in.)
include/gmp_xface.h: At top level:
include/gmp_xface.h:39: error: expected ‘)’ before ‘src’
include/gmp_xface.h:50: error: expected declaration specifiers or ‘...’ before ‘mpz_t’
include/gmp_xface.h: In function ‘uint64_2gmp’:
include/gmp_xface.h:57: warning: implicit declaration of function ‘mpz_set_ui’
include/gmp_xface.h:57: error: ‘dest’ undeclared (first use in this function)
include/gmp_xface.h:58: warning: implicit declaration of function ‘mpz_mul_2exp’
include/gmp_xface.h:59: warning: implicit declaration of function ‘mpz_add_ui’
include/gmp_xface.h: At top level:
include/gmp_xface.h:64: error: expected declaration specifiers or ‘...’ before ‘mpz_t’
include/gmp_xface.h: In function ‘int64_2gmp’:
include/gmp_xface.h:67: error: ‘dest’ undeclared (first use in this function)
include/gmp_xface.h:67: error: too many arguments to function ‘uint64_2gmp’
include/gmp_xface.h:68: warning: implicit declaration of function ‘mpz_neg’
include/gmp_xface.h:71: error: too many arguments to function ‘uint64_2gmp’
include/gmp_xface.h: At top level:
include/gmp_xface.h:76: error: expected ‘)’ before ‘src’
include/gmp_xface.h:88: error: expected ‘)’ before ‘src’
make: *** [common/filter/clique.o] Error 1
[user@id msieve-1.44]$

I tried with and without ECM=1 and d/led twice. I will probably just sneaker-net the other msieve to this machine, but any ideas?

This machine is running the same distro as the other, but it has an Intel vs. an AMD CPU.

Take Care,
Ed

[jasonp]

Originally Posted by EdH

include/gmp_xface.h:19:17: error: gmp.h: No such file or directory

Have you installed GMP? If yes, then gcc isn't finding the header file.

[jasonp]

Originally Posted by xilman

If so, I could use the CWI toolkit to complete the factorization. Seems a shame to let the sieving go to waste.

See here (source available too).

Conversion in this direction is easy, you just forget the factors that are small. Conversion in the other direction is much slower, since the small factors have to be rediscovered and you need to communicate the polynomials to the converter somehow.

[Jeff Gilchrist]

FYI, the new msieve 1.44 Windows VS2008 32bit and 64bit CPU binaries are now available:
http://gilchrist.ca/jeff/factoring/

[EdH]

Originally Posted by jasonp

Have you installed GMP? If yes, then gcc isn't finding the header file.

GMP was installed. I added GMP-DEVEL and that solved it.

Thanks.
Ed

[jasonp]

Originally Posted by jasonp

Bsquared had a similar segfault in the square root, and sent me a GDB trace ages ago. Will look into it soon.

Can anyone who has run into this crash in the square root phase and still has the crashing dataset, check out the latest SVN and try again? If you don't use SVN, try changing line 165 of gnfs/sqrt/sqrt_a.c to

		mpz_init_set_ui(tmp[i], (unsigned long)0);

This is one of those unitialized variable bugs that makes me wonder how it worked in the first place.

[jasonp]

FYI: I've completed the first step of a merge between the CPU and GPU poly selection code. This means that with the latest SVN you can search for polynomials for huge NFS inputs, even if you don't have an Nvidia graphics card. The code is still glacially slow, but I'm working on that; I suspect that even with assembly language acceleration a GPU will always be at least 10x faster (it should be 50x faster right now).

But first, many of you have asked for a way to randomize the search space so that multiple machines searching the same range of leading coefficients do not duplicate each other's work. I'll get to that now.

Edit: done; sheesh, like I couldn't spare a half hour in the last few months.

[jrk]

Originally Posted by jasonp

But first, many of you have asked for a way to randomize the search space so that multiple machines searching the same range of leading coefficients do not duplicate each other's work. I'll get to that now.

How do you plan to make that work? By randomizing the p,q subranges like you suggested earlier? I toyed with doing that, but found that on smaller inputs, there was very little room to randomize without throwing away a lot of the valuable search space.

So if the p,q ranges are randomized, it seems that it'd be nice to select a proportion of the search space according to input size. Say, for degree-5 inputs up to 120 digits, make it 1/2 (e.g. throw away only a random half of the space). For 155 digits, 1/8. 180 digits, 1/25, etc. Did you have something like that in mind?

"Search space" from above could be defined as whatever fits nicely within the smallest usable siever (or next-smallest, in the marginal case), given the size of P. There shouldn't be a problem with choosing large-enough ranges to fit within the deadline for the large inputs, but the smaller inputs will be a problem.

Alternatively, instead of choosing the ranges to search at random, individual p and q could be picked at random, but that would create additional overhead on the pre-computation of the values which will be thrown away, so that is no good.