headius

16 ms·

121.
by headius 15y ago
I feel like the MRI devs get beat on a bit too much, and they're doing the best job possible with very few paid developers. I'm more interested in showing how JRuby is improving over time than rubbing salt in the wounds.
122.
by headius 15y ago
Oh, and regarding JRuby versus Python 3...yes, if Ruby 1.9 smokes Python, and JRuby is faster than Ruby 1.9, then JRuby should smoke Python even more. I have not done the comparisons myself, though.
123.
by headius 15y ago
Duby has become Mirah, and though I have not personally had a lot of time to work on it, it has continued slowly forward. It is basically just Ruby syntax for writing Java, though, so it performs identically to Java. I don't know the status
124.
by headius 15y ago
You can certainly just call JRuby directly with the 'java' command, or just set your environment to point at the Java 7 install only when you need it, rather than forcing your whole environment to use Java 7 by default. I imagine the comput
125.
by headius 15y ago
Recently we've been working more on JRuby master, on new features and performance. With JRuby 1.6.6 coming soon and 1.7 starting to stabilize, we'll be circling back to these bugs. Of course, we can always use help too :)
126.
by headius 15y ago
Fair enough :)
127.
by headius 15y ago
That applies to ARM. I'm not sure of the equivalent workaround for x86_64 outside of installing a 32-bit Java 7 and setting that up as the source of the Java plugin.
128.
by headius 15y ago
Your updated Java 7 is probably a 64-bit version. There's currently no Java applet browser plugin for 64-bit (and I'm not sure if there's plans to create one). If you don't mind missing out on Java applets, you'll be fine.
129.
by headius 15y ago
I obviously have, but I have a lot of respect for the MRI folks and usually don't publish those results. You're free to try it out yourself. In general, JRuby should be significantly faster than MRI 1.9.2 or 1.9.3 for running Ruby code, and
130.
by headius 15y ago
I can appreciate that having a personal opinion about Scala's use in one particular context belched out into the world is unfortunate, but I have to say that Coda's email reads like my laundry list of concerns about Scala. I could have writ
131.
by headius 15y ago
Use a smaller servlet engine. Most of them assume you will be fine with a larger heap and prepare caching structures, etc with that in mind Others are smaller and lighter.
132.
by headius 15y ago
Untrue. JRuby can run an app in under 200 MB easily, and close to 100 MB if tuned right.
133.
by headius 15y ago
This is one reason I never explored it. There has been some research into "gradually typing" dynamic-typed systems, and it gets hairy pretty quick. In any case, I know JRuby's not going to be able to get boxed math as fast as primitive math
134.
by headius 15y ago
It's all public on the MLVM list. Unfortunately there's only a handful of dynlangs actively hitting this stuff. Would love to see more Clojure folks get involved.
135.
by headius 15y ago
I certainly agree. As an implementer of Ruby, I've wanted type-hinting escape hatches to make my job easier. Given that they're likely never going to happen, I will continue to optimize the hard way and work closely with JVM guys :)
136.
by headius 15y ago
That's not true anymore. --fast is mostly eliminated now, with all features either on by default or replaced by better compilation. Math-like dispatches go through different dispatch logic optimized for Fixnums and Floats, this is true. If
137.
by headius 15y ago
Of course you can get the disassembly of JITed code from Hotspot too, and the effects of boxed math are quickly visible. Escape analysis may help in the future, if it can be made more general. While I consider type hinting an uglyish wart t
138.
by headius 15y ago
I will grant I do not know the details of Clojure's dispatch protocols, but I've always felt like there's more that invokedynamic could do. Sounds like that's the case. My statements were based mostly on brief discussions with Rich about ho
139.
by headius 15y ago
For a dynamic language to add static types solely to get performance seems like a hack to me. Make the dynamic language fast enough that you don't need static types. I can appreciate it was an explicit design decision. My calling it a "hack
140.
by headius 15y ago
Another general response... Paul Stadig points out that Clojure actually does lookup (from mostly-immutable sources) in many, many cases, and correctly theorizes that it could benefit by using invokedynamic in those cases. Worth a read. ht
141.
by headius 15y ago
invokedynamic is extremely powerful whenever there's a need to dynamically bind some function or variable. That means even statically-typed languages might benefit. In JRuby, it brings us within a stone's throw of Java performance for simpl
142.
by headius 15y ago
I'll do a bulk reply since there's lots of comments here I would reply to. Clojure doesn't need invokedynamic in general because Clojure doesn't really dispatch dynamically. It's dynamically typed, but calls are made via a known path to a s
143.
by headius 15y ago
Rubinius's parser is C/++ code derived from the same Bison grammar as regular Ruby. That's not to say it couldn't be pure Ruby, but it isn't right now.
144.
by headius 15y ago
It's mostly lucky (or unlucky) that the constant benchmark now optimizes away to nothing. As I mentioned in the comments (replying to that commenter), my point was to show that the overhead of constant lookup is now nearly zero, so if the v
145.
by headius 15y ago
I don't know the granularity on which the deoptimization guards get inserted, but the basic idea would be that if the constant changes, any code running that depended on the value of that constant will have to deoptimize. In your example, w
146.
by headius 15y ago
Don't get me wrong, I think the DLR is a great piece of work. It's just limited in how much it can optimize dynamic dispatch since CLR itself can't dynamically optimize. As far as tooling for building languages, DLR is pretty epic. It's too
147.
by headius 15y ago
I assume you're referring to the Dynamic Language Runtime (DLR). DLR does nothing even close to invokedynamic for optimization. The best you can do with DLR is regenerate little dispatch stubs at each dynamic call site, to at least avoid th
148.
by headius 15y ago
Yeah, for that I don't have a solution. It seems like there ought to be a way to have FFI libraries bring along the lib they need and compile it right there, but portable C libs are still a bitch to manage across platforms no matter what yo
149.
by headius 15y ago
Actually a lot of the process size in JRuby is the fact that we need to set JVM's max size high for rare cases, but then the JVM happily grows to fill much of that size. If you choke it down to a smaller size, we're competitive with at leas
150.
by headius 15y ago
That's great to hear! Given that FFI is intended to work across all Ruby impls, I wish there were more attention paid to using FFI instead of C extensions. I will admit there are some usability problems, especially around cross-platform str

More ›