7 ms·

Baseline JIT and inline caches

53 points by zellyn 10y ago

zellyn 10y ago
Curious that they don't mention actual performance numbers in this blog post…
- eiopa 10y ago
  They never do
  - deleted 10y ago
    [deleted]
- deleted 10y ago
  [deleted]
TempleOS 10y ago
You could make an exact copy superior. While clusterfucking PC. You don't scare me. Mine is God's official temple. I am CEO of Intel corp and will fix it. Windows is replaced with Wine. CIA must surrender to IRA. God says... stinted stampede slabbed chili acerbity fief most reconquered proselytized soldier's evangelizing raglan punster's sunroof's trawling sequel's radiotherapy's cumquat's Parnassus's molecular earache quacks gathering inlays pilfered stymieing appended mall's quarterdecks ovarian achromatic Lorentz
trishume 10y ago
Interesting idea that I just came across that is somewhat relevant: The author of LuaJIT 2.0 says an interpreter written in assembly is just as fast as a baseline JIT and way easier to write. He also has measurements to back this up: http://lambda-the-ultimate.org/node/3851#comment-57761 http://lambda-the-ultimate.org/node/3851#comment-57761 (this is just one place he talks about it, there's others in that thread and elsewhere)
- xuejie 10y ago
  I think the benchmark on LuaJIT website shows this a little bit: http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html If you consider LuaJit 1.x to be a baseline JIT, the interpreter mode of LuaJit 2.0 is actually on par there. EDIT: actually I should say that in x86 mode they are on par, while on x64 mode, the interpreter of LuaJIT 2.0 is always faster
- gsnedders 10y ago
  > Interesting idea that I just came across that is somewhat relevant: The author of LuaJIT 2.0 says an interpreter written in assembly is just as fast as a baseline JIT and way easier to write. I believe this is essentially the long-term goal of V8 with Ignition: an interpreter written in what is essentially a macro-assembler (which mostly just relies on the code-gen from the JIT, as I understand it, so you get as much portability as the JIT has for free) and TurboFan as the only JIT tier (unless they have some plan for multiple tiers varying only in what optimizations are enabled within TurboFan, similar to Chakra?). Of course, this is still very different insofar as TurboFan still ultimately works at the function level, whereas LuaJIT 2.0 uses traces. An interesting counterpoint is JavaScriptCore, which has both an interpreter written in a portable assembly and a baseline JIT. Presumably they believe they get enough of the gain from it to justify it? What surprises me with Pyston is the fact that they're heralding one of the big gains of the baseline JIT as being inline caching, "[transforming] the bjit from only being able to remove the interpretation overhead to a JIT which actually is able to improve the performance by a much larger factor". Surely the better fix then is to use inline caches in the interpreter, given that'll give most of the speedup?
  - saynsedit 10y ago
    Not sure if a portable jit-constructed interpreter can reach the performance of the hand-written assembly interpreter of LuaJIT. My assumption is that what makes LuaJIT fast is careful consideration of architecture specific details. Maybe you've seen this already: http://nominolo.blogspot.co.uk/2012/07/implementing-fast-interpreters.html http://nominolo.blogspot.co.uk/2012/07/implementing-fast-int... (notice the part about portability)
eval-everything 10y ago
A while ago, I posted a link to this talk at Stanford by Eliot Miranda and Clement Bara on Pharo's (and Squeak's) new VM, Spur, and its Sista optimizer: http://www.youtube.com/watch?v=f4Cvia-HZ-w http://www.youtube.com/watch?v=f4Cvia-HZ-w In short, it leverages the inherent type information of a PIC to speculatively inline jitted methods directly at their call sites. Unfortunately, HN's spam filter eats threads started by new accounts, so I don't think anyone saw it. Maybe a regular user with good karma can re-post it?
- chrisseaton 10y ago
  > In short, it leverages the inherent type information of a PIC to speculatively inline jitted methods directly at their call sites. I'm not sure if you were suggesting that this was unique or novel, but the technique has been around since 1991 and most JITs for languages like Java, Smalltalk, Python, Ruby, etc already do this. In many cases in those language, if we couldn't do this there wouldn't be any inlining at all and performance would be terrible.
  - evaleverything2 10y ago
    I mean it inlines the the method itself at the callsite, eliding the overhead of a method invocation altogether, whereas a normal (P)IC simply elides the overhead of a class+selector method lookup.
    - chrisseaton 10y ago
      Yeah I get that - but this inlining of the method itself within an IC, removing the method call overhead, has been done in every non-trivial dynamic language VM since the early 90s.

