Yafu - Page 71

bsquared · 2011-07-28, 18:19

Quote:

Originally Posted by Belteshazzar

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.

My thoughts exactly.

Quote:

Originally Posted by Belteshazzar

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.

I don't currently use anything beyond SSE2, although some things from SSE4.1 and AVX look promising: PMULLD and PEXTRD both look like they could be useful, and the 3 register AVX variants of SSE2 stuff could also help. Plenty of things to do still

Brian Gladman · 2011-07-28, 18:42

A useful feature of GAS is that it can now handle Intel format so implementing and then moving code in this format is now easier than it used to be.

Another interesting option is that the latest versions of the Intel compiler on Windows allow MSVC/Intel compiled files to be mixed so an Intel file with inline x64 can be used in an otherwise MSVC build. This could offer a stepping stone for building full x64 assembler support on Windows.

With a little care it is also be possible to write x64 assembler code that works with minimum changes on both Linux and Windows. Much of the x64 assembler code in MPIR is largely common across Linux and Windows. This is achieved by (a) using YASM (which is available on both platforms), (b) by designing the code with the two tagets in mind, and (c) handling differences in function prologues and epilogues.

bsquared · 2011-07-28, 18:55

Thanks Brian, that's great info.

I have myself to blame for the mess of in-line assembly macro's that litter much of YAFU. I typically get excited about some possiblity or other and immediately begin to hack at it with what I know best, which is AT&T and gcc. This is usually for some critical routine deep inside some loop, and to avoid converting the entire loop/function/file into assembler I make everything into an in-line assembler based C macro. This had led to some embarassingly long inline assembler statements. I'm then left with a mess to convert into the other platforms/OS's/compilers. I agree that a more sober, top-down approach to creating assembler code would yield more re-useable results.

It's nice to know that the tools are evolving to make this easier to do. Some day I'll need to learn how to create a proper function in assembly, complete with pushing and popping arguments from the stack. So far I've been able to get away with not knowing how to do that, but the source code is getting to be a jungle because of it.

Brian Gladman · 2011-07-28, 19:43

I am not going to do any 32-bit assembler but if we do bring msieve and yafu together, I am in a good position to contribute Windows x64 assembler code. I also have the macros that make building compliant x64 Windows assember code a lot easier.

henryzz · 2011-07-28, 21:18

Assuming that the assembler is supported by c code for non-supported systems I think non-SSE2 could probably be removed.

What is the situation for Athlon 64s which had slower SSE2? Which was optimal?

jasonp · 2011-07-29, 01:31

I think what's under debate here is whether we want a generic branch of things at all, not whether we should support more than SSE2 in inline asm.

(I do have a Mac laptop that uses a Core 2 Duo)

Andi47 · 2011-07-31, 14:36

I have downloaded and tested yafu 1.28.3 - it seems to work properly, but it keeps saying "Invalid line in yafu.ini, use Keyword=Value pairsSee docfile.txt for valid keywords"

What's wrong with this yafu.ini?

Code:

B1pm1=100000
B1pp1=20000
B1ecm=11000
rhomax=1000
threads=6
ggnfs_dir=<my GGNFS dir>
ecm_path=<my ECM path>
ecm_qs_ratio=0.25
ecm_gnfs_ratio=0.25

10metreh · 2011-07-31, 18:40

Is there a newline at the end of the file?

Andi47 · 2011-07-31, 19:56

Quote:

Originally Posted by 10metreh

Is there a newline at the end of the file?

Yes, there have been two of them. I deleted one (leaving one newline) - I will see what happens when aliqueit.exe invokes yafu next time.

10metreh · 2011-07-31, 20:21

Weird - I saw the message once with two newlines and I don't seem to get it anymore. The message didn't appear when I removed both the newlines, not sure what would have happened with one newline.

EdH · 2011-08-01, 15:16

I have run into the problem of non-SSE2 AMD CPUs with my ancient systems. Oddly, one of them is currently running circles around a similar Intel that has SSE2.

Anyway, why not work on the leading edge, drop support for anything that is hindering, but leave available in an archive somewhere, earlier versions that can be used by those of us who enjoy our steam-driven machines?

I would not mind using an earlier version instead of the latest and greatest, especially if it's due to my tardiness in upgrading. For some, the restrictions might even be the drive to go ahead and upgrade, instead of procrastinating.

