![]() |
Why are you using anything other than sec/rel to judge a poly? Isn't the point of finding a good poly to find one that takes less time to perform the factorization?
#5 performs quite a lot faster than #1 or #2. What am I missing here? Also, as firejuggler pointed out, comparisons are not made vs E-score here- #1 has a 5% higher score, but sieves ~6% faster. However, #5 scores 4% worse than #1 while sieving 4% faster. |
If none of the other parameters are changed, then seconds per relation is the correct measure. If you optimize the other parameters (e.g. factor base limits or special-q range) separately for each polynomial, then you have to use the total estimated sieving time.
|
In a perfect world, sec/rel would seem reasonable. There is an overhead in starting each range, something around 15 seconds before the first relation is recorded. That's why it is better to take a few million Qs per core at a time. With the relatively small work units (WU) of NFS@Home I believe [B]debrouxl[/B] is trying to balance the trade-off. I usually look for yield ratio to minimize the WUs. (Assuming all other parameters are the same.) Perhaps [B]debrouxl[/B] has more to say because he has been doing this longer than me. :smile:
|
New best from my search for the C168:
[CODE]polynomial selection complete R0: -137982521622728045011243408554463 R1: 1339655601011561771 A0: 42456904591149864315136445197306375920560 A1: 30670859550417145194573777446486006 A2: -7650991139046352760036346229 A3: -1045673741543574747132 A4: 146948730229980 A5: 10371600 skew 7295400.25, size 1.914e-016, alpha -7.572, combined = 4.147e-013 rroots = 5[/CODE] And a 2nd one that's not quite as good: [CODE]# norm 2.121910e-016 alpha -7.656116 e 3.927e-013 rroots 5 skew: 7644763.78 c0: 71758833171721317865765888880885183510775 c1: 49536046266198119164296136514381007 c2: -90590297181877360519419115 c3: -2765515707324151868651 c4: 68394972845396 c5: 10119900 Y0: -138662170971500796224221234208258 Y1: 347372753308990319[/CODE] |
For the C166, #5 did indeed sieve ~13.3% faster than #2, but produced ~14.4% fewer relations on the range of 1K relations, so it's not significantly better or worse.
|
C168 poly
[CODE]
n: 518759670509518390499884894142825232305789370205934770356684820953606669616234831388561087386018771667622991938328056602692240129084683654895676978808741395629768407883 # norm 2.390778e-016 alpha -7.157296 e 4.234e-013 rroots 5 skew: 19835022.68 c0: -14766991706078551413874024151190708222720 c1: 16481308623853322795154573138777216 c2: 8711799723929349110308763068 c3: 203660963131057337068 c4: -19625244765905 c5: 108528 Y0: -343466912683455792965746434341297 Y1: 550334592933944653 [/CODE] |
ะก168 polynoms with good scores and not so good skews
[CODE]
# norm 2.880607e-016 alpha -8.201338 e 4.765e-013 rroots 5 skew: 89100677.43 c0: -27857995650530594214542724173490926656056000 c1: 489092174862742972528340289017184040 c2: 30770925245570759449861491874 c3: -51337377580050003917 c4: -4407409358582 c5: 10200 Y0: -551154318026277087308020573543333 Y1: 109459496504263717 # norm 2.578144e-016 alpha -7.900994 e 4.453e-013 rroots 5 skew: 89152497.21 c0: -25294409365820382440286805545396176373535995 c1: 542383637474412430010304925218961429 c2: 30617383334984154264021694081 c3: -66563245603254143525 c4: -4363140797582 c5: 10200 Y0: -551154317931265040287858120286446 Y1: 109459496504263717 [/CODE] |
Wow! Very nice finds!
|
[QUOTE=debrouxl;355575]For the C166, #5 did indeed sieve ~13.3% faster than #2, but produced ~14.4% fewer relations on the range of 1K relations, so it's not significantly better or worse.[/QUOTE]
Can you help me understand why you care about how many special-Q you need to search? I believe you're saying #5 will need 14% (or 100/86, which is more than 14%) more special-Q searched in order to produce the required number of relations, but even after taking that extra 14% into account that it will finish 13% faster than #2. The sec/rel is time per relation found, NOT time per special-Q searched. It looks to me like you're confusing the two. The only time I see this having importance is when we're already stretching a version of the siever, and might run out of special-Q. That's not nearly the case here, is it? |
C168 poly
[CODE]
# norm 2.790210e-016 alpha -6.156376 e 4.506e-013 rroots 3 skew: 12473534.14 c0: 516236450022905700097829298234459693015 c1: 1155256345148460315833790376537509 c2: 801505740961731706078779054 c3: 187904124865251487543 c4: -5004361126321 c5: 21240 Y0: -475951112043062447304070700973752 Y1: 167570844707882773 [/CODE] |
[QUOTE=VBCurtis;355702]Can you help me understand ...[/QUOTE]
He says that in the same period of time, one guy runs 100 meters throwing out into the public one dollar at every 10 meters he runs, and the second guy runs 133 meters (13.3 % faster) but spitting one dollar every 14.6 meters (14.6% slower). At the end, the public collects 10 or 11 dollars from the first guy (depending where the thrown out the first dollar), and 10 or 11 from the second (again, depending on the luck), so there is no relevant comparison between the productivity of the two guys. |
| All times are UTC. The time now is 22:30. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.