mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Aliquot Sequences

Reply
 
Thread Tools
Old 2010-11-05, 15:09   #144
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

3,253 Posts
Default

Once this iteration is factored, is it a free-for-all to factor the next? Or, is there some coordinated effort to perform the (hopefully) trivial factoring of the next few composites?

Would it be rude for those not post-processing to still run curves, or just time wasting. If a factor was happened upon, via the additional curves, would that be good or bad?

I am not doing the above, but I'm restarting some machines after a trip and the questions came to mind.
EdH is online now   Reply With Quote
Old 2010-11-05, 16:26   #145
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

17×251 Posts
Default

Quote:
Originally Posted by EdH View Post
Once this iteration is factored, is it a free-for-all to factor the next? Or, is there some coordinated effort to perform the (hopefully) trivial factoring of the next few composites?
As far as I know, it's a free-for-all with the coordination being: factors are reported in the DB and significant work is reported in the thread. e.g. informing everyone how much ECM has been run on a number or saying that you will be completing a number via GNFS.
Quote:
Originally Posted by EdH View Post
Would it be rude for those not post-processing to still run curves, or just time wasting. If a factor was happened upon, via the additional curves, would that be good or bad?
Do you mean, for example, to run ECM curves on this c170 right now? I'd call it wasteful, not rude. Either your ECM work will be wasted because no factor was found (which is most likely), or the GNFS work will be wasted because you found a factor (unlikely, but a net 'good' result).
They wouldn't be harmful, after all they just might find a factor and save us the extra couple days of post-processing, but the chances that you'd find one in this time period after the ECM we've given it is extremely slim, and whether you do the ECM or not, we'll have the answer very soon. If you were to find it via ECM now, then all the work done on the GNFS would have been wasted. But the end result is still that we have the factors.

Last fiddled with by Mini-Geek on 2010-11-05 at 16:34
Mini-Geek is offline   Reply With Quote
Old 2010-11-05, 16:48   #146
em99010pepe
 
em99010pepe's Avatar
 
Sep 2004

283010 Posts
Default

You can run some ecm curves on this c170 but you have less than 71 hours until I get the factors from the post-processing.
em99010pepe is offline   Reply With Quote
Old 2010-11-05, 19:05   #147
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

29·313 Posts
Default

As shown by Tom's and Greg's tests, larger density filtering attempts will need
1. more relations to succeed (there's no free lunch)
2. more memory to run
3. but will be faster (in this size range)

For every particular algebra setup, there's an optimum in the sky (probably the largest+densest matrix that still fits the memory and converges in filtering). The minimum total factoring time is even trickier - but doesn't have to be perfect if all participants have something else to switch to, anyway.

I'd suggest having a few precompiled binaries at hand and try e.g. first, TD 100, and if it doesn't converge or the resulting matrix doesn't fit the memory, then fallback to 90 or 80. The good ol' 70 is also nothing to sneeze at. Sometimes it is simply the best (especially for aliquot run-of-the-mill transient gnfs projects).

So, the algorithm: compile TD 70, 80, 90, 100, and also make of the not-LARGE_BLOCKS, just in case (because stages are separate, you can combine these two dimensions). Before every compilation, insert a self-descripting string in logprintf("Msieve 1.47..."), ok? We have this for example (B+D):
Sun Oct 10 05:03:41 2010 Msieve v. 1.47 SVN379 LARGE_BLOCKS zlib density100
Sun Oct 10 05:03:41 2010 random seeds: 3abfbd9f cd113da7
Sun Oct 10 05:03:41 2010 factoring 2760869837544182879281843314...95882573313215568949924071 (211 digits)
Sun Oct 10 05:03:42 2010 searching for 15-digit factors... etc

My 2 cents.

Last fiddled with by Batalov on 2010-11-05 at 19:07 Reason: /awfully long [and useless] string clipped/
Batalov is offline   Reply With Quote
Old 2010-11-05, 23:49   #148
jasonp
Tribal Bullet
 
jasonp's Avatar
 
Oct 2004

3,527 Posts
Default

Looks like the filtering needs general command line argument parsing. Command lines for filtering and LA are in my queue.

The target density defaults to 70 because it is a good compromise that keeps the memory use down while still producing a matrix that is small (enough) and sparse. My guess is that you have to be sieving with multiple machines, and generate a very large matrix, for a higher target density to reduce the LA time by more than the extra calendar-time spent sieving.

Last fiddled with by jasonp on 2010-11-05 at 23:57
jasonp is offline   Reply With Quote
Old 2010-11-06, 01:26   #149
Andi47
 
Andi47's Avatar
 
Oct 2004
Austria

2·17·73 Posts
Default

Quote:
Originally Posted by jasonp View Post
Looks like the filtering needs general command line argument parsing. Command lines for filtering and LA are in my queue.

The target density defaults to 70 because it is a good compromise that keeps the memory use down while still producing a matrix that is small (enough) and sparse. My guess is that you have to be sieving with multiple machines, and generate a very large matrix, for a higher target density to reduce the LA time by more than the extra calendar-time spent sieving.
Hmmm... maybe keep a default of 70 (seems to be a good (enough) compromise, at least for small and medium size factorizations), but allow overriding this default by command line.
Andi47 is offline   Reply With Quote
Old 2010-11-06, 01:43   #150
Andi47
 
Andi47's Avatar
 
Oct 2004
Austria

2×17×73 Posts
Default

Quote:
Originally Posted by EdH View Post
Would it be rude for those not post-processing to still run curves, or just time wasting. If a factor was happened upon, via the additional curves, would that be good or bad?
just a few random thoughts about ECM during GNFS:

personally I am currently running sequence 10212 and currently I keep encountering cofactors around c140 to c145 (I know, that's quite a bit smaller than c170, but that's the difference between home computing and team computing.).

My approach is the following:

1.) ECM to the desired extent. (e.g. for a c141 I do full B1=11e6 and maybe 500@43e6)

