mtsieve

[rogue]

I have posted mtsieve 2.4.7 to sourceforge. Here is a summary of the changes.

framework:
   Added command line switch -4.  Sieving will stop when the factors per
   second rate falls below the specified rate.   The rates only only evaluated 
   when the factor rate is computed, which is once per minute.
   
   Added command line switch -5.  Sieving will stop when the seconds per
   factor rate falls is above specified rate.  The rates only only evaluated 
   when the factor rate is computed, which is once per minute.

fbncsieve: version 1.6.2:
   If max p is overridden due to the ability to factor out all composite terms,
   then all remaining prime terms will be written the the output file as opposed
   to some being written to the <xx>_primes.txt file.
   
gcwsieve/gcwsievecl: version 1.5.2
   Modify output format to gcw_gfn.txt and gcw_mersenne.txt to make more sense.

srsieve2/srsieve2cl: version 1.7
   Can now support hundreds of thousands of sequences per execution.

   Added command line switch -S to split the sequences into separate files by
   best Q for tha sequence.  The resulting files should then be run with -q to
   ensure that it uses the best Q for that set of sequences.

   The software only factors k*b^n+/-c, even if d > 1.  When d > 1 a couple
   of other checks are in play.
   
   When sieving sequences (k*b^n+/-c)/d where d > 1, terms where d > factor and
   gcd(d, factor) > 0 will be not be removed when (k*b^n+/-c) mod factor = 0
   because there is no easy way to verify that if factor divides (k*b^n+/-c)
   that it also divides (k*b^n+/-c)/d.

   Added command line switch -r for use with (k*b^n+/-c)/d sequences where d > 1.
   When specified this will remove terms where k*b^n+/-c mod d != 0.  If you do not
   use -r then pfgw will use floor((k*b^n+/-c)/d) before doing the PRP test.

Please let me know if you run into any issues.

[storm5510]

Something I stumbled upon: If I take an ABCD file created with a v1.6.x version of srsieve2, v1.7 will drop out to the command prompt after displaying, "Split x base x sequences into x base x^y sequences." If I start a new series with v1.7, then there is no problem continuing with an ABCD.

This is easily avoidable if a person is aware of it. I was not until now.

[rogue]

Originally Posted by storm5510

Something I stumbled upon: If I take an ABCD file created with a v1.6.x version of srsieve2, v1.7 will drop out to the command prompt after displaying, "Split x base x sequences into x base x^y sequences." If I start a new series with v1.7, then there is no problem continuing with an ABCD.

This is easily avoidable if a person is aware of it. I was not until now.

Hmm. Post the ABCD file and I will take a look.

[ryanp]

Is the SVN repo at HEAD missing a file?

$ make -j 8 xyyxsieve
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/App_cpu.o core/App.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/FactorApp_cpu.o core/FactorApp.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/AlgebraicFactorApp_cpu.o core/AlgebraicFactorApp.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/Clock_cpu.o core/Clock.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/Parser_cpu.o core/Parser.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/Worker_cpu.o core/Worker.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/main_cpu.o core/main.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/SharedMemoryItem_cpu.o core/SharedMemoryItem.cpp 
g++ -Isieve -m64 -Wall -DUSE_X86 -std=c++11 -O3 -c -o core/HashTable_cpu.o core/HashTable.cpp 
make: *** No rule to make target 'core/BigHashTable_cpu.o', needed by 'xyyxsieve'.  Stop.
make: *** Waiting for unfinished jobs....

[ryanp]

I'm also seeing a segfault with an existing build of xyyxsievecl:

$ ./xyyxsievecl -i ./cand.txt  -o newterms.txt -P 1e11 -G 16 -g 16 -M 1000000
xyyxsieve v1.8.1, a program to find factors numbers of the form x^y+y^x or x^y-y^x
Segmentation fault (core dumped)

cand.txt is attached. I debugged only a little; seems to be something to do with how it allocates the iv_Terms array. It segfaults on the line assigning to it:

      if (haveBitMap)
      {
         iv_Terms[BIT(x, y)] = true;    // array seems too small here.
         il_TermCount++;
      }

[rogue]

I committed the missing source file.

I will take a look at the segfault today.

Thanks for posting the file. I expect it to be an easy fix, but one never knows...

[storm5510]

Originally Posted by rogue

Hmm. Post the ABCD file and I will take a look.

Attached are two ABCD files. One ran with v1.6.9 and the other with v1.7. Both are derived from a 60% test I did for R60: 11652*60^n-1. They are identical. I took the one from v1.6.9 and attempted a continuation with v1.70 and it accepted it.

So, some instances, it works and other times not. The best solution is to not cross from one to the other.

[rogue]

Originally Posted by rogue

I committed the missing source file.

I will take a look at the segfault today.

Thanks for posting the file. I expect it to be an easy fix, but one never knows...

The root cause is that your range of x and y are too large and there isn't enough memory for the vector.

Although I have a solution, I don't like it because it negatively impacts performance. I need to spend more time on it.

[ryanp]

Originally Posted by rogue

The root cause is that your range of x and y are too large and there isn't enough memory for the vector.

Ah OK. Presumably I could just split the file into several and then sieve each one separately?

[rogue]

Originally Posted by ryanp

Ah OK. Presumably I could just split the file into several and then sieve each one separately?

In this case yes because most of the performance improvements come from overlapping ranges of y for each x and y for each y.

Now that I think about it I could probably modify it to be more "brute force" depending upon the sparseness of x and y. That shouldn't hurt performance and might even help it.