64-bit gnfs-lasieve* - Page 3

FactorEyes · 2009-04-12, 00:41

Quote:

Originally Posted by Batalov

Need more tests from you guys. Sieve any project as usual and please report any cases of the message
SCHED_PATHOLOGY k=... excess=...

Will do. I have three fat GNFS jobs stacked up, to be followed by a Cunningham.

On a server motherboard I'm running, with two quad-core Barcelonas, there have been weird crashes, with just one client of 8 going down now and then. Strangely, I rarely get badsched reports on this machine, but it's the only place I have seen the lattice sievers crash. It has a strange memory architecture, so this may be the culprit.

<WAAAH!>
BTW, who built these 64-bit asm binaries? I still can't figure out how to build them from source, what with that weird Tex tool that is used to build the asm modules.
</WAAH!>

Is the 64-bit build any closer to getting into the subversion tree?

jasonp · 2009-04-12, 01:58

I hate that tool. 'That's fatal, son' indeed. Now Foghorn Leghorn ('Ah say thassa joke, son') is preventing stuff from compiling.

joral · 2009-04-12, 02:39

Quote:

Originally Posted by FactorEyes

Is the 64-bit build any closer to getting into the subversion tree?

Closer, perhaps, but not entirely close yet. Still hunting some weird bug in the lasched code. always segfaults second time through.

On a side note, I do have a change to provide, in that on FreeBSD systems, a needed include file isn't included in the build. Once I get this done as well, how would I actually get it into the SVN tree?

Jeff Gilchrist · 2009-04-12, 10:08

Quote:

Originally Posted by joral

On a side note, I do have a change to provide, in that on FreeBSD systems, a needed include file isn't included in the build. Once I get this done as well, how would I actually get it into the SVN tree?

If you don't have SVN access you have to ask someone who does, like Serge or myself.

Batalov · 2009-04-12, 19:14

joral: Please do not hesitate to contact Anton (or Chris) - via sourceforge's contacts. They will add you easily.
The website there is a bit confusing, but do
http://sourceforge.net/projects/ggnfs/ and then click on "Details" tab. =>
Project Admins : asl__, cmonico

FactorEyes: I hope you will be using 15e! For all the smaller sievers, I've reverted the patch - there are no appreciable memory savings for them _and_ surely, there are new bugs (the memory boundary is tight). No pathologies so far in 15e, but I am sure there will be. But they hopefully will show us how much memory we can save - your price to pay is just losing a few relations (your jobs will not fail, they will only barf to stderr every once in a while). Could you please modify your launch/qsub scripts to save stderr's (if you use qsub, then that's easy). thx!

Batalov · 2009-04-15, 18:40

The optimized binaries for Opteron/Phenom linux 64-bit are here (from 11e to 16e).
Please let me know if you will have any problems with these.

Code:

  991136  Defl:X   440626  56%  04-15-09 01:38  987b0c09  gnfs-lasieve4I11e
  974752  Defl:X   440447  55%  04-15-09 01:34  aab801c9  gnfs-lasieve4I12e
  970656  Defl:X   440422  55%  04-15-09 01:34  f2876606  gnfs-lasieve4I13e
  966560  Defl:X   440388  54%  04-15-09 01:34  199f7df7  gnfs-lasieve4I14e
  958368  Defl:X   437541  54%  04-15-09 01:34  a8db9e10  gnfs-lasieve4I15e
  958368  Defl:X   437439  54%  04-15-09 01:34  7c210536  gnfs-lasieve4I16e

Batalov · 2009-04-15, 21:57

Here's a small helper/QC script to compare relation outputs from different sievers:

Code:

#!/usr/bin/perl -w
while(<>) {
  s/\s+$//;
  my @t = split ":";
  for($j=1;$j<=2;$j++) {
      $t[$j]=lc(join(",",
                sort {hex($b)<=>hex($a)}
                grep {hex($_)>1000} split(",", $t[$j])));
  }
  print join(":", @t), "\n";
}
1;

(The GGNFS code reports all small factors, other sievers don't; msieve or procrels in fact don't need those, they easily recover them.)

Using this script (and then sort, diff or emacs or similar), it is easy to check that GGNFS SVN siever occasionally underreports one or two relations (this is a known bug), the new sievers report all, and that all larger sievers produce more and more relations and never miss anything that the smaller sievers find (that's just QC, that's normal).

FactorEyes · 2009-04-19, 22:15

Quote:

Originally Posted by Batalov

The optimized binaries for Opteron/Phenom linux 64-bit are here (from 11e to 16e).
Please let me know if you will have any problems with these.

Just built 'em, with your guidance.

I'm seeing slightly faster rels/sec with the new ones, e.g. .072 vs .075 with the older 64-bit binaries. Have there been improvements, or am I just imagining them?

Batalov · 2009-04-20, 04:07

Most likely just slight variations. In my hands, in reasonably long ranges they went on the nose - but my have small patches.

One possible benefit is that 15e (and 16e) by having lesser memory footprint, may spend less time waiting for memory latency. Maybe?

henryzz · 2009-05-28, 19:24

has someone built 64-bit linux binaries optimized for core 2?
i will use the opteron/phenom optimized ones until i find them

Batalov · 2009-05-28, 23:20

According to Greg (and me, I guess, from limited experience) - there should be hardly any difference. (Optimization of the C glue code is not significant, but the assembly code is common.)

These binaries run great on Core2 (I've run them myself, too - under ubuntu and the speed was great; but most of the time my that computer is in Windows mode for the kid's homework use) and on K8/K10 alike.

2009-04-12, 01:58	#24
jasonp Tribal Bullet Oct 2004 3,541 Posts	I hate that tool. 'That's fatal, son' indeed. Now Foghorn Leghorn ('Ah say thassa joke, son') is preventing stuff from compiling. Last fiddled with by jasonp on 2009-04-12 at 01:59

2009-04-12, 19:14	#27
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	joral: Please do not hesitate to contact Anton (or Chris) - via sourceforge's contacts. They will add you easily. The website there is a bit confusing, but do http://sourceforge.net/projects/ggnfs/ and then click on "Details" tab. => Project Admins : asl__, cmonico FactorEyes: I hope you will be using 15e! For all the smaller sievers, I've reverted the patch - there are no appreciable memory savings for them _and_ surely, there are new bugs (the memory boundary is tight). No pathologies so far in 15e, but I am sure there will be. But they hopefully will show us how much memory we can save - your price to pay is just losing a few relations (your jobs will not fail, they will only barf to stderr every once in a while). Could you please modify your launch/qsub scripts to save stderr's (if you use qsub, then that's easy). thx! Last fiddled with by Batalov on 2009-04-12 at 20:07 Reason: (fixed sourceforge links, they were local urls)

