TF before LL
 

If I have an exponent queued for LL test which has been verified to let's say 68 bit levels. Can I TF it further and modify the worktodo file with the new bit levels cleared. Would it be worth the trouble? In other words, does the LL test benefit from having more bit levels cleared?

while i don't know how to change the work type but with further TF, which is often much faster than whole LL if it is found to have a factor then that exponent can be eliminated.

[QUOTE=Unregistered;275762]If I have an exponent queued for LL test which has been verified to let's say 68 bit levels. Can I TF it further and modify the worktodo file with the new bit levels cleared. Would it be worth the trouble? In other words, does the LL test benefit from having more bit levels cleared?[/QUOTE]

Sure can
1. Stop Prime95
2. Edit worktodo.txt
3. Just in front of the Test= line add: Factor=<exponent>,68,xx
4. Change the Test= line for the new bit level
5. Save and close
6. Run Prime95

[QUOTE=Unregistered;275762]does the LL test benefit from having more bit levels cleared?[/QUOTE]

Only if TF founds a factor. In that case there is no need to run LL and two LLs-time is saved (that is A LOT). If TF don't find a factor, there is no difference for LL i.e. LL runs exactly in the same amount of time regardless how far factored it was.

[QUOTE=Unregistered;275762]Would it be worth the trouble?[/QUOTE]
[B]Yes[/B] if under 69 or 70 bits. [B]Maybe[/B], for small bit level TF (like 69, 70, 72, depending on the exponent, higher exponents reach higher bit level faster). [B]Certainly Not[/B], for higher bits. To go one bit higher (like from 71 to 72 for example) then you need the same amount of time like going from 0 bits to 71 bits. The TF-ing amount of time doubles with every bit that you raise. If you have very fast TF-ing hardware, like a GPU or so, then better TF first, using the GPU. See here around for tips. To use P95 to TF (to 72, 73 bits or higher) on CPU, is waste of time. GPU's are one magnitude order faster at TF then CPU's, so let the guys with heavy artillery GPU's do the TF, and choose an exponent which is TF-ed enough to do LL or P-1 only, on your CPU.

What exponent?

Specifically, if it's around 53-55 million, then go to 70, [I]maybe[/I] 71 bits if you really want to. More is a waste. And LaurV has everything else covered in his post.

[QUOTE=LaurV;275768][B]Yes[/B] if under 69 or 70 bits. [B]Maybe[/B], for small bit level TF (like 69, 70, 72, depending on the exponent, higher exponents reach higher bit level faster).[/QUOTE]

I don't agree. Most LL assignments have already been factored to or beyond the optimal balance between TF and LL. If by chance the OP's hasn't, the client will automatically do the extra TF needed.

That the emergence of extremely fast GPU factorisation has made it possible and desirable to use GPUs to go a few bits beyond that optimum, does not mean that anyone should use a CPU to do so.

There's a third alternative on the TF front: PM me with the exponent, and I will run TF on it for a few bit levels. Plan on this taking a day or two for mail delays. As Mr P-1 noted, running TF on your CPU is one or two orders of magnitude slower than doing it on a GPU, and therefrore not terribly effective. The 72 bits we are discussing for current LL assignments is only optimum if the TF is done on a GPU. Otherwise, it's back at 68 bits where P95 left it.

The chance of finiding a factor going 4 bit levels is about 1/69+1/70+1/71+1/72, which is in the neighborhood of 6%, still leaving an LL test to do 94% of the time. P-1 factoring will search some of the same area, further reducing the odds.

You might also want to set up P95 to let P-1 have lots of memory (500Meg to 1 Gig) so as to get a good P-1 from P95 before it begins the LL test proper. P-1 is a much smarter algorithm than TF, and can find some factors that TF simply can't touch.

Don't let any of this discourage you -- it is all part of the grand hunt...

[QUOTE=Mr. P-1;275797]I don't agree. Most LL assignments have already been factored to or beyond the optimal balance between TF and LL. If by chance the OP's hasn't, the client will automatically do the extra TF needed.

That the emergence of extremely fast GPU factorisation has made it possible and desirable to use GPUs to go a few bits beyond that optimum, does not mean that anyone should use a CPU to do so.[/QUOTE]

He and I agreed on 70 bits, which is only one more than the 69 set for current wavefront exponents. Also, Christenson, can Unregistereds use PM?

[QUOTE=Dubslow;275845]Also, Christenson, can Unregistereds use PM?[/QUOTE]

Hint: one field is,
Recipient Username(s)

[QUOTE=Dubslow;275845]He and I agreed on 70 bits, which is only one more than the 69 set for current wavefront exponents. Also, Christenson, can Unregistereds use PM?[/QUOTE]
Indeed, 70 bits is probably an optimum given the amount of total TF we have working. But part of the optimum is to increase the number of those working on the project, and if I can help that by doing a little extra TF for Mr Unregistered, then we are all ahead.

If PM won't work, posting here will, and registering a real name won't hurt....maybe I have an un-moderated message awaiting me already...hope springs eternal...

[QUOTE=LaurV;275768]Only if TF founds a factor. In that case there is no need to run LL and two LLs-time is saved (that is A LOT). If TF don't find a factor, there is no difference for LL i.e. LL runs exactly in the same amount of time regardless how far factored it was.
[/QUOTE]


Thank you, this is the answer I was looking for. I already pushed the bits to 72 in the mean time so no need to wait for my number.

Although, does someone have a intuitive way to explain why the LL test has to restart from scratch to insure a factor is prime or not as opposed to exploiting the known information?