WAGs ?
 

I don't understand the meaning of WAGs in this context. What does it mean?

[URL]http://en.wikipedia.org/wiki/Wag_(disambiguation[/URL])

Forced B/S test?
 

If you really, very much, would like your P-1 test to include a B/S test is it possible to force P95 to include a B/S test in your P-1 test even though you don't have "enough" memory?

Of course I do understand that it would slow down the test and it will not be the most rational thing to do, but is it possible?

[QUOTE=aketilander;275161]I don't understand the meaning of WAGs in this context. What does it mean?

[URL]http://en.wikipedia.org/wiki/Wag_(disambiguation[/URL])[/QUOTE]

[url]http://www.acronymfinder.com/WAG.html[/url]

I'll let you figure out which one I meant :smile:

[QUOTE=axn;275154]Actually, it is not at all obvious that it _is_ beneficial. Period. The current P-1 code just makes WAGs about B/S efficiency.[/QUOTE]

That's true.

[QUOTE]It is probably more beneficial if people don't give enough memory for B/S so that they can run thru more P-1 tests -- rather than some tests getting super P-1 and some getting none at all.[/QUOTE]

I've argued before that people taking P-1 assignments are trying to solve a different optimisation problem from that faced by those doing P-1 as a preliminary to LLing the same exponent, and that the former should do P-1 to lower bounds than the latter. I wouldn't, however recommend reducing the available memory to speed up the computation. Rather I would suggest increasing the nominal number of bits factored in the worktodo file.

But I honestly don't think this makes a lot of difference, and I don't do this myself.

[QUOTE=aketilander;275161]I don't understand the meaning of WAGs in this context. What does it mean?

[URL]http://en.wikipedia.org/wiki/Wag_(disambiguation[/URL])[/QUOTE]

Try: [url]http://www.urbandictionary.com/define.php?term=wag[/url]
Def #5.

[QUOTE=Mr. P-1;275170]I've argued before that people taking P-1 assignments are trying to solve a different optimisation problem from that faced by those doing P-1 as a preliminary to LLing the same exponent, and that the former should do P-1 to lower bounds than the latter.[/quote]
Indeed. In the context of this thread, we're trying to avoid "no P-1 LL" as much as possible, so the volunteers should ensure the maximum number of exponents to be "reasonably" P-1'ed.
[QUOTE=Mr. P-1;275170]I wouldn't, however recommend reducing the available memory to speed up the computation. Rather I would suggest increasing the nominal number of bits factored in the worktodo file.

But I honestly don't think this makes a lot of difference, and I don't do this myself.[/QUOTE]
As long as increasing memory decreases the run time, go for it. But after a certain point, B/S will kick in, and increase the run time. Not good (at least from this thread's context).
Another factor: larger memory usage means, if you're stopping and starting the P-1 run frequently, the overhead will be higher [naturally, this is not relevant if you allow it to run to completion]

----

I'd be interested to see the precise relationship b/w memory allocated and stage2 run time for the current group of exponents under consideration [modulo the caveat that memory change will slightly alter the bounds chosen and success probability].

I'd like to see some realworld data. To avoid the effect of different cpus, this can be measure as the ratio of stage2 run time : stage1 run time. I can haz data? :smile:

[QUOTE=axn;275177]I'd like to see some realworld data. To avoid the effect of different cpus, this can be measure as the ratio of stage2 run time : stage1 run time. I can haz data? :smile:[/QUOTE]

That doesn't necessarily avoid the effect of different cpus. A while back I experimented with underclocking my PC by reducing the multiplier, effectively giving it a "different" cpu. This had appreciably more effect on stage 1 than it did on stage 2, presumably because stage 2 is bound by memory bandwidth and perhaps also latency to a greater degree than stage 1.

Also I find that, when it's otherwise idle, my dual core system spends considerably longer in stage 2 than stage 1. Consequently, with maxhighmemworkers=1, it accumulates uncompleted stage 2 over time. To counteract this, I run the stage 2 process at high priority. Stage 2 gets the entire core almost all the time, and produces results to a quite regular schedule, while stage 1 competes with every other process for the other core, and timings vary wildly depending upon what other applications I'm using. I still accumulate stage 2 over time, and have to switch to maxhighmemworkers=2 every now and again, but not as often as I otherwise would.

So I'm not sure how informative the ratio would be to you.

[QUOTE=axn;275177]As long as increasing memory decreases the run time, go for it. But after a certain point, B/S will kick in, and increase the run time. Not good (at least from this thread's context). [/QUOTE]

Isn't it only bad if the increased runtime doesn't give a proportionate increase in probability of factor?

Tom

Changing worktodo after additional TF work
 

When I receive a P-1 assignment, sometimes I do additional trial factoring with the GPU from 68—>71 before the P-1 work begins. It it important to change the worktodo file to reflect this increase before the P-1 process starts?

Chuck

[QUOTE=Chuck;275185]When I receive a P-1 assignment, sometimes I do additional trial factoring with the GPU from 68—>71 before the P-1 work begins. It it important to change the worktodo file to reflect this increase before the P-1 process starts?

Chuck[/QUOTE]

I don't think any changes are critical but I think you should change the second last parm that indicates the bits of TF done.

[QUOTE=fivemack;275181]Isn't it only bad if the increased runtime doesn't give a proportionate increase in probability of factor?

Tom[/QUOTE]

Yes. Problem is p95 doesn't have any hard data for calculating the probability. And AFAICT, it overestimates the worth of B/S. But let's say, for the sake of argument, that it is around a 10% increase (which would mean roughly 1 in 10 P-1 factor that was found where B-S was used could only have been found that way -- not sure empirical data supports that).

OTOH, _I_ don't have hard numbers as to how much worse the runtime is with different degrees of B/S. If it is say 20% more, then probably B/S is not worth it (in the context of this thread).