gnfs asm version sievers illegal instruction

[EdH]

Not sure where to post this, so I'll try here.

One of my machines won't run the assembly enhanced lasieve4I* sievers. It will compile and run the github version of the ggnfs sievers.

Is it my CPU or possibly my siever version, etc? The compiled sievers are taking about twice the time I expect from the asm versions.

My trouble example:

$ ./gnfs-lasieve4I14e -a TeamPoly -o test.rels -f 70000000 -c 1000 -v
gnfs-lasieve4I14e (with asm64): L1_BITS=15, SVN $Revision: 399 $
FBsize 4116453+0 (deg 5), 4118063+0 (deg 1)
Illegal instruction

My CPU info:

processor    : 1
vendor_id    : GenuineIntel
cpu family    : 15
model        : 4
model name    : Intel(R) Pentium(R) D CPU 2.80GHz
stepping    : 4
microcode    : 0x6
cpu MHz        : 2793.225
cache size    : 1024 KB
physical id    : 0
siblings    : 2
core id        : 1
cpu cores    : 2
apicid        : 1
initial apicid    : 1
fpu        : yes
fpu_exception    : yes
cpuid level    : 5
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips    : 5586.20
clflush size    : 64
cache_alignment    : 128
address sizes    : 36 bits physical, 48 bits virtual

I tried to run a gdb example, but I'm not familiar enough with it.

Lost cause, or is there something I can do?

Thanks...

[Batalov]

