Msieve 1.43 feedback
 

Hi Jason,

Can you please be careful with updating util.h since the latest 1.43 build no longer compiles in Visual Studio.

Brian has updated SVN with putting the fix back into util.h but somehow it keeps disappearing.

Jeff.

I removed the reference to the function rint() a few releases ago because AFAICT it was only used in stage 2 of NFS poly selection, and that code was modified not to need it a long time ago. What's the compile error in question?

[quote=jasonp;193758]I removed the reference to the function rint() a few releases ago because AFAICT it was only used in stage 2 of NFS poly selection, and that code was modified not to need it a long time ago. What's the compile error in question?[/quote]

Line 1369 in lanczos.c:

dump_interval = 10000 * (int)rint(5.0e7 / ncols);

needs it.

Brian

Ah, I didn't see that. Serge, please check with Brian if you're going to use non-C89 math functions; MSVC probably doesn't have them and we'll need a windows substitute.

For anyone waiting for the 64bit or 32bit Windows VS binaries, they are finally available, compiled with the latest MPIR (1.3.0) and GMP-ECM (SVN 1422):
[url]http://gilchrist.ca/jeff/factoring/[/url]

[quote=jasonp;193763]Ah, I didn't see that. Serge, please check with Brian if you're going to use non-C89 math functions; MSVC probably doesn't have them and we'll need a windows substitute.[/quote]
Sorry, it stuck in my mind that we have it in redu2.c anyway, ...but thinking about it, it is the lat.siever source, not part of msieve. I'll replace it with floor(x+0.5).

Feature request: 75-digit GNFS
 

[QUOTE=Jeff Gilchrist;194496]I have built new Windows 32bit and 64bit ggnfs binaries based on the SVN 374 version of the ggnfs code. You can download them here: [url]http://gilchrist.ca/jeff/factoring/[/url]

Hopefully this fixes the crashes a few people have been experiencing, it also removes the garbage output in the 64bit sievers, [B]and adds an 11e siever [/B]for doing smaller jobs. Andi47 did some benchmarks and found that [B]C85's are about 20% faster with the 11e and about 4% faster at C93 vs the 12e siever.[/B] [/QUOTE]

@Jasonp: As the result of my benchmark with the 11e siever suggests that the crossover between QS and GNFS shifts down by several digits, maybe as low as 75(?) digits. So can you please add a support for such small GNFS-factorizations (Poly search and postprocessing)?

[SIZE="1"]BTW: Maybe cubic polynomials might become interesting for 50-digit GNFS-factorizations? :wink:[/SIZE]

The postprocessing should work at that small size now; polynomial selection just needs to be allowed. It's an easy change.

How does checkpointing work for the linear algebra in msieve?

Does it write a check point after at certain time intervals, or % complete intervals, or what does it use?

If have a job running on a 64bit Windows (VS2008 built) binary but when I hit CTRL-C and stopped it, there was no .chk file generated so I couldn't use -ncr to resume, I had to start -nc2 over again.

It has been been running again now for almost an hour:

[B]linear algebra completed 82974 of 5491375 dimensions (1.5%, ETA 51h42m)[/B]

and still no check point file yet. Is that normal?

Jeff.

[QUOTE=Jeff Gilchrist;195709]How does checkpointing work for the linear algebra in msieve?

Does it write a check point after at certain time intervals, or % complete intervals, or what does it use?

If have a job running on a 64bit Windows (VS2008 built) binary but when I hit CTRL-C and stopped it, there was no .chk file generated so I couldn't use -ncr to resume, I had to start -nc2 over again.

It has been been running again now for almost an hour:

[B]linear algebra completed 82974 of 5491375 dimensions (1.5%, ETA 51h42m)[/B]

and still no check point file yet. Is that normal?

Jeff.[/QUOTE]
Originally the checkpointing code would write a checkpoint after a fixed number of dimensions were completed, with the specified number of dimensions going down as the problem size increased (since each iteration is slower). I was shooting for a checkpoint every three hours or so. Serge later made the code more sensitive to the matrix dimension, and calibrated it to write a checkpoint about once per hour (presumably using timings from one of his machines).

Did the checkpoint ever arrive for you?

The speed seems roughly reciprocal to the size (in the large size range; yeah, there must be a log somewhere, but it's not important), so I left it hitting the same product 5*10[SUP]11[/SUP](for 2M[SUP]2[/SUP] matrix, every 250K iterations; for 5M[SUP]2[/SUP], every 100K, for 12.5M[SUP]2[/SUP], every 40K iterations); for most computers the checkpoint should be written every 1-3 hours.

There will be no chk, if the matrix is less than 1M[SUP]2[/SUP].