Optimisation advice

On the CPU this seems like the job for the vector unit. Eighter through hand written assembly code, intrinsics or an advanced compiler. You'll probably have to eliminate that blending table and calculate those values on the fly instead though.
Another option is to let the GPU handle the whole operation though a pixel shader.

Try with assembly. I think that it´s the best solution. Good luck!

1) as mentioned, a GPU is designed for work like this, you should be using that unless there's a very good reason. The blend you're doing should even be possible on graphics chips without shader support.


2) if at all possible, you should run your code through a profiler - optimisation without any profiling data is guesswork, and usually half of your guesses will be wrong. Ideally use something like VTune which can give you data on your cache use.


3) obvious stuff: only profile Release builds with release/retail versions of all libraries you're using, remove any frame rate limiters (including vsync waits), and ensure the way you display the frame rate/time isn't actually costing you performance (e.g. a GetDC() on a DirectDraw surface performs a Lock() internally and so kills parallelism and stalls everything).


4) accessing physical memory is one of, if not the single most expensive things you can do on a modern CPU - that's why modern CPUs have caches; if the memory you're accessing is in the cache (a cache hit), then performance is good, if the memory you're accessing isn't in the cache, then the CPU needs to go and get some main memory to fill the cache line you're accessing... The patterns you access memory in make a huge difference to cache performance.

A good profiler will tell you when you're getting awful cache performance (i.e. those cases where you should investigate access patterns and cache prefetching).


5) where are the images located/how were they allocated? - if they're D3D/OpenGL textures or DirectDraw surfaces [or similar], then if they're in AGP or video memory, *reads* from that memory won't use the cache and so will be *sloooow* - writes are better, but still not as fast as to system memory. If at all possible, put all images/surfaces you'll be accessing with the CPU in plain system memory.


6) using assembly language doesn't automatically make your code any quicker; well written C++ code compiled with a good optimising compiler can be many times faster than naively written assembly code (assuming none of the sins in #3 above are comitted). Hand tuned and well written assembly language can be faster, but only if you take account of the higher level issues like memory access patterns etc as well as lower level issues like pipelining and branch prediction.


7) as mentioned SIMD (Single Instruction Multiple Data) code, MMX in particular could be very applicable to your code to process multiple pixels at the same time. Many compilers won't automatically generate MMX code, so you might want to look at using intrinsics to access MMX. You'll find sample code doing things similar to yours on the developer.intel.com website.


8) Bear in mind that a comparison/"if" in your inner loop to avoid doing work may actually be affecting performance - profile it to check.

In case you're developing on linux, you should try the Valgrind . It's able of doing cache profiling for you with given cache configuration (you're not bound to your current processor). Another amazing tool is OProfile,but it needs kernel support (found in vanilla branch). OProfile is capable of profiling your entire system (including kernel).

You don't need assembly. I guess mmx instruction could give you a little speed, but you need to look at WHY your code is slow: all your pointers and references are alias hazards for the compiler. Which means that when you write img3ptr[0], the compiler needs to reload tGreenOnBlack and tInverseBlend, because the compiler has no idea that img3ptr[0] doesn't write the locations those variables reference!

So basically, the compiler can't do any optimization because it's fetching memory every operation. I wouldn't worry that this memory is uncached... you're accessing memory sequentially which allows automatic prefetches. It's just that the compiler can't trust its registers!

bottom line: eliminate all the '&'s .

You may get some speed from removing that if statement. Sometimes it's better to execute a few instructions more than you need every few iterations than to keep checking and branching every iteration.

Another optimisation that shouldn't take too long or make your code uglier than necessary is to try counting your loops backwards instead of forwards. Processors I have studied do less work when comparing a counter to zero than comparing it to some arbitrary value.

I see that you're not using the x and y variables. Your loop will have to access the value of myImageInfo1.iWidth for each pixel and myImageInfo1.iHeight for each row of your image. You can reduce memory access by removing the two for loops and replacing with one while loop (as shown in the following code):


Checking for a non-zero instead of doing an integer comparison each pixel is slightly faster. You could also make iNumPixels a register integer instead of an auto although the compiler is not likely to actually store the variable in a register due to the amount of code you have inside the loop.

(EDIT)
Just noticed post above mine - Kylotan kinda beat me to it!
(/EDIT)