Let's do another nice big GNFS job! - Page 2

Andi47 · 2010-11-14, 12:35

Quote:

Originally Posted by ET_

Response: 550 Failed to open file. :-(

May I start working on with my executable and eventually exchange it with a newer version during the run?

Luigi

doesn't work for me, too. I get a "550 - failed to change directory" when I click the link.

Yes, you can start for now. When you want to exchange it with a newer version, just interrupt the run with Strg-C, copy the new executable to your working directory and make sure to add "-R" (= resume) to the command line when you restart.

edit: when I try to type "ftp ftp://ssh.fivemack.org" in the command line window, I get an "unknown host" error. Afterwards it *looks like* I'm connected to an ftp server (the command line starting with "ftp>", but when I type something like "dir" or "ls", I get a "not connected" error.

fivemack · 2010-11-14, 12:38

try http://www.fivemack.org/gnfs-lasieve4I16e

But I think your timings are right; I'm getting 1.2s per relation running eight threads on an i7/2666.

mdettweiler · 2010-11-14, 19:13

Quote:

Originally Posted by Andi47

edit: when I try to type "ftp ftp://ssh.fivemack.org" in the command line window, I get an "unknown host" error. Afterwards it *looks like* I'm connected to an ftp server (the command line starting with "ftp>", but when I type something like "dir" or "ls", I get a "not connected" error.

What about just "ftp ssh.fivemack.org"?

bsquared · 2010-11-18, 13:10

I'm getting some SCHED_PATHOLOGY messages in the 26M range:

Code:

SCHED_PATHOLOGY q0=26204357 k=10938 excess=4

Do I just have an old binary, or are other people seeing this too? I don't think I've used this 16e binary before...

fivemack · 2010-11-18, 13:49

Batalov is the authority on this; I'm not seeing such messages in the 25-26 range, so I suspect you have a slightly older 16e in which the guard band for sched isn't quite wide enough. Do you see the same things with the gnfs-lasieve4I16e linked to earlier in the thread?

bsquared · 2010-11-18, 14:33

Quote:

Originally Posted by fivemack

Batalov is the authority on this; I'm not seeing such messages in the 25-26 range, so I suspect you have a slightly older 16e in which the guard band for sched isn't quite wide enough. Do you see the same things with the gnfs-lasieve4I16e linked to earlier in the thread?

I rebuilt with the latest SVN and still saw the problem:

Code:

% gnfs-lasieve4I16e -a 2+956.poly -f 26204300 -M 1 -c 100 -o test.dat
SCHED_PATHOLOGY q0=26204357 k=10938 excess=4
total yield: 296, q=26204413 (0.64003 sec/rel)

But your binary works fine:

Code:

% gnfs-lasieve4I16e -a 2+956.poly -f 26204300 -M 1 -c 100 -o test2.dat
Warning:  lowering FB_bound to 26204299.
total yield: 317, q=26204413 (0.63211 sec/rel)

Is that code not in SVN, or am I not looking in the right place?

I built from trunk/experimental/lasieve4_64

Gimarel · 2010-11-18, 18:02

I got 3 SCHED_PATHOLOGY messages so far:

Code:

SCHED_PATHOLOGY q0=20304173 k=7762 excess=10                      
SCHED_PATHOLOGY q0=20912303 k=8136 excess=4                      
SCHED_PATHOLOGY q0=22223849 k=6053 excess=4

It seems to be related to L1_BITS=16.

Code:

./gnfs-lasieve4I16e-16Bit -v -M 1 -n0 -a 2+956.poly -o test-20304173 -f 20304150 -c 50
gnfs-lasieve4I16e (with asm64): L1_BITS=16, SVN $Revision: 399 $
Warning:  lowering FB_bound to 20304149.
FBsize 1288156+0 (deg 5), 8444395+0 (deg 1)
SCHED_PATHOLOGY q0=20304173 k=7762 excess=10                      
total yield: 242, q=20304209 (0.82083 sec/rel) 
6 Special q, 10 reduction iterations
reports: 14455510->741216->654709->415782->415678->215493
Number of relations with k rational and l algebraic primes for (k,l)=:

Total yield: 242
0/0 mpqs failures, 6546/2534 vain mpqs
milliseconds total: Sieve 132220 Sched 0 medsched 13330
TD 34660 (Init 220, MPQS 10860) Sieve-Change 18450
TD side 0: init/small/medium/large/search: 2380 3470 990 3910 850
sieve: init/small/medium/large/search: 1600 25580 880 35020 2090
TD side 1: init/small/medium/large/search: 2420 2860 1100 4780 760
sieve: init/small/medium/large/search: 1040 13450 730 51440 390

Code:

./gnfs-lasieve4I16e-15Bit -v -M 1 -n0 -a 2+956.poly -o test-20304173 -f 20304150 -c 50
gnfs-lasieve4I16e (with asm64): L1_BITS=15, SVN $Revision: 399 $
Warning:  lowering FB_bound to 20304149.
FBsize 1288156+0 (deg 5), 8444395+0 (deg 1)
total yield: 269, q=20304209 (0.85959 sec/rel) 
7 Special q, 10 reduction iterations
reports: 15948682->820939->724560->460188->460064->238343
Number of relations with k rational and l algebraic primes for (k,l)=:

Total yield: 269
0/0 mpqs failures, 7278/2796 vain mpqs
milliseconds total: Sieve 166900 Sched 0 medsched 6860
TD 39240 (Init 400, MPQS 11230) Sieve-Change 18260
TD side 0: init/small/medium/large/search: 4190 3320 260 4560 960
sieve: init/small/medium/large/search: 1490 27660 110 46140 3080
TD side 1: init/small/medium/large/search: 4220 3420 210 5520 860
sieve: init/small/medium/large/search: 1110 16860 90 69710 650

bsquared · 2010-11-18, 18:47

Quote:

Originally Posted by Gimarel

I got 3 SCHED_PATHOLOGY messages so far:

Code:

SCHED_PATHOLOGY q0=20304173 k=7762 excess=10                      
SCHED_PATHOLOGY q0=20912303 k=8136 excess=4                      
SCHED_PATHOLOGY q0=22223849 k=6053 excess=4

It seems to be related to L1_BITS=16.

Interesting: both of the binaries I used which produced these messages were 15 bit. I'm not sure what fivemack's uses.

Batalov · 2010-11-18, 19:12

When this happens, a special q is skipped, which results in a loss ~20-30 relations.

I've got one or two, as well. That's fine; this is a balance between wasting memory and losing 10^-5 - 10^-4 relations. This is poly- and range-specific. On some numbers none of the sched-runaways happen. The schedule allocation boundary is about right, but those of you who can rebuild, do so with SCHED_PAD increased by the excess that you are seeing plus some more pad (e.g. add 12 or 16).

In fact, we could collect all failed q0 and run them separately with the generously padded siever on a CPU with large available memory! :-)

