Trial division with CUDA (mmff) -- used, but runs like new!

[aketilander]

Originally Posted by tServo

Did you upgrade the video driver as well? That's what would impact performance rather than the SDK, which is basically a bunch of demo programs.

Whoops! The SDK might have some needed DLLs.

Sorry, maybe I was too fast to spread the happy news. mmff0.26 runs for a while and then I get the error-message: "ERROR: cudaGetLastError() returned 30: unknown error" When I restart the program everything runs just fine, BUT the speed is about half of what it was from the beginning.

This is not a new error I had it before the upgrade as well.

I have a second computer with the same videocard. The program runs on the higher speed without problems.

So, anybody knows what is wrong?

[frmky]

A minor issue, but with gcc 4.6.3, I have to move $(LDFLAGS) to the end in the final link command in the Makefile:

../mmff.exe : $(COBJS) $(CUOBJS)
        $(LD) $^ -o $@ $(LDFLAGS)

[aketilander]

Originally Posted by aketilander

mmff0.26 runs for a while and then I get the error-message: "ERROR: cudaGetLastError() returned 30: unknown error" When I restart the program everything runs just fine, BUT the speed is about half of what it was from the beginning.

I took down the core clock speed of the videocard a little bit and the problem seems to have disappeared. The program seems to be stable now. If the problem reappears I will of course report it here.

[Batalov]

The latest mmff-gfn-0.26.zip is attached. (Contains some latest minor changes and the 0.26 backbone.)

Jerry flashjh, could you please build the Win32+Win64 binaries for each BASE (edit tf_gfn.h and delete all objects between each buils) and email them to Xyzzy for organized storage? Thank you in advance.

[ET_]

Originally Posted by Batalov

The latest mmff-gfn-0.26.zip is attached. (Contains some latest minor changes and the 0.26 backbone.)

Jerry flashjh, could you please build the Win32+Win64 binaries for each BASE (edit tf_gfn.h and delete all objects between each buils) and email them to Xyzzy for organized storage? Thank you in advance.

Thank you Serge.

Is a version ready for xGF and with every search bundled in it just on course?

Luigi

[Batalov]

Originally Posted by ET_

Thank you Serge.

Is a version ready for xGF and with every search bundled in it just on course?

Luigi

No, haven't started yet with xGFN; also have some doubts - we can run out of registers.
Over weekend, I possibly will try to build a toy one - using only 2^2[SUP]m[/SUP] and 3^2[SUP]m[/SUP] (which after linear combinations makes for F, GF(3), GF(6), GF(12), and xGF(2,3), xGF(2,9), xGF(3,4), xGF(3,8)). Ughhh, it is going to be ugly. And slow, too!

[flashjh]

Win32/64 binaries uploaded and email sent.

Jerry

[aketilander]

I have done some tests to see where the upper limit of mmff 0.26 is. If I look into the source code there is a kernal barrett188 which is suppost to cover TFs up to ^188 bits (that is k=1,152,921e12 for MM127), but when I try to run the program with k:s that large I get the error-message "Exponentiation failure". Using smaller k:s the upper limit seems to be around 420,000e12.

Just out of curiosity it would be interesting to know if this is due to limitations of my video card or if it is a limitation of the program as such?

[Prime95]

Originally Posted by aketilander

I have done some tests to see where the upper limit of mmff 0.26 is. If I look into the source code there is a kernal barrett188 which is suppost to cover TFs up to ^188 bits (that is k=1,152,921e12 for MM127), but when I try to run the program with k:s that large I get the error-message "Exponentiation failure". Using smaller k:s the upper limit seems to be around 420,000e12.

Just out of curiosity it would be interesting to know if this is due to limitations of my video card or if it is a limitation of the program as such?

Sounds like a program bug where I've miscalculated the upper limit of what the kernel can handle. At least the automatic QA caught the problem.

[ATH]

Originally Posted by aketilander

I have done some tests to see where the upper limit of mmff 0.26 is. If I look into the source code there is a kernal barrett188 which is suppost to cover TFs up to ^188 bits (that is k=1,152,921e12 for MM127), but when I try to run the program with k:s that large I get the error-message "Exponentiation failure". Using smaller k:s the upper limit seems to be around 420,000e12.

Just out of curiosity it would be interesting to know if this is due to limitations of my video card or if it is a limitation of the program as such?

I tested with ranges of 1e10 and it seems the higher the k the higher risk of the error happening but sometimes you don't get the error. The lowest I have got it at was k=280,000e12.

Here is 3 instances of the error with the -v 3 option:
MM127error.txt

[ATH]

I tried running a small range for the first time with mmff. So far I have only been troubleshooting because I think the fan on my GTX 460 might break soon and because I can't really afford a higher power bill than I have currently (I have complained a lot about danish power prices in other threads, so I'll spare the details here).

But to my surprise my small range finished 5x quicker than I expected, so it turns out I apparantly never understood the "raw rate" output of mmff.

My "raw rate" was around 368 M/s (and later dropped to 347 M/s), so I figured this range would take: (1200e12-2^50)/368e6 = 201e3 sec = 56h. But it finished after 12h4min! So my k-rate was (1200e12-2^50)/43440sec = 1706 M/s ?

So I noticed each output line says "candidates 16.04G" and took rougly 43-46s so thats where the "raw rate" of 347M/s - 368M/s comes from, but what is that measuring exactly? Candidates is number of probable primes to test divisibility with?

Starting trial factoring of k*2^46+1 in k range: 1125899906842624 to 12000000000
00000 (97-bit factors)
 k_min = 1125899906842624
 k_max = 1200000000000000
Using GPU kernel "mfaktc_barrett108_F32_63gs"
    class | candidates |    time |    ETA | raw  rate | SievePrimes | CPU wait
   3/4620 |     16.04G | 43.589s | 11h36m | 367.96M/s |      210485
.
.
4613/4620 |     16.04G | 46.216s |  0m00s | 347.04M/s |      210485
no factor for k*2^46+1 in k range: 1125899906842624 to 1200000000000000 (97-bit
factors) [mmff 0.26 mfaktc_barrett108_F32_63gs]
tf(): total time spent: 12h  4m  0.423s