![]() |
[QUOTE=storm5510;529500]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.
[/QUOTE]So, the ~30% performance loss in gr-mfaktc relative to mfaktc means Mersenne factorers should stick with the mainstream mfaktc. |
[QUOTE=kriesel;529549]So, the ~30% performance loss in gr-mfaktc relative to mfaktc means Mersenne factorers should stick with the mainstream mfaktc.[/QUOTE]
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... |
Something I was thinking about late yesterday evening: Below is a line from your work example file in the archive.
[CODE]Factor=base=10,1055167,1,64[/CODE]Question: Are the start and end bits of the same power, as in 10[SUP]1[/SUP] to 10[SUP]64[/SUP]? |
[QUOTE]Question: Are the start and end bits of the same power, as in 10[SUP]1[/SUP] to 10[SUP]64[/SUP]?[/QUOTE]
The search boundaries are always a power of 2. |
hi,
i tried out gr-mfaktc-0.21 with base=6, n=600k to 1000k on a gtx1050ti and the performance is good |
[QUOTE=lalera;530497]hi,
i tried out gr-mfaktc-0.21 with base=6, n=600k to 1000k on a gtx1050ti and the performance is good[/QUOTE] 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: [CODE]Stages=0[/CODE] If the desktop should get too unresponsive, then also lower the GPUSieveSize: [CODE]GPUSieveSize=8[/CODE] |
hi,
i think that i need stages=1 because i do use StopAfterFactor=2 in mfaktc.ini |
[QUOTE=lalera;530514]hi,
i think that i need stages=1 because i do use StopAfterFactor=2 in mfaktc.ini[/QUOTE] I have used "Stages" set to zero with "StopAfterFactor" set to 2 on some tests, like the example below. [CODE]Factor=N/A,96751147,73,75[/CODE] There is no separation, so if it finds a factor, it is done regardless of where it is in the process. |
[QUOTE=MrRepunit;529384]...[COLOR=Gray]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[/COLOR] [B]- dropped lower limit for exponents from 100,000 to 50,000 [/B] [/QUOTE] [U]Question[/U]: Would you be willing to do a custom build for a single individual? |
[QUOTE=storm5510;532794][U]Question[/U]: Would you be willing to do a custom build for a single individual?[/QUOTE]
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... |
[QUOTE=MrRepunit;532944]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...[/QUOTE] 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. |
All times are UTC. The time now is 02:14. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.