[QUOTE=axn;493402]Can you provide some stats as to the pattern you're observing (of the fraction of survivors)?[/QUOTE]

For example, below, sieving with 262176 primes has an expected survivor rate of 17.871%, yet what I count is around 17.859%. OTOH I did a sieve step on the host, and the counts did match. Thus.. I am left to suspect there's no bug?

(the counts are over a block of 256*1024*1024 bits).

[CODE]
Using 262176 primes (up to 3681761)
expected filter 17.87131%
Exponent 332195561, k 1819
599599668620 (80.000000 bits)
Count 47939695
0.0% (class 0): 47939646 (17.859%), 27.0ms
0.1% (class 3): 47939695 (17.859%), 40.2ms
0.2% (class 4): 47942475 (17.860%), 40.2ms
0.3% (class 15): 47935056 (17.857%), 40.2ms
0.4% (class 19): 47938399 (17.858%), 40.2ms
0.5% (class 24): 47933509 (17.857%), 40.2ms
0.6% (class 28): 47932880 (17.856%), 40.2ms
0.7% (class 31): 47934883 (17.857%), 40.2ms
0.8% (class 36): 47935394 (17.857%), 40.2ms
0.9% (class 39): 47935199 (17.857%), 40.2ms
1.0% (class 40): 47930480 (17.855%), 40.2ms
1.1% (class 43): 47929750 (17.855%), 40.2ms
1.2% (class 48): 47935548 (17.857%), 40.2ms
1.4% (class 55): 47933873 (17.857%), 40.2ms
1.5% (class 60): 47935660 (17.857%), 40.2ms
1.6% (class 63): 47936327 (17.858%), 40.2ms
1.7% (class 64): 47931330 (17.856%), 40.2ms
1.8% (class 75): 47935783 (17.857%), 40.2ms
1.9% (class 76): 47937988 (17.858%), 40.2ms
[/CODE]

