I can confirm a similar slowdown on Windows with a 650M GT, but not on OS X. I'm not sure what is going on yet, don't have a setup on Windows where I can build with CUDA 6.0 at the moment.

It did try building with CUDA 6.5 early access and it seems to render a few percent faster than 2.70. So if we can't find a solution for 6.0 at least we can hope the next CUDA toolkit release solves it.

Ok, found some further clues on OS X. The official testbuild also shows the slowdown, but my own cmake build does not, while a scons build does. So this may just be a cmake/scons difference, committed a fix in {b33d83bf51e8}.

Please test own builds or tomorrow's builder.blender.org builds to see if this is fixed now.

@Carlo Andreacchio (candreacchio) Is this what blender reports as ram usage or what GPU-Z or some other util reports?
If it is the latter you might render a default cube in both releases and you might find a very much larger amount of ram even for simple scenes.

If this is the case this comes ultimately from cycles complexity and the general properties of GPU architectures. Increases the max registers will most likely drop this number but also carries a performance penalty in most cases.

@Carlo Andreacchio (candreacchio)
Ok in that case I think we (you) should open a separate issue. This issue is indirectly related to a possible slowdown if we change the max-registers but is will be a different slowdown then the one this report is about. ( Combination of new cuda and a buildsystem bug)

Marking this resolved now, this is about as good as I can do as I tried a lot of things to get this faster with CUDA 6 (using cmake). Now that scons gives the same results as cmake the slowdown matches the performance based on which we made the decision to switch to CUDA 6. I think CUDA 6.5 will help further but that's not something we can use for this release yet.

Thanks i read all the posts and so on. And have to say i dont understand why the Cuda Builds of all version after 2.70a are so slow.? I got a Geforce 750 Ti OC my Test Shot needed with my old version only 1 min and 41 sec... even the latest build it took more than 2 minutes..? what happend? the speed improvment of my 750 in comparission to my old 550Ti drop nearly by one third that is nothing good. if this will not fixed i will use two different versions one for GPU and one for Smoke renderings. is it not possible to update the old faster cuda 5.0 kernel?

A lot of features were added since 2.70, mainly deformation motion blur, fire and smoke, but also baking. Additional code makes our CUDA kernel slower. And we switched to the CUDA Toolkit 6.0, which comes with a slowdown unfortunately.

There is nothing we can do about this, at east not for Blender 2.71. We also don't have 10 different GPUs at hand, so we cannot test with every card. As Brecht said, switching to the upcoming CUDA Toolkit 6.5 might improve the performance again, but for now we cannot fix this.

thanks for the fast reply. and your work. you done a amazing job with cycles. But i have to say i will not switch to version 2.71 till this is fixed. Because when i use it, its like i wasted my money with having a new card and lost a lot of speed in calcualtion.

but maybe there is a problem with the deformation motion blur. i dont use motion blur in my scene settings, and if i turn off the deformation blur stuff, it render a bit faster, even i turned it off in the global settings? maybe there is one of the problem areas. ... so thanks for your work... and hopefully this get solved in later builds maybe in 2.72

I absolutely understand the problem, and we will try to solve this later.

But we are close to the 2.71 release and cannot do risky changes anymore. As said, the upcoming CUDA Toolkit 6.5 from nvidia will hopefully improve the performance again. But we have to wait until that gets released. :)

Just a quick note.
I am not a native speaker but I think we should try and leave the acceptability to the people who have to accept the change in the end.
It might stem from a mistranslation / miss alignment with English but to me sentences like "this is totally unacceptable" somehow sound aggressive and if the person saying that is somehow the person who has to power to accept or not accept some change in blender.

Any and all regressions are bad and as far as I know all developers hate performance regressions with a passion but sometimes decision need to be made that negatively impact performance. This is not fun and probably never will be. But I think end the end it will have to be up to the people doing the actual work to decide if it is "acceptable".

Sorry for the off topic. But i have to say something. Sorry for my words, but in my point of view blender will not make the breakthrough to the industry with the tools itself inside blender. it can only conquer the markets with cycles. The Key is to be faster and with more quality then other render tools. That is for alot of guys i know for myself the only reason to make the change to blender. And so in my point of view it will be not good to drop the performance of some of the tools. Because a true artist dont need a new special button for creating a very good new simulation in physics and so on. Every Studio is working with different tools to get the best out of every software. Blenders Cycles Engine is the fastest VFX Renderengine i know for years. in my entire life, and i do it now for more than 17 years. I know exactly from what iam talking about. The key is speed and Quality inside Cycles. That is the most important point for alot of guys to make the switch...

And the Cycles development is Awesome, Thanks to every single line code from every Developer and Special Thanks to Brecht.

....

Sorry for my words but that is my opinion. ... 7 Artists i know which are working inside Studios told me. Cycles is the only reason to change...right now.. sorry to say but that is true.. and cycles with blender is very good in that case.