mersenneforum.org GNFS estimates
 Register FAQ Search Today's Posts Mark Forums Read

2009-04-05, 07:31   #34
10metreh

Nov 2008

91216 Posts

Quote:
 Originally Posted by Joshua2 Ok, what I thinking is that I start 0.9M-1.2M maybe, and then go up by what it was before both for filtering and msieve like 1.3-1.4M next. Have you done any experimenting to see how many relations it needs compared to what it thinks?
In my experience, a C100 needs about 3.7-3.8M relations, sieved from 0.9-1.4M. With my factMsieve.pl adjustment, this will run 0.9-1M, then cat, 1-1.1M, cat again, 1.1-1.2M, cat again, 1.2M-1.3M, cat and then msieve for the first time, 1.3-1.4M, cat, and then msieve for the final factorization. Meeeaow!

Last fiddled with by 10metreh on 2009-04-05 at 07:31

 2009-04-05, 07:35 #35 Joshua2     Sep 2004 53310 Posts Ok, I'm thinking a little better would be 0.9-1.35M msieve, if fail 1.35-1.4M msieve if fail 1.4-1.45M msieve, or something along those lines, to not do cat or msieve until necessary, and then do smaller qsteps. I guess you're thinking the cat time is statistically insignificant? Last fiddled with by Joshua2 on 2009-04-05 at 07:41
2009-04-05, 07:41   #36
schickel

"Frank <^>"
Dec 2004
CDP Janesville

2·1,061 Posts

Quote:
 Originally Posted by Joshua2 Ok, I'm thinking a little better would be 0.9-1.35M msieve, if fail 1.35-1.4M msieve if fail 1.4-1.45M msieve, or something along those lines, to not do cat or msieve until necessary, and then do smaller qsteps.
That's going to take some reworking of the script. Basically the script just uses the "Q size" to increment the starting value of the Q-range each time through the loop.

Last fiddled with by schickel on 2009-04-05 at 07:42 Reason: Better wording....

 2009-04-05, 07:42 #37 Joshua2     Sep 2004 13×41 Posts I figure it is in a loop like while(not factored) new q step. I'm thinking pull out a "2*q step" of the loop to do first before it starts the loop.
2009-04-05, 07:45   #38
10metreh

Nov 2008

2×33×43 Posts

Quote:
 Originally Posted by Joshua2 I figure it is in a loop like while(not factored) new q step. I'm thinking pull out a "2*q step" of the loop to do first before it starts the loop.
No difference - the only thing is cat, and that only takes seconds. It already effectively sieved 0.9M-1.1M in one batch. With my adjustment, it effectively sieves 0.9M-1.3M in one batch.

Last fiddled with by 10metreh on 2009-04-05 at 07:46

2009-04-05, 07:49   #39
schickel

"Frank <^>"
Dec 2004
CDP Janesville

2·1,061 Posts

Quote:
 Originally Posted by Joshua2 I figure it is in a loop like while(not factored) new q step. I'm thinking pull out a "2*q step" of the loop to do first before it starts the loop.
Actually it would be more like a repeat {loop} until factored; as written, it's stateless in the main loop. The main body of the script sets the start Q-value and the Q-step then enters the main loop. That way, if you interrupt the script, upon restart it will find an existing set of job files and pick up where it left off, not caring whether or not it's on the first time through or not....

As I said, it's doable, just needs a little reworking.

2009-04-05, 07:55   #40
schickel

"Frank <^>"
Dec 2004
CDP Janesville

212210 Posts

Quote:
 Originally Posted by 10metreh No difference - the only thing is cat, and that only takes seconds. It already effectively sieved 0.9M-1.1M in one batch. With my adjustment, it effectively sieves 0.9M-1.3M in one batch.
Actually, 10metreh's way is probably better. For small factorizations it's such a small time to sieve a range that changing the Q-step wouldn't have that big an impact. For bigger jobs, you have to consider the time spent on each range. For my current NFS rig, a c120 with Q-step set at 100k takes ~4 hours for each range. If I double that to 200k, that means each would take ~8 hours. It's XP so that's probably OK, but my main rig before was 98, so if it crashed because of a power outage, it would most likely lose the sieved range.....

Last fiddled with by schickel on 2009-04-05 at 08:15 Reason: Entered wrong times the first time......

 2009-04-05, 12:17 #41 henryzz Just call me Henry     "David" Sep 2007 Liverpool (GMT/BST) 37×163 Posts one change that might be worth doing would be if you use more than 1 thread doing more q values per batch
2009-04-05, 16:29   #42
Joshua2

Sep 2004

10258 Posts

Quote:
 Originally Posted by henryzz one change that might be worth doing would be if you use more than 1 thread doing more q values per batch
Is that saying increase qstep in the def-par? So I have a quad core, does that mean say double the qstep?

Also, why is the 0.2 not changed to 0.4 in the pl script already iin the minrel section? Has anyone ever had msieve succeed on the first time with the original pl script?

Last fiddled with by Joshua2 on 2009-04-05 at 16:52

 2009-04-05, 22:19 #43 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 32×1,117 Posts It is great that you are getting the gist of it. Which is -- the script is entirely yours. The better you know your weapon, the better is your fight (against numbers). The reason 0.2 is in the public version code is that with this value, the script (almost) never fails... 0.2 is needed for small numbers. (There's a comment just next to that line.) Invariably, everyone will later find failing cases, when they will say "who put 0.4 here? it doesn't work. 0.2 is needed." As for the last message - yes, you are on the right track, too. You will soon write your own scripts that will work differently. (A couple of ideas - with a few tricks: you can avoid thread idle states, i.e. when 3 threads are waiting for the last one. Make them all separate, use sh, use python!) The factMsieve.pl is just a starting point, and don't forget to thank Greg! You know, it's one thing to write the script (thank you, Greg!); it's a completely another to make it work always, and make it better too... Neither he nor anyone else signed for this (myself included). I cannot speak for the other contributors, but I only add something that "first, does no harm" and only then does some good. Keep the factors coming!
 2009-04-06, 00:10 #44 Joshua2     Sep 2004 13·41 Posts By small do you mean smaller than say 95 digits? That's the size I was doing, and 0.4 worked fine (better). Smaller than that is undoubtedly less than the crossover point w/ siqs. Even the 95 took a bit longer w/ NFS, which is why I was trying to optimize it to see if I can get it faster. I mostly need the 64-bit w/ assembly for win x64 though.

 Similar Threads Thread Thread Starter Forum Replies Last Post henryzz GMP-ECM 8 2009-12-31 17:51 Andi47 Msieve 5 2009-01-26 18:19 brownkenny Math 2 2009-01-22 17:21 henryzz Msieve 27 2009-01-21 18:37 kdq Software 4 2008-10-04 05:02

All times are UTC. The time now is 18:02.

Tue Jan 31 18:02:58 UTC 2023 up 166 days, 15:31, 0 users, load averages: 1.20, 1.20, 1.16