(the source is at [url]https://github.com/preda/gpuowl/[/url] , tf.cpp tf.cl )

[QUOTE=preda;493464]expected survivor rate of 17.871%, yet what I count is around 17.859%[/QUOTE]

These are close enough. I don't think I would rely on more than 3 significant digits from the estimate.

Hi,

we have found the issue in this case:

[QUOTE=GP2;492679]I am experimenting with one GPU of a Tesla V100-SXM2-16GB (this is a p3.2xlarge instance on Amazon AWS cloud with Deep Learning Base AMI).

Same specs as you listed for the Tesla V100-PCIE-16GB except a slightly faster clock rate:
[CODE]
clock rate (CUDA cores) 1530MHz
[/CODE]

It is configurable to use CUDA 9.2.88, by setting the symbolic link /usr/local/cuda

mfaktc passes all the Mersenne self tests.

However, when I compile an alternate version with -DWAGSTAFF added to CFLAGS, it fails all the Wagstaff self tests.

Did you try the Wagstaff self tests on your V100 and do they work for you?

Is anything more needed to create a Wagstaff version, other than adding the -DWAGSTAFF flag in CFLAGS?

The compilation uses gcc 4.8[/QUOTE]

Adding "-DWAGSTAFF" to the CFLAGS in the Makefile is not enough. This compiles the CPU code for Wagstaff numbers but the GPU code defaults to Mersenne numbers. [U]Recommended way to configure mfaktc for Wagstaff numbers is to enable this in src/params.h.[/U] Adding "-DWAGSTAFF" to both, CFLAGS and NVCCFLAGS should work aswell.

Oliver

link error / updated makefile
 

Tried to build mfaktc v0.21 unmodified, for CUDA 9.2 on Windows 64-bit, following the directions in the mfaktc readme's compiling on windows section. On a system on which gnu make for Windows had freshly been installed, and also Visual Studio 2017, and no previous builds of mfaktc performed, after one small modification to eliminate a single compile error on mfaktc.c line 995:[CODE] mystuff.selftestrandomoffset = rand() % 25000000 ; // was random() % 25000000 until 8/22/2018 kriesel; random( 25000000 ) gives a different compiler error
[/CODE] and modest changes to the makefile (attached) to update for compute capabilities and proper paths for the CUDA toolkit and Visual Studio locations, I get the following link error, which a web search shows relates to mixing 32-bit and 64-bit.
[CODE]link /nologo /LTCG sieve.obj timer.obj parse.obj read_config.obj mfaktc.obj checkpoint.obj signal_handler.obj output.obj tf_72bit.obj tf_96bit.obj tf_barrett96
.obj tf_barrett96_gs.obj gpusieve.obj tf_75bit.obj "C:\Program Files\NVIDIA GPU
Computing Toolkit\CUDA\v9.2"\lib\x64\cudart.lib /out:..\mfaktc-win-64.exe
fatal error C1905: Front end and back end not compatible (must target same proce
ssor).
LINK : fatal error LNK1257: code generation failed
make: *** [..\mfaktc-win-64.exe] Error 1257[/CODE]So how does one effectively track down what module or whatever is not 64-bit? It sure would be helpful if the linker would say what it's finding that doesn't match the 64-bit directive.
(Unfortunately, the Visual Studio command prompt in which the make is run, has too small a screen history buffer and resists attempts to increase it, to catch the thousands of lines of a clean first compile, much less to hold the error messages preceding.)

Doing 32-bit compilation is not a viable alternative in the CUDA toolkit 9.2 & VS 2017 combo:[CODE]nvcc -O2 -c tf_72bit.cu -o tf_72bit.obj -ccbin="C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin" -Xcompiler /EHsc,/W3,/nologo,/Ox,/GL -m32 --ptxas-options=-v --generate-code arch=compute_30,code=sm_30 --generate-code arch=compute_35,code=sm_35 --generate-code arch=compute_50,code=sm_50 --generate-code arch=compute_52,code=sm_52 --generate-code arch=compute_61,code=sm_61 --generate-code arch=compute_70,code=sm_70
nvcc fatal : 32 bit compilation is only supported for Microsoft Visual Studio
2013 and earlier
make: *** [tf_72bit.obj] Error 1[/CODE]I've been trying to download VS 2013 for days, without success. It's 4.8GB, and my downloads fail at no more than 1.5GB to date (via a crappy ISP that acquires territories and milks them for profit, does not maintain or upgrade them; 3/4Mbps download rate despite their advertising "high speed"; fiber coming by a different provider eventually)

Can Mfaktc be modified to support [URL="https://primes.utm.edu/top20/page.php?id=16"]Generalized repunit[/URL] trial factoring. The algebraic factors would be similar to mersenne numbers. Any help would be welcomed. Thanks.

[QUOTE=Citrix;495953]Can Mfaktc be modified to support [URL="https://primes.utm.edu/top20/page.php?id=16"]Generalized repunit[/URL] trial factoring. The algebraic factors would be similar to mersenne numbers. Any help would be welcomed. Thanks.[/QUOTE]


I would say possibly yes, but not easily. When I converted mfaktc to base 10 repunits I had to calculate the possible modular classes for base 10 and adapt the corresponding parts in the source code. For general repunits I am not sure if there is a generic way of calculating these classes. One option would be to ignore the possible classes and simply test all numbers, thus wasting lots of resources. I guess creating a lookup table for the different base to the corresponding classes is some bigger task, but possible.


Also the current mfaktc version is not well suited to handle numbers in the range of general repunits, so one has to create kernels that are faster. I did this already by implementing a kernel for numbers < 64 bits.


I can put the source code here if there is some interest.


Question to TheJudger: is there an official repository for mfaktc? I found one on github, but it was not created by you. If I would like to post my changes (on an extra branch) where would I do this?

[QUOTE=MrRepunit;495991]I would say possibly yes, but not easily. When I converted mfaktc to base 10 repunits I had to calculate the possible modular classes for base 10 and adapt the corresponding parts in the source code. For general repunits I am not sure if there is a generic way of calculating these classes. One option would be to ignore the possible classes and simply test all numbers, thus wasting lots of resources. I guess creating a lookup table for the different base to the corresponding classes is some bigger task, but possible.


Also the current mfaktc version is not well suited to handle numbers in the range of general repunits, so one has to create kernels that are faster. I did this already by implementing a kernel for numbers < 64 bits.


I can put the source code here if there is some interest.


Question to TheJudger: is there an official repository for mfaktc? I found one on github, but it was not created by you. If I would like to post my changes (on an extra branch) where would I do this?[/QUOTE]

Wiki page for mfaktc lists [URL="http://www.mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.tar.gz"]www.mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.tar.gz[/URL] There's also James Heinrich's mirror site, [URL]https://download.mersenne.ca/[/URL]

[QUOTE=kriesel;496001]Wiki page for mfaktc lists [URL="http://www.mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.tar.gz"]www.mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.tar.gz[/URL] There's also James Heinrich's mirror site, [URL]https://download.mersenne.ca/[/URL][/QUOTE]


I really meant a source code repository, similar to gpuowl: [URL]https://github.com/preda/gpuowl[/URL]

[QUOTE=MrRepunit;495991] For general repunits I am not sure if there is a generic way of calculating these classes. One option would be to ignore the possible classes and simply test all numbers, thus wasting lots of resources. I guess creating a lookup table for the different base to the corresponding classes is some bigger task, but possible.
[/QUOTE]

For generalized repunits b^p-1 (also for b^p+1 i.e. for negative b) with p prime, they have factors of the form 2*k*p+1 irrespective of b.

The only question is what form these factors can take mod 8? I do not have a general rule for this.

I am working on a special set of odd bases (for b^p+1 and b^p-1) where the factors are always 1 and 5 (mod 8).

Are there any other modular restrictions that I am not aware of?

If you could modify your program to help me.. I would appreciate it. I would prefer the compiled .exe instead of the source code. I am afraid I might not be compile the code.

Thanks.

[QUOTE=Citrix;495953]Can Mfaktc be modified to support [URL="https://primes.utm.edu/top20/page.php?id=16"]Generalized repunit[/URL] trial factoring. The algebraic factors would be similar to mersenne numbers. Any help would be welcomed. Thanks.[/QUOTE]

You are probably aware that the standard version of mfaktc was already modified to support Wagstaff numbers (with base b = −2). This was done by putting #ifdef WAGSTAFF lines in the source code rather than as a command line option flag.

The set of changes were rather small. So it ought to be feasible.



PS, if anyone is actively finding factoring Wagstaff numbers, or has log files from old searches, I am compiling a list of factors. See [URL="https://mersenneforum.org/showthread.php?t=23523"]this thread[/URL] and [URL="http://mprime.s3-website.us-west-1.amazonaws.com/wagstaff/"]this webpage[/URL].

[QUOTE=MrRepunit;496002]I really meant a source code repository, similar to gpuowl: [URL]https://github.com/preda/gpuowl[/URL][/QUOTE]
The source is there. See the screen grab below.


From my mfaktc forum notes, some of these posts might be of interest too.
2492 v0.21 release
[URL]http://mersenneforum.org/showpost.php?p=395689&postcount=2492[/URL]

2505 tuning advice

2547 mention of a v0.22 in development
[URL]http://mersenneforum.org/showpost.php?p=402408&postcount=2547[/URL]

2569 Win XP won't run mfaktc or anything built in VS2012; needs to be VS2010.
[URL]http://mersenneforum.org/showpost.php?p=408103&postcount=2569[/URL]

2570 version built for win xp
[URL]http://mersenneforum.org/showpost.php?p=408118&postcount=2570[/URL]

2602 NVIDIA bug related to 8.0 and gtx1070/80

2645 cuda 8 v0.21 build
[URL]http://mersenneforum.org/showpost.php?p=444025&postcount=2645[/URL]

2663 extra versions: wagstaff and less-classes
[URL]http://mersenneforum.org/showpost.php?p=444127&postcount=2663[/URL]

2692 linux x64 cuda8 build such as for gtx1070/80
[URL]http://mersenneforum.org/showpost.php?p=454623&postcount=2692[/URL]

2735 various versions with various minimum exponent described