mersenneforum.org > YAFU Yafu
 Register FAQ Search Today's Posts Mark Forums Read

2009-12-11, 20:32   #309
bsquared

"Ben"
Feb 2007

3,371 Posts

Quote:
 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.

Quote:
 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.

Quote:
 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. :)

Quote:
 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 ..."

Quote:
 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...

2009-12-11, 23:09   #310
EdH

"Ed Hall"
Dec 2009

2·3·5·112 Posts

Thank you for responding so quickly.

Quote:
 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:
Code:
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.

Quote:
 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

2009-12-11, 23:22   #311
bsquared

"Ben"
Feb 2007

D2B16 Posts

Quote:
 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: Code: 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?

Quote:
 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...

Quote:
 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.

2009-12-12, 00:06   #312
EdH

"Ed Hall"
Dec 2009

E2E16 Posts

Quote:
 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?
Code:
***** 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 <
. . .
Quote:
 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:

Code:
[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

 2009-12-12, 02:16 #313 EdH     "Ed Hall" Dec 2009 Adirondack Mtns 2×3×5×112 Posts 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
2009-12-12, 02:44   #314
bsquared

"Ben"
Feb 2007

3,371 Posts

Quote:
 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.

2009-12-12, 04:19   #315
EdH

"Ed Hall"
Dec 2009

2×3×5×112 Posts

Quote:
 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

2009-12-12, 05:13   #316
bsquared

"Ben"
Feb 2007

3,371 Posts

Quote:
 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.

2009-12-12, 14:59   #317
EdH

"Ed Hall"
Dec 2009

2·3·5·112 Posts

Quote:
 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

 2009-12-12, 19:34 #318 EdH     "Ed Hall" Dec 2009 Adirondack Mtns 2·3·5·112 Posts 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

 Similar Threads Thread Thread Starter Forum Replies Last Post EdH YAFU 8 2018-03-14 17:22 bsquared YAFU 119 2015-11-05 16:24 storflyt32 YAFU 2 2015-06-29 05:19 bsquared YAFU 12 2012-11-08 04:12 bsquared YAFU 21 2012-09-04 19:44

All times are UTC. The time now is 08:39.

Wed Mar 3 08:39:06 UTC 2021 up 90 days, 4:50, 0 users, load averages: 1.66, 1.47, 1.49