The cleanest way to build a binary specifically for this CPU is to build on it.
(A binary built elsewhere might have used AVX [or other] instructions [which the siever doesn't need and] your Pentium CPU doesn't have.)

The linux build for sievers is fairly straightforward. Just get the SVN branch and follow the INSTALL instructions. I am not aware of the state of the git fork.

[EdH]

Originally Posted by Batalov

The cleanest way to build a binary specifically for this CPU is to build on it.
(A binary built elsewhere might have used AVX [or other] instructions [which the siever doesn't need and] your Pentium CPU doesn't have.)

The linux build for sievers is fairly straightforward. Just get the SVN branch and follow the INSTALL instructions. I am not aware of the state of the git fork.

Thanks! The ones that are currently running were compiled on the using machine, from the github location. The SVN version didn't seem to compile for me anywhere, which is why I changed over to the github one, which appeared to be more up-to-date. But, that was quite some time ago. I usually compile ggnfs on every machine prior to copying the asm versions into the bin directory. In this case, the asm versions didn't work, so I reverted to the originals.

The asm versions I'm using in all my other machines are the ones B² made and provided here. They seem to run about twice the speed of the compiled versions on my machines. (I hope I'm not exaggerating too much...)

[Batalov]

That means that you are building non-asm versions. What exactly are you building? Are you building this one? (There is no difference between git and svn sources, but in each of them, there are two source code branches: this and this)

4*e asm versions do run almost exactly two times faster than the non-asm 4*e, no matter who builds them. There is no asm version that runs twice as fast as "the other" asm version, is there?

[EdH]

Originally Posted by Batalov

That means that you are building non-asm versions. What exactly are you building? Are you building this one? (There is no difference between git and svn sources, but in each of them, there are two source code branches: this and this)

4*e asm versions do run almost exactly two times faster than the non-asm 4*e, no matter who builds them. There is no asm version that runs twice as fast as "the other" asm version, is there?

Speed-wise I was referring to asm vs. non-asm. I am off to study the code at the links you supplied. I have probably been compiling the wrong branches.

The github page I've been using is this one, since it has a "Clone or download" button. I'm not familiar with downloading from other pages (branches?).

In case it's of importance, I'm also compiling via GCC on linux machines, most often with "make nocona" as the compile command. Is there a switch for asm that I've been missing? I have not studied (or, modified) the Makefile.

Thanks for the info. Off to study...

[Batalov]

There is no common makefile, instead use lines from "INSTALL" file as included in the source.

There is one optional step. Get proper static libgmp or build it from source with --enable-static; though it is the default, most binary packages don't contain static libs. If you don't want to mess with it, install gmp, gmp-devel, and remove "-static" from this Makefile.

[frmky]

Is this an old 64-bit Intel CPU? Might be the prefetchw instruction. See http://www.mersenneforum.org/showpos...3&postcount=23

[EdH]

Originally Posted by Batalov

There is no common makefile, instead use lines from "INSTALL" file as included in the source.

There is one optional step. Get proper static libgmp or build it from source with --enable-static; though it is the default, most binary packages don't contain static libs. If you don't want to mess with it, install gmp, gmp-devel, and remove "-static" from this Makefile.

All of this seemed to compile fine, but I ended up with:

$ ../ggnfs/bin/gnfs-lasieve4I14e -a TeamPoly -o test.rels -f 80000000 -c 1000 -v
gnfs-lasieve4I14e (with asm64): L1_BITS=15, SVN $Revision$
FBsize 4116453+0 (deg 5), 4118063+0 (deg 1)
Illegal instruction

Originally Posted by frmky

Is this an old 64-bit Intel CPU? Might be the prefetchw instruction. See http://www.mersenneforum.org/showpos...3&postcount=23

I found an instance of prefetchw in one of the files and removed the line, but I got the same result as above. I'll search the rest of the files to see if there is another.

Thank you for teaching me a lot more about the gnfs files. I will study this further. But, for now, I think I'll just let this machine chug along at half speed.

[Batalov]

Try changing

 define(l1_bits,14)dnl    in athlon64/ls-defs.asm

#define L1_BITS 14    in athlon64/siever-config.h

I think this one has only 16Kb per core...

[EdH]

Originally Posted by Batalov

Try changing

 define(l1_bits,14)dnl    in athlon64/ls-defs.asm

#define L1_BITS 14    in athlon64/siever-config.h

I think this one has only 16Kb per core...

I tried 14 and then 13, but the results are the same:

$ ../ggnfs/bin/gnfs-lasieve4I14e -a TeamPoly -o test.rels -f 80000000 -c 1000 -v
gnfs-lasieve4I14e (with asm64): L1_BITS=13, SVN $Revision$
FBsize 4116453+0 (deg 5), 4118063+0 (deg 1)
Illegal instruction

These are all with prefetchw removed.

How would I use gdb with gnfs-lasieve4I14e? Would that shed light on what instruction is "Illegal?"

Thanks...

[Batalov]

Originally Posted by EdH

I tried 14 and then 13, but the results are the same:

$ ../ggnfs/bin/gnfs-lasieve4I14e -a TeamPoly -o test.rels -f 80000000 -c 1000 -v
gnfs-lasieve4I14e (with asm64): L1_BITS=13, SVN $Revision$
FBsize 4116453+0 (deg 5), 4118063+0 (deg 1)
Illegal instruction

These are all with prefetchw removed.

How would I use gdb with gnfs-lasieve4I14e? Would that shed light on what instruction is "Illegal?"

Thanks...

Using your example above, you would run gdb as follows:

Step 0 (if it is not installed). sudo yum install -y gdb
Step 1. You edit Makefile and replace "-O3" with "-g -O"
Step 2. make
Step 3.

$ gdb ./gnfs-lasieve4I14e
GNU gdb (GDB) Amazon Linux (7.6.1-64.33.amzn1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-amazon-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/D/ggnfs/ggnfs_git/src/experimental/lasieve4_64/gnfs-lasieve4I14e...done.
(gdb) r -a TeamPoly -o test.rels -f 80000000 -c 1000 -v
Starting program: /tmp/D/ggnfs/ggnfs_git/src/experimental/lasieve4_64/./gnfs-lasieve4I14e -a TeamPoly -o test.rels -f 80000000 -c 1000 -v
gnfs-lasieve4I14e (with asm64): L1_BITS=15, SVN $Revision$
...

Then when in dies, type "where", "l", etc. It is possible that you will find that it dies in libgmp or other lib; -- that will give you hints what to update...