GPU polynomial selection, extreme edition - Page 4

debrouxl · 2012-09-09, 16:27

firejuggler: I can try that on the GT540M after restarting my graphical environment / rebooting my computer (because of the NVidia driver upgrade).

jasonp: for me, compiling msieve_faststage1 SVN r780 (current HEAD) requires replacing several occurrences of "__min" and "__max" by "min" and "max".
Debian unstable x86_64, driver 304.43. It wasn't necessary at the end of August, when I posted #4

chris2be8 · 2012-09-12, 16:29

Hello,

My next GNFS target from the Brent tables is:
n: 837206302064042535029712677077925895086708039920347288982178593096750304884924467240109093786980459248115989485695562104331771131673481571349793681

It's from 38^154+1. If anyone wants to see how good a poly they can generate and post it here I will gratefully use it.

Chris

debrouxl · 2012-09-14, 15:32

So... after firejuggler's suggestion, I have run a bit of polynomial selection on 2^877-1, with b40c+msieve_faststage1 SVN HEAD (r781).

32 minutes of msieve -np1 -nps produced 6583 polynomials, 6340 unique, and then, it errored out for some reason (might be due to driver 304.48, heat, or anything else).
Only two size-optimized hits with norm below 1e+24, the lowest norm was

Code:

120 -4902983304162 -28517866198276121429899 6610386931174804726509227 16397528100258430945544836392537201 -1120351763834396894251104228996940754 1126074124132552507 -115125475798355675406609579665783019 -1.53 4.577860e+23

From that hit, the best polynomial produced by msieve -npr was

Code:

polynomial selection complete
R0: -115125477592169297853508147822135918
R1: 1126074124132552507
A0: -55845232727142356092307092406094145981848585928365
A1: 7488993202621425380940297949390750287507
A2: 56783959033906078428543335238383
A3: 5768654849459670857837
A4: -5858771338362
A5: 120
skew 3425589127.74, size 2.038e-17, alpha -9.492, combined = 1.055e-13 rroots = 5

