Msieve v1.49 feedback

[Jeff Gilchrist]

Originally Posted by jrk

590 now. I made a small error earlier that would sometimes make the fb bounds too small when a multiplier is used. Fixed again.

Just passed 30000 tinyqs jobs without any more failures.

Thanks, seems to work for me:

Msieve v. 1.49 (SVN unknown)
Wed Jun 29 09:56:12 2011
random seeds: f3b8cc60 81da4865
factoring 30341442928592512281446689 (26 digits)
prp11 factor: 43690242767
prp15 factor: 694467254173967
elapsed time 00:00:00


Msieve v. 1.49 (SVN unknown)
Wed Jun 29 09:56:12 2011
random seeds: fc53de41 4c71154b
factoring 2711611651034302248235343 (25 digits)
p10 factor: 6205270121
prp15 factor: 436985271899383
elapsed time 00:00:00

I pulled this from SVN myself and it is still tagged as unknown so I think the Windows code was probably never updated to include this tag when compiling under Visual Studio. Brian, are you reading these posts? Is there anything you can do about that?

[Brian Gladman]

Hi Jeff, The "unknown" comes from line 36 in msieve.h - its not obvious what I can do to change this unless there is a file exported from the SVN that I can extract a tag from. I certainly don't want to do this with a manual edit given how often I update from the SVN!

[jasonp]

To make a MSVC build fill in the SVN rev, you have to get the build process to run 'svnversion' or a windows equivalent as part of the build process, then parse the output. You can do it if you build from cygwin, but that's not going to help here.

[Jeff Gilchrist]

Originally Posted by jasonp

To make a MSVC build fill in the SVN rev, you have to get the build process to run 'svnversion' or a windows equivalent as part of the build process, then parse the output. You can do it if you build from cygwin, but that's not going to help here.

With TortoiseSVN, you can run the command "subwcrev ." in the directory where SVN files are located and it will return the revision number.

Also, in the .svn directories, the file "entries" contains the revision number as well. Line 4 seems to have the latest SVN rev, the second set at line 11 seems to be the latest rev for files updated in that directory so you could parse that file as well.

Jeff.

[Brian Gladman]

Thanks Jason and Jeff.

Running and capturing output from an SVN application is easy ONCE such an applicatioin is found.

But there are quite a few different ones in use on Windows and also quite a few different locations on win32 and x64 systems where these have to be looked for (sadly many people don't respect Windows conventions for program locations).

Moreover reading program locations from the registry is quite complex in DOS because of the need to account for win32/x64 registry remapping. I don't fancy doing any of this in DOS!

Text file processing is also tedious and arcane in DOS so reading and parsing files and then modifying msieve.h to insert the revision number is far from easy. But if anyone can offer a DOS batch script that does this or even outputs the revision number into a single line file in the format:

#define MSIEVE_SVN_VERSION "revision number"

I will willingly intgerate it into the MSVC build.

Of course, I can easily do all of this in a Python script. But do we want to make the MSVC build of msieve depend on Python being present?

[Jeff Gilchrist]

Originally Posted by Brian Gladman

Of course, I can easily do all of this in a Python script. But do we want to make the MSVC build of msieve depend on Python being present?

Maybe the solution is something not automated. Since you have python scripts for testing, maybe you could add one in the build.vc10 directory that will go and modify the .h file with the correct SVN revision. That way people with python can run it and have the value updated without having to manually edit the file and those without it wouldn't be stuck.

[fivemack]

I've looked at the Bach-Peralta http://cr.yp.to/bib/1996/bach-semismooth.pdf which tells me that the right scaling is by considering log(biggest factor)/log(N), and have done a bit of sieving on scale models because Bach is one-large-prime only (though the sort of size of implementation problem that I could probably manage to do)

It seems that, with three large primes allowed, and with the sort of parameters I'd be using for the G197, I miss about 30% of smooth numbers by doing things that scale to sieving to 2^28 and largeprimesing to 2^33 (versus missing more than 60% if allowing only two large primes); so, making all sorts of unjustifiable equidistribution assumptions, it looks as I won't be screwing up completely by using the largeprime bound.

[fivemack]

The scaling between the Bernstein and Murphy values is a factor which changes substantially when I increase the integration area for the Murphy value.

Since there's a pre-test which compares scaled-Bernstein with Murphy, I have to keep the third parameter in poly_skew.c at 2e-15 even though Murphy integrating over the larger area is giving me numbers around 5e-9. Is there likely to be a serious problem connected with having the expected-Murphy-score six orders of magnitude lower than the ones actually computed?

[jasonp]

No, it just means all of the top polynomials from the root sieve will get their Murphy score optimized, and there are a few hundred of those at most. This is the default for degree 6 :)

[sleigher]

Hello All,

I am running 64-bit linux. Centos 5.5 x86_64 with a nvidia card:

nVidia Corporation G92 [GeForce 8800 GT] (rev a2)

When running make with the appropriate options, things go well until mpicc hits something strange with the CUDA libs..

mpicc -D_FILE_OFFSET_BITS=64 -O3 -fomit-frame-pointer -march=k8 -DNDEBUG -D_LARGEFILE64_SOURCE  -Wall -W -I. -Iinclude -Ignfs -Ignfs/poly -Ignfs/poly/stage1 -I"/cuda/include" -DHAVE_CUDA -DHAVE_MPI -DNO_ZLIB demo.c -o msieve  \
                        libmsieve.a "/cuda/lib64/cuda.lib" -lgmp -lm -lpthread
libmsieve.a(stage1.no): In function `poly_stage1_run':
stage1.c:(.text+0x773): undefined reference to `cuCtxDestroy_v2'
collect2: ld returned 1 exit status
make: *** [x86_64] Error 1

The make command I am running is "make x86_64 CUDA=1 MPI=1" I have the makefile edited to find the appropriate cuda/lib (libcuda.so.260.19.21).

This is using msieve 1.49 but I get the same problem with 1.48.

All I found on the web is a vague reference on the nvidia forums that was not helpful at all.

Has anyone tried compiling this with the latest CUDA devkit as well as openmpi-1.4-4.el5?

Or seen anything like this? Any hints would be great....

Thanks a lot and thanks for this wonderful software!

--

[sleigher]

Hi

I commented out the 3 lines in the stage1.c file that call this

#ifdef HAVE_CUDA

        CUDA_TRY(cuCtxDestroy(poly->gpu_context)) 

#endif

Everything then compiled ok. Any insight on what this will cause?