I've ported some code from C to C++ and I'm shocked at how much more slowly it runs. I've written a lot of C++ in the past, so I know I haven't done anything absurdly inefficient, but execution times have gone up by 150% (2.5 times slower!). Has anyone else seen anything like this? Are there any particular aspects of the Keil C++ implementation that I should look out for?
Drew, Thanks for the comments. As you surmised (and as I mentioned earlier), the BusAddress is more than 32 bits long, and is in fact 48 bits. You have pointed out that the comparison operators are passed as pointers, which then need to be de-referenced. I understand that this is an expensive operation, but it is exactly the same as the original C code, where comparisons were done in a function which took pointers to structures as it's parameters.
You also suggested that eliminating the intermediate Bool variables would speed things up. I agree that this should work, but I have kept close to the original C code for the time being.
I really hope I don't have to look at the assembler to see what's happening.
I'm tempted to try changing the storage of the 48 bit address from a 16+32 bit structure to an array of three 16 bit unsigned numbers as the compiler may be able to apply more optimisations. I also think your suggestions for inlining the code may yield some useful results as code size is not a problem.
When program optimization comes to the point of trying to figure out what code the compiler likes the most, it all begins to look rather silly. This function needs a dramatic speedup? It's a perfect candidate for implementation in assembly language. From my experience, I wouldn't expect wonders of optimization from the C166 compiler.
- mike
"When program optimization comes to the point of trying to figure out what code the compiler likes the most, it all begins to look rather silly."
Absolutely - the whole point of using a HLL is to make life easier (some say, "more productive") for the Programmer. Clearly the C++ is failing in this!
"It's a perfect candidate for implementation in assembly language."
Or, if the original 'C' performance was OK, why not leave it in plain 'C'?
Well the original C code wasn't fast enough either! The 48 bit comparisons can probably be done really quickly in assembler, and wouldn't cause code bloat if inlined. I'm probably going to accelerate it in an FPGA at the end of the day.
As for re-coding for speed, I think it's a reasonable thing to do if you get enough benefit for the effort involved. It's not the worst solution in the world.