Yafu - Page 70

Karl M Johnson · 2011-07-21, 12:29

Aha, works, thanx!

smh · 2011-07-21, 12:46

Quote:

Originally Posted by bsquared

That is pretty bizarre. There is no code in between the printing of the random seeds and the sieve parameters that would cause a bunch of random PRPs to be logged. And look at the time stamps! No idea what's going on here. Do you have several processes going at once that might be competing for the log file? Is this Windows or Linux?

Windows 7 64bit. I was running with the -batchfile option. There is another case like this in the log but i haven't seen it anymore. Probably after a restart or something. I hadn't even noticed the timestamps. Weird.

bsquared · 2011-07-21, 12:52

Quote:

Originally Posted by smh

Windows 7 64bit. I was running with the -batchfile option. There is another case like this in the log but i haven't seen it anymore. Probably after a restart or something. I hadn't even noticed the timestamps. Weird.

Weird, indeed. For now, this is going into the unsolved mysteries case file. Hopefully it remains infrequent. (on the other hand, if it *was* frequent, I might have a better idea of what was going on...). Thanks for the report.

bsquared · 2011-07-22, 03:35

Just uploaded a fix for a bug in the new external ecm binary option. Kar_bon noticed that after a while ecm'ing, it would crash. I had forgotten to close a file in a loop

, and hadn't tested long enough to see the crash.

bsquared · 2011-07-25, 02:25

Just uploaded a new version with a couple of bugfixes, including one which crippled the speed of Win32-based double large prime factorizations. Definately download this one if you are running on Win32 and are currently using 1.28 or 1.28.1

Also sped up the tinyQS routine by another 10-25% (depending on the input size).

10metreh · 2011-07-25, 19:35

When an nfs job is interrupted with Ctrl+C, the sudden killing of the siever causes the last line of the relation file to be incomplete. When the job is restarted, yafu can't find the special-q to restart from because the last line is corrupt. Removing the corrupt line works. Seems that yafu doesn't look at earlier lines if one is improperly formatted.

Also, with restarts, yafu occasionally hangs when looking for the last special-q. It finds the relation file - or at least that's what it says. But it never finds anything, and uses hardly any of the CPU (varies from 0 to a couple of percent). It isn't reproducible - yafu restarts perfectly normally the second time.

bsquared · 2011-07-28, 03:53

Thanks 10metreh, I addressed that issue (I hope) and a couple others kar_bon found when running in the interactive environment.

Also sped up smallmpqs some more, and another tiny speedup to siqs (32k with 64 bit only).

bsquared · 2011-07-28, 16:20

The SSE2 instruction set has been around for a while now (over a decade for Intel chips and 8 years for AMD, according to wikipedia).

4 years ago when I started YAFU, it was relevant to keep code paths for both SSE2 capable CPUs and non-SSE2. The amount of SSE2 code back then was also more manageable. Now, SSE2 instruction set capable CPUs are much more prevalent and SSE2 code is used much more (SIQS trial division, for example, is almost completely SSE2 based). The non-SSE2 code paths are becoming a pain to maintain, and in fact they are probably getting slower, since they have had to change to accomodate data structures which have been re-designed to facilitate SSE2 instructions.

So my question is, it is reasonable to jettison the non-SSE2 stuff, at least from SIQS? Does anyone currently use YAFU on a circa 2003 CPU?

jasonp · 2011-07-28, 16:53

The only reasonable alternative is a PowerPC, and the last PowerPC desktop was probably made in 2007.

Does the current SSE2 code work in MSVC? I'd think this is a bigger concern, since the world runs on x86 now but the calling conventions for Windows x64 are different.

bsquared · 2011-07-28, 17:42

Quote:

Originally Posted by jasonp

The only reasonable alternative is a PowerPC, and the last PowerPC desktop was probably made in 2007.

Does the current SSE2 code work in MSVC? I'd think this is a bigger concern, since the world runs on x86 now but the calling conventions for Windows x64 are different.

Yes, but with no small amount of pain on my end. I develop the assembly stuff on linux, using gcc's AT&T syntax, then once stuff works, translate everything to both Intel syntax (for 32 bit MSVC) *and*, when possible, MSVC compiler intrinsics for 64 bit MSVC. Not all of the assembly I write is possible to implement using just intrinsics for 64 bit MSVC, so 64 bit MSVC builds are probably slower than my pre-built 64 bit windows binaries that were created with mingw-64. I haven't yet learned how to write 64 bit assembly files (in Intel syntax) that 64 bit MSVC can deal with. As long as mingw-64 is there, I also don't have much motivation to do so.

