Msieve 1.51 feedback

[jasonp]

Originally Posted by ryanp

commencing number field sieve (299-digit input)
warning: NFS input not found in factor base file
integrator failed nan inf
R0: 0
A0: 0
skew 1.00, size 0.000e+00, alpha 0.000, combined = 0.000e+00 rroots = 0

Does the input number have small factors? These are not allowed for NFS postprocessing, which is what was wrong the last time I saw this happen.

Edit: to be more specific, if the sieving occurred on a different version of N, then that N has to be what's given to the postprocessing. Unfortunately the library is very bad at reporting that problem if it happens.

Chris: ryanp really does have the resources to go after very large jobs like this...

Edit 2: never mind, I found the problem. In include/common.h, change LINE_BUF_SIZE to be larger than 300, then recompile. This is a buffer overflow reading the factor base file.

[sashamkrt]

Originally Posted by chris2be8

@sashamkrt, the search space is far too large for msieve to search it all, it just searches a random subset. So getting different results each time is normal.

I've searched poly for C192(3,664+1) A5 from 0 to 500k, 1 to 1.5m, 11m, 12m, 210m and found several good polys.
The best score I found was ~1.477e-014 with A5=293700 then I tried to found a good poly for this A5 running 20 times
msieve.exe -np1 293700,293701
msieve.exe -nps "stage2_norm=2.0e+26"
msieve.exe -npr "min_evalue=1.0e-14"

and found no good polys at all. Some of them was equal. The best was 1.020e-014.
Now I understand that msieve uses random subset, but the results for the same leading coeff differ so much. I mean there are some probability or luck of finding good poly regardless of the range of leading coefficients.

[jcrombie]

Hi,

I just happened to stumble upon this crash by typing a random number into a worktodo.ini file and running msieve svn 936.

The number:

238472934729347298373323987232349283479273

The crash happens in svn 897 but not svn 896.

It's crashing at common/lanczos/lanczos_vv.c:386

    packed_matrix_t *p = task->matrix;

on the dereference of task which is NULL

Now, task should of been initialized in lanczos_matmul0.c:516

    p->tasks = (la_task_t *)xmalloc(sizeof(la_task_t) *

but the program doesn't actually get there because of an early return at line 436.

    if (max_nrows <= MIN_NROWS_TO_PACK)
        return;

(It does return early as well in svn 896.)

Can someone else confirm the bug?

Thanks.

[jasonp]

Yes, I found this a few days ago in the CUDA branch and never corrected it in the trunk. It will happen for any QS job under about 75 digits.

Edit: both problems now fixed in SVN 938.

[ryanp]

Originally Posted by chris2be8

@ryanp, it sounds as if you are trying to use msieve to do the sieving. Bur it only has a line siever which is nearly useless. You need the GGNFS lattice sievers to do any useful sieving, see http://gilchrist.ca/jeff/factoring/n...ers_guide.html (especially the SNFS section at the bottom).

But to do a SNFS 299 job like that in a year would need NFS@HOME to do the sieving and a large cluster for linear algebra.

It's already sieved, to 720M unique input relations. I just can't understand why msieve is having trouble parsing the input factor base and/or .ini files...

[prgamma10]

@ryanp: Did you try this fix?

Originally Posted by jasonp

Edit 2: never mind, I found the problem. In include/common.h, change LINE_BUF_SIZE to be larger than 300, then recompile. This is a buffer overflow reading the factor base file.

[ryanp]

Originally Posted by prgamma10

@ryanp: Did you try this fix?

Oops, I missed that from earlier. I tried that -- and it worked. Thanks! (to you and jasonp)

[chris2be8]

A comment to anyone reporting problems with msieve, please post the command line used to invoke it as well as the output. It would save (mis)guessing what you are trying to do.

Chris

[VBCurtis]

Originally Posted by sashamkrt

Now I understand that msieve uses random subset, but the results for the same leading coeff differ so much. I mean there are some probability or luck of finding good poly regardless of the range of leading coefficients.

Correct! However, small A5 values produce skews higher than large values, without producing obviously better polys. This higher skew sometimes means having to search more special-q, which sometimes produce more duplicate relations. So, in general, it is not worth your time to search A5 under 1M for composites under 170 digits, and not under 10M for composites over 175 digits. It's not that you'll find bad polys, it's that you are equally likely to find as good a poly at the higher coeff, but with lower skew.

The search is definitely probabilistic, and you should not assume there is a "magic" A5.

[chris2be8]

Another thought, it would be nice if msieve wrote a log message saying what parameters it was called with. It would have saved ryanp from being accidentally dissed by me.

Chris

[Brian Gladman]

Jeff has just posted an updated msieve Windows x64 binary that contains the latest bug fixes: http://gilchrist.ca/jeff/factoring/m...7_win64_i7.zip

This is a non-GPU binary but I am at last in a position to build the GPU version again (at least I will be when I get a new Nvidia card to test it in a a few days time).

Given that MPIR comes in many architecture flavours and GPUs have quite a few different compute capabilities, we will now face a combinatorial explosion in binaries if we continue to deliver statically linked binaries (I have done this in order to avoid forcing people to find and install DLLs).

So I think we may now have to accept that people will have to install an MPIR DLL of their choice in order to use the GPU versions of GMP-ECM and MSIEVE on Windows. Unless, of course, people can think of other ways of coping with all the variations.

Brian