Feature request: multithreaded polsel

[Andi47]

OK, we all know, that we also can do a polsel on t threads manually (or maybe with a script?):

1.) start msieve -np -v to find out the time limit and the search range
2.) kill the job immediately and delete the outputfiles (to avoid that msieve stops the run after 1 second in step 4 and outputs the first (possibly very sub-optimal) poly from step 1.)
3.) divide the search range in t subranges
4.) run the jobs in t different directories on t threads
5.) kill the jobs after (time-limit/t) hours
6.) gather the outputfiles and find out which is the best poly
7.) (re-format the best poly in ggnfs-format)

But it would be nice if we can do this automatically by just typing "msieve -np -t <number of threads>".

Edit: This would also accelerate poly search when it is launched by scripts like aliqueit (these can be adapted to start msieve -np -t <number of threads>). AFIK, FactMsieve.pl also does msieve -v -p -nc3 -t <number of threads> for square root phase - it would also be nice if each thread gets its dependencies to solve instead of running sqrt on just one thread.

[jasonp]

I don't want to run multiple threads for the square root because of the potential memory use; running different dependencies in parallel makes the memory for one dependency scale linearly. This is no problem for small inputs, but small inputs complete the square root in a few minutes anyway. The right level of parallelism is to run a single dependency using multiple threads; I'll think about trying to do that, it may not be that hard with GMP.

Running the poly selection in multiple threads, especially with the GPU code, will be tricky. Also, I'm in the middle of merging the CPU and GPU code versions, so my local sources are a mess right now.

At least the .p file has polynomials in GGNFS format already :) You also can do several msieve runs in the same directory with '-l [unique_name] -s [unique_name] -nf [unique_name]' and all the generated files will have different names.

Also, '-d <num>' will have the binary stop itself after <num> minutes.