If you are using MSVS then sse options are ignored in 64bit mode.
Moreover all cpu optimizations are useless since all the work is done on gpu.
+ It is already proven that 64 bit cuda mining software is little bit slower then 32 bit ...

So will we see the source code soon?

It looks like last commit has 10% rejects "job not found" even running without -g with extranonce subscribe enabled. nicehash ...

For me no luck with -g again. Running without parameters gives significantly better results. But miner shows realistic rate with -g now, it's good.

yes, latest sources from git show no extranonce subscribe support on the pool when using -g parameter

I do ... but build process takes some time
Will see ... new charts on nicehash will be helpful

too good to be true

Sorry, I have no faith in -g parameter. I think miner-shown performance is incorrect in this mode. Pools have no confirm of the boost in -g mode in my case.

the speed is 474900 khashes/s
-i parameter doesn't change cpu load. The same 100% load of one core. With real-time priority unusable ...

2 sp_

blake loads one cpu core to the maximum for me ... gtx750 ... both my own build and from your link

I moved from beta driver 147.xx (that comes with CUDA 7 bundle) to latest 150.xx
And with it a lost 10khs in lyra2: #49 build by sp_ from 884 goes to 872.
With latest commits my own build makes 874khs.
Rather weird ... other algo's feel fine and it seems to have some boost on driver change.
Maybe something wrong with my testings ... ?

It's asus 280x 1100/1500
qubit and quark rates are good

brief check #49 with my best previous results (don't remember exact version ...)
x11 goes to 2905 from 2890
x13 2287 from 2275
x15 1990 from 1981
qubit 4585 from 4552
skein 83750 from 83620
lyra 884 from 882
Great work, great release!

2 sp_

Tried your #49 with neoscrypt

I tried djm's version before and for my poor gtx 750 1gb it runs only with -F 1 and gives 175khs.

Default run with your #49
start /realtime ccminer.exe --cpu-priority 5 -a neoscrypt

it takes almost all gpu memory and pushes load to "Bus interface" as it called in GPU-Z.
With such conditions performance is poor - only 45 khs.
But i tried to play with -i parameter and found that it runs with maximum -i 14.5
With such config it shows 810MB memory usage, 0% bus interface load, 99% gpu load, 30-35% memory controller load.
The numbers are 187khs and this is better then old djm's version. But i didn't check on the pool yet .

So I think you should use not so heavy default launch config for this algo for low-level gpu's like mine.

Try to run without -g and with default -i. And then check on the pool. I suppose the numbers on the pool will be better without -g ...

By the way ... what laptop model do you use? Is cooling system adequate for mining? What are 840M temp? I'm looking for a laptop with Maxwel GPU for my work. Would be nice to choose one capable for mining when it will not be in use ...

commit #753
Tried to run quark and x11 without any parameters. Huge cpu usage (totally grabs one cpu core), system unusable with high priority.
p.s. win 7 64 bit, single gtx750, athlon x2 3ghz

R47 was not best for me.  Commit 742 was: 5824khs
Now commit 749 5834 khs, +10khs, nice

gtx750 oc'ed

#47 vs. Commit 742

skein 83210 vs. 83620
quark 5810 vs 5824 (hashrate fluctuating, maybe incorrect measuring)

conclusion: commit 742 is best for me ...

Forget about -g ... it just doesn't work or has no advantages

I just compared again #43 and #46 with equal -i parameters. -i 19.8 was the best for #43 and with such intensity #43 is faster then #46 with -i 19.8.

But default intensity for #46 is  -i 22. #43 just didn't work with -i 22.
And with -i 22 (or without -i) #46 is faster then #43 with -i 19.8 (or without i).
My conclusion is that #43 is more efficient per thread but as it cannot pass -i 20 border it is slower.
If you will count hashes per watt then it maybe becomes that #43 is more efficient as in my case #43 never takes more 58% TDP but #46 takes up to 65% TDP