Yafu

[bsquared]

Originally Posted by EdH

I have YAFU working on a WinXP Laptop, but am trying to run it on a linux PC. (Actually, the laptop is still working the factor example, right now. How long should it take?) I've only tried the factor() routine so far, since I'm just breaking into this area.

The README example shouldn't take more than a couple minutes. The example is constructed such that it should find several factors with ECM with reasonably high probability... but maybe you were really unlucky and it didn't. If that's the case then it could take a while to crack the C87 with siqs.

Originally Posted by EdH

However, on the linux machine, I'm getting an "Illegal Instruction" message and exit, trying to use the factor() test from the README file. I've added the computer info and lists of sessions, logs, etc. in case they may be of help.

Thanks. Unfortunately I don't have access to any natively 32 bit linux machines, so if I can get it to compile on my 64 bit machine I call it good . So I don't have a quick answer for you... Your best bet is to try to compile from source and see if there are any problems. Feel free to PM me and I can try to help you with this if you need it.

Originally Posted by EdH

Speaking of help, even that command has trouble on the linux machine, as shown in one of the sections below.

Errm, yes, I guess this needs work. :)

Originally Posted by EdH

I have noticed that several lines say, "using 64bit linux opteron data for QS time estimation"

That's a bug... it should read "using 32bit ..."

Originally Posted by EdH

Added note: I have gmp-ecm running on my linux machine, but it takes "gmp-ecm" to invoke it. References I've seen, all seem to invoke it through the "ecm" command. Is gmp-ecm called at all, if available?

No, that's only available in version 1.15, which isn't available yet for 32bit linux...

[EdH]

Thank you for responding so quickly.

Originally Posted by bsquared

The README example shouldn't take more than a couple minutes. The example is constructed such that it should find several factors with ECM with reasonably high probability... but maybe you were really unlucky and it didn't. If that's the case then it could take a while to crack the C87 with siqs.

Must be my luck isn't all that good. The laptop is still chugging away, quite active, showing ecm curve after ecm curve; sometimes up to 400. One line reads:

ecm: curve 400, sigma = 3837905283, c70 input, B1 = 250K, B2 = 25M, processed <

BTW: laptop is Intel Pentium 4 CPU 2.4GHz, WinXP with 24.5G free hd space, but only 512M RAM.

Originally Posted by bsquared

Thanks. Unfortunately I don't have access to any natively 32 bit linux machines, so if I can get it to compile on my 64 bit machine I call it good . So I don't have a quick answer for you... Your best bet is to try to compile from source and see if there are any problems. Feel free to PM me and I can try to help you with this if you need it.

I will look at the possibility of compiling, but my knowledge has not let me claim much success in the past, even though I play around with writing software. But, actually, I'm not familiar with packages that include build and makefiles. Perhaps, it's time I learn a bit more. I did not notice the source code for 1.14 on your page; only 1.15. Should I be trying to compile that, or is it only for 64bit?

Thank you again for replying so quickly. I will play around some more and get back with you if any changes come about. This is not a priority in any fashion.

As a last note: Thank you for providing this to the community.

Take Care,
Ed

[bsquared]

Originally Posted by EdH

Must be my luck isn't all that good. The laptop is still chugging away, quite active, showing ecm curve after ecm curve; sometimes up to 400. One line reads:

ecm: curve 400, sigma = 3837905283, c70 input, B1 = 250K, B2 = 25M, processed <

BTW: laptop is Intel Pentium 4 CPU 2.4GHz, WinXP with 24.5G free hd space, but only 512M RAM.

Blast. This is an indication of a bug in the QS time estimation for your platform. It is apparently exceedingly high, thus factor() thinks it needs to do extraordinary amounts of ECM before attempting QS. This report combined with your system info should make this pretty easy to debug. What is the program reporting as the estimated QS time?

Originally Posted by EdH

I will look at the possibility of compiling, but my knowledge has not let me claim much success in the past, even though I play around with writing software. But, actually, I'm not familiar with packages that include build and makefiles. Perhaps, it's time I learn a bit more. I did not notice the source code for 1.14 on your page; only 1.15. Should I be trying to compile that, or is it only for 64bit?

It should be as easy as maneuvering to the yafu directory in a command shell and typing 'make x86'. I think the 1.15 source will work, as long as you don't specify GMPECM=1 in the make command. If not, I'll have to send you the 1.14 source. I haven't done any testing with the 1.15 source in linux32 bit mode...

Originally Posted by EdH

As a last note: Thank you for providing this to the community.

Take Care,
Ed

and thank you for using it! and again for helping to make it better.

- ben.

[EdH]

Originally Posted by bsquared

Blast. This is an indication of a bug in the QS time estimation for your platform. It is apparently exceedingly high, thus factor() thinks it needs to do extraordinary amounts of ECM before attempting QS. This report combined with your system info should make this pretty easy to debug. What is the program reporting as the estimated QS time?

The next few lines read:

