Deep Dive into PHP 8's JIT

Re:Deep Dive into PHP 8's JIT by aardvark179 on Sunday August 30, 2020 @10:33AM (#24323220)

It’s not that the JIT gets confused, it’s that the C APIs for these languages can do almost anything - even stuff that you can’t normally do in the language. So you are faced with a giant optimization boundary.

However a call to a shared library that isn’t linked against your language API is not very expensive as you have a much better handle on the values that are escaping and can make much better optimization choices.

In the Truffle project we are using an LLVM bitcode interpreter that allows us to JIT right through that language boundary and still link to native shared libraries. This means people shouldn’t have to rewrite their C extensions and we can hopefully still run the combination of high level language and C extension faster.

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by jashmatthews on Tuesday September 01, 2020 @03:28AM (#24339361)

That optimization boundary seems like it's much more of a problem for TruffleRuby than it is for language-specific native implementations? IIRC TruffleRuby relies a lot on being able to optimize away Ruby objects and frames and there's quite a performance cliff if you have to materialize full escaping objects?

JSC and LuaJIT have simpler ways to deal with calling native code which might do weird stuff.

[ Parent | on HN ]