Speed optimisation in C++ Builder 2009

[BoMi]

Hi!

I've been using C++ Builder 2009 for the last couple of days trying to port one of my C++ Builder 2006 projects. The porting part went seamlessly. Had to change some parameter types for a couple of functions' calls due to the unicode support, but otherwise everything is great. I like this new RAD, everything works much faster than that 2006 version.

Now, to the problem. After porting the code is completely the same, except few function calls which needed parameters of type UnicodeString instead AnsiString (as before). But now, my application works much slower than when compiled with C++ Builder 2006.

Program essentially does some mathematics calculations during many iterations ('for' loop). Prevviously, before porting, the time taken for one iteration was in average 300-340 ms, but now, after porting, it takes at least 400 ms in average. This is a huge problem, especially if you take in consideration the number of iterations (which goes up to 30 000). Application is time critical and should run as fast as possible. Calculations involve mathematical operations with floating point numbers, simple additions, multiplications, divisions and a couple of square roots. Also includes a couple of 'if...; else if...; else...;' commands. Basically calculating some mathematical formula.

I changed project options to be the same as in the 2006 version (where they are the same, otherwise left default for release build), compiled for speed.

My question is: what is the possible reason (assuming the code is completely the same) and what might be a sollution? Is there a way to further optimise runtime performance through project options change?

I'm not looking for your suggestions for code optimisations, but for a reason the same code runs slower after compiled in C++ Builder 2009.

I'm open for your questions (for further explanations) and suggestions.

Thanks in advance.

Best regards...

 

[2ffat]

Which math library are you using? You may to use a more up to date library, esp. since you are using floating point math.



James P. Cottingham
[sup]I'm number 1,229!
I'm number 1,229![/sup]

 

[BoMi]

Thanks, 2ffat, for your response.

I use standard built in math library.
I might try some other libraries, if I find any.

But the question remains: why the same code runs slower now?
I guess they didn't update their math library to make it slower?

Best regards...

 

[2ffat]

Again, I think it has to do with the built-in libraries. C++ math libraries are pretty weak by default. Builder 2009 should have come with Boost and another library. Look through those and see if they have something that suits you better.

James P. Cottingham
[sup]I'm number 1,229!
I'm number 1,229![/sup]

 

[BoMi]

Actually, I should have been more specific about that math library I use. It is fastmath library standardly included in the C++ Builder. All routines are coded in assembly and stripped off of the most of the error checking utilities. So, I guess, it's very fast.

But, I have new info on the problem.
I did some testing and what I came up with is: integer arithmetic is about 7 times slower in 2009 than in 2006 (at least on my computer). So, my thinking is that something is wrong with the code performing integer arithmetic.

What's your opinion? Do you know where in the source integer arithmetic is located (like basic stuff: +, -, * and / operators)?

Best regards...

 

[johncp]

Hi Bomi

I am doing something very similar to you (complex number calulations) in CB2007 and I get 20-60ms (presumably variations are due to OS time slicing) for 12800 interations using math.hpp & compiling for debug (no fastmath) on an Intel dual core T7700.

Could your CBuilder FPU options be a factor. Under project options/compiler/Advanced compilation I have "floating point" set to fast floating point and optimisations set to 'none'.

Rgds John

 

[BoMi]

Hi johncp and thank you for your response!

Actually I tried many combinations of those options (thinking maybe they did something wrong with them), but those tries took me nowhere. And floating point calculations run fine (even faster than in 2006), integer arithmetic is the problem.
But, seeing you're doing some calculations too, then maybe you should try these options: optimizations -> generate fastest possible code, general compilation -> calling convention -> fastcall (register), besides ones you've already set. Actually, I always see the difference (in case of a very CPU intensive code) after I enable these options.
And fastmath library (fastmath.h) is definitely faster than standard one.

I tried many things to fix this issue of mine, but... so far no luck. I'll keep trying in spare time.

Again, thanks for the try, I really appreciate it.

Best regards...

 

[johncp]

Hi Bomi

Thanx for the advice. I tried using fastmath.h for sqrt & arctan functions. I set (in CB2007) advanced compilation/fastfloating point & optimisations/'for speed' & general compilation/'use register variables'. I didn't see any speed increase in a complicated routine iterating ldouble multiplication/div & floating point calculations on complex numbers & calling root & arctan functions in fastmath.
Presently my typical computation times of ~50ms are fine. Eventually I have to increase the interation number when I'll revisit your suggestions.

Regarding slow integer arithmetic I see the intel CPU has microcoded integer multiply and div, the FPU is structured for FP only. I wrote a v. simple program to repeatedly multiply ints a & * b and looked at the dissassembly. I got a single IMUL opcode performed in the CPU. I expect add/subtract also takes 3 opcodes

c = a* b ;
return 0 ;

00401BFC 8B4508 mov eax,[ebp+$08] //move dest,source
00401BFF F76D0C imul dword ptr [ebp+$0c] //IMUL Op Op=word: DX:AX:=AX*Op
00401C02 8945FC mov [ebp-$04],eax
speedtest.cpp.22: return 0;

Have you looked at you dissassembled code. ?

 

[BoMi]

Hi johncp,

yes, probably you have too few iterations for your CPU speed. If you set number of iterations higher and measure time you'll might be able to see improvement. But maybe not. For me it works nice. I saved that way around 50 or so miliseconds per iteration. I also set __fastcall to all my functions (as set in compiler options, but I just want to be sure), and also static if they're local. And many other stuff. Actually, when we speek of optimization, this would be a nice starting point:

http://www.azillionmonkeys.com/qed/optimize.html

Anyway, your suggestion to look up assembly is nice. I totally forgot about that possibility. Maybe assembly will show the possible problem. I'll try that out. Thanks.

Best regards...