Running GGNFS

[10metreh]

The version of msieve in Jeff's svn337 compile (I don't know about more recent ones) only included msieve 1.38. It is therefore possible that the surce did not include msieve 1.39. If you don't have access to 1.39, try using pol51 instead. If you want, I'll run a poly search for you with 1.39.

[Jeff Gilchrist]

Originally Posted by 10metreh

The version of msieve in Jeff's svn337 compile (I don't know about more recent ones) only included msieve 1.38. It is therefore possible that the surce did not include msieve 1.39. If you don't have access to 1.39, try using pol51 instead. If you want, I'll run a poly search for you with 1.39.

That is correct, msieve is bundled and the code built with the ggnfs package but it is only v1.38 as you state. If you want the latest version you need to download and install it as pointed out in the beginners guide.

mdettweiler: In the beginners guide I explicitly say as one of the steps you need to download the latest msieve and install it over top of what is in the GGNFS directory. The guide also walks you through using factMsieve.pl so you don't have to figure out command line options. Is there something in the wording I can improve to better get this point across or were you just skimming the instructions and not following each step?

Jeff.

[mdettweiler]

Originally Posted by Jeff Gilchrist

That is correct, msieve is bundled and the code built with the ggnfs package but it is only v1.38 as you state. If you want the latest version you need to download and install it as pointed out in the beginners guide.

mdettweiler: In the beginners guide I explicitly say as one of the steps you need to download the latest msieve and install it over top of what is in the GGNFS directory. The guide also walks you through using factMsieve.pl so you don't have to figure out command line options. Is there something in the wording I can improve to better get this point across or were you just skimming the instructions and not following each step?

Jeff.

Holy cow! I just checked my msieve binary and it turns out I'm using version 1.34! And all this time I thought I was using 1.39!

Looks like I definitely need to download the latest version from the msieve web site. I'm not sure exactly where I got the version I'm using right now.

BTW, thanks guys for all the help--right now I've got gnfs-lasieve4I12e cranking away on the aforedescribed polynomial and all seems to be well. I'll aim for just under 5 million relations as schickel suggested, and meanwhile, I'll go and download the latest version of msieve.

[jasonp]

Note also that the msieve source in the GGNFS repository is

- current only up to v1.38 (v1.39 added a huge number of small changes that I have not had the time to backport)

- does not contain any poly selection code or other algorithms, only the NFS line sieve and NFS postprocessing. The poly selection is a large amount of code, relies on a large amount of support code that is not used elsewhere in the library, and is currently under (furious) development

[10metreh]

Originally Posted by mdettweiler

Holy cow! I just checked my msieve binary and it turns out I'm using version 1.34! And all this time I thought I was using 1.39!

Looks like I definitely need to download the latest version from the msieve web site. I'm not sure exactly where I got the version I'm using right now.

BTW, thanks guys for all the help--right now I've got gnfs-lasieve4I12e cranking away on the aforedescribed polynomial and all seems to be well. I'll aim for just under 5 million relations as schickel suggested, and meanwhile, I'll go and download the latest version of msieve.

Do you still want to use this poly, or do you want to use a poly from 1.39? If so, I'll save you the trouble (of the poly search, that is).

BTW, how is 175182 going?

[mdettweiler]

Originally Posted by 10metreh

Do you still want to use this poly, or do you want to use a poly from 1.39? If so, I'll save you the trouble (of the poly search, that is).

BTW, how is 175182 going?

I think I'll stick with this polynomial, since I've already started sieving and have collected about 800,000 relations. Thanks for the offer, though.

Regarding 175182: so far, so good. I'd had it on a short hiatus while I did some other work, and am just now restarting it. The C107 I'm currently sieving is from line #992. Once I've completed a few more lines I'll probably post a full update in the Aliquot Sequences thread.

Edit: I just realized why I was using a 1.34 binary instead of 1.39. That's because 1.34 was the latest 32-bit Linux precompiled binary I'd come across. I just went to the msieve web site to download 1.39, and realized that I'd have to compile 1.39 myself since only a Windows binary is provided for download. So, I figured before I go through the trouble of compiling one myself, I'd ask if anyone else has a 32-bit Linux binary of msieve v1.39 hanging around. If so, I'd rather use that than compile one from scratch.

