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

 2013-09-24, 22:18 #1 bsquared     "Ben" Feb 2007 3,671 Posts Progress 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.
 2013-09-25, 13:44 #2 bsquared     "Ben" Feb 2007 71278 Posts 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
 2013-09-25, 13:51 #3 bsquared     "Ben" Feb 2007 3,671 Posts 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?
 2013-09-25, 16:14 #4 Antonio     "Antonio Key" Sep 2011 UK 10000100112 Posts 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. Last fiddled with by Antonio on 2013-09-25 at 16:24
2013-09-25, 16:25   #5
bsquared

"Ben"
Feb 2007

E5716 Posts

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

2013-09-25, 16:30   #6
bsquared

"Ben"
Feb 2007

3,671 Posts

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

2013-09-27, 07:06   #7
ldesnogu

Jan 2008
France

23B16 Posts

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

2013-09-27, 13:47   #8
bsquared

"Ben"
Feb 2007

3,671 Posts

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

 2013-10-09, 02:56 #9 bsquared     "Ben" Feb 2007 3,671 Posts 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: Code: 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: Code: 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.
2013-10-20, 14:20   #10
Antonio

"Antonio Key"
Sep 2011
UK

32·59 Posts

Ben,

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

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

 2013-10-20, 21:36 #11 VBCurtis     "Curtis" Feb 2005 Riverside, CA 2×3×11×83 Posts 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post KEP Conjectures 'R Us 54 2018-01-04 18:25 schickel FactorDB 29 2012-07-18 17:03 R.D. Silverman Factoring 0 2012-05-22 14:03 R.D. Silverman Cunningham Tables 33 2010-05-07 14:02 ATH Data 1 2006-06-22 23:04

All times are UTC. The time now is 18:32.

Fri Sep 30 18:32:11 UTC 2022 up 43 days, 16 hrs, 0 users, load averages: 1.42, 1.27, 1.23