While I haven't personally reviewed any of his code and anything is possible.
This professor is pretty sharp from what I could tell.
Still even giving away 2 orders of magnitude that is still a remarkable difference in performance.

 

Ahhh... You mean like threaded-code. Sometimes I look at the output of the C++ compiler and every other instruction is a "call" instruction. So even in the native compiled code there is a lot of jumping around to slow things down.

Anyway, here is a technique from the hardware side that can be applied to the JVM. Let's say the code is coming to a conditional branch, and we don't know in advance which way the branch is going to go (it is still waiting for the branch condition to be computed). What the HW does is to fire off two threads, one executing the true path and the other executing the false path. Once the branch condition is determined, the "good" thread is "committed" and the "bad" thread is killed. For the JVM, it could fire off two threads and start executing both paths simultaneously and then committ to the good one later. This can take advantage of multiple cores. Of course, you can extrapolate this and quickly deduce that given the frequency of conditional branches in today's code, starting two paths will quickly "branch" out to many paths and suck up all available cores. Just a thought.