bsquared · 2010-11-18, 19:18

Quote:

Originally Posted by Batalov

I've got one or two, as well. That's fine; this is a balance between wasting memory and losing 10^-5 - 10^-4 relations.
The schedule allocation boundary is about right.

P.S. When this happens, a special q is skipped, which results in a loss ~20-30 relations.

Yeah, I'm not particularly worried about it either, but any idea why my SVN build produces pathologies and Tom's binary doesn't? Maybe his is 16 bit and its a 15/16 bit thing.

Batalov · 2010-11-18, 19:43

It definitely has to do the siever being 16e (there are some plugs in the code where infinite loops happened, the reason is hard to find, so they were simply plugged), with sieving on the -a side and a huge skew (in other words with this poly being an general nfs).

L1_BITS 15/16: sure, too. More data is processed in one assembly loop and it's hard to predict what else overflows there; it's a jungle!

BTW, a word of caution: Everyone, run your own copy of the siever once with -v and see if it is L1_BITS=15 or 16 (the latest binaries should self-report). If you have an Intel CPU, you need a L1_BITS=15 binary or you will be sieving slower rather than faster (see a point in case a few messages above).

2010-11-18, 13:10	#15
bsquared "Ben" Feb 2007 2²·3·311 Posts	I'm getting some SCHED_PATHOLOGY messages in the 26M range: Code: SCHED_PATHOLOGY q0=26204357 k=10938 excess=4 Do I just have an old binary, or are other people seeing this too? I don't think I've used this 16e binary before...

2010-11-18, 19:12	#20
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2746₁₆ Posts	When this happens, a special q is skipped, which results in a loss ~20-30 relations. I've got one or two, as well. That's fine; this is a balance between wasting memory and losing 10^-5 - 10^-4 relations. This is poly- and range-specific. On some numbers none of the sched-runaways happen. The schedule allocation boundary is about right, but those of you who can rebuild, do so with SCHED_PAD increased by the excess that you are seeing plus some more pad (e.g. add 12 or 16). In fact, we could collect all failed q0 and run them separately with the generously padded siever on a CPU with large available memory! :-) Last fiddled with by Batalov on 2010-11-18 at 19:25

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
The "Hello - I am... - Nice to meet you" thread....	Prime Monster	Lounge	29	2023-01-02 21:46
Nice progress!	schickel	FactorDB	29	2012-07-18 17:03
Nice pic	Dubslow	Forum Feedback	0	2012-05-02 02:13
Very nice strategical puzzle	Raman	Puzzles	2	2009-11-01 10:23
Nice link...	Xyzzy	Lounge	4	2003-06-28 13:37

2010-11-14, 12:38	#13
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 1100100110110₂ Posts	try http://www.fivemack.org/gnfs-lasieve4I16e But I think your timings are right; I'm getting 1.2s per relation running eight threads on an i7/2666.

2010-11-18, 13:49	#16
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 1936₁₆ Posts	Batalov is the authority on this; I'm not seeing such messages in the 25-26 range, so I suspect you have a slightly older 16e in which the guard band for sched isn't quite wide enough. Do you see the same things with the gnfs-lasieve4I16e linked to earlier in the thread?

2010-11-18, 19:43	#22
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2·11·457 Posts	It definitely has to do the siever being 16e (there are some plugs in the code where infinite loops happened, the reason is hard to find, so they were simply plugged), with sieving on the -a side and a huge skew (in other words with this poly being an general nfs). L1_BITS 15/16: sure, too. More data is processed in one assembly loop and it's hard to predict what else overflows there; it's a jungle! BTW, a word of caution: Everyone, run your own copy of the siever once with -v and see if it is L1_BITS=15 or 16 (the latest binaries should self-report). If you have an Intel CPU, you need a L1_BITS=15 binary or you will be sieving slower rather than faster (see a point in case a few messages above).