Yafu

[bsquared]

I just committed changes to SVN which make siqs about 10% faster for 64 bit linux. This was done through the use of assembly routines in the bucket sieving portion of SIQS.

I haven't been able to test on an AMD system. If anyone successfully builds/tests on a phenom/athlon/opteron system, I'd be interested to hear about it. Remember to use BLOCK=64 when running make.

enjoy,
- ben.

[rekcahx]

Originally Posted by bsquared

I just committed changes to SVN which make siqs about 10% faster for 64 bit linux. This was done through the use of assembly routines in the bucket sieving portion of SIQS.

I haven't been able to test on an AMD system. If anyone successfully builds/tests on a phenom/athlon/opteron system, I'd be interested to hear about it. Remember to use BLOCK=64 when running make.

I've a phenom 9950 x4 system, so how to test? Currently I run quite large job with 2 cores, so I'm able run tests only on 2 remaining cores.

[bsquared]

Originally Posted by rekcahx

I've a phenom 9950 x4 system, so how to test? Currently I run quite large job with 2 cores, so I'm able run tests only on 2 remaining cores.

I've put new linux binaries on my webpage. You can try these (use the 64k version, as usual), but linux being how it is, it might not work due to some library incompatibility or another.

The alternative is to obtain and build each of gmp, gmp-ecm, msieve, and yafu from their repositories, in that order. This, needless to say, is a much less straightforward approach. I became comfortable with doing that chore only after several years of sporadic hair pulling. Perfectly fine if you don't want to go down that road, but it would also be interesting to hear how easy (or not) that approach is for someone new to the process.

In any case, thanks for your interest!

[bsquared]

Originally Posted by bsquared

I just committed changes to SVN which make siqs about 10% faster for 64 bit linux....

I wasn't sure if it would make a noticeable impact, but I found this raised the SIQS/GNFS crossover by about 1 digit, after running "tune" again (from 95 to 96 digits on my system).

[CRGreathouse]

~$ ./yafu-64k-linux64
./yafu-64k-linux64: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory
~$ locate libgmp.so.
/home/username/lib/libgmp.so.3
/home/username/lib/libgmp.so.3.5.2
/home/username/mth/gmp-4.3.1/.libs/libgmp.so.3
/home/username/mth/gmp-4.3.1/.libs/libgmp.so.3.5.0
/home/username/mth/gmp-5.0.0/.libs/libgmp.so.3
/home/username/mth/gmp-5.0.0/.libs/libgmp.so.3.6.0
/home/username/mth/gmp-5.0.0/tests/cxx/.libs/libgmp.so.3
/home/username/mth/gmp-5.0.0/tests/cxx/.libs/libgmp.so.3.6.0
/usr/lib/libgmp.so.3
/usr/lib/libgmp.so.3.5.2
/usr/local/lib/libgmp.so.3
/usr/local/lib/libgmp.so.3.6.0

[bsquared]

Originally Posted by CRGreathouse

~$ ./yafu-64k-linux64
./yafu-64k-linux64: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory
~$ locate libgmp.so.
/home/username/lib/libgmp.so.3
/home/username/lib/libgmp.so.3.5.2
/home/username/mth/gmp-4.3.1/.libs/libgmp.so.3
/home/username/mth/gmp-4.3.1/.libs/libgmp.so.3.5.0
/home/username/mth/gmp-5.0.0/.libs/libgmp.so.3
/home/username/mth/gmp-5.0.0/.libs/libgmp.so.3.6.0
/home/username/mth/gmp-5.0.0/tests/cxx/.libs/libgmp.so.3
/home/username/mth/gmp-5.0.0/tests/cxx/.libs/libgmp.so.3.6.0
/usr/lib/libgmp.so.3
/usr/lib/libgmp.so.3.5.2
/usr/local/lib/libgmp.so.3
/usr/local/lib/libgmp.so.3.6.0

Originally Posted by bsquared

... linux being how it is, it might not work due to some library incompatibility or another.

On a more helpful note, libgmp.so.10 is what I get when I build gmp-5.0.1. Maybe you could get away with renaming a copy of your 5.0.0 library to what is expected?

I use a pretty old build environment, so there might be other problems as well.

[bsquared]

I found a AMD box I could test on and everything seemed to work fine. I also ported a subset of the new gcc ASM code talked about in the last few posts to Windows, so SIQS now has a speedup across the board. Bigger numbers should benefit more - I've seen up to 10% improvements.

Other changes include:

+ added a -plan switch for greater selectivity in pretesting plans using factor().  
    You can now select -plan <light|normal|deep|none> and the pretesting 
    will proceed differently in each case (hopefully fairly self-descriptive)
+ added several new output option switches, -ou, -of, -op.  
    for details see the docfile
+ changed logfile output of found ECM factors to record the B1 value used
+ added a -pretest switch to tell factor() to only pretest (skip sieve methods)
+ fixed a bug in the extract factors function in nfs.c; 
    factors found in the sqrt step were not reported correctly (thanks Andi_HB)

A big thanks, as usual, to reporters of bugs. And also to wraithx, who is braving the yafu code labyrinth and adding some neat options - much appreciated.

Cheers,
- ben.

link

[lorgix]

I'm not sure I'm using the right GGNFS.

02/06/11 16:32:16 v1.23 @ PERIMETROS, nfs: commencing gnfs on c99: 'the actual number here'
02/06/11 16:32:16 v1.23 @ PERIMETROS, nfs: commencing msieve poly select

And then it fails.

[lorgix]

It's working now. I don't know what changed...

[bsquared]

Great! That was easy... *dusts hands*

[bsquared]

In all seriousness though, as I mentioned over IM - if you continue to see intermittent failures like this I'd start to look into hardware failures of any of cpu|memory|disk. msieve has been known to discover hardware faults (or reveal instability) that other stress tests do not.