[quote=bsquared;196923]You're right, I failed to get the latest in there :blush:

But I tested it on two different windows platforms and everything worked fine, single or multi-threaded. For example on a core2 with 3 threads:

[code]Processing expression: factor(rand(80))

***** cpu looks to be about 3028.228560 MHz

factoring 9797819404810769263653579038358070159754699618874081742171517090591157705353813472429

div: primes less than 10000
rho: x^2 + 1, doing 1000 iterations on C82
rho: x^2 + 3, doing 1000 iterations on C82
rho: x^2 + 2, doing 1000 iterations on C82
pp1: base 859203183, doing B1 = 20K, B2 = 1M on C82, processed < 1000003
pp1: base 607275111, doing B1 = 20K, B2 = 1M on C82, processed < 1000003
pp1: base 3351482247, doing B1 = 20K, B2 = 1M on C82, processed < 1000003
pm1: base 2397117891, doing B1 = 100K, B2 = 5M on C82, processed < 5000011
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 205.084994 seconds
ecm: 3 curves on C82 input, at B1 = 2K, B2 = 200K
***** 15 digit level took 0.316767 seconds.
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 18.506633 seconds
***** estimating 17 more curves can be run at 20 digit level
ecm: 17 curves on C70 input, at B1 = 11K, B2 = 1100K
***** 20 digit level took 2.849680 seconds.
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 18.506633 seconds
***** estimating 2 more curves can be run at 25 digit level
ecm: 2 curves on C70 input, at B1 = 50K, B2 = 5M
***** 25 digit level took 3.153414 seconds.
***** using 64bit windows core2 data for QS time estimation
***** qs time estimate = 18.506633 seconds
***** estimating 0 more curves can be run at 30 digit level

starting SIQS on c70: 1613614204085568053637736215085340000483223603454440719731638328781401

==== sieve params ====
n = 70 digits, 230 bits
factor base: 11453 primes (max prime = 261619)
single large prime cutoff: 17005235 (65 * pmax)
allocating 7 large prime slices of factor base
buckets hold 1024 elements
sieve interval: 6 blocks of size 32768
polynomial A has ~ 8 factors
using multiplier of 1
using small prime variation correction of 18 bits
using SSE2 for trial division and x64 sieve scanning
trial factoring cutoff at 82 bits

==== sieving in progress ( 3 threads): 11517 relations needed ====
==== Press ctrl-c to abort and save state ====
9479 rels found: 4619 full + 4860 from 51774 partial, (3066.40 rels/sec)

trial division touched 756193 sieve locations out of 1761199128576
QS elapsed time = 21.0000 seconds.

==== post processing stage (msieve-1.38) ====
begin with 64584 relations
reduce to 17046 relations in 2 passes
attempting to read 17046 relations
recovered 17046 relations
recovered 14756 polynomials
attempting to build 11569 cycles
found 11569 cycles in 1 passes
distribution of cycle lengths:
length 1 : 5273
length 2 : 6296
largest cycle: 2 relations
matrix is 11453 x 11569 (1.4 MB) with weight 313167 (27.07/col)
sparse part has weight 313167 (27.07/col)
filtering completed in 3 passes
matrix is 10575 x 10639 (1.2 MB) with weight 284889 (26.78/col)
sparse part has weight 284889 (26.78/col)
saving the first 48 matrix rows for later
matrix is 10527 x 10639 (1.0 MB) with weight 230590 (21.67/col)
sparse part has weight 202306 (19.02/col)
matrix includes 64 packed rows
commencing Lanczos iteration
memory use: 1.4 MB
lanczos halted after 168 iterations (dim = 10527)
recovered 17 nontrivial dependencies
Lanczos elapsed time = 1.7660 seconds.
Sqrt elapsed time = 0.0940 seconds.
SIQS elapsed time = 22.8594 seconds.
ECM/SIQS ratio was = 0.275338