2011-07-28, 18:42	#772
Brian Gladman May 2008 Worcester, United Kingdom 2²·7·19 Posts	A useful feature of GAS is that it can now handle Intel format so implementing and then moving code in this format is now easier than it used to be. Another interesting option is that the latest versions of the Intel compiler on Windows allow MSVC/Intel compiled files to be mixed so an Intel file with inline x64 can be used in an otherwise MSVC build. This could offer a stepping stone for building full x64 assembler support on Windows. With a little care it is also be possible to write x64 assembler code that works with minimum changes on both Linux and Windows. Much of the x64 assembler code in MPIR is largely common across Linux and Windows. This is achieved by (a) using YASM (which is available on both platforms), (b) by designing the code with the two tagets in mind, and (c) handling differences in function prologues and epilogues. Last fiddled with by Brian Gladman on 2011-07-28 at 18:43

2011-07-31, 14:36	#777
Andi47 Oct 2004 Austria 2·17·73 Posts	I have downloaded and tested yafu 1.28.3 - it seems to work properly, but it keeps saying "Invalid line in yafu.ini, use Keyword=Value pairsSee docfile.txt for valid keywords" What's wrong with this yafu.ini? Code: B1pm1=100000 B1pp1=20000 B1ecm=11000 rhomax=1000 threads=6 ggnfs_dir=<my GGNFS dir> ecm_path=<my ECM path> ecm_qs_ratio=0.25 ecm_gnfs_ratio=0.25

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-28, 18:55	#773
bsquared "Ben" Feb 2007 2×3×587 Posts	Thanks Brian, that's great info. I have myself to blame for the mess of in-line assembly macro's that litter much of YAFU. I typically get excited about some possiblity or other and immediately begin to hack at it with what I know best, which is AT&T and gcc. This is usually for some critical routine deep inside some loop, and to avoid converting the entire loop/function/file into assembler I make everything into an in-line assembler based C macro. This had led to some embarassingly long inline assembler statements. I'm then left with a mess to convert into the other platforms/OS's/compilers. I agree that a more sober, top-down approach to creating assembler code would yield more re-useable results. It's nice to know that the tools are evolving to make this easier to do. Some day I'll need to learn how to create a proper function in assembly, complete with pushing and popping arguments from the stack. So far I've been able to get away with not knowing how to do that, but the source code is getting to be a jungle because of it.

2011-07-28, 19:43	#774
Brian Gladman May 2008 Worcester, United Kingdom 2²×7×19 Posts	I am not going to do any 32-bit assembler but if we do bring msieve and yafu together, I am in a good position to contribute Windows x64 assembler code. I also have the macros that make building compliant x64 Windows assember code a lot easier.

2011-07-28, 21:18	#775
henryzz Just call me Henry "David" Sep 2007 Cambridge (GMT/BST) 7×29² Posts	Assuming that the assembler is supported by c code for non-supported systems I think non-SSE2 could probably be removed. What is the situation for Athlon 64s which had slower SSE2? Which was optimal?

2011-07-29, 01:31	#776
jasonp Tribal Bullet Oct 2004 3×1,181 Posts	I think what's under debate here is whether we want a generic branch of things at all, not whether we should support more than SSE2 in inline asm. (I do have a Mac laptop that uses a Core 2 Duo)

2011-07-31, 18:40	#778
10metreh Nov 2008 4422₈ Posts	Is there a newline at the end of the file?

2011-07-31, 20:21	#780
10metreh Nov 2008 100100010010₂ Posts	Weird - I saw the message once with two newlines and I don't seem to get it anymore. The message didn't appear when I removed both the newlines, not sure what would have happened with one newline.

2011-08-01, 15:16	#781
EdH "Ed Hall" Dec 2009 Adirondack Mtns 23×167 Posts	I have run into the problem of non-SSE2 AMD CPUs with my ancient systems. Oddly, one of them is currently running circles around a similar Intel that has SSE2. Anyway, why not work on the leading edge, drop support for anything that is hindering, but leave available in an archive somewhere, earlier versions that can be used by those of us who enjoy our steam-driven machines? I would not mind using an earlier version instead of the latest and greatest, especially if it's due to my tardiness in upgrading. For some, the restrictions might even be the drive to go ahead and upgrade, instead of procrastinating.