![]() |
![]() |
#1 |
"Curtis"
Feb 2005
Riverside, CA
131268 Posts |
![]()
Attached are new params files for C95 through C130.
I'm still confused about my test results for C135-C145, so I continue to test. Params for C150+ jobs are scattered around this subforum- once I get good drafts posted up to C145, I'll collect the best guesses we have so far on C150+ into a new set of files in this thread. I welcome A/B testing of factory settings and these settings- if we show clear speed gains on a variety of hardware, then we can submit these to the CADO group for inclusion as future "factory" settings. A summary of wall-clock time for factory vs new params file is all we need on these small files. |
![]() |
![]() |
![]() |
#2 |
"Curtis"
Feb 2005
Riverside, CA
2·3·953 Posts |
![]()
Wall-clock timing comparison on a Ryzen 5950, CADO version current git as of May '22:
RSA-100 Factory 343 sec Improved 180 sec #Factory poly search is deg 4 RSA-110 Factory 536 sec Improved 555 sec #hrmmm, improved? RSA-120 Factory 2016 sec Improved 1678 sec Last fiddled with by VBCurtis on 2022-09-14 at 17:24 Reason: added rsa-120 data |
![]() |
![]() |
![]() |
#3 |
Jun 2012
7×557 Posts |
![]()
A/B testing on an idle i7-3770S CPU @ 3.10GHz (Ivy Bridge), 32 Gb RAM, Windows 10 using Ubuntu 18.04 LTS, CADO installed late Aug 2022, using random composites found in factordb:
c90 571182163113957287170179806750737837113436761259235360848031582728863975649824460077229603 Factory - 2683 seconds, Improved - 1777 seconds c92 44577254493130764909193544753471835604872768288806087823258523406159832841077062167087180397 Factory - 3275 seconds, Improved - 2173 seconds c95 61678211188677863570157133010819984802060134393238837081832540114742617862791150282895502269369 Factory - 4152 seconds, Improved - 2930 seconds c100 3026995565521796176841046970188026667837386421497914848140699810836615249355620806152722969475594003 Factory - 8922 seconds, Improved - 6234 seconds c105 349146070982960202561848166250693288094792170771592377901684145676723080820817407502131216515530304977117 Factory - 14827 seconds, Improved - 10495 seconds c110 54559505794893210575630412396836182993659417080441518746765185717148940515062581106037049619993173736599367017 Factory - 24974 seconds, Improved 22697 seconds c115 2693818177394916277639013170129551006330371999162847185623364054776531064764732471565819889978176436301757113870687 Factory - 49954 seconds, Improved - 39247 seconds c120 217221355657878614893196197864671541103658421873582813009356933764214657538563824989226987509276923860046855162176551141 Factory - 84009 seconds, Improved - 70669 seconds c125 69921965218695300207302836905717351598843625309602892595999904890558896412757214218189594809196012224191740893445726272198253 Factory - 177016 seconds, Improved - 138895 seconds c130 4274423118885919346909105300287512500348793228681071392161725722181403752611150880697482969247877547695528710043215870640174290209 Factory - 362497 seconds, Improved - 257333 seconds Last fiddled with by swellman on 2022-09-04 at 20:45 |
![]() |
![]() |
![]() |
#4 |
"Curtis"
Feb 2005
Riverside, CA
2×3×953 Posts |
![]()
Here are "draft" files for C135 through C150. Timings using these files are within 5-7% of the trendline established by C100-C130 files in post #1, and I'll keep playing with settings to try to get that last few percentage points.
This .zip file will contain the most up-to-date settings I have; if I update a file I'll change the date in the .zip name. EDIT: Jan '23 I think I've hit the trendline for C135-C155, and a variety of small changes yielded no further speed improvements. Last fiddled with by VBCurtis on 2023-01-11 at 04:42 |
![]() |
![]() |
![]() |
#5 |
If I May
"Chris Halsall"
Sep 2002
Barbados
256618 Posts |
![]() |
![]() |
![]() |
![]() |
#6 |
"Curtis"
Feb 2005
Riverside, CA
2×3×953 Posts |
![]()
I don't know what you're asking, Chris.
If you mean you don't know why they're distributed here rather than with CADO, I'm working on that. |
![]() |
![]() |
![]() |
#7 | |
If I May
"Chris Halsall"
Sep 2002
Barbados
5×2,237 Posts |
![]() Quote:
I guess fundamentally I'm wondering how far along the automation of Work Units for all the various different projects is/are. I've been a bit spoilt by PrimeNet and its API. Remarkably advanced, even by today's standards (often better). I joined GIMPS after Primenet was online and the clients were doing IPC. Before that, I understand George used to distribute WUs by way of emails. A similar thing used to be done with TF'ing when the GPU code paths first manifested. Never send a human to do a machine's job... ![]() |
|
![]() |
![]() |
![]() |
#8 |
"Curtis"
Feb 2005
Riverside, CA
2×3×953 Posts |
![]()
Post #4 contains updated params for C135 through C155. There may still be a bit more to find at C150, as C155 is below the trendline but C150 is not. I'd rather explore C160+ this year.
At C160, 3 large primes start to sieve faster but with a much larger matrix- I think at that size whether to use 3LP depends on whether one is using msieve for the matrix (use 3LP) or CADO (use 2LP to save matrix time). That tradeoff depends also on machine architecture- some are relatively faster at matrices than others. Once I do more testing, I plan to post fastest 2LP sieve params as well as fastest 3LP params, so individual testers can try both and choose. |
![]() |
![]() |
![]() |
#9 |
"Curtis"
Feb 2005
Riverside, CA
2×3×953 Posts |
![]()
Attached is a C160 params file using 3LP, intended for those who use msieve for postprocessing. These params sieve about 25% faster than my best 2LP, but more relations are needed to build a reasonable matrix.
Folks like Ed who use a GPU for matrix-solving and just want to get a matrix as early as possible will likely find 225-240M relations are enough. Folks running msieve on CPU for LA may wish to experiment with rels_wanted: I'm using 255M based testing of just two jobs. C158 should get a matrix around 6M, while C161-162 will likely be around 7M size with msieve TD of 100-110. Those using CADO start-to-finish might want to adopt the poly select from this file, but use 2LP sieve settings to get a matrix that solves in less than 1/3 the time it takes to sieve. Using the attached 3LP sieve settings with CADO for matrix should target 270M relations (or more- I tried 260M for a C158 and decided more sieving would help). Msieve matrix-solving is nearly twice as fast as CADO for the same relations set- at this size, that's a meaningful time savings. I have not yet done a thorough test-sieve with a C165 to make the next-size-up params file, but a reasonable guess would be to add 25-30% to each lim, add 1 to mfb1, add 0.03 to lambda1, add 5-10% to rels_wanted, and add the same percentage to q-min that you added to lim1 (that is, make qmin a bit under 20% of lim1). When I start testing C165s, I'll try these settings against whatever we've developed in the c165-175 thread. Last fiddled with by VBCurtis on 2023-03-10 at 22:28 Reason: added note about matrix solving speed comparison |
![]() |
![]() |
![]() |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Improved params files for CADO | VBCurtis | CADO-NFS | 105 | 2022-09-17 14:19 |
CADO params and q range | mathwiz | CADO-NFS | 8 | 2022-04-27 20:22 |
Improved NFS polynomial selection | jasonp | Operation Kibibit | 5 | 2014-09-07 11:02 |
could oddperfect's ecm progress page be improved? | jasong | GMP-ECM | 11 | 2007-05-30 03:08 |
Factoring progress has really improved! | eepiccolo | Lone Mersenne Hunters | 3 | 2003-04-12 02:04 |