Phil Hassey - game dev blog
Phil Hassey as Syndrome
"Look, stores don't sell
costumes like this to just anyone."

Exceptions and various compilation option speeds

So after some discussion yesterday with a few folks about Exceptions in C++, I decided to add a compilation flag to disable the use of exceptions in tinypyC++.  The claim given to me was around these few items: 1. Exceptions slow your code down.  2. Exceptions aren’t cross-platform (in some cases).  3. Exceptions can easily add in memory-leaks.

I can’t argue with #2, although it’s not completely relevant for the platforms I’m targeting right now.  #3, with the way tinypyC++ does reference counting, I wouldn’t be surprised if this could happen.  #1, I figured might be true, but I wanted to know how real #1 actually was.  So here are my results:

g++ flags ms
(none) 894
-g 891
-O3 414
-DTP_NO_THROW -fno-exceptions 894
-g -DTP_NO_THROW -fno-exceptions 878
-O3 -DTP_NO_THROW -fno-exceptions 378

In the first test I’m rendering a Julia fractal for 20 frames and averaging the time it takes to render. In the second test (below) I’m doing the same test, but I did one code optimization to remove a new/delete that was happening for each pixel – by reusing the coordinates object.

g++ flags ms
(none) 293
-g 290
-O3 153
-DTP_NO_THROW -fno-exceptions 304
-g -DTP_NO_THROW -fno-exceptions 303
-O3 -DTP_NO_THROW -fno-exceptions 112

I found it interesting that in the 2nd test case I did, removing exceptions actually increased the time it took to render the fractal!  Not quite sure why .. hmmm.  (I tried it a few times and kept getting similar results too.)

What is clear in the second test is that the compiler is able to optimize the code much more aggressively.  I guess Exceptions choke up the optimizer.  In all cases it seems that adding on the -g flag seems to make the code run slightly faster, surprisingly enough!  (-g adds in debugger info.)  In all cases, the optimizer was able to roughly double the speed of the program, and when I disable exceptions it is able to throw in even more speed.

-Phil

6 Responses to “Exceptions and various compilation option speeds”

  1. Sol_HSA Says:

    I don’t quite follow your conclusions.. based on your data, dropping the exceptions speeds things up. Or are you referring to the speed of the debug builds? Who cares? =)

  2. philhassey Says:

    A few of us chatted about this in #LD yesterday, and I tried a few more things, some of my observations there could just be ’rounding’ errors, actually.

    But the bottom line is, removing exceptions gives real gains when you compile with -O3. ~20% gain is the average of the two cases.

  3. Rene Dudfield Says:

    hey ya,

    Another speed up used to be disabling rtti with -fno-rtti Also try -ffast-math if you’re not using it already.

    I guess one conclusion from your results could be memory management is important for speed. Since removing that one ‘new’ gave the best speedup. Removing allocations at run time often gives nice speedups 🙂

    cya.

  4. philhassey Says:

    -fno-rtti and -ffast-math didn’t see to make a discernible difference.

    I should do a comparison to a pure-C implementation, but I don’t really expect to be able to make it much faster than it is.

  5. philhassey Says:

    A pure-C implementation does 75ms vs. 115ms. Which seems pretty close considering the extra hoops tinypyC++ does to get in ref counting and other syntax niceties.

  6. Rene Dudfield Says:

    ah ok. Maybe it only makes a difference if you have a lot of classes defined. The main benefit of fno-rtti is supposed to be less memory usage.

    That’s VERY cool to get within that close of C 🙂