As in my previous runs, the polynomial produced by msieve in a low amount of CPU/GPU/wall clock time beat the best polynomial generated by pol5sel ( http://mersenneforum.org/showpost.ph...7&postcount=46 ), and the sheer number of stage 1 hits is high even on that modest GPU - most stage 1 hits do not contribute to the final result.

I'm now running chris2be8's smaller number for several hours, and msieve is producing an even larger number of hits...
I have cut activity on the CPUs, I'll see whether this run errors out as well.

fivemack · 2012-09-14, 20:27

I summoned an Amazon Compute GPU instance from the cloud (an hour on a machine with two S2050 Fermi cards for 75 cents seemed a decent deal) to have a play with this, but unfortunately I get the message

Code:

/usr/bin/ld: /tmp/tmpxft_0000126c_00000000-13_sort_engine.o: relocation R_X86_64_32 against `.nvFatBinSegment' can not be used when making a shared object; recompile with -fPIC

when I try to build b40c. What am I doing wrong?

Also, the makefile instructions say to use NVCCFLAGS="-arch sm_20", but the makefile adds -arch sm_11 to the command line and you can't have both.

Also also I had to replace __min with min in a couple of places

And finally when I got it built I found that 'msieve -g 0 -np1 -nps' just said

'error (line 66): CUDA_ERROR_NO_DEVICE'

I will happily pay 75 cents in usage charge to someone who understands Amazon cluster GPU instances enough to tell me what trivial mistakes I'm making.

Dubslow · 2012-09-14, 20:35

Maybe try without the -g?

jasonp · 2012-09-15, 00:23

Did you uncomment the linux lines in the b40c makefile? nvcc should be passing '-fPIC' to the compiler (I'm testing all this in windows)

The sm_20 instructions in the msieve makefile should work if you remove the '-arch sm_11' line from the msieve makefile; it used to be required because manually changing the arch to sm_20 would make nvcc hang forever.

debrouxl · 2012-09-15, 06:39

chris2be8: polynomial selection ran for 15 minutes before erroring out, which is highly insufficient. It's probably not due to overheating, as the CPUs were near 0% usage.
The best polynomial produced from size-optimized hits with norm 1.18e+19 to 2.37e+19 was

Code:

R0: -31846009911460450739394854604
R1: 17281174816407857
A0: -39758636173134780674886575799919471295
A1: 104464031621249588054025963084444
A2: 24038399162484121573625009
A3: -3907361624631619974
A4: -378547527444
A5: 25560
skew 7620423.74, size 2.378e-14, alpha -7.398, combined = 6.963e-12 rroots = 5

but it probably doesn't mean much.

To which SVN revisions should I be going back, if I want to try and figure out whether it's a driver problem or a msieve problem ? r778, before the initialization changes ?

debrouxl · 2012-09-15, 13:02

I reverted to r778 this morning, recompiled, and polynomial selection has been working for several hours without erroring out.

fivemack · 2012-09-15, 13:30

OK, that's working now on the Amazon machines (using http://msieve.svn.sourceforge.net/vi...age1/?view=tar as of 1100Z today), though they're a little flaky; each machine has two GPUs, and there were times at which -g 1 hung quickly and -g 0 ran fine with the same parameters. And sometimes a job runs for a while, then hangs, and hangs immediately when restarted; after a little while it gets better.

Parameter optimisation: on the Amazon machines (M2050 ~= GeForce 470), on a log(N)=158.73, stage1 norm of 3.8e22 gives about one hit per second. On a log(N)=152.62, stage1 norm of 5e21 gives about one hit per second.
On a log(N)=139.28, stage1 norm of 7e19 is about one hit per second but a ten-minute run terminated with 'polynomial selection complete' at 3:58 A5=116388.

A supposedly two-hour run on the 158.73 at msieve -g 1 -np1 "min_coeff=10000 stage1_norm=3.1e22" -nps -v said 'polynomial selection complete' after 11m58s with A5=372504 or so, and not because it had run into the upper bound for A5.

The terminations are repeatable, and are not a function of coefficient (running 139.28 with min_coeff=115000 terminates in 3:58 at A5=303108, running 158.73 with min_coeff=372000 terminates in 11:10 at A5=1129968 ); is the deadline maybe not being reset with each new coefficient?

jasonp · 2012-09-15, 21:47

Yes, the elapsed GPU time for each coefficient was not getting reset when the coefficient started; SVN784 should fix it.

debrouxl · 2012-09-16, 11:39

In nearly 25h of wall clock time, msieve -np1 -nps (SVN r778) on GT540M produced 393982 size-optimized stage 1 hits, 383398 unique, for M877.

No norm below 1e23, and only 283 hits (270 unique, less than 1 in one thousand !) have norm between 1e23 and 1e24.
The best polynomial produced by ~2h of msieve -npr on these 283 hits with norm < 1e24 is

Code:

R0: -59163051407468196687671696332175985
R1: 1731468673276545767
A0: -2204405661684738716055336590140780786304341408
A1: -84181572470021025522929485281379380820
A2: 607904864396395090996918585606
A3: 2440787429966455185322
A4: -3232339486443
A5: 3348
skew 320523711.21, size 2.042e-17, alpha -7.265, combined = 1.078e-13 rroots = 3

which slightly beats what I posted above, which itself beat the result of pol5sel.

I'll switch to SVN r784 for other tests.

2012-09-09, 16:27	#34
debrouxl Sep 2009 977 Posts	firejuggler: I can try that on the GT540M after restarting my graphical environment / rebooting my computer (because of the NVidia driver upgrade). jasonp: for me, compiling msieve_faststage1 SVN r780 (current HEAD) requires replacing several occurrences of "__min" and "__max" by "min" and "max". Debian unstable x86_64, driver 304.43. It wasn't necessary at the end of August, when I posted #4 Last fiddled with by debrouxl on 2012-09-09 at 16:29

2012-09-14, 15:32	#36
debrouxl Sep 2009 977 Posts	So... after firejuggler's suggestion, I have run a bit of polynomial selection on 2^877-1, with b40c+msieve_faststage1 SVN HEAD (r781). 32 minutes of msieve -np1 -nps produced 6583 polynomials, 6340 unique, and then, it errored out for some reason (might be due to driver 304.48, heat, or anything else). Only two size-optimized hits with norm below 1e+24, the lowest norm was Code: 120 -4902983304162 -28517866198276121429899 6610386931174804726509227 16397528100258430945544836392537201 -1120351763834396894251104228996940754 1126074124132552507 -115125475798355675406609579665783019 -1.53 4.577860e+23 From that hit, the best polynomial produced by msieve -npr was Code: polynomial selection complete R0: -115125477592169297853508147822135918 R1: 1126074124132552507 A0: -55845232727142356092307092406094145981848585928365 A1: 7488993202621425380940297949390750287507 A2: 56783959033906078428543335238383 A3: 5768654849459670857837 A4: -5858771338362 A5: 120 skew 3425589127.74, size 2.038e-17, alpha -9.492, combined = 1.055e-13 rroots = 5 As in my previous runs, the polynomial produced by msieve in a low amount of CPU/GPU/wall clock time beat the best polynomial generated by pol5sel ( http://mersenneforum.org/showpost.ph...7&postcount=46 ), and the sheer number of stage 1 hits is high even on that modest GPU - most stage 1 hits do not contribute to the final result. I'm now running chris2be8's smaller number for several hours, and msieve is producing an even larger number of hits... I have cut activity on the CPUs, I'll see whether this run errors out as well.

2012-09-14, 20:27	#37
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 7²·131 Posts	I summoned an Amazon Compute GPU instance from the cloud (an hour on a machine with two S2050 Fermi cards for 75 cents seemed a decent deal) to have a play with this, but unfortunately I get the message Code: /usr/bin/ld: /tmp/tmpxft_0000126c_00000000-13_sort_engine.o: relocation R_X86_64_32 against `.nvFatBinSegment' can not be used when making a shared object; recompile with -fPIC when I try to build b40c. What am I doing wrong? Also, the makefile instructions say to use NVCCFLAGS="-arch sm_20", but the makefile adds -arch sm_11 to the command line and you can't have both. Also also I had to replace __min with min in a couple of places And finally when I got it built I found that 'msieve -g 0 -np1 -nps' just said 'error (line 66): CUDA_ERROR_NO_DEVICE' I will happily pay 75 cents in usage charge to someone who understands Amazon cluster GPU instances enough to tell me what trivial mistakes I'm making. Last fiddled with by fivemack on 2012-09-14 at 20:35

2012-09-15, 06:39	#40
debrouxl Sep 2009 977 Posts	chris2be8: polynomial selection ran for 15 minutes before erroring out, which is highly insufficient. It's probably not due to overheating, as the CPUs were near 0% usage. The best polynomial produced from size-optimized hits with norm 1.18e+19 to 2.37e+19 was Code: R0: -31846009911460450739394854604 R1: 17281174816407857 A0: -39758636173134780674886575799919471295 A1: 104464031621249588054025963084444 A2: 24038399162484121573625009 A3: -3907361624631619974 A4: -378547527444 A5: 25560 skew 7620423.74, size 2.378e-14, alpha -7.398, combined = 6.963e-12 rroots = 5 but it probably doesn't mean much. To which SVN revisions should I be going back, if I want to try and figure out whether it's a driver problem or a msieve problem ? r778, before the initialization changes ?

2012-09-16, 11:39	#44
debrouxl Sep 2009 977₁₀ Posts	In nearly 25h of wall clock time, msieve -np1 -nps (SVN r778) on GT540M produced 393982 size-optimized stage 1 hits, 383398 unique, for M877. No norm below 1e23, and only 283 hits (270 unique, less than 1 in one thousand !) have norm between 1e23 and 1e24. The best polynomial produced by ~2h of msieve -npr on these 283 hits with norm < 1e24 is Code: R0: -59163051407468196687671696332175985 R1: 1731468673276545767 A0: -2204405661684738716055336590140780786304341408 A1: -84181572470021025522929485281379380820 A2: 607904864396395090996918585606 A3: 2440787429966455185322 A4: -3232339486443 A5: 3348 skew 320523711.21, size 2.042e-17, alpha -7.265, combined = 1.078e-13 rroots = 3 which slightly beats what I posted above, which itself beat the result of pol5sel. I'll switch to SVN r784 for other tests.

2012-09-12, 16:29	#35
chris2be8 Sep 2009 2078₁₀ Posts	Hello, My next GNFS target from the Brent tables is: n: 837206302064042535029712677077925895086708039920347288982178593096750304884924467240109093786980459248115989485695562104331771131673481571349793681 It's from 38^154+1. If anyone wants to see how good a poly they can generate and post it here I will gratefully use it. Chris

2012-09-14, 20:35	#38
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3×29×83 Posts	Maybe try without the -g?

2012-09-15, 00:23	#39
jasonp Tribal Bullet Oct 2004 3,541 Posts	Did you uncomment the linux lines in the b40c makefile? nvcc should be passing '-fPIC' to the compiler (I'm testing all this in windows) The sm_20 instructions in the msieve makefile should work if you remove the '-arch sm_11' line from the msieve makefile; it used to be required because manually changing the arch to sm_20 would make nvcc hang forever.

2012-09-15, 13:02	#41
debrouxl Sep 2009 977 Posts	I reverted to r778 this morning, recompiled, and polynomial selection has been working for several hours without erroring out.

2012-09-15, 13:30	#42
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 7²×131 Posts	OK, that's working now on the Amazon machines (using http://msieve.svn.sourceforge.net/vi...age1/?view=tar as of 1100Z today), though they're a little flaky; each machine has two GPUs, and there were times at which -g 1 hung quickly and -g 0 ran fine with the same parameters. And sometimes a job runs for a while, then hangs, and hangs immediately when restarted; after a little while it gets better. Parameter optimisation: on the Amazon machines (M2050 ~= GeForce 470), on a log(N)=158.73, stage1 norm of 3.8e22 gives about one hit per second. On a log(N)=152.62, stage1 norm of 5e21 gives about one hit per second. On a log(N)=139.28, stage1 norm of 7e19 is about one hit per second but a ten-minute run terminated with 'polynomial selection complete' at 3:58 A5=116388. A supposedly two-hour run on the 158.73 at msieve -g 1 -np1 "min_coeff=10000 stage1_norm=3.1e22" -nps -v said 'polynomial selection complete' after 11m58s with A5=372504 or so, and not because it had run into the upper bound for A5. The terminations are repeatable, and are not a function of coefficient (running 139.28 with min_coeff=115000 terminates in 3:58 at A5=303108, running 158.73 with min_coeff=372000 terminates in 11:10 at A5=1129968 ); is the deadline maybe not being reset with each new coefficient?

2012-09-15, 21:47	#43
jasonp Tribal Bullet Oct 2004 3,541 Posts	Yes, the elapsed GPU time for each coefficient was not getting reset when the coefficient started; SVN784 should fix it.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
2^877-1 polynomial selection	fivemack	Factoring	47	2009-06-16 00:24
Polynomial selection	CRGreathouse	Factoring	2	2009-05-25 07:55
Intel Core i7 Extreme Edition Q965 on the X58 MOBO	IronBits	Hardware	17	2008-11-13 18:07
Vista 64 Ultimate Extreme Remix Limited Edition	Timber Jockey	PrimeNet	4	2008-10-20 19:39
Northwood, Prescott Or Extreme Edition?	georgekh	Hardware	13	2005-03-17 06:31