2 ms·

Chris, JSC’s IRs have extensive support for accessing non local callframes and doing a great job on effects generally. JS has _lots_ of this kind of nonsense in

Chris, JSC’s IRs have extensive support for accessing non local callframes and doing a great job on effects generally. JS has _lots_ of this kind of nonsense in real code and the language supports it at least as much as Ruby does (like in super evils ways, like function.arguments). JSC has extensive support for fast calls into native code because of the DOM. For example we have the Snippet JIT that allows the DOM to turn hot functions into almost first class compiler ops. Like, callbacks in the DOM can dictate codegen and effect analysis. Josh, the canonical JSC approach to the iterator callback problem wouldn’t be to use builtins. That wouldn’t necessarily achieve great perf. It’s certainly not great for the baseline tier. I think the only good option is to make those iterators (like Array#each) be intrinsic as fuck: all call ICs can ask for inline machine code generation of the loop along with the call back to the passed in block. You could imagine this enabling inlining of the loop and its body even in the baseline JIT. I get that people probably see the builtins in JSC and start having wild fantasies about what this can achieve. In reality for things where perf matters, you deploy ICs and custom template codegen.

jashmatthews 7y ago
I think the problem with the intrinsics approach is that lots of this code isn't stdlib but extensions like: https://github.com/ged/ruby-pg/blob/6853309b64852755daed3e9c24e11de13b4c77a4/ext/pg_result.c#L1272 https://github.com/ged/ruby-pg/blob/6853309b64852755daed3e9c... I don't really see a good solution here other than lifting the control flow to Ruby with specific bytecode ops to minimize overhead and a good, typed FFI like LuaJIT has? Am I missing something?
- pizlonator 7y ago
  Could establish an interface for those extensions to participate in the JIT and ICs. JSC does that for the DOM. Other than that just try to make calls into JITed code as fast as possible. But that needs to be the backup plan, with the main plan being that perf-sensitive extensions play with the JIT.
  - chrisseaton 7y ago
    But we have no control over these C extensions. And there's a huge corpus of existing C extensions that need to keep working. 500 million lines of C and C++, in fact, even for just the publicly available code. And by the way - there isn't really any proper interface at all! There's just basically the whole internals of the C Ruby implementation exposed to C extension authors. There's no abstraction with handles and things like that. There was an effort at one point to get C extension authors to use the FFI instead, and a JNI-style API to permit a moving garbage collector was proposed, but these approaches weren't successful in gaining any momentum. All in all... that's why we don't just do it the JavaScriptCore way. We have different constraints to yours.
    - pizlonator 7y ago
      You don’t need to make all native extensions fast. You need to make some of the most common things fast and keep the rest of them working. It’s fine if not all extensions adopt a JIT interface. The thing about moving GC is a red herring. Ruby wouldn’t benefit from it. JSC doesn’t use moving GC.

jashmatthews 7y ago

I think the problem with the intrinsics approach is that lots of this code isn't stdlib but extensions like: https://github.com/ged/ruby-pg/blob/6853309b64852755daed3e9c24e11de13b4c77a4/ext/pg_result.c#L1272 https://github.com/ged/ruby-pg/blob/6853309b64852755daed3e9c... I don't really see a good solution here other than lifting the control flow to Ruby with specific bytecode ops to minimize overhead and a good, typed FFI like LuaJIT has? Am I missing something?

pizlonator 7y ago
Could establish an interface for those extensions to participate in the JIT and ICs. JSC does that for the DOM. Other than that just try to make calls into JITed code as fast as possible. But that needs to be the backup plan, with the main plan being that perf-sensitive extensions play with the JIT.
- chrisseaton 7y ago
  But we have no control over these C extensions. And there's a huge corpus of existing C extensions that need to keep working. 500 million lines of C and C++, in fact, even for just the publicly available code. And by the way - there isn't really any proper interface at all! There's just basically the whole internals of the C Ruby implementation exposed to C extension authors. There's no abstraction with handles and things like that. There was an effort at one point to get C extension authors to use the FFI instead, and a JNI-style API to permit a moving garbage collector was proposed, but these approaches weren't successful in gaining any momentum. All in all... that's why we don't just do it the JavaScriptCore way. We have different constraints to yours.
  - pizlonator 7y ago
    You don’t need to make all native extensions fast. You need to make some of the most common things fast and keep the rest of them working. It’s fine if not all extensions adopt a JIT interface. The thing about moving GC is a red herring. Ruby wouldn’t benefit from it. JSC doesn’t use moving GC.