Msieve 1.52 feedback - Page 2

chris2be8 · 2014-04-03, 15:32

How much P-1 testing does msieve do when searching for 15-digit factors? And does it do any P+1?

I got the following when running SNFS on a small number from factordb:

Code:

Thu Apr  3 14:36:38 2014 =>nice -n 19  "/home/chris/ggnfs/bin/msieve" -s f2435115607_11-1.dat -l ggnfs.log -i f2435115607_11-1.ini -v -nf f2435115607_11-1.fb -t 1 -nc1
Thu Apr  3 14:36:38 2014
Thu Apr  3 14:36:38 2014
Thu Apr  3 14:36:38 2014  Msieve v. 1.52 (SVN 956)
Thu Apr  3 14:36:38 2014  random seeds: a0be6550 345c4488
Thu Apr  3 14:36:38 2014  factoring 93084562688093517954742403409256178559796836534222796416786876173084023680714803 (80 digits)
Thu Apr  3 14:36:39 2014  searching for 15-digit factors
Thu Apr  3 14:36:39 2014  P-1 stage 2 factor found
Thu Apr  3 14:36:39 2014  prp30 factor: 650986933259644790872951284827
Thu Apr  3 14:36:39 2014  prp51 factor: 142989909523985687742590855223918621743530711847689
Thu Apr  3 14:36:39 2014  elapsed time 00:00:01

The number had had ECM to 25 digits run against it. factMsieve.pl thought that it needed to get more relations because msieve hadn't built a matrix, and carried on sieving for hours until I stopped it. I've written a fix but I'm wondering how much P-1 work msieve did.

Chris

jasonp · 2014-04-04, 00:29

If GMP-ECM is compiled in, the 15-digit level has 30 curves with B1=2000, plus a single P+1 and P-1 run. Because stage 1 for P+-1 has much less arithmetic than stage 1 for ECM, the P-1 run has B1=10*2000 and the P+1 run has B1=5*2000, and these two go first.

debrouxl · 2014-04-09, 05:42

After making some profiling runs and looking at the code, I seem to have made a relatively modest, but seemingly consistently profitable, optimization in relation.c: inlining a relatively costly routine which gets called 4 times by nfs_read_relation(), itself called many times:

Code:

Index: gnfs/relation.c
===================================================================
--- gnfs/relation.c	(révision 961)
+++ gnfs/relation.c	(copie de travail)
@@ -16,7 +16,11 @@
 #include "gnfs.h"
 
 /*--------------------------------------------------------------------*/
