20090427, 15:56  #78  
Feb 2004
258_{10} Posts 
Quote:
Code:
ECM stage 1 factor found ECM stage 1 factor found ECM stage 1 factor found edit: oh, and my cpu is an i7. I'll let Jeff tell you about the gmpecm version. :) Last fiddled with by mklasson on 20090427 at 15:58 

20090427, 16:07  #79  
Jun 2003
Ottawa, Canada
1173_{10} Posts 
Quote:


20090427, 16:16  #80 
Jun 2003
Ottawa, Canada
10010010101_{2} Posts 
Ok so I just recompiled 1.41 with GMPECM 6.2.3 and also MPIR 1.1.1 and now the message goes away. I can reproduce the messages as well on my machine but with the new build they are not there.
Tonight when I get the chance I will update my website with new builds. So did something change in GMPECM 6.2.3 that might have fixed this? Didn't someone say that the interface to GMPECM changed slightly, could that be the issue? I might have been using SVN for the last build but this one is the tarball posted on the GMPECM site. Jeff. 
20090427, 16:32  #81 
Tribal Bullet
Oct 2004
3^{3}×131 Posts 
The function prototypes for the toplevel calls to P+1 and ECM in GMPECM have had an extra argument added after v6.2.2 was released, and unfortunately msieve uses these calls and not the supported GMPECM interface (next release will definitely change that).
Not sure if that's the problem here. I can see it being the issue if you use an old ecm.h but a new precompiled GMPECM lib... Last fiddled with by jasonp on 20090427 at 16:34 
20090427, 17:29  #82 
"Nancy"
Aug 2002
Alexandria
2,467 Posts 

20090428, 00:05  #83 
Jun 2003
Ottawa, Canada
10010010101_{2} Posts 
Ok the msieve 1.41 Windows binaries have been updated and should fix the ecm messages:
http://gilchrist.ca/jeff/factoring/ Jeff. 
20090429, 23:43  #84 
Jun 2003
Ottawa, Canada
3·17·23 Posts 
I just experienced something strange with msieve 1.41 64bit Linux binary trying to generate a polynomial for a C93.
Code:
Wed Apr 29 17:21:26 2009 Msieve v. 1.41 Wed Apr 29 17:21:26 2009 random seeds: c122cfc2 84ad251c Wed Apr 29 17:21:26 2009 factoring 258382100463852506230968335487805430257100969220134618900431126539928243525631289673555119871 (93 digits) Wed Apr 29 17:21:27 2009 no P1/P+1/ECM available, skipping Wed Apr 29 17:21:27 2009 commencing number field sieve (93digit input) Wed Apr 29 17:21:27 2009 commencing number field sieve polynomial selection Wed Apr 29 17:21:27 2009 time limit set to 0.17 hours Wed Apr 29 17:21:27 2009 searching leading coefficients from 1 to 1391 I can keep the output files you think they might be useful. I will start again to see if it is repeatable. Jeff. 
20090430, 01:08  #85  
Jun 2003
Ottawa, Canada
3×17×23 Posts 
Rerunning it again is doing the same thing, running it on my Windows binary I had to manually abort it after 37 minutes:
Quote:


20090430, 02:02  #86 
Jun 2005
373 Posts 
Going some Aliquot numbers, with Msieve 1.41 I got the error mentioned in post 63. (I am not sure anymore about the "Too many merge attempts"error, I can't find it in the logs). I uploaded everything to Schickel, who ran the postprocessing with version 1.39, and everything just came out fine.
Code:
linear algebra completed 222519 of 223174 dimensions (99.7%, ETA 0h 0m) lanczos halted after 3528 iterations (dim = 222925) recovered 32 nontrivial dependencies commencing square root phase reading relations for dependency 1 read 111749 cycles cycles contain 455893 unique relations read 455893 relations multiplying 366356 relations multiply complete, coefficients have about 14.51 million bits initial square root is modulo 215881931 prp52 factor: 7570380941541769441561745312556684037938683763298177 prp52 factor: 8145994460731835857997597172380480561830720426463929 elapsed time 00:29:25 Of course I don't know if this a real regression from version 1.39 to 41, or if it's accidentally and one can't do anything about it. Just wanted to let you know. H. 
20090430, 05:05  #87  
Oct 2004
Austria
9B2_{16} Posts 
GNFS poly search for small composites
Quote:
I guess that msieve looks, how many time has passed, after each block done, so when it takes 4+ hours (my experience) to save zillions of polynomials for one block, it will never take a look at the clock and find out, that 15 minutes have passed. IMHO it should be possible to solve this problem by just rising the limit for good polynomials to save for composites up to 94 or 95 digits. 

20090430, 09:32  #88 
(loop (#_fork))
Feb 2006
Cambridge, England
13×491 Posts 
Timing problem for very small a5 and large N
I don't know if this is a variant on the problem that other users are having for small N, but I'm running (after tweaking the source code to let me use nz 25.0,23.3,15.5 to set the base10 logs of the three bounds for a polynomial search on the command line) polynomial search on a 162digit composite in 10k slices for a5=1..100000. The 1k10k and 10k20k have now both taken 100 hours CPU (to compare, 20k30k took 64, 11k took 3, 40k50k took 33) and I'm slightly concerned that they may be looping endlessly.
gdb tells me that they're at least calling and returning from root_sieve, so maybe all I need is patience, but for these large jobs it would be very nice to have a little more feedback as to what msieve is doing; I am of course capturing stderr and stdout, but it's been three days since the last line was added to either. Last fiddled with by fivemack on 20090430 at 09:33 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Msieve 1.53 feedback  xilman  Msieve  149  20181112 06:37 
Msieve 1.50 feedback  firejuggler  Msieve  99  20130217 11:53 
Msieve v1.48 feedback  Jeff Gilchrist  Msieve  48  20110610 18:18 
Msieve 1.43 feedback  Jeff Gilchrist  Msieve  47  20091124 15:53 
Msieve 1.42 feedback  Andi47  Msieve  167  20091018 19:37 