64-bit gnfs-lasieve*

[henryzz]

Originally Posted by Batalov

According to Greg (and me, I guess, from limited experience) - there should be hardly any difference. (Optimization of the C glue code is not significant, but the assembly code is common.)

These binaries run great on Core2 (I've run them myself, too - under ubuntu and the speed was great; but most of the time my that computer is in Windows mode for the kid's homework use) and on K8/K10 alike.

brilliant
i have completed a small factorization with them and was impressed by their speed

[Joshua2]

so is there a windows x64 optimized siever for core2? can someone link me the best binary to use? is linux still much faster?

[frmky]

Originally Posted by Joshua2

so is there a windows x64 optimized siever for core2? can someone link me the best binary to use? is linux still much faster?

No. I'm not an ASM guy, but I'm told calling conventions are different and a lot of ASM would need significant modification. The speedy 64-bit code is Linux only right now.

[Jeff Gilchrist]

Originally Posted by Joshua2

so is there a windows x64 optimized siever for core2? can someone link me the best binary to use? is linux still much faster?

You could always get Virtual Box, install 64bit Linux and run that inside Windows to sieve.

Jeff.

[cjohnsto]

Originally Posted by frmky

No. I'm not an ASM guy, but I'm told calling conventions are different and a lot of ASM would need significant modification. The speedy 64-bit code is Linux only right now.

The calling conventions are quite different, however most of the time it is pretty trivial to convert between the two conventions. I have found the interesting differences in the conventions don't apply that often.

In the past I have used a simple ifdef in my assembler at the start and end of the function to convert the input and results.
This method works well if there is one function that takes most of the computation time.

[Jeff Gilchrist]

Originally Posted by cjohnsto

The calling conventions are quite different, however most of the time it is pretty trivial to convert between the two conventions. I have found the interesting differences in the conventions don't apply that often.

Does that mean you are volunteering to convert the code to work in Windows then?

[cjohnsto]

Originally Posted by Jeff Gilchrist

Does that mean you are volunteering to convert the code to work in Windows then?

If you point me at a copy of the code with some build instructions for Windows I can take a look.

[Jeff Gilchrist]

Originally Posted by cjohnsto

If you point me at a copy of the code with some build instructions for Windows I can take a look.

The main source tree is in SVN trunk here:
http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/

The experimental 64bit sieving code you would need to translate is here:
http://ggnfs.svn.sourceforge.net/vie...l/lasieve4_64/

The windows VS2008 project and code is here:
http://ggnfs.svn.sourceforge.net/vie.../build.vc/vc9/

Specially load ggnfs.sln and build the solutions to get the regular 64bit code compiled, you would have to add a new project for your translated 64bit sieving code.

[cjohnsto]

I haven't disappeared. I'm having trouble with getting GMP to build for Windows.
I'm thinking I might just do the conversions blind (without building/testing) and pass them back to for someone to build, test and make small fixes.

[ltd]

Instead of GMP you can use the mpir package.

http://www.mpir.org/

This comes also with Visual Studio solutions.

[chris2be8]

Having finally got the experimental version to run on one of my systems I've benchmarked it against the C version.

64 bit assembler version yielded 340020 relations in 01:02:31
The C version yielded 340026 relations in 01:54:17

ie 1.828 times as fast. Nice.

Both with the following poly sieved from q=2750000 to q=2850000

n: 15200438395829673822887270747334456300081381814070181365670614122000527807575298698572727198863263298646427259781616606952751
skew: 149765.83
# norm 3.27e+17
c5: 34200
c4: -47685613354
c3: 173727493738605
c2: 708460243134031910960
c1: -19147218280457427952169760
c0: -2082763077173939661276956379976
# alpha -6.97
Y1: 13931002448209
Y0: -850291789984003411307205
# Murphy_E 1.61e-10
# M 10722983998325608485314324921895133003712347944750948590020548179373615865209960488935822420329521367862576842656966919610242
type: gnfs
rlim: 5500000
alim: 5500000
lpbr: 27
lpba: 27
mfbr: 53
mfba: 53
rlambda: 2.5
alambda: 2.5
qintsize: 100000

Has anyone any suggestions as to what to change polySelTimeMultiplier to? At the default it spends too long searching for polynomials related to the now shortened sieving time. But what should I reduce it by?

Chris K