Mini-Projects

[Christenson]

Originally Posted by Dubslow

Well, actually I meant PrimeNet assigning DC exponents TF assignments, not mfaktc. Also, my HS has a FIRST team :) (which I was sort of kind of not really on)

If you can think about being on a FIRST team, then you are half my age....I highly recommend joining it if you have the resources (particularly in the time domain), because there are two important political lessons to learn there, the first one being that fooling with tech can be a lot of fun, the second being how large technical teams do and don't function. The FIRST teams are very much mirrors of real life.

My FIRST team has a little off-season, off-FIRST assignment: build a robot to kick field goals for the university football team. Last year, the kids built a 4-bit adder out of the relays normally used to control the robot.

Now as for primenet automatically assigning DC exponents to TF, the problem is that automating mfaktc (and mfakto) is a necessary first step, because my cheap GPU (a $100 GTX440) is 4x faster than your expensive quad-core CPU at trial factoring, so it really makes no sense to ask CPUs to do TF anymore.

Also, the experience has been that the quality of P-1 has tremendous variability in the current DC ranges; the better the P-1 was, the worse the odds of TF finding a factor since the search spaces overlap. However, to keep perspective, additional TF might knock out an additional 10% of DC exponents -- meaning 90% of exponents awaiting DC are still going to need DCs. TF, being its simple, brute-force self, runs into an exponential wall of effort, which the GPUs have pushed back a bit (well, maybe 7 bits with a 100x speedup), but the wall is still there...effort doubles every bit level.

[MrHappy]

Originally Posted by davieddy

ABSURD

IRRELEVANT ;)

Originally Posted by davieddy

TF is obviously best done before the first LL test

That's definitely true. I wanted to aim at DCs to reduce the gap between LL and DC, but aiming at LLs is fine with me.
How many LLs are handed out per week? =How many exponents do we have to TF up a bit or two per week?
Thoughts?

[Dubslow]

Originally Posted by Christenson

If you can think about being on a FIRST team, then you are half my age....I highly recommend joining it if you have the resources (particularly in the time domain), because there are two important political lessons to learn there, the first one being that fooling with tech can be a lot of fun, the second being how large technical teams do and don't function. The FIRST teams are very much mirrors of real life.

My FIRST team has a little off-season, off-FIRST assignment: build a robot to kick field goals for the university football team. Last year, the kids built a 4-bit adder out of the relays normally used to control the robot.

Now as for primenet automatically assigning DC exponents to TF, the problem is that automating mfaktc (and mfakto) is a necessary first step, because my cheap GPU (a $100 GTX440) is 4x faster than your expensive quad-core CPU at trial factoring, so it really makes no sense to ask CPUs to do TF anymore.

Also, the experience has been that the quality of P-1 has tremendous variability in the current DC ranges; the better the P-1 was, the worse the odds of TF finding a factor since the search spaces overlap. However, to keep perspective, additional TF might knock out an additional 10% of DC exponents -- meaning 90% of exponents awaiting DC are still going to need DCs. TF, being its simple, brute-force self, runs into an exponential wall of effort, which the GPUs have pushed back a bit (well, maybe 7 bits with a 100x speedup), but the wall is still there...effort doubles every bit level.

Well, I just graduated and am now almost halfway through my first (lol) college semester, so no can do there.

Also, I have a GTX460, that's why I was mentioning it. I don't see why mfaktc has to be automated first, just make another manual assignment option.

[Mr. P-1]

Originally Posted by davieddy

ABSURD

Disagree, for reasons we have already discussed.

TF is obviously best done before the first LL test, and to 4 bits
more than a DC (assuming the exponent is twice as big).

Obviously. But we have a large pool of exponents which have already been LLed once. Doing the extra TF prior to the LL for these is not an option.

Endorsed by George and Jacob (to name but two), I've suggested that
a few GPUS could easily TF the exponents currently being dished out for
first time LL to 72 bits. Hardly any of them have been.

I'm certainly not opposed to that. But if it's worth expending a certain amount of effort to TF a particular exponent to X bits in order to save two LLs, then it's worth expending half that effort to TF the same exponent to X-1 bits in order to save one LL.

The GPU TF effort should be focussed upon both the first-time test, and DC wavefronts. If there are insufficient resources to TF every exponent on the LL wavefront to 72, prior to it going out to test, then do so to 71, or 70, or whatever the resources permit. Similarly if there are insufficient resources to TF the DC wavefront to 69, say, then do so to 68 or 67.

