Hugh Wimberly wrote: ...
I don't understand how not using exceptions allow better efficiency.
If you want to detect the error, you have to make a test in both cases.
I think I was confusing myself. Arithmetic errors aren't handled using exceptions, so code like try { ... } catch (Exception e) {throw DivideByZero} won't work if the try block contains just the division algorithm. I was thinking of comparing the above code to if (d == 0) throw DivdeByZero; else { ... } Which would be less silly and more efficient, but I have seen the former, especially in Java. In this case, I think I'm supposed to be comparing the second example to something that doesn't check for or throw errors at all, which seems like a bad practice to me, but is how ordinary integer operations are handled. Right? Am I still crazy?
In my experience, at least with earlier versions of MSVC under Windows, using a floating point math error handler to generate C++ exceptions improved performance of our RK5 integrator by >40% versus doing the divide by zero check in the inner loop. Also you wouldn't put the try catch block inside that inner loop, it is at the executive level, determining whether the overal operation completed, or failed. This is where the decision is made to decrease step size, or carry out some other operation. Actually that 40% was the overall frame time improvment, the time spent in the integrator was even less. Jeff Flinn