Yafu - Page 31

10metreh · 2010-02-08, 20:28

Quote:

Originally Posted by bsquared

The version of factMsieve.pl I have is probably old. It doesn't know about msieve degree 4 poly selection or gnfs-lasieve4I11e. Is there such a version of factMsieve.pl?

There is no version of factMsieve.pl which has msieve poly selection, but SVN 374 and onwards are compatible with 11e.

xilman · 2010-02-08, 20:44

Quote:

Originally Posted by 10metreh

There is no version of factMsieve.pl which has msieve poly selection, but SVN 374 and onwards are compatible with 11e.

Sounds like there is a demand for the Perl script to be maintained and, where possible, kept in sync with Brian's Python code.

I don't promise anything, but I've already made a few changes to the Perl script on my machine...

Paul

bsquared · 2010-02-08, 20:58

Well, most of the NFS I do is done "by hand" on larger numbers and I have my own scripts for that work.

When I do find myself wanting some automation for smaller jobs I'm restricted by the fact that 99% of my compute power is based on RHEL 5, or similar systems with no recent version of python. A sync'ed version of the perl script or a down-version ported python script would be ideal for those of us in this admittedly rather niche use case.

bsquared · 2010-02-09, 22:50

Quote:

Originally Posted by 10metreh

Get GGNFS. It's faster at 94 digits.

This is very dependent on your OS, and CPU architecture. For example, I've measured YAFU to be faster up to 95 digits and maybe beyond on core2 64 bit windows, compared to msieve degree 4 poly selection (CPU version) and 64 bit core2 ggnfs 11e (version 374). I suspect the same is probably true on opterons and athlon64s and with 32 bit and 64 bit windows OS's since that is where YAFU is fast. YAFU isn't really fast on P4's and P3's and older stuff and so msieve + ggnfs probably wins out there, but I'm unable to make the measurements.

64 bit linux is a different story, since there ggnfs gains from the assembly improvements. I've measured the crossover to be about 88 digits in that case. Maybe 1 digit lower if you're using msieve GPU poly selection.

mdettweiler · 2010-02-09, 23:19

Quote:

Originally Posted by bsquared

This is very dependent on your OS, and CPU architecture. For example, I've measured YAFU to be faster up to 95 digits and maybe beyond on core2 64 bit windows, compared to msieve degree 4 poly selection (CPU version) and 64 bit core2 ggnfs 11e (version 374). I suspect the same is probably true on opterons and athlon64s and with 32 bit and 64 bit windows OS's since that is where YAFU is fast. YAFU isn't really fast on P4's and P3's and older stuff and so msieve + ggnfs probably wins out there, but I'm unable to make the measurements.

64 bit linux is a different story, since there ggnfs gains from the assembly improvements. I've measured the crossover to be about 88 digits in that case. Maybe 1 digit lower if you're using msieve GPU poly selection.

Hmm, interesting. I have a Core 2 on 32-bit Windows, and I've been using GGNFS/msieve for anything bigger than 85 digits since the initial 11e crossover figures came out; I'll have to run some benchmarks sometime to refine that further, in light of this.

axn · 2010-02-10, 01:01

Quote:

Originally Posted by bsquared

64 bit linux is a different story, since there ggnfs gains from the assembly improvements. I've measured the crossover to be about 88 digits in that case.

I can second this. This is the setting that I am using.

However, for vista 32 bit, my crossover is 90/91 digits (tho with yafu version 1.08 -- has there been any speed improvements since then?)

EDIT:- Both on Core 2 Duo, 2GHz processor.

bsquared · 2010-02-10, 02:16

@max:
I would be interested in the results of any benchmarking you do, which is up to you, of course. I don't have any 32 bit systems with core2 based CPUs, so while I expect the crossover for those systems (and 32bit with opteron or phenom or athlon64) to be somewhere north of 90 digits, I haven't been able to test it myself. My comparison results for a windows 64 bit core 2 system are below. YAFU's speed is close to that achieved by the linux code, while the ggnfs siever's performance is 2x slower, which is what makes for quite a bit higher crossover point.

The 90 digit case is more than 2x slower, but this is because the slower poly selection didn't find as good of a polynomial to sieve with.

@axn:
1.16 should be noticeably faster, but I don't know exactly how much.

Code:

C85	1877138824359859508015524119652506869600959721781289179190693027302028679377371001561					
C90	750886878970491134480401867359489550454660065542753704510469658022612272495194857035724837					
C95	48404068520546498995797968938385187958997290617596242601254422967869040251141325866025672337021					
						
	64 bit linux (msieve, ggnfs, and yafu)					
		gnfs+msieve	11e			
	test num	poly	sieve	postproc	total(ggnfs+msieve)	yafu
	85	459	850	91	                1400	                        545
	90	468	1310	173	                1951	                        2460
	95	969	2849	380	                4198	                        6330

	64 bit windows (msieve, ggnfs, and yafu)					
		gnfs+msieve	11e			
	test num	poly	sieve	postproc	total(ggnfs+msieve)	yafu
	85	476	1407	57	                1940	                        666
	90	482	4234	139	                4855	                        2809
	95	983	6592	285	                7860	                        6842

