Why is my Scala tail-recursion faster than the while loop?

Question

Here are two solutions to exercise 4.9 in Cay Horstmann\'s Scala for the Impatient: \"Write a function lteqgt(values: Array[Int], v: Int) that returns a triple containing the co

Answer 1

The two constructs are not identical. In particular, in the first case you don't need any jumps (on x86, you can use cmp and setle and add, instead of having to use cmp and jb and (if you don't jump) add. Not jumping is faster than jumping on pretty much every modern architecture.

So, if you have code that looks like

if (a < b) x += 1

where you may add or you may jump instead, vs.

x += (a < b)

(which only makes sense in C/C++ where 1 = true and 0 = false), the latter tends to be faster as it can be turned into more compact assembly code. In Scala/Java, you can't do this, but you can do

x += if (a < b) 1 else 0

which a smart JVM should recognize is the same as x += (a < b), which has a jump-free machine code translation, which is usually faster than jumping. An even smarter JVM would recognize that

if (a < b) x += 1

is the same yet again (because adding zero doesn't do anything).

C/C++ compilers routinely perform optimizations like this. Being unable to apply any of these optimizations was not a mark in the JIT compiler's favor; apparently it can as of 1.7, but only partially (i.e. it doesn't recognize that adding zero is the same as a conditional adding one, but it does at least convert x += if (a into fast machine code).

Now, none of this has anything to do with tail recursion or while loops per se. With tail recursion it's more natural to write the if (a < b) 1 else 0 form, but you can do either; and with while loops you can also do either. It just so happened that you picked one form for tail recursion and the other for the while loop, making it look like recursion vs. looping was the change instead of the two different ways to do the conditionals.