mersenneforum.org Tweaking and compiling the Kleinjung siever
 Register FAQ Search Today's Posts Mark Forums Read

2009-04-18, 05:59   #23
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

217368 Posts

Quote:
 Originally Posted by jrk Also, this happened: mpqs failed for 354629572855321(a,b): -2920255724 2227
That's OK. It's a prime square; I've been puzzled with this as well, before.
See above - that was explained by xilman.

354629572855321 = 188316112

 2009-04-18, 06:32 #24 jrk     May 2008 109510 Posts Got it, thanks. I'll check if the skipped factors are OK.
 2009-04-18, 13:59 #25 jasonp Tribal Bullet     Oct 2004 353210 Posts Serge, the next time I'm in San Diego dinner's on me. With the polynomial selection finally figured out, maybe it's time to figure out and then rewrite lasieve for use within msieve. I'll have to see what kind of time I have in the next year.
 2009-04-18, 19:01 #26 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2×4,591 Posts Disclaimers: I've never looked in the subfolders other that athlon64/. Without much thinking I've removed the .w files (the CWEB conversion was already in place, so they were rudimentary. Thanks, Greg!). The .c and .h files still bear the conversion comments and are not indented. But hell, it builds. I simply dumped what I've lazily changed in Greg's version. For the assembly part, I only rerolled the upper loop once (when j_per_strip=1) and the source started working, but there were definitely good one-register saving ideas there, I guess just one line is missing. Could someone check that out? The real chore is to properly join it with the main trunk. I never had time to do it in full (only prepped the gnfs-lasieve4e.c file). The real tough job is to do the Windows asm, too. Our hopes are with joral. There are still tons of work.
 2009-04-19, 03:30 #27 nu4nu   Jul 2008 210 Posts Here're two bug fixes for the latest(r353) trunk/src/experimental/lasieve4_64/. First, in gnfs-lasieve4e.c, the return value of MMX_Td (a pointer) is truncated to int, because there are no function declaration in siever-config.h. So we should add the following line in siever-config.h. Code: u32_t*MMX_Td(u32_t *pbuf,int side,u16_t strip_i); It now seems working correctly on OpenBSD/amd64. Second, 'close' in gnfs-lasieve4e.c (line 563) should be 'fclose', isn't it? Could someone merge them to the SVN trunk? --Tomoya
2009-04-19, 17:10   #28
akruppa

"Nancy"
Aug 2002
Alexandria

9A316 Posts

I emailed Thorsten and asked for the latest version of the lattice siever. Here it is. It has 64 bit code and supports special-q > 2^32.

Alex
Attached Files
 lasieve5-20081105.tar.bz2 (233.4 KB, 407 views)

Last fiddled with by akruppa on 2009-04-19 at 17:13 Reason: .tgz was too big

2009-04-19, 17:11   #29
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2·3·7·137 Posts

Quote:
 Originally Posted by Batalov Yes, that's its feature (skips the factors less than 1000). msieve recovers all prime factors under 1000 by default, so there will be no problem with it. I've heard that procrels recovers factors less than 256 (but I have no idea; I haven't used straight GGNFS for very long), so you may want to change 1000 to 256 (in gnfs-lasieve4e.c) if this is the case and if this is a problem for you. If not, then ok. (Never been a problem for me. If you sieve e.g. for a distributed project with Tom, again, this is not going to be a problem.) Like I've said previously, it's a jungle. E.g. 1000 is not in a #define, but you can find it in the editor. One day, someone will merge both sources...
Is anyone able to look in the procrels source and find out how to change that to 1000 or something? Looking at the procrels source it seems to have a dump mode for outputting just ab pairs. It also seems to support reading in just ab pairs and factoring them itself. I don't know whether it will detect that it needs to find factors >255 if there are some factors available.

How much would it slow down postprocessing for it to have to look for larger factors(all up to 65535 or maybe all factors)?
Would it be worth writing a utility to convert between omitting different sizes of factors? This might be helpful for transferring huge numbers of relations around the world and enable people to do huge postprocessing jobs even if they didn't do the sieving.
Vaguely what size would a 1Gb file of relations with all factors included go down to if all factors were removed and how long would it take to get all the factors again. I would guess quite small and then they can be then compressed using ordinary compression. I suppose you could call this data specific compression.

2009-04-19, 19:32   #30
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

2·4,591 Posts

Quote:
 Originally Posted by nu4nu Here're two bug fixes for the latest(r353) trunk/src/experimental/lasieve4_64/
Added to 355. Thank you. There's also a pointer type mismatch in asm
passing argument 1 of tdsieve_sched2buf' from incompatible pointer type
(cannot read the asm code too well; will not touch for now)

Alex and Thorsten: thank you!

Henry: in GGNFS, the limit currently appears to be 50 FB primes.
../include/ggnfs.h:#define CLIENT_SKIP_R_PRIMES 50
../include/ggnfs.h:#define CLIENT_SKIP_A_PRIMES 50

Let's raise these to 170 (that's all primes under 1000). Added to SVN 356.

2009-04-19, 21:11   #31
nu4nu

Jul 2008

2 Posts

Quote:
 Originally Posted by Batalov Added to 355. Thank you. There's also a pointer type mismatch in asm passing argument 1 of tdsieve_sched2buf' from incompatible pointer type (cannot read the asm code too well; will not touch for now)
Indeed, siever-config.h is wrong on that point. The 1st arg is u16_t**.
In tdsieve-from-sched.asm, it is dereferenced twice as below.
Code:
5: define(sched_arg,%rdi)dnl
11: movq (sched_arg),sched
17: movzwq (sched),si0
There are some warnings remaining, but I'm afraid that these trivial fixes are off-topic. Could you allow me the SVN developer access? Or, should I ask someone else?

 2009-04-20, 03:00 #32 jasonp Tribal Bullet     Oct 2004 22×883 Posts I think Anton Korbeynikov (__asl here and on sourceforge) is still the GGNFS project lead, so you should ask him. Seeing as we now have the latest and greatest source, perhaps everyone can re-port their respective patches to it? PS: Henry, the intent of coordinate-only relation output was exactly to improve bandwidth for very large jobs. Storing none of the large primes means that recovering the factors of relations took a very long (perhaps unacceptably long) time. Greg has some improvements that do trial division followed by SQUFOF, and improve the decoding time by a lot. Another possibility is to specify a bound on the size of reported factors (say over a million as the default), allowing for tradeoffs between the bandwidth needed for transfers and the time needed to make full relations again. NFSNET should have lots of experience with this. Last fiddled with by jasonp on 2009-04-20 at 03:04
2009-04-20, 03:54   #33
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

2·4,591 Posts

Quote:
 Originally Posted by akruppa I emailed Thorsten and asked for the latest version of the lattice siever. Here it is. It has 64 bit code and supports special-q > 2^32. Alex
I was planning tomorrow night to have a good look. It's fantastic to have the latest version. It is very likely mergeable to the experimental branch... and then later the whole thing to the trunk (not me, not me!).

 Similar Threads Thread Thread Starter Forum Replies Last Post chris2be8 Factoring 6 2018-02-06 17:22 Zerowalker Information & Answers 8 2013-04-19 15:01 lorgix Hardware 45 2012-04-11 02:01 fivemack Msieve 38 2011-07-08 08:12 sean NFSNET Discussion 1 2005-05-11 14:25

All times are UTC. The time now is 23:49.

Thu Dec 3 23:49:22 UTC 2020 up 20 hrs, 1 user, load averages: 0.78, 1.12, 1.20