gr-mfaktc: a CUDA program for generalized repunits prefactoring

[kriesel]

Originally Posted by storm5510

Using the version of mfaktc I had, the 1080 would run around 1050 GHz-d/day. This one was 730 GHz-d/day., more or less. This was with base 2.

So, the ~30% performance loss in gr-mfaktc relative to mfaktc means Mersenne factorers should stick with the mainstream mfaktc.

[MrRepunit]

Originally Posted by kriesel

So, the ~30% performance loss in gr-mfaktc relative to mfaktc means Mersenne factorers should stick with the mainstream mfaktc.

For now yes. At a later point I might create a version that uses the original code path for Mersenne primes, probably once I have included negative bases...

[storm5510]

Something I was thinking about late yesterday evening: Below is a line from your work example file in the archive.

Factor=base=10,1055167,1,64

Question: Are the start and end bits of the same power, as in 10¹ to 10⁶⁴?

[MrRepunit]

Question: Are the start and end bits of the same power, as in 10¹ to 10⁶⁴?

The search boundaries are always a power of 2.

[lalera]

hi,
i tried out gr-mfaktc-0.21 with base=6, n=600k to 1000k on a gtx1050ti and the performance is good

[MrRepunit]

Originally Posted by lalera

hi,
i tried out gr-mfaktc-0.21 with base=6, n=600k to 1000k on a gtx1050ti and the performance is good

Up to 2^64 the performance should be really good because there is a special 64 bit GPU kernel. To get optimal performance you should disable the stages in mfaktc.ini:

Stages=0

If the desktop should get too unresponsive, then also lower the GPUSieveSize:

GPUSieveSize=8

[lalera]

hi,
i think that i need
stages=1
because i do use
StopAfterFactor=2
in mfaktc.ini

[storm5510]

Originally Posted by lalera

hi,
i think that i need
stages=1
because i do use
StopAfterFactor=2
in mfaktc.ini

I have used "Stages" set to zero with "StopAfterFactor" set to 2 on some tests, like the example below.

Factor=N/A,96751147,73,75

There is no separation, so if it finds a factor, it is done regardless of where it is in the process.

[storm5510]

Originally Posted by MrRepunit

...finally I completed the generalized repunit version of mfaktc.

Changes compared to mfaktc-0.21:
- implemented factoring of generalized repunits
- Removed Barrett and 72 bit kernels
- Removed Wagstaff related stuff
- Added 64 bit kernels
- Compiling with more-classes flag seem to be slightly faster, thus it is switched on
- allowed are all bases >= 2, program might crash if base is larger than roughly 100,000
- implemented special cases for bases 2, 3, 5, 6, 7, 8, 10, 11, 12
- dropped lower limit for exponents from 100,000 to 50,000

Question: Would you be willing to do a custom build for a single individual?

[MrRepunit]

Originally Posted by storm5510

Question: Would you be willing to do a custom build for a single individual?

Hi. Yes, I can do it if the wished-for changes are doable in some shorter time. My guess is that you want to lower the minimal exponent limit. Can do it, but than I cannot promise it still works in all cases. Also the program will waste more time because the presieving depth is affected.
But anyway, let me know what you need...

[storm5510]

Originally Posted by MrRepunit

Hi. Yes, I can do it if the wished-for changes are doable in some shorter time. My guess is that you want to lower the minimal exponent limit. Can do it, but than I cannot promise it still works in all cases. Also the program will waste more time because the presieving depth is affected.
But anyway, let me know what you need...

Thank you for the reply. This was just a passing thought. As time has gone by, the bottom end seems to have crept up on everything. Many are 100,000, leaving the smaller exponents with ECM and not much more. Then, on only a few programs. The downside is the time required to run the small ones to higher bit sizes.

An example: I have a very old factoring program called Factor5. It uses the CPU only. A while back, I gave it a small exponent, M1619 I believe it was. Start and end bits in the mid 60's. It stayed at 0.000% for 20 minutes or so before it changed. I did the math to 100%. Hundreds of years, or maybe thousands. So, it would not be anywhere near practical to do anything like this, even with a GPU.