2.) Poly search. In parallel (on the idle threads of my i7) I do P-1 and p+1 to e.g. B1=5e9 and B2=5e15, followed by yet more ECM, until poly search has finished.

3.) sieving. And only sieving. No ECM at this time. Not a single curve.

4.) postprocessing. At this time I might consider ECMing something else, but not the cofactor of the current cofactor of the sequence, hence I would consider it wasteful if I find no ECM factor, and very annoying if I would find an ECM factor just a few hours before a two-to-three-weeks-GNFS finishes to output the factors.

Last fiddled with by Andi47 on 2010-11-06 at 01:45
Andi47 is offline   Reply With Quote
Old 2010-11-06, 01:58   #151
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

29·313 Posts
Default

Quote:
Originally Posted by EdH View Post
...Would it be rude for those not post-processing to still run curves, or just time wasting. If a factor was happened upon, via the additional curves, would that be good or bad?
It won't be rude to run curves, -- but it would be rude to find a factor.
Batalov is offline   Reply With Quote
Old 2010-11-08, 11:19   #152
em99010pepe
 
em99010pepe's Avatar
 
Sep 2004

2×5×283 Posts
Default

LA will finish within 4 hours.
em99010pepe is offline   Reply With Quote
Old 2010-11-08, 17:43   #153
em99010pepe
 
em99010pepe's Avatar
 
Sep 2004

2·5·283 Posts
Default

Code:
prp55: 5020628089729196540791781957106211235328810013516737941
prp115: 6236805693823202812256436162373797339317645025210784211942726700957117792931768486741474427658616159852603436208839
ecm miss?
Attached Files
File Type: zip msieve.zip (221.2 KB, 98 views)

Last fiddled with by em99010pepe on 2010-11-08 at 17:45
em99010pepe is offline   Reply With Quote
Old 2010-11-09, 07:39   #154
schickel
 
schickel's Avatar
 
"Frank <^>"
Dec 2004
CDP Janesville

2×1,061 Posts
Default

Quote:
Originally Posted by em99010pepe View Post
Code:
prp55: 5020628089729196540791781957106211235328810013516737941
prp115: 6236805693823202812256436162373797339317645025210784211942726700957117792931768486741474427658616159852603436208839
Awesome job. Thanks for the assist with the post-processing.
Quote:
Originally Posted by em99010pepe
ecm miss?
I would say no. We had ~85% of t55 and it was getting hard to get any further.

I would have been bummed if it had turned out like my c146: three weeks to find out it was p43*p103.

Now that I've got it figured out, I can put an ECM server up on the next large composite. That'll make the job easier to track....
schickel is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Team sieve #44: C158 from 4788:i5212 RichD Aliquot Sequences 29 2014-04-13 01:55
Team sieve #42: C161 from 4788:i5193 RichD Aliquot Sequences 49 2013-12-17 12:27
Team sieve #34: c148 from 4788:i2910 jrk Aliquot Sequences 14 2012-02-24 15:10
ECM work on 4788:2549.c170 schickel Aliquot Sequences 51 2011-01-05 02:32
Team sieve #3: c131 from 4788:2382 10metreh Aliquot Sequences 39 2009-05-03 14:02

All times are UTC. The time now is 21:20.

Mon Aug 3 21:20:29 UTC 2020 up 17 days, 17:07, 0 users, load averages: 1.84, 1.51, 1.41

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.