2009-04-15, 21:57	#29
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	unifyRels.pl Here's a small helper/QC script to compare relation outputs from different sievers: Code: #!/usr/bin/perl -w while(<>) { s/\s+$//; my @t = split ":"; for($j=1;$j<=2;$j++) { $t[$j]=lc(join(",", sort {hex($b)<=>hex($a)} grep {hex($_)>1000} split(",", $t[$j]))); } print join(":", @t), "\n"; } 1; (The GGNFS code reports all small factors, other sievers don't; msieve or procrels in fact don't need those, they easily recover them.) Using this script (and then sort, diff or emacs or similar), it is easy to check that GGNFS SVN siever occasionally underreports one or two relations (this is a known bug), the new sievers report all, and that all larger sievers produce more and more relations and never miss anything that the smaller sievers find (that's just QC, that's normal).

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
3,697+ (GNFS 220.9)	pinhodecarlos	NFS@Home	0	2014-12-24 19:13
3,766+ (GNFS 215.5)	pinhodecarlos	NFS@Home	34	2014-04-01 21:27
Nonstandard lasieve binaries	fivemack	Factoring	8	2010-04-27 18:59
Bug in 64-bit lasieve	Shaopu Lin	Factoring	3	2009-11-18 18:42
c97 GNFS not possible?	Andi47	Msieve	5	2009-01-26 18:19

2009-04-20, 04:07	#31
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 10010100000101₂ Posts	Most likely just slight variations. In my hands, in reasonably long ranges they went on the nose - but my have small patches. One possible benefit is that 15e (and 16e) by having lesser memory footprint, may spend less time waiting for memory latency. Maybe?

2009-05-28, 19:24	#32
henryzz Just call me Henry "David" Sep 2007 Cambridge (GMT/BST) 2³×3×5×7² Posts	has someone built 64-bit linux binaries optimized for core 2? i will use the opteron/phenom optimized ones until i find them

2009-05-28, 23:20	#33
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	According to Greg (and me, I guess, from limited experience) - there should be hardly any difference. (Optimization of the C glue code is not significant, but the assembly code is common.) These binaries run great on Core2 (I've run them myself, too - under ubuntu and the speed was great; but most of the time my that computer is in Windows mode for the kid's homework use) and on K8/K10 alike.