mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   FermatSearch (https://www.mersenneforum.org/forumdisplay.php?f=133)
-   -   Reservations (https://www.mersenneforum.org/showthread.php?t=21412)

ET_ 2016-07-02 08:25

Reservations
 
Reserving N=35, k=470P-500P

My PC with the CUDA environment broke again. Range completed up to k=480P.

rogue 2016-12-04 23:46

2 Attachment(s)
Per my message in the other thread, I have created this file of completed ranges. It is easy enough to put as html as I wrote a program to generate it.

I have also created a file of gaps. The ranges.txt file shows what it would look like if you build ranges as I suggested. The gaps file is a list of gaps based upon those ranges. This could be due to cherry-picking or people just not being careful or people just not caring. Fortunately there are few pages for n < 10000 and it should be easy to create "most wanted" ranges from that. I do not know how much CPU/GPU power is needed to address those most wanted ranges.

ET_ 2016-12-05 11:51

[QUOTE=rogue;448396]Per my message in the other thread, I have created this file of completed ranges. It is easy enough to put as html as I wrote a program to generate it.

I have also created a file of gaps. The ranges.txt file shows what it would look like if you build ranges as I suggested. The gaps file is a list of gaps based upon those ranges. This could be due to cherry-picking or people just not being careful or people just not caring. Fortunately there are few pages for n < 10000 and it should be easy to create "most wanted" ranges from that. I do not know how much CPU/GPU power is needed to address those most wanted ranges.[/QUOTE]

Hi Mark, I am somewhat distracted in this period of time, as I am planning a move from Rome to Bergamo, and am having issues in following your idea about ranges...

You provided me with the ranges.txt file and the gaps.txt file.

Ranges.txt represents the value of the k limit where each range should be extended: such limit will be then used to deliver the next fixed-k ranges.

Gaps.txt represents the "holes" to the previous scenario, holes that should be fixed as soon as possible to grant the appropriate reservation policy.

The ranges in the gaps.txt file should be assigned and completed through the "most wanted" page.

It is auspicable that each gap had the CPU power needed for completion.

Did I get the task right? :rolleyes:

Luigi

rogue 2016-12-05 14:07

2 Attachment(s)
[QUOTE=ET_;448437]Did I get the task right?[/QUOTE]

Yes.

I hope that my suggestions are reasonable. I would like to believe that they would save you a lot of time moving forward.

I have a couple of other minor suggestions. First, for any n < 28 it appears that ECM is the best means at finding new factors. You might want to spell that out. Based upon the B1 used and the number of curves, it is unlikely that any of those numbers have unknown factors under xx digits which is well beyond the limits of trial factoring. Second, I don't think that you should waste your time managing any n >= 200000. That is what PrimeGrid is working on (for k < 10000). You can show completed work (if you want), but don't manage reservations. Most projects enforce some limits so that the project manager can maintain their sanity. You should do the same.

I have attached the program that I used to generate those files (change the extension from .txt to .c). I took the data from your website and converted to CSV (also attached) but excluded all ecm work. If anyone wants to verify correctness of the results, feel free to do so. It runs in a few minutes.

ET_ 2016-12-05 14:39

[QUOTE=rogue;448447]
I have a couple of other minor suggestions. First, for any n < 28 it appears that ECM is the best means at finding new factors. You might want to spell that out. Based upon the B1 used and the number of curves, it is unlikely that any of those numbers have unknown factors under xx digits which is well beyond the limits of trial factoring. Second, I don't think that you should waste your time managing any n >= 200000. That is what PrimeGrid is working on (for k < 10000). You can show completed work (if you want), but don't manage reservations. Most projects enforce some limits so that the project manager can maintain their sanity. You should do the same.[/QUOTE]

Suggestions accepted :smile:
Apart from Payam Samidoost, I was aware of PrimeGrid work, and stopped reservations above N > 100,000.
And I said Patrick that his work was appreciated but not quite necessary. He simply answered that 99% was not enough for him :smile:

Another consideration came to my mind...
Higher Ns (say above 6,000) would reqire a presieve of ks and a later treatment with pfgw: taking them one after the other woud be a waste of time.

Do you think the one who choose a range should do his sieving work, or do you propend for a big, global presieving of ranges, to offer selected candidates instead of complete ranges?

OK, time to do some more development. I will add some description lines to the new download page, and then start the new ranges section.

Luigi

rogue 2016-12-05 14:53

[QUOTE=ET_;448450]Another consideration came to my mind...
Higher Ns (say above 6,000) would reqire a presieve of ks and a later treatment with pfgw: taking them one after the other woud be a waste of time.

Do you think the one who choose a range should do his sieving work, or do you propend for a big, global presieving of ranges, to offer selected candidates instead of complete ranges?[/QUOTE]

I haven't thought about that and I don't have much of an opinion. If anything someone could pre-sieve the gaps for n >= 6000.

rogue 2016-12-06 14:22

I made a change to summarize the gaps more clearly. This makes the gaps appear to be much more manageable. Can you estimate the time for each range (presuming using optimal software)?

[code]
172-179 281000000000000 350000000000000
6151-6199 400000000 2500000000
10000 253000000 269000000
10001 50000000 269000000
10003-10999 50000000 269000000
14501-14999 30000000 70000000
80001-80999 80000 100000
114000-119999 40000 99999
120001-129999 30000 40000
130001-139999 20000 30000
160001-169999 15000 20000
180000 15000 30000
180001-181742 13000 30000
181744-189999 13000 30000
[/code]

ET_ 2016-12-06 15:11

[code]
172-179 281000000000000 350000000000000 [COLOR="Red"]615 days with Feromant_CUDA[/COLOR]
6151-6199 400000000 2500000000 [COLOR="Red"]1500 days with a single-core pmfs[/COLOR]
10000 253000000 269000000 [COLOR="Red"]19 hours with a single-core pmfs[/COLOR]
10001 50000000 269000000 [COLOR="Red"]11 days with a single-core pmfs[/COLOR]
10003-10999 50000000 269000000 [COLOR="Red"]5913 days with ppsieve_cuda & pfgw[/COLOR]
14501-14999 30000000 70000000 [COLOR="Red"]640 days with ppsieve_cuda & pfgw[/COLOR]
80001-80999 80000 100000 [COLOR="Red"]150 days with ppsieve_cuda & pfgw[/COLOR]
114000-119999 40000 99999 [COLOR="Red"]12 years with ppsieve_cuda and pfgw[/COLOR]
120001-129999 30000 40000 [COLOR="Red"]4 years with ppsieve_cuda & pfgw[/COLOR]
130001-139999 20000 30000 [COLOR="Red"]5 years with ppsieve_cuda & pfgw[/COLOR]
160001-169999 15000 20000 [COLOR="Red"]3 years with ppsieve_cuda & pfgw[/COLOR]
180000 15000 30000 [COLOR="Red"]no data available[/COLOR]
180001-181742 13000 30000 [COLOR="Red"]no data available[/COLOR]
181744-189999 13000 30000 [COLOR="Red"]no data available[/COLOR]
[/code]

rogue 2016-12-06 16:36

[QUOTE=ET_;448583][code]
172-179 281000000000000 350000000000000 [COLOR="Red"]615 days with Feromant_CUDA[/COLOR]
6151-6199 400000000 2500000000 [COLOR="Red"]1500 days with a single-core pmfs[/COLOR]
10000 253000000 269000000 [COLOR="Red"]19 hours with a single-core pmfs[/COLOR]
10001 50000000 269000000 [COLOR="Red"]11 days with a single-core pmfs[/COLOR]
10003-10999 50000000 269000000 [COLOR="Red"]5913 days with ppsieve_cuda & pfgw[/COLOR]
14501-14999 30000000 70000000 [COLOR="Red"]640 days with ppsieve_cuda & pfgw[/COLOR]
80001-80999 80000 100000 [COLOR="Red"]150 days with ppsieve_cuda & pfgw[/COLOR]
114000-119999 40000 99999 [COLOR="Red"]12 years with ppsieve_cuda and pfgw[/COLOR]
120001-129999 30000 40000 [COLOR="Red"]4 years with ppsieve_cuda & pfgw[/COLOR]
130001-139999 20000 30000 [COLOR="Red"]5 years with ppsieve_cuda & pfgw[/COLOR]
160001-169999 15000 20000 [COLOR="Red"]3 years with ppsieve_cuda & pfgw[/COLOR]
180000 15000 30000 [COLOR="Red"]no data available[/COLOR]
180001-181742 13000 30000 [COLOR="Red"]no data available[/COLOR]
181744-189999 13000 30000 [COLOR="Red"]no data available[/COLOR]
[/code][/QUOTE]

Fortunately some of those should be really easy to knock off. Sounds like a task for Gary. What do you mean by "no data available"? the 180000 line for 15000 to 30000 should be doable in less than a day. Are the pfgw times for a single core?

feromant 2016-12-06 16:38

[QUOTE=ET_;448583][code]
172-179 281000000000000 350000000000000 [COLOR=Red]615 days with Feromant_CUDA[/COLOR]
6151-6199 400000000 2500000000 [COLOR=Red]1500 days with a single-core pmfs[/COLOR]
10000 253000000 269000000 [COLOR=Red]19 hours with a single-core pmfs[/COLOR]
10001 50000000 269000000 [COLOR=Red]11 days with a single-core pmfs[/COLOR]
10003-10999 50000000 269000000 [COLOR=Red]5913 days with ppsieve_cuda & pfgw[/COLOR]
14501-14999 30000000 70000000 [COLOR=Red]640 days with ppsieve_cuda & pfgw[/COLOR]
80001-80999 80000 100000 [COLOR=Red]150 days with ppsieve_cuda & pfgw[/COLOR]
114000-119999 40000 99999 [COLOR=Red]12 years with ppsieve_cuda and pfgw[/COLOR]
120001-129999 30000 40000 [COLOR=Red]4 years with ppsieve_cuda & pfgw[/COLOR]
130001-139999 20000 30000 [COLOR=Red]5 years with ppsieve_cuda & pfgw[/COLOR]
160001-169999 15000 20000 [COLOR=Red]3 years with ppsieve_cuda & pfgw[/COLOR]
180000 15000 30000 [COLOR=Red]no data available[/COLOR]
180001-181742 13000 30000 [COLOR=Red]no data available[/COLOR]
181744-189999 13000 30000 [COLOR=Red]no data available[/COLOR]
[/code][/QUOTE]

I don't agree with the assessment of execution time of the first range. 24/7 Feromant_CUDA will require approximately 35 days. But mmff will count faster, it will take approximately 15 days

ET_ 2016-12-06 16:52

[QUOTE=feromant;448594]I don't agree with the assessment of execution time of the first range. 24/7 Feromant_CUDA will require approximately 35 days. But mmff will count faster, it will take approximately 15 days[/QUOTE]

From the data you sent me, it seems that Feromant_CUDA elaborates about 9.1 million k per second at N=175.

(350000000000000−281000000000000)×(179−172) = 4,83×10¹⁴ total k
(4,83×10¹⁴)÷9100000 = 53076923,076923077 seconds

53076923,076923077 / 86400 ) = 614,316239316 days.

Where did I go wrong? :smile: [COLOR="Red"]My BAD[/COLOR] I read Feromant instead of Feromant_CUDA values :redface: Sorry Roman you are right, and 35 days is correct.

mmff can't be used for such N and k, because of the bit depth of kernels.

Luigi


All times are UTC. The time now is 10:43.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.