Progress

[bsquared]

After a lengthy break, I've dusted off the code recently and started making some progress toward the next release of yafu.

A couple bugs have been fixed, and I've started to enhance the capabilities of the SNFS polynomial generator by extending what can be autodetected. Also, the SNFS detection is now done early within factor(), so that ECM effort will be reduced if the input is SNFSable.

No pre-compiled binaries available, but the latest is in SVN 321. If anyone plays around with it, let me know how it goes.

[bsquared]

A few more things now in SVN 322:

• command line is less picky about argument ordering... expression can either be first, or be anywhere else, preceeded by -e, e.g., ./yafu -v -threads 2 -e "factor(rsa(256))"
• yafu will now default to factor() applied to the input, if no other function is given, e.g., ./yafu 12345 will commence to factor 12345. this only applies to command line expressions
• added new command expr(), to evaulate numerical expressions from the command line

[bsquared]

My Haswell system has arrived! As soon as I can get it to dual boot into linux, I'll start AVX2 development.

Does anyone have any experience with dual booting alongside windows 8? Will an ubuntu live DVD Just Work?

[Antonio]

Great news, and enjoy the new system.

Please don't forget to reduce/remove the screen printout during the poly selection phase in the next release.

A quick question about Tune(). I notice that tuning is done using a single thread.
Is there a possibility of memory bottlenecks using multiple threads and if so would a multi-threaded Tune() be possible to take this into account?

P.S.
Just a little niggle and of no consequence what-so-ever , I have a 3570k running at 4.5GHz, Yafu 1.34.5 currently reports the measured speed as somewhere around 3.3GHz (i.e. less than the default 3.4GHz), so there is something wrong with your method of measuring speed.

[bsquared]

Originally Posted by Antonio

Great news, and enjoy the new system.

Please don't forget to reduce/remove the screen printout during the poly selection phase in the next release.

A quick question about Tune(). I notice that tuning is done using a single thread.
Is there a possibility of memory bottlenecks using multiple threads and if so would a multi-threaded Tune() be possible to take this into account?

I'll see what I can do about the screen output, IIRC it just involves commenting out a few lines in the msieve source.

Re: tune(), good question, but nah, multiple threads shouldn't impact the answer much. It would make tune run faster, but any memory bottlenecks would be experienced by both qs and nfs, so there shouldn't be any relative change in speed. Right now tune is only used to determine the best qs/gnfs crossover point.

[bsquared]

Originally Posted by Antonio

P.S.
Just a little niggle and of no consequence what-so-ever , I have a 3570k running at 4.5GHz, Yafu 1.34.5 currently reports the measured speed as somewhere around 3.3GHz (i.e. less than the default 3.4GHz), so there is something wrong with your method of measuring speed.

Maybe, and maybe not . I measure speed by counting clock cycles (using __rdtsc) over a small time interval. Today's processors dynamically change the clock rate depending on the cpu load, so if you start yafu while your computer isn't doing much, the system is likely underclocked and the reported frequency is likely correct.

But as you said, it doesn't matter at all... the number is not used for anything other than something neat to look at.

[ldesnogu]

Originally Posted by bsquared

Maybe, and maybe not . I measure speed by counting clock cycles (using __rdtsc) over a small time interval. Today's processors dynamically change the clock rate depending on the cpu load, so if you start yafu while your computer isn't doing much, the system is likely underclocked and the reported frequency is likely correct.

When I was playing with my i7 920 some years ago, I noticed that rdtsc never takes turbo into account. Getting frequency without cooperation of the OS has become very difficult.

[bsquared]

Originally Posted by ldesnogu

When I was playing with my i7 920 some years ago, I noticed that rdtsc never takes turbo into account. Getting frequency without cooperation of the OS has become very difficult.

True, and what's more, it is largely a meaningless number by itself. I remember when I had a PIV that ran at 3.8 GHz, and my 3.4 GHz Haswell is probably as productive as 20 of those systems were.

[bsquared]

Killing time between hard stuff: made YAFU much more robust dealing with pipes/redirects with or without other command line arguments.

And a new 'repeat' switch... no real reason, but now one can do fun stuff like this:

yafu "rsa(128)" -repeat 200 | yafu

if for some reason you want your computer to go off and factor 200 random 128-bit RSA keys.

Or this:

yafu -v -threads 8 -B1ecm 250000 -e "siqs(ecm(@,100))" < input.txt

to apply some ecm and then QS on all of the numbers in a file.

SVN 323.

[Antonio]

Ben,

I was re-reading the doc file that came with 1.34.5, before trying a little experiment, when I noticed this :-

[siqs]
usage: siqs(expression)
description:
the siqs factoring method. uses the double large prime variation, small prime variation,
bucket sieving, and too many other optimizations to mention. post-processing is
performed using a port of Jason Papadopoulos's msieve filtering and block Lanczos implementations.
Best if used for inputs < 105 digits. Above that, parameter settings
have not been tested much. Hard cap at 150 digits.

Tune() sets the cross-over at >106 digits on my machine (i5 3570K @4.5GHz, 16GB RAM). Newer i5s and i7s may set it even higher.

For the next version is it time to do some parameter testing for higher digit counts?

[VBCurtis]

Do you have the 64-bit NFS sievers? Those double sieving speed, which moved my tune() crossover from 105 to 96 digits on a laptop i7.