headius

7 ms·

31.
by headius 3y ago
You know a lot about JRuby's use of FFI! One correction though, JRuby uses a reimplementation of jna called jnr, which is generally much faster (close to jni for simple calls). We are working with folks on the FFM team to re-implement
32.
by headius 4y ago
So sad. Bob was brilliant and an all-around nice guy. He gave the JRuby team a tour of the Square offices when they were just getting started and advocated for our use there while he was CTO. What a tragic loss.
33.
by headius 5y ago
Glad to hear you got some benefit from JRuby! A lot has changed since 2011, including much better compatibility and many little performance improvements. I'm not sure we were even on the current JRuby runtime (register-based IR + JVM J
34.
by headius 5y ago
JRuby is in wide deployment at hundreds or thousands of businesses across every industry. We generally run real-world apps much faster than CRuby (lower latency, better use of CPU and memory) and are especially good at big data and high con
35.
by headius 6y ago
JRuby is also usually faster (sometimes much faster) on straight-line CPU-heavy operations, but you're right... real parallelism is one of the biggest selling points.
36.
by headius 6y ago
The main reason that JRuby and truffle Ruby parted ways was due to their desire to support C extensions. We went down that road many years ago and decided that the performance characteristics of the MRI extension API inside a managed VM lik
37.
by headius 6y ago
If you're willing to try again, I'd love to see that benchmark. JRuby almost always beats MRI on computation heavy benchmarks oh, and we have continued to get faster over the years. I would be very surprised if a string heavy benc
38.
by headius 6y ago
The optcarrot benchmark is pretty far from being typical Ruby code. It simulates several chips inside the Nintendo entertainment system and essentially interprets the instructions those chips would execute. In actuality, real world benchmar
39.
by headius 8y ago
I'm not sure if you've looked recently, but we support the big three databases up through Rails 5.0, with sqlite3 support available for 5.1 and mysql and pgsql coming very soon. We need help keeping up, but we're not that far
40.
by headius 8y ago
JRuby 9.2 will continue to support Java 8 through the end of the year, and then we'll reevaluate minimum Java version for JRuby 9.3 early in 2019. Maintaining support for older JVMs, especially ones that have been officially end-of-lif
41.
by headius 8y ago
I'm sorry to hear this! We have worked very hard to keep JRuby stable, but sometimes things drift when more issues come in than we can keep up with. If you can point me toward the issues you're having, I'll try to prioritize
42.
by headius 8y ago
I believe much of the work on forking preloaders could be modified to work with a single JRuby JVM process, or with the Drip JVM preloader. Hopefully we'll have time to make that happen, or someone from the community will step up to he
43.
by headius 8y ago
Yes the development experience is unfortunately a problem for all the optimizing Ruby runtimes. TruffleRuby with its SubstrateVM precompiling improves this situation quite a bit for trivial commands, but still takes longer than CRuby to boo
44.
by headius 8y ago
Torquebox was indeed a great server, but never generated enough interest from the Ruby community to become a full product. Without that, sadly, the developers didn't have a lot of motivation to keep working on it.
45.
by headius 8y ago
Great to hear it! JRuby has always tried to be the best "JVM Ruby" it can be, which means we've spent more time getting things like Rails to run inside a normal JVM or application server than anyone else. I don't see tha
46.
by headius 8y ago
TruffleRuby and JRuby have always been separate projects, but TR kinda "grew up" as part of JRuby for a couple years. Eventually we decided the goals were becoming too different so TR split back off into its own project. We still
47.
by headius 8y ago
Chris covered this pretty well, but you'll notice in my post and in the slides from my RubyC talk ( https://speakerdeck.com/headius/the-year-of-jruby-rubyc-2018 ) I usually include CRuby + JIT from this year in th
48.
by headius 8y ago
JRuby 9.2 already included some general improvements designed to help Graal optimize, and 9.2.x will continue that process. I have already landed logic in 9.2.1 that will "right-size" objects based on observed instance variables,
49.
by headius 8y ago
There's always more cool stuff! I'm hoping to leverage more and more of the work being done for Graal and Truffle in standard JRuby over the next year. Keep an eye out for Graal-specific improvements in JRuby releases soon.
50.
Running JRuby on the Graal JIT(blog.headius.com)
173 points by headius 8y ago|36 comments
51.
Benchmarking a Go AI in Ruby: CRuby vs. Rubinius vs. JRuby vs. Truffle/Graal(pragtob.wordpress.com)
3 points by headius 11y ago|0 comments
52.
Performance Improvements in JRuby 9.0.3.0(blog.jruby.org)
2 points by headius 11y ago|0 comments
53.
by headius 11y ago
I think it's the most interesting because it immediately turned me off to the project. Releasing this only as GPL basically means it will NEVER be adopted en masse :-(
54.
by headius 11y ago
My comment on the article has not been accepted yet, so I'll add it here... So many things wrong here…where to start? Indeed trends: you’re looking at relative growth but don’t show overall numbers. Here, let me help you with that: ht
55.
by headius 11y ago
These benchmarks are very small and do not run long enough for the JIT to really kick in. Many of them are also so synthetic as to be meaningless.
56.
by headius 11y ago
Invokedynamic's benefits have been a bit of a mixed bag, but id does make the JVM see through dynamic call sites and optimize them like it does statically-typed call sites. That generally improves performance for JRuby, but there are
57.
by headius 11y ago
You're largely right. The problem is that $~ (and related vars) and $_ are scoped to the nearest method body. If they were scoped to the closure itself, there'd be no problem.
58.
by headius 11y ago
You have to ship some time. Noisy bugs get fixed...and patches are always accepted :-)
59.
by headius 11y ago
It would be worth proposing to ruby-core that captured closures are thread-local, but that would break a lot of code that actually depends on the sharing. Programming is hard :-(
60.
by headius 11y ago
We work closely with engineers at Oracle and JRuby is one of the premier projects on the JVM. There's also no legal way they could come after us; their suit against Google is about copying Java APIs, a very narrow domain.

More ›