axn · 2010-02-10, 02:59

Quote:

Originally Posted by bsquared

1.16 should be noticeably faster, but I don't know exactly how much.

I see only 1.15 on your site (http://sites.google.com/site/bbuhrow/home).

bsquared · 2010-02-10, 03:20

Quote:

Originally Posted by axn

I see only 1.15 on your site (http://sites.google.com/site/bbuhrow/home).

Ah, yes, sorry. 1.16 is my development version, but is the same, speedwise, as 1.15.

EdH · 2010-02-20, 17:24

Hi Ben,

This is from the machine I had the compilation trouble with. I don't recall if I've seen it on the others, but will try to catch it, if possible. Any ideas? (Or, is this just saying that the whole composite isn't factored?)

Code:

02/20/10 11:58:10 v1.14 @ localhost.localdomain, 
Initializing with Tom's Fast Math (x86-32 asm)...
cached 78504 primes. pmax = 1000099
detected cpu 8, with L1 = 65536 bytes, L2 = 65536 bytes

Processing expression: siqs(8009613806701035313358482906995630036368158402281908921632362193599907567635443487257)



***factors found***

P2 = 19
PRP6 = 223253
PRP10 = 1784059351

ans = 1

WARNING: couldn't find factor in factor.log

sieving in progress (press Ctrl-C to pause)

Is this within yafu, or is it during handoff?

Edit to add factor.log:

Code:

02/20/10 11:58:11 v1.14 @ localhost.localdomain, Starting SQUFOF on 398296602288803
02/20/10 11:58:11 v1.14 @ localhost.localdomain, prp6 = 223253
02/20/10 11:58:11 v1.14 @ localhost.localdomain, prp10 = 1784059351

Take Care,
Ed

bsquared · 2010-02-21, 19:04

That warning message isn't part of YAFU, is it aliquiet? But that factorization is also not right... it looks like the input was not parsed correctly. That's something I've not seen in years, so I'm guessing it's a build issue on your older pc. Having you been using YAFU for a while on this pc and this is the first time you've seen this problem, or are you just now trying it out again?

2010-02-10, 02:16	#337
bsquared "Ben" Feb 2007 110111000001₂ Posts	@max: I would be interested in the results of any benchmarking you do, which is up to you, of course. I don't have any 32 bit systems with core2 based CPUs, so while I expect the crossover for those systems (and 32bit with opteron or phenom or athlon64) to be somewhere north of 90 digits, I haven't been able to test it myself. My comparison results for a windows 64 bit core 2 system are below. YAFU's speed is close to that achieved by the linux code, while the ggnfs siever's performance is 2x slower, which is what makes for quite a bit higher crossover point. The 90 digit case is more than 2x slower, but this is because the slower poly selection didn't find as good of a polynomial to sieve with. @axn: 1.16 should be noticeably faster, but I don't know exactly how much. Code: C85 1877138824359859508015524119652506869600959721781289179190693027302028679377371001561 C90 750886878970491134480401867359489550454660065542753704510469658022612272495194857035724837 C95 48404068520546498995797968938385187958997290617596242601254422967869040251141325866025672337021 64 bit linux (msieve, ggnfs, and yafu) gnfs+msieve 11e test num poly sieve postproc total(ggnfs+msieve) yafu 85 459 850 91 1400 545 90 468 1310 173 1951 2460 95 969 2849 380 4198 6330 64 bit windows (msieve, ggnfs, and yafu) gnfs+msieve 11e test num poly sieve postproc total(ggnfs+msieve) yafu 85 476 1407 57 1940 666 90 482 4234 139 4855 2809 95 983 6592 285 7860 6842 Last fiddled with by bsquared on 2010-02-10 at 02:20

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Running YAFU via Aliqueit doesn't find yafu.ini	EdH	YAFU	8	2018-03-14 17:22
YAFU-1.34	bsquared	YAFU	119	2015-11-05 16:24
Yafu bug.	storflyt32	YAFU	2	2015-06-29 05:19
yafu-1.33	bsquared	YAFU	12	2012-11-08 04:12
yafu-1.32.1	bsquared	YAFU	21	2012-09-04 19:44

2010-02-08, 20:58	#333
bsquared "Ben" Feb 2007 7·503 Posts	Well, most of the NFS I do is done "by hand" on larger numbers and I have my own scripts for that work. When I do find myself wanting some automation for smaller jobs I'm restricted by the fact that 99% of my compute power is based on RHEL 5, or similar systems with no recent version of python. A sync'ed version of the perl script or a down-version ported python script would be ideal for those of us in this admittedly rather niche use case.

2010-02-21, 19:04	#341
bsquared "Ben" Feb 2007 7·503 Posts	That warning message isn't part of YAFU, is it aliquiet? But that factorization is also not right... it looks like the input was not parsed correctly. That's something I've not seen in years, so I'm guessing it's a build issue on your older pc. Having you been using YAFU for a while on this pc and this is the first time you've seen this problem, or are you just now trying it out again?