mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Msieve (https://www.mersenneforum.org/forumdisplay.php?f=83)
-   -   Polynomial Request Thread (https://www.mersenneforum.org/showthread.php?t=18368)

VBCurtis 2013-10-07 17:56

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.

jasonp 2013-10-07 20:14

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.

RichD 2013-10-07 21:47

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:

wombatman 2013-10-08 02:04

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]

debrouxl 2013-10-08 05:37

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.

sashamkrt 2013-10-08 06:40

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]

sashamkrt 2013-10-08 13:18

ะก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]

wombatman 2013-10-08 14:13

Wow! Very nice finds!

VBCurtis 2013-10-09 03:28

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

sashamkrt 2013-10-09 04:45

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]

LaurV 2013-10-09 06:47

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