Tweaking and compiling the Kleinjung siever

[Batalov]

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 = 18831611²

[jrk]

Got it, thanks. I'll check if the skipped factors are OK.

[jasonp]

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.

[Batalov]

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.

[nu4nu]

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.

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

[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

[henryzz]

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.

[Batalov]

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.

[nu4nu]

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.

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?

[jasonp]

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.

[Batalov]

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!).