Earlier quoted context omitted.
One of the main Topaz developers now works on the Python equivalent of TruffleRuby.
You mean a python implementation on truffle? Or ruby on something truffle-like on RPython?
The former.
Ruby 2.6.0-preview2 released with JIT
111–120 of 136 posts
Re: Ruby 2.6.0-preview2 released with JIT
#112Earlier quoted context omitted.
>The initial results of MJIT for simply removing the instruction dispatch overhead and doing some basic optimizations are a 30-230% performance increase on a small but real-world benchmark. No type specialization and specular optimization required So, this amounts to a small improvement for some types of code. Indeed, it is "easy" to get that by "just" using some basic JIT techniques. The trick is to get consistently…
> The trick is to get consistently better performance across the board. This will come with the rest of the opimizations Takashi has planned for Ruby 2.6. Ruby-Ruby method inlining, which is almost finished, is a huge one for improving Rails performance. IMHO there's no real point talking about Rails until it's working in some form. > >I've just committed the initial JIT compiler for Ruby. It's not still so fast yet…
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.
Re: Ruby 2.6.0-preview2 released with JIT
#113Earlier quoted context omitted.
> The trick is to get consistently better performance across the board. This will come with the rest of the opimizations Takashi has planned for Ruby 2.6. Ruby-Ruby method inlining, which is almost finished, is a huge one for improving Rails performance. IMHO there's no real point talking about Rails until it's working in some form. > >I've just committed the initial JIT compiler for Ruby. It's not still so fast yet…
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 function: https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
This article literally describes how baseline JIT is worth it simply to remove the bytecode VM dispatch overhead.
Re: Ruby 2.6.0-preview2 released with JIT
#114Earlier quoted context omitted.
> It's the Rails convenience stuff which slows things down massively. Yeah no kidding.. https://samsaffron.com/archive/2018/06/01/an-analysis-of-mem...
Or Specifically Active Record. Are we going to get Turbo Record soon? :)
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.
Re: Ruby 2.6.0-preview2 released with JIT
#115> 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…
Sinatra + Sequel is already very competitive in web performance with Go + Gin[1]. It's the Rails convenience stuff which slows things down massively. MJIT could probably bring Rails in line with Sinatra though. Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. Ruby 1.8 was a tree walking interpreter, so the…
Ruby's GIL will get in your way when working with real world apps. Also in this recent run gin doubles Sinatra's performance
https://www.techempower.com/benchmarks/#section=test&runid=a...
Re: Ruby 2.6.0-preview2 released with JIT
#116Re: Ruby 2.6.0-preview2 released with JIT
#117Earlier quoted context omitted.
Sinatra + Sequel is already very competitive in web performance with Go + Gin[1]. It's the Rails convenience stuff which slows things down massively. MJIT could probably bring Rails in line with Sinatra though. Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. Ruby 1.8 was a tree walking interpreter, so the…
Ruby's GIL will get in your way when working with real world apps. Also in this recent run gin doubles Sinatra's performance https://www.techempower.com/benchmarks/#section=test&runid=a...
Interesting! Thanks.
CRuby's GIL doesn't really matter for serving web requests since it's run with one process per core like NodeJS is. It's less memory efficient but doesn't really affect throughput so much. Also, JRuby has no GIL.
Re: Ruby 2.6.0-preview2 released with JIT
#118Earlier quoted context omitted.
Or Specifically Active Record. Are we going to get Turbo Record soon? :)
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 default. Not even sure if it's available in other databases besides PostgreSQL.
Re: Ruby 2.6.0-preview2 released with JIT
#119Earlier quoted context omitted.
Because Oracle is Oracle, the most evil company in tech, the one most blatantly greedy. Look at what they pulled with Google. Oracle would wait till the tech usage grows and then use patents and API copyrights or whatever else they invent out of thin air to go after the players using its tech. The free license of Graal does not protect you from that, GPL2 specifically not. See https://www.gnu.org/licenses/rms-why-gpl…
Google abused Sun, took advantage that they were in a critical financial situation not able to sue, and when they crashed, did not move a finger to rescue the company assets. Now Android has Google's own J++, limiting what kind of Java libraries are portable to the platform. At the same time, some OEMs are adopting Android instead of Embedded Java, thus increasing the fragmentation about what Java libraries are actua…
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....
Re: Ruby 2.6.0-preview2 released with JIT
#120Earlier quoted context omitted.
Google abused Sun, took advantage that they were in a critical financial situation not able to sue, and when they crashed, did not move a finger to rescue the company assets. Now Android has Google's own J++, limiting what kind of Java libraries are portable to the platform. At the same time, some OEMs are adopting Android instead of Embedded Java, thus increasing the fragmentation about what Java libraries are actua…
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.