mersenneforum.org 100M digits prefactor project.
 Register FAQ Search Today's Posts Mark Forums Read

 2006-04-26, 20:23 #309 grobie     Sep 2005 Raleigh, North Carolina 337 Posts this is what I typed in dos box after I got to dir: mfactor -m t332194021 this is what I got: convert base 10 char uint64: isdigit fails, s = t332194021, i = 0, c = t ERROR: at line 1684 of file \documents and settings\mayer\mlucas\util.c Assertion failed: 0
2006-04-27, 01:28   #310
ewmayer
2ω=0

Sep 2002
República de California

2×32×647 Posts

Quote:
 Originally Posted by grobie this is what I typed in dos box after I got to dir: mfactor -m t332194021 this is what I got: convert base 10 char uint64: isdigit fails, s = t332194021, i = 0, c = t ERROR: at line 1684 of file \documents and settings\mayer\mlucas\util.c Assertion failed: 0
There should be no 't' preceding the Mersenne exponent (that's simply the letter prepended by Mfactor to the exponent to yield the savefile name) - you should use just

mfactor -m 332194021

That will cause the program to look for a savefile named 't332194021' on startup - the program doesn't have a feature allowing arbitrary naming of savefiles, it always uses the same exponent-dependent naming convention.

Also, could you copy me on the diagnostic prints (e.g. about which build flags were invoked) issued by the code on startup?

Thanks,
-ernst

Last fiddled with by ewmayer on 2006-04-27 at 01:28

2006-04-27, 01:49   #311
grobie

Sep 2005
Raleigh, North Carolina

337 Posts

Quote:
 Originally Posted by ewmayer There should be no 't' preceding the Mersenne exponent (that's simply the letter prepended by Mfactor to the exponent to yield the savefile name) - you should use just mfactor -m 332194021 That will cause the program to look for a savefile named 't332194021' on startup - the program doesn't have a feature allowing arbitrary naming of savefiles, it always uses the same exponent-dependent naming convention. Also, could you copy me on the diagnostic prints (e.g. about which build flags were invoked) issued by the code on startup? Thanks, -ernst
Ok thats why I added the t

but below is the resume after 34 hours:

Microsoft Windows XP [Version 5.1.2600]

C:\Program Files\llr\mfactor>mfactor -m 332194021
CPU = Pentium, OS = Windows, compiled with MSVC / .NET.
INFO: compiler sets x87 FPU to 53-bit mantissa mode. Overriding...
Setting x87 FPU to 64-bit mantissa mode.
INFO: using 64-bit-significand form of floating-double rounding constant
INFO: testing qfloat routines...
INFO: qfloat routines using subroutine form of MUL_LOHI
Mfactor build flags:
TRYQ = 2
NUM_SIEVING_PRIME = 50000
USE_FLOAT = 1
FACTOR_STANDALONE = 1
FAC_DEBUG = 0
DBG_SIEVE not defined
NOBRANCH = 1
QUIT_WHEN_FACTOR_FOUND not defined
USE_65BIT not defined
P2WORD not defined
P3WORD not defined
Mfactor self-tests:
Testing 63-bit factors...
Testing 64-bit factors...
Testing 65-bit factors...
Testing 96-bit factors...
Factoring self-tests completed successfully.
Factoring savefile t332194021 found ... reading ...
INFO: Previous run to kmax = 7107851150400 not yet complete.
Ignoring any increased factor-bound-related command-line parameters and proceedi
ng to complete previous run.
searching in the interval k=[3553917407040, 7107851150400], i.e. q=[2.361180e+02
1, 4.722371e+021]
each of 16 (p mod 60) passes will consist of 217548 intervals of length 272272
Resuming execution with pass 1 and k = 4014814003200
max sieving prime = 611957

 2006-04-28, 16:25 #312 ewmayer ∂2ω=0     Sep 2002 República de California 2×32×647 Posts OK, so it restarted successfully, about 15% of the way through the 2nd pass of 16 (the passes are numbered 0-15, so pass 1 means the 2nd pass). Do you have an estimate of how long Prime95 needs to do all 16 passes to the same bitdepth on the same hardware? I expect some sse2 optimizations of the floating-point-based versions of the factoring modules used by the code on hardware like yours (as indicated by the 'USE_FLOAT = 1' part of the informational diagnostics) should yield something on the order of a 2x speedup, but if the discrepancy vs. Prime95 is significantly greater than 2x on this hardware, then clearly something more would be required to approach parity. Also, it would be great if someone could run at least pass 1 of the same test on an AMD64, so we can gauge the speed difference between the all-integer code used on that platform (which has excellent integer multiply capability) vs. the generic floating-point code running on 32-bit x86.
 2006-04-28, 16:32 #313 grobie     Sep 2005 Raleigh, North Carolina 15116 Posts I wont be able to give you the correct speed, because I had to close the program a few times, but my iterations is set at 10000 and does it on average of 155 seconds if that helps. When p95 is done I will post time, currently 81% complete.
2006-04-28, 19:16   #314
ewmayer
2ω=0

Sep 2002
República de California

2D7E16 Posts

Quote:
 Originally Posted by grobie I wont be able to give you the correct speed, because I had to close the program a few times, but my iterations is set at 10000 and does it on average of 155 seconds if that helps. When p95 is done I will post time, currently 81% complete.
The iteration times don't help, because (unlike with the LL test) I don't know how to translate that into % complete. But if it's roughly 4/5 of the way through and you have a decent idea of how many total CPU-hours it took to get there, we can easily extrapolate to get to 100% and compare it to the Mfactor timing.

Last fiddled with by ewmayer on 2006-04-28 at 19:17

 2006-04-29, 00:23 #315 grobie     Sep 2005 Raleigh, North Carolina 337 Posts 332194021 M332194021 no factor to 2^72, Wc1: 7458A2A3
2006-04-29, 11:05   #316
gribozavr

Mar 2005
Internet; Ukraine, Kiev

11·37 Posts

Quote:
 Originally Posted by ewmayer Also, it would be great if someone could run at least pass 1 of the same test on an AMD64, so we can gauge the speed difference between the all-integer code used on that platform (which has excellent integer multiply capability) vs. the generic floating-point code running on 32-bit x86.
I have ran it on Athlon64 3000+ 1.8Ghz
Code:
grib@gribozavr:mfactor\$ ./Mfactor_amd64_linux_static -m 332194021 -bmin 71 -bmax 72 -passmin 0 -passmax 0
CPU = AMD64, OS = Linux, compiled with Gnu C.
INFO: using 64-bit-significand form of floating-double rounding constant
WARN: At line 456 of file util.c:
WARN: 64-bit rounding constant not behaving as expected - trying 53-bit version.

INFO: testing qfloat routines...
Mfactor build flags:
TRYQ = 4
NUM_SIEVING_PRIME = 50000
USE_FLOAT not defined
FACTOR_STANDALONE = 1
FAC_DEBUG = 0
DBG_SIEVE not defined
NOBRANCH = 1
QUIT_WHEN_FACTOR_FOUND not defined
USE_65BIT not defined
P2WORD not defined
P3WORD not defined
Mfactor self-tests:
Testing 63-bit factors...
Testing 64-bit factors...
Testing 65-bit factors...
Testing 96-bit factors...
Factoring self-tests completed successfully.
INFO: No factoring savefile t332194021 found ... starting from scratch.
searching in the interval k=[3553917407040, 7107851150400], i.e. q=[2.361180e+21, 4.722371e+21]
each of  1 (p mod 60) passes will consist of 217548 intervals of length 272272
max sieving prime = 611957
Time to set up sieve = 00:00:00.080
pass = 0....................................................[cut]
M332194021 has 0 factors in [2.361180e+21, 4.722371e+21], passes 0-0
Performed 9352542208 trial divides
checksum1 = A3DE2CF9941E1868
Clocks = 02:30:14.030
1 pass takes 2.5 hours, 16 passes would take 40 hours.

 2006-04-29, 13:52 #317 grobie     Sep 2005 Raleigh, North Carolina 337 Posts Taking 332194021 from 72 to 73 going to try factor4 with this one. Or would p95 be faster? Sorry I am unable to give anyone times with p95 due to so many restarts.
 2006-04-29, 14:02 #318 gribozavr     Mar 2005 Internet; Ukraine, Kiev 19716 Posts Prime95 would be definitely faster than factor4. Last fiddled with by gribozavr on 2006-04-29 at 14:06
2006-04-29, 14:15   #319
grobie

Sep 2005
Raleigh, North Carolina

337 Posts

Quote:
 Originally Posted by gribozavr Prime95 would be definitely faster than factor4.
ok switching to p95

 Similar Threads Thread Thread Starter Forum Replies Last Post aurashift Software 18 2016-04-14 13:48 xorbe LMH > 100M 189 2010-12-09 08:30 joblack LMH > 100M 1 2009-10-08 12:31 davieddy Lounge 1 2008-10-18 10:40 wblipp ElevenSmooth 0 2003-10-15 16:07

All times are UTC. The time now is 16:31.

Fri Jul 30 16:31:46 UTC 2021 up 7 days, 11 hrs, 0 users, load averages: 1.69, 1.78, 1.75