Tweaking and compiling the Kleinjung siever

Batalov · 2008-12-19, 08:24

Ok, since the Schlendrian/shenenigan brach was removed, so was my promise to add the resume option - but I did add it now and will crosspost about it here. You are welcome to get the tarball, build and try the -R option. I tested it, of course, but YMMV. Keep your existing binaries before you like the new ones.

Andi47 · 2008-12-19, 09:00

Quote:

Originally Posted by Batalov

Ok, since the Schlendrian/shenenigan brach was removed, so was my promise to add the resume option - but I did add it now and will crosspost about it here. You are welcome to get the tarball, build and try the -R option. I tested it, of course, but YMMV. Keep your existing binaries before you like the new ones.

Are there also pre-compiled gnfs-lasieve4I1?e files for windows (from 12e to 15e) available?

edit: the option for rational side sieving is -r, so I assume that -r (minuscle r) is still for r-side sieving and -R (majuscle R) is for resuming?

Batalov · 2008-12-19, 09:30

of course. (-r and -R are separate).

Binaries: I will post an Opteron x64_64 binary tomorrow, but Windows I simply do not use. Cannot help it!

fivemack · 2008-12-19, 11:06

I notice that the 64-bit Opteron assembly code hasn't got into the SVN repository:

Code:

crick% svn co https://ggnfs.svn.sourceforge.net/svnroot/ggnfs ggnfs                        
...output...
crick% cd ggnfs/trunk; make nocona
...output...
crick% bin/gnfs-lasieve4I15e -r ~/math/2+925/2+925.60.poly -f 60000000 -c 1000
total yield: 1278, q=60001021 (0.92806 sec/rel)
crick% ~/math/64bit_new/gnfs-lasieve4I15e -r ~/math/2+925/2+925.60.poly -f 60000000 -c 1000
total yield: 1278, q=60001021 (0.49510 sec/rel)

Same thing happens with 'make x86_64'. ~/math/64bit_new/gnfs-lasieve4I15e is the executable from http://physics.fullerton.edu/gchilde...eve4_64.tar.gz pointed to by post http://www.mersenneforum.org/showpos...6&postcount=23

Batalov · 2008-12-19, 21:12

Correct. The Opteron speed will not be comparable. But if you have the assembly part, you may want to combine these two sources.

The holders (not sure about the original authors) of the 64-bit Opteron assembly code have the SVN access. If the original author would be so inclined, this code would have been merged long ago. But it wasn't. There must be a reason behind it. From this, I take that I cannot commit it either. But we can share the Opteron binaries (I take it from Greg's posting of the binary in Feb and March.)

frmky · 2008-12-20, 05:58

Quote:

Originally Posted by Batalov

The holders (not sure about the original authors) of the 64-bit Opteron assembly code have the SVN access. If the original author would be so inclined, this code would have been merged long ago. But it wasn't. There must be a reason behind it. From this, I take that I cannot commit it either. But we can share the Opteron binaries (I take it from Greg's posting of the binary in Feb and March.)

Actually the only reason is (at least one of) the holders never took the time to do a clean integration of the code. I actually used a slightly modified version of the original Franke source to produce those binaries, and not the version integrated in the GGNFS sources. Feel free to put it in the SVN.

Batalov · 2008-12-20, 09:33

Yes, this an understandable hassle. Well, the author did much more work than I can add, so that chore is fair in my book.

OK, I'll give it a try next week. Indeed, some formatting and minimal cleaning will be needed. I can do that. (So that it would merge as just the necessary, say, 20 lines here and there, not like a "-500/+520 lines" patch.) I will test-build on Linux x86_64 and MinGW (I never commit a non-compiling code), but some other platforms may get broken - I don't have too much variety in my comps.

It would be nice if a name of the real developer of the assembly part could be added to those additional files. Was it Joppe Bos, and/or you, and/or someone else?

Batalov · 2008-12-20, 21:20

