Reserved for MF - Sequence 4788

[EdH]

I'm getting a really poor relations ratio. I'm seeing less than 85k relations per 100k q. Is this a sign of a poor polynomial, or does this just happen sometimes?

I had one machine working the polynomial while my main one is running the ECM and now that I have a candidate, I have several machines running with it while the main one finishes ECM. At this point, would a restart with a better poly make a big enough difference to warrant running a few more hours of selection?

Here's a bit of the log:

Sat Dec 29 10:27:50 2012  expecting poly E from 2.16e-11 to > 2.49e-11
Sat Dec 29 10:27:50 2012  searching leading coefficients from 1 to 2846669
Sat Dec 29 15:27:48 2012  polynomial selection complete
Sat Dec 29 15:27:48 2012  R0: -1728427528919286628495180538
Sat Dec 29 15:27:48 2012  R1: 30361745983217
Sat Dec 29 15:27:48 2012  A0: 27794688864805293268138545836950245
Sat Dec 29 15:27:48 2012  A1: 41756348327044212147658721274
Sat Dec 29 15:27:48 2012  A2: -54605224849948984856272
Sat Dec 29 15:27:48 2012  A3: -24857135575026902
Sat Dec 29 15:27:48 2012  A4: 5603890979
Sat Dec 29 15:27:48 2012  A5: 276
Sat Dec 29 15:27:48 2012  skew 3199130.95, size 2.219e-13, alpha -5.811, combined = 2.596e-11 rroots = 5

[Dubslow]

I'll run some GPU stage 1. Do you know how many hits you got in those five hours?

Edit: Perhaps the ggnfs parameters are off?

Edit2: YAFU (it's probably msieve's data) suggests around 50 CPU hours of poly select, so unless you were running 8 cores or something, that's probably a woefully bad poly. How many core hours total did you run?

[EdH]

Originally Posted by Dubslow

I'll run some GPU stage 1. Do you know how many hits you got in those five hours?

Edit: Perhaps the ggnfs parameters are off?

Edit2: YAFU (it's probably msieve's data) suggests around 50 CPU hours of poly select, so unless you were running 8 cores or something, that's probably a woefully bad poly. How many core hours total did you run?

Thanks!

It had suggested 54.59 CPU-hours, but I had factmsieve.py set with a wall time of 5 hours with dual core, so it was definitely cut prematurely. The question would be the difference in working with a poor poly that was obtained at 5 hours vs. a better poly that took 30 hours. At a total of 50 hours estimate for sieving, I'm not sure if a better poly would have made it faster overall.

There are 4985 polynomials in the test.dat.p file.

Over the last five hours I've accumulated >2.5M relations across all my machines with this poly, so I should be able to reach the 22M requested in roughly 45 more hours. Unless restarting with a better poly would make up the difference, it probably isn't worth restarting for this size composite. But, for something larger, I should try to be more particular in my poly choice, I suppose.

Edit: Don't tie up your systems for this. I'll get along with what I have here. I was just wondering...

[Dubslow]

Originally Posted by EdH

Edit: Don't tie up your systems for this. I'll get along with what I have here. I was just wondering...

I got 2.4 million stage 1 hits in 45 minutes, size opt running now, will have (probably a significantly better) poly sometime in the next hour or two.

[EdH]

Originally Posted by Dubslow

I got 2.4 million stage 1 hits in 45 minutes, size opt running now, will have (probably a significantly better) poly sometime in the next hour or two.

I'm not sure it would benefit me to start over at this point, but I would like to compare the results between our two poly's on a couple of my machines...

[Dubslow]

Holy bejeesus, root opt takes forever. Out of the 2.4M hits I got 860K size opt polys (took about an hour on cpu vs 45 minutes for stage 1 on gpu). I sorted them and am running root opt on the best 86K of them; 2+ hours in and I have 12.7K root opt-ed polys, so who knows how long it'll take. I'll post the best in the morning, but in the meantime, there's probably no way it'll be advantageous to switch.

[debrouxl]

You're processing too many size optimized polys, only 1-2% of them are useful
And using the out-of-tree MPI patch makes root opt scale near-linearly with the number of cores.

[Dubslow]

Originally Posted by debrouxl

You're processing too many size optimized polys, only 1-2% of them are useful
And using the out-of-tree MPI patch makes root opt scale near-linearly with the number of cores.

Ah crap, now I know for next time. Those 10% took 19 hours

polynomial selection complete
R0: -1275730550910569740948790967
R1: 68465311488443
A0: -602386029120087908552165345576724184
A1: 511077501414883308580053270504
A2: 163159912488603352570952
A3: -74272054904151261
A4: -11596854544
A5: 1260
skew 4253756.85, size 2.156e-13, alpha -7.219, combined = 2.577e-11 rroots = 5
elapsed time 19:32:47

I'm not exactly sure how to get second or third place poly easily, since it's more than one line per poly.

Edit: And it's not even as good as the first one (Edit2: Since the first one sieves so poorly, maybe this one sieves better despite the scores)

[EdH]

I will have to test your poly for a comparison on one of my machines, but I'm going to wait until the current operation is completed.

Thanks for the extra work you did.

[EdH]

LA says a few more hours...

I compared the two polynomials by running them side by side in one of my dual core machines:

My poly - Total time: 9:38:09 - Total yield: 463002

Dubslow's poly - Total time: 9:46:48 - Total yield: 529197

Would there have been any appreciable affect on the LA stage between the different sets of relations?

[EdH]

OK, looks like that one finished and now I'm running a c106 that should be done soon...