The combination of supporting complex routines, in 3 different flavors of assembly, for 2 very different compilers (3 if you count Intel's), and 2 very different OS's, is enough work (just look at the top of /factor/qs/tdiv_med.c) without also having to worry about whether or not the machine supports an instruction set that's been around for a decade.

Speaking of OS's, I would really like to add Mac to the list of supported OS's, but without a platform to test on it just hasn't worked out.

Belteshazzar · 2011-07-28, 18:05

It's certainly fine to discontinue support for x86 processors without SSE2- using a Pentium 3 or an original Athlon for serious number-crunching in this day and age would be absurd.

If any SSE3 instructions are actually helpful, it'd be fine to only support processors with SSE3- every x86 chip released in 2005 or later (incl. VIA) supports it.

Though I'd guess that almost everyone running YAFU would be using considerably more recent processors than that, the next time we'll reach a new lowest common denominator in terms of instruction support will be when you can safely assume Sandy Bridge or newer on the Intel side and Bulldozer or newer on the AMD side.

2011-07-25, 02:25	#764
bsquared "Ben" Feb 2007 2·3·587 Posts	version 1.28.2 Just uploaded a new version with a couple of bugfixes, including one which crippled the speed of Win32-based double large prime factorizations. Definately download this one if you are running on Win32 and are currently using 1.28 or 1.28.1 Also sped up the tinyQS routine by another 10-25% (depending on the input size).

2011-07-28, 03:53	#766
bsquared "Ben" Feb 2007 3522₁₀ Posts	1.28.3 available Thanks 10metreh, I addressed that issue (I hope) and a couple others kar_bon found when running in the interactive environment. Also sped up smallmpqs some more, and another tiny speedup to siqs (32k with 64 bit only).

2011-07-28, 16:20	#767
bsquared "Ben" Feb 2007 6702₈ Posts	Question The SSE2 instruction set has been around for a while now (over a decade for Intel chips and 8 years for AMD, according to wikipedia). 4 years ago when I started YAFU, it was relevant to keep code paths for both SSE2 capable CPUs and non-SSE2. The amount of SSE2 code back then was also more manageable. Now, SSE2 instruction set capable CPUs are much more prevalent and SSE2 code is used much more (SIQS trial division, for example, is almost completely SSE2 based). The non-SSE2 code paths are becoming a pain to maintain, and in fact they are probably getting slower, since they have had to change to accomodate data structures which have been re-designed to facilitate SSE2 instructions. So my question is, it is reasonable to jettison the non-SSE2 stuff, at least from SIQS? Does anyone currently use YAFU on a circa 2003 CPU? Last fiddled with by bsquared on 2011-07-28 at 16:22

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

2011-07-21, 12:29	#760
Karl M Johnson Mar 2010 3×137 Posts	Aha, works, thanx!

2011-07-22, 03:35	#763
bsquared "Ben" Feb 2007 2×3×587 Posts	Just uploaded a fix for a bug in the new external ecm binary option. Kar_bon noticed that after a while ecm'ing, it would crash. I had forgotten to close a file in a loop , and hadn't tested long enough to see the crash.

2011-07-25, 19:35	#765
10metreh Nov 2008 912₁₆ Posts	When an nfs job is interrupted with Ctrl+C, the sudden killing of the siever causes the last line of the relation file to be incomplete. When the job is restarted, yafu can't find the special-q to restart from because the last line is corrupt. Removing the corrupt line works. Seems that yafu doesn't look at earlier lines if one is improperly formatted. Also, with restarts, yafu occasionally hangs when looking for the last special-q. It finds the relation file - or at least that's what it says. But it never finds anything, and uses hardly any of the CPU (varies from 0 to a couple of percent). It isn't reproducible - yafu restarts perfectly normally the second time.

2011-07-28, 16:53	#768
jasonp Tribal Bullet Oct 2004 3×1,181 Posts	The only reasonable alternative is a PowerPC, and the last PowerPC desktop was probably made in 2007. Does the current SSE2 code work in MSVC? I'd think this is a bigger concern, since the world runs on x86 now but the calling conventions for Windows x64 are different.

2011-07-28, 18:05	#770
Belteshazzar Feb 2011 40₈ Posts	It's certainly fine to discontinue support for x86 processors without SSE2- using a Pentium 3 or an original Athlon for serious number-crunching in this day and age would be absurd. If any SSE3 instructions are actually helpful, it'd be fine to only support processors with SSE3- every x86 chip released in 2005 or later (incl. VIA) supports it. Though I'd guess that almost everyone running YAFU would be using considerably more recent processors than that, the next time we'll reach a new lowest common denominator in terms of instruction support will be when you can safely assume Sandy Bridge or newer on the Intel side and Bulldozer or newer on the AMD side.