P.S. The search function of the forum is "like a box of chocolates - you never know what you're gonna get." I thought that I've previously found all the obscure posts about the siever's code... but I was wrong (this time the search item was "Joppe Bos") - now found this (of course the name of the thread with three "?" marks usually flags for me as cranky)... So that was the first sighting of the asm code. Earlier it was mentioned in this thread about a GNFS-156. So, is it the same code these threads are talking about? Thx.

fivemack · 2008-12-21, 00:10

When using the 2+925.poly file with rlim set to 68000000 and the command line

../../64bit_new/gnfs-lasieve4I15e -r 2+925.68.poly -f 68000000 -c 500000

(IE frmky's executable), I'm getting bad-schedule messages on many primes.

Same with -f 68500000

No problems at all with 2+925.69.poly (ie rlim=69000000) and -f 69000000 or 69500000; no problems with 67.

../../64bit_new/gnfs-lasieve4I15e -r 2+925.68.poly -f 68121120 -c 2

is a test-case which produces a bad schedule.

The badsched messages come, as far as I can see, from a test in do_schedule which refers to things produced in lasched.c which is the absolute heartwood of the program.

Batalov · 2008-12-21, 02:35

(I realize the above bug report is for anyone, not for me) For this beast, I am at best a veterinarian, not a heart surgeon. You see, it is very hard to debug what happens after the code returns from the assembly-optimized part.

I can only remark to that debug case that there was a 1 relation discrepancy between the GGNFS and the Greg's binary when many people first tried it in that thread... (2206 vs. 2207/15e and 1096 vs. 1097/14e) May or may not be related. I find it minor, compared to the infinite loop in reduce2() which may get your process stuck (if unsupervised) for a week or a month.

Another open bug/feature to mention: It is also well known to those who does small numbers that there are many of "mpqs failed" messages trickling. Quite specifically in small numbers, let's say, snfs-110... On bigger numbers, these messages don't happen. Also minor.

Andi47 · 2008-12-21, 04:52

Quote:

Originally Posted by Batalov

Another open bug/feature to mention: It is also well known to those who does small numbers that there are many of "mpqs failed" messages trickling. Quite specifically in small numbers, let's say, snfs-110... On bigger numbers, these messages don't happen. Also minor.

I have also seen some "too many relations in mpqs" messages for numbers up to c136, and IIRC even with some of fivemacks huge numbers sieved with 4I15e. I also think that this is a minor bug, but every time this happens, possibly a few relations get lost / are not found?

2008-12-19, 08:24	#1
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2505₁₆ Posts	Tweaking and compiling the Kleinjung siever Ok, since the Schlendrian/shenenigan brach was removed, so was my promise to add the resume option - but I did add it now and will crosspost about it here. You are welcome to get the tarball, build and try the -R option. I tested it, of course, but YMMV. Keep your existing binaries before you like the new ones.

2008-12-19, 09:30	#3
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	of course. (-r and -R are separate). Binaries: I will post an Opteron x64_64 binary tomorrow, but Windows I simply do not use. Cannot help it! Last fiddled with by Batalov on 2008-12-19 at 09:37

2008-12-19, 11:06	#4
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 7²×131 Posts	Speediness I notice that the 64-bit Opteron assembly code hasn't got into the SVN repository: Code: crick% svn co https://ggnfs.svn.sourceforge.net/svnroot/ggnfs ggnfs ...output... crick% cd ggnfs/trunk; make nocona ...output... crick% bin/gnfs-lasieve4I15e -r ~/math/2+925/2+925.60.poly -f 60000000 -c 1000 total yield: 1278, q=60001021 (0.92806 sec/rel) crick% ~/math/64bit_new/gnfs-lasieve4I15e -r ~/math/2+925/2+925.60.poly -f 60000000 -c 1000 total yield: 1278, q=60001021 (0.49510 sec/rel) Same thing happens with 'make x86_64'. ~/math/64bit_new/gnfs-lasieve4I15e is the executable from http://physics.fullerton.edu/gchilde...eve4_64.tar.gz pointed to by post http://www.mersenneforum.org/showpos...6&postcount=23

2008-12-21, 00:10	#9
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 1913₁₆ Posts	Test cases for 'badsched' message When using the 2+925.poly file with rlim set to 68000000 and the command line ../../64bit_new/gnfs-lasieve4I15e -r 2+925.68.poly -f 68000000 -c 500000 (IE frmky's executable), I'm getting bad-schedule messages on many primes. Same with -f 68500000 No problems at all with 2+925.69.poly (ie rlim=69000000) and -f 69000000 or 69500000; no problems with 67. ../../64bit_new/gnfs-lasieve4I15e -r 2+925.68.poly -f 68121120 -c 2 is a test-case which produces a bad schedule. The badsched messages come, as far as I can see, from a test in do_schedule which refers to things produced in lasched.c which is the absolute heartwood of the program.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Compiling 64 bit lattice siever on gcc 4.8.5	chris2be8	Factoring	6	2018-02-06 17:22
Large FFT tweaking	Zerowalker	Information & Answers	8	2013-04-19 15:01
Tweaking RAM & CPU	lorgix	Hardware	45	2012-04-11 02:01
Tweaking polynomial search for C197	fivemack	Msieve	38	2011-07-08 08:12
RSA200 factored by Kleinjung et al.	sean	NFSNET Discussion	1	2005-05-11 14:25

2008-12-19, 21:12	#5
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	Correct. The Opteron speed will not be comparable. But if you have the assembly part, you may want to combine these two sources. The holders (not sure about the original authors) of the 64-bit Opteron assembly code have the SVN access. If the original author would be so inclined, this code would have been merged long ago. But it wasn't. There must be a reason behind it. From this, I take that I cannot commit it either. But we can share the Opteron binaries (I take it from Greg's posting of the binary in Feb and March.)

2008-12-20, 09:33	#7
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2505₁₆ Posts	Yes, this an understandable hassle. Well, the author did much more work than I can add, so that chore is fair in my book. OK, I'll give it a try next week. Indeed, some formatting and minimal cleaning will be needed. I can do that. (So that it would merge as just the necessary, say, 20 lines here and there, not like a "-500/+520 lines" patch.) I will test-build on Linux x86_64 and MinGW (I never commit a non-compiling code), but some other platforms may get broken - I don't have too much variety in my comps. It would be nice if a name of the real developer of the assembly part could be added to those additional files. Was it Joppe Bos, and/or you, and/or someone else?

2008-12-20, 21:20	#8
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	P.S. The search function of the forum is "like a box of chocolates - you never know what you're gonna get." I thought that I've previously found all the obscure posts about the siever's code... but I was wrong (this time the search item was "Joppe Bos") - now found this (of course the name of the thread with three "?" marks usually flags for me as cranky)... So that was the first sighting of the asm code. Earlier it was mentioned in this thread about a GNFS-156. So, is it the same code these threads are talking about? Thx.

2008-12-21, 02:35	#10
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	(I realize the above bug report is for anyone, not for me) For this beast, I am at best a veterinarian, not a heart surgeon. You see, it is very hard to debug what happens after the code returns from the assembly-optimized part. I can only remark to that debug case that there was a 1 relation discrepancy between the GGNFS and the Greg's binary when many people first tried it in that thread... (2206 vs. 2207/15e and 1096 vs. 1097/14e) May or may not be related. I find it minor, compared to the infinite loop in reduce2() which may get your process stuck (if unsupervised) for a week or a month. Another open bug/feature to mention: It is also well known to those who does small numbers that there are many of "mpqs failed" messages trickling. Quite specifically in small numbers, let's say, snfs-110... On bigger numbers, these messages don't happen. Also minor.