[QUOTE=Xyzzy;412690]6809[/QUOTE]

I have to say that at one point in time I fell in love with 68000 assembly. Very symmetrical.

I mostly hand coded "Amoeba Invaders" in 68K assembly. Unrolled loops, etc.

We thought we would get a lucrative contract.

Instead we (Late Night Developments) almost got our asses sued off....

[url=https://www.youtube.com/watch?v=O4J8kaqBhXg]This?[/url]
It does have your name on it :smile:

[QUOTE=James Heinrich;412720][url=https://www.youtube.com/watch?v=O4J8kaqBhXg]This?[/url]
It does have your name on it :smile:[/QUOTE]

Yup. That's it. :smile:

We were about to get a serious contract right up until we were told we were about to be sued because it was too accurate.

I'm not joking....

[QUOTE=James Heinrich;412653]I set Prime95...[/QUOTE]
We compare, as Chris would say, apple and oranges. The comparison has to be between [U]GPU[/U]-TF, [U]GPU[/U]-LL and [U]GPU[/U]-Pm1, which can clear more exponents per time unit. This with and without P95 running in background (in the [U]CPU[/U]).

And if you have a Nvidia card and [U]can[/U] run cudaPm1, then [B][U]definitively[/U][/B] it is better to run P-1 [U]before[/U] going to that last bit (i.e 75 for the LL front). If you have even 2% chance of finding a factor, this means you will find one factor in 50 trials, and the TF will roughly find 1 in 75, for the comparable running time.

In fact, much before the times become comparable, you must switch to P-1. For a chance of 3.9% or 4% to a factor (which is the usual one at the LL front right now, without manually changing the PFactor lines), you will find one in ~25 exponents. So, if your TF time takes a third of how much time P-1 takes, you are [B][U]better[/U][/B] doing P-1.

Some may remember RDS's plea for P-1 long time ago, he was right, and George also said long time ago, when all TF/P-1/LL was done on CPU only, that P-1 before the last bit is better - now we only moved from CPU to GPU, but the scores stay. The GPUs may be faster at TF, so we raise few bitlevels, but the logic is exactly the same, it became the same since we became able to do [U]all[/U] 3 types of work on [U]GPU only[/U].

[QUOTE=chalsall;412704]OK. Cool.
But... If the P-1 code knew what had already been found, would it not optimize itself to take this into account?[/QUOTE]
(sorry double posting, continued to read through the thread, saw George's post too)
It doesn't work like that. Big factors can be smooth (i.e. P-1 discoverable) and small factors can be "rough" (i.e. nor discoverable by P-1). The fact that we TF to some limit doesn't help P-1, or say, it helps it as a side-effect, because we only do P-1 if we don't find any TF factors, and it scrambles a little bit the "percent of chances" calculus (i.e. instead of "how many B1-power-smooth numbers", we should ask "how many B1-power-smooth numbers over xx bits", when we calculate the chances to find a factor).

[QUOTE=LaurV;412726]We compare, as Chris would say, apple and oranges. The comparison has to be between [U]GPU[/U]-TF, [U]GPU[/U]-LL and [U]GPU[/U]-Pm1[/QUOTE]I must respectfully disagree.
What you say is perhaps true if you want to optimize what work you as a user with your particular set of GPU/CPU resources should work on, but I think here we're looking at the overall GIMPS picture, where 90+% of TF is done on GPUs, and 90+% of P-1 is done (usually by a different person) on a CPU.

[QUOTE=James Heinrich;412730]I must respectfully disagree.
What you say is perhaps true if you want to optimize what work you as a user with your particular set of GPU/CPU resources should work on, but I think here we're looking at the overall GIMPS picture, where 90+% of TF is done on GPUs, and 90+% of P-1 is done (usually by a different person) on a CPU.[/QUOTE]
You appear to claim that solving for the most-efficient path should take into account the typical hardware used for each task, rather than judging by what a single piece of hardware can do for each task. How would you go about accurately doing that? How do you value 1 hr of GPU time vs 1 hr of CPU-core time (or 1 hr of a full CPU)?
I don't see how making those judgments is an improvement over pretending one's own GPU is the only item that is going to work on a particular number, and determining the most (expected) time-efficient way to go about testing that candidate. The solution is likely different on CPU vs GPU (for instance, it may be optimal to P-1 higher bounds on a GPU than a CPU because the code is relatively faster than TF code on a GPU, or vice versa), but it seems folly to declare one solution that holds for all of GIMPS for any machine.

Well, Nash said in his Equilibrium that the group is better if any individual does what is better for the group [U]and himself[/U].
You mean that if I can clear one exponent per day doing "this type of work" with [U]my hardware[/U], but I can only clean one exponent every X>1 days doing "this other type of work", [U]is there any situation[/U] when the project (in its totality) would do better if I do the "other type of work"? For the hack of me, I can't believe that. The project is better if any user clears how many exponents he can, how fast he can, with the hardware he has. Period.

If your hardware can clear more exponents per day (week, month) doing TF, then go for TF.

I might be wrong...

edit: and of course, this does not consider that some guys want to find primes, and don't care about us, the small fish doing the dirty work for them, remember davieddy. Or curtisc, who only does LL. Others want to find factors, etc...

Change in P-1 release policy
 

Just so everyone knows, based on this discussion GPU72 will now release candidates for P-1'ers back to Primenet as needed sorted by Factored level ahead of the Cat 3 range. This is so there's little to no chance of them being assigned for LL'ing.

If a factor isn't found GPU72 will then recapture the candidate to take to 75 bits before re-releasing back to Primenet for LL assignment.

Those using the GPU72 manual P-1 assignment page may wish to choose the option "Lowest TF level". The default "What Makes Sense", and the Proxy, will continue to assign candidates sorted by Lowest Exponent in order to appropriately feed the LL'ers.

[QUOTE=LaurV;412758]You mean that if I can clear one exponent per day doing "this type of work" with [U]my hardware[/U], but I can only clean one exponent every X>1 days doing "this other type of work", [U]is there any situation[/U] when the project (in its totality) would do better if I do the "other type of work"? For the hack of me, I can't believe that. The project is better if any user clears how many exponents he can, how fast he can, with the hardware he has. Period.[/QUOTE]Try this: Look for small factors in the 900M range. You'll clear more exponents per day (by finding [SIZE="1"]small[/SIZE] factors) than you do now, but it's arguably less useful for the project overall.

[QUOTE=LaurV;412758]You mean that if I can clear one exponent per day doing "this type of work" with [U]my hardware[/U], but I can only clean one exponent every X>1 days doing "this other type of work", [U]is there any situation[/U] when the project (in its totality) would do better if I do the "other type of work"? For the hack of me, I can't believe that. The project is better if any user clears how many exponents he can, how fast he can, with the hardware he has. Period.[/QUOTE]Simplistic greedy algorithms are rarely the best if everyone is being greedy. Cooperation and coordination is usually the best way for everyone to make maximal progress towards some shared goal.