***** 30 digit level took 19.47751 seconds.
***** using 32bit windows p4 data for QS time estimation
***** qs time estimate = 197.883626 seconds
***** estimating 151 more curves can be run at 35 digit level
ecm: curve 1, sigma 3413087968, C70 input, B1 = 1M, B2 = 100M, processed <
. . .

Originally Posted by bsquared

It should be as easy as maneuvering to the yafu directory in a command shell and typing 'make x86'. I think the 1.15 source will work, as long as you don't specify GMPECM=1 in the make command. If not, I'll have to send you the 1.14 source. I haven't done any testing with the 1.15 source in linux32 bit mode...

It didn't like it. It gave a lot of "incompatible" statements, followed by a series of "undefined reference" statements:

[id@computer Yafu2]$ make x86
gcc -m32 -g -O3 -fomit-frame-pointer -Wall  -I. -Iinclude tfm/fp_mul_comba.o tfm/fp_mul_comba_small_set.o tfm/fp_sqr_comba.o tfm/fp_sqr_comba_small_set.o tfm/fp_sqr_comba_generic.o tfm/fp_2expt.o tfm/fp_cmp_mag.o tfm/fp_mont_small.o tfm/fp_montgomery_calc_normalization.o tfm/fp_montgomery_reduce.o tfm/fp_montgomery_setup.o tfm/fp_mul_2.o tfm/s_fp_sub.o msieve/lanczos.o msieve/lanczos_matmul0.o msieve/lanczos_matmul1.o msieve/lanczos_matmul2.o msieve/lanczos_pre.o msieve/mpqs_gf2.o msieve/sqrt.o msieve/savefile.o msieve/squfof_jp.o factor/factor_common.o factor/algfactor.o factor/relation.o factor/sieve.o factor/poly.o factor/siqs_test.o factor/siqs_aux.o factor/smallmpqs.o factor/ecm.o factor/pp1.o factor/pm1.o factor/rho.o factor/squfof.o factor/trialdiv.o factor/MPQS.o factor/gf2.o factor/pQS.o factor/SIQS.o arith/arith0.o arith/monty.o arith/arith1.o arith/arith2.o arith/arith3.o top/driver.o top/utils.o top/soe.o top/stack.o top/calc.o top/test.o -o yafu -lm -pthread
/usr/bin/ld: i386:x86-64 architecture of input file `tfm/fp_mul_comba.o' is incompatible with i386 output
. . .
/usr/bin/ld: i386:x86-64 architecture of input file `top/test.o' is incompatible with i386 output
factor/ecm.o: In function `ecm_loop':
/users/buhrow/personal/math_stuff/mpDigits/yafu-1.15/factor/ecm.c:1026: undefined reference to `ecm_clear'
. . .
/users/buhrow/personal/math_stuff/mpDigits/yafu-1.15/include/gmp_xface.h:50: undefined reference to `__gmpz_export'
/usr/bin/ld: final link failed: Invalid operation
collect2: ld returned 1 exit status
make: *** [x86] Error 1

Thanks again for you help. Sorry to be such a pain...

Take Care,
Ed

[EdH]

Well, I feel even worse now. I just realized I got a version 1.12 somehow mixed in with my version 1.15 on the WinXP laptop.

Skip all my previous trouble in regards to the laptop. With version 1.15, it worked in just over 7.5 minutes. Oddly, with an alternate 1.4GHz laptop it ran in under 4 minutes. Both have 512M, but different CPUs.

My apologies for the trouble I caused re the Win32 version(s).

I'll probably get hold of you about the 1.14 source for the linux machine in the next few days, but I might be too embarrassed to ask for it, now.

Again, sorry for my big mistake.

Take Care,
Ed

[bsquared]

Originally Posted by EdH

Well, I feel even worse now. I just realized I got a version 1.12 somehow mixed in with my version 1.15 on the WinXP laptop.

Skip all my previous trouble in regards to the laptop. With version 1.15, it worked in just over 7.5 minutes. Oddly, with an alternate 1.4GHz laptop it ran in under 4 minutes. Both have 512M, but different CPUs.

My apologies for the trouble I caused re the Win32 version(s).

I'll probably get hold of you about the 1.14 source for the linux machine in the next few days, but I might be too embarrassed to ask for it, now.

Again, sorry for my big mistake.

Take Care,
Ed

Heh, no problem . I'm glad to hear it's resolved. Version 1.12 did have some timing issues on windows systems, and especially laptops. 1.15 should be (and apparently is) much better.

Large speed variations exist between cpu types for this type of work; memory size isn't as important as long as it is 'big enough'. For instance p4's are misrable at QS compared to core2 or any recent AMD chip.

I'm interested in getting things to work on linux 32 bit systems, so if you are game I'll help you along. I'll PM you with details.

[EdH]

Originally Posted by bsquared

Heh, no problem . I'm glad to hear it's resolved. Version 1.12 did have some timing issues on windows systems, and especially laptops. 1.15 should be (and apparently is) much better.

Large speed variations exist between cpu types for this type of work; memory size isn't as important as long as it is 'big enough'. For instance p4's are misrable at QS compared to core2 or any recent AMD chip.

I'm interested in getting things to work on linux 32 bit systems, so if you are game I'll help you along. I'll PM you with details.

OK, next phase in this mystery; I'm thinking it must be this particular machine has something wrong. I have access to several systems with a few different OS's, but I just ran both 32k and 64k versions on another machine with the identical linux system (Fedora 11), and they both ran fine. Of special note - there were no 64bit messages; all were 32 bit messages. The 32k ran the test in 390.3816 seconds to find 7 probable primes. The 64k version took 69.5544 seconds. **(Hmm, a thought just popped in. Would the 64k version possibly have found info left by the 32k version, and that is why the time difference?)

The particulars of the second machine are:

Intel Pentium 4 CPU 1.7GHz with 768M memory

I have some other machines around in various levels of disassembly. I will try to bring some of those up for testing over the weekend.

Thank you again for your help. I'm thinking your program is fine and my equipment is less than adequate for my current area of interest.

Take Care,
Ed

[bsquared]

Originally Posted by EdH

**(Hmm, a thought just popped in. Would the 64k version possibly have found info left by the 32k version, and that is why the time difference?)

Yes, the siqs routine leaves a savefile behind. If you try to factor the same number again without deleting the savefile or factoring a different number with siqs, then the relations in the file are used and the job goes *much* quicker.

[EdH]

Originally Posted by bsquared

Yes, the siqs routine leaves a savefile behind. If you try to factor the same number again without deleting the savefile or factoring a different number with siqs, then the relations in the file are used and the job goes *much* quicker.

I will try the 64k version again, from scratch, then.

Right now, I'm running an intensive memory test on the questionable machine. I tried compiling 1.14 on it last night and got several errors. I will be tied up with other things today, but plan to work in some compiling, etc. on the machine that is working. Of note, the questionable machine did compile msieve without any complaints. It then ran factors against your test number in a little over 7.5 minutes.

The questionable machine has a lot more applications installed than the other one. I wonder if that could be the trouble. I have the g++ addition to gcc and code::blocks, plus several math programs.

Thank you for the 1.14 source. I will try it and the 1.15 source on the working one a little later, as well as on an older version of Fedora that's hanging out on a laptop partition.

Take Care,
Ed

[EdH]

I had a brief chance to try some compiling, but neither 1.14 nor 1.15 would compile on the other Fedora machine. However, 1.14 runs fine. I did try the 64k version with the save files removed and it took a bit longer.

I'll have more later, with some error messages.

BTW, the memory test on the questionable machine did not find anything amiss.

Take Care,
Ed

[richs]

Running version 1.15 with XP, I had the following results with a Windows error box that the application had a problem and had to close:



02/03/10 10:22:56 v1.15 @ RICH, Initializing...
Powered by Tom's Fast Math (x86-32 asm)
Using GMP-ECM 6.2.3, Powered by GMP 4.2.3
cached 664581 primes. pmax = 10000079
detected cpu 4, with L1 = 16384 bytes, L2 = 1048576 bytes

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow -at- gmail -dot- com =======
======= Type help at any time, or quit to quit =======
===============================================================

>> siqs (89202248141393029562433987257375558697204695545353715955713528758185807
25840367919403456232991)


starting SIQS on c94: 8920224814139302956243398725737555869720469554535371595571
352875818580725840367919403456232991
82059 relations found: 20901 full + 61158 from 1126470 partial
threw away 986 relations with large primes too small

==== sieve params ====
n = 95 digits, 314 bits
factor base: 81977 primes (max prime = 2213053)
single large prime cutoff: 287696890 (130 * pmax)
double large prime range from 44 to 51 bits
double large prime cutoff: 1682996841594562
sieve interval: 26 blocks of size 32768
polynomial A has ~ 12 factors
using multiplier of 3
using small prime variation correction of 19 bits
using SSE2 for trial division and x128 sieve scanning
trial factoring cutoff at 96 bits

==== sieving in progress (1 thread): 82041 relations needed ====
==== Press ctrl-c to abort and save state ====


trial division touched 0 sieve locations out of 0
QS elapsed time = 4.0625 seconds.

==== post processing stage (msieve-1.38) ====
begin with 1148356 relations
reduce to 209157 relations in 11 passes
attempting to read 209157 relations
failed to read relation 4568
failed to read relation 4569
failed to read relation 4570
failed to read relation 4571
failed to read relation 4572
failed to read relation 4573
failed to read relation 4574
failed to read relation 4575
failed to read relation 4576
failed to read relation 4577
failed to read relation 4578
bad poly A encountered in savefile
bad poly A encountered in savefile
bad poly A encountered in savefile
bad poly A encountered in savefile
bad poly A encountered in savefile
bad poly A encountered in savefile
bad poly A encountered in savefile


Any suggestions would be appreciated!

Rich