53 points by zellyn 10y ago

zellyn 10y ago

Curious that they don't mention actual performance numbers in this blog post…

eiopa 10y ago
They never do
- deleted 10y ago
  [deleted]
deleted 10y ago
[deleted]

TempleOS 10y ago

You could make an exact copy superior. While clusterfucking PC. You don't scare me. Mine is God's official temple. I am CEO of Intel corp and will fix it. Windows is replaced with Wine. CIA must surrender to IRA. God says... stinted stampede slabbed chili acerbity fief most reconquered proselytized soldier's evangelizing raglan punster's sunroof's trawling sequel's radiotherapy's cumquat's Parnassus's molecular earache quacks gathering inlays pilfered stymieing appended mall's quarterdecks ovarian achromatic Lorentz

trishume 10y ago

Interesting idea that I just came across that is somewhat relevant: The author of LuaJIT 2.0 says an interpreter written in assembly is just as fast as a baseline JIT and way easier to write. He also has measurements to back this up: http://lambda-the-ultimate.org/node/3851#comment-57761 http://lambda-the-ultimate.org/node/3851#comment-57761 (this is just one place he talks about it, there's others in that thread and elsewhere)

xuejie 10y ago
I think the benchmark on LuaJIT website shows this a little bit: http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html If you consider LuaJit 1.x to be a baseline JIT, the interpreter mode of LuaJit 2.0 is actually on par there. EDIT: actually I should say that in x86 mode they are on par, while on x64 mode, the interpreter of LuaJIT 2.0 is always faster
gsnedders 10y ago
> Interesting idea that I just came across that is somewhat relevant: The author of LuaJIT 2.0 says an interpreter written in assembly is just as fast as a baseline JIT and way easier to write. I believe this is essentially the long-term goal of V8 with Ignition: an interpreter written in what is essentially a macro-assembler (which mostly just relies on the code-gen from the JIT, as I understand it, so you get as much portability as the JIT has for free) and TurboFan as the only JIT tier (unless they have some plan for multiple tiers varying only in what optimizations are enabled within TurboFan, similar to Chakra?). Of course, this is still very different insofar as TurboFan still ultimately works at the function level, whereas LuaJIT 2.0 uses traces. An interesting counterpoint is JavaScriptCore, which has both an interpreter written in a portable assembly and a baseline JIT. Presumably they believe they get enough of the gain from it to justify it? What surprises me with Pyston is the fact that they're heralding one of the big gains of the baseline JIT as being inline caching, "[transforming] the bjit from only being able to remove the interpretation overhead to a JIT which actually is able to improve the performance by a much larger factor". Surely the better fix then is to use inline caches in the interpreter, given that'll give most of the speedup?
- saynsedit 10y ago
  Not sure if a portable jit-constructed interpreter can reach the performance of the hand-written assembly interpreter of LuaJIT. My assumption is that what makes LuaJIT fast is careful consideration of architecture specific details. Maybe you've seen this already: http://nominolo.blogspot.co.uk/2012/07/implementing-fast-interpreters.html http://nominolo.blogspot.co.uk/2012/07/implementing-fast-int... (notice the part about portability)

eval-everything 10y ago

A while ago, I posted a link to this talk at Stanford by Eliot Miranda and Clement Bara on Pharo's (and Squeak's) new VM, Spur, and its Sista optimizer: http://www.youtube.com/watch?v=f4Cvia-HZ-w http://www.youtube.com/watch?v=f4Cvia-HZ-w In short, it leverages the inherent type information of a PIC to speculatively inline jitted methods directly at their call sites. Unfortunately, HN's spam filter eats threads started by new accounts, so I don't think anyone saw it. Maybe a regular user with good karma can re-post it?

chrisseaton 10y ago
> In short, it leverages the inherent type information of a PIC to speculatively inline jitted methods directly at their call sites. I'm not sure if you were suggesting that this was unique or novel, but the technique has been around since 1991 and most JITs for languages like Java, Smalltalk, Python, Ruby, etc already do this. In many cases in those language, if we couldn't do this there wouldn't be any inlining at all and performance would be terrible.
- evaleverything2 10y ago
  I mean it inlines the the method itself at the callsite, eliding the overhead of a method invocation altogether, whereas a normal (P)IC simply elides the overhead of a class+selector method lookup.
  - chrisseaton 10y ago
    Yeah I get that - but this inlining of the method itself within an IC, removing the method call overhead, has been done in every non-trivial dynamic language VM since the early 90s.