Total factoring time = 31.0781 seconds[/code]Frequency looks right: it predicted 18.5 seconds and it took 22.8... close enough given the errors inherent to the extrapolation equations. The ECM elapsed times also are recorded correctly. So if it's broken it doesn't look *too* broken. Is it different with win64?[/quote]

On my Core2 the timing is way out. The problem is that on some Windows systems you can assume that the frequencery counter is the same as the time stamp counter but on others this is not true.

But I have a more serious problem in that the x64 version of yafu-64k raises an illegal memory access exception at line 990 in relation.c :-(

Brian

[QUOTE=Brian Gladman;196925]On my Core2 the timing is way out. The problem is that on some Windows systems you can assume that the frequencery counter is the same as the time stamp counter but on others this is not true.

But I have a more serious problem in that the x64 version of yafu-64k raises an illegal memory access exception at line 990 in relation.c :-(

Brian[/QUOTE]

Ok, I have your latest timing source in my development code. The error you are seeing also shows up in linux 32bit compiles, but not linux64 or win32. Hoo boy, got some fun detective work ahead.

[quote=bsquared;196928]Ok, I have your latest timing source in my development code. The error you are seeing also shows up in linux 32bit compiles, but not linux64 or win32. Hoo boy, got some fun detective work ahead.[/quote]

I am happy to help out if I can.

Brian

I will make the Win64 binaries once these issues are sorted out. :smile:

If you need any help testing, I'd be happy to.

Jeff.

yafu 1.14 available
 

v. 1.14 now available [url=sites.google.com/site/bbuhrow]here[/url]

I'm starting to see a pattern develop... release an odd numbered version of code with some improvement or other in location X, receive immediate feedback that it is broken in location Y, fix and release a (pseudo) stable even numbered version :)

At least these fixes didn't take long:

New in Version 1.14
+ bugfixes and fixed memory leaks
+ got 32 bit linux builds working again
+ incorporated latest windows cpu frequency and timing code from Brian Gladman

- ben.

That pattern made linux very successful :)

What`s the right command to use multi-threadet ECM ?
Plz give a example like this ecm -2 (Number) <-don`t know the right command

[quote=Andi_HB;197094]What`s the right command to use multi-threadet ECM ?
Plz give a example like this ecm -2 (Number) <-don`t know the right command[/quote]
Note that this multi-threaded ECM is for YAFU's ECM implementation, which is slower than GMP-ECM's (ecm.exe) implementation.
Just set YAFU to use x threads and when you run any ECM through it, it'll use x threads.
e.g.[code]yafu "ecm(2348305321333187128721643453051615911877612201981824607595341595725431644675331447201502622476698707484077353247893830745261323782457787822233,200)" -threads 2 -B1ecm 50000 -B2ecm 12700000[/code]will use two threads and run 200 ECM curves.
However, again, this is YAFU's implementation, and is about 8 times slower (for my CPU with B1=50000, using GMP-ECM's default B2 for that B1) than GMP-ECM's. You can get work done twice as fast by running a single GMP-ECM instance than a 4-threaded YAFU ECM.

For now, it's still best to run separate GMP-ECM instances. The possible exception is where you have many small (<60 digits or so) candidates to factor, and want to keep it all within a single program. Then you can use YAFU and its factor() command, which is now almost completely multithreaded.

thank you Mini-Geek
I know that GMP-ECM ist faster - but Programms like Yafu & Msieve are "all in one" Programms and are running easier for users. And thats IMHO the best way for Numbers with less then 100 digits. Over 100 digits i use Programms like gmp-ecm, msieve (Polysearch), ggnfs ...
Interesting is that the command factor from yafu is allways using
multi-threadet ecm.

best Regards Andi_HB

when i run yafu on this number:
10232020301390992344903655184131
i get a reproducible crash. it also happens on many other small numbers i got from an aliquot sequence. does anyone know what caused this?

[quote=Buzzo;197515]when i run yafu on this number:
10232020301390992344903655184131
i get a reproducible crash. it also happens on many other small numbers i got from an aliquot sequence. does anyone know what caused this?[/quote]

Not yet... I'm looking into it.