mersenneforum.org Cunningham ECM efforts
 Register FAQ Search Today's Posts Mark Forums Read

2023-01-16, 23:52   #89
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

563410 Posts

Quote:
 Originally Posted by frmky 2,2194L and M are using lims of 300M (pushing the memory limit to the edge of 1GB/core but also crossing 2^28 for a small runtime hit).[...]
I think the best way to fit a larger lim into the required memory footprint is to stick to 250 or 260 on the 3LP side, and boost the lim on the 2LP side as high as memory-limits allow.

I'd go 260/340 or 250/350 and expect both yield and speed to be better than 300/300. However, I think you're reaching a job size where 3LP on both sides may be nearly as fast as the typical 2/3 settings, at least given that lims used are so small.

If you'd like to post the poly for your next job, I'm happy to test a variety of mfb choices for your 35/36 LP setting; perhaps I can find a '3LP on both sides' setting that is faster than what you're otherwise planning to use.

2023-01-19, 04:23   #90
frmky

Jul 2003
So Cal

50468 Posts

Quote:
 Originally Posted by VBCurtis I'm happy to test a variety of mfb choices for your 35/36 LP setting; perhaps I can find a '3LP on both sides' setting that is faster than what you're otherwise planning to use.
2,2206L would use
Code:
n: 385391677907023068816875399702625816359161842943133261369673832051936437247070622270782933158404692445296119872430400383813398898811140980240524745812750729966969876527198830673858429779606449065686186811518577347751947370710959080728712731829
skew: 1.54407
type: snfs
c6: 1
c5: 0
c4: 0
c3: -2
c2: 0
c1: 0
c0: 2
Y1: 1
Y0: -24519928653854221733733552434404946937899825954937634816
rlim: 300000000
alim: 300000000
lpbr: 36
lpba: 35
mfbr: 105
mfba: 71
rlambda: 3.9
alambda: 2.8
I'm planning to add a couple easy ones before queueing this one so there's some time to play with it.

 2023-01-20, 07:49 #91 pinhodecarlos     "Carlos Pinho" Oct 2011 Milton Keynes, UK 23×223 Posts Easy ones... you wouldn't say that a few years ago...lol I suppose you are talking about 2,1497+ SNFS 300 and 2,1497- SNFS 300. Glad you are doing these ones, at least I get bored of running the more difficult ones, just because I have a very slow computer and I do like to see that status page update more often. Anyway, with the overall CPU momentum available at the moment it is wise to do these quicker ones.
2023-01-20, 18:56   #92
frmky

Jul 2003
So Cal

50468 Posts

Quote:
 Originally Posted by pinhodecarlos Easy ones... you wouldn't say that a few years ago...lol ... at least I get bored of running the more difficult ones
Good point. The labels "easy" and "difficult" are relative to the computing power available.

2023-01-30, 23:02   #93
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

130028 Posts

Quote:
 Originally Posted by frmky 2,2206L would use Code: n: 385391677907023068816875399702625816359161842943133261369673832051936437247070622270782933158404692445296119872430400383813398898811140980240524745812750729966969876527198830673858429779606449065686186811518577347751947370710959080728712731829 skew: 1.54407 type: snfs c6: 1 c5: 0 c4: 0 c3: -2 c2: 0 c1: 0 c0: 2 Y1: 1 Y0: -24519928653854221733733552434404946937899825954937634816 rlim: 300000000 alim: 300000000 lpbr: 36 lpba: 35 mfbr: 105 mfba: 71 rlambda: 3.9 alambda: 2.8 I'm planning to add a couple easy ones before queueing this one so there's some time to play with it.
I've tested a bunch of alternative params, all at Q=500M so far.
3LP on both sides is good for 40% better yield, but at the expense of 60% longer sec/rel. Since you're not running out of Q to sieve, this seems unhelpful- but I'll test sec/rel at the projected "last" Q, as it's possible that 3LP on both sides for small Q (like 200-400M) may be a net benefit still.

Here are the fastest params I've found so far:
Code:
rlim: 250000000
alim: 350000000
lpbr: 36
lpba: 35
mfbr: 105
mfba: 70
rlambda: 3.85
alambda: 2.55
These yield about 2% better than the ones quoted above, but at a speed nearly 20% faster: 0.532 sec/rel vs 0.645 sec/rel.
I've tested only at Q=500M so far, so next time I have some free time I'll test a more full range of Q to make sure the new params are faster everywhere. I'll also test a couple other small variations on these params with 2LP on A side.

2023-02-01, 03:59   #94
frmky

Jul 2003
So Cal

2·3·433 Posts

Quote:
 Originally Posted by VBCurtis These yield about 2% better than the ones quoted above, but at a speed nearly 20% faster: 0.532 sec/rel vs 0.645 sec/rel. I've tested only at Q=500M so far, so next time I have some free time I'll test a more full range of Q to make sure the new params are faster everywhere. I'll also test a couple other small variations on these params with 2LP on A side.
Thanks! Amazingly, we're about done with the three smaller ones already and it's time to queue this one. It's a relatively small change in parameters, so I'm happy to just go with it and see what happens.

 2023-02-01, 06:43 #95 VBCurtis     "Curtis" Feb 2005 Riverside, CA 2×32×313 Posts I'm giving exams this week, so I can't try other tweaks to get more speed. I hope this works (better)!

 Similar Threads Thread Thread Starter Forum Replies Last Post gd_barnes Conjectures 'R Us 189 2022-12-27 23:33 gd_barnes Conjectures 'R Us 16 2014-08-07 02:11 R.D. Silverman GMP-ECM 4 2012-04-25 02:45 10metreh mersennewiki 1 2008-12-28 13:31 R.D. Silverman Factoring 63 2005-06-24 13:41

All times are UTC. The time now is 02:49.

Thu Feb 2 02:49:21 UTC 2023 up 168 days, 17 mins, 1 user, load averages: 1.24, 1.69, 1.60