Let's do another nice big GNFS job!

[Batalov]

Originally Posted by bsquared

Yeah, I'm not particularly worried about it either, but any idea why my SVN build produces pathologies and Tom's binary doesn't? Maybe his is 16 bit and its a 15/16 bit thing.

Note also that Tom's binary is statically linked (and we've seen before that this is safer in terms of other bugs as well). static vs dynamic (and the GMP/MPIR lib specific version) could produce a difference here, too.

I will try all reported cases with different builds.
I will not try Ubuntu, though (as you may have seen in other threads, something is fishy there and probably not even in lingmp but in libc or libm).

[bsquared]

Originally Posted by Batalov

Note also that Tom's binary is statically linked ...

How can you tell?

Originally Posted by Batalov

I will try all reported cases with different builds.
I will not try Ubuntu, though (as you may have seen in other threads, something is fishy there and probably not even in lingmp but in libc or libm).

I suspect Tom's build is 16bit (it is apparently too old to self-disclose), and that is the source of the discrepancy, at least for me. I'll rebuild with a bigger SCHED_PAD.

[Batalov]

I think Tom's is L1_BITS=15 (indeed it doesn't report). Static, because
> ldd ./gnfs-lasieve4I16e-Tom
not a dynamic executable

I've downloaded it and run (and compared to my binary, which is L1_BITS=16). For K10, mine is faster by a few percent. Both binaries are not the latest SVN. I have done a L1_BITS=15 as well, for BD, because his machine park is mixed and we needed a binary that was best for most machines. Don't have the results yet.

[fivemack]

150M-151M (on eight threads of an i7) took me 1080 thread-hours; which is about the amount of sieving time I'd usually devote to a 150-digit GNFS.

So this job is order of 130 times harder than that; which is actually rather close to what you'd expect, with e=3e-14 rather than 4.46e-12.

It does mean that I can take breaks between batches of sieving for this project by doing entire 145-digit GNFS jobs

[Andi47]

reserving 43M-44M

[Andi47]

gnfs-lasieve4I16e (windows 64-bit binary) just crashed at Q=43505239 - I got a windows error message (the program doesn't longer work). Trying to restart it with -R doesn't work - the siever crashes again.

The binary i use is 329.611.795 bytes long and dates to Nov. 1st 2009. I think that's SVN374 downloaded from Gilchrist's page.

Is there any newer binary for 64-bit windows available? The latest version on sourceforge is svn-400, but I never managed to build the GGNFS windows binaries.

[ET_]

Originally Posted by Andi47

5. - just add "-R" to the command line you have typed the first time. In this case GGNFS reads the output file, restarts the job where it has been interrupted and runs up to your desired end of the range.

I did.

I typed

./gnfs-lasieve4I16e -v -M 1 -a t.poly -f 21000000 -c 1000000 -R

but I got

Cannot resume without the file name

Luigi

P.S. I'm halfway through my range.

[Andi47]

Originally Posted by ET_

I did.

I typed

./gnfs-lasieve4I16e -v -M 1 -a t.poly -f 21000000 -c 1000000 -R

but I got

Cannot resume without the file name

Luigi

P.S. I'm halfway through my range.

what is the name of your outputfile? add -o <name of your outputfile> to the command line.

Edit: another reproducible crash at q=43515611. Is there a binary for windows 64-bit available, which is newer than svn-374?

[Jeff Gilchrist]

Originally Posted by Andi47

gnfs-lasieve4I16e (windows 64-bit binary) just crashed at Q=43505239 - I got a windows error message (the program doesn't longer work). Trying to restart it with -R doesn't work - the siever crashes again.

The binary i use is 329.611.795 bytes long and dates to Nov. 1st 2009. I think that's SVN374 downloaded from Gilchrist's page.

Is there any newer binary for 64-bit windows available? The latest version on sourceforge is svn-400, but I never managed to build the GGNFS windows binaries.

I haven't made any binaries lately. Is there anything new in the code that would benefit from building new ones? Note that the Windows 64bit binary is not the same as the special Linux 64bit one, often times the Windows 64bit binary is slower than the 32bit one.

Jeff.

[Andi47]

another crash at q=43031809

@Jeff: Maybe a few bugs have been fixed since svn-374?

[WraithX]

Originally Posted by Batalov

I cannot debug on Windows though (esp. 64-bit Windows). Linux binary doesn't crash, doesn't hang, plows right on.
It could be my ill-fated is_a_square (mpz_sqrtrem) test, or it could be a mpz_out_str crash; if anyone can debug/fix/rewrite this on Windows, please do.

I'd like to help, but I'm not sure where to start. I've downloaded the whole ggnfs svn400 repository.

Maybe we can start a new thread (called something like "GGNFS windows development") and talk there about specifics on problems that need to be addressed and features that are wanted/needed. I'm running on a 64-bit windows platform, so I'd also like to help get the 64-bit windows binaries as good as the linux 64-bit binaries.