mersenneforum.org Msieve 1.51 feedback
 Register FAQ Search Today's Posts Mark Forums Read

2013-07-12, 12:12   #155
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2·5·587 Posts

Quote:
 Originally Posted by jasonp Do you mean the 32-bit binary from sourceforge? My development machine is a core 2 so that's surprising. Or do you mean one of the binaries Jeff hosts?
Jeff's latest. The one compiled by Brian.

2013-07-12, 13:25   #156
WraithX

Mar 2006

11·43 Posts

Quote:
 Originally Posted by jasonp The --large-address-aware option is only to get a 32-bit binary to have a 3GB virtual address space, it's useless if you want a full 64-bit binary. Filtering is not threaded, so that doesn't matter here. If you're willing to use gdb, the core of the singleton removal is in a single function and I can try to help you figure out what's going on there. We can take it to email if you're game; if using MinGW64 is the problem, then it would be nice to have another working build option in windows. The other possibility is to try using one of Microsoft's free compilers to build the source without ECM; even if it still doesn't work, you have a nicer symbolic debugger that can help figure out what's going on.
Yeah, the single threaded case was the same. Also, even with the updated MinGW64 I just downloaded I still get the same problem. I'd definitely like to see if we can get this to work correctly with MinGW64. I'll send you a PM with my email address. Also, I hope we have access to a smaller example to try to help speed up the troubleshooting process. It takes about 25 minutes before this one starts "singleton removal, initial pass" and then it takes about another 25 minutes before it starts "in-memory singleton removal".

2013-07-12, 13:35   #157

May 2008
Worcester, United Kingdom

2×263 Posts

Quote:
 Originally Posted by henryzz Ecm crashes for me in the latest binary as well. I assume it tries to use an instruction that my core 2 doesn't support.
Are you sure that its not the assertion failure that I am seeing when msieve calls the ecm library (see my report earlier)?

EDIT: I have just compiled and run the latest version of msieve compiled without GMP-ECM on a small example and it runs fine. So we need to figure out why there is an assertion failure in GMP-ECM when called from msieve. I have not yet worked out the parameters that msieve uses to call GMP-ECM but it would be useful to call GMP-ECM natively with these inputs to see whether the problem still occurs.

Last fiddled with by Brian Gladman on 2013-07-12 at 13:58 Reason: additional information

2013-07-12, 14:06   #158
henryzz
Just call me Henry

"David"
Sep 2007
Cambridge (GMT/BST)

2×5×587 Posts

Quote:
 Originally Posted by Brian Gladman Are you sure that its not the assertion failure that I am seeing when msieve calls the ecm library (see my report earlier)? EDIT: I have just compiled and run the latest version of msieve compiled without GMP-ECM on a small example and it runs fine. So we need to figure out why there is an assertion failure in GMP-ECM when called from msieve. I have not yet worked out the parameters that msieve uses to call GMP-ECM but it would be useful to call GMP-ECM natively with these inputs to see whether the problem still occurs.
It might be.

 2013-07-12, 22:34 #159 Brian Gladman     May 2008 Worcester, United Kingdom 2×263 Posts Assertion failure in MSIEVE call to the GMP-ECM library I have posted this on the GMP-ECM developers forum but I am duplicating it here in case anyone might be able to work out what is going wrong. ----------------------------------------------------------------------------- I would appreciate advice on an assertion failure that is invoked when the GMP-ECM library is called from MSIEVE: Assertion failed: __ecm_eulerphi (params->P) == params->s_1 * params->s_2, file ..\..\pm1fs2.c, line 2902 I have tracked this down to the parameters B2min_parm, B2_parm and B2scale in the call to pm1 on line 441 in the file pm1.c. These are respectively -1, -1 and 0.0 As a result of lines 476 ..482: if (ECM_IS_DEFAULT_B2(B2)) mpz_set_d (B2, B2scale * pow (B1 * PM1FS2_COST, PM1FS2_DEFAULT_B2_EXPONENT)); /* set B2min */ if (mpz_sgn (B2min) < 0) mpz_set_d (B2min, B1); B2 gets set to 0, whereas B2min gets set to 0x4e20. Now B2 is less than B2min and as a result the function choose_P on line 552 of pm1fs2.c does not set the P, s_1 and s_2 parameters in the faststage2_param_t structures. In consequence the call at line 708 in pm1.c youpi = pm1fs2_ntt (f, x, modulus, ¶ms); is entered without the P, s_1 and s_2 set and the assertion failure is consequently raised. -----------------------------------------------------------------------------
2013-07-12, 23:54   #160
WraithX

Mar 2006

47310 Posts

