Patrick (patrickwonders) wrote,

JIT Outrage and Lazy Dogma

For maybe obvious reasons, I've been thinking a great deal this week about the strong opinions people form on very little information. Even worse, people tend to fixate on a subset of the limited information they have available while actively ignoring the rest.

JIT Compilers

A number of modern computer languages have what are called Just In Time compilers, aka JIT compilers. With JIT compilers, a human writes source code in a human-readable form. There is usually then an initial compilation stage which does some simple validation and transforms it into a form suitable for interpretation by an idealized, imaginary computer. At some later point in time, the transformed version of the code is executed on an actual, real, live computer. The Just In Time compiler takes the transformed version for an idealized computer and turns it into actual code for this specific type of computer. With some super-fancy JIT compilers, the first cut at this is very basic with some modest assumptions as to how the code will be used. As the same pieces of code are run over and over again, a super-fancy JIT compiler might recompile the code with new assumptions (based upon past-usage) as to how the code will be used so that the code can be as streamlined as possible for the most-frequent or most-costly cases.

For systems without a JIT compiler, one of two approaches is taken. Some systems take the human-written source code and transform it for an idealized, imaginary computer and later emulate the imaginary computer using your actual, real, live computer. Other systems take the human-written source code and immediately transform it the whole way into code for your actual, real, live computer.

Those systems which emulate the imaginary computer sacrifice speed. Your computer cannot emulate the idealized computer nearly as fast as it could run its own stuff.

Systems which compile directly for the real, live computer sacrifice adaptability since they can only be run on computers which are almost identical (in hardware and operating system) to the one for which they were compiled.

Either way, without a JIT compiler, there is never an opportunity to revisit the initial assumptions about how the code would be used. Any optimization has to be done up front before the code is ever run.

As a real-world example, suppose that I have decided to write all of my email in Esperanto from now on. You might set up a filter on your mail-reader that invokes a translator when it goes to display any message from me so that you can read it in Klingon rather than Esperanto. This is Just In Time translation. The message sits in your Inbox in Esperanto. When you read it, it is transformed into Klingon. If, later, you decide that your preferred language is Elvish, you just have to re-open the message to get it in Elvish instead. The alternative, not-Just In Time version would be that I have the filter set up on my end so that when I write a message to you, it gets translated into Klingon before it gets sent. It sits in your Inbox in Klingon. Even after you've moved on to Elvish, that message will be in Klingon.

Lazy Evaluation

Most programming languages have an Eager evaluation model. With an Eager evaluation model, you can safely pretend that when you see multiple function calls in a row, the functions will be called in that exact order. For example, in the following code, the function foo() would definitely be called before the function bar().

   y := foo();
   x := bar();
   return pair(x,y);

With a Lazy evaluation model, when you see a call to a function, all you are really seeing is a promise to call that function if its value is every actually needed. As such, in the code snippet above, if there is something that foo() does with the global state of the program that bar() requires be done before it is invoked, you might end up out of luck. The model hasn't guaranteed the order these two functions will be called.

As a real-world example, imagine that you tell me to subtract the year Hannibal crossed the Alps from the year Madonna won her first Grammy Award and then write down my favorite color. I might search Google to find out when Hannibal crossed the Alps and when Madonna won her first Grammy Award. I might search for either one first. I might just write down my favorite color and not bother subtracting anything. I have done Lazy evaluation. If I were doing Eager evaluation, I would have had to look up when Hannibal crossed the Alps before I could even consider the question of when Madonna won her first Grammy Award and I would have to do the subtraction before I even considered what I should write down as my favority color.

I like to think of Just In Time compiling as lazy evaluation of the make me a version for my actual, real, live computer function. You don't actually need code that can be run on an actual, real, live computer until you are really, truly, about to run the code on an actual, real, live computer. If no one ever runs that code, there is never a need to compile it.


When do we form opinions? Are our opinions pre-compiled or compiled Just In Time? Are our opinions evaluated Eagerly or Lazily? At what point do we need an opinion?

Is the strength of our opinion correlated to the strength of the evidence we possess? Is our opinion taking into account how it is actually going to be used in this situation, or is it based on modest assumptions on how opinions are generally used?

Certainly, before flaming someone online, we have to have formed an opinion. Was it a Lazy opinion where we decided to comment and used all of the available information to form the opinion? Was it an Eager opinion where the opinion was already formed well before it was needed for this comment?

I, personally, have almost no drive whatsoever to flame someone online. As such, when the question is Should I respond (with vitriol) to this blog post or comment?, I never need to try to calculate an opinion. When I do try, I find that I'm stretching my opinion over shockingly wide gaps in the landscape to try to make very sparse evidence cover very large ground.

I have been realizing this past week though, that I do calculate opinions early and on little information on other questions like Should I go to this event? or Do I want to talk to this person? I close many doors with barely a glance as to what's behind them.

It is time to flush the caches. It is time to recompile the routines that were compiled with very little information on how they'd actually be used.

  • Post a new comment


    default userpic

    Your reply will be screened