I just recently upgraded[1] a JIT that essentially compiled each bytecode separately to one that shares registers within the same basic block. Easy 40 percent improvement to runtime, as expected.

But something I hadn't expected was it also improved compilation time by 40 percent too (fewer virtual registers made for much faster register allocation).

[1] https://github.com/ZQuestClassic/ZQuestClassic/commit/68087d...

Yeah, I expect the real advantage of a JIT is that you can perform proper register allocation and avoid a lot of stack and/or virtual register manipulation.

I wrote a toy copy-patch JIT before and I don't remember being impressed with the performance, even compared to a naive dispatch loop, even on my ~11 year old processor.

Turns out one of the classic papers on this is available for those interested in this discussion - https://news.ycombinator.com/item?id=45582127

Those operating systems allow it, but Apple does not. Agree that it is a total waste.

They allow, but Apple's policy is to lock down that ability pretty much just to Safari/WKWebView. If you could transpile/compile your program to JS or WASM and run it through one of these blessed options, it should get JIT'ted.

They do, technically, allow JIT. You need a very hard-to-obtain entitlement that lets you turn writable pages into executable read-only pages, and good luck getting that entitlement if (for some reason) your name isn’t “mobilesafari”, but the capability exists.

What advantage does JIT compilation have over Swift or Obj-C?

Of course they do - this is how javascript in any site works

> that you cant even use fully because of decisions like this.

Have no clue what this means - you can pre-compile for target platforms and therefore "fully" use whichever Apple device CPU.

Speculative execution does not require out-of-order execution. When you predict a branch, you're speculatively executing the predicted branch. Whether you're doing it in the same order as instruction order or out of order is independent of that.

Essentially all microarchtectural state is fodder for side channel exploits.

Static branch prediction like "predict taken if negative branch offset" doesn't leak anything, but just about any dynamically updated tables will (almost tautologically) contain statistical information about what was executed recently.

As I noted in another comment, I would like to persuade you that this is not the right take-away..

You run into the same problem a CPU does: if you have dependencies between the instructions, you can't execute ahead of time. Your processor has a bunch of hardware to efficiently resolve conflicts but your interpreter does not.

Depending on the bytecode, instructions might be variable-length, which means that you need to execute a nontrivial amount of logic to fetch more than just the next bytecode or handler. That said, I tinkered with adding a prefetch to Wizard's interpreter which basically moves the load of the next handler from the dispatch at the end to the first thing in the handler, and saw something like a 5% improvement.

The thing you're suggesting makes sense, but it's far more efficient to do in hardware. You might say that you could do it on one of the many cores available on your modern processor, but it turns out that synchronizing them to your main thread is really inefficient -- and anyway, they're busy running your HN browser threads and your YouTube music video.

The paper is 10 years old. While the gap between a threaded an interpreter (a dispatch at the end of every handler) versus non-threaded (loop over switch) isn't as big as it used to be, it's still 15-30% on modern very fast interpreters. For example, I measured between 14 and 29% performance improvement for threading Wizard's interpreter[1].

[1] https://dl.acm.org/doi/10.1145/3563311