http://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-review/2
Because NVIDIA has essentially traded a fewer number of higher clocked units for a larger number of lower clocked units, NVIDIA had to go in and double the size of each functional unit inside their SM. Whereas a block of 16 CUDA cores would do when there was a shader clock, now a full 32 CUDA cores are necessary. The same is true for the load/store units and the special function units, all of which have been doubled in size in order to adjust for the lack of a shader clock. Consequently, this is why we can’t just immediately compare the CUDA core count of GK104 and GF114 and call GK104 4 times as powerful; half of that additional hardware is just to make up for the lack of a shader clock.

But of course NVIDIA didn’t stop there, as swapping out the shader clock for larger functional units only gives us the same throughput in the end. After doubling the size of the functional units in a SM, NVIDIA then doubled the number of functional units in each SM in order to grow the performance of the SM itself. 3 groups of CUDA cores became 6 groups of CUDA cores, 2 groups of load/store units, 16 texture units, etc. At the same time, with twice as many functional units NVIDIA also doubled the other execution resources, with 2 warp schedulers becoming 4 warp schedulers, and the register file being doubled from 32K entries to 64K entries.

http://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-review/2
In GF114 each SM contained 48 CUDA cores, with the 48 cores organized into 3 groups of 16. Joining those 3 groups of CUDA cores were 16 load/store units, 16 interpolation SFUs, 8 special function SFUs, and 8 texture units. Feeding all of those blocks was a pair of warp schedulers, each of which could issue up to 2 instructions per core clock cycle, for a total of up to 4 instructions in flight at any given time.

http://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-review/2
Ultimately where the doubling of the size of the functional units allowed NVIDIA to drop the shader clock, it’s the second doubling of resources that makes GK104 much more powerful than GF114. The SMX is in nearly every significant way twice as powerful as a GF114 SM. At the end of the day NVIDIA already had a strong architecture in Fermi, so with Kepler they’ve gone and done the most logical thing to improve their performance: they’ve simply doubled Fermi.

Altogether the SMX now has 15 functional units that the warp schedulers can call on. Each of the 4 schedulers in turn can issue up to 2 instructions per clock if there’s ILP to be extracted from their respective warps, allowing the schedulers as a whole to issue instructions to up to 8 of the 15 functional units in any clock cycle.

WOW. This would be heaven if true.

Can you say 14 GPU Nvidia mining rig with a relatively cheap motherboard ?

The only thing that may kill it is the crap MH/$ value but prices will drop anyway ...

(...) (Unless an expert CUDA programmer can map out bitcoin mining effectively over 1536 nVidia streams?)

Rumor has it that the upcoming Ivy Bridge IGP will support OpenCL.
"The Ivy Bridge GPU adds support for OpenCL 1.1, DirectX 11 and OpenGL 3.1"
See http://www.anandtech.com/show/4830/intels-ivy-bridge-architecture-exposed/5 for more details.

Newegg listed "Shader clock: 2012MHz".

Interesting... 1536 ALUs at 2012MHz would give it more processing power than a HD 6990. Either the GTX 680 is going to be the fastest GPU for mining, or it is a blatant mistake from Newegg or the microarchitecture has undisclosed limitations that would prevent exploiting all this apparent power.

GK104 will have 1536 stream processors clocked at 1GHz.

Here's my totally speculative math:

A GTX 570 with 480 SP at 732MHz gets about 150 MH/s, or 0.3125 MH s^-1 SP^-1.

Scaling linearly with clock speed, we would expect 0.4269 MH s^-1 SP^-1 at 1GHz.

For 1536 SPs, that's 656 MH/s at an estimated TDP of 200w.

Of course, it's likely that these new SPs will be a little slower than the old ones, but even if they're 30% slower they should still be competitive with AMD cards.

It's never as good as it seems and it is never as bad as it seems.

Are people expecting the secondary market to be flooded with GPU's once singles are being easily accessible?

I'm not very good at stats, but this discussion falls under the heading of something that I understand which was the reason for my very first comment

DGM does not benefit from pool hoppers. I don't know why it says that in the FAQ. That is false though. I think the extra hash rate may be from GPUMAX, they can use up to 200gh here. Most of the hashrate is coming from 2 large miners.

I believe the jump in hash rate is due to hoppers calculating that there's a high probability of us finding blocks.  In other words, we're so down on our luck that there's bound to be a bright future.

Very early days yet, but I'll most likely be making the front end for this. My basic ideas for that so far are...

A python library, to enable easy communication with the miner in your own code should you want to
Command line and GUI tools (which use the library).
For the GUI I'm still not settled on a GUI framework. What ever I choose I intend for all of it to be cross platform of course. I may also make a web front end?

comments on this also welcome