View Single Post
Old 2019-06-14, 16:02   #1762
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

2×2,311 Posts
Default

You won't get to verify their results, because msieve does quite a bit of randomizing of search spaces. When you run the msieve-gpu first stage (-np1), you'll see messages go by for each initial-coefficient like "searching piece 4 of 9". The search space grows as the input size grows, so up at C190 it may search 1 of 40 pieces for each leading coefficient.
I've managed to break all my linux-CUDA installs by way of not disallowing ubuntu to update the drivers, so I can't find you polys. Sorry!
A quick primer on msieve poly searching:
small leading coeffs produce higher skews, and there are sieving disadvantages to really high skew, so we often start a search at a higher coeff value than we would in CADO. For a C150, I'd start at 10k or so. If your GPU is modern, I'd add -t 2 before the quotes; if GPU still isn't running 90% or more, increase threads to 3 or 4. I use a 750ti, and -t 2 isn't necessary for me.

./msieve -np1 -nps "10000,500000" -s polyfile1

Let it run just a few seconds into the firehose of screen output, and kill it. Delete polyfile1.ms, as those hits aren't useful to us.
Open msieve.log, note the stage1 and stage2 norms selected by msieve. Divide stage1 by 8 or 10, divide stage2 by 30, and invoke the command line with those values included:

./msieve -np1 -nps "stage1_norm=3e25 stage2norm=3e26 10000,500000" -s polyfile1

Restricting stage 1 norm alters the number of raw polys sent from the GPU to the CPU for size-optimizing. If msieve is using 75% or more of a CPU thread, I'd tighten (lower) stage1 norm to reduce the flood of raw polys going to the CPU; the buffer is not large, so some of the flood is getting discarded when the CPU reaches 100%. Deciding what to divide the default norms by is a matter of taste, and the "best" values may vary by GPU model vs CPU speed. I've been mostly running C190+ searches this year, and size-opt up there takes meaningful CPU time so it pays to restrict stage1norm, but at C150 the CPU may never get busy so you may not need to restrict it at all.

Restricting stage2 norm alters the number of size-optimized polys written to the poly file. You'll do root-optimizing separately, but that takes a long time per poly so it's of no use to write thousands of polys to disk. At C150, a GPU-day is more than sufficient for a search, and I'd want to root-opt no more than 200 polys. So, if you find 10 or 20 polys per hour in polyfile1 you'll have plenty. Most folks use text-handling commands to sort and truncate the file to their top-nnn candidates for root-opting; on big projects I often root-opt 100 polys per day, which takes an hour or two on a single core.

root-opt:
./msieve -npr min_evalue={something about halfway between the default e-value in msieve.log and the lower "expected poly score" in the log} -s polyfile1

This will read size-opted polys from polyfile1.ms, root-optimize them, and write any results scoring better than your command-line e-value to polyfile1.p. The best-scoring poly will be written to msieve.log. You may wish to leave min_evalue at default your first couple runs, to make sure you get output; msieve actually sets a rather high default minimum in the C150 range so you won't get a flood of polys like you would at C130 or C180.

Good luck!
VBCurtis is offline   Reply With Quote