-static uint32 divide_factor_out(mpz_t polyval, uint64 p, 
+static inline
+#ifdef __GNUC__
+__attribute__((always_inline))
+#endif
+uint32 divide_factor_out(mpz_t polyval, uint64 p, 
 				uint8 *factors, uint32 *array_size_in,
 				uint32 *num_factors, uint32 compress,
 				mpz_t tmp1, mpz_t tmp2, mpz_t tmp3) {

Benchmarking code:

Code:

#!/bin/sh
for i in `seq 0 5`; do
echo "===== benchmark orig $i =====" >> msieve.log
sync; echo 3 > /proc/sys/vm/drop_caches
~/msieve/msieve_orig -i GC_4_384.ini -s GC_4_384.dat -nf GC_4_384.fb -nc1 target_density=110 -v -t 4
echo "===== benchmark mod $i =====" >> msieve.log
sync; echo 3 > /proc/sys/vm/drop_caches
~/msieve/msieve_mod -i GC_4_384.ini -s GC_4_384.dat -nf GC_4_384.fb -nc1 target_density=110 -v -t 4
done

Elapsed times, grouped by benchmark type, on Core i7-4700HQ @ 2.4 GHz with DDR3 @ 1600 MHz:

Code:

01:01:12 00:59:41 00:59:29 00:59:48 00:59:50 00:59:35
00:58:36 00:58:35 00:57:58 00:59:58 00:58:12 00:58:07

Both lines contain an outlier which raises the average; without it, the time savings seem to be consistently above 1' over 1h, i.e. at least ~1.7%; maybe even 1'30" over 1h, -2.5%.

The terminal / log file output of both versions is obviously the same, but the cycle files are completely different, which is natural, AFAICT.

I remember that the msieve-db branch contains some changes to filtering for not wasting time thoroughly checking every single relation line the very first time, because 90+% of the relations are thrown away ( http://mersenneforum.org/showpost.ph...3&postcount=25 and subsequent posts).
Could a subset of the changes to gnfs/relation.c in the msieve-db branch be backported to the trunk, e.g. through a new argument to nfs_read_relation() and putting one or more code paths under if (<that argument> != 0) ?

Batalov · 2014-05-10, 06:00

It's been a while since I used msieve (and msieve-MPI).
I have on my hands a pretty average snfs diff-254 job (2,2538M c250).

msieve-MPI on 8x4 grid is twice as fast on a 32-core Xeon (~15hrs ETA instead of 30hrs for a density 110 9.2M matrix, built already twice from averagely oversieved, ~224M 31-bit relation set), but on the third independent run it bails with only trivial deps after about ~30% done. The memory is ECC, the bail is reproducible (if you restart from any intermediate .chk file).

/sigh/ Will probably settle for a simple -t32 run; it will take a few hours longer. The version is the r965 snapshot.

jasonp · 2014-05-10, 13:15

Would you be willing to go over this offline? I hesitate to blame the MPI library you're using but fivemack regularly uses the MPI version without incident.

Batalov · 2014-05-10, 20:00

Sure. I will send details to you.

ngoxuanhuy · 2014-05-10, 23:22

Hi every body
I'm newbie, i try to run msieve but have a prolem.
I use msieve_1.52.
I compile : make all
I run : ./msieve -i Worktodo.ini -n ( i want to run nfs).
error:

hashtable: 512 entries, 0.01 MB
factor base: found 160001 rational and 159875 algebraic entries
*** glibc detected *** ./msieve: realloc(): invalid old size: 0x000000000266fbc0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3dd4275366]
/lib64/libc.so.6[0x3dd427ad67]
/lib64/libc.so.6(realloc+0xe5)[0x3dd427af25]
/home/dat/tuan/lib/libgmp.so.10(__gmp_default_reallocate+0x1c)[0x7fec5725d66c]
/home/dat/tuan/lib/libgmp.so.10(__gmpz_realloc+0x3a)[0x7fec57271a3a]
/home/dat/tuan/lib/libgmp.so.10(__gmpz_mul_ui+0xc2)[0x7fec5726ec92]
./msieve[0x415ba2]
./msieve[0x42512a]
./msieve[0x425864]
./msieve[0x4164bb]
./msieve[0x404fd5]
./msieve[0x40344a]
./msieve[0x403c8e]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3dd421ecdd]
./msieve[0x402e69]
======= Memory map: ========
00400000-0046f000 r-xp 00000000 08:02 11013781 /home/dat/huy/msieve-1.52/msieve
0066f000-00670000 rw-p 0006f000 08:02 11013781 /home/dat/huy/msieve-1.52/msieve
0263f000-02722000 rw-p 00000000 00:00 0 [heap]
3dd3a00000-3dd3a20000 r-xp 00000000 08:01 17170867 /lib64/ld-2.12.so
3dd3c1f000-3dd3c20000 r--p 0001f000 08:01 17170867 /lib64/ld-2.12.so
3dd3c20000-3dd3c21000 rw-p 00020000 08:01 17170867 /lib64/ld-2.12.so
3dd3c21000-3dd3c22000 rw-p 00000000 00:00 0
3dd3e00000-3dd3e83000 r-xp 00000000 08:01 17170893 /lib64/libm-2.12.so
3dd3e83000-3dd4082000 ---p 00083000 08:01 17170893 /lib64/libm-2.12.so
3dd4082000-3dd4083000 r--p 00082000 08:01 17170893 /lib64/libm-2.12.so
3dd4083000-3dd4084000 rw-p 00083000 08:01 17170893 /lib64/libm-2.12.so
3dd4200000-3dd4389000 r-xp 00000000 08:01 17170868 /lib64/libc-2.12.so
3dd4389000-3dd4588000 ---p 00189000 08:01 17170868 /lib64/libc-2.12.so
3dd4588000-3dd458c000 r--p 00188000 08:01 17170868 /lib64/libc-2.12.so
3dd458c000-3dd458d000 rw-p 0018c000 08:01 17170868 /lib64/libc-2.12.so
3dd458d000-3dd4592000 rw-p 00000000 00:00 0
3dd4600000-3dd4617000 r-xp 00000000 08:01 17170876 /lib64/libpthread-2.12.so
3dd4617000-3dd4817000 ---p 00017000 08:01 17170876 /lib64/libpthread-2.12.so
3dd4817000-3dd4818000 r--p 00017000 08:01 17170876 /lib64/libpthread-2.12.so
3dd4818000-3dd4819000 rw-p 00018000 08:01 17170876 /lib64/libpthread-2.12.so
3dd4819000-3dd481d000 rw-p 00000000 00:00 0
3dd4a00000-3dd4a02000 r-xp 00000000 08:01 17170870 /lib64/libdl-2.12.so
3dd4a02000-3dd4c02000 ---p 00002000 08:01 17170870 /lib64/libdl-2.12.so
3dd4c02000-3dd4c03000 r--p 00002000 08:01 17170870 /lib64/libdl-2.12.so
3dd4c03000-3dd4c04000 rw-p 00003000 08:01 17170870 /lib64/libdl-2.12.so
3dd4e00000-3dd4e15000 r-xp 00000000 08:01 17170886 /lib64/libz.so.1.2.3
3dd4e15000-3dd5014000 ---p 00015000 08:01 17170886 /lib64/libz.so.1.2.3
3dd5014000-3dd5015000 r--p 00014000 08:01 17170886 /lib64/libz.so.1.2.3
3dd5015000-3dd5016000 rw-p 00015000 08:01 17170886 /lib64/libz.so.1.2.3
3ddfe00000-3ddfe16000 r-xp 00000000 08:01 17170906 /lib64/libgcc_s-4.4.6-20120305.so.1
3ddfe16000-3de0015000 ---p 00016000 08:01 17170906 /lib64/libgcc_s-4.4.6-20120305.so.1
3de0015000-3de0016000 rw-p 00015000 08:01 17170906 /lib64/libgcc_s-4.4.6-20120305.so.1
7fec56a4a000-7fec56ccc000 rw-p 00000000 00:00 0
7fec56f3e000-7fec571bf000 rw-p 00000000 00:00 0
7fec5724d000-7fec57251000 rw-p 00000000 00:00 0
7fec57251000-7fec572c4000 r-xp 00000000 08:02 10885045 /home/dat/tuan/lib/libgmp.so.10.2.0
7fec572c4000-7fec574c3000 ---p 00073000 08:02 10885045 /home/dat/tuan/lib/libgmp.so.10.2.0
7fec574c3000-7fec574c5000 rw-p 00072000 08:02 10885045 /home/dat/tuan/lib/libgmp.so.10.2.0
7fec574c5000-7fec574c6000 rw-p 00000000 00:00 0
7fec574da000-7fec574df000 rw-p 00000000 00:00 0
7fff4e770000-7fff4e785000 rw-p 00000000 00:00 0 [stack]
7fff4e7ff000-7fff4e800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
[dat@gputesla01 msieve-1.52]$

what happen?, please help me! ( sorry about my english)

jasonp · 2014-05-11, 17:02

NFS sieving is broken in the current Msieve, do not try to use it. I haven't tried to find the problem because there is no point in using the NFS sieving included with Msieve; you should be using the GGNFS lattice sieve instead. Many here can help you get started.

wombatman · 2014-05-11, 18:18

Here's a great beginner's guide: http://gilchrist.ca/jeff/factoring/n...ers_guide.html

ngoxuanhuy · 2014-05-12, 04:29

I know , current people use lattice sieve instead and i have read http://gilchrist.ca/jeff/factoring/n...ers_guide.html,
but i want to run old nfs sieve, tell me if have other open source.
(realy, I want to sieve in GPU by cuda instead CPU)
thank for help!!
sorry about my english!!

chris2be8 · 2014-05-13, 16:18

Older versions of msieve could do classical (also called line) sieving. But my experiments showed it was slower than the lattice sieve so I stopped using it years ago.

The old version of msieve bundled with ggnfs might be able to do classical sieving. And the factLat.pl script bundled with ggnfs has an option to do classical sieving by calling a program called sieve. I've never used it but source is provided which might be useful if you want to do sieving on CUDA.

You would probably get better throughput with a lattice sieve on CUDA. Good luck writing it though.

You might be better off trying to get QS to run on CUDA. There was a project to do this mentioned in the factoring tools thread but I don't know if it was finished.

Chris

2014-04-09, 05:42	#14
debrouxl Sep 2009 3D1₁₆ Posts	After making some profiling runs and looking at the code, I seem to have made a relatively modest, but seemingly consistently profitable, optimization in relation.c: inlining a relatively costly routine which gets called 4 times by nfs_read_relation(), itself called many times: Code: Index: gnfs/relation.c =================================================================== --- gnfs/relation.c (révision 961) +++ gnfs/relation.c (copie de travail) @@ -16,7 +16,11 @@ #include "gnfs.h" /--------------------------------------------------------------------/ -static uint32 divide_factor_out(mpz_t polyval, uint64 p, +static inline +#ifdef __GNUC__ +__attribute__((always_inline)) +#endif +uint32 divide_factor_out(mpz_t polyval, uint64 p, uint8 factors, uint32 array_size_in, uint32 *num_factors, uint32 compress, mpz_t tmp1, mpz_t tmp2, mpz_t tmp3) { Benchmarking code: Code: #!/bin/sh for i in `seq 0 5`; do echo "===== benchmark orig $i =====" >> msieve.log sync; echo 3 > /proc/sys/vm/drop_caches ~/msieve/msieve_orig -i GC_4_384.ini -s GC_4_384.dat -nf GC_4_384.fb -nc1 target_density=110 -v -t 4 echo "===== benchmark mod $i =====" >> msieve.log sync; echo 3 > /proc/sys/vm/drop_caches ~/msieve/msieve_mod -i GC_4_384.ini -s GC_4_384.dat -nf GC_4_384.fb -nc1 target_density=110 -v -t 4 done Elapsed times, grouped by benchmark type, on Core i7-4700HQ @ 2.4 GHz with DDR3 @ 1600 MHz: Code: 01:01:12 00:59:41 00:59:29 00:59:48 00:59:50 00:59:35 00:58:36 00:58:35 00:57:58 00:59:58 00:58:12 00:58:07 Both lines contain an outlier which raises the average; without it, the time savings seem to be consistently above 1' over 1h, i.e. at least ~1.7%; maybe even 1'30" over 1h, -2.5%. The terminal / log file output of both versions is obviously the same, but the cycle files are completely different, which is natural, AFAICT. I remember that the msieve-db branch contains some changes to filtering for not wasting time thoroughly checking every single relation line the very first time, because 90+% of the relations are thrown away ( http://mersenneforum.org/showpost.ph...3&postcount=25 and subsequent posts). Could a subset of the changes to gnfs/relation.c in the msieve-db branch be backported to the trunk, e.g. through a new argument to nfs_read_relation() and putting one or more code paths under if (<that argument> != 0) ?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Msieve 1.53 feedback	xilman	Msieve	149	2018-11-12 06:37
Msieve 1.50 feedback	firejuggler	Msieve	99	2013-02-17 11:53
Msieve 1.43 feedback	Jeff Gilchrist	Msieve	47	2009-11-24 15:53
Msieve 1.42 feedback	Andi47	Msieve	167	2009-10-18 19:37
Msieve 1.41 Feedback	Batalov	Msieve	130	2009-06-09 16:01

2014-04-04, 00:29	#13
jasonp Tribal Bullet Oct 2004 3,541 Posts	If GMP-ECM is compiled in, the 15-digit level has 30 curves with B1=2000, plus a single P+1 and P-1 run. Because stage 1 for P+-1 has much less arithmetic than stage 1 for ECM, the P-1 run has B1=102000 and the P+1 run has B1=52000, and these two go first.

2014-05-10, 06:00	#15
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶×13 Posts	It's been a while since I used msieve (and msieve-MPI). I have on my hands a pretty average snfs diff-254 job (2,2538M c250). msieve-MPI on 8x4 grid is twice as fast on a 32-core Xeon (~15hrs ETA instead of 30hrs for a density 110 9.2M matrix, built already twice from averagely oversieved, ~224M 31-bit relation set), but on the third independent run it bails with only trivial deps after about ~30% done. The memory is ECC, the bail is reproducible (if you restart from any intermediate .chk file). /sigh/ Will probably settle for a simple -t32 run; it will take a few hours longer. The version is the r965 snapshot.

2014-05-10, 13:15	#16
jasonp Tribal Bullet Oct 2004 3,541 Posts	Would you be willing to go over this offline? I hesitate to blame the MPI library you're using but fivemack regularly uses the MPI version without incident.

2014-05-10, 20:00	#17
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2505₁₆ Posts	Sure. I will send details to you.

2014-05-10, 23:22	#18
ngoxuanhuy May 2014 3 Posts	Hi every body I'm newbie, i try to run msieve but have a prolem. I use msieve_1.52. I compile : make all I run : ./msieve -i Worktodo.ini -n ( i want to run nfs). error: hashtable: 512 entries, 0.01 MB factor base: found 160001 rational and 159875 algebraic entries * glibc detected * ./msieve: realloc(): invalid old size: 0x000000000266fbc0 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3dd4275366] /lib64/libc.so.6[0x3dd427ad67] /lib64/libc.so.6(realloc+0xe5)[0x3dd427af25] /home/dat/tuan/lib/libgmp.so.10(__gmp_default_reallocate+0x1c)[0x7fec5725d66c] /home/dat/tuan/lib/libgmp.so.10(__gmpz_realloc+0x3a)[0x7fec57271a3a] /home/dat/tuan/lib/libgmp.so.10(__gmpz_mul_ui+0xc2)[0x7fec5726ec92] ./msieve[0x415ba2] ./msieve[0x42512a] ./msieve[0x425864] ./msieve[0x4164bb] ./msieve[0x404fd5] ./msieve[0x40344a] ./msieve[0x403c8e] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3dd421ecdd] ./msieve[0x402e69] ======= Memory map: ======== 00400000-0046f000 r-xp 00000000 08:02 11013781 /home/dat/huy/msieve-1.52/msieve 0066f000-00670000 rw-p 0006f000 08:02 11013781 /home/dat/huy/msieve-1.52/msieve 0263f000-02722000 rw-p 00000000 00:00 0 [heap] 3dd3a00000-3dd3a20000 r-xp 00000000 08:01 17170867 /lib64/ld-2.12.so 3dd3c1f000-3dd3c20000 r--p 0001f000 08:01 17170867 /lib64/ld-2.12.so 3dd3c20000-3dd3c21000 rw-p 00020000 08:01 17170867 /lib64/ld-2.12.so 3dd3c21000-3dd3c22000 rw-p 00000000 00:00 0 3dd3e00000-3dd3e83000 r-xp 00000000 08:01 17170893 /lib64/libm-2.12.so 3dd3e83000-3dd4082000 ---p 00083000 08:01 17170893 /lib64/libm-2.12.so 3dd4082000-3dd4083000 r--p 00082000 08:01 17170893 /lib64/libm-2.12.so 3dd4083000-3dd4084000 rw-p 00083000 08:01 17170893 /lib64/libm-2.12.so 3dd4200000-3dd4389000 r-xp 00000000 08:01 17170868 /lib64/libc-2.12.so 3dd4389000-3dd4588000 ---p 00189000 08:01 17170868 /lib64/libc-2.12.so 3dd4588000-3dd458c000 r--p 00188000 08:01 17170868 /lib64/libc-2.12.so 3dd458c000-3dd458d000 rw-p 0018c000 08:01 17170868 /lib64/libc-2.12.so 3dd458d000-3dd4592000 rw-p 00000000 00:00 0 3dd4600000-3dd4617000 r-xp 00000000 08:01 17170876 /lib64/libpthread-2.12.so 3dd4617000-3dd4817000 ---p 00017000 08:01 17170876 /lib64/libpthread-2.12.so 3dd4817000-3dd4818000 r--p 00017000 08:01 17170876 /lib64/libpthread-2.12.so 3dd4818000-3dd4819000 rw-p 00018000 08:01 17170876 /lib64/libpthread-2.12.so 3dd4819000-3dd481d000 rw-p 00000000 00:00 0 3dd4a00000-3dd4a02000 r-xp 00000000 08:01 17170870 /lib64/libdl-2.12.so 3dd4a02000-3dd4c02000 ---p 00002000 08:01 17170870 /lib64/libdl-2.12.so 3dd4c02000-3dd4c03000 r--p 00002000 08:01 17170870 /lib64/libdl-2.12.so 3dd4c03000-3dd4c04000 rw-p 00003000 08:01 17170870 /lib64/libdl-2.12.so 3dd4e00000-3dd4e15000 r-xp 00000000 08:01 17170886 /lib64/libz.so.1.2.3 3dd4e15000-3dd5014000 ---p 00015000 08:01 17170886 /lib64/libz.so.1.2.3 3dd5014000-3dd5015000 r--p 00014000 08:01 17170886 /lib64/libz.so.1.2.3 3dd5015000-3dd5016000 rw-p 00015000 08:01 17170886 /lib64/libz.so.1.2.3 3ddfe00000-3ddfe16000 r-xp 00000000 08:01 17170906 /lib64/libgcc_s-4.4.6-20120305.so.1 3ddfe16000-3de0015000 ---p 00016000 08:01 17170906 /lib64/libgcc_s-4.4.6-20120305.so.1 3de0015000-3de0016000 rw-p 00015000 08:01 17170906 /lib64/libgcc_s-4.4.6-20120305.so.1 7fec56a4a000-7fec56ccc000 rw-p 00000000 00:00 0 7fec56f3e000-7fec571bf000 rw-p 00000000 00:00 0 7fec5724d000-7fec57251000 rw-p 00000000 00:00 0 7fec57251000-7fec572c4000 r-xp 00000000 08:02 10885045 /home/dat/tuan/lib/libgmp.so.10.2.0 7fec572c4000-7fec574c3000 ---p 00073000 08:02 10885045 /home/dat/tuan/lib/libgmp.so.10.2.0 7fec574c3000-7fec574c5000 rw-p 00072000 08:02 10885045 /home/dat/tuan/lib/libgmp.so.10.2.0 7fec574c5000-7fec574c6000 rw-p 00000000 00:00 0 7fec574da000-7fec574df000 rw-p 00000000 00:00 0 7fff4e770000-7fff4e785000 rw-p 00000000 00:00 0 [stack] 7fff4e7ff000-7fff4e800000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) [dat@gputesla01 msieve-1.52]$ what happen?, please help me! ( sorry about my english)

2014-05-11, 17:02	#19
jasonp Tribal Bullet Oct 2004 3,541 Posts	NFS sieving is broken in the current Msieve, do not try to use it. I haven't tried to find the problem because there is no point in using the NFS sieving included with Msieve; you should be using the GGNFS lattice sieve instead. Many here can help you get started.

2014-05-11, 18:18	#20
wombatman I moo ablest echo power! May 2013 29×61 Posts	Here's a great beginner's guide: http://gilchrist.ca/jeff/factoring/n...ers_guide.html

2014-05-12, 04:29	#21
ngoxuanhuy May 2014 3₈ Posts	I know , current people use lattice sieve instead and i have read http://gilchrist.ca/jeff/factoring/n...ers_guide.html, but i want to run old nfs sieve, tell me if have other open source. (realy, I want to sieve in GPU by cuda instead CPU) thank for help!! sorry about my english!!

2014-05-13, 16:18	#22
chris2be8 Sep 2009 2078₁₀ Posts	Older versions of msieve could do classical (also called line) sieving. But my experiments showed it was slower than the lattice sieve so I stopped using it years ago. The old version of msieve bundled with ggnfs might be able to do classical sieving. And the factLat.pl script bundled with ggnfs has an option to do classical sieving by calling a program called sieve. I've never used it but source is provided which might be useful if you want to do sieving on CUDA. You would probably get better throughput with a lattice sieve on CUDA. Good luck writing it though. You might be better off trying to get QS to run on CUDA. There was a project to do this mentioned in the factoring tools thread but I don't know if it was finished. Chris