On Nov 16, 11:09 pm, Charles Oliver Nutter <[email protected]> wrote: > 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 think it is essential to separate the *two* problems with boxed numbers. One problem is arithmetic with boxed numbers. EA, inlining, lever compilers etc can certainly do something about this. Frederik Öhrström gave an impressive demonstration at the JVM language summit showing how even large structures used as numbers could provide sufficient information to the compiler to enable their complete removal in arithmetic. The second, significant, and currently unavoidable problem with objects as numbers is that they do, in fact, escape. All the time. In order to be stored in our data structures. Obtaining their value requires a pointer deref, and when incorporated into the long-term information maintained by an application, they move out of the young gen. They might increase the number of active older objects by an order of magnitude or more vs a comparable Java program using primitives as fields and in collections. It is this latter problem that is bigger, and that fixnums address in a way I think nothing else can. Until references can be made to hold both an object reference on the heap and a number not on the heap, we are doomed to have to choose one. And choosing objects yields a terrible memory profile, in pointer nav, cache misses and GC. > 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. > I think you'll find the actual time cost of overflow checking is dwarfed by other things. CPU parallelism seems to do a decent job with overflow checks. > >> 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. > Immutable data structures have the very nice GC property that old things are never pointing to younger things. In addition, never being updated means they need not be volatile or have their access wrapped in locks. Yes, there is ephemeral garbage, and making that cheaper is always good. As Attila mentions in another message, being able to communicate about immutability to the runtime, and have it leverage that information, would be a huge win. Rich -- 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=.
