64-bit gnfs-lasieve* - Page 5

Batalov · 2010-02-16, 19:19

Was it a Windows port? Neat!

Don't worry about the polySelTimeMultiplier in the context of the old script; the perl script has not been updated in ages; it may need to be re-written (by someone who has time) to use msieve for much better/faster polyselecting (it will become much shorter, too). However, instead you will do better by using the new python script. (I have to confess that I use neither.)

Joshua2 · 2010-02-17, 04:04

can u post a binary once you get one faster than Jeff's win64 binary?

chris2be8 · 2010-02-17, 15:26

Quote:

Originally Posted by Batalov

Was it a Windows port? Neat!

No, Linux.It works on my laptop but not on my desktop.I'm not sure if it's the OS or the CPU that stop it running on my desktop.

The laptop runs Red Hat 2.6.18-128.el5 on the following CPU:
Genuine Intel(R) CPU T1600 @ 1.66GHz stepping 0d

The desktop runs SuSE 2.6.22.5-31-default on:
Intel(R) Pentium(R) 4 CPU 3.06GHz stepping 09

The siever terminates with RC 8 on my desktop after generating the afb files. Does anyone know if it should work on this CPU (ie I have a compiler problem) or not (ie the compiler is innocent)?

Pointers to Linux programs to get hardware info would also be welcome.

Chris K

debrouxl · 2010-02-17, 16:29

Only to name a few: hwinfo, lshw, lspci, lsusb.
For processor information, `cat /proc/cpuinfo`, x86info.

They're not necessarily available out of the box, you may have to install some of them from your distributions' package repositories

frmky · 2010-02-17, 17:27

Quote:

Originally Posted by chris2be8

The desktop runs SuSE 2.6.22.5-31-default on:
Intel(R) Pentium(R) 4 CPU 3.06GHz stepping 09

The siever terminates with RC 8 on my desktop after generating the afb files. Does anyone know if it should work on this CPU (ie I have a compiler problem) or not (ie the compiler is innocent)?

Perhaps not. The asm uses the prefetchw instruction. That's actually an AMD instruction. When Intel adopted AMD64 they just couldn't bring themselves to fully copy what AMD had done for their x86_64, so they left out a few instructions and added a few new ones in their version. After sufficient complaints, probably from Microsoft as they use prefetchw instruction in their kernel and had to implement a workaround for Intel, Intel added the instruction but, at least initially and perhaps still today, made it a NOP. Anyway, I believe it only affects the 64-bit capable single and dual core 90nm Pentium 4's and Xeon Nocona and Irwindale. Is your P4 a 90nm part?

chris2be8 · 2010-02-18, 12:37

Quote:

Originally Posted by frmky

Is your P4 a 90nm part?

How do I check? I'm at work now, I'll check when I get home if someone says what to check.

A related question, how do I check what sort of GPU is in a box? Especially useful for second hand systems that didn't come with any documentation.

Chris K

fivemack · 2010-02-18, 13:19

To identify GPUs, I would tend to boot to a command line ('rescue prompt' or similar) from a recent Linux boot disc and do 'lspci | grep VGA' (you may need to do /sbin/lspci, but mostly it'll be on the path - you get lines like

Code:

00:06.0 VGA compatible controller: XGI - Xabre Graphics Inc Volari Z7
05:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] (rev a1)
01:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 LE] (rev a1)
05:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 TurboCache] (rev a1)
01:00.0 VGA compatible controller: nVidia Corporation G94 [GeForce 9600 GT] (rev a1)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 9800 GT (rev a2)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)

It needs to be a Linux boot disc from a distribution release newer than the GPU, otherwise you get just a PCI ID, but that's not a problem for most second-hand boxes.

chris2be8 · 2010-02-18, 16:54

After google-ing prefetchw it looks as if my desktop's CPU doesn't support it. And neither has a programmable GPU so I can't use GPU code unless I buy one. But at least I know why, so thanks for the help.

And I can entertain myself trying out all the hardware scanning tools. hwinfo produces enough to study for a few hours.

Chris K

chris2be8 · 2010-05-15, 07:40

It turns out it doesn't support the prefetch instruction either. Once I'd commented out the prefetch and prefetchw instructions and recompiled the sieve generates relations instead of core dumps. But I need to run some more tests before I trust it.

I'll post some benchmarks once I've been able to generate them (after the next break in sieving 2801^79-1).

Chris K

chris2be8 · 2010-05-15, 18:40

An afterthought, would I be better off replacing prefetch with prefetcht0 instead of deleting it? I could try it both ways and see which is faster but would I be wasting my time?

Chris K

Prime95 · 2010-05-15, 19:33

In general, for data you are about to use very soon, use prefetcht0 on Intel chips (there is no difference between t0, t1, and t2 with current chips). For AMD use prefetch if the data is read-only, use prefetchw for read-write data.

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

2010-02-16, 19:19	#45
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 9477₁₀ Posts	Was it a Windows port? Neat! Don't worry about the polySelTimeMultiplier in the context of the old script; the perl script has not been updated in ages; it may need to be re-written (by someone who has time) to use msieve for much better/faster polyselecting (it will become much shorter, too). However, instead you will do better by using the new python script. (I have to confess that I use neither.)

2010-02-17, 04:04	#46
Joshua2 Sep 2004 215₁₆ Posts	can u post a binary once you get one faster than Jeff's win64 binary?

2010-02-17, 16:29	#48
debrouxl Sep 2009 3D1₁₆ Posts	Only to name a few: hwinfo, lshw, lspci, lsusb. For processor information, `cat /proc/cpuinfo`, x86info. They're not necessarily available out of the box, you may have to install some of them from your distributions' package repositories

2010-02-18, 16:54	#52
chris2be8 Sep 2009 2×1,039 Posts	After google-ing prefetchw it looks as if my desktop's CPU doesn't support it. And neither has a programmable GPU so I can't use GPU code unless I buy one. But at least I know why, so thanks for the help. And I can entertain myself trying out all the hardware scanning tools. hwinfo produces enough to study for a few hours. Chris K

2010-05-15, 07:40	#53
chris2be8 Sep 2009 2·1,039 Posts	It turns out it doesn't support the prefetch instruction either. Once I'd commented out the prefetch and prefetchw instructions and recompiled the sieve generates relations instead of core dumps. But I need to run some more tests before I trust it. I'll post some benchmarks once I've been able to generate them (after the next break in sieving 2801^79-1). Chris K

2010-05-15, 18:40	#54
chris2be8 Sep 2009 2·1,039 Posts	An afterthought, would I be better off replacing prefetch with prefetcht0 instead of deleting it? I could try it both ways and see which is faster but would I be wasting my time? Chris K

2010-05-15, 19:33	#55
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 2×53×71 Posts	In general, for data you are about to use very soon, use prefetcht0 on Intel chips (there is no difference between t0, t1, and t2 with current chips). For AMD use prefetch if the data is read-only, use prefetchw for read-write data.