Reservations

[ET_]

Originally Posted by rogue

I'll look into that.

In your table you have a number of rows where "to n" < "from n". What does that mean? I would expect "to n" to always be larger than "from n".

They are the small N who had ECM.
There are only a few Ns (from 12 to 30) where ECM is better suited than other factorization methods: for those Ns instead of the columns
"From N, To N, From k, To k"
I redefine the heading
"N, # of curves, B1 bound, B2 bound"

For such small Ns I strongly require ECM, so you can safely avoid them.

[rogue]

Originally Posted by ET_

They are the small N who had ECM.
There are only a few Ns (from 12 to 30) where ECM is better suited than other factorization methods: for those Ns instead of the columns
"From N, To N, From k, To k"
I redefine the heading
"N, # of curves, B1 bound, B2 bound"

For such small Ns I strongly require ECM, so you can safely avoid them.

I forgot about that. My code ignores ranges done with ECM. Maybe ECM testing should be in a separate table so you can name the columns properly.

[ET_]

Originally Posted by rogue

I forgot about that. My code ignores ranges done with ECM. Maybe ECM testing should be in a separate table so you can name the columns properly.

Sure, but I was lazy at that time, and George gathers Fermat ECM results far better than me.

[rogue]

I cannot run ppsieve_cuda. If anyone would like to sieve (to the appropriate depth) any of these ranges, I can do the PRP testing. My cores will start freeing up by the end of August, so that should give anyone who wants to sieve plenty of time.

6201-6299     800000000 900000000
10003-10999   50000000 269000000
14501-14999   30000000 70000000
80001-80999   90000 100000
114000-119999 40000 99999
120001-129999 30000 40000
130001-139999 20000 30000
160001-169999 15000 20000
181744-189999 13000 30000

[wombatman]

What are the appropriate depths? I don't want to reserve any of these yet since I don't know what kind of speed I can manage, but I'll take a whack at it.

Edit: Also, is this list k range followed by needed N-range, or the opposite?

[rogue]

Originally Posted by wombatman

What are the appropriate depths? I don't want to reserve any of these yet since I don't know what kind of speed I can manage, but I'll take a whack at it.

I do not know. I target a removal rate, i.e. 1 per xx seconds. For a range do a PRP test with pfgw for a number with an n about 2/3s into the range. In other words, if min n = 10000 and max n = 40000, PRP test for any k for n = 30000. The removal rate that you target should be similar to the time to do a single PRP test.

The first two values are min n and max n. The last two are min k and max k.

[wombatman]

Sounds good. I'll trial-run a few and see how it goes before reserving any ranges.

[wombatman]

So I've got it running on a GTX 750 Ti, but it's only producing a GPU load of ~3-5%, and the predicted end date for 6201-6299 8e8 9e8 is around November.

What options can I change to increase this load so as to speed things up?

[ET_]

Originally Posted by wombatman

So I've got it running on a GTX 750 Ti, but it's only producing a GPU load of ~3-5%, and the predicted end date for 6201-6299 8e8 9e8 is around November.

What options can I change to increase this load so as to speed things up?

If the program spits out a lot of results, try to redirect the output to /dev/null for the first iterations.

[wombatman]

Originally Posted by ET_

If the program spits out a lot of results, try to redirect the output to /dev/null for the first iterations.

That bumped it a little, but I'm still primarily around 3-5% load.

[ET_]

Originally Posted by wombatman

That bumped it a little, but I'm still primarily around 3-5% load.

I suppose it's partly because the program is more busy writing factors on a file than sieving. It happens on most sievers. The efficiency should progress as long as p grows and less factors are found.