headius

18 ms·

181.
by headius 16y ago
I probably should have made this clearer, since others have asked the same question. This suit is unlike the Sun v Microsoft suit in that Microsoft was building a licensed Java implementation, which they actually advertised as being a com
182.
by headius 16y ago
Sounds pretty cool :) I'd love to see some blog posts about it, but I doubt I'll have time to do so in the next couple weeks.
183.
by headius 16y ago
If there's something we or the JVM could do to improve these numbers, I would love to talk to you about it. At this point, if the JVM developers haven't found the magic sauce, we JRuby guys probably won't either...but I'd really love for JR
184.
by headius 16y ago
Object sizes in JRuby are certainly larger, especially if you run on a 64-bit JVM which necessarily has 64-bit reference fields for all object references (basically everything in Ruby). It doesn't surprise me at all to see a single-threaded
185.
by headius 16y ago
We hear this a lot. Hopefully we can keep improving startup times, but when it's possible to use either Ruby or JRuby, it makes a pretty good combination.
186.
by headius 16y ago
I'd like to see that too. In JRuby, we may be able to get Ruby-to-Ruby calls to perform as well as Java calls, which would at least get that bottleneck out of the way. The remaining performance issues, however, are usually the rate at which
187.
by headius 16y ago
It's also worth pointing out that while a JRuby/Rails instance might take 100-200MB, that's all you need to scale a site across pretty much any number of cores. MRI and REE both need to spin up multiple processes to handle concurrent reques
188.
by headius 16y ago
A large part of startup time is out of our hands, but we continue to look for workarounds. Most current startup slowness is due to the JVM itself running slow during the first few seconds of execution. Ruby scripts execute as they boot, whi
189.
by headius 16y ago
InvokeDynamic and other Java 7 features (method handles, NIO2) are definitely going to improve JRuby's situation, but maybe not in the way you expect. Indy and method handles will largely allow us to delete (or not load) code we currently g
190.
by headius 16y ago
I can comment on the JRuby results. For the base perf numbers, I'm not surprised. We've known that we're roughly on par with 1.9.2 for some time, and many of the benchmarks in question have started to reach a point of irreducible complexity
191.
by headius 16y ago
That's exactly the sort of thing I was hoping to see out of the JVM's default serialization. As it stands I think I'm going to basically have to define a custom marshaling format and hand-serialize everything for the domain I'm interested i
192.
by headius 16y ago
I'm not opposed to anything that seems like it might help bring more people to JRuby (and by extension, to Ruby). You can already access most of JRuby's internals via our Java integration layer, and that includes the AST, various core types
193.
by headius 16y ago
Ahh, I see where the confusion comes from. I meant initializing in the Ruby way...which is analogous to construction. There's no way for you to specify how to construct the object being deserialized from the stream, and so you need a no-a
194.
by headius 16y ago
And true to form, on the JRuby project we're looking into ways to optimize around where the JVM doesn't quite serve us well. I've recently been experimenting with doing my own dynamic optimization passes, and that let me to think about how
195.
by headius 16y ago
GAE has a lot more at play than standard JVM startup/warmup. JRuby on a desktop "client" Hotspot Java 6 starts up in around 0.5 seconds. On App Engine it can take as much as 10-15 seconds. Why? Because App Engine has a very different enviro
196.
by headius 16y ago
I mean the built-in serialization. Outside of the classloading and security hacks required to make it work, the fact is that it performs at its worst if you don't do things like provide a no-arg constructor and non-final fields. In those
197.
by headius 16y ago
Aren't String and Array a mix of both C++ and Ruby, though? So it's a bit more like saying it's running that mix of C++ and Ruby 1.5x slower than MRI runs C, for varying percentages of Ruby and C++. Still awesome though!
198.
by headius 16y ago
I'd love to see your benchmark to understand why JRuby wasn't faster than that. I assume you ran with the --server flag to JRuby as well.
199.
by headius 17y ago
FWIW, Duby is not "done" or "ready" yet, but it's moving along. The promise of a static-typed language with all the expressive power of Ruby (or at least, Ruby's syntax), but the performance of Java and no runtime library is very compelling