Ruby 2.6.0-preview2 released with JIT • Hacker News Board

Re: Ruby 2.6.0-preview2 released with JIT

#121

Post by jashmatthews » Mon, Jun 04, 2018, 1:47 PM UTC

vinceguidry wrote: post #118

jashmatthews wrote: post #114

Earlier quoted context omitted.

ActiveSupport also monkey-patches to_json with a recursive Ruby function, completely nerfing JSON performance by 50x in a lot of cases. Unfortunately, it's what makes 'render json: @model' just... work.

Any time I personally ever want to generate JSON in Ruby, I want recursive tree traversal. It's just too painful to expect primitive types on everything. You'd have to pay that 50x doing it explicitly with a recursive function before you turn it into JSON anyway. Ideally, you'd serialize directly from the database, bypassing the application entirely. Easily doable in ActiveRecord, but it's an explicit action, not the…

It's not required at all! Rails adds a completely avoidable massive overhead because of the way it overrides to_json see: https://twitter.com/jashmatthews/status/967423661908070401

Re: Ruby 2.6.0-preview2 released with JIT

#122

Post by vinceguidry » Mon, Jun 04, 2018, 2:22 PM UTC

jashmatthews wrote: post #121

vinceguidry wrote: post #118

Earlier quoted context omitted.

Any time I personally ever want to generate JSON in Ruby, I want recursive tree traversal. It's just too painful to expect primitive types on everything. You'd have to pay that 50x doing it explicitly with a recursive function before you turn it into JSON anyway. Ideally, you'd serialize directly from the database, bypassing the application entirely. Easily doable in ActiveRecord, but it's an explicit action, not the…

It's not required at all! Rails adds a completely avoidable massive overhead because of the way it overrides to_json see: https://twitter.com/jashmatthews/status/967423661908070401

Have you ever used Ruby's JSON.dump? The second it runs into anything that it can't convert, you get "#" everywhere in your output.

Re: Ruby 2.6.0-preview2 released with JIT

#123

Post by foldr » Mon, Jun 04, 2018, 2:52 PM UTC

jashmatthews wrote: post #113

foldr wrote: post #112

Earlier quoted context omitted.

I'm not saying that MJIT (or whatever implementation) will never be fast. I'm just saying that in general, it is not trivial to get performance improvements by writing a JIT. My original comment said nothing about Ruby.

This is simply not true. You're massively underestimating the overhead of a bytecode VM. Even the most optimal bytecode VMs are easily beaten by the simplest of JITs in 100 lines of C: https://arxiv.org/pdf/1604.01290.pdf Code doesn't even need to be "hot" to make it worth it. WebKit switches from interpreter to cheap baseline compilation, without an specular optimizations or type information, after only 6 calls of a…

It's not clear to me why you think that the linked article shows that naive JITs perform better across-the-board than well-written bytecode interpreters. The reported speed improvement from JIT itself is a mere 2.3x, and the listed benchmarks mostly involve numerical code, where JIT tends to be effective.

Relevant post here:

https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/

A simple JIT can get you to the point where you reliably outperform a bytecode interpreter for certain types of code. What takes a lot more engineering effort is reliably performing at least as fast as a bytecode VM for all types of code.

Re: Ruby 2.6.0-preview2 released with JIT

#124

Post by jashmatthews » Mon, Jun 04, 2018, 3:13 PM UTC

vinceguidry wrote: post #122

jashmatthews wrote: post #121

Earlier quoted context omitted.

It's not required at all! Rails adds a completely avoidable massive overhead because of the way it overrides to_json see: https://twitter.com/jashmatthews/status/967423661908070401

Have you ever used Ruby's JSON.dump? The second it runs into anything that it can't convert, you get "# " everywhere in your output.

Of course! We use Oj.dump in Rails compatibility mode in production at ChartMogul.

Re: Ruby 2.6.0-preview2 released with JIT

#125

Post by holstvoogd » Mon, Jun 04, 2018, 3:28 PM UTC

sho wrote: post #21

> We’re going to implement method iniling in JIT compiler, which is expected to increase Ruby’s performance in order of magnitude An order of magnitude as in .. 10x? This seems too good to be true. Half the arguments against Rails melt away like butter if that's truly the case. Anyone with a better understanding of the details care to comment on the likelihood of these performance gains being actually realised, and i…

Just spun up my ridiculously heavy rails app and did a quick test with one of the more cpu-intensive actions and see no evidence of any improvement at all. If anything, it was a bit less predictable. This little test was nowhere near an actual benchmark, but I wouldn't hold my breath.

Test suite still passes on it though, so upgrading shouldn't be a huge deal at least へ‿(ツ)‿ㄏ

Re: Ruby 2.6.0-preview2 released with JIT

#126

Post by jashmatthews » Mon, Jun 04, 2018, 4:01 PM UTC

foldr wrote: post #123

jashmatthews wrote: post #113

Earlier quoted context omitted.

This is simply not true. You're massively underestimating the overhead of a bytecode VM. Even the most optimal bytecode VMs are easily beaten by the simplest of JITs in 100 lines of C: https://arxiv.org/pdf/1604.01290.pdf Code doesn't even need to be "hot" to make it worth it. WebKit switches from interpreter to cheap baseline compilation, without an specular optimizations or type information, after only 6 calls of a…