Quote:
 Originally Posted by Brian Gladman I have posted this on the GMP-ECM developers forum but I am duplicating it here in case anyone might be able to work out what is going wrong.
Hello Brian, I'm not sure if this is the correct fix for the problem, but I think it is worth trying out to see if it will work in general. In the file:
msieve-trunk/common/smallfact/gmp_ecm.c
Code:
Can you change the value on line 215 from:
tmp->stage_1_done = 1.0;
To:
tmp->stage_1_done = 1.001;
This change should allow B2scale to be > 0 and therefore give B2 a chance to be greater than 0. (You could also try 1.01 or 1.1)

I say this because of the following code in gmp-ecm\factor.c lines 133-137:
Code:
   /* Ugly hack to pass B2scale to the library somehow. It gets piggy-backed
onto B1done. The next major release will have to allow for variable
length parameter structs. */
B1done = floor (p->B1done);
B2scale = (p->B1done - B1done) * 1048576.;

2013-07-13, 07:31   #161

May 2008
Worcester, United Kingdom

2×263 Posts

Quote:
 Originally Posted by WraithX Hello Brian, I'm not sure if this is the correct fix for the problem, but I think it is worth trying out to see if it will work in general. In the file: msieve-trunk/common/smallfact/gmp_ecm.c Code: Can you change the value on line 215 from: tmp->stage_1_done = 1.0; To: tmp->stage_1_done = 1.001; This change should allow B2scale to be > 0 and therefore give B2 a chance to be greater than 0. (You could also try 1.01 or 1.1) I say this because of the following code in gmp-ecm\factor.c lines 133-137: Code:  /* Ugly hack to pass B2scale to the library somehow. It gets piggy-backed onto B1done. The next major release will have to allow for variable length parameter structs. */ B1done = floor (p->B1done); B2scale = (p->B1done - B1done) * 1048576.;
Thanks for your input WraithX - a value of 1.001 fixed it.

I had the feeling that B2scale ought to be greater than zero and the 'ugly hack' raised my suspicions still further

I'll wait for Jason to confirm this change before I update the msieve SVN, after whiich I will let Jeff have an updated binary.

 2013-07-13, 11:35 #162 jasonp Tribal Bullet     Oct 2004 33×131 Posts Please do. I wonder if this change was made necessary by using a more recent release of GMP-ECM...
2013-07-13, 12:33   #163

May 2008
Worcester, United Kingdom

52610 Posts

Quote:
 Originally Posted by jasonp Please do. I wonder if this change was made necessary by using a more recent release of GMP-ECM...
It is quite likely since a lot of work was done fairly recently.

I have now updated the msieve SVN and sent a new binary to Jeff to host.

If anyone is desperate to have a copy, I could post it as an attachment here but I am not sure how the the mods feel about fairly large attachments.

 2013-07-13, 19:29 #164 Jeff Gilchrist     Jun 2003 Ottawa, Canada 117310 Posts The new version is now available on my website: http://gilchrist.ca/jeff/factoring/ Don't forget to download the Visual C++ 2012 Redistributable binary first if you don't already have it. There is now a link to that too at the top of the page. Jeff.
2013-07-14, 02:27   #165
WraithX

Mar 2006

11·43 Posts

I downloaded the svn915 from Jeff's site a little while ago. Unfortunately, even this version of msieve crashed on me while working on L1911. This time it crashed on me in a slightly different place. I'm attaching the log to see if anyone can see what might have been the problem this time.

At this point, I'm not sure if the Windows builds can handle large jobs. I'm still trouble shooting my MinGW64 build. It turns out that it works just fine on a GNFS139 I had sitting on my hard drive. That only had a 3.02GB dat file. However, neither my MinGW64 nor Brian's Visual Studio build have worked on the L1911 24GB dat file. I think they read in all of the relations just fine, there just seem to be strange problems after that.

If anyone here has a 4.01GB, maybe up to 5-6GB, dat file (plus the .fb and .ini files too) laying around for a job they've done, I'd like to download it and do some testing locally to see how Windows msieve handles that. If someone does have something like that, can you post here where ever you upload it, or PM me details on where I can download it? That would be much appreciated.
Attached Files
 msieve.log.txt (13.1 KB, 69 views)

 Similar Threads Thread Thread Starter Forum Replies Last Post xilman Msieve 149 2018-11-12 06:37 firejuggler Msieve 99 2013-02-17 11:53 Jeff Gilchrist Msieve 47 2009-11-24 15:53 Andi47 Msieve 167 2009-10-18 19:37 Batalov Msieve 130 2009-06-09 16:01

All times are UTC. The time now is 19:53.

Tue May 11 19:53:48 UTC 2021 up 33 days, 14:34, 1 user, load averages: 1.67, 1.93, 1.89