Yafu

[Karl M Johnson]

How long does it take for tune() get results ?
On, say, a quad core Kentsfield CPU, clocked at 3 Ghz ?

I am too anxious to let it finish

[bsquared]

Originally Posted by Karl M Johnson

How long does it take for tune() get results ?
On, say, a quad core Kentsfield CPU, clocked at 3 Ghz ?

I am too anxious to let it finish

Half hour maybe? I've never timed it before, but that sounds like the right ballpark.

You probably already know this but note that you don't need to do that before using YAFU. The tune results are used exclusively with the factor() function, and there are fallbacks and defaults which will allow it to work without doing tune() (although not optimally).

Glad to see the excitement :)

[bsquared]

I just fixed a pretty important bug. Multi-threaded poly selection works just fine, but at the end of the process a simple parser that crawls through the .p file failed to pick the best poly! It picked the last poly instead.

Apologies... but please re-download. The version number in the splash text should now read 1.26.2.

Also added printout of poly and poly score to screen with -v (and to logfile always).

[Andi_HB]

Originally Posted by bsquared

I just fixed a pretty important bug. Multi-threaded poly selection works just fine, but at the end of the process a simple parser that crawls through the .p file failed to pick the best poly! It picked the last poly instead.

Apologies... but please re-download. The version number in the splash text should now read 1.26.2.

Also added printout of poly and poly score to screen with -v (and to logfile always).

That was the reason because i asked for printed Poly before sieving begins.
But i was not sure my last poly was not better then all others - havent looked to all the other polys.
Good work Ben!

[Karl M Johnson]

tune() failbus.

However, it did add this into config file:

tune_info=Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz,WIN64,1.01027e-005,0.198339,9.14428,0.0800717,115.973,2902.24

So, I guess it's fine, even though it crashed in the end ?

[bsquared]

Yep, as long as that line is printed it worked. I remember now I was supposed to look into that... but it is lower priority since the failure is Mostly Harmless.

[Karl M Johnson]

Did a little polyselect benchmark.
Used this generated composite: 41180548594326928809733023289258411737544928004632013025004323518841883602798867461437.
Picked range 1 to 10000.
Used timethis for measuring timings.

1 thread : 192.161 sec
2 threads: 104.925 sec
4 threads:  59.623 sec

Good, good.

[bsquared]

Originally Posted by Karl M Johnson

Did a little polyselect benchmark.
Used this generated composite: 41180548594326928809733023289258411737544928004632013025004323518841883602798867461437.
Picked range 1 to 10000.
Used timethis for measuring timings.

1 thread : 192.161 sec
2 threads: 104.925 sec
4 threads:  59.623 sec

Good, good.

Great! Do you know if similar polynomials were found in each case?

[Karl M Johnson]

Actually, I've checked, yes, the best polynomial was completely the same in all 3 cases.

[bsquared]

Cool.

I just did an experiment with "-psearch wide" on your same number. Here are the differences in polynomials found with fast versus wide:

best poly (fast): # norm 8.648583e-012 alpha -4.654561 e 8.298e-008 rroots 2
best poly (wide): # norm 1.045943e-011 alpha -4.565446 e 9.112e-008 rroots 2

The better poly sieves slightly faster, but probably not enough to make up the difference in poly search time. But that's with this c86 input... I bet it's a more interesting comparison with a C110+. I'll try that out too.

[bsquared]

A comparison of "-psearch fast" and "-psearch wide" on a c110 was inconclusive... although "wide" searched 6x (using 6 threads and taking an hour versus 10 min) the range of leading coefficients, the best polynomial was the same in both cases. I wouldn't expect this to always be the case though...

Trying on a c120.