Regarding speed, we also worked a lot. Now you can use Clang and speeds up the analysis. There are other ways to speed up the analysis of the project. Learn more here: Tips on speeding up PVS-Studio.

You could provide a smarter proxy, by reversing the shared_ptr and weak_ptr. If you use the shared_ptr solely within the owner class, then you can implement a proxy around a weak_ptr which provides safe monitoring of the object lifetime.

The proxy should not expose the weak_ptr directly (as someone could then grab ownership), but instead should provide methods that encapsulate its use, and throw/return an error/do nothing when the object pointed to is dead.

Second, lots of the stuff I’m doing does run quite well on CPUs. We have a volume raycaster and various image processing stuff which runs just as fine on a dual-six-core as it does on a 560 for instance, and it’s pretty cool if you can offload some work without changing your code (and I totally expect a dual-8-core Sandy Bridge with 100 GiB/s memory bandwidth to be even faster at some stuff.) Some of the processing stuff may also run on machines without a DX11 GPU (we still have some DX10 hardware flying around), where it automatically switches to the CPU with OpenCL. Lower performance, of course, but it “just works”. Yes, I know there is a CUDA to x86 compiler right now, but I like that Intel is providing an optimized OpenCL runtime for Intel CPUs and AMD one for their, etc. instead of relying on PGI to do a good job across all hardware. Plus, the OpenCL runtime is free. I guess that if I had already a large existing body of CUDA code, I would bite the bullet and buy the CUDA->x86 compiler, but truth to be told, I started serious GPU computing with OpenCL (on an AMD 5870); the first time I really used CUDA was quite a bit later.

Do you see a striking advantage CUDA has over OpenCL? For graphics interop, they are both quite limited still … you can’t share a depth buffer in CUDA 4.1 either, no mip-maps as well and there is no multi-sampled texture access, so except for the offline compiler CUDA 4.1 is just as good/bad for graphics as OpenCL 1.2.

Second, you can do better analysis and optimization if compiling offline. Read the AMD slides on how they hacked up LLVM to compile faster, all of this doesn’t matter when compiling offline.

So it’s not that easy, and the workarounds suck. There’s a good reason that DirectX comes with a compiler; never ever had problems loading a compiled shader; but compiling on the target machine was always tricky, in particular if different SDK versions were used.

You can compile your kernels, ask the API for the binaries, and the next time, upload the binaries directly, without having to recompilate them.
Also you can download the CL compiler from the driver with API, to free its resources,

So now, you can fix your article.