[henryzz]

i haven't but would be willing to compile one tomorrow if no one has one

[mdettweiler]

Originally Posted by henryzz

i haven't but would be willing to compile one tomorrow if no one has one

Thanks for the offer! It would be greatly appreciated.

In the meantime, I've downloaded the Windows 32-bit binary of 1.39. It seems to run pretty well through Wine. I haven't done any formal speed tests, but from what I'm seeing it seems to be running essentially the same speed as it would natively. (It's possible that there's a slight speed difference, but if there is it's probably quite small.)

Earlier I successfully completed factorization of the aforementioned C107 and have now proceeded to the next line of Aliquot Sequence 175182, which after ECM leaves a C100 cofactor to be GNFS'ed. I'm now trying out the Windows 1.39 binary through Wine for polynomial selection.

[henryzz]

when i try to compile i get the following error:

david@Ubuntu8Jimmy:~/Desktop/msieve-1.39$ make x86 ECM=1
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/lanczos/lanczos.o common/lanczos/lanczos.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/lanczos/lanczos_matmul0.o common/lanczos/lanczos_matmul0.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/lanczos/lanczos_matmul1.o common/lanczos/lanczos_matmul1.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/lanczos/lanczos_matmul2.o common/lanczos/lanczos_matmul2.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/lanczos/lanczos_pre.o common/lanczos/lanczos_pre.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/smallfact/gmp_ecm.o common/smallfact/gmp_ecm.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/smallfact/smallfact.o common/smallfact/smallfact.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/smallfact/squfof.o common/smallfact/squfof.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/smallfact/tinyqs.o common/smallfact/tinyqs.c
gcc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=athlon-xp -DNDEBUG  -Wall -W -Wconversion -Iinclude -Ignfs/poly -DHAVE_GMP_ECM -DHAVE_GMP -c -o common/ap.o common/ap.c
common/ap.c: In function ‘ap_mul’:
common/ap.c:339: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
common/ap.c:339: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
common/ap.c:339: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
common/ap.c:339: error: ‘asm’ operand has impossible constraints
common/ap.c:339: error: ‘asm’ operand has impossible constraints
common/ap.c:339: error: ‘asm’ operand has impossible constraints
common/ap.c:339: error: ‘asm’ operand has impossible constraints
make: *** [common/ap.o] Error 1

any ideas jasonp?

[jasonp]

That code did change in v1.39 but it doesn't cause problems in MinGW for me. Could you run 'gcc -v' and 'uname -a' ?

[akruppa]

        ASM_G(
            "negl %0                    \n\t"
            "jz 1f                      \n\t"
            "0:                         \n\t"
            "movl (%2,%0,4), %%eax      \n\t"
            "mull %4                    \n\t"
            "addl %1, %%eax             \n\t"
            "adcl $0, %%edx             \n\t"
            "addl %%eax, (%3,%0,4)      \n\t"
            "movl %%edx, %1             \n\t"
            "adcl $0, %1                \n\t"
            "incl %0                    \n\t"
            "jnz 0b                     \n\t"
            "1:                         \n\t"
            : "+r"(tmp), "+r"(carry)   
            : "r"(a + awords), "r"(x + awords), "g"(b)
            : "%eax", "%edx", "cc", "memory");

I had a brief look at the code and it seems like there may be a problem with gcc allocating registers as input that get overwritten, i.e. %eax and %edx. I doubt this is the reason for the problem henryzz posted, though.

With %eax and %rax in the clobbered list, gcc sees no reason why it shouldn't use them as inputs, all it knows is that their value may have changed after the asm block. The only way I know to prevent gcc from passing in parameters to asm blocks in registers that get overwritten early is the make those registers output of the asm block (to a dummy variable) and marking that output register "earlyclobber", i.e. using the "&" constraint.

As mentioned, I don't think this causes the problem henryzz reported, but it might be worth fixing or a hard-to-debug incorrect multiplication result may occur some time in the future with a particular architecture/gcc version/optimization level combination.

Alex