On Mon, Nov 16, 2009 at 6:45 PM, John Cowan <[email protected]> wrote: > In the end the answer will be fixnums. As things stand, Integers are > so slow that BigIntegers aren't much slower: consequently, I decided, > since I needed unlimited size integers, to use BigIntegers > exclusively. This eliminated a lot of annoying conversions, which now > happen only when talking to Java methods.
Fixnums are certainly the final answer, or even better, support for general-purpose value types on the JVM. But in the interim, we need other solutions. And of course, we need someone willing to work on Fixnums. Maybe we need to make more noise about it? :) I'm very intrigued by your idea to just use BigInteger everywhere. In JRuby, we currently have Ruby Fixnum implemented using a Java long, and then all math operations check for overflow to potentially return a Bignum (wrapping a Java BigInteger). RubyFixnum itself is a Java object with one reference field (Ruby metaclass), one int field (Ruby object flags), and one long field (the Fixnum value). For every math operation, we're allocating one of these (though like JDK and Clojure we have a cache, in our case from -128..127) plus checking overflow. I make all of this logic inline, but have not seen EA eliminate any of it so far. When we turn off some compatibility-mode features of JRuby (like the artificial frames we maintain) we perform basically as well as Clojure for math and dynamic calls...which I think is impressive since our call pipeline is substantially more complicated. But pushing performance any further requires something more. Have you compared Integer/Long allocation plus overflow checks to just using BigInteger? One of the irreducible pieces of this logic (which I can see make it into the final assembly, even when inlining all logic) is the overflow check...probably 15 x86 instructions for every math operation, not counting typechecks and object allocations. I'd love to find a way to eliminate that. >> * JVM languages that use closures are forced to heap-allocate >> structures in which to hold closed-over values. That means every >> instantiation of those closures allocates purely-transient objects, >> populates them with data, and passes them down-stack for other code >> bodies to use. > > The key in this case is, I think, to create flat closures that contain > only the necessary variables, after boxing all assigned-to variables > so that you can copy the box pointers. I know this is what Groovy does. In JRuby, we support this mode, but there are some features of Ruby that complicate heap-allocating only the local variables we can statically see are being accessed. Ultimately though I'm not sure the size of the heap structure allocated makes a great deal of difference...it's the allocation and GC of that structure that are costly, regardless of the size. Plus the difference between putting all potentially closed-over variables on the heap versus a couple of them is only a few bytes of contiguous memory. Peanuts. >> Another wrinkle is the use of immutable structures, as in Clojure. I'm >> curious whether such systems generate more garbage than those that >> permit the use of in-place-mutable structures (seems to me that they >> would) and how that plays into memory bandwidth, allocation and GC >> rates, and whether the bulk of the extra garbage is young or gets >> tenured in typical usage. > > My guess would be that most people only care about the most recent > state, which means that older states become young garbage. That's certainly true, but depending on when the older states become garbage you could have a much higher turnover rate than for algorithms that use a mutable structure in-place rather than spinning new immutable structure for every mutation. At any rate, the problems faced by immutable data structures on current JVMs are very similar to those faced by JRuby, so I'm interested in finding a solution for both of us. - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=.