It's worth noting that if this plan were to be followed, only a tiny fraction of the GPU resources would be used on DC range exponents, so it really doesn't conflict with your goal of advancing the first-time test wavefront as fast as possible.

[Mr. P-1]

Originally Posted by MrHappy

I wanted to aim at DCs to reduce the gap between LL and DC, but aiming at LLs is fine with me.

The overarching ethos of the project is not "Do what (someone thinks) is best for GIMPS". It's "Do whatever floats your own boat". This should be borne in mind when evaluation advice from me or anyone else.

[Christenson]

Dubslow, if you like, why don't you run mfaktc and cudaLucas on exponents to DC, with the idea of checking whether it is easier to knock off DC exponents by TF or by LL test.....I think ckdo can give you a good-sized set of DC exponents for TF. Removing exponents from the DC pool by either method certainly will help GIMPS.....

[davieddy]

Originally Posted by Mr. P-1

The overarching ethos of the project is not "Do what (someone thinks) is best for GIMPS". It's "Do whatever floats your own boat". This should be borne in mind when evaluation advice from me or anyone else.

Rock the Boat.

IMAO DCs are best left to to their own devices (like Michael Jackson)

David

[Dubslow]

Originally Posted by Christenson

Dubslow, if you like, why don't you run mfaktc and cudaLucas on exponents to DC, with the idea of checking whether it is easier to knock off DC exponents by TF or by LL test.....I think ckdo can give you a good-sized set of DC exponents for TF. Removing exponents from the DC pool by either method certainly will help GIMPS.....

Currently I've got some CUDALucas DC's running (oh the irony (it's actually a 53M DC, so I spose not)) but I'll give it a shot afterwards.

As for the argument, what about considering from this point of view: With CUDALucas or one core of a top of the line cpu, I can knock out 1 DC every ~2.5 days. I can also do (conservatively) 1 bit per hour of TF. Assuming we can knock out 1/20 DC's with a factor (not as conservative) it is more efficient to TF the DC's as far as rate eliminated (though of course the ones that fail will need a proper DC).
Que pensez-vous?

[Christenson]

Originally Posted by Dubslow

Currently I've got some CUDALucas DC's running (oh the irony (it's actually a 53M DC, so I spose not)) but I'll give it a shot afterwards.

As for the argument, what about considering from this point of view: With CUDALucas or one core of a top of the line cpu, I can knock out 1 DC every ~2.5 days. I can also do (conservatively) 1 bit per hour of TF. Assuming we can knock out 1/20 DC's with a factor (not as conservative) it is more efficient to TF the DC's as far as rate eliminated (though of course the ones that fail will need a proper DC).
Que pensez-vous?

Using CUDALucas to knock off 53M DCs? Terrible Idea.......just terrible......why, if you do enough of that, DCs will catch up with first-time LL checks, and then where will we be? Will we find M49?

The question, in terms of GIMPS progress, is how to prove the most exponents aren't prime in the least time. If you TF a given exponent to, say, from 70 to 71 bits, the odds are approximately 1/70 of finding a factor. If that check takes an hour, you will spend an average of 72 hours finding a factor and proving an exponent not prime. If you can do the LL-D in less than 72 hours, then you are better off doing the LL-D. The problem with TF is that, using the same assumptions as above, if you TF from 71 to 72 bits, the cost will double to 2 hours...but the odds of finding a factor remain the same. You can clearly see that the returns will diminish rapidly with bit level. There's also the problem that the odds are somewhat worse than I stated, because P-1 will have partially searched the space searched by TF.

The other corollary of this is that this speedup of TF caused by GPUs does not eliminate the need for LL checks, it merely reduces it slightly.

Enjoy yourself, and let us know how it goes...2.5 days for the LL at 53M sounds awfully quick, so I encourage you to go get the right numbers on your machine. It might be enough to make me upgrade my GT440...

[Dubslow]

No, I meant 27M DC's in 2.5 days. 53M is about 155 seconds for 10,000 iterations, which according to Wolfram Alpha is ~9.5 days, and of course no one gets 100% efficiency. I'd guess 10-11 days total. I'm DC'ing my first completed LL, and figure CUDALucas counts as far as independent verification (I wouldn't use my CPU). And I was guessing 1/20 - 1/25 chance to find a factor, not 1/70.

Also, that IBWDT LL program would be nice, but it seems to have disappeared...

[MrHappy]

26M: 21387 at 67 bit (only 7158 still needing a DC)
27M: 11719 at 67 bit and 9902 at 68
28M: 21421 at 68 bit

54M-59M: 3631 at 68 bit and 17646 at 69 bit