It's not clear to me why you think that the linked article shows that naive JITs perform better across-the-board than well-written bytecode interpreters. The reported speed improvement from JIT itself is a mere 2.3x, and the listed benchmarks mostly involve numerical code, where JIT tends to be effective. Relevant post here: https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ A simple JIT can get you to the poi…

MJIT is completely different to PyPy. Their problems are simply not relevant to MJIT. MJIT is already just as fast as standard CRuby when executing complex Rails code, minus the small overhead for JIT compilation: http://engineering.appfolio.com/appfolio-engineering/2018/3/...

PyPy is a much more ambitious design, completely replacing CPython, and using an unusual JIT scheme of tracing the interpreter itself and trying to produce an interpreter optimized for particular traces of your code.

It was much harder for that approach to reach the same level of general performance than it seems to have been for CRuby & MJIT.

Re: Ruby 2.6.0-preview2 released with JIT

#127

Post by onli » Mon, Jun 04, 2018, 4:21 PM UTC

pjmlp wrote: post #120

onli wrote: post #119

Earlier quoted context omitted.

That's Oracle propaganda. Sun was perfectly happy with Google using Java and the free entry into the mobile market they got from that. See https://www.zdnet.com/article/a-google-android-and-java-hist... , https://www.zdnet.com/article/sun-ceo-explicitly-endorsed-ja... .

That is Google propaganda. Sun did what they could to save their face. "Triangulation 245: James Gosling" https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be... Also doesn't change the fact that even with Android 8.1, I as Java developer cannot take a random jar from Maven Central and be certain it won't crash and burn on Android, regardless of the version.

Good link.

But I don't see how you can tolerate that contradiction. Either you agree with Oracle that the Java APIs were copyrighted and Google should not have been allowed to reconstruct them. Or you worry about fragmentation coming from an incompatible Java implementation. Doing both is nonsensical.

Re: Ruby 2.6.0-preview2 released with JIT

#128

Post by pjmlp » Mon, Jun 04, 2018, 5:57 PM UTC

onli wrote: post #127

pjmlp wrote: post #120

Earlier quoted context omitted.

That is Google propaganda. Sun did what they could to save their face. "Triangulation 245: James Gosling" https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be... Also doesn't change the fact that even with Android 8.1, I as Java developer cannot take a random jar from Maven Central and be certain it won't crash and burn on Android, regardless of the version.

Good link. But I don't see how you can tolerate that contradiction. Either you agree with Oracle that the Java APIs were copyrighted and Google should not have been allowed to reconstruct them. Or you worry about fragmentation coming from an incompatible Java implementation. Doing both is nonsensical.

What contradiction?

Google should have paid Sun instead of playing a Microsoft's move fostering Sun's downfall, period.

And in doing so, Android would have been JavaSE compliant plus whatever additional libraries they would think to drop on top of it.

Re: Ruby 2.6.0-preview2 released with JIT

#129

Post by onli » Mon, Jun 04, 2018, 6:12 PM UTC

pjmlp wrote: post #128

onli wrote: post #127

Earlier quoted context omitted.

Good link. But I don't see how you can tolerate that contradiction. Either you agree with Oracle that the Java APIs were copyrighted and Google should not have been allowed to reconstruct them. Or you worry about fragmentation coming from an incompatible Java implementation. Doing both is nonsensical.

What contradiction? Google should have paid Sun instead of playing a Microsoft's move fostering Sun's downfall, period. And in doing so, Android would have been JavaSE compliant plus whatever additional libraries they would think to drop on top of it.

How do you come to the idea that having more Java devices available, even if not 100% compatible, would have in any way caused harm to Sun? And then even that much that it killed the company?

On top of that, I don't see for what google would have had an obligation to pay.

Contradiction: Google broke some imaginary copyright by re-implementing APIs, but Google is bad because the re-implementation was not 100% equal to the original causing fragmentation. Either the fragmentation was harmful, then the API copyright was the problem. Or the API copyright violation was the problem, then fragmentation was the explicit goal and Google's try to minimize it the problem. Both can't be true at the same time outside lawyer lala land.

Re: Ruby 2.6.0-preview2 released with JIT

#130

Post by ychen306 » Mon, Jun 04, 2018, 6:38 PM UTC

tbodt wrote: post #13

blattimwind wrote: post #4

> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e. Oh dear god.

What's the advantage over using LLVM's built-in JIT, or PyPy's JIT, or generating machine code directly, or anything else that doesn't have the overhead of spawning processes for compiling and linking? One of the goals listed is minimizing the JIT compilation time.

LLVM's JIT is in a sense different from that of, say, PyPy. It's more primitive. When people talk about JIT in the context of LLVM, they mean the set of APIs provided by LLVM's library. That is, give it a set of IR functions, and things they depend on, the library dynamically compiles and links them for you. More concretely, for example, given the IR of a function, it gives you a raw pointer to the compiled version that you can call directly. It takes care of the boring (and often platform dependent) parts efficiently -- code gen, linking, etc -- so that you can focus on generating efficient IR (which is the hard part for a JIT).