GNFS estimates

[10metreh]

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!

[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. I guess you're thinking the cat time is statistically insignificant?

[schickel]

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.

[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.

[10metreh]

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.

[schickel]

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.

[schickel]

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.....

[henryzz]

one change that might be worth doing would be if you use more than 1 thread doing more q values per batch

[Joshua2]

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?

[Batalov]

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!

[Joshua2]

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.