In quite a few of my more recent programs, I've been using basic calculus to replace if
statements such as in a for
loop I've used:
pos = cbltSz*(x-1)
to get the position of a small cube relative to a large one rather than saying something like if(x == 0){pos = -cbltSz}
. This is more or less to neaten up the code a little bit. But it got me thinking. To what extent would using maths out-perform pre-defined statements/ functions? and how much would it vary from language to language? This is assuming that my maths used is preferable to the alternative in a way other than aesthetic.
Should Maths Generally Be Used Over Other Functions/ Statements
45 views Asked by Damon Jenkins AtThere are 3 answers
Note that your statements pos = cbltSz*(x-1)
and if(x == 0){pos = -cbltSz}
are not equivalent if x
is non-zero: the first sets pos
to some definite value while the second leaves it to its previous value. The significance of this difference depends on the rest of your program. The two statements also differ in clarity--the second expresses your purpose better and the first does not "neaten up the code a little bit". In most programs, improved clarity is more important than a slight increase in speed.
So the answer to your question depends on too many factors to get a full answer here.
What most early programming language designers didn't understand, and many still don't understand, is that mathematical functions are a bit different from user-defined functions. If we've done any trig at all, we all know what sin(PI/8) is going to mean,and we're happy embedding the class in expressions like
rx = cos(theta) * x - sin(theta) * y;
But functions you write yourself are only seldom like basic mathematical functions. They take several parameters, they return several parameters, it's not usually quite clear what they do. The last thing you want is to embed them in complicated expressions.
Secondly, maths has its own system of notation for a reason. The cut down, ascii-only system of a programming language breaks down as soon as expressions go above a certain low complexity. (I use the rule of three, three levels of nested parentheses are all your user can take in). And, without special programming support, programming functions cannot escape their domain.
pow(sqrt(-1), sqrt(-1));
won't do what you want unless you have a complex math library installed.
As for performance, some Fortran and C compilers optimise mathematical routines very aggressively, with constant propagation and the like. Others won''t. It just depends.
Modern CPUs have deep pipelines, so that a branch misprediction may come at a considerable performance impact. On the other hand, they tend to have considerable floating-point computation power, often being able to perform multiple floating-point operations in parallel on different ALUs. So there might be a performance benefit to this approach. But it all depends. If the application is already doing a lot of number crunching, the ALUs might be saturated. If the branch predictor does a good job, branch mispredictions may be rare in many applications.
So I'd go with the usual rules for optimizations: don't try to hand-optimize everything. Don't optimize at the cost of readability and maintainability. If you have a performance bottleneck, identify the hot portions of your codebase and consider alternatives for those. Try out alternatives in benchmarks, because theoretic considerations only get you so far.