GPU to 72 status...

[James Heinrich]

Originally Posted by Bdot

There are 3 factors that influence mfakto (and mfaktc) performance

Originally Posted by James Heinrich

What would be brilliant would be if Oliver/Bertram could include a broad benchmark that runs a few classes for a range of exponents (every 1M, 5M, etc across the range specified [e.g. 30M-80M]) and for each test at various bit ranges and give throughput performance at that exponent+bitlevel. That would provide consistent data to map the 3D performance variance for the various GPUs.

@Bdot: how hard would it be to implement a benchmark such as I suggest?

[LaurV]

Originally Posted by manfred4

seems to be a lot smoother between the exponents and bitlevels.

Yes, it is. As explained few posts above, mfaktc uses (almost?) the same kernel (barrett76?) for all this stuff. The "big drop" in performance you will feel only for very short assignments, or only for bitlevels over 76, when a less performant kernel will be used. Also, as discussed, mfakto has "lower bitlevel" kernels, optimized to fit the AMD/OpenCL architecture (see Bdot's posts).

[NickOfTime]

Hmm, or how much work to create a BARRETT76_MUL15 kernel?

[kracker]

Originally Posted by NickOfTime

Hmm, or how much work to create a BARRETT76_MUL15 kernel?

Well, I think the question is: How fast or efficient would it be?

[Bdot]

Originally Posted by kracker

Well, I think the question is: How fast or efficient would it be?

It would be exactly as fast as the 82_MUL15 kernel, because it would need to be implemented like it.

When using 32-bit chunks of data, all current kernels need 3 of them, giving 96 bits. Now, certain short-cuts are possible that reduce the available bits. It's basically using less exact intermediate values during the calculation that are cheaper to compute, like skipping evaluation of some carry flags. Different short-cuts have different costs, but adding them all in brings you down to 76 bits usable out of the 96.

Now, when using 15-bit chunks, you can use 5 of them for 75 "raw" bits, or 6 chunks for 90. Adding in all short-cuts results in 69 and 82 usable bits, respectively. 73 bits is the full implementation with 5 chunks (no short-cuts; there are always small rounding errors that eat one or two bits).

It might be worth checking again, if I can squeeze out 74 bits in 5 chunks - I currently don't remember why I did not succeed the last time ...

[NickOfTime]

Originally Posted by Bdot

It would be exactly as fast as the 82_MUL15 kernel, because it would need to be implemented like it.

When using 32-bit chunks of data, all current kernels need 3 of them, giving 96 bits. Now, certain short-cuts are possible that reduce the available bits. It's basically using less exact intermediate values during the calculation that are cheaper to compute, like skipping evaluation of some carry flags. Different short-cuts have different costs, but adding them all in brings you down to 76 bits usable out of the 96.

Now, when using 15-bit chunks, you can use 5 of them for 75 "raw" bits, or 6 chunks for 90. Adding in all short-cuts results in 69 and 82 usable bits, respectively. 73 bits is the full implementation with 5 chunks (no short-cuts; there are always small rounding errors that eat one or two bits).

It might be worth checking again, if I can squeeze out 74 bits in 5 chunks - I currently don't remember why I did not succeed the last time ...

Hmm, I guess it depends on how many to 74 exponents are left and how long we will be processing them :-). I seem to be mostly processing 73-74's in the 65/66M range at the moment...

[James Heinrich]

Originally Posted by NickOfTime

Hmm, I guess it depends on how many to 74 exponents are left and how long we will be processing them :-)

Many, and a long time.
As of 01-May-2014 "many" was approximately 21,176,383 exponents above 65M (for requiring 2⁷⁴) in PrimeNet range (below 1000M) that are currently TF'd to less than 2⁷⁴ and will eventually need to be taken there. I didn't bother to calculate the THz-years required, but it'll be a bunch.

Small trivia: if we continue TF limits in the current curve, TF for the range between 1000M-4294M will require 1.5 EHz-days (exahertz-days, as in thousand-million GHz-days. That means 1000 TitanBlack/780ti GPUs running continuously for 1000 years.)

[Bdot]

Originally Posted by James Heinrich

@Bdot: how hard would it be to implement a benchmark such as I suggest?

I was extending the --perftest mode of mfakto over the last versions, but so far it is mainly testing the sieving performance, in order to find the best config values.

Doing the performance tests for each kernel is on the list ... Oliver and I discussed that a while ago, in order to have some comparable results. we need to revive that.


And my attempt for a 74_15 kernel comes in less than 1% ahead of the 82_15 kernel, but still misses some factors I will need to use an even more accurate modulo function that will slow down the kernel even more ...

[chalsall]

Originally Posted by Bdot

Doing the performance tests for each kernel is on the list ... Oliver and I discussed that a while ago, in order to have some comparable results. we need to revive that.

That would be really cool. What would be even more cool is if such results could then be submitted to Primenet, and then made available to those interested. Perhaps James could help with that.

Originally Posted by Bdot

And my attempt for a 74_15 kernel comes in less than 1% ahead of the 82_15 kernel, but still misses some factors I will need to use an even more accurate modulo function that will slow down the kernel even more ...

Not meaning to blow inappropriate sunshine. But what you and Oliver (et al) do is (IMO) quite impressive.

[James Heinrich]

Originally Posted by chalsall

What would be even more cool is if such results could then be submitted to Primenet, and then made available to those interested. Perhaps James could help with that.

I don't know about on PrimeNet since I'm not all that comfortable with database interactions there, but I'd be happy to make such data available in raw and aggregated form on mersenne.ca

[chalsall]

Originally Posted by James Heinrich

I don't know about on PrimeNet since I'm not all that comfortable with database interactions there, but I'd be happy to make such data available in raw and aggregated form on mersenne.ca

LOL... If you could "make it so", is would be appreciated and useful.