(jit/jitable (fn []))

Small callable Janet Jit. You tell the jit what functions to compile and it compiles them on next call. The jit makes a huge number of assumptions, so the jit is not theright choice in all cases.

Right now it only target System V x86 with nanboxed janet values. I would love to support ARM and Janet without nanboxed, but haven't doneso yet.

(defn lerp
  [a b t]
  (+ a (* t (- b a))))
(def lerp-jit (jit/jitable lerp))

(lerp-jit 1 20 0.3) # call just like usual, but will compile to binary on first call.

experimental / educational

jit.c can be used directly in your project via jpm,

(declare-project :name "my project")
(declare-native :name "jit" :source @["jit.c"])

You can then build it with,

jpm build

Run the tests with,

janet test/test-asm.janet
janet test/test-fns.janet

$ jpm build && janet benchmarks/microbench.janet

I believe the next big performance boost for larger functions will be inlining.

Jit generated code has less strict garantees about correctness and errors than the interpreter. It expects that you to pass it correct numeric focused code.

In Janet, (+ "hi" 1) raises an error. This JIT that should be treated as undefined behavior. On my machine this returns "hi", but that may change at any time.

This also applies to defining your own operators. writting,

(def addable
  @{
    :+ (fn [x y] (print x " " y))
   })
(+ addable 10)) # prints #<table> 10

works in the interpreter, but should be considered undefined behavior in the JIT.

There are also a number of operations the VM can do that the JIT today does not support. They mostly have to do with VM state and probably make bad candidates for the JIT anyways. Today the list of unsupported ops is:

• (ldu) load up value
• (setu) set up value
• (res) resume
• (sig) signal
• (prop) propagate
• (clo) closure

Operations that fall back to the interpreter, will use the JIT:

• push
• type check
• next
• call
• in
• get
• getindex
• set
• setindex
• length
• make array
• make tuple
• make buffer
• make string
• make table
• make struct

Using these operators can slow down jitted functions, but should work as expected.

• Calling out of the JIT uses janet_call which means GC will not run. This can be a benefit, or a mistake depending on the application. Calls also have a ~10% performance penalty. If you need to leave the JIT a lot, you won't have very good JIT performance.

• tailcalls are just normal calls, so you can get stack depth issues you otherwise wouldn't get.